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

[Bob Briscoe <[e-mail]>]

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]>;
> [e-mail];[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/