OpenBSD Journal

Cisco claiming patents on TCP - Goodbye Free Network Stacks.

Contributed by grey on from the apparently only Cisco can secure TCP, so pay up! News at 11 dept.

Thanks to Bob Beck who writes:

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 Barr 

Cisco 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)


Comments
  1. By Anonymous Coward (67.70.164.207) on

    WTF is up with the IETF? Cisco makes me sick too.

    Comments
    1. By Anonymous Cheese (68.124.163.80) on

      The IETF board is driven by a majority of Suits now-a-days.

    2. By Tony S (217.215.183.53) on

      This situation is unfortunate, but if Cisco hadn't done this someone else would have. Would it please you better if Microsoft, or even SCO had claimed the patent instead ?

      Comments
      1. By Daniel Hartmeier (195.234.187.87) daniel@benzedrine.cx on

        No, what would please me better would be Cisco promptly implementing their suggestions in their own products instead of making patents their first priority, thereby establishing prior art and rendering any subsequent patents on the subject worthless.

        Oh, and had their primary focus been proper implementation, maybe their customers wouldn't still be standing in the rain.

        Comments
        1. By Tony S (217.215.183.53) on

          This is true. And I am still standing in the rain, and from where I'm standing there is currently more than one storm.

          Comments
          1. By Anonymous Coward (67.70.164.207) on

            Rather than UPS you an umbrella, I'll send you a couple tarps.

            Comments
            1. By Anonymous Coward (204.174.61.214) on

              Don't you mean "a couple of CARPs"?

  2. By Anthony (68.145.111.134) on

    Just saw on misc@, Theo's asking for T1 and T3 PCI hardware docs. Apparently with the goal of replacing cisco in most situations.

    Comments
    1. By Anonymous Coward (67.70.164.207) on

      w00t! Sounds like some really good and fun stuff is going to start happening.

    2. By Anonymous Coward (67.70.164.207) on

      Do you know the subject line? I can't seem to find it on http://www.sigmasoft.com/~openbsd/archive/openbsd-misc/200405/ Thx.

      Comments
      1. By grey (64.139.7.172) on

        Try:

        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
        1. By Anonymous Coward (67.70.164.207) on

          Awesome! I really like what he's got in mind... I love OpenBSD! I agree with you on the switches part, would be nice...

        2. By Anonymous Coward (209.162.224.7) on

          You really can't replace switches with off the shelf hardware and a general purpose OS. You need huge internal bandwidth, switches are designed specifically with this in mind. And a general purpose OS just adds far too much overhead. In theory, you could make a switch on a pci card, and have all the work done on the card, and the OS is just used to configure it/report interface info, etc. Doesn't seem likely anyone will make them though, since the cost would be pretty much the same as just making a normal switch.

          Comments
          1. By Anonymous Coward (67.70.164.207) on

            I think Theo's goal is now replacing Cisco PIX, Routers and WAN connectivity where applicable. Correct me if I'm wrong though.

            Comments
            1. By Anonymous Coward (209.162.224.7) on

              Theo does want to replace ciscos as routers. The person I was replying to wanted to see replacements for switches. I was explaining why that isn't likely to happen.

              Comments
              1. By Anonymous Coward (67.70.164.207) on

                Sorry, I didn't mean it the way you read it. But, I do see your point... Thanks for the post though. Regards.

        3. Comments
          1. By mirabile (212.185.103.56) on

            They're allowing for GPL-only things, which is not bad per se, but worse, their documentation is GFDL-licenced, which is REALLY REALLY bad.

            Comments
            1. By Lennie (82.74.129.164) on

              I can imagine the OpenBDS people to be against that.

          2. By Anonymous Coward (131.130.1.150) on

            Wow, the idea of using a FPGA for packet filtering is cute, in my opinion :)

    3. By kris (66.236.9.30) on

      I have a couple Sangoma cards. I spoke with Theo last night, as well as Sangoma. Sangoma has the source available for their Wanpipe cards. I received an email back from them today about hardware donations, and they offered a discount, but I am trying to talk them into FREE hardware, after all, they are trying to push Cisco out of the market as well, and this will help them do so.

      Comments
      1. By kris (66.236.9.30) on

        I got in contact with Sangoma, and the sales rep, Doug (awesome guy) offered to donate 5 or 6 T1 cards to the OpenBSD project. http://www.sangoma.com, the company donating to the project, is trying to expand its support into the BSD system, and what perfect timing this is!

        Comments
        1. By Anonymous Coward (162.83.93.12) on

          What about detailed hardware docs? Sangoma has this very wierd driver kit, which if I'm not mistaken has supported OpenBSD for a while, but still does everything Sangoma's way. Contrast with the LMC cards which are quite well supported out of the box on OpenBSD and work pretty much like a normal BSD if.

          Comments
          1. By kris (66.236.9.30) on

            Straight from Dougs email to me, he states: "As things stand right now, we already provide source code for our cards to work with OpenBSD, FreeBSD, and Linux.". When I spoke with Doug, he agreed that Sangoma wants to expands to BSD and would do what they could to help out. I do not foresee this being a problem.

            Comments
            1. By Anonymous Coward (67.70.164.207) on

              Who wrote the source code drivers for them? Them? If so, wouldn't detailed docs be better than source code that someone else made? I'm not putting this or you down, I think it's great of you to do this and my thanks to you for helping give to the OpenBSD community as a whole. Regards.

              Comments
              1. By kris (66.236.9.30) on

                I agree completely. When I spoke with Doug (hes the rep, not the coder/engineer), I told him if OpenBSD began to natively support it, it would be coded from the ground up, and many people would probably work on it. If we can get others, like LMC then by all means, the more the better. Just doing my part :)

        2. By mike (217.162.10.167) on

          while they're at it, perhaps they could throw in a couple of PCI ADSL cards too? it would be nice to have a complete range of connectivity options supported out of the box... in any case, well done!

          Comments
          1. By Anonymous Coward (4.16.136.107) on

            Get them docs and hardware, and they'll do amazing things. ;)

  3. 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
    1. By Daniel Hartmeier (62.65.145.30) on

      That's just one of the several changes suggested. Compare the others to what has been in the tree for a long time and what was commited recently. For instance, sequence numbers must match precisely (not just fall within a window) in some cases, with OpenBSD. They couldn't very well suggest and patent source port randomization, because there is prior art, of course. If you consider the differences small, the entire suggested changes aren't very broad, to start with.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]