[secdir] secdir review of draft-ietf-radext-bigger-packets

[Paul Wouters <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area directors. 
Document editors and WG chairs should treat these comments just like any other 
last call comments.

The draft is Ready with nits

This document introduces new attributes to Radius to signal handling
radius packets larger than 4096 octets. This is possible when using TCP as
a transport mechanism which is already defined in another RFC. The
document sort of suggests using TLS to protect against any possible
attacks on TCP. I think it could be more explicit about this.

I'm a little confused about when a size refers to a RADIUS packet size,
and when it refers to a TCP packet size. eg:

    An implementation of [RFC6613] will silently discard any packet
    larger than 4096 octets and will close the TCP connection.

But TCP is a stream, so it could be using multiple packets smaller
than 4096 that would transport a radius packet that is larger than
4096 bytes. (I assume in the beginning it couldn't since everything
was limited by single UDP packets?)

What does "maximum size of a response" refer to? TCP packet size or
radius packet size? I think it would make the document clearer if the
authors would go over all mentions of "packet" and "size" and
specifically write it out as radius packet size or TCP packet size.

I'm also confused by:

 	Other attributes or configuration MAY be used as an indicator that large responses are
 	likely to be acceptable.

Are those attributes defined in another RFC? If not, this document
should not hand-wave about non-standard attributes.

The security considerations state:

 	These attacks can be entirely mitigated by using TLS.  If these attacks are
 	acceptable, then this specification can be used over TCP.

This text is confusing. I think it means to say "These attacks can be
avoided by using TLS". Because this whole document is about TCP, so
there is no case where "this specification" can be used "not over TCP".

nits:

cloing -> closing?

by including the attribute the client indicates -> By including the attribute, the client indicates

an next hop -> a next hop


Paul