Multicast in Identifier/Locator Separation Architectures

Transcription

1 Multicast in Identifier/Locator Separation Architectures Michal Kryczka Universidad Carlos III de Madrid Abstract Many assumptions which were made during projecting current Internet are not valid any longer what forces us to rethink and redesign some elements of present network architecture. This paper presents identifier/locator split technologies which try to overcome problems of using IP address as a main identifier of the host. Paper covers also multicast aspects in that technologies. I. INTRODUCTION Since first packets through ARPANET were sent, the Internet has extremely evolved and changed its face. In present world mobility has become a central aspect of our lives. Nowadays, IP addresses are used to identify host. However, IP address primarily describes a topological location of a host in network, so it needs to be changed when a host changes its location in the network. As a result, using IP addresses as identifiers is quite problematic. As in real world, where we define the person by name rather than his address of living, it would be very beneficial to identify place in the network by using some different name space. This is the main idea of new proposals which introduces separation between identificator and locator. These new proposals also imply multicast techniques to be changed what can be a great opportunity to improve present multicast and overcome problems it suffers now. Next four Chapters will present different architectures and protocol proposals (TRIAD, IPNL, LISP, HIP respectively) together with multicast solutions before concluding in Chapter V. II. TRIAD TRIAD, proposed in [1], is the new network architecture which focuses on content distribution an is oriented on data. In this proposal all end to end identification is based on names rather then addresses. It is according to way how we use Internet nowadays, which is primary content distribution (web pages, audio or video streams). Because users are mainly interest in content not particular machine or IP address, TRIAD introduces a special content layer which serves clients requests and locates nearest place to get content. Client asks for a content identified by URL (optionally with cookies) and TRIAD returns a network pointer to a content, which is realised by HTTP/TCP connection through which content is read or written. For example, client can send a request for the news page of some portal (e.g. cnn.com) to its own content router, which then, based on URL, tries to Fig. 1. WRAP packet find replica for this content and forward request to a next hop. In the same time, CNN content server advertises the content cnn.com to nearby content router. Finally, user can directly have access to the content on the server which is located nearby. Key parts of the TRIAD are then content routers (forwards requests based on name routing table, augments present IP router, proxies and NAT) and content servers (answers content requests, advertises content through content router, augments present web servers, cache and proxy). Two significant parts of TRIAD architecture are Internet Name Resolution Protocol (INRP) and Name-Based Routing Protocol (NBRP). First one routes a content request (based on its name) towards the closest server for that name. Name routing tables are used and they keep next-hop for a corresponding name. The second one, NBRP, augments but not replace IP routing. In general it advertises naming information into the network using a dynamic routing protocol. NBRP is similar to BGP but operates on name suffixes rather then on address prefixes. Additionally, TRIAD introduce WRAP - a shim protocol for content routing control, which allows path-based addressing. It is used in inter-realm packet delivery. WRAP Relay Agents (RAs) exist and they have two interfaces, each in a different address realm. WRAP packets (Fig. 1) contains two Internet Relay Tokens (ITR) which are mapped from domain names and respectively indicates path the packet has taken (reserve token) and path the packet is going to take (forward token). The simplest version simply contains a sequence of IPv4 intra-realm addresses. Each this address identifies RA which forward packets from one address realm to another. Multicast in TRIAD with WRAP supports a model called EXPlicity REquested Single Source (EXPRESS) which is described in [2]. This solution introduces multicast channels. It is simply a datagram delivery service identified by (S,E) where S is an address of a sender and E is a channel destination address. Subscriber host requests reception of

