Cisco's Statement about IPR Claimed in draft-ietf-tcpm-tcpsecure
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 From: Robert Barr <rbarr@cisco.com> 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 On May 11, 2004, at 3:46 PM, David Krause wrote:
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 From: Robert Barr <rbarr@cisco.com>
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
On Tue, 11 May 2004, David Krause wrote: : 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: ===== this means that most connections (assuming the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). ===== (Burp. Pardon me for the half-censored expletive.) And exactly why are we supposed to assume that anyone can guess /both/ ports on any connection where the attacker is external? Oh, that's right, because we're all paranoid and gun-shy. (This /is/ NANOG, after all. 8-) Sure, randomization doesn't help if someone netstat(8)s for connections while logged into a host, but reasonable admins shouldn't be letting unprivileged users see network info for critical services, or other users' connections for that matter. Read that as: "Don't make netstat setuid." Gimme a break. This text is a half-baked concoction at best if the next draft still doesn't mention port randomization as a cheap and effective mitigator for external attack attempts. You can get at least 14 bits of entropy for one lousy arc4random() call. Enter as often as you like. No purchase required. 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. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
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
On Wed, 12 May 2004 21:51:53 EDT, Todd Vierling <tv@duh.org> said:
Gimme a break. This text is a half-baked concoction at best if the next draft still doesn't mention port randomization as a cheap and effective mitigator for external attack attempts. You can get at least 14 bits of entropy for one lousy arc4random() call. Enter as often as you like. No purchase required.
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.
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
On Thu, 13 May 2004 Valdis.Kletnieks@vt.edu wrote: : 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.) -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
On 13-mei-04, at 19:07, Todd Vierling wrote:
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.
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@duh.org> <tv@pobox.com>
* 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... -- Henning Brauer, BS Web Services, http://bsws.de hb@bsws.de - henning@openbsd.org Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
In message <Pine.NEB.4.58.0405122134560.9034@server.duh.org>, Todd Vierling wri tes:
On Tue, 11 May 2004, David Krause wrote:
: 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?
How many zombies would it take to search the port number space exhaustively? --Steve Bellovin, http://www.research.att.com/~smb
On May 13, 2004, at 1:48 PM, Steven M. Bellovin wrote:
In message <Pine.NEB.4.58.0405122134560.9034@server.duh.org>, Todd Vierling wri tes:
On Tue, 11 May 2004, David Krause wrote:
: 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?
How many zombies would it take to search the port number space exhaustively?
Irrelevant. The limiting factor here is how many packets can make it to the CPU. Using 10K pps as a nice round (and high) figure, a single machine can do that. Also, many of the calculations I've seen assume much higher pps when calculating time to reset a session. Has anyone done a test to see what a Juniper M5/10/whatever and a GSR can actually take without dropping packets due to rate limiting and/or falling over from being packeted? -- TTFN, patrick
The same document that fully ignores that port number randomness will severely limit the risk of susceptibility to such an attack?
How many zombies would it take to search the port number space exhaustively?
Irrelevant.
The limiting factor here is how many packets can make it to the CPU. Using 10K pps as a nice round (and high) figure, a single machine can do that.
Also, many of the calculations I've seen assume much higher pps when calculating time to reset a session. Has anyone done a test to see what a Juniper M5/10/whatever and a GSR can actually take without dropping packets due to rate limiting and/or falling over from being packeted?
In some fairly informal tests that I did with an M20/RE3, I had to saturate the PFE <-> RE link (100Mbps) with packets destined to the RE before routing adjacencies started flapping. Packet size (64-1518 bytes) didn't make much of a difference (larger packets seemed to make things a bit more difficult for the routing protocols), and CPU usage on the RE rarely went above 30% during any test. Streams were sent from random source addresses. Packets that elicited a response from the RE (e.g., pings) didn't appear to have a greater effect on performance than ones that didn't, as there appears to be a good amount of rate-limiting going on internally to keep things reasonably calm. It's documented that pings to the RE are limited to 1000/sec, but it also appears that other packet types such as SYNs are rate-limited in some fashion, either the ingress packets themselves or maybe the responses from the RE. But in any case, whatever rate-limiting was going on didn't appear to be affecting routing adjacencies. Although I didn't try anything too fancy, it appears that it's pretty difficult to bog down the CPU (a PIII 600) on an RE3. Routing adjacencies were only affected with the PFE <-> RE link became saturated, which isn't surprising. There was no indication of transit traffic being affected, which also isn't surprising given that such packets are handled by ASICs. -Terry
On 13-mei-04, at 19:48, Steven M. Bellovin wrote:
The same document that fully ignores that port number randomness will severely limit the risk of susceptibility to such an attack?
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.
participants (10)
-
David Krause -
Henning Brauer -
Iljitsch van Beijnum -
Patrick W.Gilmore -
Peter Galbavy -
Steven M. Bellovin -
Terry Baranski -
Todd Vierling -
Tony Li -
Valdis.Kletnieks＠vt.edu