Re: [radext] Proposed new charter text

[Alan DeKok <[e-mail]>]

On Mar 23, 2015, at 1:14 PM, Peter Deacon <[e-mail]> wrote:
> To clear up any confusion I will go back and expand on my previous question.

  That helps a lot, thanks.

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

  The RADIUS answer is that RoamA simply proxies the request.  It does no verification or filtering of proxied packets.

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

  Yes.  Exactly.  The proxies just proxy the packets.  Nothing more

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

  Yes.  Exactly.

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

  Unfortunately, yes.  That’s an issue with 5176.  And with this document.  I don’t think fixing roaming is in scope for it.

  The recommended way to address this issue is to use Acct-Session-Id, and User-Name in the CoA packets.  That information is “private”, and random home servers can’t guess it.  Proxies can still watch the traffic and forge disconnects… but they’re trusted.  That’s the nature of the trust relationship they have with the other parties.

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

  There is little or nothing to be gained by having the proxies (or visited network) maintain any kind of session state.  Doing so would be costly, and would only make it more difficult for malicious home servers to disconnect their competitors users.  All of the proxies could still disconnect any users, because they’re proxies, and have all of the state information.

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

  It doesn’t need to.  It contains the Operator-Name, which is sufficient for the CoA packets to be proxied to the visited network.

> Issues are identical to scenario A.

  Yes.

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

  I’m not sure I agree.

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

  i.e. what you’re saying is that there is a requirement for home server A to NOT be allowed to disconnect users for home server B in a visited network.  That is a *new* requirement, which doesn’t negate my comments above.

  I want to solve one problem at a time.  Operator-Name and Operator-NAS-Identifier are sufficient to get the packet to the visited NAS.   Your earlier comments seemed to say that they were NOT sufficient, which is what was unclear.

  To solve the NEW problem of forged disconnects, we need a NEW solution.  i.e. rely on Acct-Session-Id, which is hard to guess.  I think that would be sufficient for most intents and purposes.

  If you have *specific* suggestions for a solution, I’d be happy to hear them.  But please explain it clearly.  Most of the time your posts are full of unstated assumptions, which makes it nearly impossible to understand them.

  Alan DeKok.