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

["Scheffenegger, Richard" <[e-mail]>]

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 https://tools.ietf.org/html/draft-trammell-tsvwg-spin :)

Best regards,
   Richard