At 11:59 PM 3/6/2002, you wrote:
> <sigh> It has been many years since I argued this with Karl Fox back when
> he chaired the L2TP WG.
Karl chaired only the pppext WG.
Then at the time L2TP or the precursor discussions were done within the
PPPEXT WG because the discussion was with Karl.
> At that time he agreed but also said that there
> was too much water under the bridge to fix L2TP at that time so it was
> going to go forward in its subtlely-broken form. I haven't looked at it
> since then. I don't even remember the lexicon so I will undoubtedly sound
> uninformed.
>
> The LCP negotiation should take place with the L2TP equivalent of the
> NAS. That is independent of anything else that happens and nothing
> associated with that needs to be communicated to the edge device at the
> target network. The authentication phase then takes place so you can do
> authorization and configuration.
That would have been nice, but, the requirements were that it be possible for
user authorization be completed at the LNS (the edge device at the target
network), and at the LAC (NAS).
Thank you for reminding me. LNS and LAC were the terms I was looking for.
WRT authentication, there is no reason not to do it in both places. Let
the protocol carry the information.
In addition, we could not require the user to
enter a username and password twice. You simply had to be able to drop in
L2TP, and everything look the same as it did before to the end user.
I agree that is the more desirable scenario.
> Once that is complete you can do the
> MLPPP and NCP negotiation(s) because then and only then do you know what
> the end system is authorized to do.
Yup, that would have been nicer.
Yes, it would.
> "But MLPPP is negotiated during LCP," you say! Right. That is broken and
> I helped make it broken and, in retrospect, I am *really* sorry I did.
That's OK, we'll forgive you ;-)
Thank you. It may seem silly but that has really bugged me for a number of
years. I hate the thought of having done flawed work.
Barring redesign of PPP, getting around the wrong things being located in
the LCP negotiation would have been made a little easier if we had been
allowed to go through LCP negotiation twice. So, you could have LCP
negotiated at the LAC,
But you wouldn't have needed to do LCP negotiation twice. The LAC
negotiates LCP because that is the terminus of the link. The LAC
communicates the options negotiated back to the LNS. Remember, the LCP
options negotiate only indicate what the client is willing to accept
therefore it doesn't really matter what it negotiates. It is just there to
prevent its peer from sending something it can't handle.
forward any necessary link parameters to the LNS so that it could set them
correctly during "LCP round 2", and then renegotiate LCP at the LNS to get
things like MLPPP and perhaps authentication type which should have been
designed into the negotiation process later.
Right. That is the crux of the problem.
But -- and here is the point about broken PPP stacks -- at the time there
were a lot of PPP stacks which would simply roll over and die if you tried
to reneogtiate LCP after you had already begun (yes, in great violation to
what it says in RFC 1661). This wasn't discovered until L2TP came along
because before that, you really didn't see LCP renegotiation occur very much.
<sigh> But we did know. The argument was that it took too long to
negotiate PPP as it was so anything we did to speed it up was necessary. I
have kicked myself for caving in to that argument for many years now.
But, it was way too late as there were so many clients in the field with
this bug. So, we ended up with Proxy LCP and Proxy Authentication like you
see them today.
I know: add more ugliness in order to deal with other ugliness. I
preferred the old days where people found problems, fixed them, and the
fixes then found their ways into new versions, usually with a
backward-compatibility switch. I reject the argument, "but we have lots of
systems in the field; we can't fix them now." Engineers from Microsoft
(among others but they come immediately to mind) has been known to use that
argument. It is specious because they then turn around and reissue code on
a regular basis to fix other bugs in their products.
There's not much else you can do if you want to complete PPP negotiation
at the LNS, but *start* it at the LAC so that you can get the "@domain"
portion of the username to determine where to tunnel the user. Sigh...
Yes, if we had thought about running PPP over IP from the beginning,
things might have looked very different in general... A more seperate link
layer negotiation would have been one of them. But, PPP isn't nearly as
difficult as, say, TDM over IP ;-)
This reared its ugly head when we started to do multilink PPP. The problem
was *very* clear then. Pointing out that LCP and NCP were really
completely separate protocols and represented different layers is what made
it possible to resolve the deadlock in the WG at that time.
There are even other "bugs in the field" we have had to code around with IPCP
negotiation, and don't even get me started on ACCM mapping....
You know, sometimes you just tell people, "this is the way it is done so
make your implementation conform."
> So, as I said, this is water under the bridge and it isn't going to
> change. Any attempt to do so would be met with a barrage of "but we have
> lots of systems in the field and this would break them" arguments.
Right. The same argument that led to some of the choices we had to make in
L2TP.
Yes, but I wanted to get this off my chest after all these years.
> >Tunneling, particularly L2 tunneling, is by its very definition a "layer
> >violation". The perfect world where this is not necessary or desirable
> >does not
> >exist beyond textbooks and laboratories. So here we are in the real world,
> >tunneling not just PPP but a plethora of L2 or L2-like layers.
>
> There is nothing wrong with tunneling per-se. In fact, it solves many
> problems. IMHO tunneling is a good thing. My comments had only to do with
> the fallacy of rigid layering, how many people don't really understand
> layering, and as a side issue, how PPP was really a suite of protocols at
> different layers and how that affects MLPPP and L2TP.
Then we agree more than we disagree :-)
I suspect so. I find that, when people talk an *engineering* problem
through to its real conclusion, they are more in accord than not.
Brian Lloyd
brian(_at_)lloyd(_dot_)com
+1.530.676.1113 - voice
+1.360.838.9669 - fax