[secdir] SECDIR review of draft-ietf-radext-reverse-coa

[Donald Eastlake <[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 summary of the review is Almost Ready

This is a simple draft improving the standardization of how to send
"reverse path" RADIUS CoA and Disconnect packets from a RADIUS server,
possibly via proxies, to a NAS.

I note that it is very late in the process and this document is in
IESG Consideration. I have not looked at any of the AD reviews so this
may be a fresh review.

Security
--------

The Security Considerations Section 8 just says (in different words)
that the document improves security by standardizing reverse paths for
CoA-Request and Disconnect-Request packets. I would add a little bit
about why, if there is a need to disconnect or change authentication,
it can be a security problem if you cannot do that. Also, Section 4
just says that in various cases of misconfiguration CoA (which is
defined to also include Disconnect in this document) packets will not
flow and says this causes no further issues. I suggest "there will be
no other issues with this misconfiguration" -> "which may reduce
security (see Section 8)".

Nits / trivial issues
---------------------

Section 1, 2nd and 3rd paragraphs: Perhaps these should be merged or
something as on initial reading it was not clear to me that the
"Section 3.4" in the 3rd paragraph was that section in RFC 6614 which
is referenced in the 2nd paragraph.

Section 1, 3rd paragraph: Should "which types of packets are supported
on a server" be "which types of packets it supports"?

Section 3: "a configuration and signalling," -> "a configuration and
signalling method,"

Section 3 says there are two additions. These are then discussed in
Section 4 and 5 but there is no tie between those sections and Section
3. Suggest adding at the end of Section 3: "These additions are
discussed in Sections 4 and 5 respectively."

Section 5.1, 2nd paragraph: "have the choice more than one" -> "have a
choice of more than one"

Section 5.2, 2nd paragraph: the server's connection choice is not
unconstrained. "chooses one connection" -> "chooses one of these
connections"

Section 6.3, I didn't review Section 6 very closely but it seems odd
that in Section 6.3 there is a raw direct reference rather than
indirecting through the Informational References section. But, since
Section 6 is going away, it does not matter much.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]