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

[Alan DeKok <[e-mail]>]

On Aug 6, 2025, at 6:13 PM, Donald Eastlake <[e-mail]> wrote:
> 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.

  Done.

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

   Done.

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

  I've reworded the introduction to make it clearer.

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

  That's a quote from another specification, so I'll leave it alone, and make it clearer that it's a quote.

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

  Done.

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

  Done.

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

  Fixed.

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

  Fixed.

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

  OK.