[LACNIC/Seguridad] [Fwd: Some comments on "Improving TCP security with robust cookies"]

[Fernando Gont]

Estimados,

Aqui va lo prometido (mi feedback sobre el articulo que aparecio en login;).


-------- Original Message --------
Subject: Some comments on "Improving TCP security with robust cookies"
Date: Sat, 05 Dec 2009 01:32:58 -0300
From: Fernando Gont <fernando en gont.com.ar>
To: namedroppers en ops.ietf.org
CC: perry en piermont.com,  William Allen Simpson
<william.allen.simpson en gmail.com>, vixie en isc.org

Hello, folks,

Here are some comments on the aforementioned publication:

> However, SYN cookies can only be used in emergencies; they are
> incompatible with most TCP options. As there is insufficient space in
>  the sequence number, the cookie is not considered cryptologically
> secure.

There was an idea by FreeBSD's Andre Opperman to use TCP timestamps to
store more bits for the cookies. That would make cookies more
TCP-options-friendly.


> TCPCT requires the TCP Timestamps Option [5], which in turn requires
>  Path MTU Discovery [24] and that the Don’t Fragment (DF) bit is
> always set in the IP header.

Do TCP timestamps really require PMTUD?


> Because of these deficiencies, SYN cookies were not accepted for
> publication in the Internet Engineering Task Force (IETF) RFC series
> until recently [7].

Sadly enough, I doubt that the reason for which TCP cookies had not
been published in the RFC series had to do with their technical
properties.  The IETF has largely ignored everything that has to do with
IP or TCP security. Well known issues such as IPv4 source routing have
not only been ignored, but later rehashed in "new" protocols (e.g., RHT0
in IPv6). As another example, it has taken us more than *five* years in
TCPM WG to publish something (draft-ietf-tcpm-icmp-attacks) to publish
something about the well-known ICMP attacks against TCP. And thanks to
some "bright" people, the document is heading for Informational (rather
than Std. track or BCP).

This situation has been one of the main motivations behind the project
on TCP and IP security I carried out on behalf of UK CPNI.

FWIW,
TCP security:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
IP security: http://www.cpni.gov.uk/Docs/InternetProtocol.pdf


> TCP Cookie Transactions (TCPCT) bolster the defense against such
> attacks. A cookie option is exchanged as the connection is opened.
> These cookies are larger and more unpredictable than addresses,
> ports, sequence numbers, and timestamps. They validate the connection
>  between two parties.

While port numbers, sequence numbers, timestamps, etc., *are*
predictable in many implementations, they need not be so. In general,
RFC1948-like schemes should be applied to all these fields.


> A closed TCP port must not be reused until a (TCP TIME-WAIT) timeout
> period has expired. If old port numbers are recycled too quickly,
> messages intended for the closed session cannot be distinguished from
> a newly opened session, appearing to be delayed duplicate
> transmissions.

This can be avoided if proper algorithms for selecting TCP sequence
numbers and TCP timestamps are in place. See, e.g.,
http://tools.ietf.org/html/draft-gont-tcpm-tcp-timestamps-02.txt

Note: Figure 1 in your document is incorrect. Only the end-point
performing the active close (i.e., starting the connection-termination
phase) will remain in the TIME-WAIT state. The only scenario in which
both endpoints remain in the TIME-WAIT state is that of "simultaneous
close", which is generally unlikely.

As a meta comment, I'd like to see more details about TCPCT... like a
draft specification, or something.

Thanks!

Kind regards,
---- fin del mensaje original ----

Saludos cordiales,
-- 
Fernando Gont
e-mail: fernando en gont.com.ar || fgont en acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1