PPP/ISDN multilink security issue - summary

[davids () WEBMASTER COM (David Schwartz)]

        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 <jeffm () iglou com>:


        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 <DCKavanaugh () nersc gov> 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
        <davids () webmaster com>