Subject: re: Multilink with unidirectional authentication

From: [email-masked] (Vernon Schryver)
Date: Mon, 19 Jan 1998 21:40:52 -0700

> From: John Bray <[email-masked]>

> There has been much discussion in the past on the relationship between
> the endpoint discriminator and authentication when bundling links to
> together using MP. However, I haven't seen the following issue
> specifically addressed, and I'd like to get some opinions as to how to
> interpret RFC 1990, Section 5.1.3.

Section 5.1.3 says 

]   (4)  Discriminator, authentication:
]        Discriminator match and authenticated match -> MUST join bundle,
]        discriminator mismatch -> MUST establish new bundle,
]        authenticated mismatch -> MUST establish new bundle.

What does "authenticated mismatch" mean?  Does it mean "authentication
failed (i.e. secrets did not match)," "no authentication offered or
required," or "authentication succeeded but with different 'username'
and/or authentication protocol"?

What is the meaning of "MUST establish new bundle"?  Can your
implementations tolerate more than one bundle between a single pair of
peers?  Most cannot, which implies that "MUST establish new bundle"
really means "MUST drop or reject a link."

The text in section 5.1.3 is a hopeless mess.  I think in part it
reflects the controversy about how to identify links and bundles. 
I opposed Endpoint Discriminators because they are entirely redundant
if you have authentication, and you cannot trust or use an Endpoint
Discriminator until after you have passed Authentication.  Any
information that an ED can carry can just as easily be carried, for
example, as an ad hoc subfield of the authentication username.

Others didn't like the bookkeeping required to know all of the
usernames and secrets associated with any particular bundle, and got
hives at the though of ad hoc subfields.  Some even argued for
usernames and secrets shared by many users.  (Never mind that unsecret
secrets have little to do with what most understand as
"authentication.")

One difficulty with my position is that you cannot know whether
authentication "matches" (usernames?) until after the Authenticate
Phase, but you must know which bundle you are going to use earlier,
during the Establish to pick the right MRRU, MTRU, MRU, MTU, and other
parameters.

> Consider a bundle in which there are two links between host A and host
> B. Host A supplies the same ED in its LCP Config-requests on both
> links. Host B does likewise. In the absence of authentication, this
> means both links must be bundled together (scenario (2)). Now consider
> what happens if A authenticates B on one link, and B authenticates A
> on the other.  Do we have one bundle or two? 

So you figure the "matching" in section 5.1.3 applies only to the
boolean of whether authentication is present, and not to the username,
secret, IP address, customer name and Postal Service address of the
outfit owning the user name, or even something else associate with 
authentication?

> My interpretation is that we have two bundles, since the
> authentication does not match between the two links. This falls under
> scenario (4). Host A has an authenticated name for B on the first
> link, but not the second. Host B has an authenticated name for A on
> the second link, but not the first. To me, that's a mismatch.

In that case, what do you do with your two MP bundles?
Can you have, for example, two MP bundles, each with two PPP links,
between a pair of hosts at 192.0.2.2 and 10.1.1.1?

> However, I've run across another vendor that has chosen to put both
> links in one bundle in this case. I'm not sure whether they are just
> keying on the ED when one link is not authenticated, or whether they
> assume that since they initiated the dialup call for the link they
> didn't authenticate (i.e. B called A for the first link, A called B
> for the second), it is safe to rely on the name in the CHAP challenge
> from the remote peer to match the authenticated link.

Are you asking about authentication?  How does B ensure that the second
phone call is from the same A that B phoned first?  You are assuming
different CHAP secrets for the two directions, aren't you?  If not,
have you spoken to Carl Fox?

I think practical considerations must rule.  Most systems cannot use
more than a single PPP bundle to a peer.  That implies that in real
life, you must either add a second link to the existing bundle or you
must drop it.  Thus, whether you choose to drop it or bundle it should
depend on whether you trust it.  If it has been authenticated to your
satisfaction (and you might require no authentication), then add it.
Otherwise, distrust and drop it.

The best solution (assuming we never move Authentcation into Establish,
perhaps with a modified ED, as has been proposed), is to require ED's
to match to join a bundle, and use authentication only as
authenticating the validity of the preceding ED's.

Vernon Schryver,  [email-masked]

---

From: Clara Mckenzie <[email-masked]>
Date: Tue, 20 Jan 1998 10:24:11 -0800 (PST)

> 
> From: Vernon Schryver,  [email-masked]
> 
> 

Practical considerations aside,  our customers demand multiple bundles
between peers.  Which leaves us to identify the bundles with the endpoint
discriminator and information derived from the authentication.

/clara mckenzie
ascend communications