Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

"Scheffenegger, Richard" <> Mon, 16 July 2018 09:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88F78130DE8; Mon, 16 Jul 2018 02:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wbpSlf-QJQYR; Mon, 16 Jul 2018 02:15:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32D69130DC1; Mon, 16 Jul 2018 02:15:42 -0700 (PDT)
Received: from [] ([]) by (mrgmx102 []) with ESMTPSA (Nemesis) id 0M9eHT-1flIJz0dR9-00CyIs; Mon, 16 Jul 2018 11:15:36 +0200
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <>, "" <>, "" <>
References: <>
From: "Scheffenegger, Richard" <>
Message-ID: <>
Date: Mon, 16 Jul 2018 11:15:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:WQBczm/2KY9aH/lmBeWs0dbNPJhzEJ8SGQlMgz9951V1bDXvGGP fcI/oWg0jJ0k3VrdspLEUQyTwrqWU0rcpT0N9bUOE1t/WXrWRazYpuGNkr9kCpJrbWpKjC7 XmmiOi8pv8bYOWQDgWuVIx4JDSzwAw3oYyznpUpOBo2Dc3NUGFiHeUYqljYPTvMQsOobOA2 hUyrrOjovLCMWqqbdaOvA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UpZVx9uAk80=:1dwWEuUefe0O9VUHL5gs9/ EbP9gcysd5J7naP5HWM1W+hsn0MzpSSuHdw5TnD9ZORL+JOv3rt9FWQIg+O8pR9SKvJXet2gX ZC3tmA+Oy90PYP9+y3tm2Q400X2EgCoNeYwOkNz9bNBQJfbvFkCr5Z7ZdnI7KpRL6pOgpinVK VZVIAaF2NqZq9TKzqE3A7EVnxBFms93WuWRw1kXHIkHltbnTD+a95cBJKfNPlshW9TikxsrHn VRKn83sdGm5e3p8S45YgGwkhA0zfTTKILEb/OQgPwTrpgUqCfPwCt0t/6D4sUPF6vnZTfkIbb 3SXY4rYosWhdL8igZ6iQc7HPFyG2jyk6do211oGwl26Ou9GiSeo7vps3H6fsHy4rlv4bGJoox Se+XDns46qwaa5TVxiRLXq1KrGlPEgczWgoGxM0Gt7PDiAwDXum47oB4GuQUdZYB73SMpadc6 3Tm6oBtMV7EvTmgJE2p13/mnJCG/MtQklcXMY0LRNDaeYZ8P6h1sIZz7KVzTVkmG0uTgmC6DN mCSl2etxJI064/9MflBWSEwMTMK+xAB/FAZ9EKTmcoNhbZDqfZ7R/sFqUqg9SI7qabuuvSQY3 T054axZb8f+NZJ4+vUAM2kjLQ4LSznmqMz90ScMGptFDq/VpG9dt9jvziDY3c7yk6AxJKbj2v fpUfSlP5jP9ij6xSTetTl2mjx9dWmC4hd3cn4ge+OTeqkWlAGcga+7yQtgsM0TFPUhwiPyyeG PRKZpytrLPOf6utQWsc1OBeC0DrNuwLqt+k6g4mpW6Pf4vpDIEeYLDYY1MDaKgGiaJ3mi8HEx Ym5ryeD
Archived-At: <>
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jul 2018 09:15:46 -0000

Hi Michael,

Am 15.07.2018 um 22:54 schrieb Scharf, Michael (Nokia - DE/Stuttgart):
> Hi all,
> While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
 > [...]
> Section 7.  Security Considerations
> [ms] I wonder about the security implications of "confusing" classic ECN and AccECN feedback in (passive) network monitoring solutions, most notably if packet sampling is used and no per-connection state is applied. At least theoretically, passive monitoring of "classic ECN" TCP header flags could be used for network monitoring, e.g., to estimate congestion levels in a network, no? How would such a (hypothetical) passive monitoring solution be able to distinguish the standard ECN feedback from an ongoing AccECN experiment, in particular in a sampled packet stream w/o having access to the SYN negotiation? Would there be security or safety implications when experimenting with AccECN in networks using network monitoring solutions that only support ECN as standardized by the IETF?

For the safety aspect, if a middlebox meddles with the tcp header bits, 
and doesn't forward segments with specific ACE field codepoints, a 
reasonable response would be to resend the second or third 
retransmission with ECN disabled, and disable ECN for the remainder of 
the session. However, none of the large scale measurements conducted so 
far has found an indication of such a middlebox misbehavior to warrant 
text here. The regular AccECN negotiation will capture all known 
misbehaving middleboxes.

As to the passive monitoring - Mirja and Brian will certainly expand on 
this, but sampling ever so often should expose ACE field codepoints with 
high probability, which are unlikely or not possible with RFC3168 ECN 
(e.g. CWR + ECE is very unlikely - pure ACKs are not ECT marked in 
RFC3168, and bidirectional data exchange without stretches of pure acks 
is not common), anything with the former "NS" bit set has never been 
observed on the public internet to my knowledge. To summarize random 
sampling has at least a 5/8th chance to detect AccECN. However, as r.cep 
(section 3.2) is initialized to a value of 5 (101b), and many (short) 
flows probably rarely encounter a CE mark, the chance to detect, by 
random sampling, the presence of AccECN passively is even higher than 
this.  Short flow with up to 2 CE marks are immediately detectable, as 
the former "NS" bit remains set.

As to the passive monitoring of the congestion levels - the same problem 
of having only 1 bit signal per RTT applies here too, not? Also, you 
probably don't know where the congestion point (doing the CE marks) is 
from your vantage point, but looking at the TCP header flags to estimate 
the congestion levels is IMHO not the correct approach - for that, you'd 
want to evaluate the IP header "CE" marks, and AccECN does not change 
that at all...

If anything, AccECN should improve the passive monitoring of congestion 
*levels* (on asymetric paths) as now the monitoring point can track each 
CE in the reverse path; formerly, you could only use the stream of ECEs 
to estimate the connection receive window (spin bit), but not the extent 
of congestion in the network...

This "former use" of the ECE bit could be taken over by a different 
signal - see :)

Best regards,