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

[Alan DeKok <[e-mail]>]

On Dec 14, 2017, at 9:43 AM, Stefan Winter <[e-mail]> wrote:
> 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.

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

  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.