Brian Lloyd wrote:
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.
Not just that, the LAC may also need to get authentication information from the
user so that it can know which LNS to forward to.
The LAC
communicates the options negotiated back to the LNS.
That's what we do now. Please read section 4.4.5 of RFC2661.
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.
But, if the LNS, say, want's to do some different authentication... Say, PAP
with an OTP but the LAC negotiated CHAP, then, well... We have to start over PPP
LCP, which should be OK except that it used to break a lot of PPP clients.
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.
Then let me give you a collective kick from all of the l2tp developers out there
;-)
I thought it was just a bug. I remember telling Robert Webster about this little
problem at a pacbell bakeoff many years ago. His jaw dropped, and he went back
and made an on-the-fly bugfix for it and afterwards it worked great. Note that
Robert worked at Shiva then, and maintained code for the PPP stack that for a
while was the original code base for much of the dialup client industry (e.g.
Windows, OS/2, and probably some others...).
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."
Until the customer calls you and says "Your access equipment doesn't work with
my customer's MAC clients. Fix it or we aren't buying any more equipment from
you."
In this particular case, the MAC was actually being too strict to the spec with
regard to ACCM... We were able to get by with every other more lenient PPP
implementation on the planet (except maybe some versions of OS/2), but not the
MAC. So, we made some clarifications in the protocol that are actually decent
refinements from a hardline perspective. It didn't bother me so much from a
purist standpoint given that we were doing something that was actually more
correct, though not entirely necessary as evidenced by the majority of PPP
clients in operation at the time.
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.
I hope you feel better. We don't want any tense pilots in the skies grumbling
over their past protocol design mistakes. ;-)
If you really want to excercise your noodle, think about what can happen if IPCP
retries start dropping options from a config request after 2 or 3 retries (but
we can take that offline if you really care).
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.
Oui, d'accord.
- Mark
Brian Lloyd
brian(_at_)lloyd(_dot_)com
+1.530.676.1113 - voice
+1.360.838.9669 - fax