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

[Donald Eastlake <[e-mail]>]

Hi Alan,

I am satisfied with your changes and consider my comments resolved.

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

On Sun, Aug 17, 2025 at 5:38 PM Alan DeKok <[e-mail]> wrote:
>
> 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.