INTERNET DRAFT A. C. Snoeren Expires May 2001 MIT LCS H. Balakrishnan MIT LCS November 2000 TCP Connection Migration Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document describes a set of TCP options to support the migration of an active TCP connection across IP addresses and TCP port numbers. Using this option, a TCP peer can open a migrateable connection, transfer one or more bytes on it, and continue the connection from another IP address/TCP port pair in an application-transparent fashion. The set of addresses or ports from where a connection might be continued need not be known in advance. Security against connection hijacking is achieved using a secret cryptographic cookie negotiated through an Elliptic Curve Diffie-Hellman [ANSI-X962] exchange during connection establishment. The initiation of migration can be done either by one of the communicating peers, or by a trusted third-party that presents the negotiated cryptographic Snoeren & Balakrishnan [Page 1] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 cookie. TCP connection migration has several applications, including preserving TCP communication across host mobility in the Internet, and inter-host migration of connections for fault-tolerance or load- balancing. Furthermore, unlike previous approaches such as ETCP [Huitema95], the Migrate options require no modification to the TCP header, packet format, or semantics, and can be initiated by a trusted node different from the communicating peers. Introduction A TCP connection [RFC-793] is associated with a particular IP address and TCP port pair. When one of the communicating peers changes its IP address, all TCP on-going connections are terminated. This document describes a set of TCP options to migrate connections from one IP address to another, thereby permitting on-the-fly re- addressing of end-hosts. In-progress connections may also change port numbers, enabling them to function correctly across legacy Network Address Translators (NATs) and Port Address Translators (PATs) [RFC-2663]. Although TCP connections today are bound to particular IP addresses, most TCP applications communicate with end-hosts or end-services. An end-host (e.g., a desktop or mobile computer) may have multiple network interfaces on it, or have one interface whose address changes due to mobility, while an end-service (e.g., a Web server) may be replicated on several different computers on the Internet. Most TCP applications open a connection to a name, which gets resolved by the Domain Name System (DNS) to an IP address. If the IP address associated with the name were to change for any reason, connections in progress cannot continue. The TCP migration options are motivated by the desire for a TCP that can work across changes in name-to- address mappings, e.g., due to host mobility, or server-to-server migration of one end-point of a connection for fail-over or load- balancing reasons. The Migrate options allow hosts to divert established TCP connections to a new IP address/TCP port pair by referencing them with a cryptographic cookie, which protects against connection hijacking by malicious parties. This cookie is established using an Elliptic Curve Diffie-Hellman key exchange during the establishment of the initial connection [ANSI-X962]. The security provided by this cryptographic cookie also allows a trusted host other than the communicating peers to take over a connection. Any host with knowledge of the cookie can request migration of the connection, allowing servers in a cluster to continue servicing a client of a failed server. Snoeren & Balakrishnan [Page 2] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 Document Conventions The terms "migrating host" and "mobile host" are used to refer to the TCP peer that is being re-addressed. The connection, however, is completely symmetric. Either (or both) peer(s) may move after the connection is established, but not at the same time. During a migration by the migrating host, the peer TCP host is referred to as the fixed host. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Background Mobile IP [Perkins] supports re-addressing and could be used in this context, but has two major drawbacks. First, all traffic to a mobile host must (at least initially) travel via the home agent. The necessity of a home agent can be a significant burden, especially in ad-hoc networks of devices. Additionally, depending on the network topology, packets routed through the home agent may travel a significantly longer path than necessary. Secondly, packets sent by the mobile host use the mobile's home address as the source address. It is often the case that this source address does not topologically belong to the subnet that the mobile is currently attached to. Current firewalls and secure routers often block such traffic to prevent IP spoofing. As an alternative, packets may be "reverse tunnelled" back to the home agent before being sent to the destination using the host's home IP address. Unfortunately, this imposes the "trangle routing" penalty described above on packets leaving the mobile host as well. More importantly, however, Mobile IP requires that the original (home) address continue to be allocated to the mobile host. In cases when the available address space is small, such a restriction may make re-addressing prohibitive. One would like the mobile node's previous address to be immediately reusable by another host. The widespread adoption of the incrementally-deployable migration options described in this document will obviate the need for network- layer approaches like Mobile IP to handle host mobility for TCP applications. Furthermore, many mobile computers use multiple network interfaces; selecting between them based on the available connectivity and network performance on a per-connection basis is supported by connection migration. The TCP migrate option avoids these drawbacks, but functions only for Snoeren & Balakrishnan [Page 3] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 TCP. UDP-based protocols typically fall into two classes: short transactions and longer streams. Transactional protocols, such as DNS and Remote Procedure Call (RPC) protocols are typically mostly stateless and involve at most a small number of packets. Although the server in such protocols might move, locating it is a matter of determining the most current name-to-address binding, which can be done using dynamic DNS [RFC-2136]. It is, of course, possible for the requesting host to have moved concurrently, but in a network where the probability of this occurring is significantly smaller than the probability of multiple packet losses (as is typically expected in today's Internet), an application-level retry (consisting of a DNS lookup) of the form used for loss recovery should suffice. UDP-based unicast streaming applications, on the other hand, tend to make use of an application-level protocol like RTP [RFC-1889] to implement a connection-like abstraction. Although this document does not describe any details, we expect that a connection migration scheme for such protocols to be easy to develop, similar to the one for TCP proposed herein. Alternatively, the Transport Area Working Group has recently proposed the Stream Control Transport Protocol (SCTP) [SCTP], which provides similar "multi-homing" functionality, although the semantics provided by the current draft are not as amenable to address changes. Extending the lives of TCP connections across address changes is not a new idea. A proposal based on a "context identifier" (essentially equivalent to our cryptographic cookie) was proposed by Huitema [Huitema95] and Steve Deering. However, these identifiers were passed in the clear, so any eavesdropper could hijack the connection quite easily. Huitema's "Multi-homed TCP" allowed multiple concurrent addresses on both ends of the connection, but required a new protocol, extended TCP (ETCP) to be deployed on the end hosts [Huitema95]. While our proposal limits the connection to one active address per peer at a time, it requires significantly less modification to the TCP stack, and is compatible with many protocol-based firewalls, filters, and such "middle boxes" that are a reality of today's Internet infrastructure. Alternative techniques, aimed at separating routing identifiers (e.g., IP addresses) from endpoint identification (e.g., permanent endpoint identifiers, often called EIDs), have been proposed. We believe that such proposals are worthy of research, but that they are likely to incur greater deployment costs. The approach proposed in this document is rather different, since it does not require additional level of global addressing or indirection, but only a (normally pre-existing) DNS entry for endpoint identification. Snoeren & Balakrishnan [Page 4] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 Furthermore, any technique based upon "permanent identifiers" only pushes the problem one level higher, and awaits the time when those too need to be re-assigned. Basic Approach The Migrate Options facilitate rebinding TCP connections to a new address/port pair that need not be known a priori. This differs for the "multi-homing" capability found in SCTP [SCTP], which requires the set of approved addresses for the connection to be negotiated in advance. Further, standard TCP connection semantics are preserved for transparent operation in the presence of legacy network infrastructure such as NATs or PEPs. Finally, this is achieved with signalling sent only on connection establishment--individual data segments have no additional overhead. Fundamentally, the Migrate options allows corresponding hosts to synchronize two separate TCP connections such that the context is identical. In particular, establishment of the second connection terminates the first, and transfers the original TCB to the second connection, except for the IP address/port binding, and congestion control state. This allows TCP (and any of its attending options) to function properly across both connections, regardless of its current state. By establishing a completely separate connection to continue communication, the correspondent hosts may conspire to support connection migration without the network's knowledge or consent. Both connections appear to be standard TCP connections (except for the new options passed in the SYN packets), so stateful firewalls, NATs, PATs, and the like will not interfere with proper operation. The migration process consists of two parts: an initial key exchange conducted during the three-way handshake, and a migration request. In order for a connection to by migrateable, the correspondent hosts must first exchange Migrate-Permitted Options during the SYN handshake. This negotiates a shared connection token, which is then used to identify the connection in later Migrate Requests (as opposed to the IP address/port pair, which may change). At any point after the initial SYN handshake (while the connection is in either ESTABLISHED or FIN-WAIT) either host may attempt to establish a second connection (from a new address/port pair) containing a Migrate Request option. This Migrate Request option contains the token referencing the previously established connection. If the request meets various security requirements described below, the correspondent host terminates the first connection (without Snoeren & Balakrishnan [Page 5] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 emitting any further packets) and instantiates the second connection with a TCB identical to the first. The new connection is associated with the same socket (application) as the first. In practice, this is often implemented by simply modifying the TCB of the first connection rather than allocating an entirely new one. Migrate-Permitted Option This variable-length option SHOULD be sent in SYN segments by a TCP that has been extended to support the Migrate options. It MUST NOT be sent on non-SYN segments. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind: # | Length = 3/20 | Curve ID | Key Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Data (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Data (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Data (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Data (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Migrate-Permitted Option Format The Migrate-Permitted option has two varieties. It may either specify the non-secured variant of the Migrate Options (NOT RECOMMENDED) or the secure version. The non-secure version has length 3, and contains a zero in the Curve ID field. The secured version has length 20 and contains two fields, a one byte Curve ID field and 17 bytes of Key data. The Curve ID contains one of a predefined set of values to select a particular set of Elliptic Curve parameters. The Key Data contains the most significant 17 bytes of the 25 bytes of Key Data used to compute the secret connection token. In order to support key lengths up to 200 bits, the remaining 8 bytes of Key Data are transmitted in the Timestamp option [RFC-1323], which MUST be included on any SYN packet containing a non-secure variant of the Migrate-Permitted Option. The least significant 4 bytes are transmitted in the Time Stamp Echo Reply (TSecr) field, and the remaining 4 bytes are transmitted in the Time Stamp Value (TSval) field. Snoeren & Balakrishnan [Page 6] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 Migrate Option The Migrate option is used to request the migration of a currently open TCP connection to a new address. A variable-length option, it may only be sent in a SYN segment to a host with which a previously- established connection already exists (in the ESTABLISHED or FIN-WAIT states), over which the Migrate-Permitted option has been negotiated. It MUST NOT be sent in non-SYN segments. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |///////////////| Kind: # | Length = 19 |P| ReqNo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Migrate Option Format A 19-byte option, the Migrate Option includes four fields. There are two 64-bit fields in a Migrate option: a Token, and a Request. In addition, there is a 7-bit sequence number field, ReqNo, which must be monotonically increasing with each new migrate request issued by an end host for a connection, and a 1 bit Preload flag field. The Preload flag SHOULD be zero, unless the Migrate Option is sent by a host other than one of the original two corresponding hosts. Migrate-Permitted Processing A host wishing to establish a migrateable connection MUST include a Migrate-Permitted option in the initial SYN segment. For the insecure variant, the length MUST be 3, and the Curve ID field set to zero. In the secure variant, the Curve ID must contain a defined value specifying a particular set of Elliptic Curve domain parameters. In particular, each set of domain parameters contains a finite field, F, a generating point P, and the order of P, n. The Key Data field MUST contain a randomly generated public key, k, generated over the field F by selecting a random number X in the range [1,n-1] and computing k = X * P, Snoeren & Balakrishnan [Page 7] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 where the * operation is the scalar multiplication operation over the field F. The securing of the connection hinges on the secrecy of the negotiated key, hence X should be randomly generated and stored in the control block for each new connection. Any retransmissions of the SYN packet MUST contain the same values in the Migrate-Permitted Option. Upon receipt of an initial SYN (without an ACK) with a Migrate- Permitted Option, a compliant TCP MUST include a Migrate-Permitted Option in its SYN/ACK segment or send a RST. If a SYN/ACK is sent, the length and Curve ID MUST be identical to those in the received SYN segment. If the secure variant is transmitted, it must be transmitted along with a Timestamp option, and contain a random public key selected as described above. If the implementation does not support the domain parameters corresponding to the Curve ID in the received option, it MUST NOT include a secure Migrate-Permitted option in its SYN/ACK. Any necessary retransmissions of SYN or SYN/ACKs MUST include identical values for the Migrate-Permitted option, if present. A compliant host receiving a SYN/ACK with the Migrate-Permitted option set MUST compare the Curve ID. If they differ, a RST MUST be sent and the connection aborted as in [RFC-793]. If both acceptable, secure-variant Migrate-Permitted Options are received by both hosts, they MUST compute a shared secret key, K, using their random value, X, and received public key, k, K = k * X, where * is the same operation as before. If the indicated domain parameters result in a key of length less than 200 bits, the value MUST be left padded with zeros to 200 bits. If the unsecured variant is negotiated, K MUST be set to all zeros. The secret key is then used to compute a connection validation token T, by computing the SHA-1 hash of the initial sequence numbers of the SYN (Ni) and SYN/ACK (Na) packets as: T = SHA-1(Ni, Na, K) SHA-1 produces a 160-bit hash, of which only the 64 most significant bits are retained, and stored in the connections TCB. Timestamp Option Processing As stated above, the TSecr and TSval fields of a Timestamp option sent in the same SYN segment as a Migrate-Permitted option MUST contain the least significant 8 bytes of the Migrate-Permitted Key Snoeren & Balakrishnan [Page 8] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 Data field. Hence these values MUST NOT be used in either of the algorithms specified in [RFC-1323]. We note that both Protection Against Wrapped Sequence Numbers (PAWS) and the Round-Trip Time Measurement (RTTM) are performed only on Synchronized connections, hence a compliant TCP stack should not operate on these values in a SYN segment in any event. The ramifications of the Migrate-Permitted option's interaction with the Timestamp option are two-fold. First, a Migrate-compliant host MOST NOT echo the value contained in the TSval from the SYN segment in the Timestamp option of its SYN/ACK. Instead, it should fill both the TSval and TSecr fields of the Timestamp option as described above. Secondly, a host receiving a SYN/ACK with the Migrate- Permitted option MUST NOT perform either a PAWS check or a RTTM calculation on the values in the Timestamp option. It should, however, echo the value in the TSval back in the TSecr field of its next segment, as specified in [RFC-1323]. After the three-way handshake, timestamp processing SHOULD proceed as specified in [RFC-1323]. Before Migration If a connection becomes aware that its address/port pair is about to change, the migrating host SHOULD pause transmission of all buffered TCP traffic, and MAY generate a duplicate ACK advertising a receive window size of zero to suppress further data transmissions from the fixed host. Requesting Migration If the host requesting migration is not the original host, it MUST preload the TCB with the appropriate state extracted from the TCB at the previous host. This data can be stale (the current sequence space information, for example), but must be from the original connection. In any event, before resuming communication, the congestion-related state of the TCP connection must be reset to initial slow-start conditions in order to re-discover the properties of the new path in both directions. After the host has determined its new address, a SYN segment SHOULD be generated including a Migrate Option, using the sequence number of the most recently acknowledged byte. The Token field should be filled with the Token previously computed and stored in the TCB. The ReqNo field MUST contain a monotonically increasing number in the range [0-127], with standard sequence number wraparound. The Request field MUST contain the the following computed value: Snoeren & Balakrishnan [Page 9] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 R = SHA-1(Ni, Na, K, S, ReqNo) where Ni and Na are the initial sequence numbers for the connection as before, K is the secret key, ReqNo is the ReqNo field from this option, and S is the sequence number of this SYN segment. If the connection had previously negotiated the non-secured variant, K should simply be all zeros. This SYN segment MUST NOT contain any options except the Migrate option. TCP MUST then move the connection to the SYN-SENT state. Upon receipt of a SYN/ACK, the connection then resumes as before, with all previously negotiated options enabled. The sequence number in the ACK field of the SYN/ACK should be treated as an acknowledgement of data transmitted with that sequence number, and not of the SYN segment (the SYN segment need not be explicitly acknowledged). Further, if the Preload flag was set (meaning this host was not an original end point), it should examine the sequence number of the SYN/ACK and consider that the most recently acknowledged segment. Migrate Option Processing Upon receipt of a SYN packet with the Migrate Option set, a TCP stack that supports migration MUST attempt to locate the connection associated with the provided Token. If none is found, a RST MUST be generated and the SYN ignored. Otherwise, the ReqNo should be compared to the most recently received ReqNo on this connection. If it is not larger, this SYN packet MUST be treated as a duplicated and handled accordingly. If it is greater, the host should generate a request as described above and compared it to the received packet. If they do not match, the host MUST generate a RST segment and continue. Only if the Request matches should the host update its stored value of the ReqNo and change the address and port in the TCB to match that of the received IP datagram. After altering the TCB, a SYN/ACK packet should be generated using the sequence number of the last successfully ACKNOWLEDGED byte of data, and the ACK field set to acknowledge that last data packet on the previous connection (the sequence number in the SYN packet is ignored), and the connection placed in the SYN-RCVD state. Further, the congestion-related state of the connection MUST be reset to initial values. Upon receipt of an ACK, the connection continues as before. If the received Migrate Option has the Preload flag set, the connection MUST flush any previously-received out-of-order packets and corresponding SACK blocks. Snoeren & Balakrishnan [Page 10] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 SYN Processing SYN packets may now correctly arrive on a bound port not in the LISTEN state. They should be processed only if they contain the Migrate Option as specified above. Otherwise, they should be treated as specified in [RFC-793]. RST Processing Migration requires additional care when handling RST packets, as an unfortunate circumstance may arise when the address used to establish a migrateable connection has been reassigned, and transmitted packets reach a new host with the same address before the old host has had a chance to properly migrate the connection. In this case, a RST packet will be generated by the new host. [RFC-793] specifies that connections should be immediately closed upon receipt of a RST when in the ESTABLISHED state. If, however, the connection had negotiated the Migrate-Permitted option, it MUST NOT be immediately closed. Instead, it should be placed in a new MIGRATE-WAIT state. MIGRATE-WAIT State TCP connections in the MIGRATE-WAIT state SHOULD NOT emit any segments, instead, they MUST wait until either a SYN packet with the Migrate option is received, which will resume the connection, or the appropriate timeout (identical to the TIME-WAIT state) has occurred, in which case the connection is closed. Any packets received while in the MIGRATE-WAIT state should be processed as in the ESTABLISHED state, except that no ACKs should be generated. Further, any RST packets received in the MIGRATE-WAIT state MUST be ignored. Security Considerations The ability to blindly hijack connections is dangerous. It is therefore of paramount importance that the cookie is cryptographically secure, such that it is highly unlikely an attacker can guess the appropriate cookie to hijack a connection. The cryptographic security of a cookie generated using the Elliptic Curve Diffie-Hellman technique described in this document is fundamentally based on the quality of the random number generator used. Snoeren & Balakrishnan [Page 11] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 Firewalls Many currently-deployed firewalls enforce restrictions on the directions in which TCP connections can be established. Most do so by monitoring network traffic for TCP SYN packets, and blocking those traveling in the wrong direction. The Migrate Option requires sending a SYN packet from the mobile host to the fixed host. Depending on the direction the connection was originally established, this may or may not be permitted by the firewall. IPsec Interactions Note that Security Associations are established on a address basis. When a TCP connection with an associated SA is migrated, a new SA MUST be established with the new destination address before communications are resumed. If the establishment of a this new SA would conflict with existing policy, the connection MUST be closed. Denial of Service SYN packets carrying invalid Tokens are rejected immediately, so no additional resources are wasted processing invalid packets. Hence the TCP migrate option introduces no additional security concerns in addition to standard TCP, modulo the cryptographic security of the cookie used to migrate connections. Acknowledgments We thank Allison Mankin for encouraging us to document the Migrate options in this form and Dave Andersen for his comments on earlier versions of this document. Authors' Addresses: Alex C. Snoeren MIT Laboratory for Computer Science 200 Technology Square Cambridge, MA 02139 USA Phone: +1 617 452-2820 Email: snoeren@lcs.mit.edu Web: http://www.mit.edu/~snoeren/ Hari Balakrishnan MIT Laboratory for Computer Science 200 Technology Square Cambridge, MA 02139 USA Snoeren & Balakrishnan [Page 12] Internet Draft draft-snoeren-tcp-migrate-00.txt November 2000 Phone: +1 617 253-8713 Email: hari@lcs.mit.edu Web: http://nms.lcs.mit.edu/~hari/ References [ANSI-X962] American National Standards Institute, "Public Key Cryptography for the financial security industry: The Elliptic Curve Digital Signature Algorithm. ANSI X9.62-1998, January 1999. [Huitema95] Huitema, C., "Multi-homed TCP", Internet Draft, May 1995. Now expired. [Perkins] Perkins, C., "IP Mobility Support for IPv4, revised", Internet Draft, October 1999. [RFC-793] Postel, J., "Transmission Control Protocol", STD 5, RFC 793, September 1981. [RFC-1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 5, RFC 1122, August 1989. [RFC-1323] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-2136] Vixie, P., et al., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC-2401] Kent, S., and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC-2663] Srisuresh, P., and Holdrege, M., "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [SCTP] Stewart, R., et al., "Stream Control Transmission Protocol", Internet Draft, draft-ietf-sigran-sctp-13.txt, July 2000. Snoeren & Balakrishnan [Page 13]