Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black)

[Bob Briscoe <[e-mail]>]

David,

On 2) I intend to replace the whole of "3.1 Network behaviour" with the 
following, which calls out the cases explicitly:

Previously RFC3168 required the sender to set not-ECT on certain TCP 
control packets. Some readers might have erroneously interpreted this 
aspect of RFC3168 as a requirement for firewalls, intrusion detection 
systems, etc. to check and enforce this behaviour. Now that the present 
experimental specification allows TCP senders to set ECT on all TCP 
packets (control and data), it needs to be clear that a firewall (or any 
network node) SHOULD NOT treat any ECT packet differently dependent on 
what type of TCP packet it is.

One potential exception is envisaged, otherwise the previous sentence 
could have said "MUST NOT" rather than "SHOULD NOT". The exception 
allows a security function that has detected an ongoing attack to drop 
more ECT marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT 
be applied routinely. It SHOULD only be applied if an attack is 
detected, and then only if it is determined that the ECT capability is 
intensifying the attack.


Bob

On 07/04/17 23:33, Black, David wrote:
> Bob,
>
> Two comments:
>
> 1) I'll wait for new text before commenting further on Accurate ECN vs. vanilla RFC 3168 ECN.  The current text left me somewhat confused, and the summary of changes from RFC 3168 will almost certainly help.
>
> 2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section 5, top of p.7):
>
>     The CE codepoint '11' is set by a router to indicate congestion to
>     the end nodes.
>
> One wants to avoid text that could be read as modifying that sentence by adding possible exceptions for TCP control packets and/or retransmissions.
>
>> [BB] Unfortunately, RFC3168 does not specify anything about network node
>> forwarding behaviour wrt ECT. So some firewall policies could have
>> decided to block any TCP control packets that contravene RFC3168. That's
>> why we wrote this section.
> If "firewalls" is what was meant, use that word ;-) ... or as you write ...
>
>> However I admit that, by not explaining that DPI was the problem we were
>> trying to solve, rather than removing any ambiguity that might have been
>> interpreted as a need for DPI. We'll fix this.
> In doing so, please keep in mind that in this draft, discussion of forwarding  and dropping behavior is implicitly about router queue management, not middlebox access control (e.g., based on DPI), so access control has to be called out explicitly when that is what is meant.
>
> Thanks, --David
>


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/