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

[Bob Briscoe <[e-mail]>]

David,

I hope you will find that I have addressed all your concerns - so at 
least you will be able to understand it now.
The draft is now unexpired.

I have also addressed all the points in Mirja's review (some 
intersecting with your points).

You will see that it's actually turned into quite a major re-write. The 
diff is nearly total, mainly cos I was turning Spanglish into English as 
I went (Marcelo, it was quite understandable, but just not quite how a 
native English speaker would say it).

However, I have changed technical points in a few places too - the more 
one thinks about this, the more depth one finds.

I just noticed I missed one of your nits (shortening the definition of 
Retransmission), which I have already fixed in my local copy of the xml 
for the next rev.



Bob


On 08/04/17 01:11, Bob Briscoe wrote:
> 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/