Re: [radext] Extended IDs

[Enke Chen <[e-mail]>]

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.

>
> * using the 4-octet identifier *instead of* the normal ID means the protocol
>   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
>   don't implement this.

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.

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

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