IPFilter Infriging on Bay Network Patent?

jorhan writes "Darren Reed, the author of IPFilter, recently posted this message to the IPFilter mailing list. Apparently IPFilter may infringe upon USA patents owned by Bay Networks, specifically, #5790554. The patent might seem to own just about every conceivable way one might wish to filter and forward data packets, but trying to read through all of the "wherein said first condition" started to give me a headache (ObIANAL). But when you read what application the authors specifically had in mind, it really has little to do with network layer firewalling. Even more important is the question Darren's mail indirectly poses, "Anyone know of any prior art?""

Comments

found

[Anonymous Coward]

I believe the drawbridge software well predates this (1993?) and darren is now aware of it.

But does Bay actually really exist anymore? Nortel sucked up them (after they had sucked up Annex). Getting updates for Annex is a bear. Bay was sort of sinking beneath the relentless Cisco; getting bought by a telco wasn't going to make them more agile.

No red alert yet.

[darkonc]

This isn't a serious lawyer-cease-and-desist type of situation. It's just someone bringing up the possibility that an old patent infringes, and noting that the probability is that it does not .. ianal/ymmv.

It'd be nice if someone had a few thousand dollars to hire a lawyer and get a more definitive answer, but it seems like prior art was also mentioned in the (two message) thread, so this isn't (yet) a serious issue.

The patent seems to only apply if you use numeric offsets into fields. If the patent is an intent to patent just about any rule-based firewalling, just about any commercial firewall product -- like FW1 product for Solaris would be simple examples of prior art. If this isn't the case, then it's got too many differences between itself and IPFilter or IPtables to be of much use in shutting down the IPfilter project.

One Example of Prior Art

[llywrch]

This patent claim was filed 4 October 1995.