2 2 Fig. 2. Difference between channel and group addressing data sent to a channel by specifying both S and E in the request. Source S sends data to the channel, by transmitting a datagram addressed to E. Thus, packets are addressed to the channel rather then to a host or host group (Fig. 2). With this in mind, channels (S,E) and (S,E) are unrelated despite common destination address. EXPRESS Count Management Protocol (ECMP) is also proposed and it maintains distribution tree, supports counting and voitng. It also sets up entries in FIB at the routers that are used to look up the (S,E) pairs for multicast distribution. With WRAP a subscriber joins a multicast channel by specifying name, and by making lookup, it gets required multicast channel addressing information. To perform multicast WRAP the same as unicast one, WRAP header contains multicast address of group repeated r times, where r is the maximum number of relay hops. TRIAD provides a very efficient architecture for content routing. It introduces new content layer and integrates routing and naming what provides better availability of data. It can be used with any kind of addressing (IPv4, IPv6, WRAP), however WRAP is recommended by authors as it solves the problem of address exhaustion while some of the IPv4 equipment does not need to be change. Using an EXPRESS model of multicast gives some benefits like receiving traffic only from the source which was designated by subscriber, simplifying address management or mechanism which allows for counting the number of subscribers. However, in this solution only a single-source multicast is allowed. III. IPNL In [3] the solution called IP Next Layer (IPNL) is proposed. This architecture bases on IP infrastructure and adds an extra layer between IP and TCP/UDP layers. The topology of IPNL consists huge middle realm (continuation of present Internet) connected with private realms or directly attached hosts. Moreover, private realms can be aggregated in realm groups and reach middle realm through a single middle realm IP address (MRIP). With this approach, we can see that IPNL topology is quite similar to today s Internet with private realm separated from public Internet using NAT. The example of IPNL topology is presented on Fig. 3. On this illustration, we can see three private realms which creates one group with single MRIP, three separated private realms and directly connected hosts. Fig. 4. Fig. 3. IPNL topology IPNL address structure IPNL address has a length of 80 bits and contains three fields: Middle Realm IP Address (MRIP, 32 bits), globally unique Realm Number (RN, 16 bits), aggregates private realms End Host IP Address (EHIP, 32 bits), locally unique IP realms are connected by IPNL routers, each of which can belong to one of three categories (Fig. 4): frontdoor router, which uses MRIP to connect a realm group with global Internet backdoor router, which connects two realm groups, which can have overlapping realm numbers interior router, which connects private realms within realm group Routing in IPNL is quite straightforward and bases on encapsulating and decapsulating IP packets with each realm crossing. Inside realms, all the work is made by IP routing. Within realm group, there is a BGP-like path vector routing

3 3 Fig. 5. Example of routing in IPNL protocol, which advertises and propagates realm numbers. It is used by interior routers and frontdoor routers (advertise middle realm). When interior router will find a packet, which destination is a private realm group attached to that router, router rewrites EHIP address into encapsulating IP header and forward it to the destination. On the other hand, if such a router finds a packet, with realm number which is not private, packet is by default forwarded to frontdoor router. When frontdoor router gets such a packet it rewrites MIRP address and put it into encapsulating IP header and forward to middle realm. If frontdoor router gets a packet from middle realm it forwards it to the appropriate interior router. Additionally communication between two realm groups with usage of backdoor routing can happen. In this case it may happen that realm numbers in each of realm group can overlap. Thus, it is necessary for backdoor router to keep correct translation, and overwrite realm number groups in packets it forwards. Next innovation proposed in IPNL, is using Fully Qualified Domain Name (FQDN) as a fully routable address, what allows for end-to-end consistency and addressing symmetry. However, because FQDN has no fix length and using it in every packet will be very costly, FQDN is only sent in some packets (typically in the first), together with IPNL address what allows router to automatically learn and keep appropriate translation. Fig. 5 shows an example of usage FQDN. When two locally addressed hosts want to setup connection, routing with FQDN is straightforward as interior routers keep a table with zonerealm number entries. Thus, if host a.phy.xyz.edu wants to establish connection with b.math.xyz.edu, interior router C, will know the next hop. Now, lets imagine situation, when this host wants to communicate with c.b.com, which is globally addressed. In this situation packet is sent to frontdoor router, which uses DNS for resolving MRIP address of destination. Then packet is encapsulated into IP packet with MRIP as destination address. Once packet will reach frontdoor router of destination, it determines proper realm number and forwards packet to this realm and then to destination. The idea of multicast in IPNL is quite similar to unicast transmissions and is described in [4]. Both, FQDN and IPNL address, are used. FQDN which define multicast group is syntactically the same as unicast FQDN. The difference is that hosts learn about FQDN of the group while joining a group, unlike in unicast when sending data packet. Multicast packets are distinguished because of destination host IP address in IPNL header, which is IP class D address. The rest of the header is syntactically the same. Source address is the unicast address of the sender. Home realm of IPNL multicast FQDN assignes IP multicast address to the multicast group. This address needs to be unique in the realm, but can overlap with other multicast addresses assigned by other realms. IPNL multicast address contains then IP multicast address, number of home realm and MRIP of the home realm, if it contains not local users (it can be distinguished by router). When joining multicast group, host transmits a join message together with FQDN of the group to its IPNL router. Because of join message, router knows that FQDN is multicast rather then unicast. If router does not know the address of multicast group yet, it forwards the message to home realm of the multicast FQDN. Then router in home realm assignes IP multicast address for a group (if has not done earlier). This address is return to the source host, which now can start transmitting and receiving packets within the group. IPNL looks as a good alternative to IPv6 and solves problem of increasing demands for IPv4 addresses. IPNL can coexist with present infrastructure (DNS, routing protocols, IPv4 hosts) but also has some drawbacks including need of significant change in TCP/IP protocol and quite complicated architecture. Multicast in IPNL is based on present multicast and it is simply extending IP multicast rather then projecting new architecture. Usage of FQDNs and extended address simplifies multicast address assignment, however, authors claim that it can be profitable to design new multicast architecture to overcome problems which exist with present multicast. IV. LISP One of the proposal of locator/identifier separation proposed in [5] and discussed in [6] is a Locator/ID Separation Protocol (LISP). It is an IP-over-IP tunnelling protocol, which gives to a network layer support to routing locators and allows for endhost identifiers separation. The biggest advantage of LISP that it does not modify current protocol stack but adopts IP and it can be incrementally implemented without sudden negative impact on current architecture. In LISP (Fig. 6) we can distinguish two key elements: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). EIDs are IP addresses which on the beginning can still be routable globally but finally are supposed to be routable only in the area of local AS. RLOCs are IP addresses of Tunnel Routers. These addresses will remain routable globally. Ingress Tunel Router (ITR) adds a LISP header to each packet and Egress Tunel Router (ETR) remove this new header before

