Issue 223: Event-Timestamp and Duplicate Detection

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Issue 223: Event-Timestamp and Duplicate Detection
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: March 19, 2007
Reference:
Document: RFC 3576bis
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

During the discussion of RADIUS duplicate detection it occurred to me that 
the inclusion of the Event-Timestamp attribute in RFC 3576bis messages 
impacts the duplicate detection functionality described in RFC 2865 Section 
3:

     The RADIUS server can detect a duplicate request if
     it has the same client source IP address and source UDP port and
     Identifier within a short span of time.

However, if an Event-Timestamp attribute is included in a request, then the 
Identifier will change on retransmission, and this technique will not work.

RFC 2869 Section 5.3, appears to prohibit inclusion of Event-Timestamp 
except in an Accounting-Request:

     This attribute is included in an Accounting-Request packet to
     record the time that this event occurred on the NAS, in seconds
     since January 1, 1970 00:00 UTC.

RFC 2869 Section 5.19 does not include a table row for the Event-Timestamp 
attribute, suggesting that Event-Timestamp is prohibited in Access-Request, 
Accept, Reject and Challenge packets.

However, RFC 3576 suggested inclusion of an Event-Timestamp attribute in CoA 
and Disconnect messages for replay protection.  Since the Event-Timestamp 
attribute will change on retransmission of a CoA-Request or 
Disconnect-Request, the Identifier will also change, and this implies that 
duplicates would potentially go undetected. Could this cause a problem?

I do not think so.  If one Disconnect-Request arrives and is responded to, 
then the user has been disconnected (or not) and receiving another duplicate 
request will not make a difference, since you can't disconnect a user twice. 
 Similarly, if a CoA-Request was already processed, processing it again 
will yield the same result.

Still, the Nonce attribute described in RFC 3576bis does not have this 
issue, because the Nonce doesn't change if the packet is retransmitted.  
Would it be a good idea to remove mention of Event-Timestamp from RFC 
3576bis?

Also, would it be a good idea to include language similar to RFC 2865 in RFC 
3576bis, such as:

     The NAS can detect a duplicate CoA or Disconnect-Request if
     it has the same server source IP address and source UDP port and
     Identifier within a short span of time.



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