Slashdot Mirror
Cisco Patents NAT RFC?
rageout noted that
Cisco seems to have filed
patent US5793763, which looks remarkably like
RFC 1631 (the RFC that defines NAT).
This came from this story on freebsddiary.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Yes, -do- read the actual patent; in particular, claim 1. Translated,
'A method wherein: if someone on the intranet sends out a packet, we translate their address to one that the internet accepts, and remember who they are. If a packet comes back for that exact translated address, and we haven't timed out the connection yet, then pass it through to the appropriate intranet host.'
If that isn't a patent on 'NAT implemented as device consisting of software on a computer' I don't know what is.
Please remember that each -claim- stands on its own as separate invention, put together in one patent for convenience and relatedness, but Cisco is claiming claim 1 all by itself as an invention regardless of other complexities in the claims.
Real text for reference, but it's more readable on the database page:
1. A method for translating network addresses on packets destined for local hosts on a private network from hosts on an external network, the method comprising the following steps:
identifying a global IP destination address on an inbound packet arriving at the private network;
determining whether the global IP destination address corresponds to any local host on the private network by determining if a translation slot data structure exists for the global IP destination address, which translation slot associates the global IP destination address to a corresponding local IP address for a particular local host which has sent an outbound packet to an external network host on the external network within a defined time period;
if the inbound packet is found to be intended for the particular local host on the private network which has sent the outbound packet to the external network host within said defined time period, determining whether the inbound packet meets defined security criteria;
if the inbound packet meets said security criteria, replacing the inbound packet's global IP destination address with the corresponding local IP address for the particular local host to which the inbound packet was addressed; and
forwarding the inbound packet to the particular local host to which the inbound packet was addressed.
--Parity
--Parity
'Card carrying' member of the EFF.
Summary: It may be tossed out because of the RFC/standards process. (besides prior art)
From: Darren Reed
To: ipfilter@coombs.anu.edu.au
Subject: Those turds over at (1$(0.
Someone has unfortunately brought to my attention the fact that certain
parts of NAT have been patented by the company which lovingly likes to
think it "runs the internet" (puke, spew, vomit). #5793763 patents a
complete implementation of what is essentially described in RFC 1631.
The patent was filed a whole 8 days prior to the first public release
(beta) of IPFilter with NAT.
If anyone can provide a legal opinion on whether or not that particular
patent would stand up in court, please let me know. That's legal opinions,
not personal opinions (they're dime a dozen). I'd be especially interested
to know of there are other NAT implemtenations which date back to prior to
that patent being filed and how complete they are/were.
And the non-legal reply:
From: Nigel Dyson-Hudson
To: ipfilter@coombs.anu.edu.au
Subject: Re: Those turds over at (1$(0.
folks,
Apparently you can not patent material from working with a standards body.
Dell was smacked down on this in 1996. You might want to look at what is
happening with RAMBUS memory, www.tomshardware.com has a number of
articles, since RAMBUS was a member of JEDC and has patented stuff from
those meetings.
So, if said company was anywhere near the RFC process, they would be trying
to patent stuff from an open standards body.
If it was said on slashdot, it MUST be true!
SLiRP also did TIA-like things. IIRC, it was release the summer of 1995. So there's an OPEN SOURCE release prior to CISCO's patent being filed. I don't know if it predates their internal first use, which may be a wash here.
I'd be happy to testify to these facts in a court of law, should it come to that, assuming that I can convince the folks that bought Cyberspace Developement to allow me to do so.
Warner Losh
The way I understood it, it would prevent a malicious external traffic source from sneaking their evil packets past the NAT using the source/destination port numbers that the NAT was sending out on its outbound packets. So FTP packets get through only if an internal host initiated an FTP session, DNS packets get through, certain ICMP packets, etc.
--Ford Prefect
Check out the list of 10 patents that reference this one, especially 6006272 "Method for Network Address Translation", by Lucent. That one sounds like a more general one, and a lot more like the RFC.
Actually, they didn't buy anything. This range is registered with IANA as the link-local IP address range, from which a machine can assign itself a temporary IP, for use during configuration. The range for that is 169.254/16. The definition for how this range is used in IPv4 as part of an ad hoc network is located here. It's also used in IPv6 in RFC 2462.
Scroll all the way to the bottom of the page, and you'll see the patent does, in fact, reference RFC 1631. They're not patenting NAT, they're patenting "an adaptive security algorithm" for use with NAT.
As far as I can make out, the difference in the patent and the RFC seems to me to be that the patent specifies that the packets are filtered by a security algorithm, where the RFC states that it has no security algorithm.
The patent then, only applies to a version of NAT that uses an adaptive security algorithm.
Anything less than this would definately hit the prior art. And it's quite likely that even this will hit the prior art bin too.
From the Patent:
Packets arriving from the Internet are screened by an adaptive security algorithm
From the RFC:
Unfortunately, NAT reduces the number of options for providing security. With NAT, nothing that carries an IP address or information derived from an IP address (such as the TCP-header checksum) can be encrypted. While most application-level encryption should be ok, this prevents encryption of the TCP header.