My thanks to the many people who responded to my post about security issues when terminal servers make the decision about whether to bond two physical connections into a single network connection (multilink PPP). Ascend has stated (unofficially) that their implementation was at one point insecure, and relied upon the TEI or EDO (endpoint identifier) to make the decision. This is in violation of standards. They state that their implementation has been secure for about three years and will not bond two connections together unless the authenticate with the same username. If multilink PPP is properly implemented, it should make two connections _eligible_ to be linked together if and only if their TEIs match. However, it must be prepared to not link them if they later identify (by PAP or CHAP) for different accounts. The RFCs state, according to Jeff Mcadams <jeffmat_private>: The Endpoint Discriminator Option represents identification of the system transmitting the packet. This option advises a system that the peer on this link could be the same as the peer on another existing link. If the option distinguishes this peer from all others, a new bundle MUST be established from the link being negotiated. If this option matches the class and address of some other peer of an existing link, the new link MUST be joined to the bundle containing the link to the matching peer or MUST establish a new bundle, depending on the decision tree shown in (1) through (4) below. To securely join an existing bundle, a PPP authentication protocol must be used to obtain authenticated information from the peer to prevent a hostile peer from joining an existing bundle by presenting a falsified discriminator option. The problem is, it seems that in some cases the router needs to do certain things one way if it's going to bundle the two connections together and another way if it's not going to, and it may need this information _before_ the new connection has authenticated: Dennis Kavanaugh <DCKavanaughat_private> states: Sadly, the real problem, IMHO, is in the Multilink PPP spec; if a vendor wants to conform to the spec, they must allow this to happen. I spent quite a bit of time with numerous vendors trying to explain the inherent vulnerabilities in the existing spec, but they didn't seem to understand or be bothered by the potential problems. The spec covers any type of MLPPP connection, be it dial-up ISDN (i.e., T/A), multiple async, or Brouter. Both ends must understand what can be done, and take steps to ensure they are providing as much security as they feel they need for the given situation. It's just another case where poor configuration can result in poor security. In reality, the resulting session when a hijacked session bonds with a legitimate session is unusable. Sort of 'security by unusability', if you don't count the DoS. The unusuability occurs because compression is usually in use, and the compression breaks when you only have part of a bundle. It seems that it is possible to do things right, but there are probably numerous implementations that incorrectly bond two connections with the same identifier even if they authenticate for different accounts. I still wouldn't want anyone else to know the Ethernet hardware address of my ISDN router. David Schwartz <davidsat_private>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:34:16 PDT