Looks like Cisco is now trying to patent security....
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt
Title: Cisco's Statement about IPR Claimed in draft-ietf-tcpm-tcpsecure
Received: April 26, 2004
Cisco is the owner of one or more pending patent applications relating to
the subject matter of "Transmission Control Protocol security
considerations" <draft-ietf-tcpm-tcpsecure-00.txt>. If technology in this
document is included in a standard adopted by IETF and any claims of any
Cisco patents are necessary for practicing the standard, any party will be
able to obtain a license from Cisco to use any such patent claims under
reasonable, non-discriminatory terms, with reciprocity, to implement and
fully comply with the standard.
For information contact:
Robert Barr
Worldwide Patent Counsel
Cisco Systems
408-525-9706
rbarr@cisco.com
What's very amusing is reading section 5 of the draft, wherein the author
distributes credit to a number of parties. If Cisco were to file a patent
at this point and not include those parties (including other companies),
the patent validity would be at risk by reason of excluding a contributor.
If Cisco does include all of those other companies in the patent, then all of
them must also present the IETF with relevant IPR statements.
Frankly, this is yet another PR blunder by Cisco. If they had simply said
nothing or formally put their contribution into the public domain, they wouldn't
look so egregiously greedy.
Tony
: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt
The same document that fully ignores that port number randomness will
severely limit the risk of susceptibility to such an attack? S**t, the only
mention of port numbers at all is in the following text snippet:
Todd Vierling wrote:
With this and the patent funny business, I don't know if I can roll
my eyes any further into the back of my head.
I dunno, but perhaps there is a (new) policy of applying for a patent for
every bug fix or code change in IOS - just in case the incompetent USPTO
grants one in a thousand out of boredom.
Peter
Well.. you have to remember that we live in an environment where people
are *just* noticing that RFC793 says "The RST has to be in the window,
not dead on"... and apparently overnight somebody has re-discovered the
fact that CSMA/CA networks will fall over if somebody starts jabbering:
http://www.auscert.org.au/render.html?it=4091
: Well.. you have to remember that we live in an environment where people
: are *just* noticing that RFC793 says "The RST has to be in the window,
: not dead on".
Right, and 32 - <window bits> + <random port bits> in a /reasonable/
implementation totals at least 28 [bits that must be guessed by the
attacker].
Whereas the Internet-Draft claims, by assuming that both source and dest
ports are knowns, the number of bits required for the attack is 16 (or even
lower) and thus can cause connection resets "even at DSL speed."
A 2^[28..33] problem is much more difficult to attack than a 2^[14..16]
problem. It's amazing that such a cheap source of entropy -- randomizing
the source port appropriately -- is being so readily discounted.
(In case you're curious, 2^33 is achievable for things like BGP, where it's
not certain which end initiated the connection. You get one extra bit for
the originator choice, on top of a fully randomized 16-bit port and a 16-bit
window size: 2^33.)
Whereas the Internet-Draft claims, by assuming that both source and dest
ports are knowns, the number of bits required for the attack is 16 (or even
lower) and thus can cause connection resets "even at DSL speed."
Guess what, they call them drafts because they're not finished yet. So why don't you say something to the author?
A 2^[28..33] problem is much more difficult to attack than a 2^[14..16]
problem. It's amazing that such a cheap source of entropy -- randomizing
the source port appropriately -- is being so readily discounted.
(In case you're curious, 2^33 is achievable for things like BGP, where it's
not certain which end initiated the connection. You get one extra bit for
the originator choice, on top of a fully randomized 16-bit port and a 16-bit
window size: 2^33.)
I don't think you can fully randomize the source port as it might clash with well-known ports. Also, it may be somewhat expensive to make ports truly random. (But not as expensive as doing MD5 for the whole session.)
But why are you assuming the window size is 64k? This is completely unnecessary, and not done in practice by "real" routers: those typically use a 16k window. It should even be possible to set the window to a very small size, such as 64 bytes. That's enough to receive the initial BGP header, after which the window can be set to a larger size until the session is idle again.
: 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. 
: 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.
* Iljitsch van Beijnum <iljitsch@muada.com> [2004-05-13 19:52]:
I don't think you can fully randomize the source port as it might clash
with well-known ports.
of course. 1024 - 49151, on OpenBSD.
Also, it may be somewhat expensive to make ports
truly random. (But not as expensive as doing MD5 for the whole
session.)
We have randomized src ports in OpenBSD since 1996 - on all platforms,
including vax and such. No, it is not expensive.
But why are you assuming the window size is 64k? This is completely
unnecessary, and not done in practice by "real" routers: those
typically use a 16k window. It should even be possible to set the
window to a very small size, such as 64 bytes. That's enough to receive
the initial BGP header, after which the window can be set to a larger
size until the session is idle again.
In OpenBSD's bgpd, we only scale the window up of md5sig or ipsec is in
use...