Subject: Re: [radext] Extended IDs
From: Alan DeKok <[email-masked]>
To: Astrid Smith <[email-masked]>
Cc: Winter Stefan <[email-masked]>, [email-masked]
Date: Fri, 1 Dec 2017 17:16:36 -0500
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>

On Nov 28, 2017, at 3:18 PM, Astrid Smith <[email-masked]> wrote:
> I'm concerned about the extended Code field it defines: How should
> implementations treat messages where this Code differs from the Code
> in the RADIUS header?  The precedence is poorly defined and liable to
> cause issues.

  That is a concern.  What happens if the same Extended ID is used in two different packets from the same src/dst IP/port + Code + ID?

> The proposal also requires all proxies to explicitly support (by
> parsing and passing through, or by stripping) the Identifier
> Attribute; this requires protocol users to upgrade and test all the
> software in their RADIUS deployment before any clients may safely
> attempt to use the attribute.

  There are provisions for negotiation in both drafts.

> The request-authenticator proposal appears safe to deploy without
> upgrading the software of any proxies in the network.  As a maintainer
> of a RADIUS proxy I prefer this, and I suspect my customers would
> agree :)

  The one benefit of the request authenticator draft is that even in the case of misconfiguration, it's *impossible* for the extended IDs to leak across a proxy boundary.

  draft-chen, on the other hand, would have the extended ID leaked across old-style proxies if the client was statically misconfigured.

  Alan DeKok.