Subject: [radext] Requirements for extended ID

From: Alan DeKok <[email-masked]>
Date: Mon, 25 Jul 2016 07:22:23 -0400

Following on my previous email, I'd like to have a discussion around the requirements for extending the RADIUS ID space.

  I think changing the headers or protocol is forbidden.  Which pretty much leaves us with using an attribute that contains the extended ID.

  If the extended ID is used in packets without prior configuration or negotiation, existing proxies may forward that attribute as-is.  That may lead subsequent servers to erroneously believe that the previous hop was the source of the extended ID.

  So we can only send the extended ID when manually configured, or when server capability is discovered.

  After some thinking, I think it's OK to ignore the problem for UDP transport.  the reason is that UDP has another issue, which is small packets.  Each UDP packet takes up one ethernet frame.  Even if the extended ID allows a NAS to send 1M packets/s over a UDP src/dst IP/port pair, Ethernet can't always support that.

  Moving to TCP transport solves the Ethernet issue.  It also helps with the capability negotiation.  Because if a TCP connection remains up, you're pretty sure that you've stayed connected to a particular application.  In contrast, a UDP application can change between reception of one UDP packet and the next.  So adding capability negotiation to UDP means that you're never really sure if the other end actually is the same one now, that you negotiated with, 10 minutes ago.

  I think the text in Section 2.3 of https://tools.ietf.org/html/draft-chen-radext-extended-header-00 is OK.  I'd add:

* the Status-Server MUST only be sent over TCP/TLS connections, and it MUST be the first packet sent over that connection. 

* other packets MAY be sent over that connection before extended ID is used, but those packets MUST NOT use the extended ID until it has been negotiation.
  * in practice, it's probably better to just wait.

* If a new TCP/TLS connection is brought up while an old one is still active, the new one MAY just send extended ID without negotiation.
  * in practice, it's probably better to just negotiate every time.  It simplifies the code, and it's only one packet.

* it can work with DTLS too, as there is an underlying TLS connection.

* it can *sort of* work with UDP, subject to the problems noted above.  But I'd be OK with implementing it.  I don't think there would be many issues in practice.

  The next question is what *format* does the extended ID have?  A 32-bit token would be a good choice.  I think we should take a serious look at making it 64-bit.

  The reason is a different, but related problem.  When proxies fail-over, a duplicate packet can get routed across different paths.  Right now, the home server won't detect the new packet as a duplicate.  I think it should be able to do that.

  The solution may be to just re-use the Hop-by-Hop Identifier and End-to-End Identifier from Diameter. :)

  The text in RFC 6733 is mostly OK for RADIUS.  I'd replace the use of Origin-Host AVP with the Opaque-NAS-Identifier from the CoA proxy document.

  Hmm... for Status-Server, I'd argue that the End-to-End Identifier MUST be zero.  Which indicates that it's a message local to the current hop, and must not be proxied.

  Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Tue, 26 Jul 2016 14:07:29 -0700

Hi, Alan:

Thanks for your comments. My comments are inlined.

On 7/25/16 4:22 AM, Alan DeKok wrote:
>   I think changing the headers or protocol is forbidden.

Could you please elaborate on why changing the headers of a protocol is forbidden?

AFAIK, it has been done in several other protocols for similar reasons that we are
facing in Radius. I understand that such changes are not to be taken lightly ...

> Which pretty much leaves us with using an attribute that contains the extended ID.
> 

Yes, that is right. We either use "capability discovery" or manually configuration.

> 
> After some thinking, I think it's OK to ignore the problem for UDP transport.  the reason is
> that UDP has another issue, which is small packets. 
> Each UDP packet takes up one ethernet frame.  Even if the extended ID allows a NAS to 
> send 1M packets/s over a UDP src/dst IP/port pair,
> Ethernet can't always support that.

How about the case of using multiple interfaces?

> 
> Moving to TCP transport solves the Ethernet issue.  It also helps with the capability negotiation.
> Because if a TCP connection remains up, you're pretty sure that you've stayed connected to a
> particular application.
> In contrast, a UDP application can change between reception of one UDP packet and the next.
> So adding capability negotiation to UDP means that you're never really sure if the other end
> actually is the same one now, that you negotiated with, 10 minutes ago.

TCP has the same issue with the "ID" field, though.

>   * in practice, it's probably better to just wait.

Ok.

>   * in practice, it's probably better to just negotiate every time.  It simplifies the code, and it's only one packet.

Yes, I agree.

> * it can work with DTLS too, as there is an underlying TLS connection.

Ok.

> 
> * it can *sort of* work with UDP, subject to the problems noted above.  But I'd be OK with implementing it.
> I don't think there would be many issues in practice.

That is good - given your implementation experience.
> 
> 
>   The next question is what *format* does the extended ID have?  A 32-bit token would be a good choice.
>   I think we should take a serious look at making it 64-bit.

I am fine with 64-bit if it is indeed desirable.

> 
> The reason is a different, but related problem.  When proxies fail-over, a duplicate packet can get
> routed across different paths.  Right now, the home server won't detect the new packet as a duplicate.
> I think it should be able to do that.
> 
>   The text in RFC 6733 is mostly OK for RADIUS.  I'd replace the use of Origin-Host AVP with the
> Opaque-NAS-Identifier from the CoA proxy document.
> 
>   Hmm... for Status-Server, I'd argue that the End-to-End Identifier MUST be zero.  Which indicates
> that it's a message local to the current hop, and must not be proxied.
> 
>   Alan DeKok.

Thanks.  Will incorporate your comments in the next revision.

-- Enke

> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 26 Jul 2016 18:35:14 -0400

> Could you please elaborate on why changing the headers of a protocol is forbidden?

  Because changing the headers means it's no longer RADIUS.

> facing in Radius. I understand that such changes are not to be taken lightly ...

  We already have a "next generation" RADIUS protocol.  It's called Diameter.  We can't make substantial changes to RADIUS, or else we might as well give up, and just use Diameter.

> How about the case of using multiple interfaces?

  It doesn't really change anything.  Ethernet has an upper limit of packets it can sustain.  UDP packets use up one Ethernet frame, but only carry a small amount of data.  That limits the total bandwidth of the ethernet link.

  If the goal is to allow more data between client and server, then we should allow the maximum amount of data that can be carried via ethernet.

> Thanks.  Will incorporate your comments in the next revision.

  My $0.02:

* delete all the text about changing the header

* move to using a 64-bit attribute, with text mostly taken from RFC 6733.

  Alan DeKok.