eap Mailing List: Re: resolution to issue 161

[Bernard Aboba (aboba]

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