Re: [tcpm] poll for adopting draft-gont-tcp-security

[Matt Mathis <[e-mail]>]

Fernando Gont wrote:
> Matt Mathis wrote:
>
>> THIS DOCUMENT IS EXTREMELY DANGEROUS:: It is based in the same mindset
>> that successfully killed ECN before ECN was even conceived.  
>
> Please read e.g., page 24 (Section 3.6.1) and let me know if this is 
> the same mindset. Here's an excerpt of the aforementioned Section:
>
> "  These four bits are reserved for future use, and must be zero.  As
>    with virtually every field,
--Snip--
Consider sect 4.4.1, SACK-permitted option length must be 2:  This 
forbids ever extending SACK by adding a subtype, for example to 
negotiate non-renege-able SACK, by putting a 1 in an optional sub-type 
carried in additional bytes in the SACK-permitted option.  As far as I 
know every implementation today correctly parses the option length (e.g. 
skips forward by the relevant amount), but ignores the option data, so 
such a change would be backwards compatible with all existing 
implementations.

Even though this is not the target audience, the mere existence  of 
these  documents increases the chances that some over eager firewall 
implementer will add the check to some future pix-bis-bis, and our 
ability to extend SACK might be gone forever.

>> The basic
>> point of view is that firewalls should discard all traffic bearing
>> features that are not explicitly permitted by todays standards.
>
> This document provides advice for host implementations, not for 
> firewalls.
>
Sorry, I didn't read the introduction.   But I would not assume that 
host implementors  would be the only readers.
>
>> I read all of 2 pages before I found something that, if significantly
>> deployed, would haunt some Internet users for a very very long time (p
>> 43, SACK resource exhaustion).
>
> I guess you are arguing against the proposed limit of 16 for the 
> maximum number of sack holes? I understand you could argue that this 
> value could/should be raised. However, IIRC I based my proposal on 
> existing data on the number of holes.
>
> FWIW, NetBSD and others already enforce limits for this. See
> the "net.inet.tcp.sack.maxholes" sysctl (which defaults to 32) in
> http://osdir.com/ml/netbsd.ports.x86-64/2006-05/txtdA8OHygdEK.txt
>
> You may even be more interested in the 
> "net.inet.tcp.sack.globalmaxholes", which defaults to 1024.
>
> Other systems (e.g., FreeBSD) already enforce limits, too.
>
> So... why instead of knocking the document down altogether, we discuss 
> e.g., whether the proper limit should be something else?
>
> I guess/hope you are not arguing against enforcing limits, but about 
> the specific value proposed in the I-D. And the reason for submiting 
> this I-D as a IETF I-D is exactly to discuss these issues and get 
> consensus on e.g., what the proper/safe value should be for this limit.
The current limits are workaround for using inappropriate algorithms for 
maintaining the  SACK scoreboard.   The easy way to implement the 
scoreboard has cost O(N^2).  However there is at least one OS that uses 
an O(N*ln(N)) scoreboard, and O(N) might be possible.  (These are the 
total cost of the worst case recovery at window size N, so O(N) total 
cost is constant cost per ACK.)

If you have a moderately fast continental  scale Ethernet (1500 Byte 
MTU, 1 Gb/s, 100 ms RTT), you need a window size of 9000-18000 
packets.    Slow start typically loses ever other or every third packet, 
so you might hypothetically need to recover from 3000 to 9000 holes 
following a slow-start.    Telling host implementers that they should 
limit the number of holes rather than investing in better algorithms is 
pushing them in the wrong direction.   Kludges in existing 
implementations, or arguments about typical users are no excuse to tell 
implementers that they should not do this correctly for all users, 
including users who need the very highest performance.

Here is a hint about RFC 2018 (which probably applies to many other 
RFCs):  Every single SHOULD is a clue that we knew of something that 
might be done better than permitted by the document at hand.   Going 
through a spec and "tightening" it, by changing SHOULDs into MUSTs, is 
guaranteed to close of opportunities for improvement (although  some 
might be closed already for other reasons).

>> And then all of us who think TCP might still be improved may as well
>> just go home and retire, because nothing that we want to try will be
>> permitted by standard conforming firewalls.
>>
>> No I really don't want to work on this document, but I am not ready to
>> retire yet, so I guess I will.
>
> Thanks.
>
>
>
>> Think of it a huge gray-matter tax imposed by one standards
>> organization on another.
>
> I really don't understand this statement. The only standard 
> organization involved in this is the IETF. UK CPNI is *NOT* a 
> standards organization (please see http://www.cpni.gov.uk)
Yes, but it issued a document full of advice to implementers, that has 
the potential to have lasting negative repercussions.  If they really 
are not high profile, then there is a chance that we can get away with 
just ignoring their report.

Once I have had time to actually read the whole thing, I will comment 
further.   (I am traveling for another couple of days).

Thanks,
--MM--