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

[Bob Briscoe <[e-mail]>]

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*

 1. Unreliable congestion notification delivery
 2. DoS Attacks

Common rebuttals (respectively):

 1. No worse than undetectable loss of Not-ECT control packet, and
    better performance
 2. 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:

 1. Unknown ECN capability at the responder (may discard ECT SYN or RST
    connection)
 2. Loss of congestion notification due to lack of support for feeding
    back CE on SYN at the responder.
 3. DoS attacks.

Rebuttals (respectively):

 1. 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
 2. 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.
 3. See common DoS Attack rebuttal


*Pure ACK**
*Arguments against ECT:

 1. Unreliable congestion notification delivery
 2. No means to feed back congestion notifications (no ACKs of ACKs)

Rebuttals (respectively):

 1. See common unreliability rebuttal
 2. No worse than drop of Pure ACK, and better performance


*Retransmission**
*Arguments against ECT:

 1. Unreliable congestion notification delivery
 2. DoS attacks
 3. Over-reacting to congestion.

Rebuttals (respectively):

 1. See common unreliability rebuttal
 2. See common DoS Attack rebuttal, complemented by recommendation to
    ignore CE on out of window packets
 3. Correct to react twice to congestion in different RTTs


*Window Probe**
*
Arguments against ECT:

 1. Unreliable congestion notification delivery

Rebuttal:

 1. 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
> [phone]     Cell: [phone]
> [e-mail]         
> ---------------------------------------------------
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/