Cisco's Statement about IPR Claimed in draft-ietf-tcpm-tcpsecure

Thu May 13 18:23:05 UTC 2004

On Thu, 13 May 2004, Iljitsch van Beijnum wrote:

: Guess what, they call them drafts because they're not finished yet. So
: why don't you say something to the author?

I did exactly this earlier today.  I don't necessarily expect action on it,
considering that the vendor in question does not currently implement
randomness in all appropriate places.  But I retain hope.  8-)

: I don't think you can fully randomize the source port as it might clash
: with well-known ports.

Which is why I say "14 bits":  you can get away with at least a quarter of
the 65536-port range.  Most systems can get about 15.5 bits' worth of
entropy with reasonable randomness diversity, without trampling well known
service ports.

: Also, it may be somewhat expensive to make ports truly random.

arc4random() is cheap even on m68k's (read: "really old Cisco 25xx's"), only
needed when initiating TCP sessions, and it's even more secure if it's fed
just a teensy bit of real-world entropy now and then to stir its pot.
These days it's a security risk /not/ to make use of randomness if you
otherwise could -- and not just for the attack vector presented in this I-D.

: But why are you assuming the window size is 64k?

The draft's assumption is such, and it's in the bit-vicinity of common TCP
stack defaults.  With smaller window sizes, you of course get even better
connection security -- something that might be worth mentioning on its own,
elsewhere in the document.

: > How many zombies would it take to search the port number space
: > exhaustively?
:
: How many route processors does it take to look at the packets from all
: those zombies? This very quickly becomes a DoS against the route
: processor rather than a TCP exploit.

Exactly; once the attack requires more packets (due to more guessed bits)
than the CPU can handle, the "TCP attack" part becomes pretty much moot.

-- 
-- Todd Vierling <tv at duh.org> <tv at pobox.com>