Re: [radext] Proposed new charter text

[Peter Deacon <[e-mail]>]

On Mon, 23 Mar 2015, Alan DeKok wrote:

To clear up any confusion I will go back and expand on my previous 
question.


Roaming network consisting of a number of participating organizations all 
sharing access.

'Home' system, roaming network (RoamA,B,C) and 'Visit' systems all 
controlled by separate companies.  Each use different RADIUS systems.

The word STATE refers to Operator-NAS-Identifier or something like it.

+------+    +-------+   +-------+   +-------+   +-------+   +----------+
| Home | -  | RoamA | - | RoamB | - | RoamC | - | Visit | - | VisitNAS |
+------+    +-------+   +-------+   +-------+   +-------+   +----------+

Scenario A:

'Home' user logs on to 'VisitNAS' as user@home using realm proxy, 
Access-Request proxied to home server and user admitted to the network.

At a later time home server decides to send a DM request to disconnect 
user@home.  It transmits a request to RoamA containing roughly:

Operator-Name="1visit"
Operator-NAS-Identifier=010100100101010
Acct-Session-Id="dontchawishwewerealwaysunique"
NAS-Port-Id="Astern123"
NAS-IP-Address=10.1.1.1

This request does NOT contain User-Name.

Issues:

- 'RoamA' can either use STATE included in the request to verify 
Acct-Session-Id is related to a session belonging to 'Home' before it 
enters the roaming network or it can simply punt responsibility up thru 
the proxy chain.

- If 'RoamA' decides to punt to 'RoamB' or 'RoamC' the same problem of 
using STATE to verify Acct-Session-Id is related is encountered. Also 
since there is no standard way of communicating 'Home' originated the 
request roaming network will need to manage some OOB or proprietary method 
of facilitating origination information so that it can render a coherent 
judgment.

- If RoamA-C all fail to verify Acct-Session-Id the request responsibility 
is punted to 'Visit'

- If 'Visit' trusts the roaming network and STATE is never used to verify 
relationship of DM to 'Home' the effective outcome any 'Home' network is 
able to disconnect any of their competitors users with only knowledge of 
session identifying attributes.

- If 'Visit' is more cautious and can get trusted originating 'Home' 
information from 'Roam' and STATE this could be used to verify the 
relationship itself.


Scenario B:

'Home' user logs on to 'VisitNAS' as user using policy based proxy on a 
VSA.  Access-Request proxied to home server and user admitted to the 
network.

At a later time home server decides to send a DM request to disconnect 
user.  It transmits a request to RoamA containing roughly:

Operator-Name="1visit"
Operator-NAS-Identifier=010100100101010
User-Name="user"
Acct-Session-Id="dontchawishwewerealwaysunique"
NAS-Port-Id="Astern123"
NAS-IP-Address=10.1.1.1

This request does NOT contain VSA used for policy based proxy.

Issues are identical to scenario A.

STATE is helpful in addressing situations where there is a mismatch 
between session identification and means of proxy.

>  The draft implements CoA proxying based on Operator-Name.  This is 
> sufficient for all proxies to get the packet to the visited domain, 
> independent of anything else in the packet.  The Operator-Name *is* 
> “sufficient information” for all proxies.  The proxies need no other 
> information, and can safely ignore every single other attribute in the 
> packet.

No unfortunately this does not work across administrative domains as 
operators are able to affect operation of unrelated sessions belonging to 
other operators without the checks in place.  While all parties explicitly 
trust roaming infrastructure they may not necessarily trust each other.

regards,
Peter