Re: resolution to issue 161
From: Pasi.Eronen (Pasi.Eronennokia.com)
Date: Tue, 21 Oct 2003 03:49:20 -0500 (CDT)
Hi,

I agree with you in that the demultiplexing can't (or at least
shouldn't) be done at the link layer in e.g. PPP, since it would
need to look inside the EAP packets (to check the Code field). 

More likely it's done by "something" between the link layer and
EAP state machines. Would simply changing "lower layer" to
"implementation" be sufficient?

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Monday, October 20, 2003 9:20 PM
> To: eap [at] frascone.com
> Subject: [eap] Re: resolution to issue 161
> 
> > Add to state machine doc, section 2, before the last paragraph:
> >
> >  Some environments where EAP is used, such as PPP, may support
> >  peer-to-peer operation. That is, both parties act as peers and
> >  authenticators at the same time, in two simultaneous and
> >  independent EAP conversations. In this case, the lower layer to
> >  at each node has to perform demultiplexing of incoming EAP 
> >  packets. EAP packets with Code set to Response are delivered 
> >  to the Authenticator state machine, and all other EAP packets 
> >  are delivered to the Peer state machine.
> 
> What are the link layer requirements for support of EAP peer-to-peer
> operation?  I ask this because there is nothing in RFC 2248bis Section
> 2.4 or 3.1 that discusses these requirements.
> 
> For example, if there a requirement for the link layer to be
> able to demultiplex the EAP conversations in each direction,
> wouldn't that imply the need for a field in the link layer
> header with which to do this demultiplexing?  For example,
> IPv4/IPv6 packets are demultiplexed by different EtherType
> values, not really by the IP version number.
> 
> In Section 3.2.1 of RFC 2284bis the PPP Authentication
> Protocol format is defined.  EAP packets are encapsulated with
> an Authentication Protocol value of C227 (Hex).  Similarly, in
> IEEE 802.1X an Ethertype is assigned to 802.1X
> packets. Neither of these encapsulations can demultiplex EAP
> conversations occurring in different directions.  For example,
> there is no different Authentication Protocol value or
> Ethertype for this.
> 
> Since neither of these encapsulations demultiplexes EAP
> conversations in either direction, and the link layer does not
> look at frames deeper in the packet, such as the EAP Code or
> Type fields, I don't think that this explanation can be
> correct. If there is demultiplexing, then this would need to
> occur in the EAP layer, not in the link layer, no?
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap

Results generated by Tiger Technologies using MHonArc.