Re: [radext] Extended IDs

[Peter Deacon <[e-mail]>]

On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote:

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

Offered an example in my initial response.  More detail below.

Request:
[+Client]  ---> [-Proxy A] ---> [+Proxy B] --> ...

Response:
... ---> [+Proxy B] ---> [-Proxy A] ---> [+Client]

+ supports extended id
- does not support extended id


Assumptions:

- Proxy A performs duplicate detection over (src ip/port) + id.
- Requests transmitted from Client /w extended ID.
- Client receives responses /w extended ID courtesy of Proxy B.


This scenario can easily result in high numbers of intermittently dropped 
packets because Proxy A is intentionally dropping what it believes are 
duplicates.  Proxy A does not implement extended id and so has no idea 
what is going on nor instrumented to know anything about extended id.

Client is similarly clueless.  It sees extended id requests AND extended 
id responses /w intermittent packet loss.  It has no clue the upstream 
proxy it is directly communicating does not support extended id.  There is 
no way for it to know.

>From the client perspective it would in my experience likely be very 
difficult for an operator to troubleshoot this kind of intermittent 
failure one that gets progressively worse as load increases unless they 
had an unrealistically high degree of technical knowledge.


This problem DOES NOT exist /w ORA because any and all such 
misconfiguration always results in client seeing no valid response at all. 
This is an acceptable response to misconfiguration.

A client receiving bogus ORA from some other peer or no ORA at all is free 
to complain loudly explicitly alerting operators of misconfiguration. 
This option simply is not possible /w extended id.

regards,
Peter