Subject: [radext] Comments on draft-chen-radext-extended-header

From: Alan DeKok <[email-masked]>
Date: Mon, 25 Jul 2016 06:49:13 -0400

I have some comments after the presentation at IETF.

  Yes, something like this has been needed for about 10 years.  However, I don't think this proposal is a good solution.

  Let's say the RADEXT WG likes it, and tries to standardize it.  I'm pretty sure that everyone *outside* of RADEXT will shoot it down in flames.  For very good reason.

  We just can't make breaking changes to the RADIUS protocol.  We can't extend it in incompatible ways.  Doing so would involve creating a new protocol, and we'd be better off using a "next generation" AAA protocol.

  Something like Diameter.  :)  But I disagree with Lionel's suggestion to use Diameter, for the simple reason that the RADIUS needs are *much* simpler than the Diameter ones.

  i.e. using the Diameter protocol as a transport layer may be a good idea.  Requiring NASes to implement all of Diameter is not.  The NAS vendors don't want to implement Diameter, the enterprises / telcos don't want to use Diameter.  RADIUS is (mostly) good enough.

  So we're stuck with RADIUS for now.  The problem then becomes how do we fix the 8-bit ID problem?

  There's at least one commercial product which has a work-around.  They add a VSA with an extended ID to each packet.  The extended ID is used only when manually configured on both client and server.

  It's a simple solution, and works well.  The requirement for manual configuration also avoids the issue of capability negotiation.  That has been an unresolved topic in this WG for almost a decade.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 25 Jul 2016 07:24:07 -0700

Agree with Alan. 

There is a real problem here but the proposed (backward incompatible) solution is a non-starter. The VSA extended ID approach has been in use for a decade and is a much better example of how this problem should be approached.

> On Jul 25, 2016, at 03:49, Alan DeKok <[email-masked]> wrote:
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

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

Hi, Alan:

Again thanks for your review and commands. My comments are inlined.

>   proposal is a good solution.

If there are specific suggestions, we will be happy to work you and others to make it better.

> 
>   Let's say the RADEXT WG likes it, and tries to standardize it.  I'm pretty sure that everyone
>   *outside* of RADEXT will shoot it down in flames.  For very good reason.
> 
>   We just can't make breaking changes to the RADIUS protocol.  We can't extend it in
>   incompatible ways.  Doing so would involve creating a new protocol, and we'd be better
>   off using a "next generation" AAA protocol.

I agree - this has to be done in a backward compatible manner, and that is what the proposal
tries to achieve.  Which part of the proposal would break backward compatibility?

> 
>   Something like Diameter.  :)  But I disagree with Lionel's suggestion to use Diameter,
>   for the simple reason that the RADIUS needs are *much* simpler than the Diameter ones.
> 
>   i.e. using the Diameter protocol as a transport layer may be a good idea.  Requiring NASes
>   to implement all of Diameter is not.  The NAS vendors don't want to implement Diameter,
>   the enterprises / telcos don't want to use Diameter.  RADIUS is (mostly) good enough.
> 
>   There's at least one commercial product which has a work-around.  They add a VSA with an
>   extended ID to each packet.  The extended ID is used only when manually configured on both
>   client and server.
> 
>   It's a simple solution, and works well.  The requirement for manual configuration also avoids
>   the issue of capability negotiation.  That has been an unresolved topic in this WG for almost
>   a decade.

Certainly manual config is an option as listed in the draft. Regarding using the capability
discovery, I do not understand the concerns or issues.  Certainly it has been used by several
recent extensions quite effectively.  It seems to me that the capability discovery is quite
nice in facilitating deployment of new features, and it is something that is needed.

-- Enke

---

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

Hi, Bernard:

As I replied to Alan, the proposal tries to address the issue in a backward compatible
manner. If there is something that would be of concern in the area, please let us know.

Regarding the option of using a VSA attribute, it is something that we discussed before
submitting the proposal. Since this is a fundamental issue, it would be better for
customers and our industry if the issue is addressed by radius server vendors broadly.

Thanks.   -- Enke