Hi Jari, I agree with you that a more optimized implementation can consume less amount of memory allocation even when a cookie and the first EAP request are carried in the handshake phase messages. In fact, the specification does not prohibit the operation:
" The initial EAP Request message MAY be optionally carried by the PANA-Start-Request (as opposed to by a later PANA-Auth-Request) message in order to reduce the number of round-trips. This optimization SHOULD NOT be used if the PAA is desired to be stateless in the handshake phase since transmission of an EAP Request message creates a state at EAP layer. See [RFC4137] for more information on the EAP state machine and the allocation of state information in the respective protocol steps. " Or are you suggesting to *always* carry EAP message in the handshake phase messages regardless of L-flag? Regards, Yoshihiro Ohba On Tue, Oct 03, 2006 at 05:26:40PM +0300, Jari Arkko wrote: > Yoshihiro, > > Since PaC and PAA may be communicating over multiple IP hops (and thus > > PAA is exposed to attackers in the Internet in general), it is > > important from security perspective to support stateless operation > > until rechability of the PaC from the PAA is verified as much as > > possible. > > > > Speaking of EAP layer state, I know of an existing EAP authenticator > > state machine implementation that requires more than 500 bytes of > > memory allocation per EAP session. > I'm not sure this is a major problem. I agree that we need to > verify that the client is a real entity before engaging in a > costly exchange. But the first EAP message is EAP Identity > Request, and it comes from the PAA, not from the AAA. > There's really very little need for state at that time other > than the ID value from the EAP packet, but even this could > be either static or somehow related to the Cookie value. So > I think implementations can be built to be stateless even > if you send the first EAP message at an early stage. > > --Jari > > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
