Re: [radext] Proposed new charter text

[Alan DeKok <[e-mail]>]

On Mar 22, 2015, at 8:44 PM, Peter Deacon <[e-mail]> wrote:
> My understanding this would be a new item rather than change to an existing WG work item currently on the charter. Stefan solicited feedback and I gave it.  The CoA draft as written would certainly continue to fall under my proposed change.  I am aware of nothing lost by proposed text.

  Deleting text is pretty much the dictionary definition of “losing something”.

> Concern regards intent of Operator-NAS-Identifier.
> 
> Dynamic authorization allows multiple sessions to be influenced with single requests.

  Maybe I’m misunderstanding something, but no.  A CoA or Disconnect-Request packet addresses *one* session with *one* request.  Nothing in RFC 5176 suggests otherwise.

>  Sufficient / required session identifying attributes varies between NASes and sometimes across access technologies within the same NAS.  There are no further constraints expressed in draft on both required / acceptable session identifying attributes and method of initial authentication proxy (realm based or other policy based)

  Because the draft doesn’t address session identification.  It just addresses proxying.  RFC 5176 addresses session identification.  Badly, IMHO, but that’s the WG consensus.  No one could agree on a solution, so it was left pretty much the same as RFC 3576.

  i.e. session identification is explicitly outside of the scope of this document.

> So I'll throw the question back at you.. how the heck is this supposed to work?

  The document explains it’s assumptions and operating model in great detail.  If you don’t understand it, ask a *specific* question about a part you don’t understand.  I see no reason to re-post the document here to answer your question.

> When the upstream proxy in a forwarding chain gets the request how is it supposed to know whether it is safe to pass up the chain without either keeping a lot of state or verifying some kind of secure stateless signature/token conveyed within Operator-NAS-Identifier?

  A proxy isn’t supposed to know if a packet is “safe” to proxy.  It just proxies the packet.  That’s how RADIUS works.

> Section 3.1 of the draft makes it clear Operator-NAS-Identifier is not just a fungible label for a generic state attribute with the "20 octets" language and associated removal of NAS-Identifying attributes.

  Exactly.  It’s NOT a “generic state attribute”.   It’s not intended to be one.   All of the text explains in excruciating detail what it is, what it means, and how it’s used.  I fail to see how there is any potential for confusion.

> I see two opportunities:
> 
> Get to working by constraining both means of authentication proxy and session identifying attributes.

  Any constraint on proxying is out of scope of this work item.  Any change to session identification attributes is out of scope of this work item.

> Or you can get there by keeping state at which point the language of Operator-NAS-Identifier in my judgment is insufficient.  While it may well resolve any ambiguities as to "where" the request is going it does so while missing the larger problem.

  I suggest writing a document which addresses that larger problem.  Don’t try to extend this work item.

>> The idea has been presented at meetings going back 3-4 years, IIRC.
>> The only discussion of this topic has been supportive of this approach taken here.
> 
> As earlier I also support the general "idea".

  Which is nice.

  If you want to write a document which describes how proxies can maintain per-user session state, and filter proxied CoA packets based on that information… go right ahead.  But that subject is out of scope for this document.

  Your charter changes would allow this document to include text on session identification, which is probably why you’re suggesting them.  The time to fix session identification with CoA was with RFC 5176.  That ship has sailed, the subject is closed.

  Everything you’ve said convinces me that the proposed charter text should stay the same.  RFC 5176 allows CoA packets to be proxied, but doesn’t specify how that’s done.  This document specifies how CoA packets are proxied in a roaming environment.  That’s it, that’s all.

  The document doesn’t address session identification attributes.  It doesn’t address generic state attributes.  It doesn’t address how proxies maintain per-user session state.  It doesn’t address how proxies “filter” packets they receive.  It doesn’t address all kinds of topics.  That’s fine.  Other topics are for other documents.

  Alan DeKok.