I have a first edition copy of the book, D. Brent Chapman & Elizabeth D. Zwicky, _Building Internet Firewalls_ (Sevastopol, California: O'Reilly and Associates), dated September 1995. Thumbing thru it, I find chapter 6, which is titled ``Packet Filtering". ISTR that September is the month that preceeds October.

Since it takes about a year for a book to go from start of writing, thru production & at last release, I'd say Packet Filtering was a technology very familiar if not much used in late 1994.

Is that satisfactory evidence of prior art?

Geoff

PF (OpenBSD's) might also be affected

[norwoodites]

read http://marc.theaimsgroup.com/?l=openbsd-misc&m=102 663216302242&w=2

but in the thread it talks about a prior art, the main writer of OpenBSD's PF mentioned a prior art: http://marc.theaimsgroup.com/?l=openbsd-misc&m=102 665630513591&w=2

OpenBSD pf and the solutions

[mirabilos]

Darren Reed also asked in the OpenBSD misc mailing list
for prior art and points to pf probably being affected,
too (read here).

Daniel Hartmeier, swiss Author of PF, the OpenBSD packet
filter, has a good reply finding prior art and Darren even thanks him explicitly a lot, which is not what we _were_ used to read from him.

I personally do not have any objections against him,
still - though I use pf as it is in OpenBSD - the operating system of my choice, and not
even the recent OpenSSH bug could prevent me from
trusting that team.

Re:Not one reference to Linux

[petong]

iptables is the userspace tool that uses netfilter, not IPfilter.

Re:It doesn't seem to directly apply to IPFilter..

[wilko11]

The patent actually acknowledges that there is "related art" in the are of packet filtering. This patent claims four improvements:

• Directing data to multiple ports (obviously very oriented towards LAN switching)
• Filtering on variable length fields
• Jumping between rules rather than sequential processing
• Less than/greater than comparisons in addition to equals/not equals

I am not too familiar with IPFilter, but a quick read of the web page indicates that it doesn't support these features, although NAT may come close in some ways to the first (IANAL).

I also suspect that some bigger fish, such as Cisco, may infringe on this patent if IPFilter does

Here are the relevent piecesof the related art section:

prior art techniques also allow filtering on an arbitrary offset within a packet. However, these techniques do not allow filtering on the contents of well known variable length fields, e.g., the routing information field (RIF) of an IEEE 802.5 token ring data packet.

Prior art filtering mechanisms allow for the application of multiple filters to the same data packet; however, the filters are applied in sequential order--no skipping to other filters is allowed. As soon as a match is found, no further filters are considered and the packet is processed according to the filter for which a match occurred. The only processing provided is to either permit the packet to be forwarded or drop the packet. There is no mechanism by which the data packet may be redirected to a port of the network device other than the normal destination port to which the packet is forwarded in the absence of an access list or filter, nor is a packet redirected to multiple destination ports.

and

Moreover, a filter cannot jump to another filter, rather, filters are applied according to the order in which they are configured in the network device. Furthermore, prior art filtering systems do not allow forwarding of a data packet to an alternative port or an additional port. The packets may only be forwarded to the normal destination port or dropped. Finally, filters heretofore have only allowed the logical operators equal and not equal in determining whether a value specified by the filter matches or fails to match the contents of a data packet at the location in the packet specified by the filter. The additional logical operators of less than, less than or equal to, greater than, and greater than or equal to, have not been permissible

Patent acknowledges traditional patent filters

[werdna]

The patent specfification appears to expressly acknowledge that the prior art contains traditional patent filter firewalls, and seems to focus more on modes for redirecting packets based on a ruleset, rather than drop/pass decisions:

2. Description of the Related Art

A technique that has been employed by prior art network devices such as a LAN switch involves access lists, or filters, that allow the network administrator to control the forwarding of packets from a network device based upon the contents of the data packet. Such access lists allow a user to define a value within a specific field of a data packet. For example, to filter on an Internet protocol (IP) data packet with an IP address of 129.1.1.1, a user may configure and then apply to a particular port an access list that forwards or drops data packets having a value of 129.1.1.1 in the IP header of the data packet.

prior art techniques also allow filtering on an arbitrary offset within a packet. However, these techniques do not allow filtering on the contents of well known variable length fields, e.g., the routing information field (RIF) of an IEEE 802.5 token ring data packet.
Prior art filtering mechanisms allow for the application of multiple filters to the same data packet; however, the filters are applied in sequential order--no skipping to other filters is allowed. As soon as a match is found, no further filters are considered and the packet is processed according to the filter for which a match occurred. The only processing provided is to either permit the packet to be forwarded or drop the packet. There is no mechanism by which the data packet may be redirected to a port of the network device other than the normal destination port to which the packet is forwarded in the absence of an access list or filter, nor is a packet redirected to multiple destination ports.

There are a number of disadvantages to the above approach for controlling the flow of data packets in a network device. A network administrator must specify a well known field based on an access list type, i.e., the manager is not allowed to specify an arbitrary offset within the data packet at which to compare the contents of the data packet to a value specified by the filter. Moreover, a filter cannot jump to another filter, rather, filters are applied according to the order in which they are configured in the network device. Furthermore, prior art filtering systems do not allow forwarding of a data packet to an alternative port or an additional port. The packets may only be forwarded to the normal destination port or dropped. Finally, filters heretofore have only allowed the logical operators equal and not equal in determining whether a value specified by the filter matches or fails to match the contents of a data packet at the location in the packet specified by the filter. The additional logical operators of less than, less than or equal to, greater than, and greater than or equal to, have not been permissible.

Scary, isn't it.

[FreeLinux]

The patent is certainly valid but, don't panic just yet. This particular patent, though very general and broad scoped in nature, was actually filed to protect a very nice feature found in Bay / Nortel layer 2/3 and beyond switches. This feature has been in their switches since 1995 and possibly earlier and it allows for the routing/switching of packets based on a specified pattern match of ANY arbitrary portion of a FRAME. Note the specific reference to ATM?

Using this filtering method, you can switch/route a packet or frame from/to any port based on ANY part of the frame. If you wanted, for some bizzar reason, to make your decision based on the crc checksum you can do it. Also, because you are looking at the entire frame/packet, it is not specific to IP. You can filter/switch/route ANY protocol IP, IPX, HTTP, DECNet, APPN, anything. It is extraordinarily powerful, though infrequently used. But it is great to have when you need it. You can find it on most of their switches and routers from the BayStack 450 to the Bay BCN router to the Passport 8600 series layer 3 switches.

I do not feel that IPFilters needs to be concerned as this patent and could possibly be applied to ANY filtering tecnique in use today. Anything from MAC based port blocking to layer 7 web switching. However, even Bay/Nortel has notr choesen to challenge or attempt to enforce the patent on anyone so far.

As an interesting side note. Up until last year Nortel was filing and being awarded patents at a rate of two per day. They patented any and everything that they did. Hell, there is even a patent(not copyright) on a set of icons they designed for you on mobile phone type PDAs. That's right, a patent on a small set of crappy looking icons. Try doing a patent search with keyword Nortel. You'll be amazed.

Re:Not one reference to Linux

[Simon Garlick]

Netfilter = iptables.

Wakey wakey.

Re:Watch out for companies in trouble

[Xciton]

Not so fast.

Nortel (My employer) is doine MUCH better than what the media would let you beleive. There's a lot of BIG entities in the US that would like to see Nortel fail (need I mention any names??) Don't beleive everything you read/see.

Also, nowhere has Nortel issued any statement regarding this patent. Nortel hasn't said a word, so don't be putting up the defector shields too fast there....

Re:Early bird (corporate whore) gets the worm(pate

[Vulture_]

To replace them, bring in university professors that have nothing better to do than to sit on this panel of review.

And don't forget to pay them well. The USPTO's biggest problem is that it is horribly underfunded considering how much damage it is capable of causing. Homeland Security is frankly useless if your economy is cripped by rampant trivial patents being used as weapons of mass economic destruction.

How patent claims work

[Paul Johnson]

The "Claims" section of a patent is the most important bit. It lays out what the patent covers. It consists of a series of numbered items, each of which covers one idea or variation. So far so simple.

The key thing is that a court might in future decide that some claims are valid but others are not. So the first couple of claims in a patent might well lay claim to the entire state of the art, and might only be there as a kind of #define macro for subsequent claims. I once read an encryption patent (ISTR it was for a DVD system that didn't get used) where Claim 1 was for XORing the output of a random number generator with the cleartext. This was followed by a series of claims that started "A system as in Claim 1 where the random number generator is...".

So when you see a patent that seems to claim the whole of some technology, don't panic. There is going to be tons of prior art. You just have to work out where the prior art ends and the real invention starts. This is going to be a bit grey on the boundary (thats where patent lawyers make their money), but you can still get a fairly clear idea pretty quickly. You can also get a fair idea just by looking at the claims and thinking about the technology they represent. Once you get to precise descriptions of obscure algorithms then you are into the meat of the patent.

Incidentally, don't be scared of legalese. Just think of it as an unusually verbose and unstructured programming language.

Paul.

Berkeley Packet Filter?

[Anonymous Coward]

Given the general terms of the patent, might the Berkeley Packet Filter, published in December 1992, constitute prior art? (see http://citeseer.nj.nec.com/mccanne92bsd.html )

Re:How to read a patent

[Anonymous Coward]

4. Claims repeat themselves. Generally, you'll find that the earlier base claims are narrow in scope. They'll then refine some of this in derived claims to make the application clearer or cover the most valuable applications of the invention. Then, a new base claim is started, with more generic language. That process tends to continue until the patent is very large. This is deliberate -- the patent attorney is trying to be as broad as possible, but if they're too broad, the patent will be invalid. So the strategy is to repeat the basic claims so that if a broad claim is struck down as invalid the narrower ones can still survive. If you don't infringe the narrowest patent you can often skip the broader claims. This one's a little different -- some of the claims cover different aspects of the "invention".

A useful article, but the author has created some confusion between the terms "broad" and "narrow". When talking about patents, "broad" means "covers a large set of possible devices", while "narrow" means "covers a small, specific set" (more or less). An independent claim (referred to as a "base claim" above) is broader than it's dependent claims (referred to as "derived claims" above) . To illustrate, if there were an old patent on computers, it might have claims like this:

1. A computer comprising a storage device, a processor, and a display.
2. The computer of claim 1 wherein said storage device is a hard disk drive.
3. The computer of claim 2 wherein said display includes a cathode ray tube.
4. The computer of claim 1 wherein said storage device is a hard disk drive and said display includes a cathode ray tube, and wherein said computer further includes a keyboard as an input device, a printer as an output device, and a 10baseT network card as a communications device.

Many people misread claims, thinking that the longest claim, the one that mentions the most stuff, is the "broadest" and most dangerous. Generally, the opposite is true. Usually, it's the independent claim that covers the most things. Claim 4 above is the narrowest because only computers that have all 6 elements (hard disk, processor, CRT, keyboard, printer, and 10baseT card) can infringe. The broadest claim above is Claim 1, which even covers systems with several processors or several storage devices.

It's easier to infringe broad claims like Claim 1, but it's also easier to invalidate them. Narrow claims like Claim 4 are hard to invalidate because you must find prior art (or some other argument) against all 6 elements; however, they cover fewer devices and are easier to avoid infringing.

The author was right about several things, especially this: on the first read to see what a patent covers, go straight to the claims. Refer back to the rest of the patent as necessary to figure out what the claims are talking about.