eap Mailing List: Re: Re: resolution to issue 161

[Bernard Aboba (aboba]

I think this is sufficient for the State Machine spec.  But I think we may
also need to change some text and possibly a figure in RFC 2284bis to
make it more clear.

For example, if multiplexing occurs on the "Code" field then it implies
that an "EAP peer" listener within an EAP implementation will not receive
EAP packets with Code=2 (Response) (but packets for all other Codes,
including 1, 3, 4).  Similarly, the "EAP server" listener will only
recieve EAP packets with Code=2 (Request). The implementation behavior
therefore differs based on whether there is an "EAP peer" or "EAP server"
listener present, or both.

This is a bit different than the behavior implied by RFC 2284bis as
where it is implied that an "EAP peer" will silently discard a
received EAP-Response packet.  If there is no "EAP server" listener
on the receiving host, or if there is but the EAP method only supports
"EAP peer" functionality, then silent discard will occur.  However if
there is an "EAP server" listener, and an EAP method registered with "EAP
server" functionality, then the EAP-Response might be processed.

There is therefore some implied multiplexing that occurs based on the Code
field, prior to the Type multiplexing which occurs later.  This is not
shown on the diagrams.

On Tue, 21 Oct 2003 Pasi.Eronen [at] nokia.com wrote:

>
> 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
>