Re: [radext] moving forward with draft-ietf-radext-coa-proxy

[Benjamin Kaduk <[e-mail]>]

Sorry for the delay here, it was kind of messy to sort out what needs to
happen, and there were holidays and an IETF meeting in there, too...

On Tue, Nov 13, 2018 at 07:14:09AM -0500, Alan DeKok wrote:
> On Nov 12, 2018, at 6:48 PM, Benjamin Kaduk <[e-mail]> wrote:
> > I also plan to change the target status to Informational (from Proposed
> > Standard); it is a little unfortunate to need to do so, but the IESG's
> > discussions convinced me that this is the sort of thing that the downref
> > policy was intended to avoid.
> 
>   OK.

Unfortunately, things are not this simple, and I think we need to keep the
PS status (and add some explanatory text for what is/isn't
standards-track).  More below.

> > There were a few things in the diff between the -05 and -07 that stuck out
> > to me, though, and might require further changes.
> > 
> > In Section 3.2,
> > 
> >   We also update Section 5 of [RFC5580] to permit CoA-Request and
> >   Disconnect-Request packets to contain zero or one instances of the
> >   Operator-Name attribute.
> > 
> > is not reflected in the Updates header and would require WG confirmation
> > and potentially re-running the IETF LC.
> > (Also, 5580 is Proposed Standard, so we'd have trouble doing this update
> > from an Informational document.)  It's somewhat unclear to me exactly what
> > is being Updated, too, so I'd appreciate a bit of explanation (here in the
> > email thread).
> 
>   RFC 5580 defined, Operator-Name, and Section 5 forbade Operator-Name from occurring in CoA-Request packets.
> 
>   So something needs to be updated in order to allow it.

It seems that 5580 is not quite as clear as it could have been here ("The
attributes defined in this document are not used in any messages other than
the ones listed in Figure 7." could be merely descriptive at the time of
writing, perhaps), but it does seem best to explicitly note the update of
behavior.  However, we can't just do that in a quick note in the main body
of the text; we need a proper "Updates: 5580" header, and to mention that
in the Abstract and Introduction.

For the Introduction, perhaps a penultimate paragraph:

    We also update the behavior of RFC 5580 to allow the Operator-Name
    attribute to be used in the CoA messages as described in this document.

Luckily, this document was LC'd for PS, so we have the option to publish as
PS, which is needed in order to Update 5580 (since 5580 is PS).  But that
leaves us in the problematic state that sparked Ben's balot position, with
this quite substantial normative dependency on a "less-mature" document.

In the vein of some text you proposed in Ben's ballot thread, I'd propose
that we add a disclaimer akin to:

    This document is a Proposed Standard in order to update the behavior of RFC
    5580, which is also a Proposed Standard.  This document relies heavily upon
    and also updates some behavior of RFC 5176, which is an Informational
    document; though the applicability statements in Section 1.1 of RFC 5176 do
    not apply to this document, this document does not change the status of RFC
    5176.

(after the previous paragraph I suggested to add).

> > Section 3.3 introduces a new normative requirement:
> > 
> >   Some Home Networks will not have permission to send CoA packets to
> >   the Visited Network.  The CoA server SHOULD therefore also validate
> >   the NAI contained in the User-Name attribute.  If the Home Network is
> >   not permitted to send CoA packets to this Visited Network, then the
> >   CoA server MUST return a NAK packet that contains an Error-Cause
> >   attribute having value 502 ("Request Not Routable").
> > 
> > Can the chairs confirm there is WG consensus for it?
> 
>   I'll leave that for the chairs.  My $0.02 is that it's useful to signal routing errors.  Tho this specific error number may or may not be appropriate.

(I don't think we heard back from the chairs, but I'm willing to go ahead
with this.)

> > In Section 3.4:
> > 
> >      Implementations supporting this attribute MUST be able to handle
> >      between one (1) and thirty-two (32) octets of data.
> >      Implementations creating an Operator-NAS-Identifier MUST NOT
> >      create attributes with more than sixty-four octets of data.  A
> >      thirty-two octet string should be more than sufficient for future
> >      uses.
> > 
> > The bump from 20 to 32 octest is fine, but now we have MUST be able to
> > handle 32 and MUST NOT generate more than 64, which are different numbers.
> > (In the -05 the numbers were both 20.)  Where did the 64 come from?
> 
>   IIRC, Adam Roaches discussion of creating tokens using modern ciphers.  64 bytes would be needed for that to occur.
> 
> > Section 4.2 introduces a new normative requirement:
> > 
> >   The Visited Network MUST also ensure that the CoA packet sent to the
> >   NAS contains one of the following attributes: NAS-IP-Address, NAS-
> >   IPv6-Address, or NAS-Identifier.  This step is the inverse of the
> >   removal required above in Section 3.4.
> > 
> > First off, is this "at least one" or "exactly one"?
> 
>   At least one.
> 
> > And the same question of WG consensus applies.
> 
>   WG consensus is nice, but that text is required in order for this specification to be compatible with RFC 5176, and with NAS implementations.  Failure to include *any* of those attributes in a CoA packet means that the NAS will reject the packet entirely.

That's fair.


One other comment on the changes in the -07:

Section 3.4

    If a packet contains more than one Operator-NAS-Identifier,
    implementations MUST ignore the second and subsequent attributes, and
    treat them as "invalid attributes", as discussed in Section 2.8 of
    [RFC6929].

I think the "and treat them as" is misleading; this is a "by" sort of
relationship, for "as is proper for 'invalid attributes'".  The present
text seems to essentially be saying the same thing in two different ways,
which may cause people to wonder if the two are subtly in conflict.

Please go ahead and publish an -08 with the formal Updates header,
Abstract/Introduction changes, and hopefully a change here in 3.4 as well,
when you get a chance.

Thanks,

Ben