Re: [radext] Proposed new charter text

[Alan DeKok <[e-mail]>]

On Apr 30, 2015, at 3:34 AM, Stefan Winter <[e-mail]> wrote:
> 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.

  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.

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

  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. 

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

  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.