Conflicting RADIUS && EAP retransmits (was re: Issues & Fixes..)

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> However, I think we might want to explicitly state in Section 2.1.2 that
> there is no need for per-NAS Identifier restrictions, using appropriate
> normative language (SHOULD?).

  How about adding the following text at the bottom of 2.1.2:

  "Implementations that do not use this algorithm are often restricted
to having an EAP Identifier space per NAS, or perhaps one that is global
to the implementation.  These restrictions are unnecessary when the
above algorithm is used, which gives each session a unique EAP
Identifier space.  The above algorithm SHOULD be used to track EAP
sessions in preference to any other method.

> Also, in the section on duplicate detection, we should make it clear
> that this should be handled at the per-EAP session level, not the NAS
> level,  potentially using the algorithm described in Section 2.1.2.  The
> concern is that if a RADIUS server implements clumsy Identifier
> restrictions, then the ability to support duplicate detection may be
> also limited.  For example, Jouni mentions a product that, when
> duplicate detection is enabled, imposes simultaneous session
> restrictions (not clear if this was per-NAS or (shudder) per server).

  Should we talk about EAP duplicate detection in a RADIUS document?  Or
just say something about RADIUS as a transport protocol?

  The following text is awkward, to say the least.  It also opens up a
weird case, as outlined below:


2.x.x  RADIUS as a transport protocol

  RADIUS is often used as a transport protocol for other authentication
protocols such as EAP.  When a transported protocol needs to send a
duplicate packet, that packet is often carried in a RADIUS packet that
is a duplicate of the one that carried the original transported packet.
However, the RADIUS protocol requirements mandate that in some
situations a new RADIUS packet is sent, such as when the RADIUS packet
contains an Event-Timestamp attribute.   In that case, the transported
packet is identical to that sent an earlier RADIUS packet, even though
the RADIUS packet performing that transport has changed.

  When a RADIUS server acts as a transport layer for other protocols, it
SHOULD implement duplicate detection for the transported protocol in
addition to RADIUS layer duplicate detection.  The algorithm described
above in Section 2.1.2 SHOULD be used to perform this detection.

  If the RADIUS server receives a duplicate transported packet for which
 it has already sent a transported response, it SHOULD resend the
original transported response without reprocessing the transported
packet.  This transported response MAY be carried in a different RADIUS
packet than one that carried the original transported response, due to
the RADIUS requirements mentioned above.

!!! What about interaction effects? !!!

  i.e. The RADIUS server is slow, and has not responded to a request.
For EAP, the supplicant may retransmit, the NAS may send a *new* RADIUS
packet with an Event-Timestamp, containing "duplicate" EAP information.

  The RADIUS server can't send a duplicate EAP response, because it
doesn't have one.  It can't silently discard the new RADIUS packet,
because that would cause EAP to fail.  It can't respond to the original
EAP request either, because the NAS may be tracking EAP sessions via
RADIUS ID's, and it now has a new RADIUS Id for the ongoing EAP session.

  We could tie EAP retransmits to RADIUS retransmits.  i.e. forbid the
RADIUS packet to change if the underlying authentication protocol is
retransmitting.  But that's not nice.

  I guess the only thing to do is mention this possibility, and note
that the only choice is to send the duplicate transported packet to the
underlying authentication protocol... which should also do duplicate
detection, and then send duplicate responses.

  i.e.

1. Access-Request Id=1, Event-Timestamp, EAP Id=2
2. RADIUS server sends EAP packet to EAP server.
3. Access-Request ID=2, Event-Timestamp, EAP Id=2
4. RADIUS server sees no RADIUS duplicate, sends packet to EAP server
5. EAP server notices duplicate, sits on the new request
6. EAP server finishes request from stage 2, responds to BOTH stage 2 &&
 stage 4.
7. RADIUS server responds with Access-Challenge Id=1, EAP...
8. RADIUS server responds with Access-Challenge Id=2, EAP...

  where the EAP content in (7) and (8) is identical.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>