4 4 Fig. 6. LISP topology delivering packet to final destination. Every EID is associated with at least one RLOC. While communication between two hosts occurs, first host sends a packet with its EID as a source address, and EID of the receiver as a destination address. Packet is routed in local AS to one of the locator RLOC (choice depends on traffic engineering policy). RLOC performs a lookup to find the address of the locator of the destination and then IP packet is sent with LISP header (address of corresponding locators are used as a source and destination address). Packet is routed through the Internet and once it reaches appropriate locator, LISP header is stripped and packet is normally routed in local AS. Main issue of that is to design EID-to-RLOC mapping function. Different solutions were proposed including new ICMP messages, DNS service or rely on BGP. Multicast in LISP is described in [7]. The whole idea is based on encapsulating a multicast packet into another multicast packet. The multicast packet received from a source is encapsulated into LISP multicast header. Destination group address from inner header is copied to outer header. Inner source address is EID of multicast source host and outer address is RLOC of router which encapsultes packet. Joining a multicast group is made in the same way as today (using IGMP). Multicast ETR at receiver site gets a PIM Join/Prune message which contains two things: source EID address and group receiver want to join (S-EID,G). ETR makes a mapping for source EID and gets corresponding source RLOC. Next two PIM Join/Prune messageges are sent. One is unicast message (S-EID,G) to ITR S-RLOC address and the other is (S-RLOC,G) through core, so core network could create multicast state from ETR to ITR. When multicast ITR at source site receives unicast PIM Join/Prune message (S- EID,G), it forwads it to source site. ITR also acts as root of (S-RLOC,G) tree for site. Whenever multicast message is sent now, ITR encapsulates (S-EID,G) packet into (S-RLOC,G) and ETR at receiver site decapsulates it from (S-RLOC,G) to (S- EID,G). Thanks to Locator/Identifier separation we can improve Traffic Engineering capabilities and reduce size of FIBs what has influence on resource usage by router or speed of forwarding table updates. Authors claim also that ASes can obtain more paths in shorter time than using BGP-based Fig. 7. HIP architecture multihoming. Also presented architecture of multicast, where multicast state in the core operates on locators and multicast state at the sites operates on EIDs, is consistent and scalable with LISP architecture. It makes no changes to hosts and can be deployed incrementally. V. HIP Opposite to LISP, the other proposal, Host Identity Protocol (HIP) [8] [9] introduces a completely new name space - Host Identity (HI), which is simply a public cryptographic key of a public-private key-pair. Host, which has a private key of the key-pair can prove that it owns the public key which is used to identify in the network. Each host can generate short-term or long-term keys, depending of what is the need. As HI is quite long, instead of this, Host Identity Tag (HIT) is used in transmission, which has a length of 128 bits and is generated by hashing HI. Because of the length it can be directly used with IPv6 applications. HIP introduces a new layer which insulates upper layer from IP addresses. Upper layers, including applications, instead of seeing IP addresses, they see HIT. Each HI is mapped locally to the IP address of the node. When packets leave the host, correct route is chosen and corresponding IP addresses are put into the packet as a source and destination address. Such an architecture is presented on Fig. 7 HIP session bases on four-way handshake (Fig. 8). During this exchange, a Diffle-Hellman authenticated key exchange is used to create a session key and establish a pair of IPSec ESP Security Associations (SA). The ESP SAs between the hosts are bound to the Host Identities. Arriving packet is identified and mapped to the correct SA using Security Parameter Index (SPI) value from the IPSec header. Thanks to this, changing the location information in the packet will not make any problems as packet will still be correctly identified by SPI. There is also a proposal of extending HIP protocol for supporting multicast, and it was presented in [10]. In proposed model, authors introduce Multicast Agents (MAs), what improves control and managing and also strengthens a security

