Re: [radext] Extended IDs

[Peter Deacon <[e-mail]>]

On Tue, 28 Nov 2017, Stefan Winter wrote:

>> I think it would be good if all remaining readers of this list who care
>> enough now take some time to read both drafts and make up their mind on
>> what the preferred approach is.

>> In approx. two weeks' time I will start a call for adoption on both
>> drafts, and hopefully there are enough responses to make the exercise
>> meaningful. If so, the one with more votes wins.

> * draft-chen-radext-identifier-attr-02
> * draft-dekok-radext-request-authenticator-02

> Since the two drafts treat the same topic, at most one can be selected
> to serve as the basis for future work.

> In your reply to this call for adoption, please indicate which of the
> two drafts you think should be adopted. You can of course also indicate
> that none of the two are fit for purpose. The only thing you really

While both approaches achieve the same thing using similar means and 
similar properties of the two draft-dekok-radext-request-authenticator-02 
is my preference.  Details below for those interested.


----
draft-chen-radext-identifier-attr-02

While I have some minor concerns:

- structure of attribute
Please make it a normal integer?

- ordering requirement
Only one specification can ever demand its attribute be "first". You have 
to check the rest anyway to enforce stated constraint.  This should be 
relaxed.

- lack of details

The approach at a high level is reasonable and makes sense to me.

A very minor issue I see is behavior in face of misconfigured clients by 
allowing for manual configuration:

Consider client /w extended id support enabled sends Request to immediate 
upstream server in proxy chain not supporting extended id.

In this case some things may happen:

1. No server in the chain support extended id resulting in client never 
seeing a response.  This seems acceptable enough to me because the client 
is after-all misconfigured.

2. One or more servers in the chain support extended id.  What happens in 
this case is implementation specific.

A. Best case the benefits of extended id space are successfully tunneled 
back to requesting client thru servers that don't support it.  This is 
actually kind of cool assuming it's what actually happens.

B. Second best extended id attribute is dropped due to proxy specific 
policy restrictions causing client to never see response.  No response is 
an acceptable response to client misconfiguration.

C. Not so good proxy server is only checking srcaddr/srcport/id for 
duplicate requests resulting in a ton of dropped requests and a 
potentially difficult problem for operators to understand or troubleshoot.


----
draft-dekok-radext-request-authenticator-02

This approach also makes sense conceptually and seems to be marginally 
easier to manage.  No changes to request attributes, no worry about 
dynamic auth req and no sequence counter to maintain when generating ORA 
response.

This approach offers a small benefit ORA response always unambiguously 
correlated with requesting peer avoiding possibility of (C.) behavior in 
proxy chains.

I don't agree with client behavior when ORA is expected yet missing.  The 
response should always be to silently ignore request.  Certainly mandatory 
fallback mechanism for static configuration is going way too far in 
dictating behavior / controlling operator preference.

Wouldn't count on those who elect to implement a mechanism like this to 
also spend too much time working viable scalable connection management to 
provide useful interop with servers that don't support ORA otherwise to be 
honest likely wouldn't be much point in implementing this draft in the 
first place.  In my view it should not be assumed fallback is harmless or 
even a viable option.

regards,
Peter