Proposed Resolution of Issue 223: Event-Timestamp and Duplicate Detection

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

The WG came to the conclusion at IETF 68 that Event-Timestamp should NOT be 
recalculated on retransmission.  Here are the changes necessary to address 
this issue in RFC 3576bis:

Section 2.3

Delete:

"     Note that if the Event-Timestamp Attribute is included, it will be
     updated when the packet is retransmitted, changing the content of
     the Attributes field and requiring a new Identifier and Request
     Authenticator."

Section 6.4

Change:

"When the Event-Timestamp attribute is present,
both the NAS and the RADIUS server MUST check that the Event-Timestamp
Attribute is current within an acceptable time window.
If the Event-Timestamp Attribute is not
current, then the packet MUST be silently discarded.
This implies the need for loose time
synchronization within the network, which can be achieved
by a variety of means, including SNTP, as described in [RFC4330].

Implementations SHOULD be configurable to discard CoA-Request or
Disconnect-Request packets not containing
an Event-Timestamp attribute.
A default time window of 300 seconds is recommended."

To:

"When the Event-Timestamp attribute is present,
both the NAS and the RADIUS server MUST check that the
Event-Timestamp Attribute is current within an
acceptable time window. If the Event-Timestamp
Attribute is not current, then the packet MUST be silently
discarded.  This implies the need for loose time
synchronization within the network, which can be achieved
by a variety of means, including SNTP, as described in [RFC4330].
Implementations SHOULD be configurable to discard CoA-Request or
Disconnect-Request packets not containing an Event-Timestamp attribute.

If the Event-Timestamp Attribute is included, it represents the time
at which the original packet was sent, and therefore it SHOULD NOT
be updated when the packet is retransmitted.
If the Event-Timestamp attribute is not updated, this implies that the 
Identifier
is not changed in retransmitted packets.  As a result, the ability to detect 
replay
within the time window is dependent on support for duplicate detection 
within
that same window.  RADIUS clients implementing this specification MUST be 
capable of
detecting a duplicate request if it has the same source IP
address, source UDP port and Identifier within a short span of time.

On RADIUS clients that support the Event-Timestamp Attribute for replay
protection,  the time window used for duplicate detection MUST be the
same as the window used to detect stale Event-Timestamp Attributes.
Since the RADIUS Identifier cannot be repeated within the selected time
window, no more than 256 Requests can be accepted within the time
window.  As a result, the chosen time window will depend on the
expected maximum volume of CoA/Disconnect-Requests, so that
unnecessary discards can be avoided.  A default time window of
300 seconds should be adequate in many circumstances."



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