Subject: Re: [radext] Proposed new charter text

From: Stefan Winter <[email-masked]>
Date: Thu, 30 Apr 2015 09:34:58 +0200

Hello,

we still don't seem to have agreement on the updated charter text.
Luckily, all the discussions revolved around one single work item, CoA
proxying.

Some folks want the spec to tackle RFC5176's "Authorization Issues"
security consideration, and there are ideas around this floating on the
mailing list. Others just want to solve the routing issue, and leave the
security issues for another document.

From the discussions on the list so far, I'm not seeing a clear
direction, but I also don't want this to hold up the recharter.

So, may I suggest a more general text; and that we leave the exact shape
of the document to the WG process once the document is in-charter and
the individual draft adopted?

My suggestion would be:

> - CoA proxying.  RFC 5176 permits proxying of CoA and Disconnect
> messages, but makes no provisions for how that is done in a roaming
> environment.  This work item will provide descriptions of how to use the
> Operator-Name attribute in a roaming environment to proxy CoA packets. > Depending on whether the document can tackle the security issues
> around CoA as enumerated in RFC5176, the document will either be
> Informational or Standards-Track.

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 30 Apr 2015 07:40:19 -0400

> security issues for another document.

  The "Authorization Issues" section of 5176 is missing authorization issues for proxies.  The CoA proxying document has to have text addressing this issue.

  The consensus on the list was that there were two ways of addressing this issue:

a) the "reverse path forwarding" check from 5176

  and/or

b) requiring that Operator-NAS-Identifier be cryptographically secure, and impossible to forge.

  The only counter-point that I recall was that these solutions would be insufficient, for unspecified reasons.

> direction, but I also don't want this to hold up the recharter.

  We had multiple people agreeing that the above approach was sufficient for the CoA proxy document.

  We need this document to be done soon.  There is WG consensus on it, and all we need is an updated draft which can be submitted for publication. 

> the individual draft adopted?

  I would be opposed to this.  There is a clear problem statement: CoA proxying is unspecified.  There is a clear solution: Operator-Realm and Operator-NAS-Identifier.  There is consensus that the approach works, and is secure.  There is an implementation of CoA proxying with Operator-Name.  This solution is deployed in running environments.  The solution has been discussed for years in RADEXT.  There is a draft (which needs updates to reflect the latest WG discussion).

  The counter-point is to extend the document to solve an unspecified problem, with no solution, no draft, no implementation, etc.  Well, that's what new documents are for.

  We have WG consensus on a path for the CoA proxy document.  I welcome additional documents to solve other, unrelated, problems.   Problems which *everyone agrees* are unrelated to the CoA proxying issue.

  We can update 5176 with multiple documents.  But I find it disturbing that progress on one document can be shut down because of *additional*, unspecified work.  Adding random things to specification documents is a process best left for politics.  Last-minute "riders" are well-known there, and are discouraged in the IETF.

  We do not need WG unanimity.   We have broad consensus for the existing document, I believe we should go with that.

  Alan DeKok.