Subject: [dnsext] Some comments on "Improving TCP security with robust cookies"

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Dec 2009 01:32:58 -0300

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,
- --
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: William Allen Simpson <[email-masked]>
Date: Sat, 05 Dec 2009 07:24:05 -0500

> Here are some comments on the aforementioned publication:
Nice to know Usenix ;Login: is winging its way to subscribers....

> store more bits for the cookies. That would make cookies more
That was implemented in many TCP stacks, and only gives you timestamps --
not SACK, nor the new "TCP User Timeout Option", nor anything else.

Syn cookies were clever, and marginally better than nothing, but not as
useful as a new option.

> Do TCP timestamps really require PMTUD?
Yes, please re-read the specification.

> IP or TCP security.

The official reason was the technical properties.  But you're preaching to
the choir here.

I still remember when Steve Kent refused to allow IP security to have a
BOF (let alone Working Group).  Karn held the BOF anyway in my hotel room
at IETF San Diego, and at successive lunch meetings.  Karn et alia
published via Usenix, too....

I still remember when somebody from Boston with a four (4) character last
name got the FBI to investigate me for *treason*, for presenting PPP CHAP
at IETF Santa Fe (a meeting with foreign nationals).

I still remember Perry calling me this time of the year in 1994, asking me
to write IPsec for IPv4.  I started (with permission) from drafty drafts
for IPv6 by Atkinson.  I created "SPI"es, and "transforms", and much of
the framework we have today.

> Well known issues such as IPv4 source routing have
> in IPv6).

Hey, you don't need to tell me, none of that was in the original IPv6.
You may have forgotten that I was a member of the original design team.

> As another example, it has taken us more than *five* years in
Yes, there's a very good practical reason for not going through TCPM WG.

> IP security: http://www.cpni.gov.uk/Docs/InternetProtocol.pdf
We thank you, and reference your paper.

> RFC1948-like schemes should be applied to all these fields.
That's true.  But in the reality-based community, that hasn't happened.

This option signals that *has* happened, because it's a requirement of
the specification.

> http://tools.ietf.org/html/draft-gont-tcpm-tcp-timestamps-02.txt
I'm on the TCPM mailing list, and even before that have been on the
TSVWG mailing list (since its inception).  I've read various drafts.

> close", which is generally unlikely.
Interesting comment.  But in the reality-based community, that's not how
folks have implemented.

This option signals that *has* happened, because it's a requirement of
the specification.

> draft specification, or something.
The first 5 drafty drafts were completed last August among a select group
of implementors.  The last time that I tried to submit to internet-drafts,
it was closed for IETF.  Since there's renewed interest, I'll spin another
draft this weekend.

The first experimental code should be in the next Linux release, but it's
incomplete due to great difficulty working through their arcane process.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Dec 2009 05:18:53 -0300

Hello, William,

Thanks for your response. Comments inline...

> Nice to know Usenix ;Login: is winging its way to subscribers....

Well, Paul Vixie announced the paper on the mailing list ;-) (namedroppers)

> not SACK, nor the new "TCP User Timeout Option", nor anything else.

No. It gives you timestamps, SACK, wscale, and more. See
http://www.ietf.org/mail-archive/web/tcpm/current/msg02251.html

> Syn cookies were clever, and marginally better than nothing, but not as

I still want to take a look at the draft TCPCT spec.

> Yes, please re-read the specification.

Implementation of PMTUD is "required" in the upcoming rev of rfc1323,
but not in RFC 1323 itself. -- hence my comment. (I had not checked the
aforementioned I-D)

> BOF (let alone Working Group).

And the reason for that was....?

> Hey, you don't need to tell me, none of that was in the original IPv6.

Overall, part of my feedback was meant as comments to the list... (i.e.,
I did not assume any of the above was "new" to you).

> We thank you, and reference your paper.

Yes, and thanks for that. Again, this one was input to the list, rather
than the authors of the "robust cookies" paper.

> That's true.  But in the reality-based community, that hasn't happened.

I'd say most implementations randomize their ephemeral ports. I would
say most randomize their sequence numbers, too. Some (e.g. OpenBSD)
randomize the timestamps, too.

> Interesting comment.  But in the reality-based community, that's not how

Are you implying that in mosts stacks, both end-points of the connection
end up in the TIME-WAIT state?

> it was closed for IETF.  Since there's renewed interest, I'll spin another

I look forward to it.

> incomplete due to great difficulty working through their arcane process.

Is it available online?

Thanks!

Kind regards,
-- 
Fernando Gont

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 09 Dec 2009 16:15:13 -0500

> http://www.ietf.org/mail-archive/web/tcpm/current/msg02251.html
Thanks for the link, I'd forgotten that old TCPM message.  Looks like
FreeBSD has done more than others.  With a secret rotation and 2 secrets!
Cool.  I've only just begun to learn about Linux kernel code, and they
have a constant secret initialized during startup (weak).  They still use
system time for initial sequence numbers, etc.  Fairly predictable.

> but not in RFC 1323 itself. -- hence my comment. (I had not checked the
It's been so long since I've read RFC1323.  RFC1323bis is yet another
reason not to go through the TCPM WG -- how many years has it been, and
still not published?  Sheesh!

> And the reason for that was....?
Unknown for certain.  All we know is that he's probably the male mentioned
in my FBI file who's reporting to some "Other Agency" (likely, NSA) that
refused to declassify major portions of my FBI file.

   "Sources whose identities are concealed herein have furnished
   reliable information in the past except when otherwise noted."

My FBI file also indicates that they sent agents to infiltrate the IETF.

We *do* know Kent required the removal of the PPP LCP encryption option,
refused to publish PPP CHAP, and refused to grant the IPSec charter....
When the NomCom replaced the IAB, he was first against the wall.  Then,
we published all of those things.

> randomize the timestamps, too.
Not Linux.  There are a fair number more Linux installations than OpenBSD.
We should get more OpenBSD practices into other platforms.

IIRC, RFC1323bis requires a random "offset" for timestamps.

>> incomplete due to great difficulty working through their arcane process.
The usual places:

   git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Dec 2009 18:31:25 -0300

William Allen Simpson wrote:

> Cool.  

I'm not sure they ended up comitting to the FreeBSD kernel, or was
actually included in Oppermann's rewritten-from-scratch TCP/IP stack
code (that would eventually replace the tradicional TCP/IP code in FreeBSD).

> I've only just begun to learn about Linux kernel code, and they

Wow. I will check the code. I thought (and expected) they were doing better.

They do randomiza port numbers, though. IIRC, they implement the
simple-hash based algorithm we proposed in
draft-ietf-tsvwg-port-randomization

> still not published?  Sheesh!

It usually takes 4+ years to publish a document within TCPM (there have
been some exceptions, though).

> My FBI file also indicates that they sent agents to infiltrate the IETF.

And your crime was... advocating the use of crypto?

> We should get more OpenBSD practices into other platforms.

I fully agree.

> IIRC, RFC1323bis requires a random "offset" for timestamps.

It probably does (this was in response of
draft-gont-tcpm-tcp-timestamps, which has been stalled for a year or so....)

Thanks,

---

From: Danny Mayer <[email-masked]>
Date: Mon, 14 Dec 2009 08:54:06 -0500

> system time for initial sequence numbers, etc.  Fairly predictable.

Well that gets really interesting because you won't have started ntpd to
synchronize the system clock since it has to wait for the IP stack to be
available. So what system time is "used" is somewhat unpredictable. I
guess there's some randomness in that!

>> randomize the timestamps, too.

After or before the system time is synchronized?

Danny

>   git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.