5 5 Fig. 8. HIP session Any multicast traffic with corresponding GIT and GK will now go to the host. When host decides to leave the group he sends an extended packet with HIP parameter leave request to its MA. Similarly creating a group is made with usage of HIP option create group. HIP looks as a very promising architecture. It implements identifier/locator split and provides better security, mobility, multihoming and IPv4/IPv6 interoperability. Also extension of HIP, which provides secure multicast looks very promising. The main part of the system is MA, which is responsible for tree and key management, authentication of group members and collecting accounting information. All that makes the multicast more secure and easy to manage. VI. CONCLUSIONS In this paper different solutions about splitting identifier and locator were introduced. Corresponding proposals about multicast were also presented and discussed. Introducing new protocol for current architecture can be also a good opportunity for improving present multicast. The last described protocol, HIP, is investigated now quite widely (an IETF formed HIP working group in 2003) and has a status of experimental RFC. It can be assumed that this protocol has a chance of being adopted in nearest future. While HIP implies modification in present architecture it can be also beneficial to introduce new multicast architecture which will base on HIP. Solution described in the paper sounds very promising as it provides secure, reliable and easy to manage multicast. REFERENCES Fig. 9. HIP-multicast model in comparison to present multicast architecture. Example of HIP-multicast model is presented in (Fig. 9) New model works different from traditional IP-multicast. Instead of using IGMP for group managing, it uses HIP. There is also no more need for IP multicast addresses as they are replaced by a Group Identity (GI). Similarly to HI, it is represented by a group of public key. Also similarly to HIT, Group Identity Tag (GIT) is used, which is created by hashing GI and has a length of 128 bits. During four way handshaking, packets which are sent are extended and they also carry GIT. When a host (both it can be a group receiver or MA) wants to join a multicast group, it sends a request to related MA asking for joining multicast group (specified by GIT). After successful authentication, MA adds the authenticated host to the related multicast tree, updates forwarding table and sends packet to the initiator confirmating the GIT and sending Group Key (GK). Then host finishes authentication and joins multicast group. [1] D. R. Cheriton and M. Gitter, TRIAD: A next generation internet architecture, Stanford Univeristy, Computer Sciece Department, January [2] H. W. Holbrook and D. R. Cheriton, IP multicast channels: EXPRESS support for large-scale single-source applications, Stanford Univeristy, Computer Sciece Department, [3] P. Francais and R. Gummadi, IPNL: A simpler and cheaper fix for IP, SIGCOMM, [4], IPNL protocol specification, IPNL specification, [5] D. Farinacci, V. Fueller, D. Oran, D. Meyer, and S. Brim, Locator/ID separation protocol (LISP), work in progress, December [6] B. Quoitin, L. Iannone, C. Launois, and O. Bonaventure, Evaluating the benefits of the locator/identifier separation, MobiArch 07, Kyoto, Japan, August [7] D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas, LISP for multicast environments, work in progress, November [8] R. Moskovitz, P. Nikander, P. Jokela, and T. Henderson, Host identity protocol, RFC5201, April [9] P. Jokela, P. Nikander, J. Melen, J. Ylitalo, and J. Wall, Host identity protocol - extended abstract, Ericsson Research, NomadicLab, [10] X. Zhou and J. W. Atwood, A secure multicast model for peer-topeer and access networks using the host identity protocol, Consumer Communications and Networking Conference, January 2007.