INTERNET DRAFT M. Borella Expires April 2000 D. Grabelsky 3Com Corp. J. Lo K. Tuniguchi NEC USA October 1999 Realm Specific IP: Protocol Specification 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. Abstract This draft presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP client and server. This protocol is designed to operate as an application and to use its own TCP or UDP port. In particular, the protocol allows a server to allocate addressing and control parameters to a client such that a flow policy can be enforced at the server. 1. Introduction Network Address Translation (NAT) has gained popularity as a method Borella et al. Expires April 2000 [Page 1] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 of separating public and private address spaces, and alleviating network address shortages. A NAT translates the addresses of packets leaving a first routing realm to an address from a second routing realm, and performs the reverse function for packets entering the first routing realm from the second routing realm. This translation is performed transparently to the hosts in either space, and may include modification of TCP/UDP port numbers and IP addresses in packets that traverse the NAT. While a NAT does not require hosts to be aware of the translation, it will require an application layer gateway (ALG) for any protocol that transmits IP addresses or port numbers in packet payloads (such as FTP). Additionally, a NAT will not work with protocols that require IP addresses and ports to remain unmodified between the source and destination hosts, or protocols that prevent such modifications to occur (such as some IPSEC modes, or application-layer end-to-end encryption). An alternative to a NAT is an architecture that allows the clients within the first (e.g., private) routing realm to directly use addresses and other routing parameters from the second (e.g., public) routing realm. Thus, RSIP [RSIP-FRAME] has been defined a method for address sharing that exhibits more transparency than NAT. In particular, RSIP requires that an RSIP server (a router or gateway between the two realms) assign at least one address from the second routing realm, and perhaps some other resources, to each RSIP client. An RSIP client is a host in the first routing realm that needs to establish end-to-end connectivity to a host, entity or device in the second routing realm. Thus, the second routing realm is not directly accessible from RSIP client, but this system allows packets to maintain their integrity from RSIP client to their destination. ALGs are not required in the RSIP server. RSIP requires that hosts be modified so that they place some number of layer three, layer four or other values from those assigned by the RSIP server in each packet bound for the second routing realm. This draft discusses a method for assigning parameters to an RSIP client from an RSIP server. The requirements, scope, and applicability of RSIP, as well as its interaction with other layer 3 protocols, are discussed in a companion framework draft [RSIP-FRAME]. RSIP interaction with IPSEC is discussed in [RSIP-IPSEC]. 2. Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this document are to be interpreted as described in [RFC2119]. Borella et al. Expires April 2000 [Page 2] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 3. Terminology Private Realm A routing realm that uses private IP addresses from the ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in [RFC1918], or addresses that are non-routable from the Internet. Public Realm A routing realm with unique network addresses assigned by the Internet Assigned Number Authority (IANA) or an equivalent address registry. RSIP Server A router situated on the boundary between a private realm and a public realm and owns one or more public IP addresses. An RSIP server is responsible for public parameter management and assignment to RSIP clients. An RSIP server may act as a normal NAT router for hosts within the private realm that are not RSIP enabled. RSIP Client A host within the private realm that acquires publicly unique parameters from an RSIP server through the use of RSIP. RSA-IP: Realm Specific Address IP An RSIP method in which each RSIP client is allocated a unique IP address from the public realm. Discussed in detail in [RFC2663] RSAP-IP: Realm Specific Address and Port IP An RSIP method in which each RSIP client is allocated an IP address (possibly shared with other RSIP clients) and some number of per-address unique ports from the public realm. Discussed in detail in [RFC2663] Binding An association of some combination of a local IP address, one or more local ports, a remote IP address, and a remote port with an RSIP client. All other terminology found in this document is consistent with that of [RFC2663] and [RSIP-FRAME]. Borella et al. Expires April 2000 [Page 3] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 4. Architecture For simplicity, for the remainder of this document we will assume that the RSIP clients in the first routing realm (network) use private (e.g. see [RFC1918]) IP addresses, and that the second routing realm (network) uses public IP addresses. The RSIP server connects the public and private realms and contains interfaces to both. Other NAT terminology found in this document is defined in [RFC2663]. The diagram below describes an exemplary reference architecture for RSIP. Some number of RSIP clients are attached via a private network to an RSIP server, which also acts as a router or gateway between the private and public networks. This router has been assigned some number of public addresses that it may use or allocate for use on the public network. +-------------+ | RSIP client | | 1 +--+ | 10.0.0.2 | | +-------------+ +-------------+ | 10.0.0.1 | | 149.112.240.0/24 +-----------------+ RSIP server +------------------- +-------------+ | | | | RSIP client | | +-------------+ | 2 +--+ private public | 10.0.0.3 | | network network +-------------+ | | | ... 5. Client / Server States An RSIP client can be in exactly one of three fundamental states with respect to an RSIP server: Unregistered: The RSIP server does not know of the RSIP client's existence, and it will not forward or deliver packets on behalf of the client. The only valid RSIP-related action for a client to perform in this state is to request registration with an RSIP server. Registered: The RSIP server knows of the RSIP client and has assigned it a client ID and has specified the flow policies that it requires of the client. However, no resources, such as addresses or ports, have been allocated to the client, and the server will not forward or deliver packets on behalf of the client. Borella et al. Expires April 2000 [Page 4] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 Assigned: The RSIP server has granted one or more bindings of resources to the client. The server will forward and deliver packets on behalf of the client. Architectures in which an RSIP client is associated with more than one RSIP server are possible. In such cases, an RSIP client may be simultaneously in different states with different RSIP servers. 6. Server Flow Policy and State Since an RSIP server is likely to reside on the boundary between two or more different administrative domains, it is desirable to enable an RSIP server to be able to enforce flow-based policy. In other words, an RSIP server should have the ability to explicitly control which local addresses and ports are used to communicate with remote addresses and ports. In the following, macro-flow policy refers to controlling flow policy at the granularity level of IP addresses, while micro-flow policy refers to controlling flow policy at the granularity of IP address and port tuples. Of course there may be no policy at all, which indicates that the RSIP server does not care about the flow parameters used by RSIP clients. We consider two levels of local flow policy and three levels of remote flow policy. 6.1. Local Flow Policy Local flow policy determines the granularity of control that an RSIP server has over the addressing parameters that an RSIP client uses for particular sessions. Since an RSIP client must use at least an IP address allocated by the server, the loosest level of local flow policy is macro-flow based. Under local macro-flow policy, an RSIP client is allocated an IP address (RSA-IP) or an IP address and one or more ports to use with it (RSAP-IP). However, the client may use the ports as it desires for establishing sessions with public hosts. Under micro-flow policy, a client is allocated exactly one port at a time. The client may request more ports, also one at a time. This policy gives the server very tight control over local port use, although it affords the client less flexibility. Note that only local macro-flow policy can be used with RSA-IP, while either local macro-flow or local micro-flow policy may be used with RSAP-IP. Examples of how RSIP flow policy operates are given in Appendix C. Borella et al. Expires April 2000 [Page 5] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 6.2. Remote Flow Policy Remote flow policy determines the granularity of control that an RSIP server has over the remote (public) hosts with which an RSIP client communicates. In particular, remote flow policy dictates what level of detail that a client must specify addressing parameters of a remote host before the RSIP server allows the client to communicate with that host. The simplest and loosest form of flow policy is no policy at all. In other words, the RSIP server allocates addressing parameters to the client, and the client may use these parameters to communicate with any remote host, without specifically notifying the server. Macro-flow policy requires that the client identify the remote address of the host that it wishes to communicate with as part of its request for local addressing parameters. If the request is granted, the client MUST use the specified local parameters only with the remote address specified, and MUST NOT communicate with the remote address using any local parameters but the ones allocated. However, the client may contact any port number at the remote host without explicitly informing the server. Micro-flow policy requires that the client identify the remote address and port of the host that it wishes to communicate with as part of its request for local addressing parameters. If the request is granted, the client MUST use the specified local parameters only with the remote address and port specified, and MUST NOT communicate with the remote address and port using any local parameters but the ones allocated. Remote flow policy is implemented in both the ingress and egress directions, with respect to the location of the RSIP server. 6.3. Server State An RSIP server must maintain state for all RSIP clients and their assigned resources. The amount and type of state maintained depends on the local and remote flow policy. The required RSIP server state will vary based on the RSIP method, but will always include the chosen method's demultiplexing parameters. 6.3.1. RSA-IP State An RSIP server serving an RSIP client using the RSA-IP method MUST maintain the following minimum state to ensure proper mapping of incoming packets to RSIP clients: Borella et al. Expires April 2000 [Page 6] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 - Client's private address - Client's assigned public address(es) 6.3.2. RSAP-IP State An RSIP server serving an RSIP client using the RSAP-IP method MUST maintain the following minimum state to ensure proper mapping of incoming packets to RSIP clients: - Client's private address - Client's assigned public address(es) - Client's assigned port(s) 6.3.3. Flow State Regardless of whether the server is using RSA-IP or RSAP-IP, additional state is necessary if either micro-flow based or macro-flow based remote policy is used. If the server is using macro-flow based remote policy, the following state must be maintained: - Remote host's address If the server is using micro-flow based remote policy, the following state must be maintained: - Remote host's address - Remote host's port More state MAY be used by an RSIP server if desired. For example, ToS/DS bytes may be recorded in order to facilitate quality of service support. 7. Parameter Specification and Formats In this section we define the formats for RSIP parameters. Each RSIP message contains one or more parameters that encode the information passed between the client and server. The general format of all parameters consists of a 1-byte code followed by a 2-byte length as shown below. 1 byte 2 bytes 'Length' bytes +------+----------+-------------- | Code | Length | ... +------+----------+-------------- The length field determines the length, in bytes, of the rest of the Borella et al. Expires April 2000 [Page 7] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 parameter. 7.1. Address Code Length Type Value +-------+---------+--------+--------+ | 1 | 2 bytes | 1 byte | varies | +-------+---------+--------+--------+ The address parameter contains addressing information, either an IPv4 address or netmask, an IPv6 address or netmask, or a fully qualified domain name (FQDN). The type field is 1 byte in length, indicating the type of address. Defined types are: Type Length of value field (in bytes) ---- -------------------------------- 0 Reserved 0 1 IPv4 4 2 IPv4 netmask 4 3 IPv6 16 4 IPv6 netmask 16 5 FQDN varies For FQDN, the length of the value field will be one less than the value of the length field. In some cases, it is necessary to specify a "don't care" value for an address. For IPv4 and IPv6 addresses, this is signified by an address value field of all zeros. For FQDN addresses, this is signified by a zero length value field. 7.2. Ports Code Length Number Port Port +-------+---------+--------+---------+ +---------+ | 2 | 2 bytes | 1 byte | 2 bytes | ... | 2 bytes | +-------+---------+--------+---------+ +---------+ The ports parameter encodes one or more TCP or UDP ports. When a single port is specified, the value of the number field is 1 and there is one port field following the number field. When more than one port is specified, the value of the number field will indicate the total number of ports contained, and the parameter may take one of two forms. If there is one port field, the ports specified are considered to be contiguous starting at the port number specified in the port field. Alternatively, there may be a Borella et al. Expires April 2000 [Page 8] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 number of port fields equal to the value of the number field. The number of port fields can be extrapolated from the length field. In some cases, it is necessary to specify a don't care value for one or more ports. This is accomplished by filling the one or more port fields with zeros. This parameter is not used with RSA-IP. 7.3. Lease Time Code Length Value +-------+--------+---------+ | 3 | 4 | 4 bytes | +-------+--------+---------+ The lease time parameter specifies the length, in seconds, of an RSIP client parameter binding. 7.4. Client ID Code Length Value +-------+--------+---------+ | 4 | 4 | 4 bytes | +-------+--------+---------+ The client ID parameter specifies an RSIP client ID. 7.5. Bind ID Code Length Value +-------+--------+---------+ | 5 | 4 | 4 bytes | +-------+--------+---------+ The bind ID parameter specifies an RSIP bind ID. 7.6. Message ID Code Length Value +-------+--------+---------+ | 6 | 4 | 4 bytes | +-------+--------+---------+ The message ID parameter specifies an RSIP message ID. 7.7. Tunnel Type Borella et al. Expires April 2000 [Page 9] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 Code Length Value +-------+--------+--------+ | 7 | 1 | 1 byte | +-------+--------+--------+ The tunnel type parameter specifies the type of tunnel used between an RSIP client and an RSIP server. Defined tunnel types are: Tunnel Type ----------- 0 Reserved 1 IP-IP 2 GRE 3 L2TP 7.8. RSIP Method Code Length Value +-------+--------+--------+ | 8 | 1 | 1 byte | +-------+--------+--------+ The RSIP method parameter specifies an RSIP method. Defined RSIP methods are: RSIP method ----------- 0 Reserved 1 RSA-IP 2 RSAP-IP 3 RSA-IP with IPSEC 4 RSAP-IP with IPSEC 7.9. Error Code Length Value +-------+--------+---------+ | 9 | 2 | 2 bytes | +-------+--------+---------+ The error parameter specifies an error. The currently defined error values are presented in Appendix A. 7.10. Flow Policy Borella et al. Expires April 2000 [Page 10] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 Code Length Local Remote +-------+--------+--------+--------+ | 10 | 2 | 1 byte | 1 byte | +-------+--------+--------+--------+ The flow policy parameter specifies both the local and remote flow policy. Defined local flow policies are: Local Flow Policy ----------------- 0 Reserved 1 Macro flows 2 Micro flows Defined remote flow policies are: Remote Flow Policy ------------------ 0 Reserved 1 Macro flows 2 Micro flows 3 No policy 7.11. Vendor Specific Parameter Code Length Vendor ID Subcode Value +-------+---------+-----------+---------+--------+ | 11 | 2 bytes | 2 bytes | 2 bytes | varies | +-------+---------+-----------+---------+--------+ The vendor specific parameter is used to encode parameters that are defined by a particular vendor. The vendor ID field is the vendor-specific ID assigned by IANA. Subcodes are defined and used by each vendor as necessary. An RSIP client or server SHOULD silently ignore vendor-specific messages that it does not understand. 8. Message Types RSIP messages consist of two mandatory fields, version and message type, followed by one or more required parameters, followed in turn by zero or more optional parameters. In an RSIP message, all required parameters MUST appear in the exact order specified below. Optional parameters MAY appear in any order. The version number field is a single byte and specifies the RSIP Borella et al. Expires April 2000 [Page 11] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 version number that is being used. The current RSIP version number is 1. The message type field is a single byte and specifies the message contained in the current packet. There may be only one message per packet. Message types given numerical assignments in Appendix B. Most parameters are only allowed to appear once in each message. The exceptions are as follows: - Multiple address parameters MUST appear in ASSIGN_REQUEST_RSA-IP, ASSIGN_RESPONSE_RSA-IP, ASSIGN_REQUEST_RSAP-IP, ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE. - Multiple ports parameters MUST appear in ASSIGN_REQUEST_RSAP-IP, ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE. - Multiple RSIP method and tunnel type parameters MAY appear in RESISTER_RESPONSE. - Multiple address parameters MAY appear in QUERY_REQUEST and QUERY_RESPONSE. The following message types are defined in simple BNF. Required parameters are enclosed in <> and MUST appear. Optional parameters are enclosed in [] and MAY appear. Not all message types need to be implemented in order to be RSIP compliant. For example, an RSIP client and/or server may not support LISTEN_REQUEST and LISTEN_RESPONSE, or may only support RSA-IP or RSAP-IP. 8.1. ERROR_RESPONSE An ERROR_RESPONSE is used to provide error messages from an RSIP server to an RSIP client. Usually, errors indicate that the RSIP server cannot or will not perform an action or allocate resources on behalf of the client. If the error is related to a particular client ID or bind ID, these associated parameters MUST be included. Multiple errors MAY NOT be reported in the same ERROR_RESPONSE. ::= [Client ID] [Bind ID] [Message ID] 8.2. REGISTER_REQUEST Borella et al. Expires April 2000 [Page 12] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 The REGISTER_REQUEST message is used by an RSIP client to establish registration with an RSIP server. An RSIP client MUST register before it requests resources or services from an RSIP server. Once an RSIP client has registered with an RSIP server, it may not register again until it has de-registered from that server. ::= [Message ID] 8.3. REGISTER_RESPONSE The REGISTER_RESPONSE message is used by an RSIP server to confirm the registration of an RSIP client, and to provide a client ID and flow policy. The RSIP server MAY respond with one or more RSIP methods and tunnel types that it supports. ::= [RSIP Method]... [Tunnel Type]... [Message ID] 8.4. DE-REGISTER_REQUEST The DE-REGISTER_REQUEST message is used by an RSIP client to de- register with an RSIP server. If a client de-registers from the assigned state, all of the client's bindings are revoked. The client SHOULD NOT de-register from the unregistered state. ::= [Message ID] 8.5. DE-REGISTER_RESPONSE The DE-REGISTER_RESPONSE message is used by an RSIP server to confirm the de-registration of an RSIP client. ::= [Message ID] Borella et al. Expires April 2000 [Page 13] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 8.6. ASSIGN_REQUEST_RSA-IP The ASSIGN_REQUEST_RSA-IP message is used by an RSIP client to request resources to use with RSA-IP. Note that RSA-IP cannot be used in combination with micro-flow based local policy. The RSIP client specifies two address parameters. The RSIP client may request a particular local address by placing that address in the first address parameter. To indicate that it has no preference for local address, the RSIP client may place a "don't care" value of all zeros in the address parameter. If macro-flow based remote policy is used, the client MUST specify the remote address that it will use this binding (if granted) to contact; however, the remote port number MAY remain unspecified. If micro-flow based remote policy is used, the client MUST specify the remote address and port number that it will use this binding (if granted) to contact. If no flow policy is used, the RSIP client may place a "don't care" value of all zeros in the value fields of the respective address and ports parameters. ::=
[Lease Time] [Tunnel Type] [Message ID] 8.7. ASSIGN_RESPONSE_RSA-IP The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP server to deliver parameter assignments to an RSIP client using RSA-IP. A client-wise unique bind ID, lease time, and tunnel type must be provided for every assignment. If no remote flow policy is used, the RSIP server MUST use "don't care" values for the remote address and ports parameters. If macro-flow based remote policy is used, the remote address parameter MUST contain the address specified in the associated request, and the remote ports parameter MUST contain a "don't care" value. If micro-flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information specified in the associated request. Borella et al. Expires April 2000 [Page 14] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 ::=
[Message ID] 8.8. ASSIGN_REQUEST_RSAP-IP The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP client to request resources to use with RSAP-IP. The RSIP client specifies two address and two port parameters, the first of each, respectively, refer to the local address and port(s) that will be used, and the second of each, respectively, refer to the remote address and port(s) that will be contacted. An RSIP client may request a particular local address by placing that address in the value field of the first address parameter. The RSIP client may request particular local ports by placing them in the first port parameter. To indicate that it has no preference for local address or ports, the RSIP client may place a "don't care" value of zeros in the respective address or ports parameters. If macro-flow based remote policy is used, the client MUST specify the remote address that it will use this binding (if granted) to contact; however, the remote port number(s) MAY remain unspecified. If micro-flow based remote policy is used, the client MUST specify the remote address and port number(s) that it will use this binding (if granted) to contact. If no flow policy is used, the RSIP client may place a value of all 0's in the value fields of the respective address or port parameters. ::=
[Lease Time] [Tunnel Type] [Message ID] Borella et al. Expires April 2000 [Page 15] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 8.9. ASSIGN_RESPONSE_RSAP-IP The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP server to deliver parameter assignments to an RSIP client. A client-wise unique bind ID, lease time, and tunnel type must be provided for every assignment. Regardless of local flow policy, a local address and port(s) MUST be assigned to the client. If macro-flow based local policy is used, the client is assigned an address and one or more ports. If micro-flow based local policy is used, the client is assigned an address and exactly one port. If no remote flow policy is used, the RSIP server MUST use "don't care" values for the remote address and ports parameters. If macro-flow based remote policy is used, the remote address parameter MUST contain the address specified in the associated request, and the remote ports parameter must contain a "don't care" value. If micro-flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information specified in the associated request. ::=
[Message ID] 8.10. EXTEND_REQUEST The EXTEND_REQUEST message is used to request a lease extension to a current bind. It may be used with both RSA-IP and RSAP-IP. The client MUST specify its client ID and the bind ID in question, and it MAY suggest a lease time to the server. Borella et al. Expires April 2000 [Page 16] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 ::= [Lease Time] [Message ID] 8.11. EXTEND_RESPONSE The EXTEND_RESPONSE message is used by an RSIP server to grant a requested lease extension. The server MUST specify the client ID of the client, the bind ID in question, and the new assigned lease time. ::= [Message ID] 8.12. FREE_REQUEST The FREE_REQUEST message is used by an RSIP client to free a binding. The given bind ID identifies the bind to be freed. Resources may only be freed using the granularity of a bind ID. ::= [Message ID] 8.13. FREE_RESPONSE The FREE_RESPONSE message is used by an RSIP server to acknowledge a FREE_REQUEST sent by an RSIP client. ::= [Message ID] 8.14. QUERY_REQUEST A QUERY_REQUEST message is used by an RSIP client to ask an RSIP server whether or not a particular address or network is local or Borella et al. Expires April 2000 [Page 17] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 remote. The client uses this information to determine whether to contact the host(s) directly (in the local case), or via RSIP (in the remote case). If the client needs to specify a subnet, it must use two address parameters - the first indicates the network and the second indicates the subnet mask. ::=
[Address (netmask)] [Message ID] 8.15. QUERY_RESPONSE A QUERY_RESPONSE message is used by an RSIP server to answer a QUERY_REQUEST from an RSIP client. The RSIP server MAY respond with a list of all networks and/or addresses that are on the private side of the network. If the server needs to specify a subnet, it must use two address parameters - the first indicates the network and the second indicates the subnet mask. An address with a "don't care" value indicates that address queried is not local. ::=
[Address (netmask)] [Message ID] 8.16. DEALLOCATE A DEALLOCATE message is used by an RSIP server to force an RSIP client to relinquish a specified binding. The client ID of the client and the bind ID of the resources to be relinquished MUST be included. Upon receiving a DEALLOCATE message, an RSIP client MUST stop all use of the said resources and immediately send an OK response to the server. ::= [Message ID] 8.17. OK Borella et al. Expires April 2000 [Page 18] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 An OK message MAY be used by an RSIP client to positively acknowledge the receipt of a message from the RSIP server. The OK message MUST be used to respond to a DEALLOCATE message from an RSIP server. If the OK is in reference to a particular bind ID, then that bind ID MUST appear in the message. ::= [Bind ID] [Message ID] 8.18. LISTEN_REQUEST A LISTEN_REQUEST message is sent by an RSIP client that wants to register a service on a particular IP address and port number. The client must include its client ID, local address parameter and ports parameters, and remote address and ports parameters. The client MAY suggest a lease time and one or more tunnel types. If the client wants to listen on a particular address or port, it may specify these in the address and ports parameters. Otherwise it may leave one or both of these parameters with "don't care" values. If no remote flow policy is being used, the client MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the client MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the client MUST specify the remote address and ports parameter. Once a LISTEN_REQUEST has been granted, the RSIP server MUST forward all packets destined to the address and port in question to the client, even if the remote host address and port tuple has not been previously contacted by the client. LISTEN_REQUEST is not necessary for RSA-IP. ::=
[Lease Time] [Tunnel Type]... Borella et al. Expires April 2000 [Page 19] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 [Message ID] 8.19. LISTEN_RESPONSE A LISTEN_RESPONSE message is used by an RSIP server to respond to a LISTEN_REQUEST message from an RSIP client. The RSIP server MUST issue a bind ID, and specify the address and port which have been granted to the client. The server must also specify a tunnel type and lease time. If no remote flow policy is being used, the server MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the server MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the server MUST specify the remote address and ports parameter. ::=
[Message ID] 9. Discussion 9.1. General Server Policy There is a significant amount of RSIP server policy that may be implemented, but is beyond the scope of this draft. We expect that most of this policy will be site-specific or implementation- specific and therefore do not make any recommendations. Examples of general server policy include: - How ports are allocated to RSIP clients. - Preferred length of lease times. 9.2. Default Tunnel Type and RSIP Method If an RSIP server does not specify a tunnel type or RSIP method as part of a REGISTER_RESPONSE, the client MUST assume a tunnel type of IP-IP and an RSIP method of RSAP-IP. Borella et al. Expires April 2000 [Page 20] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 9.3. Address and Port Requests and Allocation Regardless of local flow policy, an RSIP client may "suggest" that it would like to use a particular local address and/or port number in a particular binding. An RSIP server that cannot grant such a request, because the specified resources are already in use, MAY either (1) deny the request with an appropriate error message, or (2) approve the request but with different values than those suggested. 9.4. Local Servers and Flow Policy Interaction An RSIP client may initialize a publically accessible server (such as an FTP or HTTP server) by transmitting a LISTEN_REQUEST message to an RSIP server and receiving a LISTEN_RESPONSE. However, unless no remote flow policy is used, the server will have to specify the address or address and port of a single remote host that will be allowed to contact it. Obviously, such as restriction is not very useful for clients that require their servers to be accessible by any remote host. This indicates that there is a conflict between flow-based policy and support for servers. The main purpose of enforcing flow-based policy for LISTEN_REQUESTs is that it allows an RSIP server tight control over how an RSIP client uses ports and the associated accounting. For example, an RSIP client, operating under remote micro-flow based policy and using a protocol such as FTP, will have to specify the address and port that it will receive FTP data on, as well as the address and port that the server will transmit data from, in a LISTEN_REQUEST. In general, an RSIP server may not allow arbitrary clients to start public servers because of the traffic and security concerns. Thus, we recommend that if remote micro-flow based policy is used, that an RSIP server only allow public servers on RSIP clients via administrative override. 9.5. Unreliable Transport and Message IDs A message ID field SHOULD be included in all messages if UDP is used. The message ID starts with zero in the client's REGISTER_REQUEST message and end with a maximum value in the server's DE-REGISTER_RESPONSE message. This field SHOULD be incremented by one for every request issued. Responses MUST include the same message ID as that of the request which it acknowledges. If an RSIP client does not receive a response from the RSIP server Borella et al. Expires April 2000 [Page 21] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 for a request, a new request with the same message ID MAY be issued after an interval of time. An RSIP server receiving a request with a message ID smaller than what it previously received (within a REGISTERed session) SHOULD ignore the request. Pipelining of requests and aggregation of responses MUST NOT be allowed. Message ID wraparound is highly unlikely, however it must be considered in both the RSIP clients and servers. RSIP servers SHOULD implement message IDs, and SHOULD respond with message IDS to all clients that offer message IDs in their requests. An RSIP client MAY accept messages without message IDs from servers even if the client has offered message IDs. 10. Security Considerations RSIP, in and of itself, does not provide security. It may provide the illusion of security or privacy by hiding a private address space, but security can only be ensured by the proper use of security protocols and cryptographic techniques. RSIP messages send between a client and server SHOULD be authenticated. Further discussion of such authentication can be found in [RSIP-FRAME]. Discussion of RSIP support for end-to-end IPSEC can be found in [RSIP-IPSEC]. 11. IANA Considerations All of the below are tentative. - RSIP port number: 4455. - RSIP error codes (see Appendix A). - RSIP message type codes (see Appendix B). 12. Changelog 02 to 03 - Overall re-write and editing. - Removed a number of extraneous details that are now covered in the framework draft. - Moved parameter and message type codes to appendices. - Added section on flow policy. - Modified address and port parameters to simplify and generalize. 01 to 02: Borella et al. Expires April 2000 [Page 22] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 - Added section on server state. - Re-wrote section on parameter negotiation. - Added details to ICMP Handling section. - Added LISTEN_REQUEST and LISTEN_RESPONSE messages. - Added appendix with client state diagram. - Updated references with respect to RFC 2663. - Clarified use/non-use of message IDs between clients and servers. - Added recommendation that RSIP use port 4455 for initial implementation and testing, until further notice. - Bumped code values up by 1, made code value of 0 reserved. - Expanded ASSIGN_REQUEST into ASSIGN_REQUEST_ADDR for RSA-IP, ASSIGN_REQUEST_PORT for RSAP-IP and ASSIGN_REQUEST_EXT for lease extensions. The same expansion applies for ASSIGN_RESPONSE. - Indiciated that all RSIP parameters must not appear more than once except for tunnel type and RSIP method in ASSIGN_REQUEST messages. - Exactly one error is now reported in each ERROR_RESPONSE message. 00 to 01: - Eliminated number of IP addresses and IP address range parameters and fixed other parameters to reflect this change. - Added IP address request message. - Added discussion on authentication to Security Considerations section. - Added Miscellaneous Issues section. - Changed all mention of "sequence number" to "message ID". - Reformatted References section. - Added reference to RSIP framework draft. - Separated request and response messages, then renumbered them. - Required that all RSIP implementations support IP-IP tunneling and RSA-IP. - Modified message semantics slightly. - Added appendix with protocol example. - Added address and port resource error messages. - Specified that multiple error responses may be returned in the same ERROR_RESPONSE message. - RSIP method may now be specified per binding, so that different methods can be used when connecting to different external systems. - Synched up terminology with the latest NAT terminology draft. - Added mention of RSIP servers also implementing a NAT as a fallback. - Added DEALLOCATE and OK messages. - Tunneling now negotiated per bind rather than per-registration. 13. Acknowledgements The authors would like to thank Gabriel Montenegro, Pyda Srisuresh, Dan Nessett, Gary Jaszewski, and Rick Cobb for their input. Borella et al. Expires April 2000 [Page 23] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 14. Appendix A: RSIP Error Numbers This section provides descriptions for the error values in the RSIP error parameter. These error values are preliminary and are very likely to change over time as implementations are tested. 1: UNKNOWNERROR - An error that cannot be identified has occurred. 2: BADBINDID - The request refers to an invalid Bind ID. 3: BADCLIENTID - The request refers to an invalid Client ID. 4: MISSINGPARAM - The request does not contain a required parameter. 5: DUPLICATEPARAM - The request contains an illegal duplicate parameter. 6: ILLEGALPARAM - The request contains a parameter that it should not. 7: ILLEGALMESSAGE - The RSIP server does not understand the message type. 8: REGISTERFIRST - The RSIP client has attempted to request or use resources without registering. 9: BADMESSAGEID - The request contains an unexpected message ID. 10: ALREADYREGISTERED - The RSIP client has attempted to register again without first de-registering. 11: ALREADYUNREGISTERED - The RSIP client has attempted to de- register but it is already in the unregistered state. 12: BADTUNNELTYPE - The RSIP client has tried to use a tunnel type that the RSIP server does not support. 13: ADDRUNAVAILABLE - The RSIP server was not able to allocate an IP address. 14: PORTUNAVAILABLE - The RSIP server was not able to allocate port(s). 15. Appendix B: Message Type Values This section defines the values assigned to RSIP message types. These values are preliminary and are very likely to change over time as implementations are tested. Borella et al. Expires April 2000 [Page 24] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 1 ERROR_RESPONSE 2 REGISTER_REQUEST 3 REGISTER_RESPONSE 4 DE-REGISTER_REQUEST 5 DE-REGISTER_RESPONSE 6 ASSIGN_REQUEST_ADDR 7 ASSIGN_RESPONSE_ADDR 8 ASSIGN_REQUEST_PORT 9 ASSIGN_RESPONSE_PORT 10 EXTEND_REQUEST 11 EXTEND_RESPONSE 12 FREE_REQUEST 13 FREE_RESPONSE 14 QUERY_REQUEST 15 QUERY_RESPONSE 16 DEALLOCATE 17 OK 18 LISTEN_REQUEST 19 LISTEN_RESPONSE 16. Appendix C: Example RSIP client/server transactions In this appendix, we present an exemplary series of annotated transactions between an RSIP client and an RSIP server. All client to server traffic is denote by `C --> S' and all server to client traffic is denoted by `S --> C'. Parameter values are denoted inside of parentheses. Versions, message types and message ID's are not included in order to save space. "Don't care" values are indicated by 0's. A ports parameter is represented by the number of ports followed by the port numbers, separated by dashes. For example, 2-1012-1013 indicates two ports, namely 1012 and 1013, while 16-10000 indicates 16 ports, namely 10000-10015, and 4-0 indicates four ports, but the sender doesn't care where they are. IPv4 addresses are assumed. 16.1. RSAP-IP with Local Macro-flow Based Policy and No Remote Flow Policy This example exhibits the loosest policy framework for RSA-IP. C --> S: REGISTER_REQUEST () The client attempts to register with the server. S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy = Borella et al. Expires April 2000 [Page 25] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 Macro, Remote Flow policy = None) The server responds, assigning a Client ID of 1, local macro- flow based policy and no remote flow policy. No RSIP method is indicated, so RSAP-IP is assumed. No tunnel type is indicated, so IP-IP is assumed. C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) = 0, Lease Time = 3600) The client requests an address and four ports to use with it, but doesn't care which address or ports are assigned. The client does not specify the remote address or ports either. The client suggests a lease time of 3600 seconds. S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1, Address (local) = 149.112.240.156, Ports (local) = 4-1234, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800, Tunnel Type = IP-IP) The server responds by indicating that a bind ID of 1 has been assigned to IP address 149.112.240.156 with ports 1234-1237. Any remote host may be communicated with, using any remote port number. The lease time has been assigned to be 1800 seconds, and the tunnel type is confirmed to be IP-IP. The client is now able to communicate with any host on the public network using these resources. C --> S: QUERY_REQUEST: (Client ID = 1, Address = 10.20.60.0, Address (netmask) 255.255.255.0) The client asks the server if the network 10.20.60.0 is local. S --> C: QUERY_RESPONSE: (Client ID = 1, Address = 10.20.60.0, Address (netmask) = 255.255.255.0) The server responds indicating that the network in question is local. C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800) The client requests eight more particular ports for use with RSAP-IP with the same address. A lease of 1800 seconds is Borella et al. Expires April 2000 [Page 26] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 requested. IP-IP tunneling is implied by default. S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2, Address (local) = 149.112.240.156, Ports (local) = 8-1305, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800) The server grants the request with the same address, but with a different set of ports. IP-IP tunneling is implied by default. C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1) The client frees bind ID 1; i.e., ports 1234-1237 from IP address 149.112.240.156. Note that the address itself is still assigned to the client because the client is still assigned ports 1305-1314. S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1) The server acknowledges that Bind ID 1 has been freed. C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time = 1800) The client request that the lease on bind ID 1 be extended for 1800 seconds. S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time = 1800) The server confirms the request. S --> C: DEALLOCATE (Client ID = 1, Bind ID = 2) The server forces the client to deallocate the resources of bind ID 2. C --> S: OK (Client ID = 1, Bind ID 2) The client acknowledges that the resources have been deallocated. C --> S: DE-REGISTER_REQUEST (Client ID = 1) The client de-registers with the sever. S --> C: REGISTER_RESPONSE (Client ID = 1) The server acknowledges that the client has de-registered. Borella et al. Expires April 2000 [Page 27] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 16.2. RSAP-IP with Local Micro-flow Based Policy and Remote Micro- flow Based Policy This example exhibits the strictest policy framework for RSAP-IP. C --> S: REGISTER_REQUEST () The client attempts to register with the server. S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy = Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE) The server responds, assigning a Client ID of 5, local micro- flow based policy and remote micro-flow based policy. Both RSAP-IP and RSA-IP are supported. Both IP-IP and GRE tunnel types are supported. C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) = 0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP) The client requests a local address and a port assignment to use with it. The client indicates that it wants to contact host 38.196.73.6 at port 21 (FTP control). The client requests a lease time of 600 seconds and a tunnel type of IP-IP. S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1, Address (local) = 149.112.240.156, Ports (local) = 2049, Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP) The server responds by indicating that a bind ID of 1 has been assigned to IP address 149.112.240.156 with port 2049. Only host 38.196.73.6 at port 21 may be contacted. The lease time has been assigned to be 600 seconds, and the tunnel type is confirmed to be IP-IP. C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) = 149.112.240.156, Ports (local) = 2050, Address (remote) = 38.196.73.6, Ports (remote) = 20) The client requests a listen port 2050 at the same address that it has been assigned. Only host 38.196.73.6 from ports 20 (FTP data) will be able to contact it. S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) = 149.112.240.156, Ports (local) = 2050, Address (remote) = Borella et al. Expires April 2000 [Page 28] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type = IP-IP) The server confirms the request and assigns a lease time of 600 seconds and a tunnel type of IP-IP. C --> S: DE-REGISTER_REQUEST (Client ID = 5) The client de-registers with the sever. S --> C: REGISTER_RESPONSE (Client ID = 5) The server acknowledges that the client has de-registered. All of the client's bindings have been implicitly revoked. 17. Appendix D: Example RSIP client state diagram This appendix provides an exemplary diagram of RSIP client state. The client begins in the unregistered state. We assume that for UDP, if a message is lost, the client will timeout and retransmit another copy of it. We recommend a 7-fold binary exponential backoff timer for retransmissions, with the first timeout occurring after 12.5 ms. This diagram does not include transitions for the LISTEN_REQUEST message or the DEALLOCATE message. send +------------+ REGISTER_REQUEST +------------+ | |----------------->|Registration|<-- timeout/send +--->|Unregistered|<-----------------| Pending |--- REGISTER_REQUEST | | | 7th timeout/recv +------------+ | +------------+ ERROR_RESPONSE | | ^ | | |7th timeout/recv |recv timeout/send | |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST | | | ^ | | | send DE- v send | | | +----------------+ REGISTER_REQUEST+----------+QUERY_REQUEST +----------+ | | Registered |<----------------| |-------------->|Registered| | | De-registration| |Registered| | Query | | | Pending |---------------->| |<--------------| Pending | | +----------------+ recv +----------+ 7th timeout/ +----------+ | | ^ ERROR_RESPONSE ^ | recv | | | | | QUERY_RESPONSE or | timeout/send | | ERROR_RESPONSE | DE-REGISTER_REQUEST 7th timeout/recv| | | ERROR_RESPONSE | | | +----------------+ | | Borella et al. Expires April 2000 [Page 29] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 | |Go to Registered| | |send | +----------------+ | |ASSIGN_REQUEST | ^ timeout/send | | | |Yes FREE_REQUEST | | | + | | | | | + + v | | v | + + 7th timeout/ +--------+ +----------+ | + Are all + recv | Free | |Assignment|<--timeout/send | + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST | + freed? + FREE_RESPONSE+--------+ +----------+ | + + ^ | | | + + | | | | + | | |recv | |No send | |recv |ASSIGN_RESPONSE | v ERROR_REQUEST| |ERROR_ | | +---------------+ | |RESPONSE | | | Go to Assigned| | | | | +---------------+ | | | 7th timeout/recv | recv | | | QUERY_RESPONSE or | +---------------+ERROR_RESPONSE | v v ERROR_RESPONSE+-------------+ | | Assigned |-------------->+-------------+------------->| Assigned | +>|De-registration| | Assigned | | Query | | Pending |<--------------+-------------+<-------------| Pending | +---------------+ send ^ | send +-------------+ ^ | DE-REGISTER_REQUEST | | QUERY_REQUEST ^ | | | | | | | timeout/send 7th/timeout/recv | |send | | DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send REQUEST or ERROR_RESPONSE| | QUERY_REQUEST | | | v +----------+ | Assigned | |Assignment| | Pending | +----------+ ^ | | | timeout/send ASSIGN_REQUEST 18. References [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets," RFC 1918, Feb. 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to indicate Borella et al. Expires April 2000 [Page 30] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 requirement levels," RFC 2119, Mar. 1997. [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations," RFC 2663, Aug. 1999. [RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm Specific IP: Framework," Internet Draft , Oct. 1999 (work in progress). [RSIP-IPSEC] G. Montenegro and M. Borella, "RSIP Support for End-to- end IPSEC," , work in progress, May 1999. 19. Authors' Addresses Michael Borella 3Com Corp. 1800 W. Central Rd. Mount Prospect IL 60056 (847) 342-6093 mike_borella@3com.com David Grabelsky 3Com Corp. 1800 W. Central Rd. Mount Prospect IL 60056 (847) 222-2483 david_grabelsky@3com.com Jeffrey Lo NEC USA C&C Research Labs. 110 Rio Robles San Jose, CA 95134 (408) 943-3033 jlo@ccrl.sj.nec.com Kunihiro Taniguchi NEC USA C&C Research Labs. 110 Rio Robles San Jose, CA 95134 (408) 943-3031 taniguti@ccrl.sj.nec.com 20. Copyright Statement Borella et al. Expires April 2000 [Page 31] INTERNET-DRAFT Realm Specific IP: Protocol Specification October 1999 Copyright (c) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked 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 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Borella et al. Expires April 2000 [Page 32]