Network Working Group D. Jen Internet-Draft M. Meisel Intended status: Informational D. Massey Expires: January 3, 2008 L. Wang B. Zhang L. Zhang July 2, 2007 APT: A Practical Transit Mapping Service draft-jen-apt-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The size of the global routing table is a rapidly growing problem. Several solutions have been proposed. These solutions commonly divide the Internet into two parts, one for customers and one for providers, where only provider addresses are globally routable. Packets destined for customer addresses are tunneled through provider Jen, et al. Expires January 3, 2008 [Page 1]
Internet-Draft Transit Mapping July 2007 space. For this process to work, there must be a mapping service that can supply an appropriate provider-edge address for any given customer address. We present a design for such a mapping service. We adhere to a "do no harm" design philosophy: maintain all desirable features of the current architecture without negatively affecting its security or reliability. Our design aims to minimize delay and prevent loss in packet encapsulation, minimize the number of new or modified devices, and keep the level of control traffic manageable. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Mapping Service . . . . . . . . . . . . . . . . . . . . . 5 4.1. A Mapping Example . . . . . . . . . . . . . . . . . . . . 6 5. Multihoming Support . . . . . . . . . . . . . . . . . . . . . 7 5.1. Using Alternate ETRs During Failures . . . . . . . . . . . 8 5.1.1. Handling TS Prefix Failure . . . . . . . . . . . . . . 9 5.1.2. Handling Single TS Address Failure . . . . . . . . . . 9 5.1.3. Handling User-to-TR Link Failure . . . . . . . . . . . 10 5.2. Summary of Requirements for Multihoming Support . . . . . 11 6. Exchanging Mappings Between ASes . . . . . . . . . . . . . . . 11 6.1. In Defense of BGP . . . . . . . . . . . . . . . . . . . . 12 7. Security and Robustness . . . . . . . . . . . . . . . . . . . 13 7.1. Detecting Misconfigurations . . . . . . . . . . . . . . . 13 7.2. ICMP Mapping Packets . . . . . . . . . . . . . . . . . . . 14 7.3. Other ICMP Packets . . . . . . . . . . . . . . . . . . . . 14 7.4. Default Mapper Scalability . . . . . . . . . . . . . . . . 15 8. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 15 9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. BGP Mapping Announcement Fields . . . . . . . . . . 18 Appendix B. ICMP Mapping Message Fields . . . . . . . . . . . . 19 Appendix C. ICMP Border Link Failure Fields . . . . . . . . . . 19 Appendix D. Hidden Backup Mappings . . . . . . . . . . . . . . . 19 Appendix D.1. Hidden Backup Mapping Protocol . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Jen, et al. Expires January 3, 2008 [Page 2]
Internet-Draft Transit Mapping July 2007 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction The unexpected, explosive growth of the Internet is causing a greater and greater strain on its infrastructure. This problem has been well-documented in [RAWS][AddrAlloc]. Several solutions have been proposed to address this problem [EFIT][CRIO][LISP], most of which involve separating the Internet into two parts -- one for user networks and one for transit providers. Routers in transit space would only need to know how to route to transit prefixes, which are stable and conducive to topological aggregation. When a packet is sent from user address A to destination user address B, A's provider- edge router (the ingress tunnel router, or "ITR", as defined in [LISP]) encapsulates the packet and sends it through transit space to B's provider-edge router (the egress tunnel router, or "ETR"). B's ETR decapsulates the packet and forwards it to the appropriate recipient, B. When encapsulating a packet, A's ITR must somehow determine B's ETR's transit-space address and include it in the outer header. In general, any ITR must be able to map any given user-space address to a corresponding ETR transit-space address for proper tunneling through transit space. This illustrates the need for a mapping service that can provide this address. The design details of this mapping service will play a large part in determining the effectiveness of any proposed implementation of a user/transit provider address space separation. The mapping service also presents an exciting opportunity to enhance the services currently offered by the Internet, which is further reason to carefully consider how this service should be implemented. Should mapping information be distributed via a push or a pull model? What additional information, if any, should be obtained along with the mapping information? Can we satisfy the mapping requirement without sacrificing any services or packet delivery quality? Our answers to these questions are rooted in a "do no harm" design philosophy: improve routing scalability without sacrificing any desirable features in the current architecture or negatively affecting its security and reliability. To this end, we present APT, A Practical Transit mapping service designed with the following goals in mind. Jen, et al. Expires January 3, 2008 [Page 3]
Internet-Draft Transit Mapping July 2007 o Minimize delay and prevent loss in packet encapsulation. o Minimize the number of devices that need to be modified to support our new design. o Minimize the number of devices that will require additional resources or complexity. o Keep the design modular so that the method used to propagate mapping information is independent from the method used to retrieve mapping information for tunneling. APT is designed for use with eFIT [efitID][EFIT], one of the major proposals for user/transit provider address space separation. However, APT should be generally applicable to other proposals of the same class. 3. Terminology User Network (UN) - A network that pays another organization to deliver its packets through the Internet. Each user network is a customer of some Transit Network (see definition below). "User network" holds the same meaning as it does in the eFIT proposal. Transit Network (TN) - An AS whose business is to provide packet delivery services for its customers. Transit Networks serve as providers for user networks. As a rule of thumb, if the AS appears in the middle of any ASPATH in a BGP route today, it is considered a transit network. Transit Space (TS) - The address space used by transit networks. Nodes within a transit network are assigned TS addresses. Sometimes the term "transit space" will refer to the non-edge area of the Internet where TS prefixes are routable. User Space (US) - The address space used by user networks. Nodes within a user AS are assigned user-space addresses. Sometimes the term "user space" will refer to the edges of the Internet whose prefixes are not routable in transit space (though packets to those addresses are deliverable through transit space). We assume that TS and US addresses can be clearly distinguished. Border Link - A link that crosses the boundary between transit space and user space. Default Mapper - A new device required by our mapping service. Each transit network MUST have at least one default mapper. A default Jen, et al. Expires January 3, 2008 [Page 4]
Internet-Draft Transit Mapping July 2007 mapper carries a complete mapping table. In other words, given any user-space address, default mappers can return the TS address of a provider-edge router corresponding to that address. To support the growing trend towards multihoming, default mapping entries will map a user-space prefix to a non-empty SET of TS destinations, all of which have a direct connection to the destination network in user space. Tunnel Router (TR) - These devices will replace all current provider- edge routers, located at the provider end of border links. Like ITRs and ETRs in LISP [LISP], TRs provide the encapsulation and decapsulation services required for tunneling user packets through transit space. A TR has both ITR and ETR functionality, meaning that any TR can perform both encapsulation and decapsulation of packets. To properly encapsulate any given user-space packet, TRs can query the default mappers for mapping information. TRs also cache commonly used mapping entries locally. Note that TR cache entries are NOT identical to the mappings stored at default mappers (see the definitions of "mapping" and "mapping entry" below). TRs are designed to be as simple and as fast as possible, adding only what is necessary for proper tunneling functionality. APT Node - A general term referring to any new device type introduced by APT. This includes both default mappers and TRs. Router - These are ISP-owned non-border routers that exist today. Other than minor configuration changes, these routers need no alteration or replacement, and can be used just as they are used currently. Mapping - A mapping contains a user-space prefix and a non-empty SET of ETR TS addresses associated with the prefix. Mappings also include related information such as the user's public key and priority rankings for each of the ETRs in the set. Default mappers store mappings. Mapping Entry - A mapping entry contains a user-space prefix and any SINGLE ETR TS address associated with the prefix. Any mapping entry is a subset of the complete mapping for its user-space prefix. TRs store mapping entries along with an associated TTL. A mapping entry is removed once its TTL expires. 4. The Mapping Service To minimize the latency introduced by encapsulation, APT seeks to store mapping information as close to the ITR as possible. However, the global mapping table is likely to grow very large over time. To avoid undue memory requirements for ITRs while still keeping mapping Jen, et al. Expires January 3, 2008 [Page 5]
Internet-Draft Transit Mapping July 2007 information within reach, we introduce the concept of default mappers. A TR does not need to store the entire global mapping table. Instead, it queries a default mapper for mapping information and caches recently used mapping entries. Default mappers are the only devices in the network that need to store the complete global mapping table. As we will see in the following example, TRs only use default mappers in the event of a cache miss. This means that, given large enough caches at the TRs, network latency will not heavily depend upon default-mapper performance. Additionally, we propose the use of anycast to reach default mappers within an AS. Each TN AS need only have a single default mapper, but the use of anycast makes it easy for a TN to deploy more. The result is a robust, scalable default mapping system. 4.1. A Mapping Example _ _ / \ / \ / A \ / B \________ \___/ \___/ | | | | User Space - - - - -|- - - - - - - - - - - - - -|- - - - -|- - - - - - - - - - - - | | | Transit Space .--+---. .--+---. | _-| ITR1 |-_ _-| ETR1 |-_ | / '------' .`--. .--'. '------' .`--+--. | ____ | X |--------| X | ____ | ETR2 | | | M1 | '-;-' '-:-' | M2 | '-;----' \ '-/\-' / \ '----' / \___/ \___/ \__________/ ______/ \____________________ | User Net | TS Addr | Priority | |----------|----------|----------| | ... | ... | ... | |----------|----------|----------| | B | ETR1 | 10 | | | ETR2 | 20 | |----------|----------|----------| | ... | ... | ... | '--------------------------------' Figure 1. This is a simple topology for demonstrative purposes. A and B are user networks addressable via user-space prefixes, ITR1, Jen, et al. Expires January 3, 2008 [Page 6]
Internet-Draft Transit Mapping July 2007 ETR1, and ETR2 are TRs, any node labeled "X" is a router, and M1 and M2 are default mappers. A portion of the mapping table for M1 is shown. In this section, we illustrate how TRs and default mappers interact within an AS to properly tunnel user-space packets through transit space. In Figure 1, assume a node in network A sends a packet to a user- space address in network B. When this packet arrives at ITR1, ITR1 looks up the destination user-space address in its mapping cache. If a matching prefix is present in its cache, ITR1 simply encapsulates the packet with the corresponding TS destination address and send it across transit space. If a matching prefix is not present, ITR1 will send the packet through its default mapper. It does this by encapsulating the packet with the anycast address for default mappers in its AS as the destination. This packet will arrive at M1, the only default mapper in ITR1's AS. When M1 receives the packet, it decapsulates it and examines the user-space destination address. Since default mappers store the full, global mapping table, a default mapper will always be able to encapsulate the packet with a valid TS destination address. All packets encapsulated by a default mapper MUST contain the default mapper's TS address as the source address. In addition to forwarding the packet to an appropriate ETR (ETR1, in this case), M1 also treats the incoming packet as an implicit request from ITR1 for mapping information. M1 responds to ITR1 with an ICMP packet containing a mapping entry that maps B to ETR1. This allows ITR1 to add this mapping entry to its cache so that ITR1 can tunnel further packets destined for B directly to ETR1. The mapping entry also contains a time to live (TTL) that is set by M1. The TTL ensures that ITR1 will occasionally re-request this mapping information from M1. At this time, if the mapping information changed in any way since ITR1's prior request, M1 can respond with an updated mapping entry. Without this TTL, ITR1's cached information may become inaccurate over time. 5. Multihoming Support In the example above, the observant reader may have noted that B is multihomed. That is, B can be reached through both ETR1 and ETR2. Multihoming provides B with both enhanced reliability in case of a connectivity failure and the flexibility to split incoming traffic across different ETRs. Jen, et al. Expires January 3, 2008 [Page 7]
Internet-Draft Transit Mapping July 2007 In accordance with our design goals, all of the logic for selecting a destination for a multihomed user is contained within default mappers. Default mappers will store mappings containing all of the ETRs for a given user-space prefix, and ITRs will only store a single mapping entry per user-space prefix. When an ITR requests a mapping entry for a multihomed user, it is up to the default mapper to decide which one to return. Many users will want to have some control over which ETR is used for incoming traffic. To allow this, we let users assign a priority value to each of the mapping entry for their prefixes, making it available to all default mappers throughout the transit space (see Section Section 6). The number is to be treated like a ranking -- an ETR with a lower priority value is more preferable. At the same time, a transit network may also has its own preference regarding which of the ETRs to use for a given user-space prefix. Default mappers can use a combination of locally configured routing policies and the user priority information to choose from a set of valid ETR addresses. Going back to Figure 1, assume that ITR1 does not have a mapping entry for B in its cache. When A sends B a packet, ITR1 will send the packet to M1. If M1 has no preference between ETR1 and ETR2, it will examine the priority values in B's mapping and select ETR1, B's most preferred ETR. M1 forwards the packet to ETR1 and returns the appropriate mapping entry to ITR1, which stores the mapping entry in its cache. In the case of a priority value tie, the default mapper can break the tie by picking the ETR to which it has the shortest path. If some ETRs are tied in terms of both lowest priority value and shortest path, the default mapper is free to break the tie arbitrarily. The address of the selected ETR will be used as the destination address when encapsulating the packet. We envision that users will be able to manipulate their incoming traffic load by setting appropriate priority values in their mapping. A user who wants load balancing can assign the same priority value to all of his mapping entries. A user who wants to have one TN as a primary provider and another only as a backup can simply assign a higher priority value to his ETR at his backup provider. 5.1. Using Alternate ETRs During Failures When a network failure has caused an ETR to become unreachable, an affected multihomed user will expect his traffic to be temporarily routed through alternate ETRs. There are three general types of failures that would require an ITR to use an alternate ETR: (1) an ITR may discover via BGP that it can no longer reach the TS prefix Jen, et al. Expires January 3, 2008 [Page 8]
Internet-Draft Transit Mapping July 2007 containing the address of the intended ETR, (2) an ITR may learn via ICMP Destination Unreachable packets that its intended ETR is unreachable, and (3) the link between a user network and its TR may be down, a new problem introduced by the tunneling architecture. We will explain how to handle each of these failure types below, using Figure 1 as a reference. We assume that, at the time of failure, all TN ASes are using ETR1 to reach B. To assist in handling these failures, we include a time till retry (TTR) for each mapping entry in every mapping stored in default mappers. Normally, the TTR for each mapping entry is set to zero, indicating that it is usable. Any mapping entry with a non-zero TTR value is considered invalid. We will refer to the action of setting a mapping entry's TTR as "invalidating the entry." Mapping entries that map to unroutable destinations are also considered invalid. So long as a mapping entry is invalid, default mappers will not use this entry as a destination address or include it in mapping responses. The role of the TTR for handling failures will become clear in the explanations below. 5.1.1. Handling TS Prefix Failure For failures of type (1), ITR1 has no route to ETR1. Assume a host in network A attempts to send a packet to a host in network B. If ITR1 does not have B's mapping in its cache, it will forward the packet to M1 (see Section Section 4.1). If ITR1 does have B's mapping in its cache, it will see that it has no path to ETR1, and send the packet to M1 instead. M1 will also see that it has no route to ETR1, and thus select the next-most-preferred ETR for B, ETR2. If it has a route to ETR2, it sends the packet with ETR2 as the TS destination address and replies to ITR1 with the corresponding mapping entry. M1 can assign a relatively short TTL to the mapping entry in its response. Once this TTL expires, ITR1 will forward the next packet for B to the default mapper, which will respond with the most-preferred mapping entry that is routable at that time. This allows ITRs to quickly go back to using ETR1 once it becomes routable again. 5.1.2. Handling Single TS Address Failure In the second case, the TS prefix containing ETR1 is still routable from ITR1, but ETR1 is unreachable from ITR1. Thus, ITR1 will receive an ICMP Destination Unreachable message in response to any packet sent to ETR1. ITR1 will need to turn to its default mapper for an alternate TS destination address for B. M1 will send an alternate valid mapping entry (if available) to ITR1. For this to work, TRs MUST forward all received ICMP Destination Unreachable messages to their default mappers. Default mappers MUST then Jen, et al. Expires January 3, 2008 [Page 9]
Internet-Draft Transit Mapping July 2007 invalidate ALL mapping entries that map to the unreachable TS destination address. To allow this, default mappers will have a reverse-mapping table to go along with their mapping table. These reverse-mapping tables map TS addresses to their corresponding user- space prefixes. Now default mappers can look up the unreachable TS address in their reverse-mapping tables, and temporarily invalidate all entries that map to that TS address. 5.1.3. Handling User-to-TR Link Failure The final case involves a failure of the link connecting ETR1 to B. In the previous two cases, current Internet standards were in place to allow ITR1 to know that a failure occurred. This case, on the other hand, is a new type of failure that does not exist in today's infrastructure. Therefore, it will require a new type of failure message. These messages will take the form of a new ICMP message type, which will include the user-space prefix that was not reachable. TRs MUST be configured to forward all border link failure ICMP messages to their default mappers, in the same fashion that TRs forward all destination unreachable ICMP messages to their default mappers. Going back to our example, when ETR1 discovers it cannot forward the packet to B due to a border link failure, it will send ITR1 an ICMP packet of our new type stating that B's prefix is currently unreachable. ITR1 will forward the border link failure ICMP message to its default mapper, which will invalidate that mapping entry. If the mapping entry is already invalid, it will reset the entry's TTR. If the prefix has an alternate valid mapping entry, M1 will send this mapping entry to ITR1. Furthermore, to minimize packet losses, ETR1 should not simply drop the packet addressed to the unreachable user network. Instead, ETR1 should send this packet to M2 in hopes of finding an alternate ETR that can reach the user network. However, M2 will then look up a TS destination address for B and choose ETR1 again. This is undesirable, since we are seeking an alternative destination. Therefore, when encapsulating packets for forwarding, default mappers MUST check if the chosen TS destination address is the same as the TS sender address in the packet's original TS header. If so, this indicates that the TS-to-user link is down at this ETR. In such cases, default mappers MUST invalidate the corresponding mapping entry and seek an alternative. To complete our example, ETR1 sends an ICMP message to ITR1 and also sends the data packet to M2. M2 looks up a destination TS address for the packet and finds ETR1. M2 then compares this TS address with the TS address of the original sender of the packet, which is also Jen, et al. Expires January 3, 2008 [Page 10]
Internet-Draft Transit Mapping July 2007 ETR1. Since they are the same, M2 invalidates this mapping entry and finds an alternate destination, ETR2. M2 then forwards the packet to ETR2. 5.2. Summary of Requirements for Multihoming Support TR cache entries MUST include a TTL value, which will be provided by their default mapper. In default mappers, every TS destination address in a mapping MUST include a time until retry (TTR). Usable mapping entries have a TTR of zero. When a mapping entry becomes unreachable due to failures, the TTR MUST be set to a pre-configured value. An alternate entry in the same mapping MUST be used in place of an invalid mapping entry if available. Default mappers MUST be able to invalidate all mapping entries that map to a particular TS destination address that has become unreachable. This can be implemented using a reverse-mapping table. We will use a new type of ICMP message to indicate border link failure. TRs MUST forward all ICMP destination unreachable and border link failure messages to their default mapper. If an ETR cannot send a packet due to a border link failure, it MUST send this packet to its default mapper. This ETR MUST use its own TS address as the source TS address of the packet. Upon receipt of any data packet, default mappers MUST check if the chosen TS destination address is the same as the TS source address in the packet's original TS header. If so, default mappers MUST invalidate the corresponding mapping entry and look for an alternate ETR for the packet. 6. Exchanging Mappings Between ASes In order for default mappers to store a full, global mapping table, there must be some way for them to receive mappings from other ASes. To avoid introducing latency or packet loss when encapsulating packets, the default mappers must have a full set of mappings available locally. To accomplish this, we distribute mappings using a push method. Default mappers MUST regularly announce the mappings for all of their customers to the rest of the network. When a default mapper receives new mappings, it stores them in its Jen, et al. Expires January 3, 2008 [Page 11]
Internet-Draft Transit Mapping July 2007 mapping table, replacing any existing mappings. When a TR receives new mappings, it simply deletes any matching cache entries. Any further communication with the formerly cached host will require the use of a default mapper. This ensures that only the default mappers need to validate mapping announcements and enforce policy. Mapping messages will be flooded throughout the network via BGP. A new BGP attribute will be required for this purpose. We have selected BGP initially in order to ease incremental deployment and minimize the changes required to existing routers. However, mapping announcements could easily be distributed via a different reliable broadcast protocol at a later date. Transitioning mapping distribution to a different protocol will not affect any other aspect of APT. 6.1. In Defense of BGP Despite the use of BGP, mapping announcements will not cause the same problems that BGP routing announcements do in the Internet today for the following reasons. First, for routing announcements, the path taken to reach each router is a crucial piece of information. For mapping announcements, the path taken to reach each APT node is not meaningful. This means that only a single copy of each mapping announcement needs to reach each APT node, providing an opportunity to prune duplicates, or even to make use of a spanning tree. This also means that path exploration and its repercussions do not exist for mapping announcements. Second, mapping announcements only require processing at default mappers and, to a lesser extent, TRs. Other routers in the network need only pass these announcements along to their peers. Thus, the processing burden placed on other routers by excessive routing updates is completely avoided. Finally, there will be far fewer mapping announcements than there are routing announcements. TNs rarely change the addresses of their equipment, and customers are generally under a monthly contract with their provider TNs. Therefore, permanent mapping changes are unlikely to occur more than once per month per customer. Furthermore, transient failures do not cause mapping announcements in APT. The most common cause of mapping announcements will be regular refresh announcements, which should never need to be sent more than every other day in most cases. Jen, et al. Expires January 3, 2008 [Page 12]
Internet-Draft Transit Mapping July 2007 7. Security and Robustness Using BGP to distribute mapping announcements guarantees that they are only accepted from manually configured BGP peers. This ensures that mapping announcements are no less secure than routing announcements today. When applied to the eFIT architecture, however, the security of this scheme is greatly increased. This is due to the fact that eFIT TS addresses are not addressable from user space [efitID][EFIT]. This turns out to be a major boon for the BGP trust model, since only other TS nodes are valid BGP peers. The complete separation of the eFIT TS address space provides another security benefit: malicious users cannot attack equipment that they cannot address. End users simply cannot affect the TS nodes that their packets travel through within transit space. Despite these benefits, there are some additional issues introduced by APT. Manually configured mappings provide an opportunity for human error, our reliance on ICMP packets provides an opportunity for spoofing and cache poisoning, and storing the entire global mapping table at default mappers poses a threat to long-term scalability. The remainder of this section will address each of these issues in turn. 7.1. Detecting Misconfigurations Due to the fact that only TNs will have access to transit space, false mapping updates are far more likely to be the result of accidental misconfigurations than malicious attacks. With this in mind, we present a simple, extensible authentication scheme that can detect and, in some cases, prevent accidental misconfigurations. The types of misconfigurations that could potentially be harmful are those that result in one provider accidentally interfering with the mapping for another provider's customer. This can happen whenever a provider accidentally announces a mapping for the wrong user-space prefix. These types of accidental conflicts fall into three categories: (1) a provider announces a mapping for a prefix owned by another provider's customer, (2) a provider announces a mapping for a shorter user-space prefix that contains a longer user-space prefix owned by owned by another provider's customer, and (3) a provider announces a mapping for a longer user-space prefix that is a subset of a shorter user-space prefix owned by another provider's customer. The first category of conflicts is the only one that we intend to actively prevent. Clearly, the user that owns a particular user- space prefix should be the ultimate authority for his mapping information. However, user networks do not announce their mappings Jen, et al. Expires January 3, 2008 [Page 13]
Internet-Draft Transit Mapping July 2007 to the network directly, but rather through their providers. In order to ensure a mapping update for a user-space prefix is approved by its rightful owner, we must include some sort of user authorization string in each announcement. To this end, we introduce a public-key field into each mapping. This field SHOULD contain a cryptographically valid public key, but it will only rarely need to be used as such. In the normal case, when a default mapper receives a new mapping announcement that would replace an existing one, it only needs to ensure that the public key has not changed. (This scheme is similar in spirit to the way that OpenSSH uses its 'known_hosts' file.) However, as long as all of a UN's providers store the corresponding private key, the distribution of public keys also introduces the possibility of using cryptographic signatures for any number of purposes within transit space. For the other two categories, it is less clear that such an announcement is the result of a misconfiguration. It is possible, for example, that the owner of a /16 user-space prefix has resold some of the contained /24 prefixes to other UNs. In such cases, only the administrators will know if the announcement is valid. It is for this reason that (in the spirit of PHAS [PHAS]) we do not attempt to prevent such changes, but only detect and notify interested parties. Since legitimate mapping changes are infrequent, notifying interested parties of mapping changes via e-mail is a perfectly viable option. These notifications could also prove useful in debugging the mapping service, or a particular provider's configuration. 7.2. ICMP Mapping Packets ICMP mapping packets are used exclusively by default mappers to send mapping entries to the TRs within their AS. Therefore, there is no reason that these ICMP packets should ever need to travel between ASes. In order to prevent cache poisoning through spoofing, these ICMP packets simply MUST be dropped at all border routers within transit space. 7.3. Other ICMP Packets Our mapping service also depends on two other types of ICMP packets: existing ICMP Destination Unreachable messages, and our new ICMP Border Link Failure messages. Both of these packet types must traverse AS boundaries. Again note that, under the eFIT architecture, these packets are already more trustworthy than ICMP packets in the current infrastructure -- they can only be generated by hosts in transit space. However, if this level of security is deemed insufficient, the keys used for detecting misconfigurations could be used to cryptographically sign such packets, ensuring that they are coming from the appropriate sender. Jen, et al. Expires January 3, 2008 [Page 14]
Internet-Draft Transit Mapping July 2007 7.4. Default Mapper Scalability Theoretically, the global mapping table could grow to contain a separate mapping for every user-space prefix. In the case of IPv6 prefixes, the total number of mappings would be on the order of 10^18, far more than we can expect to be able to store on a single device. If the global mapping table were to approach such gargantuan proportions, a few simple changes to the default-mapper model would allow APT to scale gracefully. Instead of each default mapper storing the full, global mapping table, each default mapper would store only a subset of the table. This subset would be aggregatable by user-space prefix. For addresses outside of this subset, a default mapper would store mappings that mapped short, artificially aggregated prefixes to the TS addresses of other default mappers. Like virtual prefixes in CRIO [CRIO], the user-space prefixes in these mappings would not necessarily correspond to actual user prefixes. Each virtual prefix would be announced by the default mapper responsible for the corresponding subset of the global mapping table. In order to ensure complete coverage of the user address space, some central authority would need to assign these virtual prefixes to individual transit networks. This scheme allows for a tradeoff between latency and default mapper storage requirements. (For more discussion of the characteristics of such a tradeoff, see [CRIO].) However, this scheme also requires some providers to become authoritative sources for mappings owned by other providers' customers. Both this requirement and the need to involve a central authority could prove problematic for deployment. Therefore, we do not recommend using this scheme unless the size of the global mapping table demands it. 8. Incremental Deployment Clearly, the deployment of APT will coincide with the deployment of eFIT (or a similar architecture). Though incremental deployment of the eFIT architecture itself is beyond the scope of this document, we must at least show that APT will behave properly under partial deployment. Under the eFIT architecture, addresses outside of transit space will not change. This means that user-space prefixes will initially share the existing IP address space. This fact provides us with a simple method for delivering packets to addresses for which no mapping is available. Presumably, the only such addresses will be those Jen, et al. Expires January 3, 2008 [Page 15]
Internet-Draft Transit Mapping July 2007 connected to providers who have not yet adopted the new architecture. In order to deliver such packets, APT nodes can simply return them to the old infrastructure, and they will be routed as they are today. In order to support this feature, default mappers will respond to TRs with an ICMP mapping packet that indicates that no entry exists for the given user-space prefix. TRs will keep a negative cache entry for such prefixes so that they can forward such packets directly to a non-TS router. In discussing incremental deployment, we must also address the issue of how new default mappers will acquire the complete mapping table when they are first connected to transit space. Since our mapping service design requires that all ASes re-announce all of their mappings at a regular interval, commissioning a new default mapper only requires connecting it to the network and waiting for all other TS ASes to re-announce their mappings. Yet, this introduces a potential problem -- if there is no upper bound on the regular refresh interval, there will be no upper bound on how long a new default mapper needs to wait until its mapping table is complete. Therefore, there needs to be an upper bound on the refresh interval for mappings. An appropriate value would be once a week. This would mean that a newly deployed default mapper would be able to reach the entire transit space one week later (with the exception of any ASes that failed to follow protocol). 9. Future Work Optimally, any design paper should include an evaluation section. In the future, we will examine traces of Internet activity to determine the characteristics of the tradeoff between TR cache size and default mapper workload, the amount of traffic overhead that would be incurred by our push-based design, and any other results that the community deems useful. We are also considering automating user mapping updates. Under our current design, whenever a user needs to update his mapping information (he may add, subtract, or change providers, or change his priority values), the user must contact his providers offline and request that they announce the updated mapping information. It is then up to the providers to update the mapping information. As we have seen with DNS updates, human involvement introduces the possibility of human error and delay. We hope to provide UNs with an automated way to manage their mapping information. Jen, et al. Expires January 3, 2008 [Page 16]
Internet-Draft Transit Mapping July 2007 10. IANA Considerations This memo includes no request to IANA. 11. Security Considerations Security considerations for APT are discussed in Section Section 7. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [efitID] Massey, D., Wang, L., Zhang, B., and L. Zhang, "A Proposal for Scalable Internet Routing and Addressing", Internet Dr aft, http://www.ietf.org/internet-drafts/ draft-wang-ietf-efit-00.txt, 2 2007. [EFIT] Massey, D., Wang, L., Zhang, B., and L. Zhang, "A Scalable Routing System Design for Future Internet", SIGCOMM IPv6 Workshop , 8 2007. [LISP] Farinacci, D., Fuller, V., and D. Oran, "Locator/ID Separation Protocol (LISP)", Internet Draft, http:// www.ietf.org/internet-drafts/draft-farinacci-lisp-00.txt, 2007. [PHAS] Lad, M., Massey, D., Pei, D., Wu, Y., Zhang, B., and L. Zhang, "PHAS: A Prefix Hijack Alert System", USENIX Security . [AddrAlloc] Meng, X., Xu, Z., Zhang, B., Huston, G., Lu, S., and L. Zhang, "IPv4 Address Allocation and BGP Routing Table Evolution", ACM SIGCOMM Computer Communication Review (CCR) special issue on Internet Vital Statistics, Volume 35, Issue 1, p71-80. [RAWS] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", Internet Draft, http: //www.ietf.org/internet-drafts/ draft-iab-raws-report-02.txt, 2007. Jen, et al. Expires January 3, 2008 [Page 17]
Internet-Draft Transit Mapping July 2007 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "Scaling IP Routing with the Core Router-Integrated Overlay", Proc. International Conference on Network Protocols , 11 2005. Appendix A. BGP Mapping Announcement Fields Address Type - This field specifies the type of user-space addresses used for the user-space prefixes in the announcement. All user-space prefixes in a single mapping announcement MUST be of the same address type. Currently, this is expected to be either IPv4 or IPv6, but any other address type is possible provided that it is supported by the APT nodes in the ASes that wish to use it. APT nodes MUST ignore mapping announcements for address types that they do not understand. Total Length - This field specifies the total number of bytes used by all mappings in the announcement. Each mapping announcement can contain mappings for multiple prefixes, each with multiple mapping entries. Each mapping in the announcement is described by the following fields: User-space Prefix - This is the user prefix for the mapping. Public Key - This is a public key that can be used to verify signatures, decrypt data, and prevent misconfigurations for the corresponding user-space prefix. See Section Section 7.1 for more information. Time To Live (TTL) - This is the amount of time in hours that this mapping should persist in default mappers before being considered obsolete and erased. This value MUST be set to at least three times the regular refresh interval lest the corresponding user-space prefix become unreachable. The TTL is specified in hours to prevent misconfigurations from causing excessive mapping updates. TS Address Count - This is the total number of TS addresses that the corresponding user-space prefix maps to. TS Address Set - This is a set of TS addresses, each with a priority. The total number of addresses is specified by the previous field. Priorities are arbitrary integers that only have meaning in reference to each other. Addresses with lower priority values are considered more preferable. Jen, et al. Expires January 3, 2008 [Page 18]
Internet-Draft Transit Mapping July 2007 Appendix B. ICMP Mapping Message Fields User-space Prefix - This prefix is used to match the input address for mapping cache lookups. TS Address - This is the destination that the user-space prefix maps to. TTL - This is the time that the entry stays in the cache. Its value is determined by the default mapper. Appendix C. ICMP Border Link Failure Fields Prefix - This field contains the user-space prefix that cannot be reached as a result of the border link failure. Signature - This field can optionally contain a signature generated using the UN's private key. It can then be used to verify the legitimacy of the message. Appendix D. Hidden Backup Mappings As mentioned in our mapping section, our design allows users to assign backup providers and perform traffic engineering through appropriate assignment of their TN priority values. Of course, this method will only prove effective if all transit networks generally respect these priority values. This may not be the case in practice. User networks may be negatively affected if priorities are not respected. For example, imagine that a user has a cheap primary provider and an expensive backup provider. If enough transit networks ignore the UN's preference and send his traffic through the backup provider, the financial impact on the user could be significant. For this reason, users may not want to depend on other ASes to respect their priority values. In today's Internet, multihomed user networks can use BGP trickery to hide their backup providers unless they are needed. The backup provider simply does not announce a route to the UN's prefix unless it receives a withdrawal for that prefix from the UN's primary provider. At this point, the backup provider will announce its path to the UN's prefix. Once it receives a new announcement for the prefix from the primary provider, the backup provider withdraws its path to the UN's prefix, putting it back into hiding. In accordance with our "do no harm" design philosophy, we present a Jen, et al. Expires January 3, 2008 [Page 19]
Internet-Draft Transit Mapping July 2007 method for including a hidden backup feature into APT. Hidden backup support introduces new ICMP packets, mapping tables, and state into APT. We leave it as an open question whether this feature should be included at all. If transit networks are willing to respect the priority values included with mapping entries, hidden backup support (and its complexity) can be omitted entirely from APT. Appendix D.1. Hidden Backup Mapping Protocol A user would want to activate his hidden backup provider in the same three failure situations that require switching to an alternate provider (see Section Section 5.1). We will explain how to handle each of these failure types. Situation (1) is detectable by the backup provider via BGP. When the backup provider learns that there are no routes to the UN's primary provider, he MUST announce his own backup mapping and begin servicing the user network. If the UN's primary provider later becomes reachable, the backup provider MUST re-announce the original mapping. The responsibility to re-announce the original mapping lies with the backup provider in order to prevent route flapping from causing mapping flapping. The backup provider SHOULD wait until the primary provider has been stable for a set period of time before re- announcing the original mapping. Also note that these mapping announcements are indistinguishable from those generated by permanent mapping changes, leaving default mappers throughout transit space no choice but to respect them. Situation (2) is detectable by the primary provider via IGP. When the primary provider learns that one of his TRs is down, he MUST inform the backup providers for the affected user networks. This could be done via BGP flooding, but it seems excessive to flood the entire core with a message that is only relevant to a handful of providers. Instead of flooding, the primary provider needs to inform the relevant backup providers directly. To support this, primary providers MUST store a "backup-mapping table" that maps each of their customers to their corresponding backup providers. This table should not be very large, since each provider will only store entries for his own customers. Furthermore, customers who do not have a hidden backup can be excluded from the backup-mapping table. When a TR goes down, one of the provider's default mappers can use its reverse-mapping table (see Section Section 5.1) to determine which user prefixes are affected. It can then use its backup-mapping table to determine which backup providers need to be notified. The rest of the communication will be implemented using two new ICMP message types, "Primary Provider Failure" and "Primary Provider Recovery". Each of these types will require an acknowledgment (ACK) Jen, et al. Expires January 3, 2008 [Page 20]
Internet-Draft Transit Mapping July 2007 flag to ensure delivery. Primary providers MUST send an ICMP "Primary Provider Failure" message to each of the appropriate backup providers. These messages MUST contain the relevant mapping entry. Upon receipt of such a message, a backup provider MUST respond with an identical packet, except that it MUST set the ACK flag. Then, it MUST announce a backup mapping entry. When the customer's primary provider detects a recovery, it MUST send an ICMP "Primary Provider Recovery" message to the appropriate backup providers. The backup providers MUST acknowledge the message, and re-announce the original mapping. As in situation (1), re-announcing of the original mapping is left to the backup providers to prevent mapping flapping. Situation (3) is detectable by the TR whose link to a user has gone down. The TR MUST inform his default mapper of this failure via the new ICMP type described in Section Section 5.1.3. At this point, the primary provider can lookup the affected user in his backup-mapping table, and proceed as in situation (2). The ICMP communication described above is essential to hidden backup functionality. Thus, these messages must be secure and reliable. Security can be achieved with public-private key cryptography (see Section Section 7.3). For reliability, the primary provider MUST continue to send "Primary Provider Failure" and "Primary Provider Recovery" ICMP packets periodically until it receives an acknowledgment from the backup provider. Backup providers MUST always acknowledge these types of ICMP messages, regardless of the state of the corresponding mapping. Mapping announcements and ICMP communication will be carried out by default mappers unless otherwise specified. Backup-mapping tables are also stored in the default mappers. Authors' Addresses Dan Jen Email: jenster@cs.ucla.edu Michael Meisel Email: meisel@cs.ucla.edu Jen, et al. Expires January 3, 2008 [Page 21]
Internet-Draft Transit Mapping July 2007 Dan Massey Email: massey@cs.colostate.edu Lan Wang Email: lanwang@memphis.edu Beichuan Zhang Email: bzhang@cs.arizona.edu Lixia Zhang Email: lixia@cs.ucla.edu Jen, et al. Expires January 3, 2008 [Page 22]
Internet-Draft Transit Mapping July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jen, et al. Expires January 3, 2008 [Page 23]