Internet Engineering Task Force INTERNET-DRAFT G. Morrow draft-morrow-mipv6-zod-00.txt Nortel Networks Expires: June 2002 January 2002 Diversion with No Transport Overhead 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. 1 Abstract Under certain circumstances the desired effects of diversion can be achieved with no per-packet transport overhead. This draft describes these circumstances as well as the per-packet bearer processing and general signaling requirements of some proposals that strive to remove the need for this overhead. The first proposal is referred to as Zero-Overhead Diversion (ZOD). The second is referred to as More Robust Zero-Overhead Diversion (MR. ZOD). Mobile IP and load distribution are examples of the useful application of diversion. Table of Contents 1 Abstract.......................................................1 2 Terminology....................................................3 3 Overview.......................................................4 4 Existing Proposals for Diversion Tunneling.....................5 5 The Reflector Attack, Security Precautions and MIPv6...........8 6 Zero Overhead Diversion (ZOD) applied to MIPv6.................9 7 Implementation Example for MIPv6 application...................9 7.1 Forward Path Processing.......................................10 7.2 Reverse Path Processing.......................................11 8 Generalizing Zero Overhead Diversion..........................12 9 End to End Considerations.....................................12 10 Robustness - Corruption of/Stale Routing Table Entries........13 Morrow 1 Internet Draft Zero-Overhead Diversion Jan 2002 11 Robustness - Cache Overruns...................................14 12 Security Implications.........................................15 13 Other Signaling Semantics.....................................15 14 NAT Interactions..............................................15 15 Applicability of Zero Overhead Diversion......................15 16 ZOD compared with Hardened Diversion Tunneling................17 17 More Robust ZOD (MR. ZOD).....................................17 18 Deployability.................................................18 19 Decisions Decisions Decisions.................................18 20 IANA Considerations...........................................18 21 Notice on Intellectual Property...............................18 22 References....................................................19 23 Author's Addresses............................................19 24 Full Copyright Statement......................................19 25 Acknowledgements..............................................20 Morrow Draft - Expires June 2002 2 Internet Draft Zero-Overhead Diversion Jan 2002 2 Terminology Transparent Diversion: Address obviation used to guarantee transparent communications between nodes along diverted paths of a connectionless network. The methods described in [MIPv6] and [Deering] are previous examples of tunneling solutions designed and optimized to achieve transparent diversion. Other uses for transparent diversion include: content distribution, load-sharing and internal address-space hiding. Beneficiary Node (BN): The beneficiary node is defined to be the node which benefits from the diversion. The beneficiary node may or may not be the same node that actually performs the diversion function. Correspondent Node (CN): The correspondent node is the node for which IP - transparent communications with the beneficiary is desired. The correspondent node may or may not be the same node which performs the diversion function. Transparency Address (TA): An address allocated to a beneficiary node in order to achieve IP transparent communications with correspondent nodes. In Mobile IPv6, the home address is the transparency address. A single beneficiary node can have more than one TA at any given point in time. Depending on your inclination, you might think of the TA as a stack identifier [NAME], end system designator (GES) or logical address (LAR) for a node that needs transparent diversion. Then again you may just think of it as a divertible network address for a single node. If a node does not require diversion there is no need for separation of DA and TA. A TA may be a DA for another TA. Diversion Address (DA): An address allocated to a beneficiary node in order to provide network-layer transport across a connectionless network which employs topological correctness checks e.g. ingress filtering. In mobile IPv6, the care of address is the diversion address. A single beneficiary (stack) can have more than one DA associated with it any given point in time. If a node does not require diversion there is no need for separation of DA and TA. A DA may be a TA for another DA. Beneficiary Diversion Endpoint (BDE): The beneficiary diversion endpoint is the node or nodes nearest to the BN performing the diversion functions on behalf of the BN. The BDE may be the same node as the beneficiary node. This is the case with mobile IPv6 as currently defined. Correspondent Diversion Endpoint (CDE): Morrow Draft - Expires June 2002 3 Internet Draft Zero-Overhead Diversion Jan 2002 The correspondent diversion endpoint is the node or nodes nearest to correspondent nodes performing the diversion on behalf on the beneficiary. The CDE may be the same node as correspondent nodes. This is the case with mobile IPv6 as currently defined. Routing Table: A routing table is a conceptual term used in this document to generically represent an arbitrary internal data structure used to describe the bearer processing semantics of this proposal. Implementations of zero overhead diversion may put route entries in either the FIB, RIB, or function specific data structure such as the binding cache and binding list as described in mobile IPv6, ingress and egress partitions, etc... We generically refer to any of these implementation choices as routing table to obviate the need to pin down something implementation specific. Throttling: Throttling is used in this document to represent the tear-down and re-establishment of a node's logical connections (sockets) either via the transport itself (ex. TCP RESET/SYN) or by the application. For instance upon a timeout or successive timeouts an application may tear down the socket being used, reestablish it and then try to send another message. 3 Overview Over the years many forms of tunneling have emerged. Each tunneling mechanism has been designed to meet specific requirements related to functionality, ease of implementation and optimization in terms of packet overhead. Each tunneling method has various applicability to problem sets, restrictions and complications. The proposals described in this document are applicable to the problem scope of transparent diversion with no tunneling overhead. The route optimized mobile IPv6 application is one such case that zero-overhead diversion (ZOD) could be employed along the path between mobile and correspondent nodes. Throughout this document we use mobile IPv6 [MIPv6] as an example; however, these proposals could also be used with other signaling and for other functions than just node mobility. Currently MIPv6 is defined such that a mobile node can obtain two or more addresses: a home address (transparency address) and a care of address (diversion address). The home address is used for IP transparency to upper layers and the care of address is used for diversion of packets across an IP network. If ZOD is employed in the case of basic mobile IPv6, the beneficiary and the associated diversion endpoint are contained within the same node (the mobile); likewise, the CDE and CN are also the same node. ZOD tries to eliminate the need for tunneling overhead between Morrow Draft - Expires June 2002 4 Internet Draft Zero-Overhead Diversion Jan 2002 mobile and correspondent nodes associated with route optimized communications. The train of thought for this document is as follows: . The bearer processing semantics of the existing proposed tunneling methods of MIPv6 are detailed to facilitate understanding of these proposals and implementations. Some points are made about the stateless operation of these tunnels to justify why the tunneled addresses were assumed to be needed in the first place. . Security protections are then discussed which may be necessary to inhibit the use of these tunneling proposals as a method of reflection that could be exploited by nodes engaged in DDoS attack to achieve address spoofing. Of particular interest is the state that may be deemed necessary on the tunnel endpoints to protect against the reflection spoofing. . The fact that this state may need to be installed on the tunnel endpoints prior to bearer processing via signaling is then used to postulate that the stateless justification for including the tunneled source or destination address in every packet is no longer valid. . A generalized implementation example of zero overhead diversion operation applied to MIPv6 is then detailed. . Robustness considerations are discussed. . Other possible uses for zero overhead diversion are discussed. . Comparison and ramifications of zero overhead diversion vs. overhead-based tunneling methods are discussed. The primary motivation of this draft is to remove much of the tunneling overhead that has previously been perceived to be needed for diversion. If some form of ZOD is agreed to then there should be less need for per-packet tunneling overhead associated with diversion. Though the examples used within this document relate to IPv6, the same functionality can be applied to IPv4. 4 Existing Proposals for Diversion Tunneling Figures 1 and 2 below show the basic semantics of tunneling which have been suggested to be employed by route optimized mobile IPv6 to achieve transparent diversion along the path between a mobile and a correspondent node. Figure 2 tries to show the operations on packets sent from a correspondent node to a mobile node. Typically in a mobile IPv6 implementation there is an IP-layer shim which performs the tunnel endpoint functions. A shim exists on both the mobile and correspondent nodes. Figure 1 shows the operation of these shims on the forward path. The transport and application layers above IP and the shims use the Morrow Draft - Expires June 2002 5 Internet Draft Zero-Overhead Diversion Jan 2002 mobile's home address (TA) for their operations. The job of the shims is to swap and replace the care of address for the home address in order to guarantee transport and application transparency over network mobility events such as handoff or simply standalone IP-based remote attachment in a foreign subnet with IP transparency to a home subnet. In figure 1 the mobile node's application desires to send a packet to an application on the correspondent node. The application and transport layers assume and calculate checksums based upon the mobile's home address as the source. The mobile node's shim takes the home address and places it in an encapsulated home address option as described in [MIPv6] or a tunneled inner source address as described in [Deering]. The mobile node's shim then forwards the packet through the network. When the correspondent node's shim receives the packet it removes the tunneled home address option and places its value in the IP source address before delivery to the upper layer. Similar operation is shown in Figure 2 for the reverse path from the correspondent node to the mobile; however, instead of using a home address option, a routing header contains the home address as suggested by [MIPv6]. The [Deering] case uses a tunneled destination field. Morrow Draft - Expires June 2002 6 Internet Draft Zero-Overhead Diversion Jan 2002 FIGURE 1: Existing Forward-Path MIPv6 Tunneling =============================================== Mobile Node IP network Correspondent Node -------------------- --------------- -------------------- Application Shim Shim Application ----------- ------- ------- ----------- s=h d=n ---> s=c d=n -> s=c, d=n --> s=h, d=n s=h, d=n hao=h hoa=h s=hao=h s = source address field d = destination address field c = mobile's care of address (DA) n = correspondent nodes' address h = mobile's home address (TA) hao = home address option FIGURE 2: Existing Reverse-Path MIPv6 Tunneling =============================================== Mobile Node IP network Correspondent Node -------------------- --------------- -------------------- Application Shim Shim Application ----------- ------- ------- ----------- s=n d=h <--- s=n d=h <- s=n, d=c <-- s=h, d=c s=n, d=h d=rh=h rh=h rh=h rh = routing header We should note that one reason for sending the home address option was to facilitate the stateless operation of diversion for route optimization of bearer packets along the forward path when the correspondent node did not implement a binding cache. I.e. no state was previously justified as being needed on the correspondent shim in order to process the bearer stream. The packet is simply examined for the existence of the home address option or tunneled address and the address mapping could occur without any state being maintained at that endpoint. One could also make an argument that the extra addresses were needed as an index into specific routing tables; however, this is likely an invalid argument because the DA (care of address) can be used as the key to a specific table of routing entries. One could also make an argument that that these extra addresses were needed to distinguish that a particular packet was a diverted packet or a regular packet so that the shim processing could take place. This reasoning is likely invalid on the forward path from the CN to the MN as the MN already has (via prior signaling) and must maintain knowledge of the home and care of addresses if reflection spoofing is to be prevented. Complementary to the above argument is the argument that the MN's binding cache entry containing the correspondent address may have been corrupted, expired or the cache overrun and that the extra Morrow Draft - Expires June 2002 7 Internet Draft Zero-Overhead Diversion Jan 2002 address is needed to quickly handle these errors. This document postulates that this reasoning may prove to be a false concern as well. Details are described later in the ZOD robustness section. The same arguments apply to the route optimized reverse path when a binding was installed. Nevertheless, there used to be valid excuse on the route optimized forward path for the cases when the CN did not support the binding functionality; that is - until it was realized that a reflector spoofing hole existed and that it might need to be filled. 5 The Reflector Attack, Security Precautions and MIPv6 Recent discussions for mobile IPv6 have focused on security for protection against address spoofing via reflection [MIPSEC] related to DDoS attack and the additional overhead of various tunneling schemes. In addition, possible firewall conflicts for routing headers have also caused some concern. These items motivated the creation of this proposal; namely, firewall traversal, tunneling overhead and state needed to provide security protections. This document postulates that the security protections necessary to prevent reflector spoofing require that the tunnel endpoints must authenticate, authorize, install and maintain the address mapping state of the care-of and home addresses prior to enabling bearer processing as described in Figures 1 and 2. This document also postulates that the tunneling overhead was never warranted along the route optimized path between the MNs and CNs in mobile IPv6 for the case when the correspondent nodes did implement the binding cache function. In other words, if MIPv6 is to be hardened to protect against reflector spoofing attacks, then the justification for sending the tunneled address on every packet goes away completely on the path between the MN and CN. There is, however, justification for sending the home address during the signaling setup of these endpoints; namely, to install the address mapping state. We should also NOTE WELL that the information (state) that must be kept in order to prevent the reflector attack on the forward path between the MN and the CN is the same state that must be kept in order to enable route optimization; therefore, if the reflector attack is to be thwarted via code and state maintenance on the CN, you may as well make the processing of route optimization and the binding update on correspondent nodes a MUST as well. The other option would be to not mandate any functions for node mobility on correspondent nodes other than a lack of resources response; however, this may significantly hamper the ubiquity of any Morrow Draft - Expires June 2002 8 Internet Draft Zero-Overhead Diversion Jan 2002 form of mobile route optimization and a standardized global diversion technology in general for IPv6. 6 Zero Overhead Diversion (ZOD) applied to MIPv6 Zero-overhead diversion uses the address mapping state located at the tunnel endpoints to perform the address mapping required for the transparent diversion function. This state is assumed to have been conveyed via signaling or configuration of some sorts. This state is stored on the diversion endpoints and operated on by the associated shims. Figures 3 and 4 show the basic bearer processing semantics of zero overhead diversion applied to mobile IPv6. Basically the routing tables are inspected by the diversion shims to determine if the address mapping should occur or not. FIGURE 3: ZOD Tunneling on Forward Path =============================================== Mobile Node IP network Correspondent Node -------------------- --------------- -------------------- Application Egress Shim Ingress Shim Application ----------- ------- ------- ----------- s=h d=n ---> s=c d=n -> s=c, d=n --> s=h, d=n s=h, d=n s = source address field d = destination address field c = mobile's care of address (DA) n = correspondent nodes' address h = mobile's home address (TA) FIGURE 4: ZOD Tunneling on Reverse Path =============================================== Mobile Node IP network Correspondent Node -------------------- --------------- -------------------- Application Ingress Shim Egress Shim Application ----------- ------- ------- ----------- s=n d=h <--- s=n d=h <- s=n, d=c <-- s=h, d=c s=n, d=h 7 Implementation Example for MIPv6 application For this section the reader is assumed to be aware of the basic IP implementation concepts of Forwarding and Routing Information Base (FIB, RIB), ingress and egress processing of each as well as the typical flags used in well known open source implementations of IP stacks. The reader is also assumed to be familiar with the Mobile IP implementation of a binding cache and list and how one might implement such conceptual data structures into the existing ingress and egress tables of a commercial system. Morrow Draft - Expires June 2002 9 Internet Draft Zero-Overhead Diversion Jan 2002 We point out that some implementations may incorporate the binding cache as part of the existing tables with new flags or routing types while others may keep a separate table altogether. In this example we generically refer to any of these implementation options by using the generic term routing table in order to obviate the need to pin down a specific implementation. We must highly stress that the naming, data structure concepts, routing table schemas, etc.. are only one example of how one could implement and document these functions. This example is not intended to be "the only design" for this functionality and this example should also never be construed, as such. It is only given to facilitate understanding of the proposal. To describe zero overhead diversion in a more general manner than just the mobile IP application, we delineate the concepts of BN, BDE, CN and CDE described above in the terminology section. For instance, when applied to the route optimized node mobility application, the BN and the BDE are co-located on the mobile node. The beneficiary is really the transport layers and above while the BDE is the IP-layer shim which performs the transparency diversion on behalf of these upper layers. A similar analogy can be made for the correspondent and CDE. In all processing cases the reflector spoofing is prevented by the existence of the route entries in the routing tables. Signaling or configuration is used to authorize, set up and maintain these route entries. 7.1 Forward Path Processing This section relates to processing shown in Figure 3, above. It describes the operation of zero-overhead diversion endpoint shims related to the forward path processing of the node mobility application as desired for route optimized mobile IPv6 on the path between the mobile and correspondent nodes. Again, this processing assumes that signaling has already been done to set up the state. BDE Egress Shim Processing: -------------------------- An application (beneficiary) calls the IP stack to forward a packet to the correspondent node. The application assumes the home address (TA) as the source when generating any check-sums. It then passes the packet to the IP stack for forwarding. The IP stack performs a route lookup on the routing table for the destination address of the packet i.e. the correspondent node's address. As signaling was used to setup this binding, a route entry exists in the routing table and an entry-type delineator or perhaps flag may be used to delineate that that the route to the correspondent node is a zero overhead diversion BDE origination point. Morrow Draft - Expires June 2002 10 Internet Draft Zero-Overhead Diversion Jan 2002 This flag or entry-type causes the BDE Egress shim to be run. The route entry also contains or has a vector to the DA prefix along with a prefix length for the mapping. The shim applies the DA prefix using the associated prefix length to the source address of the IP packet. In this particular example, the prefix is a /128 and the prefix length indicates this. Namely, the mobile's care of address (DA) is written to the source address of the IP header. The packet is then forwarded. A simpler option for implementation exists if it is guaranteed that the DA is only used when the transparent diversion is needed i.e. with the TA. This option would simply check the routing table for the existence of source address TA prefix and apply the associated DA prefix to it. Simply put, examine the source address for the existence of the TA and then replace the source address with the DA. CDE Ingress Shim Processing: --------------------------- The IP stack receives the packet and performs a route lookup (some may call this filter lookup) on the source address of the packet. The routing table entry for the source address lookup on the care of address indicates via a flag or entry-type that a ZOD CDE ingress shim is to be run. This route entry also contains or has a vector to the TA prefix (home address) and associated prefix length (/128) that was installed via signaling at some earlier point. The CDE Ingress shim applies the TA prefix (home address) using the TA length (128) to the IP source field and delivers the packet to the (correspondent) transport or other application layers for further processing. Namely, the mobile's home address (HA) is written to the source address of the IP header. The packet is then delivered to the correspondent. 7.2 Reverse Path Processing This section describes the operation of zero-overhead diversion endpoint shims related to the reverse path processing of the node mobility application as desired for route optimized mobile IP on the path between the correspondent and mobile nodes. This processing also assumes that signaling has already set up the state. This section relates to bearer processing shown in Figure 4, above. CDE Egress Shim Processing: -------------------------- An application or transport layer submits a packet to the IP stack for forwarding to the beneficiary's TA (mobile's home address). The IP stack performs a route lookup on the destination address, TA. The table entry for the mobile node's home address indicates via a flag or entry-type that this is a zero-overhead diversion CDE egress Morrow Draft - Expires June 2002 11 Internet Draft Zero-Overhead Diversion Jan 2002 entry and that the corresponding shim should be run. The CDE egress shim applies the DA prefix (mobile's care of address) using the associated DA length (/128), contained or vectored to via the route entry, to the IP destination address field. Essentially the mobile's care of address is written to the destination field. The packet is then forwarded. BDE Ingress Shim Processing: --------------------------- The IP stack receives a packet and performs a route/filter lookup on the source address. The ingress table entry for the source address (i.e. the CN's address) indicates via a flag or entry-type that the zero-overhead diversion BDE ingress shim should be run. The BDE ingress shim applies TA prefix (mobile's home address) and associated prefix length (/128) contained in or vectored to via the route entry. Essentially the home address is written into the IP destination field before passing the packet onto the transport or application layers. A simpler option for implementation exists if it is guaranteed that the DA is only used when the transparent diversion is needed i.e. with the TA. This option would simply check the routing table for the existence of the destination address, DA, and apply the associated TA prefix to it. Simply put, examine the destination address for the existence of the DA and then replace the destination address with the TA. 8 Generalizing Zero Overhead Diversion In the above example, the mobile IPv6 application assumes that the Beneficiary and Correspondent are co-located with the BDE and CDE, respectively; however, the proposal can be applied to forwarding devices, as well, for various functions. In the previous example, the terminology "an application calls or passing the packet onto the transport or application layers" could be replaced with the packet arrives on an interface or the packet is forwarded such that the assumed co-location of the beneficiaries/correspondents with the endpoints of the example becomes irrelevant. Also, the MIP example shows the application of the diversion functions on /128s which may be appropriate for some mobile hosts. The diversion can also work on a prefix basis for the case of diverted prefixes. As work continues on IPv6 we may find that /64 is appropriate; however discussion of 8+8 is not within the scope of this document. 9 End to End Considerations Morrow Draft - Expires June 2002 12 Internet Draft Zero-Overhead Diversion Jan 2002 As the address mapping is end to end there is no collision with any end to end operation. An example and proof of this is that IPSEC can still be used, as is, by using the transparency address for integrity calculations. Care must be taken in co-located implementations to insure that the shim processing occurs before (in the ingress case) and after (in the egress case), the IPSEC handling. The diversion is transparent to firewall operations. Zero-overhead diversion can be applied host to host (end to end), host to router (end to edge) or router to router (edge to edge). Though address translation is employed, it is done on both ends transparently. This diversion proposal has none of the associated application and transport layer transparency problems associated with the more traditional well-known address translation schemes. In fact, it can be used to achieve diversion even when traditional NATs are present without any changes to the traditional NATs. 10 Robustness - Corruption of/Stale Routing Table Entries As routing tables or configuration information must be kept on the diversion endpoints to perform this mapping, this information may be corrupted or stale due to temporary network outages or race conditions. If the information is corrupted then it is assumed that false information has been inserted into the routing table somehow or the table has been corrupted such that it appears that there is no routing entry for the diversion. If a table entry is not found for the DA in the CDE, the incoming packet will be treated as a normal IP packet and likely dropped at the transport or application layer. An ICMP message or application message may result back to the DA which will may result in a throttle of the associated socket in question. Another possibility is that the application simply times out. This may also result in the throttling of a socket. If an entry was found for the DA and a corrupt mapping occurred this would likely result in the packet being dropped at the application/transport layer (IPv6) as integrity checks would fail. This failure may result in an ICMP or application error message to the originating node. This may also result in the transport layer being reset. Another possibility is the packet is simply dropped which may cause the application/transport to time-out. For each case the associated socket may be throttled in some manner. We should note that ZOD is no less robust than IP itself with respect to packet corruption and temporary network outages. For instance a set of routers' or hosts' configuration or cache may become corrupted as well - resulting in similar misbehaviors. IP/Transport/application integrity checks, audits, heartbeats, timeouts and throttling are mechanisms used to deal with corruption Morrow Draft - Expires June 2002 13 Internet Draft Zero-Overhead Diversion Jan 2002 and stale entry errors. IP alone does not guarantee delivery and neither does ZOD. We should also note that if a nodes' routing tables are corrupted it is highly likely that other memory spaces are corrupted as well. The main point this section is trying to convey is that using the remote possibility of memory corruption or staleness of route entries as an excuse for tunneling overhead is probably unwarranted. For each of these error cases and for other cases related to IP networks in general, application and transport stacks typically perform some sort of throttling procedure on their sockets. It is recommended that nodes which desire diversion functions throttle the diversion signaling when the sockets are throttled. The time values for re-establishment of communications using this throttling approach may be seen to be too great for certain streams. As a final protection against these types of errors, the signaling associated with the diversion may employ a heartbeat, audit or refresh transaction scheme in order to improve the robustness. The refresh semantics detailed in [MIPv6] are examples of such signaling to improve robustness. Specification of this signaling is beyond the scope of this document. Again, the recovery time for correcting these errors via a heartbeat or audit may be seen as too much. One could decrease the interval of this heartbeat but this may conflict with the original goal of reducing overhead. Again, the probability of these errors occurring is rather small. In the unlikely chance that beneficiary finds that these errors are occurring with some regularity the lifetime of the refresh can be decreased. An adaptive sliding lifetime window for the audit could be employed by the beneficiary. 11 Robustness - Cache Overruns There may also be some concerns with this proposal related to cache overruns. The handling of cache overruns is implementation and signaling specific but we mention it here to try to capture the possible behaviors of diversion signaling in a general manner. For instance if the mapping information is stored in a cache, the cache may be protected by having a threshold that takes appropriate actions of notifying interested parties when entries are forced to expire or are deleted due to an overrun, handoff etc.. via signaling. Another implementation may simply rely on resource feedback replies in the binding signaling and back-off procedures to insure that the overruns never occur. This memo recommends that implementations be designed such that the entities affected by cache deletions due to overruns be notified via signaling and that the diversion signaling employ a mechanism to Morrow Draft - Expires June 2002 14 Internet Draft Zero-Overhead Diversion Jan 2002 notify the beneficiary when no resources are available for the diversion. Again, the fact that cache overruns can occur is not a valid excuse for maintaining the tunneling overhead when memory resources are available. 12 Security Implications Signaling or trusted configuration MUST be used to set up the zero overhead diversion state in diversion endpoints. The signaling MUST be authenticated and authorized to protect against reflection, replay and man in the middle abuses. The signaling used to set up this diversion mechanism is beyond the scope of this document other than that these are the requirements for this signaling. Zero overhead diversion could be employed via many different signaling mechanisms. The signaling could be bundled or piggybacked with bearer packets in some cases; however, care must be taken to insure that any security credentials related to the diversion setup are either the same as that of the application or are delineated some way in the packet such that separate credentials can exist. The delineation allows the receiving nodes to determine which function each applies. In order to fully protect against diversion-oriented man in the middle threats, the transparency address in the diversion signaling MUST be made confidential in some fashion. The use of zero overhead diversion is compatible with and transparent to IPSEC. 13 Other Signaling Semantics In the case of signaling prefix lengths associated with TAs and DAs, the signaling is not necessarily required to explicitly include the prefix lengths. If the prefix lengths are not present in the signaling, then the implementation can simply assume a /128 or /64 in the case of IPv6 depending on your inclination and a 32-bit length in the case of IPv4. 14 NAT Interactions Zero Overhead Diversion is compatible and transparent with traditional NATs. IPv6/v4 boundaries are beyond the scope of this document and for further study. 15 Applicability of Zero Overhead Diversion Morrow Draft - Expires June 2002 15 Internet Draft Zero-Overhead Diversion Jan 2002 Zero-overhead diversion can be used only if the beneficiary has associated with it two or more addresses such that each address used as a DA has one and only one TA associated with it to represent the beneficiary. Such a case exists for the mobile IPv6 route optimized path between mobile and correspondent nodes. The proposal can also be applied to route optimized IPv4 using co-located addresses in a similar manner. It should be pointed out the address spaces of each address (TA, DA) may be disparate as long as both diversion endpoints have link connectivity to the networks using each address space. Zero-overhead diversion may also be used to provide connectionless transport across global networks such as the Internet to sites using a common sub-netted local or perhaps site address space. For instance in a VPN of sorts connecting two or more corporate sites that use different prefixes of the same local address space. Each node on the network must be allotted both an interior and exterior address in such as case. Other uses for which zero-overhead diversion are: local mobility management, end to end load sharing, content distribution, router mobility, obviating an IPv6 local boundary among particular global prefixes, etc.. In many of these cases the conservation of addresses may conflict with conservation of bandwidth overhead, however. Detailed specification of the signaling or configuration associated with each use is beyond the scope of this specification. More than one function can be achieved at the same time on the same nodes using ZOD. ZOD is a recursive technology in that a TA may be a DA for another TA. Depending on the functionality or application desired, zero overhead diversion can be set up via configuration or with secure signaling. Zero-overhead diversion can be applied under the following circumstances: . The beneficiary of the diversion is known via two or more associated addresses: a transparency address (TA) and a diversion address (DA). . The beneficiary may be known by multiple TAs and DAs provided that for each DA there corresponds one and only one associated TA. Multiple DAs may be associated with a single TA for a single instance of diversion. . However, ZOD can be recurrent in that a DA may actually be a TA for another DA. This is useful if more than one diversion function is needed on the same nodes. . Both of the diversion endpoints are made aware of these distinct addresses either via prior configuration or signaling. . Each diversion endpoint maintains this address information for the period in which the diversion is in use. Morrow Draft - Expires June 2002 16 Internet Draft Zero-Overhead Diversion Jan 2002 . The correspondent has an address which is in the same address space as the beneficiary's transparency address. 16 ZOD compared with Hardened Diversion Tunneling By hardened we mean that man in the middle and reflector spoofing checks are employed in the tunnel endpoints of the overhead-based tunneling methods. Overhead-based diversion solutions allow multiple TAs to employ the same DA(s). This is the main difference. With ZOD you have to have at least one separate and unique DA prefix for each unique TA prefix. Though this may be considered a concern with IPv4, whether it may or may not be a concern with IPv6 could be debated due to the expanded address space. Some implementations of overhead-based diversion may not need to be hardened on the mobile node for ingress packets i.e. the source address route-lookup may not be deemed necessary to verify if the a binding is associated with the CN's source address in the case of MIP. The optional implementations, given in the ZOD applied to MIPv6 example above, were designed to address these concerns; however, these implementation options have further restrictions on the use of the DA and are more susceptible to man in the middle attacks. We can also clearly say that ZOD can not recover from stale entries and memory corruption of entries as fast as overhead based diversion. ZOD will recover eventually, though if a heartbeat audit is in place for the binding signaling or if diversion signaling is coupled with socket throttling procedures. This inequality in recovery time brings us to the discussion of MR. ZOD. 17 More Robust ZOD (MR. ZOD). As noted above, ZOD may not recover from table corruption and stale entries as fast as overhead-based methods. The reason overhead-based methods recover faster is due to the fact that the packets themselves indicate diversion by the existence of the extra tunneled addresses. More Robust Zero Overhead Diversion (MR. ZOD) removes this inequality with the overhead methods by using a bit in either the flow label or traffic class field to indicate that the packet is diverted or not. For example, when the low order bit of the flow label is set, the shims are run and if there was corruption or staleness of the table entries, appropriate signaling is used to correct the error in the same manner as the overhead based methods. Morrow Draft - Expires June 2002 17 Internet Draft Zero-Overhead Diversion Jan 2002 18 Deployability It appears that if there are an arbitrary set of nodes that unilaterally agreed to employ ZOD for some function, then they can; irrespective of other nodes within the network. Nothing prevents its use. If MR. ZOD employs a flow label bit to indicate diversion it is expected that nothing will prevent its use either. If MR. ZOD employs a traffic class bit to indicate diversion it is expected that policing and remarking may prevent its use. So the use of traffic class bit may result in backwards compatibility and deployment issues day one. 19 Decisions Decisions Decisions In a start from scratch environment, it seems somewhat arbitrary as to whether a traffic class or a flow label bit is used for MR. ZOD. One could suggest that a traffic class bit would allow MR. ZOD to be used on IPv4 as it does not have a flow label. Then again, there is the deployment issue with the traffic class bit. And then again, it may be that ZOD with the use of audits (heartbeats), itself, is considered good enough and the need to reserve an extra bit to indicate diversion is not needed. The same reasoning is applied to IP itself in that IP does not guarantee delivery. This is why sockets are throttled and transport layers exist. This document solicits opinions on these matters from others in the IETF. Please direct opinions to the author or an appropriate mailing list. It is intended to introduce the concept of diversion without tunneling, discuss the benefits, issues and possible ways forward. The intent is to have an appropriate working group or set of working groups determine the best way forward. It is the authors opinion that the advantages in terms of transparency through firewalls and overhead reduction far outweigh any perceived negatives of both ZOD and MR. ZOD. 20 IANA Considerations None 21 Notice on Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of Morrow Draft - Expires June 2002 18 Internet Draft Zero-Overhead Diversion Jan 2002 claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 22 References [MIPv6] draft-ietf-mobileip-ipv6-15.txt - work in progress. [Deering] draft-deering-ipv6-encap-addr-deletion-00.txt - work in progress. [MSEC] draft-ietf-mobileip-mipv6-scrty-reqts-02.txt - work in progress. [NAME] draft-irtf-nsrg-report-00.txt - work in progress. 23 Author's Addresses Glenn Morrow Nortel Networks 2201 Lakeside Blvd. Richardson, TX. USA Email: gmorrow@nortelnetworks.com 24 Full Copyright Statement 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. Morrow Draft - Expires June 2002 19 Internet Draft Zero-Overhead Diversion Jan 2002 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. 25 Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. Special thanks is due to Fayaz Kadri, Cheng-Yin Li, Brian Hibbard and Leland Dillaha. Thanks are also due to Eric Nordmark for suggesting that these proposals be documented in the IETF format for possible consideration. Morrow Draft - Expires June 2002 20