Re: [radext] Extended IDs

I prefer draft-chen-radext-identifier-attr-02. While both approaches
can work, I prefer not to overload the RA.

The draft needs some more work, but I believe it is ready for adoption.

Stig

On Sun, Dec 3, 2017 at 6:18 AM, Alan DeKok <aland@deployingradius.com> wrote:
> On Dec 3, 2017, at 3:22 AM, Peter Deacon <peterd@iea-software.com> wrote:
>> 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.
>
>   That was a major goal in the design.
>
>> This approach offers a small benefit ORA response always unambiguously correlated with requesting peer avoiding possibility of (C.) behavior in proxy chains.
>
>   It does have the possibility of a server sending the ORA attribute back in a response when it's not supposed to.  In that case, an old-style proxy *could* forward that attribute downstream.  We then have two cases:
>
> - the downstream proxy / client doesn't implement the draft, in which case the attribute is ignored
>
> - the downstream proxy / client does implement the draft, but hasn't negotiated it with the upstream (which doesn't implement it), and therefore the attribute is ignored.
>
>   So the change is compatible with existing servers for all possible scenarios.
>
>> 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.
>
>   That's certainly a good option.  I tried to cover all possible scenarios in the draft, with recommended behaviour.  But I'm open to changing the recommendations.
>
>> 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.
>
>   I'm happy with that.
>
>   i.e. if the server sends bad packets, the client should ignore them.
>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext