Subject: [radext] Extended IDs

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Apr 2017 15:54:48 -0400

I've been having offline conversations with the authors of the draft-chen-radext-extended-header.  My comments on the draft and process are:

* there's no need to add provisions for extending the Code field.  Having that in this document confuses people, and makes them less likely to support the other parts of it

* The "status" field should similarly be removed from the document.  Instead, just the presence of the attribute in a reply should be good enough.

* using the 4-octet identifier *instead of* the normal ID means the protocol is being changed, this cannot be done.

* the changes MUST interoperate with existing RADIUS clients and servers that don't implement this.

* i.e. the new systems MUST be able to either detect that the old systems don't support the extended ID, *or* the old systems MUST be able to work as before when sent "new" packets.

   It looks like it's hard to have a solution the problem which satisfies all of the above.

   So I was thinking...

  What if the 8-bit IDs were *temporal*, in addition to tracking src/dst ip/port?  A simple approach would be put a "ID space timestamp" into every packet.  You'd want to send more than 256 packets per second, so that's not good enough.

  What about using a simple sequence number instead?

  i.e. a RADIUS client sends 256 packets, each with sequence number 0.  The server is busy, and doesn't respond to them all.

  The client would like to send a second packet of (say) ID 0.  It notices that there's still a packet outstanding for ID 0, and increments the sequence number.  It can then send a packet containing { ID 0, SEQ 1 }.  The server will see this packet, and treat it differently from one which contains { ID 0, SEQ 0 }.

  The sequence number should also be local to each src/dst ip/port connection.

   I don't think there are technical reasons why this wouldn't work. It may also be acceptable to the wider IETF as a minor variation to RADIUS.  (He said naively...)

   Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Tue, 18 Apr 2017 15:47:24 -0700

Hi, Alan:

Thanks for you comments.  Please see my replies/comments inline.

On 4/18/17 12:54 PM, Alan DeKok wrote:
>   I've been having offline conversations with the authors of the
>   draft-chen-radext-extended-header. My comments on the draft and process are:
>
> * there's no need to add provisions for extending the Code field.  Having that
>   in this document confuses people, and makes them less likely to support the
>   other parts of it

Out of 255 numbers for the Packet Type Codes, 52 are currently allocated.  Given
the popularity of RAIDUS, this number space may run out in the future.

Although the Code field does not have to be enlarged together with the Identifier
field, it just makes sense to do them together so that we go through the changes
once and be done with it.  There is little additional cost (in terms of development,
memory and transmission) to cover the Code field, and its usage is optional until
needed.

>
> * The "status" field should similarly be removed from the document.  Instead,
>   just the presence of the attribute in a reply should be good enough.

Without the "status" field, we are afraid that some implementation may just send
back the unrecognized attribute.  The field would certainly help make it more
explicit and deterministic about whether the feature is supported by a device.

>   is being changed, this cannot be done.

I am not sure what you mean by the statement "the protocol is being changed, 
this cannot be done".

You seem to mean that "such change is not allowed"?  If that is correct, then I
am wondering what basis you have (other than personal opinion) for such a position.
If there exists some official IETF rules that I am not aware of, please let me know.

I have been involved in IETF (mostly in the routing area) for more than 20 years.
AFAIK, any extension to an existing protocol is a change to the protocol, and such
changes have been made and continue to be made all the time, and some by you in
this radext working group :-) 

The existence of the the IETF and its Working Groups is to make protocol extensions
and changes.

> * the changes MUST interoperate with existing RADIUS clients and servers that

Yes, absolutely.  That is covered extensively in the draft using the "Status-Server"
message for discovery of the feature before the larger Identifier field is carried in
the attribute.  Please let us know if you see any holes with backward compatibility.

>
> * i.e. the new systems MUST be able to either detect that the old systems don't
>   support the extended ID, *or* the old systems MUST be able to work as before when
>   sent "new" packets.

That’s precisely the reason that the "Status-Server" message is used in the draft
for discovery of the feature between a client and a server.

>   What if the 8-bit IDs were *temporal*, in addition to tracking src/dst ip/port?
>   A simple approach would be put a "ID space timestamp" into every packet.  You'd
>   want to send more than 256 packets per second, so that's not good enough.
>
>   i.e. a RADIUS client sends 256 packets, each with sequence number 0.  The server
>   is busy, and doesn't respond to them all.
>
>   The client would like to send a second packet of (say) ID 0.  It notices that
>   here's still a packet outstanding for ID 0, and increments the sequence number.
>   It can then send a packet containing { ID 0, SEQ 1 }.  The server will see this
>   packet, and treat it differently from one which contains { ID 0, SEQ 0 }.
>

AFAIK, the RADIUS standard does not specify how the IDs are allocated, and that is
completely left to the implementation and as a local matter on the sender.

IMO deviation from such well-established practice will be challenging for backward
compatibility and deployment.

