Subject: [radext] Extended Identifiers: is manual configuration in scope?

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Dec 2017 15:43:45 +0100

Hello,

there is one question to which the answer did not become entirely clear
in the discussion so far.

Could the authors of the respective drafts please clearly indicate the
answer to this question:

Is a manually configured mode of operation considered in scope?

I.e. do you consider it a valid use case that an implementation presents
administrators with a configuration option "Enable Extended
Identifiers", and that the implementation starts making use of that
feature /without/ a capability negotiation using Status-Server with its
next-hop peer?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Dec 2017 10:14:01 -0500

> Is a manually configured mode of operation considered in scope?

  Yes.

  https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-03#section-8.1

   Clients SHOULD have an configuration flag which lets administators
   statically configure this behavior for a server.  Clients MUST
   otherwise negotiate this functionality before using it.

> feature /without/ a capability negotiation using Status-Server with its

  Yes.

  We have manual configuration for many other things in RADIUS.  I think it should be allowed unless there is a strong technical reason to forbid it.

  On a related note, I'd like a more detailed discussion about the subject of negotiation.  What happens during negotiation?

  i.e. it's easy to say "send status-server and wait for access-accept with ACK or NACK".  But what *else* happens?

- are all *other* packets blocked until the client receives an ACK or a NACK?
  - i.e. does the client sit on all outgoing packets until such time as it receives a response?
- what if the server doesn't support Status-Server and never responds?
  - when should the client time out?
- should the client do the negotiation per connection (or for UDP src/dst IP/port combination)
  - if not, why not?
  - if so, why?
- what happens if the client stops sending packets for a while?
  - should it restart negotiation if there have been no packets?
    - if so, what are the timeouts?
- if the server sends an old-style reply after negotiating the functionality, can it be matched to an outstanding packet?

  My concern is that it's easy to say "negotiate functionality".  The code changes may even be small.  But the hard part of coding isn't implementing a particular piece of functionality.  It's ensuring that the program behaves correctly in corner cases, or when things go wrong.

  Taking a look at the patch posted earlier:

https://mailarchive.ietf.org/arch/msg/radext/BkXgD68MASxqD4vjXV1M2CaRWAY

  None of these issues are handled.  I suspect that dealing with these corner cases will make the code much more complex.

  Much of the verbiage in draft-dekok is there in order to deal with these issues.  As an implementor, the draft is written with an eye to dealing with *all* corner cases.  It gives technical reasons for the decisions, it discusses the pros and cons of these decisions, and it gives guidelines for implementors.

  The result is a draft which is *much* more complex than "add a 32-bit ID to a packet".  But that complexity highlights the complex nature of the protocol, instead of waving it away.

  I'd be happier with draft-chen if it could be shown that all of these issues are addressed in a *simpler* manner than in draft-dekok.  While I'm concerned with the possibility of "leaking" the extended-ID, implementation simplicity should be a serious consideration, too.

  Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Thu, 14 Dec 2017 12:00:27 -0800

Hi, Stefan:

Yes, it is, and such a config is allowed in the following section of
draft-chen-radext-identifier-attr-02.txt. 

----
2.2. Status-Server Considerations

   Unless specified by configuration, a client MUST NOT send a RADIUS
   packet (other than the Status-Server request) with the "Extended
   Identifier Attribute" to a server until it has received a response
   from the server confirming its support for the Extended Identifier
   feature using the "Extended Identifier Attribute".

Thanks.  -- Enke

On 12/14/17 6:43 AM, Stefan Winter wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

---

From: Stefan Winter <[email-masked]>
Date: Fri, 15 Dec 2017 08:30:38 +0100

Hello,

thanks for the clarification.

In this case - manual configuration is considered in scope -, both need
to be prepared for particular scrutiny of their respective failure modes.

The considerations in RFC5706 are of course valid for every draft in the
IETF; but they are even more in the focus of the Operations & Management
area, as the Appendix A of that RFC is what the Ops Directorate uses for
its OPSDIR reviews during IETF Last Call.

Failure Management is an explicit item to look out for, and the
pertinent question is:

"Does the solution have failure modes that are difficult to diagnose or correct?"

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.

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
c) correction of faulty configuration requires action of admnistrators
of two adjacent RADIUS nodes who are usually in contact with each other,
or even in the same administrative domain

The failure modes possible in draft-chen
a) possibly transpire over an arbitrary amount of proxies
b) are easier to see in a packet inspection in the request; no need to
correlate request and response
c) correction of faulty configuration requires interaction of all
administrators along the affected proxy chain, who are not necessarily
otherwise in direct contact

(IOW, two distinct arguments made earlier, "easier to debug" vs. "stay
local", actually both relate to the same topic of failure modes and
their remediation)

In that light, it would seem that neither of the two drafts are 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.

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Dec 2017 06:53:11 -0500

> with draft revisions later on), I believe it makes sense to highlight

  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.

> 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.

> 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.

> 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.

> 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.

> servers on it).  In the end, the question is which failure mode is "less

  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.