Re: Adding ECN to Transport and Recovery

Magnus Westerlund <> Tue, 12 June 2018 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C99BA1310FC for <>; Tue, 12 Jun 2018 01:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ql0XKyWGO_X1 for <>; Tue, 12 Jun 2018 01:23:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB2F4130F93 for <>; Tue, 12 Jun 2018 01:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1528791795; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mOFGjXvqQ9wybQuSY8ofkK780F9PWGm+xgBQ3ciN5vY=; b=VXjVtlT4rdTmp228nIFTliTAqQZn1s2L3UkyLEKTEBmQJZrnLHUSNz7sSNzMKEAs eQjkUKHb946TR2bwCdgojFOTgUzEzxac29Edjp61AUu67gHUphP+NkuFW9TLmciA q94Sw9e+vtdwH4Cm1MWGXqL4gAS/Bgtp3G8sz/hnkyU=;
X-AuditID: c1b4fb3a-323229c000005fee-f3-5b1f82f216bf
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D8.D4.24558.2F28F1B5; Tue, 12 Jun 2018 10:23:15 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 12 Jun 2018 10:22:33 +0200
Subject: Re: Adding ECN to Transport and Recovery
To: "Lubashev, Igor" <>, "" <>, "" <>
CC: "" <>, "" <>, "" <>
References: <> <> <20180608150833.GB13418@ubuntu-dmitri> <> <> <> <> <> <> <> <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Tue, 12 Jun 2018 10:22:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------4944FC734587CA0F6A8716C7"
Content-Language: en-GB
X-Originating-IP: []
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7tO7nJvlog939zBaTG2ezW/y8t5PV YmPLOzaLpoYVzBbtl+YxW/Qs4HZg85h8ZAGzx85Zd9k9Fmwq9bg14xSLx5IlP5k8nuyfyRLA FsVlk5Kak1mWWqRvl8CVMfXXHvaCvQ2MFW2LfjA2MC5L6mLk5JAQMJE4+GgRexcjF4eQwBFG iQfHJkM5Wxglbq7pZOxi5OAQFjCU2HHRAaRBRKCFUWLtNBYQm1mgUuLUnVlsEPU3WCWufn3B CpJgE7CQuPmjkQ3E5hWwl5g24RyYzSKgKnG4Yw4TiC0qECOxeuNldogaQYmTM5+ADeUUCJa4 3bSCEWJBmMTJ7ffZIWxxiaYvK8HmCwloSzQ0dbBCfKAkcX3edZYJjIKzkIyahaR9FpL2WUDv MAOd9GBrGURYXqJ562xmCFtf4vqd+6zI4gsY2VcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxi BEbXwS2/rXYwHnzueIhRgINRiYc3q0A+Wog1say4MvcQowQHs5IIb64OUIg3JbGyKrUoP76o NCe1+BCjNAeLkjivU5pFlJBAemJJanZqakFqEUyWiYNTqoGR5/2Kc6w7LVt5zvsvvm78/Tbj 67b4XsmSLZXN/+ebtPSl16UePr7yZcYSZilFwUtPFZ2Xvdi+jnW+6xLbOXWXLq3h3BVx+vPm nuqT8T07FmkvWx90s0LB9lrutRD2JO2qNa2n73+/uXzOu1SGib/SDwf9sO7TXJgfe8lOq2GW 62e2YN9t1hGCSizFGYmGWsxFxYkAizhtpaoCAAA=
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2018 08:23:22 -0000


So, if the on-a-side attack manages to race its attack packet with CE 
set so that it arrives prior to the original packet with an ECT 
code-point it will affect the congestion window. The same way that if an 
attack can cause periodic network drop of packets for a QUIC connection 
the connection can't really distinguish this attack from a legit 
congestion indication signal.

So the PR's current security consideration addition says:

12.7.  Explicit Congestion Notification Attacks

    The ECN bits [RFC3168] are an unauthenticated signal from the
    network.  An on-path attacker may manipulate the value of the field.
    Thus, affecting the congestion avoidance behavior of the sender.  By
    clearing any CE marks the connection can help drive a bottle neck
    queue into a loss regime.  By setting the ECN field to CE marking it
    can drive down the senders congestion window thus resulting in
    reduced throughput.  The later could equally be accomplished by
    dropping packets for the connection.  Section 18 and 19 of [RFC3168]
    discusses the effects of undesired manipulation of the ECN field in
    more details.

    If a receiver would not have packet duplication detection and not
    discard any duplicates an off-path attacker that can receive copies
    of the connection's packets can manipulate the senders congestion
    avoidance state.  If packet duplicates are dropped, the off-path
    attacker will need to race the original packet to be successful in
    this attack.

If there is a proper on-path attack, then it can accomplish this already
to day by dropping packets, so ECN does not create a new vulnerability.
The requirement for an on-the-side attacker to successfully race its modified
packets make the attack harder to perform, the right situation must exist
where the normal route is longer than the route for the attacker, i.e.
tap -> attacker -> receiver. And the attacker must be able to tap the flow.
 From my perspective, that makes this an attack with limited applicability.

Mitigating the attack in either of the QUIC endpoints are also extremely
hard. How does a receiver or sender determine that the congestion signals
are manipulated? For an attacker that changes an ECT to ECN-CE I don't see
there being any reasonable detection mechanism. One would need to generate
parallel flow and statistically compare the behaviour of the flows to determine
that one flow was manipulated. But, such a flow is likely to be picked up by
an attacker as if I am attacking one I would tap the flows using a single
source or destination IP as flow template for the traffic that I as an
attacker are interested in.

For the case where an attacker removes the CE marks, that would be possible
to detect by sender side probes injecting CE marked packets, as discussed
in this issue:

My view is that the PR has the necessary text noting the issue and
referencing the far more extensive discussion in RFC 3168. We have an
issue to continue to discuss additional mitigation. Such mitigation should
be written up in a separate PR in my view.



Den 2018-06-11 kl. 14:18, skrev Lubashev, Igor:
> I do not think I have seen this in the PR, so I am wondering what your 
> recommendation is for defending against an on-a-side attacker, who 
> sets CE bits on every EC(*) packet and races that packet to the 
> destination? Should that be a part of this PR?
> - Igor
> -----Original Message-----
> *From:* Magnus Westerlund []
> *Received:* Monday, 11 Jun 2018, 1:15PM
> *To:* Jana Iyengar []; Christian Huitema 
> []
> *CC:* Brian Trammell (IETF) []; Ian Swett 
> []; QUIC WG []
> *Subject:* Re: Adding ECN to Transport and Recovery
> Hi,
> I agree with Jana, as there are not a clear consensus lets take any 
> further modifications of the ACK frames as a separate issue. The PR 
> have from my perspective no open technical content issues. I will 
> await to see if the editors or any of you have any editorial issues. 
> But, otherwise I expect this PR to be merged quite soon.
> I will now start working on a new section for a separate PR regarding 
> the ECN black hole mitigation.
> Cheers
> Magnus
> Den 2018-06-10 kl. 19:14, skrev Jana Iyengar:
>> Sounds like there's general agreement that modifying the varint to 
>> contain a flag bit will add unnecessary complexity.
>> Let's try to get the PR in as it is now, and if anyone really wants 
>> to go merge this and the ACK frame or rename things, let's paint that 
>> bikeshed separately.
>> On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema < 
>> <>> wrote:
>>     > On Jun 9, 2018, at 8:27 AM, Ian Swett <
>>     <>> wrote:
>>     >
>>     > QUIC is complex enough, I think we should just call them ACK
>>     and ACK_ECN.  A few implementations sending at least one ACK_ECN
>>     frame per connection will dispel any belief that ACK_ECN is
>>     optional.  A small amount of use will be a lot more valuable than
>>     clever naming.
>>     Also, ECN is just one of the extensions that could be planned for
>>     ACK. Timestamps would be nice too, for those who want
>>     one-way-delay based congestion control.
>>     -- Christian Huitema
> -- 
> Magnus Westerlund
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden |
> ----------------------------------------------------------------------


Magnus Westerlund

Network Architecture & Protocols, Ericsson Research
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: