Re: [radext] Extended IDs

[Alan DeKok <[e-mail]>]

> On Dec 11, 2017, at 8:08 PM, Brian Weis (bew) <[e-mail]> wrote:
> 
> I’ve read through the latest versions of both drafts, and I do prefer the approach taken in draft-chen-radext-identifier-attr.
> 
> From a protocol perspective, the two approaches do not seem very far apart to me. They both seem to do the following. (1) Define a new per-connection attribute as part of a Status-Server message. (2) Specify that a client chooses when to use a larger identifier. (3) Specify that when the server recognizes the “new extended field”, then it is obligated to return the original values of both identity field and the “new extended field”. (4) The server need not have any knowledge as to how the “new extended field” is determined.  (5) If the server does not recognize the new attribute, it ignores it. So in neither case do that the mechanism seem to unduly modify RADIUS.

  The differences are that the draft-chen proposal effectively modifies the RADIUS header, and that it has the opportunity for "leakage" of extended IDs in the case of error or misconfiguration.

  My draft has none of these issues.

> It seems to me that the real difference comes down to how the “new extended field” is carried — either in the new per-connection attribute, or by overloading the Request Identifier. I appreciate the arguments in draft-dekok that indicate that there should not be a problem with overloading, but because overloading protocol fields can carry unexpected risks

  Risks like... ?

  I must admit to being a little surprised at the dislike of "overloading" the Request Authenticator field.  As Peter Deacon pointed out, it's already "overloaded" for many, many, other things.

  Given the existing definition of the Request Authenticator field, it is *impossible* at this time to change how it's calculated.  Similarly, it's impossible to change the meaning of the field for packet signatures.  And, it's impossible to change the usage of the field within other attributes.

  So we're left with a field that we cannot change, but we can look at.  What is the risk in looking at it?  What is the risk in echoing it verbatim in a response packet?

  I understand that saying "we add a 32-bit ID" is conceptually simpler.  But I still don't get where any "risk" or concern with "overloading" of the field comes from.  Some additional explanation would be useful here.

> my preference is to adopt the explicit approach in draft-chen. With the same thought process I’m a little worried about defining "behavior previously left open to implementation interpretation” (as mentioned in Section 2.1 of draft-dekok). I cannot disagree that it “should" be OK, but the lack of certainly does add some risk.

  How?

  The draft goes through exhaustive enumeration of the possibilities.  It shows that the proposal is no worse than existing RADIUS, and in some cases is substantially better.

> However, I also believe that there is a lot of good background and explanatory text in draft-dekok that is valuable and if the working group takes draft-chen as the base then some of this would be valuable to bring that into the draft. This might address some of the concerns that draft-chen is under-specified.

  I agree.

  I think a large part of the concern here is due to the background and explanatory text in my document.  i.e. a proposal which describes the risks seems risky.   A proposal which ignores the risks seems less risky.

  But I would still like to understand (a) what the risks are here, and (b) why there's a concern with "overloading" a field that cannot be changed, and is already used for many things.

  Alan DeKok.