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

[Fernando Gont <[e-mail]>]

Matt Mathis wrote:

>> 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.  

Are you sure this would ever work regardless of the advice we are 
giving? I could check if you want, but I bet most stacks have been 
performing this type of checks for quite some time now.

Also, why not using a different option type for that?



> 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.

I will check this and come back to you.




>>> 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.
[....]
>> 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.

It's more than that. If you don't enforce any limits, you could get a 
system to commit lots of memory for the scoreboard. Not enforcing limits 
is a highway to buffer overflows and other type of attacks. You must 
impose *some* limit.



> 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.)

Could you provide details of the algorithms you mention, references, etc.?



> 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.   

As I mentioned above, as a general rule to security problems, you need 
to enforce limits. We can argue about the specific value, But I don't 
think you'd want any data structure to be able to grow without bounds 
these days. You recommend this, somebody implements it, and the next day 
you have the attack tool posted on bugtraq.



> 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.

Nobody had brought up this issue of the algorithm. And, again, the 
reason for publishing the I-D was to provide the means to discuss this 
stuff within the IETF. If there's anything that can be improved, I'd be 
happy to do it.




> 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).

In this particular case, we didn't change any SHOULD into a MUST. The 
only reference to the option length in RFC 2018 is in the option figure.



>> 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.

I don't really know what "high profile" is supposed to mean. The 
motivation for producing this document is explained in the 
Preface/Introduction of the document. This type of document clearly has 
an impact on implementations, because it provides help to developers 
that before this document was only available (if anything) by going 
through the 100+ papers referenced in this I-D. Many developers have 
payed attention to this document.

We have been in very close contact with the developer community of a 
number of operating systems, and the document was very welcome. It was 
felt that such a document was needed. And many of them are working on 
document.

The motivation for bringing this document to the IETF was to further 
polish the document, and give the IETF the chance to publish something 
on these issues. Even for things like "SYN floods" or "ICMP attacks", 
the IETF has provided advice/discussion at least ten or twenty years 
*later* from when many implementations had to do something about it.

There's too much stuff that an implementer of TCP has to figure out by 
himself. And many of the problems that have been found in real 
implementations have to do with that. This document simply tries to 
change that state of affairs.

Think about any TCP vulnerability that has ever been discussed in, say, 
bugtraq or full-disclosure, and I bet at least 95% have been ignored by 
the IETF (or put another way, nothing was published about them). This is 
not good.


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

Thanks!

I look forward to your feedback.

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1