Re: [Stackevo] New Version Notification for draft-hardie-path-signals-02.txt

["Brian Trammell (IETF)" <[e-mail]>]

> On 3 Jan 2018, at 23:25, Martin Thomson <[e-mail]> wrote:
> 
> On Thu, Jan 4, 2018 at 3:33 AM, Eliot Lear <[e-mail]> wrote:
>>> I don't think that we need any specific mitigation, but we should
>>> recognize that this is a natural consequence of the recommendations in
>>> the draft.  That isn't strictly a negative outcome either.  One
>>> conceivable - but actually highly unlikely - outcome of designing
>>> explicit signals is that intermediaries might insist on a certain set
>>> of signals before a packet is allowed to pass ("give me SNI or I kill
>>> your flow").  A signal that isn't directly coupled to the actual
>>> protocol machinery can be falsified to appease a middlebox, even in
>>> cases where the endpoint might otherwise prefer not to provide the
>>> information.  I wouldn't include all that exposition though, just note
>>> that falsification is possible, without affecting the e2e protocol
>>> operation.
>> 
>> I think it's probably worth expanding this point.  Falsification of
>> signaling means that middleboxes will not trust it.  To what degree that
>> holds true will depend on circumstances, but if it becomes the general
>> case, one has to ask what the point of including it was in the first
>> place?  That way lies dragons.
> 
> That's why I think we are better avoiding saying anything.  The value
> of signals will depend greatly on whether endpoints provide accurate
> values, and that in turn will depend on the consequences that are
> attached to either faithful or falsified values.  I can't predict the
> outcome, which remains the big open question in this entire space.
> It's certainly true that there is a case for mutual benefit to be
> gained by filling explicit signals accurately, but it's not clear if
> the gains are as well understood as for other voluntary things, such
> as using a sane congestion control algorithm [1].

For what it's worth, https://tools.ietf.org/html/draft-trammell-quic-spin-01#section-7 addresses this issue in particular for the spin bit in the last two paragraphs of section 7. IMO it might make sense to mention this in the general case, and to note that the specifics of trustworthiness have to be considered separately for each signal.

> [1] Side discussion for bonus credit: In TCP, an endpoint that fails
> to observe proper sender behaviour with respect to congestion control
> can be managed in the network by terminating their TCP connections.
> End-to-end protection of the transport prevents that.

Keeping a LRU stateful flow rule to drop all packets for a five-tuple, refreshed on every packet seen, is sufficient for a forwarding middlebox to terminate a connection identifiable by five-tuple. AFAIK at least one of the famous stateless RST-emitting censorship firewalls has migrated to stateful operation along these lines, so there's at least one existence proof for stateful connection killing that scales (if you're motivated to pay for it).

Breaking the five-tuple = connection equivalency is necessary to really screw thing up. :) So, more accurately, end-to-end protection of the transport together with aggressive connection migration or multipathing prevents that.

Cheers,

Brian


> _______________________________________________
> Stackevo mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo