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

[Alan DeKok <[e-mail]>]

On Aug 13, 2018, at 10:06 PM, Adam Roach <[e-mail]> wrote:
> 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.

  I don't think so, for the simple reason that clearing houses don't accept CoA packets right now.

  There are other reasons.

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

  Note that 6 depends on 5.  i.e. the Home domain border proxy should *not* accept random packets, even from trusted parties, and proxy them to random destinations.  Doing so would be a violation of a host of security issues.

  The Home domain border proxy MUST implement the following rules:

- CoA packets from inside the network (i.e. trusted packets) can be proxied externally

- CoA packets from outside the network (i.e. less trusted packets) MUST contain the realm of the Home domain.  All other packets MUST be NAKd.

  These rules are already applied for Access-Request and Accounting-Request packets.

> 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 discards the packet as unknown.  At the *network* layer, because nothing is even listening on the CoA port (3759).

  If the clearing house receives the CoA packet on one of the normal RADIUS ports (1812 or 1813), it also discards the packet, as those ports are only supposed to be for Access-Request and Accounting-Request packets.

  If the clearing house implements RADIUS over TCP/TLS, then it's permitted to accept any packet (CoA or otherwise) on that port.  However... it must also have processing rules for those packets in place.  And since there is currently no way to proxy CoA packets, it will discard the packet.

> it follows its normal logic of routing according to the NAI in the
>   User-Name attribute.

  It should not follow the normal logic of routing according to the NAI.  For one, clearing houses currently only deal with Access-Request and Accounting-Request packets.  Any *other* packet they receive is silently discarded.

  So in order for a loop to exist, multiple things have to go wrong:

- the clearing house has to accept CoA packets (none do right now)

- the clearing house has to be configured to use the NAI for forwarding CoA packets (no RADIUS server does this)

- the home domain proxy has to accept external packets for third-party domains, and forward them (all these systems have rules in place now to prevent this).

  I'll see if I can clarify this issue in the document.

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

  Why is replay an issue?  The point of obfuscating the information is to hide internal / private information about the network.  e.g. private IP of the NAS.

  If a home server replays a previously-seen token, then one of two things will happen:

- the packet will go to the NAS which hosts the user session, and will be processed normally

- the packet will go to a different NAS, and will be NAKd

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

  32 bytes is fine.  I'll update that.

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

  Fair enough.

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

  I'll add some text.

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

  Fixed.

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

  This spec documents NAI-based CoA proxying.  Other methods can be used, but aren't discussed here.

  The mechanism for discovering next hop is specific to NAI-based proxying.

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

  Fixed.

> ---------------------------------------------------------------------------
> 
> §3.2:
> 
>> We therefore need a way to identifier a NAS in the Visited Network,
> 
> Nit: "...to identify a NAS..."

  Fixed.

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

  I'll update the text.

> ---------------------------------------------------------------------------
> 
> §3.3:
> 
>>    This token MUST allow the Visited Network to direct the packet to
>>    the NAS for the users session.
> 
> Nit: "...user's session..."

  Fixed.

> ---------------------------------------------------------------------------
> 
> §4.2:
> 
>> CoA server (i.e. NAS).  This requirement is phrase more generically
>> below, in Section 4.3.2.
> 
> Nit: "...phrased..."

  Fixed.

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

  Fixed.

  Alan DeKok.