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

[Fernando Gont <[e-mail]>]

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, the Reserved field could be used as a
    covert channel.  While there exist intermediate devices such as
    protocol scrubbers that clear these bits, and firewalls that drop/
    reject segments with any of these bits set, these devices should
    consider the impact of these policies on TCP interoperability.  For
    example, as TCP continues to evolve, all or part of the bits in the
    Reserved field could be used to implement some new functionality.  If
    some middle-box or end-system implementation were to drop a TCP
    segment merely because some of these bits are not set to zero,
    interoperability problems would arise.

    Therefore, we recommend implementations to simply ignore the Reserved
    field."



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



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



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

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