Re: [tcpm] Case for ECN-capable TCP control packets: draft-bagnulo-tsvwg-generalized-ecn

Hi,

I think this is interesting stuff!  Definitely good to work on, I’m interested to help out if needed.

Cheers,
Michael

> On 15. jul. 2016, at 20.31, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> David, [re-sending to include tsvwg & tcpm, which is what I had intended to do first time.]
> 
> Here's a heads-up for tsvwg, plus cross-posting to tcpm as suggested,
> And for a fast read, there's a summary of every argument below.
> Pls bash the arguments.
> 
> Summary:
> The ECN spec [RFC 3168] says various TCP control packets must not be ECN capable.
> This draft lays out each argument given in the RFCs, and articulates a rebuttal against each one:
> draft-bagnulo-tsvwg-generalized-ecn <https://tools.ietf.org/html/draft-bagnulo-tsvwg-generalized-ecn>
> Subject to some more experiments, we think this knocks down every reason given, so that all these packets could safely be ECN-capable.
> 
> Pls read the draft for more details (preferably before responding).
> 
> Enumeration of arguments about each type of control packet follows, starting with some arguments common to many:
> ___________________________________________________________________________________________
> 
> Common arguments against ECT
> Unreliable congestion notification delivery
> DoS Attacks
> Common rebuttals (respectively):
> No worse than undetectable loss of Not-ECT control packet, and better performance
> Mandating Not-ECT does not stop attackers using ECT for flooding. Nonetheless, it would allow firewalls to discard control packets not meant to be ECT., however this would negate the benefit of ECT for compliant transports and seems unnecessary for the following reason. 
> RFC3168 (Sec.7) and RFC7567 (Sec.4.2.1) say an AQM MUST turn off ECN support if under persistent overload. This makes it hard for flooding packets to gain from ECT, but more experiments needed to see how much might be gained by an attacker flying "just under the radar".
> 
> SYN/ACK
> ECT on SYN/ACK already justified in RFC5562
> 
> SYN
> Arguments against ECT:
> Unknown ECN capability at the responder (may discard ECT SYN or RST connection)
> Loss of congestion notification due to lack of support for feeding back CE on SYN at the responder.
> DoS attacks.
> Rebuttals (respectively):
> No RFC mandates these responder behaviours, but 0.6% - 0.8% of Alexa top 1M Web sites (or their network paths) exhibit this. Could retransmit the SYN without ECT, and cache this knowledge to avoid 1 RTT delay in future
> Support for CE feedback in SYN needed in the TCP wire protocol. Solution proposed in AccECN <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn> draft: if SYN/ACK shows lack of support for feeding back CE on SYN (i.e. no support for AccECN) IW MUST be reduced conservatively as if CE on SYN (no need to be as conservative as drop of SYN - cannot be severe congestion as packet got through). Could cache this knowledge.
> See common DoS Attack rebuttal
> 
> Pure ACK
> Arguments against ECT:
> Unreliable congestion notification delivery
> No means to feed back congestion notifications (no ACKs of ACKs)
> Rebuttals (respectively):
> See common unreliability rebuttal
> No worse than drop of Pure ACK, and better performance
> 
> Retransmission
> Arguments against ECT:
> Unreliable congestion notification delivery
> DoS attacks
> Over-reacting to congestion.
> Rebuttals (respectively):
> See common unreliability rebuttal
> See common DoS Attack rebuttal, complemented by recommendation to ignore CE on out of window packets
> Correct to react twice to congestion in different RTTs
> 
> Window Probe
> 
> Arguments against ECT:
> Unreliable congestion notification delivery
> Rebuttal:
> See common unreliability rebuttal
> FIN
> 
> No arguments against using ECT in RFCs.
> To be discussed in next rev of draft.
> 
> RST
> 
> No arguments against using ECT in RFCs
> To be discussed in next rev of draft.
> 
> Cheers
> 
> 
> Bob & Marcelo
> 
> 
> On 11/07/16 21:28, Black, David wrote:
>> Marcelo and Bob,
>> 
>> Interesting draft - I need to read it in more detail ... in my "copious spare time" this week ;-).
>> 
>> While it is of interest to TSVWG, as general ECN work happens here, I suspect
>> that as a proposed modification to TCP it would be in the domain of the TCPM WG,
>> as was the case for RFC 5562.
>> 
>> Thanks, --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC, 176 South St., Hopkinton, MA  01748
>> +1 (508) 293-7953     Cell: +1 (978) 394-7754
>> david.black@emc.com <mailto:david.black@emc.com>        
>> ---------------------------------------------------
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>_______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm