FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis

["David B. Nelson" <d.b.nelson@comcast.net>]

IESG DISCUSS and COMMENT.

> -----Original Message-----
> From: Tim Polk [mailto:tim.polk@nist.gov]
> Sent: Wednesday, October 17, 2007 4:23 PM
> To: iesg@ietf.org
> Cc: radext-chairs@tools.ietf.org
> Subject: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
> 
> Discuss:
> This is a discuss discuss in two parts.  To be clear, it is not blocking;
> I will clear immediately
> after the document comes up on the agenda.
> 
> (1) Paul Hoffman has suggested that standards track would be more
> appropriate than
> informational for this specification.  I understand this would necessitate
> an issue-specific
> IETF Last Call, but I tend to agree with Paul.  Is there another reason
> that I am missing
> to stay at informational?
> 
> (2) The security considerations section on Impersonation (section 6.2)
> seem to apply to
> implementations of RFC 2865, rather than this specification:
> 
>    To address these vulnerabilities RADIUS proxies one hop from the NAS
>    SHOULD check whether NAS identification attributes (see Section 3)
>    match the packet source address.  Where one or more attributes do not
> 
> As far as I can tell, the RADIUS proxy that SHOULD perform this check may
> be entirely
> unaware of this specification.  Is that correct?  If so, publishing the
> security considerations
> here seems unlikely to have much impact.  (I checked RFC 2685, and these
> considerations
> do not seem to be present.)
> 
> This is a carryover from RFC 3567, so there is no value in blocking the
> progression
> of this specification.  (Besides, the following paragraph notes that this
> check cannot always
> be performed.)  I would like to hear other ADs thoughts on handling this
> sort of situation
> in the future, though.
> 
> Comment:
> The figures in sections 2.1 and 2.2 use Disconnect-Response and CoA-
> Response as shorthand
> for "Disconnect-ACK or Disconnect-NAK" and "CoA-ACK or CoA-NAK"
> respectively.  These
> terms are never defined, and in fact are never used again.  I can't claim
> it was too hard to figure
> out, but it might be better if the meaning was explicitly stated.
> 
> Perhaps the terms could be introduced in the text following the figures
> and implicitly defined
> in a parenthetical, in the same way that "Response packet" was introduced
> in section 2.3:
> 
>            The  Authenticator field in a Response Packet (e.g. Disconnect-
> ACK,
>             Disconnect-NAK, CoA-ACK, or CoA-NAK).




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