Re: Issue 223: Event-Timestamp and Duplicate Detection

[Alan DeKok <aland@nitros9.org>]

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

  Yes.

> RFC 2869 Section 5.3, appears to prohibit inclusion of Event-Timestamp
> except in an Accounting-Request:
...
> 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.

  That sounds good.

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

  So long as there are no race conditions (login, disconnect, login,
duplicate disconnect), that would appear to be OK.

  A longer term fix would be to require Access-Request packets to
contain a Acct-Session-Id attribute, which would be used to detect
duplicate sessions, independent of duplicate packets.  That fix would
also mean that EAP may not need the State attribute, as discussed in the
Isses & Fixes draft.

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

  I would agree.  Optional parts of the protocol that could cause
problems are best left umentioned.

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

  Yes.

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