Re: [radext] Extended Identifiers: failure modes

[Alan DeKok <[e-mail]>]

On Dec 15, 2017, at 2:30 AM, Stefan Winter <[e-mail]> wrote:
> If there were only one draft, I'd happily care about this after WG
> adoption. But considering that there are two competing concepts where
> one of the main differences is apparently on this very question, and
> where the difference is rooted in the /concept/ (i.e. not easy to fix
> with draft revisions later on), I believe it makes sense to highlight
> this right now.

  I'd like to have a larger discussion of not only failure modes, but implementation issues.

  I really do suspect that a large part of the push-back against draft-dekok is not just the "overloading" issue, but that the failure modes and implementation issues are *described*.  Whereas in draft-chen, they're not.

  I also suspect that once we get into details, the issues with draft-chen won't be that different from draft-dekok.

> We have seen many arguments going back and forth on this topic. I'm
> trying to summarise those below.
> 
> The failure modes possible in draft-dekok
> a) are always local to the client/server pair that tries to communicate
> b) are harder to see during packet inspection of the request; need to
> correlate request and response

  I would phrase that as "there's no explicit indication in the request that the new method is being used".

  But all you need to do is observe one response containing the Original-Request-Authenticator, and you know that the draft is being used.

  If there is no such attribute... it's just traditional RADIUS.

  And if you can't see responses, well, you have other issues.  So I would label (b) here as a non-issue.

> c) correction of faulty configuration requires action of administrators

  The draft goes through fall-back in detail.  Implementations are mandated to have failure modes that are compatible with existing RADIUS.

  i.e. no administrator intervention is required.

> The failure modes possible in draft-chen
> a) possibly transpire over an arbitrary amount of proxies

  To be fair, most of the time the attribute "leaks", nothing bad happens.  But it does seem unfriendly.

> b) are easier to see in a packet inspection in the request; no need to
> correlate request and response

  You can see the new attribute in the request.  But to track packets, you'd still need to correlate requests and responses.

> c) correction of faulty configuration requires interaction of all
> administrators along the affected proxy chain, who are not necessarily
> otherwise in direct contact

  It's also not clear what the failure modes or fallback behaviour is for a client/server that communicate directly with each other.

> In that light, it would seem that neither of the two drafts are perfect.

  Anything RADIUS is far from perfect.

> draft-dekok has harder debugging on the local link, draft-chen may
> involve parties across "the internet" (or rather the subset of RADIUS
> servers on it).  In the end, the question is which failure mode is "less
> difficult" to handle.

  Implementation issues matter, too.

  If implementors are left to their own devices, we will have all kinds of deployment and inter-operability issues.  If we leave these discussions until *after* we've chosen a draft, then we might discover that the draft has had unseen issues all along.

  Alan DeKok.