Re: [radext] Extended IDs

Hello,

> Once we are arguing "It doesn't work when there's bugs or misconfigs",
> then we've sunk pretty low.

As a chair:

I do not think that was the point made in this (sub)thread.

The substantial part of the discussion was about misconfiguration (not
bugs in implementation), and the *extent* to which a misconfiguration
does harm.

The argument was that draft-dekok has a more gentle failure consequence:
communication between a client and its communication target (server or
proxy) does not work, and deterministically so. The breakage is local
between the two.

Contrary to that, draft-chen's failure mode is that confusion about the
state of communication peers may transpire along all proxies and the
final server along the proxy chain, with the ability to debug and
isolate the problem becoming difficult.

It is a configuration problem because nobody is required to implement
this new RFC - so if a request comes in with the new attribute, it's by
default treated like any other unknown attribute in RADIUS: ignore as a
server, forward unchanged as a proxy. This simple "do-nothing" is what
triggers the unpleasant failure mode in draft-chen draft. To prevent it,
every proxy operator has to take action and configure this attribute as
to-be-deleted when proxying.

That appears to be a very strong argument against a new attribute.

As an individual:

Operating a global-scale proxy environment with hundreds of proxies
across hundreds of different administrative domains, I think I can say
with some certainty that a) proxies without support for the new RFC will
be around for timescales best measured in decades, and b) such
misconfigurations WILL occur.

Greetings,

Stefan Winter

>  But now that we're there, here is a more
> likely bug: Retransmission with a new request-authenticator.
> draft-dekok will interpret that as an entirely new request.
> That is why keeping the id and authenticator separate is cleaner.
>
> Thanks,
> Jakob
>
>
> -----Original Message-----
> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Naiming Shen (naiming)
> Sent: Tuesday, December 12, 2017 10:08 PM
> To: Peter Deacon <peterd@iea-software.com>
> Cc: radext@ietf.org
> Subject: Re: [radext] Extended IDs
>
>
> When I say “check the status of the server”, sorry I didn’t mean the server-status
> message. When an operator decides to do manual configuration of a new feature
> and override the normal automated discovery procedure, he/she needs to check
> the radius server and/or radius proxy server software version, status, etc. He/she would
> not just blindly configure the new feature, and go home to sleep and assume
> everything is fine. That's just common sense. 
>
> BTW, Status-server is not supported universally is not a problem here.
> When the server software supports this draft, then it MUST implement the
> Status-server message at least for this feature.
>
> Regards,
> - Naiming
>
>> On Dec 12, 2017, at 9:58 PM, Peter Deacon <peterd@iea-software.com> wrote:
>>
>> On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote:
>>
>>> If you insist misconfiguration is the greatest thing we have to deal with,
>> Decision to expand on original remarks in response to call for adoption was result of your inquiry:
>>
>> "Third, if assume an operation completely messed up, and leaking this extended-ID towards the home-server, I still need to see a good example on what the harm is that, and why this can not be debugged. The draft I agree needs to add some text on various cases and how to debug those in each of them."
>>
>> Otherwise I am happy with the relative strength of my remarks in their original context.
>>
>>> then I can imagine you misconfigurae your server ip address and proxy ip address,
>>> and packets will not be returned, how to you troubleshoot that? if you do
>> If when manually switched on in an environment where it should not be the result is not working at all that would be perfectly fine.  Unfortunatly as I have shown this is not the case with extended-id.
>>
>> In this aspect of consideration ORA clearly has an advantage both in ability to detect and report failure and nature of failure itself.
>>
>>> have ways, and this draft also have ways. Can you imaging an operator
>>> insist to do a manual configuration without check the status of the server,
>> Yes absolutely.  This will defiantly occur.  Status-server is not universally supported.
>>
>> regards,
>> Peter
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext