Untitled Document

Internet Draft B. FordDocument: draft-ford-midcom-p2p-01.txt M.I.T.Expires: April 27, 2004 P. SrisureshCaymas SystemsD. Kegelkegel.comOctober 2003Peer-to-Peer (P2P) communication across middleboxesStatus of this MemoThis document is an Internet-Draft and is subject to all provisionsof Section 10 of RFC2026. Internet-Drafts are working documents ofthe Internet Engineering Task Force (IETF), its areas, and itsworking groups. Note that other groups may also distribute workingdocuments as Internet-Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet- Drafts as referencematerial or to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/1id-abstracts.htmlThe list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.htmlDistribution of this document is unlimited.Copyright NoticeCopyright (C) The Internet Society (2003). All Rights Reserved.AbstractThis memo documents the methods used by the current peer-to-peer(P2P) applications to communicate in the presence of middleboxessuch as firewalls and network address translators (NAT). Inaddition, the memo suggests guidelines to application designersand middlebox implementers on the measures they could take toenable immediate, wide deployment of P2P applications with orwithout requiring the use of special proxy, relay or midcomprotocols.Ford, Srisuresh & Kegel [Page 1]Internet-Draft P2P applications across middleboxes October 2003Table of Contents1. Introduction .................................................2. Terminology ..................................................3. Techniques for P2P communication over middleboxes ............3.1. Relaying ...............................................3.2. Connection reversal ....................................3.3. UDP Hole Punching ......................................3.3.1. Peers behind different NATs ..................3.3.2. Peers behind the same NAT ....................3.3.3. Peers separated by multiple NATs ...............3.3.4. Consistent port bindings .......................3.4. UDP Port number prediction .............................3.5. Simultaneous TCP open ..................................4. Application design guidelines ................................4.1. What works with P2P middleboxes .........................4.2. Applications behind the same NAT ........................4.3. Peer discovery ..........................................4.4. TCP P2P applications ....................................4.5. Use of midcom protocol ..................................5. NAT design guidelines ........................................5.1. Deprecate the use of symmetric NATs .....................5.2. Add incremental Cone-NAT support to symmetric NAT devices5.3. Maintaining consistent port bindings for UDP ports .....5.3.1. Preserving Port Numbers ........................5.4. Maintaining consistent port bindings for TCP ports .....5.5. Large timeout for P2P applications ......................6. Security considerations ......................................1. IntroductionPresent-day Internet has seen ubiquitous deployment of"middleboxes" such as network address translators(NAT), drivenprimarily by the ongoing depletion of the IPv4 address space. Theasymmetric addressing and connectivity regimes established by thesemiddleboxes, however, have created unique problems for peer-to-peer(P2P) applications and protocols, such as teleconferencing andmultiplayer on-line gaming. These issues are likely to persist eveninto the IPv6 world, where NAT is often used as an IPv4 compatibilitymechanism [NAT-PT], and firewalls will still be commonplace evenafter NAT is no longer required.Currently deployed middleboxes are designed primarily around theclient/server paradigm, in which relatively anonymous client machinesactively initiate connections to well-connected servers having stableIP addresses and DNS names. Most middleboxes implement an asymmetricFord, Srisuresh & Kegel [Page 2]Internet-Draft P2P applications across middleboxes October 2003communication model in which hosts on the private internal networkcan initiate outgoing connections to hosts on the public network, butexternal hosts cannot initiate connections to internal hosts exceptas specifically configured by the middlebox‘s administrator. In thecommon case of NAPT, a client on the internal network does not havea unique IP address on the public Internet, but instead must sharea single public IP address, managed by the NAPT, with other hostson the same private network. The anonymity and inaccessibility ofthe internal hosts behind a middlebox is not a problem for clientsoftware such as web browsers, which only need to initiate outgoingconnections. This inaccessibility is sometimes seen as a privacybenefit.In the peer-to-peer paradigm, however, Internet hosts that wouldnormally be considered "clients" need to establish communicationsessions directly with each other. The initiator and the respondermight lie behind different middleboxes with neither endpointhaving any permanent IP address or other form of public networkpresence. A common on-line gaming architecture, for example,is for the participating application hosts to contact a well-knownserver for initialization and administration purposes. Subsequentto this, the hosts establish direct connections with each otherfor fast and efficient propagation of updates during game play.Similarly, a file sharing application might contact a well-knownserver for resource discovery or searching, but establish directconnections with peer hosts for data transfer. Middleboxes createproblems for peer-to-peer connections because hosts behind amiddlebox normally have no permanently usable public ports on theInternet to which incoming TCP or UDP connections from other peerscan be directed. RFC 3235 [NAT-APPL] briefly addresses this issue,but does not offer any general solutions.In this document we address the P2P/middlebox problem in two ways.First, we summarize known methods by which P2P applications canwork around the presence of middleboxes. Second, we provide a setof application design guidelines based on these practices to makeP2P applications operate more robustly over currently-deployedmiddleboxes. Further, we provide design guidelines for futuremiddleboxes to allow them to support P2P applications moreeffectively. Our focus is to enable immediate and wide deploymentof P2P applications requiring to traverse middleboxes.2. TerminologyIn this section we first summarize some middlebox terms. We focus hereon the two kinds of middleboxes that commonly cause problems for P2Papplications.Ford, Srisuresh & Kegel [Page 3]Internet-Draft P2P applications across middleboxes October 2003FirewallA firewall restricts communication between a private internalnetwork and the public Internet, typically by dropping packetsthat are deemed unauthorized. A firewall examines but doesnot modify the IP address and TCP/UDP port information inpackets crossing the boundary.Network Address Translator (NAT)A network address translator not only examines but also modifiesthe header information in packets flowing across the boundary,allowing many hosts behind the NAT to share the use of a smallernumber of public IP addresses (often one).Network address translators in turn have two main varieties:Basic NATA Basic NAT maps an internal host‘s private IP address to apublic IP address without changing the TCP/UDP portnumbers in packets crossing the boundary. Basic NAT is generallyonly useful when the NAT has a pool of public IP addresses fromwhich to make address bindings on behalf of internal hosts.Network Address/Port Translator (NAPT)By far the most common, a Network Address/Port Translator examinesand modifies both the IP address and the TCP/UDP port numberfields of packets crossing the boundary, allowing multipleinternal hosts to share a single public IP address simultaneously.Refer to [NAT-TRAD] and [NAT-TERM] for more general information onNAT taxonomy and terminology. Additional terms that further classifyNAPT are defined in more recent work [STUN]. When an internal hostopens an outgoing TCP or UDP session through a network address/porttranslator, the NAPT assigns the session a public IP address andport number so that subsequent response packets from the externalendpoint can be received by the NAPT, translated, and forwardedto the internal host. The effect is that the NAPT establishes aport binding between (private IP address, private port number) and(public IP address, public port number). The port bindingdefines the address translation the NAPT will perform for theduration of the session. An issue of relevance to P2Papplications is how the NAT behaves when an internal host initiatesmultiple simultaneous sessions from a single (private IP, privateport) pair to multiple distinct endpoints on the external network.Cone NATAfter establishing a port binding between a (private IP, privateport) tuple and a (public IP, public port) tuple, a cone NAT willre-use this port binding for subsequent sessions theFord, Srisuresh & Kegel [Page 4]Internet-Draft P2P applications across middleboxes October 2003application may initiate from the same private IP address andport number, for as long as at least one session using the portbinding remains active.For example, suppose Client A in the diagram below initiates twosimultaneous outgoing sessions through a cone NAT, from the sameinternal endpoint (10.0.0.1:1234) to two differentexternal servers, S1 and S2. The cone NAT assigns just one publicendpoint tuple, 155.99.25.11:62000, to both of these sessions,ensuring that the "identity" of the client‘s port is maintainedacross address translation. Since Basic NATs and firewalls donot modify port numbers as packets flow acrossthe middlebox, these types of middleboxes can be viewed as adegenerate form of Cone NAT.Server S1 Server S218.181.0.31:1235 138.76.29.7:1235| || |+----------------------+----------------------+|^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^| 18.181.0.31:1235 | | | 138.76.29.7:1235 |v 155.99.25.11:62000 v | v 155.99.25.11:62000 v|Cone NAT155.99.25.11|^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^| 18.181.0.31:1235 | | | 138.76.29.7:1235 |v 10.0.0.1:1234 v | v 10.0.0.1:1234 v|Client A10.0.0.1:1234Ford, Srisuresh & Kegel [Page 5]Internet-Draft P2P applications across middleboxes October 2003Symmetric NATA symmetric NAT, in contrast, does not maintain a consistentport binding between (private IP, private port) and (public IP,public port) across all sessions. Instead, it assigns a newpublic port to each new session. For example, suppose Client Ainitiates two outgoing sessions from the same port as above, onewith S1 and one with S2. A symmetric NAT might allocate thepublic endpoint 155.99.25.11:62000 to session 1, and then allocatea different public endpoint 155.99.25.11:62001, when theapplication initiates session 2. The NAT is able to differentiatebetween the two sessions for translation purposes because theexternal endpoints involved in the sessions (those of S1and S2) differ, even as the endpoint identity of the clientapplication is lost across the address translation boundary.Server S1 Server S218.181.0.31:1235 138.76.29.7:1235| || |+----------------------+----------------------+|^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^| 18.181.0.31:1235 | | | 138.76.29.7:1235 |v 155.99.25.11:62000 v | v 155.99.25.11:62001 v|Symmetric NAT155.99.25.11|^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^| 18.181.0.31:1235 | | | 138.76.29.7:1235 |v 10.0.0.1:1234 v | v 10.0.0.1:1234 v|Client A10.0.0.1:1234The issue of cone versus symmetric NAT behavior applies equallyto TCP and UDP traffic.Cone NAT is further classified according to how liberally the NATaccepts incoming traffic directed to an already-established (publicIP, public port) pair. This classification generally applies only toUDP traffic, since NATs and firewalls reject incoming TCPconnection attempts unconditionally unless specifically configured todo otherwise.Full Cone NATFord, Srisuresh & Kegel [Page 6]Internet-Draft P2P applications across middleboxes October 2003After establishing a public/private port binding for a newoutgoing session, a full cone NAT will subsequently acceptincoming traffic to the corresponding public port from ANYexternal endpoint on the public network. Full cone NAT isalso sometimes called "promiscuous" NAT.Restricted Cone NATA restricted cone NAT only forwards an incoming packet directed toa public port if its external (source) IP address matches theaddress of a node to which the internal host has previously sentone or more outgoing packets. A restricted cone NAT effectivelyrefines the firewall principle of rejecting unsolicited incomingtraffic, by restricting incoming traffic to a set of "known"external IP addresses.Port-Restricted Cone NATA port-restricted cone NAT, in turn, only forwards an incomingpacket if its external IP address AND port number match those ofan external endpoint to which the internal host has previouslysent outgoing packets. A port-restricted cone NAT providesinternal nodes the same level of protection against unsolicitedincoming traffic that a symmetric NAT does, while maintaining aprivate port‘s identity across translation.Finally, in this document we define new terms for classifyingthe P2P-relevant behavior of middleboxes:P2P-ApplicationP2P-application as used in this document is an application inwhich each P2P participant registers with a publicregistration server, and subsequently uses either itsprivate endpoint, or public endpoint, or both, to establishpeering sessions.P2P-MiddleboxA P2P-Middlebox is middlebox that permits the traversal ofP2P applications.P2P-firewallA P2P-firewall is a P2P-Middlebox that provides firewallfunctionality but performs no address translation.P2P-NATA P2P-NAT is a P2P-Middlebox that provides NAT functionality, andmay also provide firewall functionality. At minimum, aP2P-Middlebox must implement Cone NAT behavior for UDP traffic,allowing applications to establish robust P2P connectivity usingthe UDP hole punching technique.Ford, Srisuresh & Kegel [Page 7]Internet-Draft P2P applications across middleboxes October 2003Loopback translationWhen a host in the private domain of a NAT device attempts toconnect with another host behind the same NAT device usingthe public address of the host, the NAT device performs theequivalent of a "Twice-nat" translation on the packet asfollows. The originating host‘s private endpoint is translatedinto its assigned public endpoint, and the target host‘s publicendpoint is translated into its private endpoint, beforethe packet is forwarded to the target host. We refer the abovetranslation performed by a NAT device as "Loopback translation".3. Techniques for P2P Communication over middleboxesThis section reviews in detail the currently known techniques forimplementing peer-to-peer communication over existing middleboxes,from the perspective of the application or protocol designer.3.1. RelayingThe most reliable, but least efficient, method of implementing peer-to-peer communication in the presence of a middlebox is to make thepeer-to-peer communication look to the network like client/servercommunication through relaying. For example, suppose two clienthosts, A and B, have each initiated TCP or UDP connections with awell-known server S having a permanent IP address. The clientsreside on separate private networks, however, and their respectivemiddleboxes prevent either client from directly initiating aconnection to the other.Server S||+----------------------+----------------------+| |NAT A NAT B| || |Client A Client BInstead of attempting a direct connection, the two clients can simplyuse the server S to relay messages between them. For example, tosend a message to client B, client A simply sends the message toserver S along its already-established client/server connection, andserver S then sends the message on to client B using its existingclient/server connection with B.This method has the advantage that it will always work as long asFord, Srisuresh & Kegel [Page 8]Internet-Draft P2P applications across middleboxes October 2003both clients have connectivity to the server. Its obviousdisadvantages are that it consumes the server‘s processing power andnetwork bandwidth unnecessarily, and communication latency betweenthe two clients is likely to be increased even if the server is well-connected. The TURN protocol [TURN] defines a method of implementingrelaying in a relatively secure fashion.Ford, Srisuresh & Kegel [Page 9]Internet-Draft P2P applications across middleboxes October 20033.2. Connection reversalThe second technique works if only one of the clients is behind amiddlebox. For example, suppose client A is behind a NAT but clientB has a globally routable IP address, as in the following diagram:Server S18.181.0.31:1235||+----------------------+----------------------+| |NAT A |155.99.25.11:62000 || || |Client A Client B10.0.0.1:1234 138.76.29.7:1234Client A has private IP address 10.0.0.1, and the application isusing TCP port 1234. This client has established a connection withserver S at public IP address 18.181.0.31 and port 1235. NAT A hasassigned TCP port 62000, at its own public IP address 155.99.25.11,to serve as the temporary public endpoint address for A‘s sessionwith S: therefore, server S believes that client A is at IP address155.99.25.11 using port 62000. Client B, however, has its ownpermanent IP address, 138.76.29.7, and the peer-to-peer applicationon B is accepting TCP connections at port 1234.Now suppose client B would like to initiate a peer-to-peercommunication session with client A. B might first attempt tocontact client A either at the address client A believes itself tohave, namely 10.0.0.1:1234, or at the address of A as observed byserver S, namely 155.99.25.11:62000. In either case, however, theconnection will fail. In the first case, traffic directed to IPaddress 10.0.0.1 will simply be dropped by the network because10.0.0.1 is not a publicly routable IP address. In the second case,the TCP SYN request from B will arrive at NAT A directed to port62000, but NAT A will reject the connection request because onlyoutgoing connections are allowed.After attempting and failing to establish a direct connection to A,client B can use server S to relay a request to client A to initiatea "reversed" connection to client B. Client A, upon receiving thisrelayed request through S, opens a TCP connection to client B at B‘spublic IP address and port number. NAT A allows the connection toproceed because it is originating inside the firewall, and client Bcan receive the connection because it is not behind a middlebox.Ford, Srisuresh & Kegel [Page 10]Internet-Draft P2P applications across middleboxes October 2003A variety of current peer-to-peer systems implement this technique.Its main limitation, of course, is that it only works as long as onlyone of the communicating peers is behind a NAT: in the increasinglycommon case where both peers are behind NATs, the method fails.Because connection reversal is not a general solution to the problem,it is NOT recommended as a primary strategy. Applications may chooseto attempt connection reversal, but should be able to fall backautomatically on another mechanism such as relaying if neither a"forward" nor a "reverse" connection can be established.3.3. UDP hole punchingThe third technique, and the one of primary interest in thisdocument, is widely known as "UDP Hole Punching." UDP hole punchingrelies on the properties of common firewalls and cone NATs to allowappropriately designed peer-to-peer applications to "punch holes"through the middlebox and establish direct connectivity with eachother, even when both communicating hosts may lie behind middleboxes.This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet[KEGEL] and used in some recent protocols [TEREDO, ICE]. As the nameimplies, unfortunately, this technique works reliably only with UDP.We will consider two specific scenarios, and how applications can bedesigned to handle both of them gracefully. In the first situation,representing the common case, two clients desiring direct peer-to-peer communication reside behind two different NATs. In the second,the two clients actually reside behind the same NAT, but do notnecessarily know that they do.3.3.1. Peers behind different NATsSuppose clients A and B both have private IP addresses and lie behinddifferent network address translators. The peer-to-peer applicationrunning on clients A and B and on server S each use UDP port 1234. Aand B have each initiated UDP communication sessions with server S,causing NAT A to assign its own public UDP port 62000 for A‘s sessionwith S, and causing NAT B to assign its port 31000 to B‘s sessionwith S, respectively.Server S18.181.0.31:1234||+----------------------+----------------------+| |NAT A NAT BFord, Srisuresh & Kegel [Page 11]Internet-Draft P2P applications across middleboxes October 2003155.99.25.11:62000 138.76.29.7:31000| || |Client A Client B10.0.0.1:1234 10.1.1.3:1234Now suppose that client A wants to establish a UDP communicationsession directly with client B. If A simply starts sending UDPmessages to B‘s public address, 138.76.29.7:31000, then NAT B willtypically discard these incoming messages (unless it is a full coneNAT), because the source address and port number does not match thoseof S, with which the original outgoing session was established.Similarly, if B simply starts sending UDP messages to A‘s publicaddress, then NAT A will typically discard these messages.Suppose A starts sending UDP messages to B‘s public address, however,and simultaneously relays a request through server S to B, asking Bto start sending UDP messages to A‘s public address. A‘s outgoingmessages directed to B‘s public address (138.76.29.7:31000) cause NATA to open up a new communication session between A‘s private addressand B‘s public address. At the same time, B‘s messages to A‘s publicaddress (155.99.25.11:62000) cause NAT B to open up a newcommunication session between B‘s private address and A‘s publicaddress. Once the new UDP sessions have been opened up in eachdirection, client A and B can communicate with each other directlywithout further burden on the "introduction" server S.The UDP hole punching technique has several useful properties. Oncea direct peer-to-peer UDP connection has been established between twoclients behind middleboxes, either party on that connection can inturn take over the role of "introducer" and help the other partyestablish peer-to-peer connections with additional peers, minimizingthe load on the initial introduction server S. The application doesnot need to attempt to detect explicitly what kind of middlebox it isbehind, if any [STUN], since the procedure above will establish peer-to-peer communication channels equally well if either or both clientsdo not happen to be behind a middlebox. The hole punching techniqueeven works automatically with multiple NATs, where one or bothclients are removed from the public Internet via two or more levelsof address translation.3.3.2. Peers behind the same NATNow consider the scenario in which the two clients (probablyunknowingly) happen to reside behind the same NAT, and are thereforelocated in the same private IP address space. Client A hasestablished a UDP session with server S, to which the common NAT hasassigned public port number 62000. Client B has similarlyFord, Srisuresh & Kegel [Page 12]Internet-Draft P2P applications across middleboxes October 2003established a session with S, to which the NAT has assigned publicport number 62001.Server S18.181.0.31:1234||NATA-S 155.99.25.11:62000B-S 155.99.25.11:62001|+----------------------+----------------------+| |Client A Client B10.0.0.1:1234 10.1.1.3:1234Suppose that A and B use the UDP hole punching technique as outlinedabove to establish a communication channel using server S as anintroducer. Then A and B will learn each other‘s public IP addressesand port numbers as observed by server S, and start sending eachother messages at those public addresses. The two clients will beable to communicate with each other this way as long as the NATallows hosts on the internal network to open translated UDP sessionswith other internal hosts and not just with external hosts. We referto this situation as "loopback translation," because packets arrivingat the NAT from the private network are translated and then "loopedback" to the private network rather than being passed through to thepublic network. For example, when A sends a UDP packet to B‘s publicaddress, the packet initially has a source IP address and port numberof 10.0.0.1:124 and a destination of 155.99.25.11:62001. The NATreceives this packet, translates it to have a source of155.99.25.11:62000 (A‘s public address) and a destination of10.1.1.3:1234, and then forwards it on to B. Even if loopbacktranslation is supported by the NAT, this translation and forwardingstep is obviously unnecessary in this situation, and is likely to addlatency to the dialog between A and B as well as burdening the NAT.The solution to this problem is straightforward, however. When A andB initially exchange address information through server S, theyshould include their own IP addresses and port numbers as "observed"by themselves, as well as their addresses as observed by S. Theclients then simultaneously start sending packets to each other ateach of the alternative addresses they know about, and use the firstaddress that leads to successful communication. If the two clientsare behind the same NAT, then the packets directed to their privateaddresses are likely to arrive first, resulting in a directcommunication channel not involving the NAT. If the two clients arebehind different NATs, then the packets directed to their privateFord, Srisuresh & Kegel [Page 13]Internet-Draft P2P applications across middleboxes October 2003addresses will fail to reach each other at all, but the clients willhopefully establish connectivity using their respective publicaddresses. It is important that these packets be authenticated insome way, however, since in the case of different NATs it is entirelypossible for A‘s messages directed at B‘s private address to reachsome other, unrelated node on A‘s private network, or vice versa.3.3.3. Peers separated by multiple NATsIn some topologies involving multiple NAT devices, it is notpossible for two clients to establish an "optimal" P2P route betweenthem without specific knowledge of the topology. Consider forexample the following situation.Server S18.181.0.31:1234||NAT XA-S 155.99.25.11:62000B-S 155.99.25.11:62001||+----------------------+----------------------+| |NAT A NAT B192.168.1.1:30000 192.168.1.2:31000| || |Client A Client B10.0.0.1:1234 10.1.1.3:1234Suppose NAT X is a large industrial NAT deployed by an internetservice provider (ISP) to multiplex many customers onto a few publicIP addresses, and NATs A and B are small consumer NAT gatewaysdeployed independently by two of the ISP‘s customers to multiplextheir private home networks onto their respective ISP-provided IPaddresses. Only server S and NAT X have globally routable IPaddresses; the "public" IP addresses used by NAT A and NAT B areactually private to the ISP‘s addressing realm, while client A‘s andB‘s addresses in turn are private to the addressing realms of NAT Aand B, respectively. Each client initiates an outgoing connection toserver S as before, causing NATs A and B each to create a singlepublic/private translation, and causing NAT X to establish apublic/private translation for each session.Now suppose clients A and B attempt to establish a direct peer-to-Ford, Srisuresh & Kegel [Page 14]Internet-Draft P2P applications across middleboxes October 2003peer UDP connection. The optimal method would be for client A tosend messages to client B‘s public address at NAT B,192.168.1.2:31000 in the ISP‘s addressing realm, and for client B tosend messages to A‘s public address at NAT B, namely192.168.1.1:30000. Unfortunately, A and B have no way to learn theseaddresses, because server S only sees the "global" public addressesof the clients, 155.99.25.11:62000 and 155.99.25.11:62001. Even if Aand B had some way to learn these addresses, there is still noguarantee that they would be usable because the address assignmentsin the ISP‘s private addressing realm might conflict with unrelatedaddress assignments in the clients‘ private realms. The clientstherefore have no choice but to use their global public addresses asseen by S for their P2P communication, and rely on NAT X to provideloopback translation.3.3.4. Consistent port bindingsThe hole punching technique has one main caveat: it works only ifboth NATs are cone NATs (or non-NAT firewalls), which maintain aconsistent port binding between a given (private IP, private UDP)pair and a (public IP, public UDP) pair for as long as that UDP portis in use. Assigning a new public port for each new session, as asymmetric NAT does, makes it impossible for a UDP application toreuse an already-established translation for communication withdifferent external destinations. Since cone NATs are the mostwidespread, the UDP hole punching technique is fairly broadlyapplicable; nevertheless a substantial fraction of deployed NATs aresymmetric and do not support the technique.3.4. UDP port number predictionA variant of the UDP hole punching technique discussed above existsthat allows peer-to-peer UDP sessions to be created in the presenceof some symmetric NATs. This method is sometimes called the "N+1"technique [BIDIR] and is explored in detail by Takeda [SYM-STUN].The method works by analyzing the behavior of the NAT and attemptingto predict the public port numbers it will assign to future sessions.Consider again the situation in which two clients, A and B, eachbehind a separate NAT, have each established UDP connections with apermanently addressable server S:Server S18.181.0.31:1234||+----------------------+----------------------+| |Symmetric NAT A Symmetric NAT BFord, Srisuresh & Kegel [Page 15]Internet-Draft P2P applications across middleboxes October 2003A-S 155.99.25.11:62000 B-S 138.76.29.7:31000| || |Client A Client B10.0.0.1:1234 10.1.1.3:1234NAT A has assigned its own UDP port 62000 to the communicationsession between A and S, and NAT B has assigned its port 31000 to thesession between B and S. By communicating through server S, A and Blearn each other‘s public IP addresses and port numbers as observedby S. Client A now starts sending UDP messages to port 31001 ataddress 138.76.29.7 (note the port number increment), and client Bsimultaneously starts sending messages to port 62001 at address155.99.25.11. If NATs A and B assign port numbers to new sessionssequentially, and if not much time has passed since the A-S and B-Ssessions were initiated, then a working bi-directional communicationchannel between A and B should result. A‘s messages to B cause NAT Ato open up a new session, to which NAT A will (hopefully) assignpublic port number 62001, because 62001 is next in sequence after theport number 62000 it previously assigned to the session between A andS. Similarly, B‘s messages to A will cause NAT B to open a newsession, to which it will (hopefully) assign port number 31001. Ifboth clients have correctly guessed the port numbers each NAT assignsto the new sessions, then a bi-directional UDP communication channelwill have been established as shown below.Server S18.181.0.31:1234||+----------------------+----------------------+| |NAT A NAT BA-S 155.99.25.11:62000 B-S 138.76.29.7:31000A-B 155.99.25.11:62001 B-A 138.76.29.7:31001| || |Client A Client B10.0.0.1:1234 10.1.1.3:1234Obviously there are many things that can cause this trick to fail.If the predicted port number at either NAT already happens to be inuse by an unrelated session, then the NAT will skip over that portnumber and the connection attempt will fail. If either NAT sometimesor always chooses port numbers non-sequentially, then the trick willfail. If a different client behind NAT A (or B respectively) opensup a new outgoing UDP connection to any external destination after A(B) establishes its connection with S but before sending its firstFord, Srisuresh & Kegel [Page 16]Internet-Draft P2P applications across middleboxes October 2003message to B (A), then the unrelated client will inadvertently"steal" the desired port number. This trick is therefore much lesslikely to work when either NAT involved is under load.Since in practice a P2P application implementing this trick wouldstill need to work if the NATs are cone NATs, or if one is a cone NATand the other is a symmetric NAT, the application would need todetect beforehand what kind of NAT is involved on either end [STUN]and modify its behavior accordingly, increasing the complexity of thealgorithm and the general brittleness of the network. Finally, portnumber prediction has no chance of working if either client is behindtwo or more levels of NAT and the NAT(s) closest to the client aresymmetric. For all of these reasons, it is NOT recommended that newapplications implement this trick; it is mentioned here forhistorical and informational purposes.3.5. Simultaneous TCP openThere is a method that can be used in some cases to establish directpeer-to-peer TCP connections between a pair of nodes that are bothbehind existing middleboxes. Most TCP sessions start with oneendpoint sending a SYN packet, to which the other party responds witha SYN-ACK packet. It is possible and legal, however, for twoendpoints to start a TCP session by simultaneously sending each otherSYN packets, to which each party subsequently responds with aseparate ACK. This procedure is known as a "simultaneous open."If a middlebox receives a TCP SYN packet from outside the privatenetwork attempting to initiate an incoming TCP connection, themiddlebox will normally reject the connection attempt by eitherdropping the SYN packet or sending back a TCP RST (connection reset)packet. If, however, the SYN packet arrives with source anddestination addresses and port numbers that correspond to a TCPsession that the middlebox believes is already active, then themiddlebox will allow the packet to pass through. In particular, ifthe middlebox has just recently seen and transmitted an outgoing SYNpacket with the same addresses and port numbers, then it willconsider the session active and allow the incoming SYN through. Ifclients A and B can each correctly predict the public port numberthat its respective middlebox will assign the next outgoing TCPconnection, and if each client initiates an outgoing TCP connectionwith the other client timed so that each client‘s outgoing SYN passesthrough its local middlebox before either SYN reaches the oppositemiddlebox, then a working peer-to-peer TCP connection will result.Unfortunately, this trick may be even more fragile and timing-sensitive than the UDP port number prediction trick described above.First, unless both middleboxes are simple firewalls or implement coneFord, Srisuresh & Kegel [Page 17]Internet-Draft P2P applications across middleboxes October 2003NAT behavior on their TCP traffic, all the same things can go wrongwith each side‘s attempt to predict the public port numbers that therespective NATs will assign to the new sessions. In addition, ifeither client‘s SYN arrives at the opposite middlebox too quickly,then the remote middlebox may reject the SYN with a RST packet,causing the local middlebox in turn to close the new session and makefuture SYN retransmission attempts using the same port numbersfutile. Finally, even though support for simultaneous open istechnically a mandatory part of the TCP specification [TCP], it isnot implemented correctly in some common operating systems. For thisreason, this trick is likewise mentioned here only for historicalreasons; it is NOT recommended for use by applications. Applicationsthat require efficient, direct peer-to-peer communication overexisting NATs should use UDP.4. Application design guidelines4.1. What works with P2P middleboxesSince UDP hole punching is the most efficient existing method ofestablishing direct peer-to-peer communication between two nodesthat are both behind NATs, and it works with a wide variety ofexisting NATs, it is recommended that applications use thistechnique if efficient peer-to-peer communication is required,but be prepared to fall back on simple relaying when directcommunication cannot be established.4.2. Peers behind the same NATIn practice there may be a fairly large number of users whohave not two IP addresses, but three or more. In these cases,it is hard or impossible to tell which addresses to send tothe registration server. The applications should send all itsaddresses, in such a case.4.3. Peer discoveryApplications sending packets to several addresses to discoverwhich one is best to use for a given peer may become asignificant source of ‘space junk‘ littering the net, as thepeer may have chosen to use routable addresses improperly asan internal LAN (e.g. 11.0.1.1, which is assigned to the DOD).Thus applications should exercise caution when sending thespeculative hello packets.4.4. TCP P2P applicationsFord, Srisuresh & Kegel [Page 18]Internet-Draft P2P applications across middleboxes October 2003The sockets API, used widely by application developers, isdesigned with client-server applications in mind. In itsnative form, only a single socket can bind to a TCP or UDPport. An application is not allowed to have multiplesockets binding to the same port (TCP or UDP) to initiatesimultaneous sessions with multiple external nodes (or)use one socket to listen on the port and the other socketsto initiate outgoing sessions.The above single-socket-to-port bind restriction is not aproblem however with UDP, because UDP is a datagram basedprotocol. UDP P2P application designers could use a singlesocket to send as well as receive datagrams from multiplepeers using recvfrom() and sendto() calls.This is not the case with TCP. With TCP, each incoming andoutgoing connection is to be associated with a separatesocket. Linux sockets API addresses this problem with theaid of SO_REUSEADDR option. On FreeBSD and NetBSD, thisoption does not seem to work; but, changing it to use theBSD-specific SetReuseAddress call (which Linux doesn‘thave and isn‘t in the Single Unix Standard) seems to work.Win32 API offers an equivalent SetReuseAddress call.Using any of the above mentioned options, an applicationcould use multiple sockets to reuse a TCP port. Say, opentwo TCP stream sockets bound to the same port, do alisten() on one and a connect() from the other.4.5. Use of midcom protocolIf the applications know the middleboxes they would betraversing and these middleboxes implement the midcomprotocol, applications could use the midcom protocol toease their way through the middleboxes.For example, P2P applications require that NAT middleboxespreserve end-point port bindings. If midcom is supported onthe middleboxes, P2P applications can exercise control overport binding (or address binding) parameters such as lifetime,maxidletime, and directionality so the applications can bothconnect to external peers as well as receive connections fromexternal peers; and do not need to send periodic keep-alives tokeep the port binding alive. When the application no longer needsthe binding, the application could simply dismantle the binding,also using the midcom protocol.5. NAT Design GuidelinesFord, Srisuresh & Kegel [Page 19]Internet-Draft P2P applications across middleboxes October 2003This section discusses considerations in the design of networkaddress translators, as they affect peer-to-peer applications.5.1. Deprecate the use of symmetric NATsSymmetric NATs gained popularity with client-serverapplications such as web browsers, which only need to initiateoutgoing connections. However, in the recent times, P2Papplications such as Instant messaging and audio conferencinghave been in wide use. Symmetric NATs do not support theconcept of retaining endpoint identity and are not suitablefor P2P applications. Deprecating symmetric NATs isrecommended to support P2P applications.A P2P-middlebox must implement Cone NAT behavior for UDPtraffic, allowing applications to establish robust P2Pconnectivity using the UDP hole punching technique.Ideally, a P2P-middlebox should also allow applications tomake P2P connections via both TCP and UDP.5.2. Add incremental cone-NAT support to symmetric NAT devicesOne way for a symmetric NAT device to extend support to P2Papplications would be to divide its assignable portnamespace, reserving a portion of its ports for one-to-onesessions and a different set of ports for one-to-manysessions.Further, a NAT device may be explicitly configured withapplications and hosts that need the P2P feature, so theNAT device can auto magically assign a P2P port from theright port block.5.3. Maintain consistent port bindings for UDP portsThe primary and most important recommendation of this document forNAT designers is that the NAT maintain a consistent and stableport binding between a given (internal IP address, internal UDPport) pair and a corresponding (public IP address, public UDPport) pair for as long as any active sessions exist using thatport binding. The NAT may filter incoming traffic on aper-session basis, by examining both the source and destinationIP addresses and port numbers in each packet. When a node on theprivate network initiates connection to a new externaldestination, using the same source IP address and UDP port as anexisting translated UDP session, the NAT should ensure that thenew UDP session is given the same public IP address and UDP portFord, Srisuresh & Kegel [Page 20]Internet-Draft P2P applications across middleboxes October 2003numbers as the existing session.5.3.1. Preserving port numbersSome NATs, when establishing a new UDP session, attempt to assign thesame public port number as the corresponding private port number, ifthat port number happens to be available. For example, if client Aat address 10.0.0.1 initiates an outgoing UDP session with a datagramfrom port number 1234, and the NAT‘s public port number 1234 happensto be available, then the NAT uses port number 1234 at the NAT‘spublic IP address as the translated endpoint address for the session.This behavior might be beneficial to some legacy UDP applicationsthat expect to communicate only using specific UDP port numbers, butit is not recommended that applications depend on this behavior sinceit is only possible for a NAT to preserve the port number if at mostone node on the internal network is using that port number.In addition, a NAT should NOT try to preserve the port number in anew session if doing so would conflict with the goal of maintaining aconsistent binding between public and private endpoint addresses.For example, suppose client A at internal port 1234 has established asession with external server S, and NAT A has assigned public port62000 to this session because port number 1234 on the NAT was notavailable at the time. Now suppose port number 1234 on the NATsubsequently becomes available, and while the session between A and Sis still active, client A initiates a new session from its sameinternal port (1234) to a different external node B. In this case,because a port binding has already been established between clientA‘s port 1234 and the NAT‘s public port 62000, this binding should bemaintained and the new session should also use port 62000 as thepublic port corresponding to client A‘s port 1234. The NAT shouldNOT assign public port 1234 to this new session just because port1234 has become available: that behavior would not be likely tobenefit the application in any way since the application has alreadybeen operating with a translated port number, and it would break anyattempts the application might make to establish peer-to-peerconnections using the UDP hole punching technique.5.4. Maintaining consistent port bindings for TCP portsFor consistency with the behavior of UDP translation, cone NATimplementers should also maintain a consistent binding betweenprivate and public (IP address, TCP port number) pairs for TCPconnections, in the same way as described above for UDP.Maintaining TCP endpoint bindings consistently will increasethe NAT‘s compatibility with P2P TCP applications that initiatemultiple TCP connections from the same source port.Ford, Srisuresh & Kegel [Page 21]Internet-Draft P2P applications across middleboxes October 20035.5. Large timeout for P2P applicationsWe recommend the middlebox implementers to use a minimum timeoutof, say, 5 minutes (300 seconds) for P2P applications, i.e.,configure the middlebox with this idle-timeout for the portbindings for the ports set aside for P2P use. Middleboximplementers are often tempted to use a shorter one, as they areaccustomed to doing currently. But, short timeouts areproblematic. Consider a P2P application that involved 16 peers.They will flood the network with keepalive packets every 10seconds to avoid NAT timeouts. This is so because one mightsend them 5 times as often as the middlebox‘s timeout just incase the keepalives are dropped in the network.5.6. Support loopback translationWe strongly recommend that middlebox implementers supportloopback translation, allowing hosts behind a middlebox tocommunicate with other hosts behind the same middlebox throughtheir public, possibly translated endpoints. Support forloopback translation is particularly important in the caseof large-capacity NATs that are likely to be deployed as thefirst level of a multi-level NAT scenario. As described insection 3.3.3, hosts behind the same first-level NAT butdifferent second-level NATs have no way to communicate witheach other by UDP hole punching, even if all the middleboxespreserve endpoint identities, unless the first-level NATalso supports loopback translation.6. Security ConsiderationsFollowing the recommendations in this document should notinherently create new security issues, for either theapplications or the middleboxes. Nevertheless, new securityrisks may be created if the techniques described here arenot adhered to with sufficient care. This section describessecurity risks the applications could inadvertently createin attempting to support P2P communication across middleboxes,and implications for the security policies of P2P-friendlymiddleboxes.6.1. IP address aliasingP2P applications must use appropriate authentication mechanismsto protect their P2P connections from accidental confusion withother P2P connections as well as from malicious connectionhijacking or denial-of-service attacks. NAT-friendly P2PFord, Srisuresh & Kegel [Page 22]Internet-Draft P2P applications across middleboxes October 2003applications effectively must interact with multiple distinctIP address domains, but are not generally aware of the exacttopology or administrative policies defining these addressdomains. While attempting to establish P2P connections viaUDP hole punching, applications send packets that may frequentlyarrive at an entirely different host than the intended one.For example, many consumer-level NAT devices provide DHCPservices that are configured by default to hand out site-localIP addresses in a particular address range. Say, a particularconsumer NAT device, by default, hands out IP addresses startingwith 192.168.1.100. Most private home networks using that NATdevice will have a host with that IP address, and many of thesenetworks will probably have a host at address 192.168.1.101 aswell. If host A at address 192.168.1.101 on one private networkattempts to establish a connection by UDP hole punching withhost B at 192.168.1.100 on a different private network, then aspart of this process host A will send discovery packets toaddress 192.168.1.100 on its local network, and host B will senddiscovery packets to address 192.168.1.101 on its network. Clearly,these discovery packets will not reach the intended machine sincethe two hosts are on different private networks, but they are verylikely to reach SOME machine on these respective networks at thestandard UDP port numbers used by this application, potentiallycausing confusion. especially if the application is also runningon those other machines and does not properly authenticate itsmessages.This risk due to aliasing is therefore present even without amalicious attacker. If one endpoint, say host A, is actuallymalicious, then without proper authentication the attacker couldcause host B to connect and interact in unintended ways withanother host on its private network having the same IP addressas the attacker‘s (purported) private address. Since the twoendpoint hosts A and B presumably discovered each other througha public server S, and neither S nor B has any means to verifyA‘s reported private address, all P2P applications must assumethat any IP address they find to be suspect until they successfullyestablish authenticated two-way communication.6.2. Denial-of-service attacksP2P applications and the public servers that support them mustprotect themselves against denial-of-service attacks, and ensurethat they cannot be used by an attacker to mount denial-of-serviceattacks against other targets. To protect themselves, P2Papplications and servers must avoid taking any action requiringsignificant local processing or storage resources untilFord, Srisuresh & Kegel [Page 23]Internet-Draft P2P applications across middleboxes October 2003authenticated two-way communication is established. To avoid beingused as a tool for denial-of-service attacks, P2P applications andservers must minimize the amount and rate of traffic they send toany newly-discovered IP address until after authenticated two-waycommunication is established with the intended target.For example, P2P applications that register with a public rendezvousserver can claim to have any private IP address, or perhaps multipleIP addresses. A well-connected host or group of hosts that cancollectively attract a substantial volume of P2P connection attempts(e.g., by offering to serve popular content) could mount adenial-of-service attack on a target host C simply by including C‘sIP address in their own list of IP addresses they register with therendezvous server. There is no way the rendezvous server can verifythe IP addresses, since they could well be legitimate privatenetwork addresses useful to other hosts for establishingnetwork-local communication. The P2P application protocol musttherefore be designed to size- and rate-limit traffic to unverifiedIP addresses in order to avoid the potential damage such aconcentration effect could cause.6.3. Man-in-the-middle attacksAny network device on the path between a P2P client and arendezvous server can mount a variety of man-in-the-middleattacks by pretending to be a NAT. For example, supposehost A attempts to register with rendezvous server S, but anetwork-snooping attacker is able to observe this registrationrequest. The attacker could then flood server S with requeststhat are identical to the client‘s original request except witha modified source IP address, such as the IP address of theattacker itself. If the attacker can convince the server toregister the client using the attacker‘s IP address, then theattacker can make itself an active component on the path of allfuture traffic from the server AND other P2P hosts to theoriginal client, even if the attacker was originally only ableto snoop the path from the client to the server.The client cannot protect itself from this attack byauthenticating its source IP address to the rendezvous server,because in order to be NAT-friendly the application MUST allowintervening NATs to change the source address silently. Thisappears to be an inherent security weakness of the NAT paradigm.The only defense against such an attack is for the client toauthenticate and potentially encrypt the actual content of itscommunication using appropriate higher-level identities, so thatthe interposed attacker is not able to take advantage of itsposition. Even if all application-level communication isFord, Srisuresh & Kegel [Page 24]Internet-Draft P2P applications across middleboxes October 2003authenticated and encrypted, however, this attack could still beused as a traffic analysis tool for observing who the client iscommunicating with.6.4. Impact on middlebox securityDesigning middleboxes to preserve endpoint identities does notweaken the security provided by the middlebox. For example, aPort-Restricted Cone NAT is inherently no more "promiscuous"than a Symmetric NAT in its policies for allowing eitherincoming or outgoing traffic to pass through the middlebox.As long as outgoing UDP sessions are enabled and the middleboxmaintains consistent binding between internal and externalUDP ports, the middlebox will filter out any incoming UDP packetsthat do not match the active sessions initiated from within theenclave. Filtering incoming traffic aggressively while maintainingconsistent port bindings thus allows a middlebox to be"peer-to-peer friendly" without compromising the principle ofrejecting unsolicited incoming traffic.Maintaining consistent port binding could arguably increase thepredictability of traffic emerging from the middlebox, by revealingthe relationships between different UDP sessions and hence aboutthe behavior of applications running within the enclave. Thispredictability could conceivably be useful to an attacker inexploiting other network or application level vulnerabilities.If the security requirements of a particular deployment scenarioare so critical that such subtle information channels are ofconcern, however, then the middlebox almost certainly should not beconfigured to allow unrestricted outgoing UDP traffic in thefirst place. Such a middlebox should only allow communicationoriginating from specific applications at specific ports, orvia tightly-controlled application-level gateways. In thissituation there is no hope of generic, transparent peer-to-peerconnectivity across the middlebox (or transparent client/serverconnectivity for that matter); the middlebox must eitherimplement appropriate application-specific behavior or disallowcommunication entirely.7. AcknowledgmentsThe authors wish to thank Henrik, Dave, and Christian Huitemafor their valuable feedback.8. References8.1. Normative referencesFord, Srisuresh & Kegel [Page 25]Internet-Draft P2P applications across middleboxes October 2003[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee,"Bidirectional Peer-to-Peer Communication with InterposingFirewalls and NATs", August 2001.http://www.peer-to-peerwg.org/tech/nat/[KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999.http://www.alumni.caltech.edu/~dank/peer-nat.html[MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, andA. Rayhan, "Middlebox communication architecture andframework", RFC 3303, August 2002.[NAT-APPL] D. Senie, "Network Address Translator (NAT)-FriendlyApplication Design Guidelines", RFC 3235, January 2002.[NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complicationswith the IP Network Address Translator", RFC 3027,January 2001.[NAT-PT] G. Tsirtsis and P. Srisuresh, "Network AddressTranslation - Protocol Translation (NAT-PT)", RFC 2766,February 2000.[NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network AddressTranslator (NAT) Terminology and Considerations", RFC2663, August 1999.[NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP NetworkAddress Translator (Traditional NAT)", RFC 3022,January 2001.[STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy,"STUN - Simple Traversal of User Datagram Protocol (UDP)Through Network Address Translators (NATs)", RFC 3489,March 2003.8.2. Informational references[ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE):A Methodology for Network Address Translator (NAT) Traversalfor the Session Initiation Protocol (SIP)",draft-rosenberg-sipping-ice-00 (Work In Progress),February 2003.[RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro,"Realm Specific IP: Framework", RFC 3102, October 2001.[SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, andFord, Srisuresh & Kegel [Page 26]Internet-Draft P2P applications across middleboxes October 2003L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.[SYM-STUN] Y. Takeda, "Symmetric NAT Traversal using STUN",draft-takeda-symmetric-nat-traversal-00.txt (Work InProgress), June 2003.[TCP] "Transmission Control Protocol", RFC 793, September 1981.[TEREDO] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs",draft-ietf-ngtrans-shipworm-08.txt (Work In Progress),September 2002.[TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema,"Traversal Using Relay NAT (TURN)",draft-rosenberg-midcom-turn-01 (Work In Progress),March 2003.[UPNP] UPnP Forum, "Internet Gateway Device (IGD) StandardizedDevice Control Protocol V 1.0", November 2001.http://www.upnp.org/standardizeddcps/igd.asp9. Author‘s AddressBryan FordLaboratory for Computer ScienceMassachusetts Institute of Technology77 Massachusetts Ave.Cambridge, MA 02139Phone: (617) 253-5261E-mail: baford@mit.eduWeb: http://www.brynosaurus.com/Pyda SrisureshCaymas Systems, Inc.11799-A North McDowell Blvd.Petaluma, CA 94954Phone: (707) 283-5063E-mail: srisuresh@yahoo.comDan KegelKegel.com901 S. Sycamore Ave.Los Angeles, CA 90036Phone: 323 931-6717Email: dank@kegel.comWeb: http://www.kegel.com/Ford, Srisuresh & Kegel [Page 27]Internet-Draft P2P applications across middleboxes October 2003Full Copyright StatementCopyright (C) The Internet Society (2003). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain itor assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph areincluded on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Ford, Srisuresh & Kegel [Page 28]