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

[Alan DeKok <[e-mail]>]

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.

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

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

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

  Alan DeKok.