DISCUSS and COMMENT: draft-ietf-radext-fixes

[Bernard Aboba <bernard_aboba@hotmail.com>]

> To: iesg@ietf.org
> CC: draft-ietf-radext-fixes@tools.ietf.org; radext-chairs@tools.ietf.org
> From: jari.arkko@piuha.net
> Date: Tue, 3 Jul 2007 14:11:09 -0400
> Subject: DISCUSS and COMMENT: draft-ietf-radext-fixes 
> 
> Discuss:
> This is an overall great document, long overdue, and I will
> move to a Yes vote once the below issues have been properly
> handled.
> 
> Section 2.2.2 states:
> 
> > Cache entries MUST also be purged if the server receives an
> > Access- Request packet that matches a cached Access-Request
> > packet in source address, source port, RADIUS Identifier,
> > and receiving socket, but where the Request Authenticator
> > field is different from the one in the cached packet.
> 
> This got me thinking about the way that duplicates are
> detected and the cache entries managed. I re-read RFC 2865 and
> the draft under consideration, but I did not find clear
> guidance on this issue. Specifically, what exactly are the
> requirements for such purging? Do you check for validity of
> the packet before purging? Check the User-Password attribute
> which contains the message authentication?
> 
> It seems inappropriate to purge cache entries before the
> cryptographic message authentication has been verified. If you
> do it before verification, it means that an attacker could
> send a message that purges the cache, and if a real duplicate
> arrives after this the server will erroneously process
> the duplicate.
> 
> But maybe I'm missing something.
> 
> > In general, it is best for RADIUS clients to err on the side of
> > caution. On receiving an Access-Accept including an attribute of
> > unknown Type, a RADIUS client SHOULD assume that it is a potential
> > service definition, and treat it as an Access-Reject. Unknown VSAs
> > SHOULD be ignored by RADIUS clients.
> 
> This is a major change and can have significant
> negative effects to interoperability. Has this
> been discussed in the WG and have you found
> convincing arguments that taking on this rule
> will not lead to major problems?
> 
> Comment:
> > This suggests that the User-Name attribute may be ommitted if it is
> 
> s/ommitted/omitted/
> 
> > The CPE may also require a delegated prefix for its own use, if it is
> > decrementing the Time To Live (TTL) field of IP headers. In that
> > case, it should be delegated a prefix by the NAS via the Delegated-
> > IPv6-Prefix attribute. [RFC4818]. If the CPE is not decrementing
> > TTL, it does not require a delegated prefix.
> 
> Time To Live is called Hop Limit in IPv6, and since this is
> an IPv6 specific Section, perhaps this is the name that you
> should use.
>