INTERNET-DRAFT James Stepanek stepanek@aero.org The Aerospace Corporation Stephen Schwab schwab@aero.org Twin Sun Inc VIPRE -- Virtual Internet Packet Relay An Encapsulation Architecture for Unidirectional Links November 1997 Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes a method of incorporating unidirectional links into an IP network in a bidirectional mode by relaying encapsulated IP packets over a bidirectional network. 1. Introduction Successful incorporation of asymmetric, unidirectional satellite links into a internetwork requires special treatment of those links. The design of many protocols commonly used in the Internet assume the existence of symmetrical, bidirectional links between nodes. As a result, many of these same protocols do not work as intended over links which are asymmetric, unidirectional, or both. Asymmetric network topologies, for example, those which incorporate satellite links, primarily affect protocols which use link-dependent state for their operation. This usually occurs whenever the network needs to treat a link as a distinct resource. Examples of this include protocols which handle routing and group management, as well as link-bound heuristics of transport protocols and management software. For example, consider a host with connectivity through two Schwab and Stepanek Expires August 1997 [Page 1] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 interfaces, in other words, a "multi-homed" host. On this host, one interface forms the receiving end of a connection to a unidirectional, high-bandwidth satellite link. The second interface connects the host to a low-bandwidth, bidirectional terrestrial network. Ideally, an internetwork in this topology makes use of the satellite link where appropriate while still behaving much like a common symmetrical internet. This document describes one approach to incorporating unidirectional satellite links into an internet--the Virtual Internet Packet Relay (VIPRe). This document describes an architecture for incorporating unidirectional links into an internet--reducing the problem of unidirectional links to the more general problem of asymmetric links. Note that while this approach was developed for use in unidirectional satellite links, it could quite possibly be used on other types of unidirectional links. Before describing the details of the architecture, a couple of alternative existing approaches are summarized for the below for the purposes of discussion. 1.1. Terminology For the purposes of this discussion, consider two types of network nodes with connections to a unidirectional satellite links. "Uplink" nodes have the ability to send data over a unidirectional link, while "downlink" nodes have the ability to receive data from a unidirectional link. 1.2. Split Routing A simple, straight-forward approach modifies routing tables on the uplink and downlink nodes. By introducing a static "split" route on both the downlink and uplink nodes, traffic originating from downlink and destined for uplink nodes is always sent out a bidirectional interface. Similarly, traffic originating from a uplink host and destined for a down link node is always sent out the unidirectional interface. This allows some IP traffic to flow between the uplink and downlink nodes much as it does in a "normal" internet. However, for large networks maintaining the static "split" routes requires significant system management. Also, protocols with bidirectional link assumptions remain broken under this routing configuration. 1.3. Routing Protocol Modification Another method of dealing with unidirectional links involves modifying routing protocols to account for one-way hops. The modified routing processes share information with each other for the purpose of directing traffic in a "split" fashion. Essentially, this incorporates a mechanism for "discovery" of uplink nodes by downlink nodes, as well as a mechanism for distributing routing information from downlink nodes back to uplink nodes directly. By handling the problem directly, this approach offers the most general of solutions. Schwab and Stepanek Expires August 1997 [Page 2] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 In fact in addition to routing protocols, it's expected that many protocols require modification or extensions to remove asymmetric links assumptions. 1.4. Virtual Packet Relays A third approach, uses a "relay", or one-way tunnel, to transmit packets back to the uplink node. Virtual Packet Relays, described here in detail, attempt to make a functionally bidirectional interface out of a unidirectional interface. To achieve this, traffic sent out the unidirectional interface of the downlink node is captured somewhere beneath the network layer and relayed through a bidirectional interface on the downlink node to a bidirectional interface on the uplink node. Once the captured data arrives at the uplink node, it's taken out of the relay and injected into the unidirectional interface of the uplink node where it's received as a "normal" network packet by the uplink node. Using a Virtual Packet Relay to deal with unidirectional links differs slightly from the other approaches described earlier. Unlike the "split" route approach, using a Virtual Packet Relay does not require modification of routing table entries for attached networks. This means packets originating on downlink nodes which are destined for uplink nodes can be sent out the unidirectional interface of the downlink node, as if this interface were bidirectional. For this reason, some protocols which include bidirectional link assumptions will operate unmodified under this architecture. A Virtual Packet Relay provides functionality similar to "split" IP routing, but hides the details of the one-way network from IP route tables and routing protocols. This holds the appealing property of allowing some existing protocols to function in this environment without modification. However, this approach assumes that uplink and downlink nodes are connected on a bidirectional network. It also fails to handle the asymmetric nature of the bidirectional link it approximates. In other words, the routing protocols in use will have to be configured to reflect the high cost of the virtual IP hop from receiver to uplink site. In effect, a Virtual Packet Relay creates a virtual network over which IP packets can flow as if there is a reverse path on the unidirectional link. Bandwidth of this path is limited by the underlying bandwidth of the bidirectional internet, so bandwidth management of the reverse link is important. Implementing a Virtual Packet Relay requires two components. On the uplink side, a relay "server" handles unencapsulating and injection of PDUs. On the downlink side a relay "client" handles the capture and encapsulation of PDUs. In practice, this is accomplished with a pair of "Split" Virtual Interfaces (SVIFs). On the server side, a special interface exists which transmits data normally, but receives incoming traffic from a set of one or more relays. On the client side, another special interface exists which receives traffic normally, but transmits outgoing traffic through a set of one or more Schwab and Stepanek Expires August 1997 [Page 3] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 relays. Together, these two components maintain one-way flows of encapsulated IP traffic, including two SVIFs on either side. In this architecture, relay clients keep a list of relay servers with which they participate, each with a set of corresponding relay endpoints. And when a single relay client communicates with multiple relay servers, the client must use a separate SVIF for each. #*# \ \ \ +----+ +---------------+ | |======>|\ | |SVIF| | downlink node | | |<===1==|/ | +----+ | | | +--relay client-+ | ^ | +===2==>======>| +---3---> relay server (via bidirectional network) ===> link traffic (below network layer) ---> IP traffic Figure 1: Downlink Node Detail #*# / / / +---------------+ +----+ | /|======>| | | uplink node | |SVIF| | \|<==6===| | | | +----+ +--relay server-+ | | | ^ -----4---->--+ +=======>===5===>| relay client (via bidirectional network) ===> link traffic (below network layer) ---> IP traffic Figure 2: Uplink Node Detail 2. ICMP Relay Discovery Protocol Before a relay client can provide a fully-functioning SVIF, it must know the IP address of at least one functioning "endpoint" of a relay Schwab and Stepanek Expires August 1997 [Page 4] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 corresponding to that SVIF. In other words, it must know where to send payload packets so they arrive at the relay server for this SVIF. One method of acquiring this knowledge involves using configuration files to inform the relay client of all the relay servers it needs to know about. Another possible method involves listening to exiting protocol traffic on the unidirectional link and deducing--based on this traffic--the addresses of suitable relay endpoints. Since, both of these methods have drawbacks, a third method is described here, which relies heavily upon the concepts presented in ICMP Router Discovery [RFC1256]. Like ICMP Router Discovery, this method introduces a new ICMP message called a "Relay Advertisement". In fact, the ICMP Relay Discovery process works much like ICMP Router Discovery. If a relay server wishes to advertise its willingness to accept relayed packets, it periodically sends Relay Advertisements on its unidirectional link. Relay clients discover the relay endpoints by listening for Relay Advertisements on their unidirectional link. Like Router Advertisements, Relay Advertisement contain a "lifetime" field. This specifies the maximum time that relay endpoints are considered valid in the absence of further Advertisements. Relay clients use this value to maintain a timer for each relay. Unlike Router Advertisements, Relay Advertisements include a vector of "relay addresses" instead of a "router addresses". They also omit the "preference" field found in Router Advertisements. And unlike ICMP Router Discovery's "Router Addresses", the addresses advertised in Relay Advertisements will likely reside in different subnets or different networks than the address(s) of the interface which receives them. 2.1. Message Formats ICMP Relay Advertisement Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Addrs |Addr Entry Size| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay Address[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay Address[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | IP Fields: Schwab and Stepanek Expires August 1997 [Page 5] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 Source Address An IP address belonging to the interface from which this message is sent. Destination Address The configured AdvertisementAddress or the IP address of a neighboring host. Time-to-Live 1 if the Destination Address is an IP multicast address; at least 1 otherwise. ICMP Fields: Type TBD Code 0 Checksum The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0. Num The number of relay endpoint addresses advertised in this message. Addr Entry Size The number of 32-bit words of information per each relay address (1, in the version of the protocol described here). Lifetime The maximum number of seconds that the relay addresses may be considered valid. Relay Address[i] The addresses of the relay endpoints advertised in this message, where i = 1..Num Addrs. 2.2. Relay Server Specification 2.2.1. Relay Server Configuration Variables Relay Server Configuration Variables for ICMP Relay Discovery are analogous to the Router Configuration Variable in ICMP Router Discovery. A relay server implementing ICMP Relay Discovery must allow configuration of the following variables by system management. The term "advertisement space" refers to a set of relays associated with a single SVIF for which a relay server sends Relay Advertisement messages. For each advertisement space, the relay server maintains the following variables: AdvertisementAddress The IP destination address to be used for Relay Advertisements sent for relays in the advertisement space. Schwab and Stepanek Expires August 1997 [Page 6] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 Default: 224.0.0.1 if the relay server supports IP multicast on the SVIF interface, else 255.255.255.255 MaxAdvertisementInterval The maximum time allowed between sending Relay Advertisements for relays in this advertisement space, in seconds. As in ICMP Router Discovery, this must be no less than 4 seconds and no greater than 1800 seconds. Default: 600 seconds MinAdvertisementInterval The minimum time allowed between sending multicast Relay Advertisements from relays in the advertisement space, in seconds. As in ICMP Router Discovery, this must be no less than 3 seconds and no greater than MaxAdvertisementInterval. Default: 0.75 * MaxAdvertisementInterval For each of its relays, the relay server's maintains the following information: Advertise A flag indicating whether or not the relay is to be advertised. Default: TRUE 2.2.2. Relay Server Behavior For each advertisement space with at least one relay whose Advertise flag is TRUE, the relay server transmits periodic Relay Advertisements, with the following values. - In the destination address field of the IP header: the configured AdvertisementAddress for the advertisement space. - In the Lifetime field: the configured AdvertisementLifetime for the advertisement space. - In the Relay Address[i] fields: all the addresses of the relay endpoints in the advertisement space with Advertise flags marked TRUE. To avoid unwanted synchronization, the interval between sending Relay Advertisements varies randomly. Many other protocols which transmit "periodic" messages describe why and how to achieve this, including ICMP Router Discovery. Schwab and Stepanek Expires August 1997 [Page 7] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 2.3. Relay Client Specification 2.3.1. Relay Client Configuration Variables Relay Client Configuration Variables for ICMP Relay Discovery are analogous to the Host Configuration Variable in ICMP Router Discovery. A relay client implementing ICMP Relay Discovery must allow configuration of the following variables by system management. For each SVIF, a relay client maintains the following variables: PerformRelayDiscovery A flag indicating whether or not the relay client performs ICMP Relay Discovery for the SVIF. Default: TRUE For SVIFs which will not perform ICMP Relay Discovery, the relay client must support a configurable list of relay endpoints. The following variables exist for each SVIF not performing ICMP Relay Discovery. RelayAddress The IP address of the endpoint of the desired relay for this SVIF. Default: (none) 2.3.2. Message Validation by Relay Clients Relay Advertisements are validated by relay clients in the same way that Router Advertisements are validated by hosts--as described in Section 5.2 of RFC 1256--except when validating Relay Advertisements, the ICMP Addr Entry Size must be greater than or equal to 1, instead of greater that or equal to 2. 2.3.3. Relay Client Behavior Upon receiving and validating a Relay Advertisement, the relay client executes the following process for each Relay Address in the Advertisement. - If the address does not already exist in the relay client's list of relay addresses, it may create a new entry in the list for the new address. The new entry contains the address along with a timer initialized with the Lifetime value of the advertisement. - If the address already exists in the relay client's list as a result of a previously-received advertisement, the client resets the timer using the Lifetime value of the advertisement. If no Relay Advertisement are received such that the timer expires Schwab and Stepanek Expires August 1997 [Page 8] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 for a entry created as a result of a previously received advertisement, the client removes this entry from its list 3. Encapsulating Traffic Once a relay client knows of one or more relay endpoints, it may begin encapsulating captured traffic, and sending it through the relay. Currently, many protocols exist for the purpose of transporting encapsulated packets. Some of these are discussed in the context of IP mobility [RFC2002][RFC2003], point-to-point link transport [RFC1661], security [RFC1827], and multicast routing [RFC1075]. If a relay server does not support a protocol with "advertisements", it must support IP in IP encapsulation using an intervening GRE [RFC1701] header, that is, using GRE with IP as both the delivery and payload protocol as discussed in [RFC1702] (see Figure 3). Otherwise, the relay server must advertise the tunneling protocols it supports. If a desired tunneling protocol supports a suitable notion of advertisement, then these messages provide one method of uplink discovery for Relay Clients. Alternatively, extensions to the Relay Discovery protocol--by adding additional information the the Address Entries of advertisements--would support use of other encapsulation methods. +---------------------------+ | | | Outer IP Header | | | +---------------------------+ | | | GRE Header | | | +---------------------------+ | | | IP Header | | | +---------------------------+ | | | | | IP Payload | | | | | +---------------------------+ Figure 3: Baseline Encapsulation Protocol The correct choice of encapsulation protocol depends upon the nature of network. Important considerations include security and bandwidth management of bidirectional links, as well as the expected number of participating downlink nodes. In addition to these considerations, the encapsulation process itself affects several IP mechanisms. Appendix B of [RFC1241] contains a discussion of some of the Schwab and Stepanek Expires August 1997 [Page 9] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 implications of encapsulating IP traffic. 4. Security Considerations RFC 1256 points out that systems can use ICMP Router Discovery to masquerade as a default router. In a similar manner, systems can use ICMP Relay Discovery to masquerade as a relay server. As described in Section 7 of RFC 1256, one possible method of addressing this problem involves adding authentication information to advertisements. On the relay server side, the simple encapsulation method described in this memo fails to provide relay server's with the ability to authenticate relay clients. And since relay client transmit payload packets entirely in the clear, potentially malicious intermediate nodes have the ability to interpret the payload of the relay. The protocols and architecture described in the memo were intended to tolerate variety in choice encapsulation protocol, so where authenticating relay clients and protecting payload transmissions are concerns, an alternative encapsulation protocol which provides these services may be used instead of the simple one describe here. Security mechanisms may also reside on entities conceptually above the relay, using the relay as it's intended, that is, as just another IP link. 5. References [RFC1256] S. Deering, "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1996. [RFC2003] C. Perkins, "IP Encapsulation within IP", RFC 2003, October 1996. [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, Daydreamer, July 1994. [RFC1827] R. Atkinoson, "IP Encapsulating Security Payload (ESP)", RFC1827, August 1995 [RFC1075] D. Waitzman, C. Partridge, and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1705, November 1988. [RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October 1994. [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd., cisco Systems, October 1994. Schwab and Stepanek Expires August 1997 [Page 10] INTERNET-DRAFT Virtual Internet Packet Relay February 1997 [RFC1241] R. Woodburn, D. Mils, "A Scheme for an Internet Encapsulation Protocol: Version 1", RFC 1241, July 1991. 6. Authors' Address: Schwab and Stepanek Expires August 1997 [Page 11]