Contributed by grey on from the apparently only Cisco can secure TCP, so pay up! News at 11 dept.
Looks like cisco is trying to bend everyone over a barrel again like they did for VRRP - except now with TCP, by hijacking the new IETF process to work on TCP issues. Good way to ensure that everyone can't implement compatible standards, since free software implementors will not be able to implement this. When will people learn that RAND == NO FREE SOFTWARE. Of course, for all we know the applied patents are for Cat Detector vans, so you have no idea if this is even relevant.
Message from good old Robert Barr at cisco is here: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt
An additional write up with responses from Theo de Raadt can be found at at KernelTrap here: http://kerneltrap.org/node/view/3085
The complete statement from Cisco reads:
Title: Cisco's Statement about IPR Claimed in draft-ietf-tcpm-tcpsecure Received: April 26, 2004 From: Robert BarrCisco is the owner of one or more pending patent applications relating to the subject matter of "Transmission Control Protocol security considerations" . 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
(Comments are closed)
By Anonymous Coward (67.70.164.207) on
Comments
By Anonymous Cheese (68.124.163.80) on
By Tony S (217.215.183.53) on
Comments
By Daniel Hartmeier (195.234.187.87) daniel@benzedrine.cx on
Oh, and had their primary focus been proper implementation, maybe their customers wouldn't still be standing in the rain.
Comments
By Tony S (217.215.183.53) on
Comments
By Anonymous Coward (67.70.164.207) on
Comments
By Anonymous Coward (204.174.61.214) on
By Anthony (68.145.111.134) on
Comments
By Anonymous Coward (67.70.164.207) on
By Anonymous Coward (67.70.164.207) on
Comments
By grey (64.139.7.172) on
http://marc.theaimsgroup.com/?l=openbsd-misc&m=108431516706763&w=2
and for the mention about the E1/T1 and E3/T3 cards check:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=108432660625483&w=2
That said, there are always commercial alternatives to Cisco in pretty much every space they play in (e.g. Juniper, Extreme, Enterasys). E1/T1 E3/T3 pci cards probably won't be impossible to find, and I can't remember the name of the project, but I even saw PCI-based OC3 & OC12 cards that were developed at a university with NetBSD (googling isn't turning up what I'm recalling so maybe the details are wrong). So, as far as getting hardware that one could use with *BSD or Linux for WAN links, that probably isn't too tough.
On the other hand, find me gear that could replace core switches with something like *BSD and Linux and I would be impressed. (e.g. minimum 48 10/100 ports in 1U of rackspace, though some extreme switches now offer 48 10/100/1000 ports + 10gigE uplinks).
Comments
By Anonymous Coward (67.70.164.207) on
By Anonymous Coward (209.162.224.7) on
Comments
By Anonymous Coward (67.70.164.207) on
Comments
By Anonymous Coward (209.162.224.7) on
Comments
By Anonymous Coward (67.70.164.207) on
By Lennie (82.74.129.164) on
Comments
By mirabile (212.185.103.56) on
Comments
By Lennie (82.74.129.164) on
By Anonymous Coward (131.130.1.150) on
By kris (66.236.9.30) on
Comments
By kris (66.236.9.30) on
Comments
By Anonymous Coward (162.83.93.12) on
Comments
By kris (66.236.9.30) on
Comments
By Anonymous Coward (67.70.164.207) on
Comments
By kris (66.236.9.30) on
By mike (217.162.10.167) on
Comments
By Anonymous Coward (4.16.136.107) on
By krh (207.75.181.178) on
So I read the patch listed on the errata page. As far as I can tell, it changes OpenBSD's behavior when receiving in-window SYNs from sending RSTs to ACKs with the additional fix of rate-limiting the number of ACKs sent in response to in-window SYNs (to 100 per second). This is extremely close to the IETF recommendation; the differences that I can see are the rate-limited ACKs (which is a very, very good thing) and not subtracting one from the sequence number if RCV.NXT == SEG.SEQ (which I'm not sure about; I'm not a TCP guru, but as far as I can tell the IETF recommendation is probably the right thing here, even though it looks a little bizarre).
Now, the way it sounded to me before was that OpenBSD was doing something significantly different from the IETF recommendation, but as I read the code, that's not the case. Am I making a mistake here?
Comments
By Daniel Hartmeier (62.65.145.30) on