Subject: [radext] Review of draft-chen-radext-identifier-attr-01

From: Alan DeKok <[email-masked]>
Date: Wed, 6 Sep 2017 10:14:16 -0400

This message reviews the document, and explains my thoughts on what more should be in the document.

   In this document we propose extensions to the RADIUS protocol to
   address this fundamental limitation and thus allowing for more
   efficient and more scalable implementations. More specifically, a new
   attribute ("Extended Identifier Attribute") 

nit-pick: I would just call it "Extended-Identifier", and use that name consistently throughout the document.

   Once the
   support is confirmed, the attribute can then be used to carry the
   extended identifier parameter

nit-pick:  Same here: just call it Extended-Identifier, not "extended identifier parameter"

   For brevity the extensions specified in this document are referred to
   as "the Extended Identifier feature" hereafter.

nitpick: I would just say "supports Extended-Identifier".

2.1. The Extended Identifier Attribute

  Again, use the name which will be in the IANA

3. IANA Considerations

   A new attribute ("Extended Identifier Attribute") is defined for the
   RADIUS protocol. The type value [RFC3575] needs to be assigned using
   the assignment rules in section 10.3 of [RFC6929]

  IANA needs explicit instructions.  "Assign a new attribute in the "RADIUS Attribute Types" with the following information:

Value		TBD (assigned by IANA)
Description	Extended-Identifier
Data Type	integer
Reference	TBD (this specification)

...   The value of the
   attribute has 4 octets, and consists of the following fields:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Sta|               Extended Identifier                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  My $0.02 is to just make it an "integer" attribute.  If it exists in Status-Server, it is an indication that the client wants to use extended identifiers.  If it exists in a reply to a status-server, it indicates that the server agrees to use this feature.

  To simplify packet processing and for consistency, the "Extended
   Identifier Attribute" MUST be encoded as the very first attribute in
   the attribute list of a RADIUS packet.  If the attribute does not
   appear as the first one in the attribute list of a RADIUS packet, the
   RADIUS packet MUST be treated as invalid and the packet be discarded
   according to [RFC2865].

  I would recommend deleting that text.  The Extended-Identifier should be an attribute like any other.  Otherwise it's really extending the RADIUS header, which can have compatibility issues.

  I would suggest replacing it with text saying that it's just a normal attribute, and that implementations MUST NOT rely on it being the first attribute in the packet.

  One simple reason is that implementations must walk the packet to see if it's valid, before they do any additional processing.  They can look for Extended-Identifier at the same time as they walk the packet, so there's really no cost in allowing it to be anywhere.

   Due to the hop-by-hop nature of RADIUS packet transmission between
   RADIUS devices, a PROXY server MUST strip the "Extended Identifier
   Attribute" (and reconstruct if appropriate) before sending the packet
   over a different session.

 That's my biggest worry about this proposal.  If proxies don't do that... the attribute "leaks" across proxies, and Bad Things happen.

2.2. Status-Server Considerations
   ...
   Prior to sending a RADIUS packet (other than the Status-Server
   request) with the "Extended Identifier Attribute", a client
   implementing this specification SHOULD first send a Status-Server
   request with the "Extended Identifier Attribute" to indicate its
   support for the Extended Identifier feature.

  That's good, but does the client have to wait for the response before sending any other packet?

  I would suggest allowing it.  i.e. clients can send Status-Server with Extended-Identifier, and *immediately* also send normal RADIUS packets without Extended-Identifier.

  The server can reply to normal packets the normal way.  And if the server receives Extended-Identifier (and supports it), it echoes the attribute back in replies.

  This dual capability can make implementations more complex.  But, it means that they can immediately start sending packets without waiting for negotiation to finish.

2.3. Use of the Extended Identifier Field
   ...
   The Extended Identifier is to be used together with the
   Identifier to identify requests and replies.  The assignment of these
   parameters is left to implementation.

I would suggest some guidelines here:

- the Extended-Identifier "ID space" is per connection.  i.e. tracking and comparison of Extended-Identifiers is done *in addition to* all existing RADIUS tracking of request / reply  ID / IP / port information.  It does not *replace* any of that.

- the Extended-Identifier ID is publicly visible, and therefore has no cryptographic purpose.  Implementations should likely just use a simple incrementing counter per connection.  That way minimal tracking has to be done on the client.

- How is the Extended-Identifier use in UDP, where RADIUS clients may be behind a NAT (not really supported officially in RADIUS, but a wide-spread use-case)  (See Section 7.1 of my draft)

- and what happens for TCP and dynamic discovery? (See section 7.2 / 7.3 of my draft)

- Does a client re-negotiate Extended-Identifier every time it opens a new source port? (See section 7.4 of my draft)

- who should use Extended-Identifier? Should low-load systems use it?  What are the costs for using it?
 
- what does a server do if it receives a packet with a duplicate Extended-Identifier?  (See Section 2.3 of my draft)

- can client and servers be administratively configured to support Extended-Identifier?  If so, they likely don't need to do negotiation.  But what happens if the configurations don't agree?  can the client send Extended-Identifier, fail to see it in the response...and fall back to normal RADIUS?  Or should it just always do negotiation?

- add Extended-Identifier as an allowed attribute in Access-Request, Access-Reject, Accounting-Response, etc. (See Section 6 of my draft)

- if the client successfully negotiates Extended-Identifier, is there a recommendation to NOT open multiple source ports?  I would suggest so...

- how does this capability affect proxies?  i.e. if they support Extended-Identifier inbound, but not outbound... what happens?  See RFC 6613 Section 2.5 for issues.

- a more detailed Security Considerations section would be good.

  My draft goes through many of these points in detail.  My draft also has a lot of text which likely shouldn't be in any published RFC, but serves to explain to the reader why these choices were made.  Once everyone agrees on the best approach forward, those explanations can be removed.

  Alan DeKok.