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

[Bob Briscoe <[e-mail]>]

David, Mirja, list,

Thanks again for your reviews of the -00. I've been busy over the w/e 
after thinking more deeply about some of your comments and after 
realizing that RFC3168 contained an assumption that a single pure ACK 
implies that all other packets in that direction are pure ACKs, which is 
not true in general.

We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02 
<https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-02>).

This is a general invitation for anyone on the list, including you two, 
to review this again, so we can ask for an informed adoption call.

We need people with the following expertise:
* TCP hijacking and DoS/flooding attacks
* Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc).
* All the common variants of TCP

We have identified clearly where decisions are needed.
As well as where more measurements are needed.

Main changes:
* Moved more discursive text from S.3 (Spec) to S.5 (Arguments against 
RFCs)
* Major changes to Pure ACK sections and the reliability argument, to 
address Mirja's arguments better, and to separately address cwnd 
response (required) and ACK-rate response (optional but not required).
* Referred to Network Behaviour in ecn-experimentation, rather than 
repeating it.
* Fixed description of window probe.
* Recommended RFC 5961, which gives much stronger packet validity checks 
for retransmissions, RSTs & FINs.

Cheers


Bob


On 14/04/17 02:13, Bob Briscoe wrote:
> 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/