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

["Scharf, Michael (Nokia - DE/Stuttgart)" <[e-mail]>]

I disagree. I believe it would be possible to design a protocol spec that is more backward compatible with standardized ECN on the wire, which would not cause issue to (potentially) deployed passive monitoring systems that use packet sampling. Such passive monitoring systems could e.g. make wrong traffic engineering decisions because the TCP connection is not compliant to the ECN standards. Anomaly detection could also be triggered as the TCP header of packets deviates from the IETF standards. Due to the limited deployment of ECN, it is possible that this is not an important problem.

Yet, it is a design choice of the protocol that within a sampled packet stream standardized ECN cannot be distinguished from the proposed experiment, and that the experimental TCP header encoding on the wire is not backward compatible to the existing standards.

I believe a discussion on potential operational impact on potentially deployed systems belong into the document, e.g., along the lines of the text of Richard has written.

Michael


From: Bob Briscoe [mailto:[e-mail]]
Sent: Tuesday, July 17, 2018 1:13 AM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]>; Scheffenegger, Richard <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,



-----Original Message-----

From: Scheffenegger, Richard [mailto:[e-mail]]

Sent: Monday, July 16, 2018 11:16 AM

To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]><mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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



Hi Michael,
On 16/07/18 13:48, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

Section 7.  Security Considerations



[ms] I wonder about the security implications of "confusing" classic ECN

and AccECN feedback in (passive) network monitoring solutions,


[snip]

[RS] 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.

[ms] To me, this sort of discussion belongs into the document.


[BB] Although it's interesting to consider whether passive monitoring would be able to detect a difference between one version of a protocol and another, I think any discussion of that belongs in a draft about passive monitoring, or in mailing list discussion (as here). Not in a protocol spec.

We can't be expected to have to ensure that new protocols can be distinguished from old protocols by monitoring systems that haven't been properly programmed to look for the protocol negotiation during the handshake. If such a monitoring system is controlling something critical and it's not monitoring correctly, that is surely a safety issue with the monitoring system, not with the new protocol.

Having just been talking to a colleague who set up the monitoring systems for a mobile operator, the first and most obvious thing they do is look for the flow starts.




Bob




--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/