In addition, following the current RADIUS practice it remains an implementation
decision how this new 4 bytes "ID" field is allocated.  However, I do not see any
value for combining this new 4-byte "ID" field with the existing one-byte "ID"
field and using them both.

Thanks again, -- Enke

>    I don't think there are technical reasons why this wouldn't work. It may also be
>    acceptable to the wider IETF as a minor variation to RADIUS.  (He said naively...)
>
>    Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Apr 2017 20:16:34 -0400

> the popularity of RAIDUS, this number space may run out in the future.

  That's called "Diameter".  :(

> memory and transmission) to cover the Code field, and its usage is optional until

  The issue is solving one problem at a time.  There is no *current* need to extend the Code space.  Therefore, there shouldn't be a proposal to extend it.

> explicit and deterministic about whether the feature is supported by a device.

  I think it's safe to say that servers don't "echo" back attributes.

  If you need an explicit ACK, create one.  Don't overload the contents of an attribute.  See RFC 6929 Section 6.3 for guidelines on using Complex Data Types.

> If there exists some official IETF rules that I am not aware of, please let me know.

  I mean that modifying RADIUS in minor ways is probably OK.  Changing the base RADIUS protocol is not.

  Making clients and servers change the meaning and interpretation of the ID field is changing RADIUS.  I don't think you will get consensus from RADEXT, much less the IESG for this proposal.

> this radext working group :-) 

  Sure.  Except that *major* changes to RADIUS are called "Diameter". :(

> compatibility and deployment.

   It's no more challenging than your proposal to replace the ID field entirely.

> field and using them both.

  There is likely no technical value.  The issue is any change requires consensus from RADEXT and IESG, which means the changes must be *percieved* to be minor extensions to RADIUS.

  Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Tue, 18 Apr 2017 17:52:48 -0700

Hi, Alan:

>   That's called "Diameter".  :(

That is a different protocol :-) For better or worse RADIUS is not going away in
enterprise anytime soon.

>   The issue is solving one problem at a time.  There is no *current* need to extend
>   the Code space.  Therefore, there shouldn't be a proposal to extend it.

I have to disagree. I do not see any benefits with the piecemeal approach in this
case. 

>   If you need an explicit ACK, create one.  Don't overload the contents of an attribute.
>   See RFC 6929 Section 6.3 for guidelines on using Complex Data Types.

There are tradeoffs. The question is, do we really want to burn another attribute
when one can do?  I would think that we want to preserve the attribute space and
learn from the past.

>   Making clients and servers change the meaning and interpretation of the ID field
>   is changing RADIUS.  I don't think you will get consensus from RADEXT, much less
>   the IESG for this proposal.

"minor" vs "major" is just opinion, right?  Also is there some IETF rule that
states that a particular field can not be touched (even when needed), especially
when it is done in a backward compatible way?

I think that we will be better served if we just speak for ourselves (instead of
for someone else or IESG), and stay on the technical issues.

>   Sure.  Except that *major* changes to RADIUS are called "Diameter". :(

Again, you consider this ID enlargement as "major", and I do not, but that does not
really matter. RADIUS is not going away anytime soon, and we have to keep addressing
issues we face.  I guess that is the reason this WG still exists.

>   There is likely no technical value.  The issue is any change requires consensus
>   from RADEXT and IESG, which means the changes must be *percieved* to be minor
>   extensions to RADIUS.

Our experiences may differ. My experience with IETF has been quite positive regarding
addressing real world issues and making progress.  No religious, and no kings, and
"Rough consensus and running code" have got us this far.  But that is probably off
topic.

Thanks.   -- Enke

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Apr 2017 21:54:47 -0400

> That is a different protocol :-) For better or worse RADIUS is not going away in

  What I mean is that extending the Code space has already been done in Diameter.  There is no need to do it in RADIUS.  Even worse, if there *is* a need to do it in RADIUS, the answer should be "don't do it, just use Diameter".

> I have to disagree. I do not see any benefits with the piecemeal approach in this

  It's about doing what's necessary.  It's not necessary to extend the Code space at this time.  Therefore, it shouldn't be done.

> when one can do?  I would think that we want to preserve the attribute space and

  My $0.02 is that a simpler approach will work just as well.

> when it is done in a backward compatible way?

  It's at least convention.  I've had enough discussion with people that I think there is wide-spread consensus that major changes to RADIUS won't be approved.

> for someone else or IESG), and stay on the technical issues.

  I've given my technical review of the document.

> issues we face.  I guess that is the reason this WG still exists.

  Yes... that's not my point.  My point is that we've been patching RADIUS in minor ways for a long time now.  That's unpleasant, but part of real-world engineering.

  Major changes to RADIUS have wide-spread opposition in the IETF.  You don't need to convince me that the changes will be OK.  You need to convince everyone else.

  Alan DeKok.