[e2e] on local ethernet throughput?

[Andrew Smith]

Vern,

I didn't miss your point - I was starting from the premise that people had
already decided to do Ethernet-over-DSL: once they'd decided that they would
have done better to use something 802.1X-like for
authentication/authorisation (can't say they should have used 802.1X since
IEEE didn't have it fully cooked at that time).

I didn't take it as a premise that PPP was what people would run on top of
such things and underneath IP. But that's the most screwy part - putting
connectionless IP on top of connection-oriented PPP on top of connectionless
Ethernet on top of connection-oriented ATM on top of point-to-point DSL on
top of (by definition :-) point-to-point copper wire!

Andrew Smith

P.S. Sorry you didn't like my "fancy jargon" - I thought stuff like that was
what most people on this list understood.

-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org]On Behalf Of Vernon Schryver
Sent: Wednesday, October 24, 2001 4:09 PM
To: end2end-interest at postel.org
Subject: RE: [e2e] on local ethernet throughput?


> From: "Andrew Smith" <ah_smith at acm.org>

> You're missing my point: for every new link technology, you do need two
> forms of interaction between the control plane and the data plane in the
> device that is situated at the point where you want to control access, in
> order to a) extract the authentication information from the data stream
and
> b) to enforce the authentication decision (or, to be precise, the
> authorisation decision). That is all that 802.1X specifies, for 802-like
> link technologies. You are correct that there is no need to re-invent the
> authentication protocols themselves for each link technology (802.1X does
> not touch that).

I don't think I missed that point.

If you mean that if DSL were going to use some kind of 802 framing
like 802.3, then 802.1X would have been right, then I'd agree.

What you may have missed is that there was no need to get any 802
anything involved.  Fancy jargon about planes does not make a
fundamentally simply and long ago solved problem complicated.
80.21X may be wonderful for 802.11 and other links that have nothing
to do with PPP (or necessarily to do with IP).
As long as they are using PPP with PPP's authentication mechanisms,
jamming Ethernet between PPP and the DSL framing was just plain silly.


> The issue of whether PPP needed new authentication protocols is an
entirely
> separate question that is link-technology-independent - many in IETF
> believed that there was a need for something to decouple the operational
> issues around continuously upgrading PPP authentication in the dial-up
> servers (RASs): they came up with EAP (which is really just a framework)
> which makes things easier in that regard (not perfect of course, but
> better).

Don't tell people in the PPPEXT WG, but I'm not the only WG participant
that considers EAP a typical case of what's wrong with the IETF.
EAP would nothing to stop upgrading PPP authentication code in dial-up
servers, if there were any real need to upgrade PPP authentication
code in dial-up servers except to fix bugs, of which there would be
more for EAP if EAP were widely implemented.  All that EAP does
or can do on that front is cause more upgrading of RAS firmware.
EAP does nothing to solve the real problem in PPP authentication,
which is the fact that it happens after LCP instead of during.  EAP
might have been the better way to do AUTH, but given AUTH, EAP just
gilds the sows ear with not really useful extensibility that does not
make a silk purse.


Vernon Schryver    vjs at rhyolite.com