[radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-radext-coa-proxy-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to thank the author and all other involved parties for the work that
has gone into making CoA transactions work across multiple domains. I have a
couple of DISCUSS points that I think need to be cleared up.

---------------------------------------------------------------------------

This is a concern with the general mechanism, and might be due to a
misunderstanding on my part (which I hope you can clear up); but if I'm not
wrong, then I'm concerned that the mechanism as described can introduce RADIUS
message routing loops in some very common deployment scenarios.

Consider a setup involving three networks: a Visited network (with its NAS and
a Radius server), a Clearinghouse network (with one or more proxies), and a
Home network (with a border proxy and a Home Server). Both the Home and Visited
network also have federated networks that they communicate directly with without
traversing the Clearinghouse network.

The Clearinghouse determines the destination of any request message by looking
at the realm portion of the NAI present in the "User-Name" attribute, which I
believe is pretty common routing logic in these kinds of cases.

Now, consider what happens when the Home network updates to use this mechanism
(in order to better work with their federated partners), and the Visited network
also updates to use this mechanism (for the same reason), but the Clearinghouse
is not yet updated. I'll try to step through section 5 with this scenario:

1) The NAS in the Visited network sends an Access-Request packet to the
   Visited Radius server. The visited RADIUS server will see that the
   user is roaming, and will add an Operator-Name attribute, with value
   "1" followed by it's own realm name.  e.g. "1example.com".

2) The visited RADIUS server will then proxy the authentication request
   to the Clearinghouse network, which uses the NAI in the User-Name to forward
   it to the Home network.

3) The Home Server records the Operator-Name along with other information
   about the users session

4) When the Home Server determines that a user should be disconnected,
   it looks up the Operator-Name, along with other user session identifiers as
   described in [RFC5176].

5) The Home Server sends the Disconnect-Request to the Home domain's border
   proxy.

6) The Home domain's border proxy looks up the Operator-Name in the
   Disconnect-Request message, determines that it is an operator that it is
   not federated with, and consequently sends the Disconnect-Request to the
   Clearinghouse.

7) The Clearinghouse receives the Disconnect-Request message. Since it has not
   yet been updated to handle the Operator-Name attribute as described in this
   document, it follows its normal logic of routing according to the NAI in the
   User-Name attribute.

8) Go to 6

---------------------------------------------------------------------------

§4.2:

>  The value SHOULD be cryptographically strong, and SHOULD be
>  verifiable by the Visited Network, without requiring it to track in a
>  database every individual value of Operator-NAS-identifier which was
>  issued.

I don't think this is really phrased in a way that means what you want to say.
If I had to guess, you mean to say that the value must be encrypted, and that it
must be integrity-protected. If integrity protection is important, then you also
need to consider techniques to avoid replay of previously-seen tokens (e.g., the
integrity protection needs to be over not just the Operator-NAS-Identifier,
but also over some portion of the session that prevents its replay). Most
notably, this desire for encryption and integrity protection is almost
certainly at odds with the assertion (in §3.3) that "A twenty octet string is
more than sufficient to individually address all of the NASes on the planet."
For example, the naïve approach of appending a SHA-256 hash to the end of an
encrypted, salted index into a table of NAS devices would require over 32 bytes
at its absolute minimum. So, if integrity protection is something that any
operator might ever want, you need to revisit the 20-byte limit.

>  Exactly how this requirement is implemented is outside of the scope
>  of this document.

That's fair, but I think you need a proof-of-concept example of how it could be
done, so that you find any additional corner cases beyond the one I've
identified above.

I think these aspects of this attribute need a lot more treatment in Section 6.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

All of my comments are editorial nits.

---------------------------------------------------------------------------

ID Nits reports:

  ** The abstract seems to contain references ([RFC7542]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question (e.g., "RFC 7542").

---------------------------------------------------------------------------

§2.1:

>  Other methods are
>  possible, but we restrict ourselves to this usage, as it is the most
>  common one.

This needs to be clear whether the *description* is restricted to NAI-based
routing, or whether the *mechanism* is. I suspect it's the former; in any case,
please add text.

---------------------------------------------------------------------------

§2.1:

>  Once
>  a response has been received by the proxy, it can discard all
>  information about the request packet.

Nit: "Once a response has been sent by the proxy..."
                               ^^^^

---------------------------------------------------------------------------

§3.2:

>  We therefore need a way to identifier a NAS in the Visited Network,

Nit: "...to identify a NAS..."

---------------------------------------------------------------------------

§3.3:

>  We suggest that the contents of the NAS-Identifier be the Realm name
>  of the Visited Network.  That is, for everyone outside of the Visited
>  Network, there is only one NAS: the Visited Network itself.  For the
>  Visited Network, the identity of the NAS is private information,
>  which is opaque to everyone else.

Please be clear that this recommendation is for the (existing) NAS-Identifier
attribute rather than the (new) Operator-NAS-Identifier attribute.

---------------------------------------------------------------------------

§3.3:

>     This token MUST allow the Visited Network to direct the packet to
>     the NAS for the users session.

Nit: "...user's session..."

---------------------------------------------------------------------------

§4.2:

>  CoA server (i.e. NAS).  This requirement is phrase more generically
>  below, in Section 4.3.2.

Nit: "...phrased..."

---------------------------------------------------------------------------

§4.3.1:

>  it SHOULD return a
>  CoA-NAK or Disconnect-NAK packet, that contains an Error-Cause
>  attribute having value 503 ("Session Context Not Found").

Nit: "...packet that contains..."