« 2013 Software Traini... | Main | Reminder: Unidata's... »

Version 6.11.4 of the Local Data Manager (LDM) has been released. This version fixes and improves the defense against a denial-of-service attack, which is new with version 6.11. Getting the defense right was trickier than initially thought.

A key aspect of the defense is that a request by a downstream LDM that duplicates an earlier request from the same downstream host will cause termination of the upstream LDM process that's servicing the earlier request. This has ramifications for LDMs running on distinct computers that request data from the same upstream LDM from behind a Network Address Translation (NAT) device. To the upstream LDM, all the requests will appear to come from the same IP address (that of the NAT device). Consequently, duplicate requests will interfere with each other. The solutions to this situation are:

1. Have one LDM request all the desired data and have the other LDMs request from it;
2. Make the patterns in the REQUEST entries distinct by enclosing them in different numbers of parentheses (e.g., ".*" on one computer, "(.*)" on the second, "((.*))" on the third, etc.);
3. Have the LDMs request from each other as well as the same upstream LDM and just live with the resultant churn in the connections.

The significant new log messages of LDM 6.11.4 are:

Terminated obsolete upstream LDM
?(addr=ipAddr, pid=pid, vers=vers, type=type, mode=mode, sub=(sub))

This means that the upstream LDM that logged the message terminated the indicated earlier upstream LDM because the logging LDM will send at least the same data as the earlier LDM to the same downstream host. ipAddr is the IP address of the downstream host, pid is the process identifier of the earlier LDM, vers is the LDM protocol version (5 or 6), type is the type of the earlier LDM (feeder or notifier), mode is the transfer-mode of the earlier LDM (primary or alternate), and sub is the subscription that the earlier LDM was satisfying (feedtype, pattern, etc.).

If this happens a lot (on the order of once per minute), then 1) the downstream "host" might actually be multiple hosts — each running an LDM that makes the same request — that are hidden behind a NAT device (as described earlier); and 2) you should contact the LDM user at the downstream site to make sure that everything is OK.

Subscription reduced by one or more existing subscriptions: requested -> allowed

This means that the upstream LDM that logged the message reduced the subscription from its associated downstream LDM by the amount that the subscription overlapped subscriptions that are being currently serviced by existing, previously-created upstream LDMs. Note that this can result in an empty subscription, in which case the downstream LDM will close the connection and retry sometime later. Here requested is the initial subscription and allowed is the reduced subscription.

You should contact the LDM user at the downstream host and tell them that they are making redundant requests. 

If you need to contact the LDM user at the downstream site, the email address "ldm@host" should work, where host is either the fully-qualified name of the downstream host or its IP address. It might be necessary to enclosed the IP address in square brackets.

Besides ensuring against the denial-of-service attacks that we've seen, this new feature of LDM 6.11 should reduce unnecessary bandwidth usage by enforcing the requirement that requests for data from the same upstream LDM be disjoint.

This version can be downloaded at https://www.unidata.ucar.edu/downloads/ldm.

For documentation and additional release information, see this version's homepage.