From jari.arkko@piuha.net Mon Oct 3 14:59:12 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40BA21F8EF4 for ; Mon, 3 Oct 2011 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRPppOCpkDk0 for ; Mon, 3 Oct 2011 14:59:12 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE021F8EF3 for ; Mon, 3 Oct 2011 14:59:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 70AB02CEFF; Tue, 4 Oct 2011 01:02:06 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVFJGbIgPrBl; Tue, 4 Oct 2011 01:02:03 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DB8142CE32; Tue, 4 Oct 2011 01:02:02 +0300 (EEST) Message-ID: <4E8A30DA.5080706@piuha.net> Date: Tue, 04 Oct 2011 01:02:02 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org, Joel Halpern References: <4E86486A.6010402@piuha.net> In-Reply-To: <4E86486A.6010402@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 21:59:12 -0000 Continuing with my review. Many of the observations below are questions. I may understand most of these better once I finish the whole document, but I wanted to send out my notes already now. Technical: > o End-systems (hosts) only send to addresses which are EIDs. They > don't know addresses are EIDs versus RLOCs but assume packets get > to LISP routers, which in turn, deliver packets to the destination > the end-system has specified. > Is this always true, e.g, when some interworking mechanism between the LISP and non-LISP parts of the Internet is in use, and one of the peers employs some NAT traversal techniques? It would seem that there can be cases where the peers observe RLOC addresses and use them for some purpose. This might be something to mention in the limitations/things to test section, for instance, or discussed in in the interworking document (and maybe it already is, I did not check). > > A server host can be the endpoint > of a LISP tunnel as well. ... > o RLOCs are always IP addresses assigned to routers > Isn't this an inconsistency? Or is a server that terminates a tunnel called a router? > o When a router originates packets it may use as a source address > either an EID or RLOC. You should state somewhere what the manageability requirements are for making this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use of addresses). Does this require additional functionality for RFC 3484 style source address selection, or can you cope with existing functionality? Note: I'm not asking for any new functionality, just a statement about the expectations. > In order to avoid excessive packet overhead as well as possible > encapsulation loops, this document mandates that a maximum of two > LISP headers can be prepended to a packet. This seems hard to mandate in any real sense. Perhaps you want to say "recommends" instead of "mandates"? > 2. The LISP ITR must be able to map the EID destination to an RLOC > of one of the ETRs at the destination site. The specific method > used to do this is not described in this example. See [ALT ] or > [CONS ] for possible solutions. > > 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be > rate-limited. > > 4. When an alternate mapping system is not in use, the Map-Request > packet is routed through the underlying routing system. > Otherwise, the Map-Request packet is routed on an alternate > logical topology. In either case, when the Map-Request arrives > at one of the ETRs at the destination site, it will process the > packet as a control message. First, the the "alternate mapping system" appears here for the first time. Maybe you should indicate it refers to [ALT]. Second, parts of step 4 go pretty deep in what the specific mapping methods are. I'm wondering if this alternative text would fit better: "4. The Map-Request packet is delivered to the right ETR with the help of the mapping system. (For instance, in [ALT] this happens via an EID-based alternate routing topology.) In any case, when the Map-Request arrives ..." > 6. The ITR receives the Map-Reply message, parses the message (to > check for format validity) and stores the mapping information > from the packet. This information is stored in the ITR's EID-to- > RLOC mapping cache. Note that the map cache is an on-demand > cache. An ITR will manage its map cache in such a way that > optimizes for its resource constraints. > This is just a comment, but FWIW, I am not super happy about the way the caching is an integral part of the specifications for LISP. Fundamentally, you could have used two orthogonal tools for dealing with routing scalability: 1. have only a subset of routers have to deal with EID routing (the xTRs) and 2. use caching for scaling these routers better. If we had done this, then we would have had a very easy answer to those who have criticized the caching approach over the years: it is optional and up to the implementors to use or not. The first tool would still have been a valid approach to make the Internet scale better, even if you never did any caching. In any case, your description of the thins-to-test should probably say something about effects of caching. > 8. The ETR receives these packets directly (since the destination > address is one of its assigned IP addresses), strips the LISP > header and forwards the packets to the attached destination host. > > Spoofing of inner header addresses of LISP encapsulated packets is > possible like with any tunneling mechanism. ITRs MUST verify the > source address of a packet to be an EID that belongs to the site's > EID-prefix range prior to encapsulation. An ETR must only > decapsulate and forward datagrams with an inner header destination > that matches one of its EID-prefix ranges. If, upon receipt and > decapsulation, the destination EID of a datagram does not match one > of the ETR's configured EID-prefixes, the ETR MUST drop the > datragram. If a LISP encapsulated packet arrives at an ETR, it MAY > compare the inner header source EID address and the outer header > source RLOC address with the mapping that exists in the mapping > database. Then when spoofing attacks occur, the outer header source > RLOC address can be used to trace back the attack to the source site, > using existing operational tools. First, I think Step 8 should be slightly edited to cover the fact that some additional checks are being made. E.g., "The ETR receives these packets directly (since ...), checks the validity of the addresses used in the packet, strips the LISP header and ..." Second, I wish you would have specified the source address checks better. Are there situations where you would NOT want to make a pretty strict test, i.e., that source EID maps to source RLOC? > The next sub-sections illustrate packet formats for the > homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 > combinations SHOULD be supported. For interoperability, wouldn't it be cleaner to have a MUST here? How would I otherwise know if I can send an IPv4-in-IPv6 packet to a destination? Editorial: > Since additional tunnel headers are prepended, the packet becomes > larger and can exceed the MTU of any link traversed from the ITR to > the ETR. It is recommended in IPv4 that packets do not get > fragmented as they are encapsulated by the ITR. Instead, the packet > is dropped and an ICMP Too Big message is returned to the source. > This feels odd, as there is no explanation in this point about what you do with IPv6. Maybe a sentence on IPv6 should be added? I'm sure the details on IPv6 follow later in the document, but I suspect that other readers would be wondering here in the same way as I am. I'm reading on... Jari From dino@cisco.com Mon Oct 3 15:43:35 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3321F8EE7 for ; Mon, 3 Oct 2011 15:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tcgdxDvRYDs for ; Mon, 3 Oct 2011 15:43:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A6DBF21F8EF6 for ; Mon, 3 Oct 2011 15:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=10361; q=dns/txt; s=iport; t=1317681998; x=1318891598; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+rtwUb0vHshR6bReCTGlDMMQV7d3FbKqN2ngsbBgOd0=; b=BU1c9ez8EKfJdGmO+wJ9OCKQij8epg97yBMKRTpKZSZdS3aEaZaAckFp x8XuciLj+PcI/AKyi9GQkQdFas5LXqV3w5dZtDvvCCKhk01RYfRPZBPHY ImSbZ5SM74+1IMP6bwKvQE7OJWRKlR+1k/012N7X8ZppOVRHY6ho/kREa k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPk5ik6rRDoH/2dsb2JhbABCqAGBBYFTAQEBAwEBAQEPAVsLBQsLRicwBhMbB4dZBpppAZ16hkBhBId3i2mFJYw5 X-IronPort-AV: E=Sophos;i="4.68,481,1312156800"; d="scan'208";a="5714451" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 03 Oct 2011 22:46:38 +0000 Received: from [10.21.75.254] ([10.21.75.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p93Mkbw4002933; Mon, 3 Oct 2011 22:46:37 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Dino Farinacci In-Reply-To: <4E8A30DA.5080706@piuha.net> Date: Mon, 3 Oct 2011 15:46:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 22:43:35 -0000 > Continuing with my review. Many of the observations below are = questions. I may understand most of these better once I finish the whole = document, but I wanted to send out my notes already now. Thanks for getting something out sooner rather than latter. See my = comments inline.=20 > Technical: >=20 >> o End-systems (hosts) only send to addresses which are EIDs. = They >> don't know addresses are EIDs versus RLOCs but assume packets = get >> to LISP routers, which in turn, deliver packets to the = destination >> the end-system has specified. >>=20 >=20 > Is this always true, e.g, when some interworking mechanism between the = LISP and non-LISP parts of the Internet is in use, and one of the peers = employs some NAT traversal techniques? It would seem that there can be = cases where the peers observe RLOC addresses and use them for some = purpose. But they don't know they are RLOC addresses. All end-systems assume is = that addresses they put int destination address fields will make it to = the destination. So if the address is an RLOC, the underlying routing = system will have routes to get the packet to the destination. Otherwise, = the packet moves toward a LISP router that will encapsulate to get the = packet to the destination. > This might be something to mention in the limitations/things to test = section, for instance, or discussed in in the interworking document (and = maybe it already is, I did not check). We mentionn nothing because the host doesn't care and doesn't need to = care. >> A server host can be the endpoint >> of a LISP tunnel as well. > ... >> o RLOCs are always IP addresses assigned to routers >>=20 >=20 > Isn't this an inconsistency? Or is a server that terminates a tunnel = called a router? For the sake of this document and keeping it within the charter of the = working group, a router is a LISP router. We do not consider hosts doing = LISP as specified in the LISP-MN document. Which is out of charter for = this working group. So if a server is acting as a router, then it has RLOCs.=20 Hosts have EIDs assigned to them (when they are resident in a LISP = site), IGP routers have EIDs assigned to them, and LISP routers have = both EIDs and RLOCs assigned to them. >> o When a router originates packets it may use as a source address >> either an EID or RLOC. >=20 > You should state somewhere what the manageability requirements are for = making this happen, or if hardcoded policies are sufficient (e.g., iBGP = vs. eBGP use of addresses). Does this require additional functionality = for RFC 3484 style source address selection, or can you cope with = existing functionality? It does not. The same requirements for originating IP packets has not = changed. If it is stated that the outgoing interface's address is used = as the source address, then whatever namespace the address belongs to is = used. > Note: I'm not asking for any new functionality, just a statement about = the expectations. No expectations. ;-) >> In order to avoid excessive packet overhead as well as possible >> encapsulation loops, this document mandates that a maximum of two >> LISP headers can be prepended to a packet. >=20 > This seems hard to mandate in any real sense. Perhaps you want to say = "recommends" instead of "mandates"? We thought long and hard about this and wanted to mandate to indicate = the seriousness of not going overboard with encapsulation. Now I know = implementors can ignore specs, but for the record when it is documented = the way we did it is more clear on the strength of the statement. >> 2. The LISP ITR must be able to map the EID destination to an = RLOC >> of one of the ETRs at the destination site. The specific = method >> used to do this is not described in this example. See [ALT = ] or >> [CONS = ] for possible = solutions. >>=20 >> 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be >> rate-limited. >>=20 >> 4. When an alternate mapping system is not in use, the = Map-Request >> packet is routed through the underlying routing system. >> Otherwise, the Map-Request packet is routed on an alternate >> logical topology. In either case, when the Map-Request = arrives >> at one of the ETRs at the destination site, it will process = the >> packet as a control message. >=20 > First, the the "alternate mapping system" appears here for the first = time. Maybe you should indicate it refers to [ALT]. But we have a long list of mapping systems, do you want all of them to = be listed? > Second, parts of step 4 go pretty deep in what the specific mapping = methods are. I'm wondering if this alternative text would fit better: >=20 > "4. The Map-Request packet is delivered to the right ETR with the = help of the mapping system. (For instance, in [ALT] this happens via an = EID-based alternate routing topology.) In any case, when the Map-Request = arrives =85" Well it does not capture the fact that the Map-Request can be delivered = via the underlying routing system. I will add a refernece to ALT though = from your first comment. >> 6. The ITR receives the Map-Reply message, parses the message (to >> check for format validity) and stores the mapping information >> from the packet. This information is stored in the ITR's EID-to- >> RLOC mapping cache. Note that the map cache is an on-demand >> cache. An ITR will manage its map cache in such a way that >> optimizes for its resource constraints. >>=20 >=20 > This is just a comment, but FWIW, I am not super happy about the way = the caching is an integral part of the specifications for LISP. = Fundamentally, you could have used two orthogonal tools for dealing with = routing scalability: 1. have only a subset of routers have to deal with = EID routing (the xTRs) and 2. Which is the way LISP is designed. > use caching for scaling these routers better. If we had done this, = then we would have had a very easy Which is also the way LISP is designed. So I am not following you. > answer to those who have criticized the caching approach over the = years: it is optional and up to the implementors to use or not. The = first tool would still have been a valid approach to make the Internet = scale better, even if you never did any caching. The map-cache is only in the ITRs and PITRs as you described in point 1. = And with added stretch the ITRs and PITRs could have a default cache = entry that encapsulates to a set of ETRs which can hold more cache = entries, and so on. If one chose to deploy LISP in a hierarchical way. > In any case, your description of the thins-to-test should probably say = something about effects of caching. We have added a lot of text to cover many concerns. After reading the = entire document, let us know what you think. ;-) >> 8. The ETR receives these packets directly (since the destination >> address is one of its assigned IP addresses), strips the LISP >> header and forwards the packets to the attached destination = host. >>=20 >> Spoofing of inner header addresses of LISP encapsulated packets is >> possible like with any tunneling mechanism. ITRs MUST verify the >> source address of a packet to be an EID that belongs to the site's >> EID-prefix range prior to encapsulation. An ETR must only >> decapsulate and forward datagrams with an inner header destination >> that matches one of its EID-prefix ranges. If, upon receipt and >> decapsulation, the destination EID of a datagram does not match one >> of the ETR's configured EID-prefixes, the ETR MUST drop the >> datragram. If a LISP encapsulated packet arrives at an ETR, it MAY >> compare the inner header source EID address and the outer header >> source RLOC address with the mapping that exists in the mapping >> database. Then when spoofing attacks occur, the outer header = source >> RLOC address can be used to trace back the attack to the source = site, >> using existing operational tools. >=20 > First, I think Step 8 should be slightly edited to cover the fact that = some additional checks are being made. E.g., "The ETR receives these = packets directly (since ...), checks the validity of the addresses used = in the packet, strips the LISP header and =85" I will add "checks the validity of the addresses" and of course keep the = text that follows Step 8. > Second, I wish you would have specified the source address checks = better. Are there situations where you would NOT want to make a pretty = strict test, i.e., that source EID maps to source RLOC? Because this is work still in progress. >> The next sub-sections illustrate packet formats for the >> homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 >> combinations SHOULD be supported. >=20 > For interoperability, wouldn't it be cleaner to have a MUST here? How = would I otherwise know if I can send an IPv4-in-IPv6 packet to a = destination? I can change to MUST. > Editorial: >=20 >> Since additional tunnel headers are prepended, the packet becomes >> larger and can exceed the MTU of any link traversed from the ITR to >> the ETR. It is recommended in IPv4 that packets do not get >> fragmented as they are encapsulated by the ITR. Instead, the packet >> is dropped and an ICMP Too Big message is returned to the source. >>=20 >=20 > This feels odd, as there is no explanation in this point about what = you do with IPv6. Maybe a sentence on IPv6 should be added? It is explained in the MTU section. I think you may have not gotten = there yet? > I'm sure the details on IPv6 follow later in the document, but I = suspect that other readers would be wondering here in the same way as I = am. Yes, they do. > I'm reading on=85 Thanks. Dino >=20 > Jari >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Wed Oct 5 19:48:04 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AD821F8CC5; Wed, 5 Oct 2011 19:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEJtMknq8eIb; Wed, 5 Oct 2011 19:48:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7084621F8C86; Wed, 5 Oct 2011 19:48:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111006024804.2973.49882.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2011 19:48:04 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 02:48:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP for Multicast Environments Author(s) : Dino Farinacci Dave Meyer John Zwiebel Stig Venaas Filename : draft-ietf-lisp-multicast-09.txt Pages : 38 Date : 2011-10-05 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-multicast-09.txt From jari.arkko@piuha.net Tue Oct 11 12:04:31 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D9421F8FD9 for ; Tue, 11 Oct 2011 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ujWBm1eJuwc for ; Tue, 11 Oct 2011 12:04:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE5A21F8FE5 for ; Tue, 11 Oct 2011 12:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A4FAF2D565; Tue, 11 Oct 2011 22:04:26 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty1-KOgqsY2v; Tue, 11 Oct 2011 22:04:25 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 967A52CE32; Tue, 11 Oct 2011 22:04:25 +0300 (EEST) Message-ID: <4E949339.4050109@piuha.net> Date: Tue, 11 Oct 2011 22:04:25 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org, Joel Halpern References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> In-Reply-To: <4E8A30DA.5080706@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp (part 3) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:04:31 -0000 Continuing my review: Technical: > LISP Nonce: The LISP nonce field is a 24-bit value that is randomly > generated by an ITR when the N-bit is set to 1. The nonce is also > used when the E-bit is set to request the nonce value to be echoed > by the other side when packets are returned. When the E-bit is > clear but the N-bit is set, a remote ITR is either echoing a > previously requested echo-nonce or providing a random nonce. See > Section 6.3.1 for more details. > I read 6.3.1 and this text but it was still unclear to me if the nonces are generated fresh on a per-packet basis, or if one nonce value is sent on a stream of packets until you see it echoed back. Can you clarify? > When doing ITR/PITR encapsulation: > > o The outer header Time to Live field (or Hop Limit field, in case > of IPv6) SHOULD be copied from the inner header Time to Live > field. > Just checking: this happens *after* you have decremented the TTL/HL as you were making a forwarding decision for the packet. So when the packet passes through an ITR, the outer IP header has a TTL that is decremented by one compared to the original packet, when looking at the packets on the wire. Right? > Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate > after decapsulating, the net effect of this is that the new outer > header will carry the same Time to Live as the old outer header. > This seems wrong. Shouldn't the TTL be decremented even in this situation? But I'm sure you thought about this. What am I missing? > The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service > field and the IPv6 Traffic Class field [RFC3168 ]. The ECN field > requires special treatment in order to avoid discarding indications > of congestion [RFC3168 ]. ITR encapsulation MUST copy the 2-bit ECN > field from the inner header to the outer header. Re-encapsulation > MUST copy the 2-bit ECN field from the stripped outer header to the > new outer header. If the ECN field contains a congestion indication > codepoint (the value is '11', the Congestion Experienced (CE) > codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from > the stripped outer header to the surviving inner header that is used > to forward the packet beyond the ETR. These requirements preserve > Congestion Experienced (CE) indications when a packet that uses ECN > traverses a LISP tunnel and becomes marked with a CE indication due > to congestion between the tunnel endpoints. This works for routers that do not participate in ECN process themselves. I suppose it is theoretically possible that an xTR would also be doing ECN. Perhaps you could add to the end of this paragraph: "In addition, at the end of the process specified above, an ECN-capable xTR may perform its own modification of the ECN bits per [RFC3168], when it detects congestion. > An ITR that is configured with mapping database information (i.e. it > is also an ETR) may optionally include those mappings in a Map- > Request. When an ETR configured to accept and verify such > "piggybacked" mapping data receives such a Map-Request and it does > not have this mapping in the map-cache, it may originate a "verifying > Map-Request", addressed to the map-requesting ITR. If the ETR has a > map-cache entry that matches the "piggybacked" EID and the RLOC is in > the locator-set for the entry, then it may send the "verifying Map- > Request" directly to the originating Map-Request source. If the RLOC > is not in the locator-set, then the ETR MUST send the "verifying Map- > Request" to the "piggybacked" EID. Doing this forces the "verifying > Map-Request" to go through the mapping database system to reach the > authoritative source of information about that EID, guarding against > RLOC-spoofing in in the "piggybacked" mapping data. I want to understand this better and I guess reading to the end of the document will answer some of my questions. But as a general rule, I think we should not trust other nodes in the network to claim alternative addresses for themselves, unless we can somehow verify (via return routability or via mapping data base) that they appear to really be at that address. So I am wondering if the "may originate" should become "originates". But I'm reading on. > Weight: when priorities are the same for multiple RLOCs, the weight > indicates how to balance unicast traffic between them. Weight is > encoded as a relative weight of total unicast packets that match > the mapping entry. For example if there are 4 locators in a > locator set, where the weights assigned are 30, 20, 20, and 10, > the first locator will get 37.5% of the traffic, the 2nd and 3rd > locators will get 25% of traffic and the 4th locator will get > 12.5% of the traffic. If all weights for a locator-set are equal, > receiver of the Map-Reply will decide how to load-split traffic. I am surprised by the last sentence. Do you really mean that the receiver has the power to distribute, e.g., all traffic to the first locator? Or that the load-split will be equal among the locators? If you mean the former, how do I signal that I desire an equal load split? Send 49-51? Editorial: > UDP Length: The UDP length field is for an IPv4 encapsulated packet, > the inner header Total Length plus the UDP and LISP header lengths > are used. For an IPv6 encapsulated packet, the inner header > Payload Length plus the size of the IPv6 header (40 bytes) plus > the size of the UDP and LISP headers are used. The UDP header > length is 8 bytes. > I had trouble parsing this text. The first sentence seems to say that the is only for IPv4, but I think you mean that the values are calculated in different ways for IPv4 and IPv6. Please clarify/reformulate. > The format of the > last 4 bytes of the LISP header would look like: > > > x x x x 1 x x x > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|flags| Nonce/Map-Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID | LSBs | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... format of the last 8 bytes of the LISP header .... > M: When set, it indicates a Map-Reply Record segment is included in > the Map-Request. Unlike other bits this one has no name. Or is it the "Map-Reply Record Bit"? > S: This is the SMR bit. SeeSection 6.6.2 for details. > Please expand SMR, as this is the first time this abbreviation appears in the document. > S: This is the SMR bit. SeeSection 6.6.2 for details. > > s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is > sending a Map-Request in response to a received SMR-based Map- > Request. The naming looks somewhat odd. Maybe SMR-request and SMR-response bits, or Solicited Map Request bit and Solicited Map Request Response bit... > IRC: This 5-bit field is the ITR-RLOC Count which encodes the > additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields > present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- > Address) pair must always be encoded. Multiple ITR-RLOC Address > fields are used so a Map-Replier can select which destination > address to use for a Map-Reply. The IRC value ranges from 0 to > 31, and for a value of 1, there are 2 ITR-RLOC addresses encoded > and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. > Perhaps you should explicitly say that value 0 means there are 1 ITR-RLOC addresses. (You say only that "At least one pair must always be encoded", but does that mean that value 0 is disallowed or that it means 1 pair?) Jari From jmh@joelhalpern.com Wed Oct 12 10:49:59 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B6321F8B9C; Wed, 12 Oct 2011 10:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw4gZRqbiZFu; Wed, 12 Oct 2011 10:49:59 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10F21F8B86; Wed, 12 Oct 2011 10:49:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 032AD43010A; Wed, 12 Oct 2011 10:49:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.243.68] (unknown [212.99.116.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 627404300A4; Wed, 12 Oct 2011 10:49:58 -0700 (PDT) Message-ID: <4E95D344.30302@joelhalpern.com> Date: Wed, 12 Oct 2011 13:49:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" References: <20111011210422.209AB21F8EC6@ietfa.amsl.com> In-Reply-To: <20111011210422.209AB21F8EC6@ietfa.amsl.com> X-Forwarded-Message-Id: <20111011210422.209AB21F8EC6@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: Nomcom 2011-2012: Call for community feedback X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:49:59 -0000 -------- Original Message -------- Subject: Nomcom 2011-2012: Call for community feedback Date: Tue, 11 Oct 2011 14:04:22 -0700 (PDT) From: NomCom Chair To: IETF Announcement list CC: ietf@ietf.org As per RFC 5680, NomCom 2011-2012 is issuing a call to the entire IETF community for feedback on the Willing Nominees for the open IETF positions. Nominations for the open positions are now closed and the list of willing nominees is now quite stable. Why is feedback important? ========================== Feedback is information you think will help NomCom make a decision on selecting candidates for open IETF positions. Feedback should be based on information you know first hand about an individual nominee. Community feedback is the most important input that determines who fills the open positions. We cannot properly execute the task of selecting the best candidates for the open positions without **YOUR** participation and feedback. Review the list of willing nominees and open positions ====================================================== The open list is currently available on the Nomcom page and the entire community is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ where the list of willing nominees is available and sorted by open position. IMPORTANT NOTE: Access to the Provide Feedback pages requires an www.ietf.org login. Logins used for previous years' nomcom pages used the tools.ietf.org login, which is separate. To get a www.ietf.org login if you don't already have one, please go to this page: https://datatracker.ietf.org/accounts/create/ Means of providing feedback to the NomCom ========================================= You can use one (or more) of the following methods to provide feedback to the Nomcom: - The best method is to enter it directly on the NomCom website at https://www.ietf.org/group/nomcom/2011/input/ . Click on the name of the person who you are providing feedback about and enter the text you want to provide us. - Send an email to nomcom11@ietf.org and be sure to identify the nominee and position the feedback pertains to. - Contact one (or more) of the Nomcom members by email. - Contact us in person in Taipei during our office hours. (to be announced soon) - You can provide **anonymous** feedback by contacting either the Nomcom chair or any of the Nomcom members who will anonymize it for the rest of the members. I would like to thank everyone who has provided us feedback already, and hope that more people from the community will take time to provide us further feedback. Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From internet-drafts@ietf.org Thu Oct 13 13:58:26 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C2E21F8B7E; Thu, 13 Oct 2011 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+dpfQO178md; Thu, 13 Oct 2011 13:58:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34D321F84F8; Thu, 13 Oct 2011 13:58:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111013205825.6840.2327.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2011 13:58:25 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:58:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map-Versioning Author(s) : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-map-versioning-05.txt Pages : 22 Date : 2011-10-13 This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to legacy implementations, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-05.txt From jari.arkko@piuha.net Thu Oct 13 14:34:30 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D000821F8A7D for ; Thu, 13 Oct 2011 14:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU6qKXTbBHWg for ; Thu, 13 Oct 2011 14:34:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E837C21F8564 for ; Thu, 13 Oct 2011 14:34:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 53F8B2D42C; Fri, 14 Oct 2011 00:34:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgnzCIYbxSmK; Fri, 14 Oct 2011 00:34:27 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A9F912CEFF; Fri, 14 Oct 2011 00:34:26 +0300 (EEST) Message-ID: <4E975962.3030908@piuha.net> Date: Thu, 13 Oct 2011 23:34:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org, Joel Halpern References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> <4E949339.4050109@piuha.net> In-Reply-To: <4E949339.4050109@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp (part 4) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:34:30 -0000 Still more parts in my review. I have now read until the beginning of Section 6.3.1. Some of these comments may change as I have read to the end of the document. Technical: > When an ETR is misconfigured or compromised, it could return coarse > EID-prefixes in Map-Reply messages it sends. The EID-prefix could > cover EID-prefixes which are allocated to other sites redirecting > their traffic to the locators of the compromised site. > > To solve this problem, there are two basic solutions that could be > used. The first is to have Map-Servers proxy-map-reply on behalf of > ETRs so their registered EID-prefixes are the ones returned in Map- > Replies. Since the interaction between an ETR and Map-Server is > secured with shared-keys, it is more difficult for an ETR to > misbehave. The second solution is to have ITRs and PTRs cache EID- > prefixes with mask-lengths that are greater than or equal to a > configured prefix length. This limits the damage to a specific width > of any EID-prefix advertised, but needs to be coordinated with the > allocation of site prefixes. These solutions can be used > independently or at the same time. > > At the time of this writing, other approaches are being considered > and researched. > There are obvious remaining issues with these solutions. Map-Servers may also be compromised, it is not clear that site prefix allocations have all equal size, ETRs may still return prefixes for someone else, etc. Have these been described in the security considerations section? > S: This is the Security bit. When set to 1 the field following the > Reserved field will have the following format. The detailed > format of the Authentication Data Content is for further study. For further study, as in not defined by any of the LISP documents currently being published? It might be more appropriate to say "This contents of this field are reserved for future use and no current authentication data formats are defined." And the implications should be described somewhere in security considerations section or the overall list of issues that need further work. (Or if this is actually defined somewhere, say "The detailed format of the field is described in [normative reference].") And why is this definition different from other places where an authentication data field was included? > 2. An ITR may receive an ICMP Network or ICMP Host Unreachable > message for an RLOC it is using. This indicates that the RLOC is > likely down. > There is obviously a need to soften the impact spurious or spoofed ICMP messages. There is probably a TCP RFC somewhere where you can copy some current advise wrt. trusting ICMP error messages. > When a bit goes from 1 to 0, the ETR will > refrain from encapsulating packets to an RLOC that is indicated as > down. Some considerations might be necessary for conflicting information. For instance, what do you do if you receive a packet from a locator that is claimed to be down by another ITR? Also, I do not fully understand what happens when you include the map version numbers in a LISP packet (V=1) and no nonce. Can off-the path attackers spoof a packet that claims to come from an ITR and which changes the locator status bits? That would open an ETR up for believe anyone in the Internet. Or am I missing something? Editorial: > 10.0.0.0/8 > 10.1.0.0/16 > 10.1.1.0/24 > 10.1.2.0/24 > > A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record > count of 1 to be returned with a mapping record EID-prefix of > 10.1.1.0/24. This is just a comment, but I would personally use the IPv4 example address ranges for these sorts of examples, particularly given that both identifiers and locators are normally globally reachable addresses. Jari From terry.manderson@icann.org Thu Oct 13 18:46:03 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9228621F84FA for ; Thu, 13 Oct 2011 18:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 304xhynrADL7 for ; Thu, 13 Oct 2011 18:46:03 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3050721F84F9 for ; Thu, 13 Oct 2011 18:46:03 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 13 Oct 2011 18:46:02 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 13 Oct 2011 18:46:00 -0700 Thread-Topic: WG meeting in Taipei, and call for agenda items. Thread-Index: AcyKEwY0EIuWDo6cnUuFIAwKor8L0Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] WG meeting in Taipei, and call for agenda items. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 01:46:03 -0000 Folks, The draft agenda has been released. https://datatracker.ietf.org/meeting/82/agenda.html In this IETF 82 draft agenda LISP has the slot: THURSDAY, November 17, 2011 1740-1940 Afternoon Session III 102 INT lisp=20 Locator/ID Separation Protocol WG So the dates to keep in mind are: 2011-10-17 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). 2011-10-21 (Friday): Final agenda to be published. 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC). 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC). 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC). 2011-11-04 (Friday): Early Bird registration and payment cut-off at 17:00 PT (00:00 UTC). 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC). So I am now open to receive requests for time on the LISP agenda in Taipei. Please get these to me by 2011-11-01 UTC 00:00:00. Cheers Terry From jerome@ceriz.fr Wed Oct 12 05:38:35 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ACB21F8CAB for ; Wed, 12 Oct 2011 05:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZf8QKM1vHSg for ; Wed, 12 Oct 2011 05:38:35 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F97621F8CAD for ; Wed, 12 Oct 2011 05:38:34 -0700 (PDT) Received: by qadb12 with SMTP id b12so669069qad.31 for ; Wed, 12 Oct 2011 05:37:30 -0700 (PDT) Received: by 10.229.188.12 with SMTP id cy12mr5518393qcb.26.1318422555140; Wed, 12 Oct 2011 05:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.84.146 with HTTP; Wed, 12 Oct 2011 05:28:55 -0700 (PDT) From: =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= Date: Wed, 12 Oct 2011 14:28:55 +0200 Message-ID: To: lisp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 15 Oct 2011 09:12:33 -0700 Subject: [lisp] IOS15.1(4)M out : time to test-drive it X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:38:35 -0000 Hi all, It was quite a great surprise to see LISP support embedded in the lates IOS15 M trend (2 weeks old). Beeing now able to run LISP off realtively cheap nodes (ISRs), let's start playing with it ! I've reed many things about LISP beeing capable of solving many common issues and am mostly interested in load balancing. Is there any case-study or test-drive-howto about deploying lisp in such manner ? Thanks ! --=20 J=C3=A9r=C3=B4me Nicolle +33 6 19 31 27 14 From jmh@joelhalpern.com Mon Oct 17 06:21:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AE421F848E for ; Mon, 17 Oct 2011 06:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq9bLxqwjJ+P for ; Mon, 17 Oct 2011 06:21:27 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id C9DD621F8A62 for ; Mon, 17 Oct 2011 06:21:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AD5C24300F5; Mon, 17 Oct 2011 06:21:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 8397F430096; Mon, 17 Oct 2011 06:21:22 -0700 (PDT) Message-ID: <4E9C2BD5.8060506@joelhalpern.com> Date: Mon, 17 Oct 2011 09:21:25 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "lisp@ietf.org" References: <015e01cc8c38$67e59c60$37b0d520$@olddog.co.uk> In-Reply-To: <015e01cc8c38$67e59c60$37b0d520$@olddog.co.uk> X-Forwarded-Message-Id: <015e01cc8c38$67e59c60$37b0d520$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-ms@tools.ietf.org, "draft-ietf-lisp@tools.ietf.org" Subject: [lisp] Fwd: RE: Adrian Farrel's Discuss on draft-ietf-lisp-ms-11: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:21:27 -0000 I have been exchanging notes with Adrian about his request for a disclaimer on the Mapping Service document. I believe we have agreed on text which is appropriate. THere is one implication on the text below. We will have to make sure we put appropriate warnings in the LISP base spec. But I believe we planned to do so anyway. Please let me know if you see a problem with the proposal. Yours, Joel -------- Original Message -------- Subject: RE: Adrian Farrel's Discuss on draft-ietf-lisp-ms-11: (with DISCUSS and COMMENT) Date: Sun, 16 Oct 2011 20:18:29 +0100 From: Adrian Farrel ... Just a statement along the lines of "Issues and concerns about the deployment of LISP for Internet traffic are discussed in [LISP]. Section 5 provides additional issues and concerns raised by this document." (Obviously, [LISP] would need to include the referenced text!) Regards, Adrian From internet-drafts@ietf.org Mon Oct 17 15:48:56 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8887C11E80B5; Mon, 17 Oct 2011 15:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQGDKUp9yFi6; Mon, 17 Oct 2011 15:48:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3885A11E8096; Mon, 17 Oct 2011 15:48:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111017224856.21311.91715.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2011 15:48:56 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:48:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP for Multicast Environments Author(s) : Dino Farinacci Dave Meyer John Zwiebel Stig Venaas Filename : draft-ietf-lisp-multicast-10.txt Pages : 39 Date : 2011-10-17 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-multicast-10.txt From jari.arkko@piuha.net Wed Oct 19 15:26:51 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AB521F8512 for ; Wed, 19 Oct 2011 15:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic+aJxQjDgfL for ; Wed, 19 Oct 2011 15:26:50 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0E54821F84F9 for ; Wed, 19 Oct 2011 15:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EFCAB2D42C; Thu, 20 Oct 2011 01:26:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+QquoAjkNaz; Thu, 20 Oct 2011 01:26:47 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 65A1D2CE32; Thu, 20 Oct 2011 01:26:47 +0300 (EEST) Message-ID: <4E9F4EA7.2090409@piuha.net> Date: Thu, 20 Oct 2011 01:26:47 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org, Joel Halpern Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp (poart 5) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:26:51 -0000 I'm still continuing my review. I've now read halfway through Section 11, and hope to complete the review by Friday. Technical: > 6.3. Routing Locator Reachability I think Lisp supports only bidirectional reachability (unless it relies on underlying BGP information), but I was unable to tell for sure from the document. Nonces and probes appear to work only when the same locator pairs are used for both directions of traffic. Could you say something about this in the document? > 6.5. Routing Locator Hashing It may be useful to point to http://tools.ietf.org/html/draft-ietf-6man-flow-ecmp-05 as well. > 1. Either a source and destination address hash can be used or the > traditional 5-tuple hash which includes the source and > destination addresses, source and destination TCP, UDP, or SCTP > port numbers and the IP protocol number field or IPv6 next- > protocol fields of a packet a host originates from within a LISP > site. When a packet is not a TCP, UDP, or SCTP packet, the > source and destination addresses only from the header are used to > compute the hash. There is a complication that fragments, and in general, IPv6 extension headers make the 5-tuple approach impractical on some systems. I wonder if this should affect the recommendation somehow. I can see the danger that people implement the 5-tuple check incompletely, causing fragmented packets to potentially go to a different path. But this is obviously a general issue, not Lisp specific. I can't remember other recommendations than the 6man document above about this matter. Does someone else remember? > 6.6.2. Solicit-Map-Request (SMR) The various rate limit mechanisms should either be specified or you should state that the right parameters are still under experimentation (I'd prefer the latter). > Since the ETRs don't keep track of remote ITRs that have cached their > mappings, they do not know which ITRs need to have their mappings > updated. As a result, an ETR will solicit Map-Requests (called an > SMR message) from those sites to which it has been sending > encapsulated data to for the last minute. In particular, an ETR will > send an SMR an ITR to which it has recently sent encapsulated data. More time factors that we do not yet know if they work well. But more importantly, what happens with ITRs who are not currently sending data but had cached a map entry? If the previous cache entry still contains working locators, we are fine, but what if not? Doesn't this point to a limitation that locator sets cannot (completely) change except on time scales longer than map entry cache lifetimes? Or am I missing something? > o When a tunnel encapsulated packet is received by an ETR, the outer > destination address may not be the address of the router. This seems like a basic thing, but I must have missed this. Which Lisp tunnel packets do not use the address of an ETR as the destination? > 7. Router Performance Considerations I expected this section to also talk about the effects of caching-based designs. What happens when you suddenly are getting a flood of new destinations to find a mapping to, etc. > The solution we propose to solve this problem is to cache traceroute > IPv4 headers in the ITR and to match them up with corresponding IPv4 > Time Exceeded messages received from core routers and the ETR. The > ITR will use a circular buffer for caching the IPv4 and UDP headers > of traceroute packets. All IPv4 UDP packets? Uh oh... perhaps you should include some of the implications either here or Section 7. This means inspecting every packet, for instance... Are you sure there are no other solutions to doing this? > The signature of a traceroute packet comes in two forms. The first > form is encoded as a UDP message where the destination port is > inspected for a range of values. The second form is encoded as an > ICMP message where the IP identification field is inspected for a > well-known value. > This is not much fun, either. Traceroute implementations generally allow quite liberal specification of which packets should be used for the probing: ICMP echo, UDP, TCP SYN, port selections, etc. At the very least you should document what the implications are, i.e., that only limited traceroute functionality can be supported. I don't think you can rely on configuration of port ranges and other things, because even if the administrator would know what traceroute types are used in his own network, traceroute should also work from the outside in the other direction, initiated by other people. > 10. Mobility Considerations We've talked about this in the past. I don't think mobility-as-a-feature-of-lisp belongs in this document, it belongs in the possible future document on Lisp mobility. We should not speculate what could be done. The impacts of Lisp to mobility protocols are, however, in scope. But I at least found the text somewhat unclear. First, I think you have decide what kind of scenarios you'd like to support. The text talks about changing EIDs, and I think that is something that you wouldn't necessarily need to cover; it is pretty alien to the current mobility protocols. But it would be a very reasonable question to ask if mobile nodes can move in and out of Lisp networks, and what the effects are? As far as I can tell, this can subdivided into the following aspects: 1) Pure mobile nodes (like most of today's laptops and PDAs) that do not support mobility protocols. When such a node arrives in a Lisp site, it will cause cache activity as it continues to do what it wants to do and re-establish connections to the sites that it wants to communicate with. 2) Mobile nodes that support a mobility protocol (MIP4, MIP6, HIP, etc). If all parties in the communication are in Lisp sites, these should not be affected beyond the usual cache effects. Lisp as is should be able to support this. 3) As above but using interworking between the Lisp and the Non-Lisp Internets. These bring NAT-like effects, I think, which may work with MIP4 but may have issues with MIP6. 4) Home agents and other forwarding agents. Can these exist in a Lisp site? I think the considerations are very similar to those in items 2 and 3. Here's a suggested quick rewrite: 10. Mobility Considerations There are several kinds of mobility of which only some might be of concern to LISP. Essentially they are as follows. 10.1. Site Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-RLOC mappings for sites are expected to be handled by configuration, outside of the LISP protocol. 10.2. Slow Endpoint Mobility An individual endpoint wishes to move, but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs. [RFC4984] 10.3. Fast Endpoint Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC3775] [RFC4866]. Possible Lisp support for similar functionality remains to be addressed by future work. 10.4. Interaction with Existing Mobile Nodes Mobile nodes that do not support any particular protocol mechanism (such as Mobile IP) should appear to Lisp sites just as other hosts do. However, nodes that move around are likely to re-establish connections to their communication peers when they enter the Lisp site, and this will likely cause additional mapping entries to be fetched for the caches, and may cause some initial performance degradation. Mobile nodes that use a mobility protocol (Mobile IPv4, Mobile IPv6, HIP) but communicate entirely within Lisp-enabled sites should not experience any differences to their usual operations. Again, mobile node movement will cause new communication patterns to the relevant home agents and, in the case of route optimization, correspondent nodes. The use of mobility protocols between Lisp-enabled and non-Lisp enabled sites will likely cause NAT-like effects. The specific effects remain a topic for further work and experimentation. Editorial: > There are two basic deployment trade-offs to consider: centralized > versus distributed caches and flat, recursive, or re-encapsulating > tunneling. When deciding on centralized versus distributed caching, > the following issues should be considered: > Perhaps you should define what you mean by centralized caching, distributed caching, etc. It was not clear for me. Jari From terry.manderson@icann.org Wed Oct 19 16:23:31 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4461F0C47 for ; Wed, 19 Oct 2011 16:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44KxkhaWpxub for ; Wed, 19 Oct 2011 16:23:31 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 27C0F1F0C44 for ; Wed, 19 Oct 2011 16:23:31 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 19 Oct 2011 16:23:30 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Wed, 19 Oct 2011 16:23:26 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx5TIaevaA3w2i0T9e8wLpgRLaj2gDf8fv2AAF3XfAAjeHhlAPrGaUv Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:23:31 -0000 Hi All, Joel and I bounced the following charter around and have also passed it in front of AD's eyes. You obviously have time to chew on this for a while before Taipei. The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol and any items which directly impact LISP. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for LISP and the various LISP mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on as well as the manageability and operability of LISP. Goals and Milestones Jun 2012 Forward draft-ietf-lisp-mib to the IESG. Jun 2012 Forward draft-ietf-lisp-sec to the IESG. Jun 2012 Forward draft-ietf-lisp-deployment to the IESG. Jun 2012 Forward a security proposal document (draft-ietf-lisp-threats) to the IESG. Dec 2013 Forward to the IESG an operational set of documents which shoul= d include cache management and ETR synchronization techniques inclusive of a cache management specification. Jun 2014 Forward to the IESG an evaluation of the security threat to cache management and ETR synchronization. Jun 2014 Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Dec 2014 Re-charter or close Cheers Terry From ari.keranen@nomadiclab.com Thu Oct 20 01:01:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49D621F8AF8 for ; Thu, 20 Oct 2011 01:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKmaYI0+upAC for ; Thu, 20 Oct 2011 01:01:27 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0226821F8AF7 for ; Thu, 20 Oct 2011 01:01:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 5FE764E6DA; Thu, 20 Oct 2011 11:01:25 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaLsVYYdsdDF; Thu, 20 Oct 2011 11:01:24 +0300 (EEST) Received: from n212.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 4BDAF4E6C5; Thu, 20 Oct 2011 11:01:24 +0300 (EEST) Message-ID: <4E9FD553.1020209@nomadiclab.com> Date: Thu, 20 Oct 2011 11:01:23 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 08:01:28 -0000 Hi, I read through the draft-ietf-lisp-15 and here's some comments (note that this is the first time I read the whole draft and I haven't followed closely the discussions on the list, so some of these issues may already have been discussed): The security features seem fairly weak. I guess that's OK for an experimental spec, but saying that "[...] nonce, coupled with the ITR accepting only solicited Map-Replies goes a long way toward providing decent authentication" (in the security considerations section) seems a bit misleading, especially considering on-path attackers. I think the security considerations section should be more clear on that. The basic overview section says that "EIDs are not expected to be usable for global end-to-end communication". From this I'd assume that with IPv4 RFC1918 addresses are commonly used as EIDs. However, sometimes packets seem to be sent directly to EIDs outside of LAN, e.g., section 6.1.3 says "For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure". How does this work with RFC1918 addresses? More specific comments and nits: 2. Introduction interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed xTRs. First instance of "xTR"; could use something generic like "LISP tunnel router" in the intro text instead. 3. Definition of Terms That is, a site which receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally prefix. What is "globally prefix"? Data Probe: A data-probe is a LISP-encapsulated data packet where the inner header destination address equals the outer header destination address used to trigger a Map-Reply by a decapsulating It would help to have "Map-Reply" and request defined before "Data Probe". 4.1. Packet Flow Sequence 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. [...] If there is no match, the Map-Request is dropped. I found it surprising that the Map-Request is (silently) dropped if there's no match. Wouldn't the request be then just re-transmitted to cope with packet loss? And how many times (I missed the discussion on re-transmissions too)? 5.4.2. A Stateful Solution to MTU Handling There's no discussion/recommendations on what kind of time-out values should be used for the MTU cache entries. 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats The UDP Checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register and ECM control messages. First (and only) instance of ECM; expand. 6.1.2. Map-Request Message Format A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. Could move the description of A-bit from 6.1.4 already here. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. This being one of the main security features, a "SHOULD" sounds pretty weak; I'd make it a MUST. 6.1.4. Map-Reply Message Format If all weights for a locator-set are equal, receiver of the Map-Reply will decide how to load-split traffic. Should this be "if all weights are 0" as discussed in section 6.2., 4th bullet? 6.1.5. EID-to-RLOC UDP Map-Reply Message the local IP addresses chosen to allow uRPF checks to succeed in the First (and only) instance of uRPF; expand (and add refence?) 6.2. Routing Locator Selection When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Should that rather be "MUST NOT send LISP encapsulated traffic toward RLOC" or something? Cheers, Ari From jmh@joelhalpern.com Thu Oct 20 08:02:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9316821F8B45 for ; Thu, 20 Oct 2011 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGEQfqey2BPh for ; Thu, 20 Oct 2011 08:02:53 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE0721F8B29 for ; Thu, 20 Oct 2011 08:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C69064300E1; Thu, 20 Oct 2011 08:02:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id A01434300CC; Thu, 20 Oct 2011 08:02:52 -0700 (PDT) Message-ID: <4EA0381A.1070805@joelhalpern.com> Date: Thu, 20 Oct 2011 11:02:50 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ari Keranen References: <4E9FD553.1020209@nomadiclab.com> In-Reply-To: <4E9FD553.1020209@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:02:53 -0000 Ari, on what basis did you come to the conclusion below. The goal (putting aside transition) is not that EIDs will come from 1918 space, but that we will be able to remove the EID blocks (and their dis-aggregations) from the global routing table. The use of the EID as the destination is within the ALT (or other mapping systems). EIDs must be unique within a mapping system. Yours, Joel On 10/20/2011 4:01 AM, Ari Keranen wrote: > The basic overview section says that "EIDs are not expected to be usable > for global end-to-end communication". From this I'd assume that with > IPv4 RFC1918 addresses are commonly used as EIDs. However, sometimes > packets seem to be sent directly to EIDs outside of LAN, e.g., section > 6.1.3 says "For the initial case, the destination IP address used for > the Map-Request is the destination-EID from the packet which had a > mapping cache lookup failure". How does this work with RFC1918 addresses? From ari.keranen@nomadiclab.com Thu Oct 20 09:05:04 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9AE21F8CBE for ; Thu, 20 Oct 2011 09:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVqqcgr97qzl for ; Thu, 20 Oct 2011 09:05:03 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB821F8CA0 for ; Thu, 20 Oct 2011 09:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 1608A4E6BA; Thu, 20 Oct 2011 19:05:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdMdeL13ctWv; Thu, 20 Oct 2011 19:05:01 +0300 (EEST) Received: from n212.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 1F2C64E664; Thu, 20 Oct 2011 19:05:01 +0300 (EEST) Message-ID: <4EA046AC.90504@nomadiclab.com> Date: Thu, 20 Oct 2011 19:05:00 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E9FD553.1020209@nomadiclab.com> <4EA0381A.1070805@joelhalpern.com> In-Reply-To: <4EA0381A.1070805@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:05:04 -0000 Hi Joel, I got that impression from the text I cited below and from the examples in the draft using the 10/8 space. If the "common case" (at least eventually) is using the globally routed addresses blocks, perhaps that could be explicitly stated, e.g., somewhere in the beginning of section 4? And apparently at least Map-Requests can be sent without ALT using the "underlying routing system topology" (section 4.1.) and EID as destination address (sec 6.1.3). Doesn't this break if the EID blocks are removed from the global routing table? Cheers, Ari On 10/20/11 6:02 PM, Joel M. Halpern wrote: > Ari, on what basis did you come to the conclusion below. > The goal (putting aside transition) is not that EIDs will come from 1918 > space, but that we will be able to remove the EID blocks (and their > dis-aggregations) from the global routing table. > > The use of the EID as the destination is within the ALT (or other > mapping systems). EIDs must be unique within a mapping system. > > Yours, > Joel > > On 10/20/2011 4:01 AM, Ari Keranen wrote: >> The basic overview section says that "EIDs are not expected to be usable >> for global end-to-end communication". From this I'd assume that with >> IPv4 RFC1918 addresses are commonly used as EIDs. However, sometimes >> packets seem to be sent directly to EIDs outside of LAN, e.g., section >> 6.1.3 says "For the initial case, the destination IP address used for >> the Map-Request is the destination-EID from the packet which had a >> mapping cache lookup failure". How does this work with RFC1918 addresses? From damien.saucez@gmail.com Fri Oct 21 08:23:33 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB2A1F0C87 for ; Fri, 21 Oct 2011 08:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8m0YHfg2KyJ for ; Fri, 21 Oct 2011 08:23:33 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A775C1F0C86 for ; Fri, 21 Oct 2011 08:23:32 -0700 (PDT) Received: by wyh22 with SMTP id 22so4615702wyh.31 for ; Fri, 21 Oct 2011 08:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=wPehSIEgKtvu0DvvTLJr5Ds0HZAzkfkFCZudgg2Fn9w=; b=Qg7g4X2ZQVkD8/MhEXeQBoOzcAiRphOFOr/QhEBgXM3UJBMHITXgcVMNexG9wfirI2 vnCMz0ZVb+gfKvWv26BcakUZMwYY/6f7zPG0B9ecgqVstc1sitUMchOBLHM0jMHBv/UX 38PeVExJSpXNLDRkkPpc6LLFflpzPYBJBp/QI= Received: by 10.227.58.84 with SMTP id f20mr6678064wbh.9.1319210580279; Fri, 21 Oct 2011 08:23:00 -0700 (PDT) Received: from eduroam-107a.sophia.inria.fr (eduroam-107a.sophia.inria.fr. [193.48.247.107]) by mx.google.com with ESMTPS id a21sm22371250wbo.10.2011.10.21.08.22.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Oct 2011 08:22:59 -0700 (PDT) From: Damien Saucez Content-Type: multipart/alternative; boundary="Apple-Mail=_2879F8AA-5BB9-4EEE-9E5A-46E3CED76D4D" Date: Fri, 21 Oct 2011 17:22:58 +0200 References: <20111021151333.3316.42337.idtracker@ietfa.amsl.com> To: LISP mailing list list Message-Id: <94D2A643-5798-4793-BBA8-0786B709389C@gmail.com> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [lisp] Fwd: New Version Notification for draft-saucez-lisp-ccn-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:23:34 -0000 --Apple-Mail=_2879F8AA-5BB9-4EEE-9E5A-46E3CED76D4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-saucez-lisp-ccn-00.txt > Date: 21 Oct 2011 17:13:33 GMT+02:00 > To: damien.saucez@inria.fr > Cc: damien.saucez@inria.fr >=20 > A new version of I-D, draft-saucez-lisp-ccn-00.txt has been = successfully submitted by Damien Saucez and posted to the IETF = repository. >=20 > Filename: draft-saucez-lisp-ccn > Revision: 00 > Title: CCN Router Interconnection with LISP > Creation date: 2011-10-21 > WG ID: Individual Submission > Number of pages: 6 >=20 > Abstract: > Content distribution prevails in today's Internet and = Content-Centric > Networking (CCN) proposes to access the data directly by their > content instead of their location. In this memo we present a LISP > based solution to interconnect CCN routers over the Internet. We > first describe how content names can be encoded in LISP with LCAF. > We then detail the operations of CCN routers to determine the CCN > routers to which forward Interest and Data messages. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_2879F8AA-5BB9-4EEE-9E5A-46E3CED76D4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: New Version Notification for = draft-saucez-lisp-ccn-00.txt
Date: 21 Oct 2011 17:13:33 GMT+02:00

A new version of I-D, draft-saucez-lisp-ccn-00.txt has = been successfully submitted by Damien Saucez and posted to the IETF = repository.

Filename: = draft-saucez-lisp-ccn
Revision: 00
Title: CCN = Router Interconnection with LISP
Creation date: = 2011-10-21
WG ID: Individual Submission
Number = of pages: 6

Abstract:
  Content distribution = prevails in today&#39;s Internet and Content-Centric
=   Networking (CCN) proposes to access the data directly by = their
  content instead of their location.  In this = memo we present a LISP
  based solution to interconnect = CCN routers over the Internet.  We
  first describe = how content names can be encoded in LISP with LCAF.
  We = then detail the operations of CCN routers to determine the CCN
=   routers to which forward Interest and Data = messages.




The IETF = Secretariat

= --Apple-Mail=_2879F8AA-5BB9-4EEE-9E5A-46E3CED76D4D-- From jari.arkko@piuha.net Fri Oct 21 16:24:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68D121F8B07 for ; Fri, 21 Oct 2011 16:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvQnIVp8PCla for ; Fri, 21 Oct 2011 16:24:24 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D20C621F8B05 for ; Fri, 21 Oct 2011 16:24:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C66E32CC52; Sat, 22 Oct 2011 02:24:21 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmCL22pq4Cqw; Sat, 22 Oct 2011 02:24:20 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 866FC2CC51; Sat, 22 Oct 2011 02:24:20 +0300 (EEST) Message-ID: <4EA1FF24.7000902@piuha.net> Date: Sat, 22 Oct 2011 02:24:20 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org, Joel Halpern Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp (part 6) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 23:24:24 -0000 Technical: Overall, the security considerations section is a bit thin. I don't think we need a lot of additional text, but there are some additional pieces of information that need to be added. Some suggested text below. > The nonce, coupled > with the ITR accepting only solicited Map-Replies goes a long way > toward providing decent authentication. Hmm. This is not really descriptive. How about this instead: The nonce, coupled with the ITR accepting only solicited Map-Replies provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these Lisp mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible, but would already by itself be a denial-of-service attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking or redirecting traffic. Lisp relies on the correct operation of a BGP-based routing system [LISP-ALT], but so do the current Internet routing mechanisms. > It is a good idea to have instrumentation in place > to detect thrashing of the cache. Implementation experimentation > will be used to determine which cache management strategies work > best. Yes, but I think we should also acknowledge that defending against cache trashing attacks is hard: It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. In general, it is difficult to defend against cache trashing attacks. (Unless, of course, I'm missing some obvious schemes that show promise of avoiding some of these issues against determined attackers. It is also possible that if we described the situation in more detail, we'd be able to describe the threats in a more rational way. E.g., outsiders can cause some (limited) problems, insiders could cause big trouble but are generally a bit more trusted, etc.) > This experimental specification does not address automated key > management (AKM).BCP 107 provides guidance in this area. Yes, but I think we should include two additional important pieces of information. 1. you need to acknowledge that you are not following BCP 107 in this case, as it requires AKM under certain conditions (we are within those conditions, right?). And 2) more importantly, you need to document the implications of not providing AKM. Personally, I do not necessarily consider it a panacea, and often the nonce etc. mechanisms are far more important. In any case, the reader needs to understand what we are losing without AKM. > 13. Network Management Considerations > > Considerations for Network Management tools exist so the LISP > protocol suite can be operationally managed. The mechanisms can be > found in [LISP-MIB] and [LISP-LIG]. It is good that you point to these specifications. I wonder if there are additional things you should say in this spec, however. Are there parameters that Lisp needs to operate? Are they and their default values described in LISP-MIB? There are many good pieces of advice about the management of a Lisp network in previous sections, should there be some kind of summary/pointers for these here as well? Editorial: > Return- Routability s/- /-/ > datragram. If a LISP encapsulated packet arrives at an ETR, it MAY > datagram > system [KARP ], [RPKI ], > [BGP-SEC ], [LISP-SEC ], s/[LISP-SEC],/[LISP-SEC]./ Jari From jari.arkko@piuha.net Sat Oct 22 14:03:08 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33C421F8677 for ; Sat, 22 Oct 2011 14:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY9Y+SECcLWX for ; Sat, 22 Oct 2011 14:03:07 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 64BE021F8801 for ; Sat, 22 Oct 2011 14:03:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6AC642CC4E; Sun, 23 Oct 2011 00:02:54 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4Wu0hOUTkyx; Sun, 23 Oct 2011 00:02:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id F103A2CC4A; Sun, 23 Oct 2011 00:02:52 +0300 (EEST) Message-ID: <4EA32F7B.1060904@piuha.net> Date: Sun, 23 Oct 2011 00:02:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org, Joel Halpern References: <4EA1FF24.7000902@piuha.net> In-Reply-To: <4EA1FF24.7000902@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 21:03:09 -0000 This is the last part of my review, as far as the actual document contents go. I will send another summary e-mail. Technical: > 14.1. LISP Address Type Codes > > Instance ID type codes have a range from 0 to 15, of which 0 and 1 > have been allocated [LCAF]. New Type Codes MUST be allocated > starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. > Type Codes 11 - 15 are available on a First Come First Served policy. > > The following codes have been allocated: > > Type 0: Null Body Type > > Type 1: AFI List Type > > See [LCAF] for details for other possible unapproved address > encodings. The unapproved LCAF encodings are an area for further > study and experimentation. To begin with, I did not understand this definition. I'm trying to understand where the LCAF draft actually makes the instance ID allocations, and I can't see it. In addition, the "Null Body Type" string only appears twice in this and the LCAF draft, and neither occurrence explains what it is. I think something is missing here. Finally, I do not understand why this section is in -lisp. The string "LISP Address Type Code" does not appear in the rest of the document AFAICT. The allocations in the LCAF draft seem to be inside a format defined in that draft. Shouldn't the IANA allocations and the creation of the registry be in that draft as well? This seems particularly important, given that the list of types in -lisp does not match the list in -lcaf. Suggested edit: delete this section. > > o The following policies are used here with the meanings defined in > BCP 26 : "Specification Required", "IETF Consensus", "Experimental > Use", "First Come First Served". > None of these terms are used in the rest of the document. (But see below.) > 14. IANA Considerations This sections makes the right allocations from other, already existing registries (like UDP port numbers). But it should also define what the policies are for allocating new values with the various new number spaces that Lisp introduces: - flags - type - reserved - act - unused flags - ... > [BGP-SEC] Lepinski, M., "An Overview of BGPSEC", > draft-lepinski-bgpsec-overview-00.txt (work in progress), > March 2011. > > [KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for > Routing Protocols (KARP)Design Guidelines", > draft-ietf-karp-design-guide-02.txt (work in progress), > March 2011. > [RPKI] Lepinski, M., "An Infrastructure to Support Secure > Internet Routing",draft-ietf-sidr-arch-13.txt (work in > progress), February 2011. I have a hard time seeing why these should be normative references. They are just mentioned as work that is in progress in securing the routing system. You do not need to read these to implement LISP as specified in this document, or even to understand what Lisp is or its impacts. > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13,RFC 1034 , November 1987. > If you look at the way this is referenced from the text, it is clear that this should be a non-normative reference. The host obtains a destination EID the same way it obtains an destination address today, for example through a Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. > [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, > A., Peterson, J., Sparks, R., Handley, M., and E. > Schooler, "SIP: Session Initiation Protocol", RFC 3261, > June 2002. Same as above. > [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. > Traina, "Generic Routing Encapsulation (GRE)",RFC 2784 , > March 2000. > If you look at the way this is referenced from the text, I think this should be a non-normative reference. o On an ITR, prepending a new IP header consists of adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. GRE is here use as an example, not as normative behavior. > [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains > via IPv4 Clouds",RFC 3056 , February 2001. > Same as above. > > [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route > Optimization for Mobile IPv6",RFC 4866 , May 2007. I think this one can be non-normative or even be removed, depending on how the mobility section rewrite goes. > > [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB > Workshop on Routing and Addressing",RFC 4984 , > September 2007. > Background. Non-normative. > [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY > NUMBERS > http://www.iana.org/assignments/address-family-numbers. > > [AFI-REGISTRY] > IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY > NUMBER registryhttp://www.iana.org/assignments/ > address-family-numbers/ > address-family-numbers.xml#address-family-numbers-1. Is there really no better reference for this, an RFC perhaps? I wish there were... and that RFC could be put in to the normative-reference section. If there is no suitable RFC I'm fine with the current two references as-is. > [INTERWORK] > Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, > "Interworking LISP with IPv4 and IPv6", > draft-ietf-lisp-interworking-02.txt (work in progress). > I think this one should be normative. This is such a key piece of work to understanding Lisp, and the text seems to treat it as if it is a normative part. For instance: Proxy ITR (PITR): A PITR is also known as a PTR is defined and described in [INTERWORK], a PITR acts like an ITR but does so on behalf of non-LISP sites which send packets to destinations at LISP sites. > [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", > draft-ietf-lisp-ms-09.txt (work in progress). > Isn't this normative as well? Here's an example of how the text refers to it: Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on encapsulated Map-Requests and Map-Resolvers can be found in [LISP-MS]. > > [VERSIONING] > Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping > Versioning",draft-ietf-lisp-map-versioning-01.txt (work > in progress). > I suspect this is normative, too. See Section 6.6.3. Jari From jari.arkko@piuha.net Sun Oct 23 04:28:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6010C21F85A4 for ; Sun, 23 Oct 2011 04:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpNG6sHi2Z0G for ; Sun, 23 Oct 2011 04:28:26 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7D921F8515 for ; Sun, 23 Oct 2011 04:28:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7FC232CC4E; Sun, 23 Oct 2011 14:28:24 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO+b99fRf0fs; Sun, 23 Oct 2011 14:28:23 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 974522CC43; Sun, 23 Oct 2011 14:28:23 +0300 (EEST) Message-ID: <4EA3FA55.5050100@piuha.net> Date: Sun, 23 Oct 2011 14:28:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: draft-ietf-lisp@tools.ietf.org, lisp@ietf.org, Joel Halpern Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp: summary X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 11:28:27 -0000 I have now completed my review. In general, I'm quite happy with the document. There were of course a number of issues, even some technical ones such as explaining the areas where experimentation is needed in Section 1, expanding the security considerations section, when you do return routability checks, pointing to normal ECN functionality, advice for ICMP treatment, the scope of the mobility section, better acknowledgment of cache management difficulties in the router performance section, contents of the IANA section, normative/non-normative reference split, and so on. But on the whole I did not see any showstoppers. We should be able to make the modifications quickly and last call the document. I can see that Dino has already done a lot of that; thanks. In some cases further discussion is needed. I will respond on the mail thread on each specific mail. One additional follow-up on my own earlier note: >> An ITR that is configured with mapping database information (i.e. it >> is also an ETR) may optionally include those mappings in a Map- >> Request. When an ETR configured to accept and verify such >> "piggybacked" mapping data receives such a Map-Request and it does >> not have this mapping in the map-cache, it may originate a "verifying >> Map-Request", addressed to the map-requesting ITR. If the ETR has a >> map-cache entry that matches the "piggybacked" EID and the RLOC is in >> the locator-set for the entry, then it may send the "verifying Map- >> Request" directly to the originating Map-Request source. If the RLOC >> is not in the locator-set, then the ETR MUST send the "verifying Map- >> Request" to the "piggybacked" EID. Doing this forces the "verifying >> Map-Request" to go through the mapping database system to reach the >> authoritative source of information about that EID, guarding against >> RLOC-spoofing in in the "piggybacked" mapping data. > > I want to understand this better and I guess reading to the end of the document will answer some of my questions. But as a general rule, I think we should not trust other nodes in the network to claim alternative addresses for themselves, unless we can somehow verify (via return routability or via mapping data base) that they appear to really be at that address. So I am wondering if the "may originate" should become "originates". But I'm reading on. I think the right thing here is already specified in your text for the case when the map-cache entry exists. But I think you need to change the "may originate" in the to "MUST originate" when there is no map-cache entry. Otherwise, you are believing a locator claim from a random packet sent to you. It is too easy to misuse this, and the remedy is simple: just require the same check as you already do when the cache entry exists but the locator is new. Jari From jari.arkko@piuha.net Sun Oct 23 05:13:36 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5456321F84C2 for ; Sun, 23 Oct 2011 05:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UUEU2BYxt7z for ; Sun, 23 Oct 2011 05:13:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CAE0A21F84F5 for ; Sun, 23 Oct 2011 05:13:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 76E4F2CC4E; Sun, 23 Oct 2011 15:13:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TxQQQYuPKsm; Sun, 23 Oct 2011 15:13:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 64D362CC39; Sun, 23 Oct 2011 15:13:26 +0300 (EEST) Message-ID: <4EA404E4.7040302@piuha.net> Date: Sun, 23 Oct 2011 15:13:24 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Dino Farinacci References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 12:13:36 -0000 Dino, > >>> o End-systems (hosts) only send to addresses which are EIDs. They >>> don't know addresses are EIDs versus RLOCs but assume packets get >>> to LISP routers, which in turn, deliver packets to the destination >>> the end-system has specified. >>> >> Is this always true, e.g, when some interworking mechanism between the LISP and non-LISP parts of the Internet is in use, and one of the peers employs some NAT traversal techniques? It would seem that there can be cases where the peers observe RLOC addresses and use them for some purpose. > But they don't know they are RLOC addresses. All end-systems assume is that addresses they put int destination address fields will make it to the destination. So if the address is an RLOC, the underlying routing system will have routes to get the packet to the destination. Otherwise, the packet moves toward a LISP router that will encapsulate to get the packet to the destination. That makes sense. Please consider if you want to modify the text somehow; currently you are saying that hosts only send to EIDs. That is of course normally the case, but other cases will also happen and the routing should still work as expected. This is just a comment from me though, not a blocking issue. > >>> A server host can be the endpoint >>> of a LISP tunnel as well. >> ... >>> o RLOCs are always IP addresses assigned to routers >>> >> Isn't this an inconsistency? Or is a server that terminates a tunnel called a router? > For the sake of this document and keeping it within the charter of the working group, a router is a LISP router. We do not consider hosts doing LISP as specified in the LISP-MN document. Which is out of charter for this working group. > > So if a server is acting as a router, then it has RLOCs. > > Hosts have EIDs assigned to them (when they are resident in a LISP site), IGP routers have EIDs assigned to them, and LISP routers have both EIDs and RLOCs assigned to them. OK > >>> o When a router originates packets it may use as a source address >>> either an EID or RLOC. >> You should state somewhere what the manageability requirements are for making this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use of addresses). Does this require additional functionality for RFC 3484 style source address selection, or can you cope with existing functionality? > It does not. The same requirements for originating IP packets has not changed. If it is stated that the outgoing interface's address is used as the source address, then whatever namespace the address belongs to is used. > >> Note: I'm not asking for any new functionality, just a statement about the expectations. > No expectations. ;-) Fine. Can we state that? At least this reader was wondering if a router needed something special to be handle the selection. I'm of course very glad that the answer is no. > >>> In order to avoid excessive packet overhead as well as possible >>> encapsulation loops, this document mandates that a maximum of two >>> LISP headers can be prepended to a packet. >> This seems hard to mandate in any real sense. Perhaps you want to say "recommends" instead of "mandates"? > We thought long and hard about this and wanted to mandate to indicate the seriousness of not going overboard with encapsulation. Now I know implementors can ignore specs, but for the record when it is documented the way we did it is more clear on the strength of the statement. OK > >>> 2. The LISP ITR must be able to map the EID destination to an RLOC >>> of one of the ETRs at the destination site. The specific method >>> used to do this is not described in this example. See [ALT] or >>> [CONS] for possible solutions. >>> >>> 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be >>> rate-limited. >>> >>> 4. When an alternate mapping system is not in use, the Map-Request >>> packet is routed through the underlying routing system. >>> Otherwise, the Map-Request packet is routed on an alternate >>> logical topology. In either case, when the Map-Request arrives >>> at one of the ETRs at the destination site, it will process the >>> packet as a control message. >> First, the the "alternate mapping system" appears here for the first time. Maybe you should indicate it refers to [ALT]. > But we have a long list of mapping systems, do you want all of them to be listed? >> Second, parts of step 4 go pretty deep in what the specific mapping methods are. I'm wondering if this alternative text would fit better: >> >> "4. The Map-Request packet is delivered to the right ETR with the help of the mapping system. (For instance, in [ALT] this happens via an EID-based alternate routing topology.) In any case, when the Map-Request arrives …" > Well it does not capture the fact that the Map-Request can be delivered via the underlying routing system. I will add a refernece to ALT though from your first comment. OK >>> 6. The ITR receives the Map-Reply message, parses the message (to >>> check for format validity) and stores the mapping information >>> from the packet. This information is stored in the ITR's EID-to- >>> RLOC mapping cache. Note that the map cache is an on-demand >>> cache. An ITR will manage its map cache in such a way that >>> optimizes for its resource constraints. >>> >> This is just a comment, but FWIW, I am not super happy about the way the caching is an integral part of the specifications for LISP. Fundamentally, you could have used two orthogonal tools for dealing with routing scalability: 1. have only a subset of routers have to deal with EID routing (the xTRs) and 2. > Which is the way LISP is designed. > >> use caching for scaling these routers better. If we had done this, then we would have had a very easy > Which is also the way LISP is designed. > > So I am not following you. > >> answer to those who have criticized the caching approach over the years: it is optional and up to the implementors to use or not. The first tool would still have been a valid approach to make the Internet scale better, even if you never did any caching. > The map-cache is only in the ITRs and PITRs as you described in point 1. And with added stretch the ITRs and PITRs could have a default cache entry that encapsulates to a set of ETRs which can hold more cache entries, and so on. If one chose to deploy LISP in a hierarchical way. This isn't a very urgent discussion because my comment was just that a comment. No need for you to change anything in the document. But I am still curious if you could implement a LISP router that simply held the entire mapping database and did not use any caching. But lets take the answer to that in some other thread to save time for moving the document forward... > 8. The ETR receives these packets directly (since the destination > address is one of its assigned IP addresses), strips the LISP > header and forwards the packets to the attached destination host. > > Spoofing of inner header addresses of LISP encapsulated packets is > possible like with any tunneling mechanism. ITRs MUST verify the > source address of a packet to be an EID that belongs to the site's > EID-prefix range prior to encapsulation. An ETR must only > decapsulate and forward datagrams with an inner header destination > that matches one of its EID-prefix ranges. If, upon receipt and > decapsulation, the destination EID of a datagram does not match one > of the ETR's configured EID-prefixes, the ETR MUST drop the > datragram. If a LISP encapsulated packet arrives at an ETR, it MAY > compare the inner header source EID address and the outer header > source RLOC address with the mapping that exists in the mapping > database. Then when spoofing attacks occur, the outer header source > RLOC address can be used to trace back the attack to the source site, > using existing operational tools. >> First, I think Step 8 should be slightly edited to cover the fact that some additional checks are being made. E.g., "The ETR receives these packets directly (since ...), checks the validity of the addresses used in the packet, strips the LISP header and …" > I will add "checks the validity of the addresses" and of course keep the text that follows Step 8. Thanks. > >> Second, I wish you would have specified the source address checks better. Are there situations where you would NOT want to make a pretty strict test, i.e., that source EID maps to source RLOC? > Because this is work still in progress. I understand that, but accepting tunnel packets without this validation just seems pretty open to attacks. And this is not just about LISP. In general, every IETF technique that comes out may have vulnerabilities that cause trouble not just for that technology but also for other things in the Internet. I'm worried that this coyld be an attack vector to attack other things in the Internet in the future. Can we agree on a middle ground, e.g., make the MAY a SHOULD? I'd be much happier with that... > >>> The next sub-sections illustrate packet formats for the >>> homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 >>> combinations SHOULD be supported. >> For interoperability, wouldn't it be cleaner to have a MUST here? How would I otherwise know if I can send an IPv4-in-IPv6 packet to a destination? > I can change to MUST. Thanks. Jari From jari.arkko@piuha.net Sun Oct 23 05:47:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA6E21F861E for ; Sun, 23 Oct 2011 05:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44tXycO0MdT3 for ; Sun, 23 Oct 2011 05:47:22 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 40ECD21F8586 for ; Sun, 23 Oct 2011 05:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 04C352CC61 for ; Sun, 23 Oct 2011 15:47:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J57h7nS6jqJq for ; Sun, 23 Oct 2011 15:47:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A538B2CC52 for ; Sun, 23 Oct 2011 15:47:14 +0300 (EEST) Message-ID: <4EA40CC8.8000303@piuha.net> Date: Sun, 23 Oct 2011 15:47:04 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: lisp@ietf.org References: <4E9FD553.1020209@nomadiclab.com> <4EA0381A.1070805@joelhalpern.com> <4EA046AC.90504@nomadiclab.com> In-Reply-To: <4EA046AC.90504@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 12:47:22 -0000 By the way, it is interesting that Ari thought the EIDs would come out of 10/8 space. That is obviously wrong, but maybe this misunderstanding gives us a datapoint on the issue that I raised earlier about using the 10/8 addresses in examples. Jari From dino@cisco.com Sun Oct 23 12:30:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF97B21F8B2B for ; Sun, 23 Oct 2011 12:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzCj5S2MA5eb for ; Sun, 23 Oct 2011 12:30:22 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E03F421F8B26 for ; Sun, 23 Oct 2011 12:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=718; q=dns/txt; s=iport; t=1319398222; x=1320607822; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CGZhux0peQiD+WPWlLOc7RKOZ+9chZDeebcTQaoSLms=; b=XPSFg2izeQAn962c0l/xYtZ9Q+v4cSIjHO1mzgv6929vhXmngdaUV29u GqsFOgGKsCgNeYQfhkUvj1KhyNNAxsPLJKh70SIJE+/5jrj0h1VKcSzCz S+cVqcvESG0FGE7PdcIx5ayH+1Br6gp2oDUHXnUVja/IGVB6LTi2yGwIM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACZqpE6Q/khR/2dsb2JhbABCqRKBBYFuAQEBAwEBAQEPASc0CwULC0YnMAYTIodeCJdnAZ0WBIdfYQSIBowDkXs X-IronPort-AV: E=Sophos;i="4.69,394,1315180800"; d="scan'208";a="58351078" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 23 Oct 2011 19:30:19 +0000 Received: from sjc-vpn6-1888.cisco.com (sjc-vpn6-1888.cisco.com [10.21.127.96]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9NJUII1018039; Sun, 23 Oct 2011 19:30:18 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <4EA40CC8.8000303@piuha.net> Date: Sun, 23 Oct 2011 12:30:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> References: <4E9FD553.1020209@nomadiclab.com> <4EA0381A.1070805@joelhalpern.com> <4EA046AC.90504@nomadiclab.com> <4EA40CC8.8000303@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:30:22 -0000 > By the way, it is interesting that Ari thought the EIDs would come out = of 10/8 space. That is obviously wrong, but maybe this misunderstanding = gives us a datapoint on the issue that I raised earlier about using the = 10/8 addresses in examples. Ah, but they could. That is the point. Since they are not injected in = the core, an EID-prefix in 10/8 space can be made unique to both the = mapping database and the data-plane core by coupling it with an = instance-ID. And the instance-ID need only be unique *per mapping = database system*. Dino > Jari >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jari.arkko@piuha.net Sun Oct 23 12:48:18 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC2B21F8A91 for ; Sun, 23 Oct 2011 12:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONlWPwVd6Mx6 for ; Sun, 23 Oct 2011 12:48:17 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7B07421F8AAA for ; Sun, 23 Oct 2011 12:48:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6E5F42CC54; Sun, 23 Oct 2011 22:48:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm-mTcOqUnC4; Sun, 23 Oct 2011 22:48:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D3B462CC52; Sun, 23 Oct 2011 22:48:15 +0300 (EEST) Message-ID: <4EA46F7D.3020303@piuha.net> Date: Sun, 23 Oct 2011 22:48:13 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Dino Farinacci References: <4E9FD553.1020209@nomadiclab.com> <4EA0381A.1070805@joelhalpern.com> <4EA046AC.90504@nomadiclab.com> <4EA40CC8.8000303@piuha.net> <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> In-Reply-To: <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 19:48:18 -0000 Yes, but setting up the entire system so that this works would be challenging (how names resolve to addresses, how applications know about this, etc). But it probably doesn't matter, it is of course true that it could be done. My point was that this is probably not the usual configuration, and at least one reader got confused by the use of private addresses in the examples. I'm not holding this as a blocking comment in my review, but if it were my spec I would probably change the addresses to something else. Jari From akatlas@gmail.com Sun Oct 23 13:17:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3E21F89BA for ; Sun, 23 Oct 2011 13:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aevgzaoi3etL for ; Sun, 23 Oct 2011 13:17:47 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4A621F8922 for ; Sun, 23 Oct 2011 13:17:47 -0700 (PDT) Received: by pzk34 with SMTP id 34so15152877pzk.9 for ; Sun, 23 Oct 2011 13:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yRprUQyqhThhatKOTC1+RSDTDvsM7rr3iE2caA99RoY=; b=NxBcfRiwXtjbBXwFDF8t3H5nzEJp3Qd75rCiZcWqKMnZ+fGSfXVILvM8JgagYbpS4j 5iKm+EEy1d2P+V4RmTfzqhFcije1+dv8c0YPbJ1I7WcNjUydOVhSm4izQ0YGIHiKtSCW sX3hKNf2VvXrtXQ4sBz7YphDn4bZqZqqSGDFQ= MIME-Version: 1.0 Received: by 10.68.14.97 with SMTP id o1mr43750129pbc.0.1319401066415; Sun, 23 Oct 2011 13:17:46 -0700 (PDT) Received: by 10.143.92.18 with HTTP; Sun, 23 Oct 2011 13:17:46 -0700 (PDT) In-Reply-To: <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> References: <4E9FD553.1020209@nomadiclab.com> <4EA0381A.1070805@joelhalpern.com> <4EA046AC.90504@nomadiclab.com> <4EA40CC8.8000303@piuha.net> <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> Date: Sun, 23 Oct 2011 16:17:46 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 20:17:48 -0000 As I recall, all of the details to pass Instance-ID weren't there for the ALT mapping database. I'd have to review my earlier comments, but I also found this confusing and considered the idea of the Instance-IDs as one of those concepts that wasn't sufficiently developed in the spec. Alia On Sun, Oct 23, 2011 at 3:30 PM, Dino Farinacci wrote: >> By the way, it is interesting that Ari thought the EIDs would come out o= f 10/8 space. That is obviously wrong, but maybe this misunderstanding give= s us a datapoint on the issue that I raised earlier about using the 10/8 ad= dresses in examples. > > Ah, but they could. That is the point. Since they are not injected in the= core, an EID-prefix in 10/8 space can be made unique to both the mapping d= atabase and the data-plane core by coupling it with an instance-ID. And the= instance-ID need only be unique *per mapping database system*. > > Dino > > >> Jari >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jmh@joelhalpern.com Sun Oct 23 13:54:08 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE7B21F867F for ; Sun, 23 Oct 2011 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.782 X-Spam-Level: X-Spam-Status: No, score=-101.782 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBFs8NvOcKWC for ; Sun, 23 Oct 2011 13:54:08 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 478C121F8678 for ; Sun, 23 Oct 2011 13:54:08 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) by morbo.tigertech.net (Postfix) with ESMTP id 01501A3920 for ; Sun, 23 Oct 2011 13:54:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 40AB7361C16; Sun, 23 Oct 2011 13:54:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from [10.10.10.100] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 840C1361BFA; Sun, 23 Oct 2011 13:54:04 -0700 (PDT) Message-ID: <4EA47EE7.3030304@joelhalpern.com> Date: Sun, 23 Oct 2011 16:53:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4E9FD553.1020209@nomadiclab.com> <4EA0381A.1070805@joelhalpern.com> <4EA046AC.90504@nomadiclab.com> <4EA40CC8.8000303@piuha.net> <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> In-Reply-To: <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 20:54:08 -0000 The problem I have with that view is that although it is accurate, it is also bascially not explained. For charter reasons, we left out any explanation of the private spaces, other than putting in the hook for instance-ID. So, yes, as long as all of the users of a given mapping system and given instance ID use 10/ space in a consistent fashion for allocating IDs, it will work. But I don't see how a reader could understand that from the document. Yours, Joel On 10/23/2011 3:30 PM, Dino Farinacci wrote: >> By the way, it is interesting that Ari thought the EIDs would come out of 10/8 space. That is obviously wrong, but maybe this misunderstanding gives us a datapoint on the issue that I raised earlier about using the 10/8 addresses in examples. > > Ah, but they could. That is the point. Since they are not injected in the core, an EID-prefix in 10/8 space can be made unique to both the mapping database and the data-plane core by coupling it with an instance-ID. And the instance-ID need only be unique *per mapping database system*. > > Dino > > >> Jari >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Mon Oct 24 00:48:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AA421F8ADC for ; Mon, 24 Oct 2011 00:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deYtLzN5R0Ul for ; Mon, 24 Oct 2011 00:48:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE221F877F for ; Mon, 24 Oct 2011 00:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1698; q=dns/txt; s=iport; t=1319442530; x=1320652130; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fpGmnSwY82PN6S4uwNNL0OWl8DtXw0Ti+ztT1E97cgI=; b=FjbVnL+ZYKHaYEnnlHAn1iPvMIz7vlKePFZbq4eJLbVHt+1ruKwEdvmx JfjYQ3A0SKA7/nWPRD6hMU257YWHL1cmQC6ZhtG2z0k7dnLa18+FGuFKS 59vMUuks4XzPykffpnC+fcsdZYWt/RcO+mvuC55ZFSVCrYdkXV7dnZ9YJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGgXpU6rRDoG/2dsb2JhbABDqRCBBYFuAQEBAwEBAQEPAVsLBQsLGC4nMAYTIodeCJVFAZ1CBIdfYQSIBowDkXs X-IronPort-AV: E=Sophos;i="4.69,396,1315180800"; d="scan'208";a="9127693" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 24 Oct 2011 07:48:49 +0000 Received: from sjc-vpn7-205.cisco.com (sjc-vpn7-205.cisco.com [10.21.144.205]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9O7mnR6009625; Mon, 24 Oct 2011 07:48:49 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: <4EA47EE7.3030304@joelhalpern.com> Date: Mon, 24 Oct 2011 00:48:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E9FD553.1020209@nomadiclab.com> <4EA0381A.1070805@joelhalpern.com> <4EA046AC.90504@nomadiclab.com> <4EA40CC8.8000303@piuha.net> <8226DCC0-952D-471D-9331-81DFBBEC73E6@cisco.com> <4EA47EE7.3030304@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1251.1) Cc: lisp@ietf.org Subject: Re: [lisp] draft-ietf-lisp-15 review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 07:48:50 -0000 Instance-IDs are there (in the LCAF draft) to support LISP-VPNs. There = is nothing in the main specifications because VPNs are out of scope for = the LISP WG. Dino On Oct 23, 2011, at 1:53 PM, Joel M. Halpern wrote: > The problem I have with that view is that although it is accurate, it = is also bascially not explained. > For charter reasons, we left out any explanation of the private = spaces, other than putting in the hook for instance-ID. >=20 > So, yes, as long as all of the users of a given mapping system and = given instance ID use 10/ space in a consistent fashion for allocating = IDs, it will work. But I don't see how a reader could understand that = from the document. >=20 > Yours, > Joel >=20 > On 10/23/2011 3:30 PM, Dino Farinacci wrote: >>> By the way, it is interesting that Ari thought the EIDs would come = out of 10/8 space. That is obviously wrong, but maybe this = misunderstanding gives us a datapoint on the issue that I raised earlier = about using the 10/8 addresses in examples. >>=20 >> Ah, but they could. That is the point. Since they are not injected in = the core, an EID-prefix in 10/8 space can be made unique to both the = mapping database and the data-plane core by coupling it with an = instance-ID. And the instance-ID need only be unique *per mapping = database system*. >>=20 >> Dino >>=20 >>=20 >>> Jari >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 From terry.manderson@icann.org Mon Oct 24 18:11:40 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38DF11E8090 for ; Mon, 24 Oct 2011 18:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiUatXf6ILEC for ; Mon, 24 Oct 2011 18:11:40 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 15D0821F8A71 for ; Mon, 24 Oct 2011 18:11:40 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 24 Oct 2011 18:11:29 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 24 Oct 2011 18:11:26 -0700 Thread-Topic: WG meeting in Taipei, and call for agenda items. Thread-Index: AcyKEwY0EIuWDo6cnUuFIAwKor8L0QIn/5b6 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] WG meeting in Taipei, and call for agenda items. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:11:41 -0000 Just a reminder folks, Normally by this stage I have several requests in for speaking slots- so far only one has fronted. Cheers Terry On 14/10/11 11:46 AM, "Terry" wrote: > Folks, >=20 > The draft agenda has been released. >=20 > https://datatracker.ietf.org/meeting/82/agenda.html >=20 > In this IETF 82 draft agenda LISP has the slot: >=20 > THURSDAY, November 17, 2011 > 1740-1940 Afternoon Session III > 102 INT lisp > Locator/ID Separation Protocol WG >=20 > So the dates to keep in mind are: >=20 > 2011-10-17 (Monday): Working Group Chair approval for initial document > (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). >=20 > 2011-10-21 (Friday): Final agenda to be published. >=20 > 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PT (00:00 UTC). >=20 > 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT > (00:00 UTC). >=20 > 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:0= 0 > UTC). >=20 > 2011-11-04 (Friday): Early Bird registration and payment cut-off at 17:00 > PT (00:00 UTC). >=20 > 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 > UTC). >=20 > So I am now open to receive requests for time on the LISP agenda in Taipe= i. >=20 > Please get these to me by 2011-11-01 UTC 00:00:00. >=20 > Cheers > Terry From internet-drafts@ietf.org Tue Oct 25 12:14:37 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AE521F8A97; Tue, 25 Oct 2011 12:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbOoTQcN5odA; Tue, 25 Oct 2011 12:14:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41B21F87C9; Tue, 25 Oct 2011 12:14:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025191436.16707.94805.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 12:14:36 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:14:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-12.txt Pages : 19 Date : 2011-10-25 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint = ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-12.txt From terry.manderson@icann.org Wed Oct 26 22:10:49 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79B621F8A80 for ; Wed, 26 Oct 2011 22:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-tn-vg2h8aq for ; Wed, 26 Oct 2011 22:10:49 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id ECA6521F8A55 for ; Wed, 26 Oct 2011 22:10:48 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 26 Oct 2011 22:10:44 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Wed, 26 Oct 2011 22:10:42 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx5TIaevaA3w2i0T9e8wLpgRLaj2gDf8fv2AAF3XfAAjeHhlAPrGaUvAWwrCEc= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 05:10:50 -0000 WG hat on. This follow-up is initiated due to a recent observation gleaned from a presentation request for the Taipei meeting. While this draft charter does not preclude taking on work items specificall= y related to LISP VPN or LISP mobility, I think it's useful to tease out the questions and put them to the WG for discussion. Should LISP mobility be specifically included in the work plan? Should LISP VPN modalities be specifically included in the work plan? Cheers Terry On 20/10/11 9:23 AM, "Terry Manderson" wrote: > Hi All, >=20 > Joel and I bounced the following charter around and have also passed it i= n > front of AD's eyes. >=20 > You obviously have time to chew on this for a while before Taipei. >=20 > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > rekindled interest in scalable routing and addressing architectures for > the Internet. Among the many issues driving this renewed interest are > concerns about the scalability of the routing system and the impending > exhaustion of the IPv4 address space. Since the IAB workshop, several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "locator/identifier separation". >=20 > The basic idea behind the separation is that the Internet architecture > combines two functions, routing locators, (where you are attached to the > network) and identifiers (who you are) in one number space: The IP > address. Proponents of the separation architecture postulate that > splitting these functions apart will yield several advantages, including > improved scalability for the routing system. The separation aims to > decouple locators and identifiers, thus allowing for efficient > aggregation of the routing locator space and providing persistent > identifiers in the identifier space. >=20 > LISP supports the separation of the IPv4 and IPv6 address space > following a network-based map-and-encapsulate scheme (RFC 1955). In > LISP, both identifiers and locators are IP addresses. In LISP, > identifiers are composed of two parts: a "global" portion that uniquely > identifies a particular site and a "local" portion that identifies an > interface within a site. The "local" portion may be subdivided to > identify a particular network within the site. For a given identifier, > LISP maps the "global" portion of the identifier into a set of locators > that can be used by de-capsulation devices to reach the identified > interface; as a consequence a host would typically change identifiers > when it moves from one site to another or whenever it moves from one > subnet to another within an site. Typically, the same IP address will > not be used as an identifier > and locator in LISP. >=20 > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. >=20 > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. >=20 > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP. The working group will encourage and > support interoperable LISP implementations as well as defining > requirements for alternate mapping systems. The Working Group will also > develop security profiles for LISP and the various LISP mapping systems. >=20 > It is expected that the results of specifying, implementing, and testing > LISP will be fed to the general efforts at the IETF and IRTF (e.g., the > Routing Research Group) that attempts to understand which type of a > solution is optimal. The LISP WG is NOT chartered to develop the final > or standard solution for solving the routing scalability problem. Its > specifications are Experimental and labeled with accurate disclaimers > about their limitations and not fully understood implications for > Internet traffic. In addition, as these issues are understood, the > working group will analyze and document the implications of LISP on > Internet traffic, applications, routers, and security. This analysis > will explain what role LISP can play in scalable routing. The analysis > should also look at scalability and levels of state required for > encapsulation, decapsulation, liveness, and so on as well as the > manageability and operability of LISP. >=20 >=20 > Goals and Milestones >=20 > Jun 2012 Forward draft-ietf-lisp-mib to the IESG. > Jun 2012 Forward draft-ietf-lisp-sec to the IESG. > Jun 2012 Forward draft-ietf-lisp-deployment to the IESG. > Jun 2012 Forward a security proposal document (draft-ietf-lisp-threats= ) > to the IESG. >=20 > Dec 2013 Forward to the IESG an operational set of documents which sho= uld > include cache management and ETR synchronization > techniques inclusive of a cache management specification. >=20 > Jun 2014 Forward to the IESG an evaluation of the security threat to > cache management and ETR synchronization. > Jun 2014 Evaluate the applicability and coverage for LISP from a > reuse of SIDR technology. >=20 > Dec 2014 Re-charter or close >=20 >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu Oct 27 09:41:19 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74CA21F8484 for ; Thu, 27 Oct 2011 09:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6okt-r+VEQO for ; Thu, 27 Oct 2011 09:41:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A2E9A21F8492 for ; Thu, 27 Oct 2011 09:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=5023; q=dns/txt; s=iport; t=1319733670; x=1320943270; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fKiOJso2wFSadTh5cAYPVKarlYeRuf1KAnWhezL+Nto=; b=mfDaCQs9EXZ8brNckSq2dpnexIHffDPlL8TkLljKOOedPXv8NgGdm1Cv LbJrkme4huTBhKjqTC7xo9/Kd31PDVsTtBCMETaUiSStnMpDCzZxiCleA KdB3EN56EmS+K8SCLY27ryiMEqhOY9vNw8SOZH53h6qs6zxvGopv8Kxn1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFiJqU6rRDoJ/2dsb2JhbABDqV6BBYFyAQEBAwEBAQEPASc0CwULC0YnMAYTIodgCJZAAZ5aiB1hBIgGjAeRfw X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208";a="9742188" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 27 Oct 2011 16:41:09 +0000 Received: from sjc-vpn6-100.cisco.com (sjc-vpn6-100.cisco.com [10.21.120.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9RGf99C026414; Thu, 27 Oct 2011 16:41:09 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <4EA1FF24.7000902@piuha.net> Date: Thu, 27 Oct 2011 09:41:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24DD9327-60B2-4B35-A723-8E36C0AA82F9@cisco.com> References: <4EA1FF24.7000902@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 6) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:41:19 -0000 > Technical: >=20 > Overall, the security considerations section is a bit thin. I don't = think we need a lot of additional text, but there are some additional = pieces of information that need to be added. Some suggested text below. >=20 >> The nonce, coupled >> with the ITR accepting only solicited Map-Replies goes a long way >> toward providing decent authentication. >=20 > Hmm. This is not really descriptive. How about this instead: >=20 > The nonce, coupled with the ITR accepting only solicited Map-Replies = provides a basic level of security, in many ways similar to the security = experienced in the current Internet routing system. It is hard for = off-path attackers to launch attacks against these Lisp mechanisms, as = they do not have the nonce values. Sending a large number of packets to = accidentally find the right nonce value is possible, but would already = by itself be a denial-of-service attack. On-path attackers can perform = far more serious attacks, but on-path attackers can launch serious = attacks in the current Internet as well, including eavesdropping, = blocking or redirecting traffic. Lisp relies on the correct operation of = a BGP-based routing system [LISP-ALT], but so do the current Internet = routing mechanisms. I will add this text modulo the last sentence. I don't understand how = ALT plays into this. So I felt it was a random statement. Did you mean = LISP relies on a secure mapping database system? >> It is a good idea to have instrumentation in place >> to detect thrashing of the cache. Implementation experimentation >> will be used to determine which cache management strategies work >> best. >=20 > Yes, but I think we should also acknowledge that defending against = cache trashing attacks is hard: >=20 > It is a good idea to have instrumentation in place > to detect thrashing of the cache. Implementation experimentation > will be used to determine which cache management strategies work > best. In general, it is difficult to defend against cache trashing = attacks. >=20 > (Unless, of course, I'm missing some obvious schemes that show promise = of avoiding some of these issues against determined attackers. It is = also possible that if we described the situation in more detail, we'd be = able to describe the threats in a more rational way. E.g., outsiders can = cause some (limited) problems, insiders could cause big trouble but are = generally a bit more trusted, etc.) Schemes are work in progress and hence why we don't want to list them. = We had mentioned this before from the Nanog-triggered thread which we = moved over to the lisp@ietf.org list. >> This experimental specification does not address automated key >> management (AKM).BCP 107 = provides guidance in this area. >=20 > Yes, but I think we should include two additional important pieces of = information. 1. you need to acknowledge that you are not following BCP = 107 in this case, as it requires AKM under certain conditions (we are = within those conditions, right?). And 2) more importantly, you need to = document the implications of not providing AKM. Personally, I do not = necessarily consider it a panacea, and often the nonce etc. mechanisms = are far more important. In any case, the reader needs to understand what = we are losing without AKM. This text was created, accepted, and agreed upon from the security ADs. = So I dare not to touch it. >> 13. Network Management Considerations >>=20 >> Considerations for Network Management tools exist so the LISP >> protocol suite can be operationally managed. The mechanisms can be >> found in [LISP-MIB] and [LISP-LIG]. >=20 > It is good that you point to these specifications. I wonder if there = are additional things you should say in this spec, however. Are there = parameters that Lisp needs to operate? Are they and their default values = described in LISP-MIB? There are many good pieces of advice about the = management of a Lisp network in previous sections, should there be some = kind of summary/pointers for these here as well? All described in the LISP-MIB, which is still ongoing. I will make sure = we put any configuration guidelines in there. > Editorial: >=20 >> Return- Routability >=20 > s/- /-/ Fixed. >> datragram. If a LISP encapsulated packet arrives at an ETR, it = MAY >>=20 >=20 > datagram Fixed. >> system [KARP = ], [RPKI = ], >> [BGP-SEC = ], [LISP-SEC = ], >=20 > s/[LISP-SEC],/[LISP-SEC]./ Fixed. Dino >=20 > Jari >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu Oct 27 09:56:30 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8A921F861E for ; Thu, 27 Oct 2011 09:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZymAJtd7qA+m for ; Thu, 27 Oct 2011 09:56:29 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B055821F85B8 for ; Thu, 27 Oct 2011 09:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=10532; q=dns/txt; s=iport; t=1319734589; x=1320944189; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nds5kF7oGMJGpHB6ejcCy67XzMqKax4iBMe4FjCeV3Y=; b=MTA3UNr5F8B9mJQ10rS1pY2l5RGnfn3oGhiB6N6PZQ8E98yft+kyRmxj vpxU+p46v5FLd801XpNUYY9TIRipltUv0HV9twxpKoWAyJNDkS4Wsmayg iD38JvtT2ZsCjml7FXEd/ZTk4bec7hV3JRNzubh4wgHH/zLthRsWSItI8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH2MqU6rRDoG/2dsb2JhbABDqV+BBYFyAQEBAwESAVgOBQsLRlcGHBmHYAiWOgGeV4gdYQSIBowHijeHSA X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208";a="10700589" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 27 Oct 2011 16:56:29 +0000 Received: from sjc-vpn6-100.cisco.com (sjc-vpn6-100.cisco.com [10.21.120.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9RGuTVi018410; Thu, 27 Oct 2011 16:56:29 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Dino Farinacci In-Reply-To: <4EA32F7B.1060904@piuha.net> Date: Thu, 27 Oct 2011 09:54:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A8DA48E-6A42-4976-9A2D-6792D9C254DD@cisco.com> References: <4EA1FF24.7000902@piuha.net> <4EA32F7B.1060904@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:56:30 -0000 > This is the last part of my review, as far as the actual document = contents go. I will send another summary e-mail. >=20 > Technical: >=20 >> 14.1. LISP Address Type Codes >>=20 >> Instance ID type codes have a range from 0 to 15, of which 0 and 1 >> have been allocated [LCAF]. New Type Codes MUST be allocated >> starting at 2. Type Codes 2 - 10 are to be assigned by IETF = Review. >> Type Codes 11 - 15 are available on a First Come First Served = policy. >>=20 >> The following codes have been allocated: >>=20 >> Type 0: Null Body Type >>=20 >> Type 1: AFI List Type >>=20 >> See [LCAF] for details for other possible unapproved address >> encodings. The unapproved LCAF encodings are an area for further >> study and experimentation. >=20 > To begin with, I did not understand this definition. I'm trying to = understand where the LCAF draft actually makes the instance ID = allocations, and I can't see it. In addition, the "Null Body Type" = string only appears twice in this and the LCAF draft, and neither = occurrence explains what it is. I think something is missing here. The source-EID in an RLOC-probe may contain a null body encoding. = Because there was no data packet that triggered this Map-Request. I will = add that to the RLOC-probe section. Instance-ID is defined in the LCAF draft as Type 2. Here is the packet = format: Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [LISP] for details. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. > Finally, I do not understand why this section is in -lisp. The string = "LISP Address Type Code" does not appear in the rest of the document = AFAICT. The allocations in the LCAF draft seem to be inside a format = defined in that draft. Shouldn't the IANA allocations and the creation = of the registry be in that draft as well? This seems particularly = important, given that the list of types in -lisp does not match the list = in -lcaf. We (the working group) have decided to put the in-charter values in this = draft and keep the other values in the LCAF draft. So that is why values = 0 and 1 are in this draft. Since instance-ID is part of a VPN use-case, = this is why it is the next value assigned in the LCAF draft. We received direction from Terry on this since he is expert in = registries et al. > Suggested edit: delete this section. >=20 >>=20 >> o The following policies are used here with the meanings defined = in >> BCP 26 : "Specification = Required", "IETF Consensus", "Experimental >> Use", "First Come First Served". >>=20 >=20 > None of these terms are used in the rest of the document. (But see = below.) That is Terry text and seems to be standard. >> 14. IANA Considerations >=20 > This sections makes the right allocations from other, already existing = registries (like UDP port numbers). But it should also define what the = policies are for allocating new values with the various new number = spaces that Lisp introduces: >=20 > - flags > - type > - reserved > - act > - unused flags > - =85 Terry needs to respond to this. >> [BGP-SEC] Lepinski, M., "An Overview of BGPSEC", >> draft-lepinski-bgpsec-overview-00.txt = = (work in progress), >> March 2011. >>=20 >> [KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication = for >> Routing Protocols (KARP)Design Guidelines", >> draft-ietf-karp-design-guide-02.txt = (work = in progress), >> March 2011. >=20 >> [RPKI] Lepinski, M., "An Infrastructure to Support Secure >> Internet Routing",draft-ietf-sidr-arch-13.txt = (work in >> progress), February 2011. >=20 >=20 > I have a hard time seeing why these should be normative references. = They are just mentioned as work that is in progress in securing the = routing system. You do not need to read these to implement LISP as = specified in this document, or even to understand what Lisp is or its = impacts. Can yo and the chairs argue over this and make a decision. Then I will = put it where you have agreed. >> [RFC1034] Mockapetris, P., "Domain names - concepts and = facilities", >> STD 13,RFC 1034 , = November 1987. >>=20 >=20 > If you look at the way this is referenced from the text, it is clear = that this should be a non-normative reference. >=20 > The host obtains > a destination EID the same way it obtains an destination address > today, for example through a Domain Name System (DNS) [RFC1034] > lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. >=20 >> [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, >> A., Peterson, J., Sparks, R., Handley, M., and E. >> Schooler, "SIP: Session Initiation Protocol", RFC 3261, >> June 2002. >=20 > Same as above. >=20 >> [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. >> Traina, "Generic Routing Encapsulation (GRE)",RFC 2784 = , >> March 2000. >>=20 >=20 > If you look at the way this is referenced from the text, I think this = should be a non-normative reference. >=20 > o On an ITR, prepending a new IP header consists of adding more > bytes to a MAC rewrite string and prepending the string as part = of > the outgoing encapsulation procedure. Routers that support GRE > tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already > support this action. >=20 > GRE is here use as an example, not as normative behavior. >=20 >> [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains >> via IPv4 Clouds",RFC 3056 = , February 2001. >>=20 >=20 > Same as above. >=20 >>=20 >> [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route >> Optimization for Mobile IPv6",RFC 4866 = , May 2007. >=20 > I think this one can be non-normative or even be removed, depending on = how the mobility section rewrite goes. >=20 >>=20 >> [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB >> Workshop on Routing and Addressing",RFC 4984 = , >> September 2007. >>=20 >=20 > Background. Non-normative. >=20 >> [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS = FAMILY >> NUMBERS >> http://www.iana.org/assignments/address-family-numbers. >>=20 >> [AFI-REGISTRY] >> IANA, "Address Family Indicators (AFIs)", ADDRESS = FAMILY >> NUMBER registryhttp://www.iana.org/assignments/ >> address-family-numbers/ >> address-family-numbers.xml#address-family-numbers-1. >=20 > Is there really no better reference for this, an RFC perhaps? >=20 > I wish there were... and that RFC could be put in to the = normative-reference section. If there is no suitable RFC I'm fine with = the current two references as-is. >=20 >> [INTERWORK] >> Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, >> "Interworking LISP with IPv4 and IPv6", >> draft-ietf-lisp-interworking-02.txt = (work = in progress). >>=20 >=20 > I think this one should be normative. This is such a key piece of work = to understanding Lisp, and the text seems to treat it as if it is a = normative part. For instance: >=20 > Proxy ITR (PITR): A PITR is also known as a PTR is defined and > described in [INTERWORK], a PITR acts like an ITR but does so on > behalf of non-LISP sites which send packets to destinations at > LISP sites. >=20 >> [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", >> draft-ietf-lisp-ms-09.txt = (work in = progress). >>=20 >=20 > Isn't this normative as well? Here's an example of how the text refers = to it: >=20 > Map-Requests can also be LISP encapsulated using UDP destination port > 4342 with a LISP type value set to "Encapsulated Control Message", > when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are > LISP encapsulated the same way from a Map-Server to an ETR. Details > on encapsulated Map-Requests and Map-Resolvers can be found in > [LISP-MS]. You guys decide where all of this should go (from my last comment to = this line), and I'll make one change. >> [VERSIONING] >> Iannone, L., Saucez, D., and O. Bonaventure, "LISP = Mapping >> Versioning",draft-ietf-lisp-map-versioning-01.txt = = (work >> in progress). >>=20 >=20 > I suspect this is normative, too. See Section 6.6.3. >=20 > Jari Dino From dino@cisco.com Thu Oct 27 10:04:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A6721F8BB1 for ; Thu, 27 Oct 2011 10:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pks26OlSrJId for ; Thu, 27 Oct 2011 10:04:41 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A030621F8B9F for ; Thu, 27 Oct 2011 10:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2049; q=dns/txt; s=iport; t=1319735081; x=1320944681; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lfvVkobO3yLMYcMoue8kUzFEPQ1ePJA+bTxLRu9nKn8=; b=dbQPp/j8GA9Z4UWNL6QiF3xP+d7fe0pdYywrTsHlLJVDErmQkDGAqMd8 qYmd8gsrmx/oEiKXWeCdKLKnYgpHZGquNIc/sg7sIf0RklIxTGZjc0Abr +8N3H9BW2qWUFwCi4PSMHFy+hud6uB6x2o1ce3c2Vca2oXLJU9eEHfjSh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPeNqU6rRDoG/2dsb2JhbABDqV+BBYFyAQEBBBIBZhALRlcGNZ4mAZ5XiB1hBIgGjAeFNoxJ X-IronPort-AV: E=Sophos;i="4.69,414,1315180800"; d="scan'208";a="10723401" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 27 Oct 2011 17:04:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9RH4fP3024893; Thu, 27 Oct 2011 17:04:41 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 10:04:41 -0700 Received: from sjc-vpn6-100.cisco.com ([10.21.120.100]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 10:04:40 -0700 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Dino Farinacci In-Reply-To: <4EA404E4.7040302@piuha.net> Date: Thu, 27 Oct 2011 10:04:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F86A59E-EECF-4662-A1E6-5E0E1E19C739@cisco.com> References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> <4EA404E4.7040302@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) X-OriginalArrivalTime: 27 Oct 2011 17:04:41.0015 (UTC) FILETIME=[84426470:01CC94CA] Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:04:42 -0000 On Oct 23, 2011, at 5:13 AM, Jari Arkko wrote: >>>> o When a router originates packets it may use as a source = address >>>> either an EID or RLOC. >>> You should state somewhere what the manageability requirements are = for making this happen, or if hardcoded policies are sufficient (e.g., = iBGP vs. eBGP use of addresses). Does this require additional = functionality for RFC 3484 style source address selection, or can you = cope with existing functionality? >> It does not. The same requirements for originating IP packets has not = changed. If it is stated that the outgoing interface's address is used = as the source address, then whatever namespace the address belongs to is = used. >>=20 >>> Note: I'm not asking for any new functionality, just a statement = about the expectations. >> No expectations. ;-) >=20 > Fine. Can we state that? At least this reader was wondering if a = router needed something special to be handle the selection. I'm of = course very glad that the answer is no. I added a sentence to the first bullet. >>=20 >>> Second, I wish you would have specified the source address checks = better. Are there situations where you would NOT want to make a pretty = strict test, i.e., that source EID maps to source RLOC? >> Because this is work still in progress. >=20 > I understand that, but accepting tunnel packets without this = validation just seems pretty open to attacks. And this is not just about = LISP. In general, every IETF technique that comes out may have = vulnerabilities that cause trouble not just for that technology but also = for other things in the Internet. I'm worried that this coyld be an = attack vector to attack other things in the Internet in the future. Can = we agree on a middle ground, e.g., make the MAY a SHOULD? I'd be much = happier with that=85 I hear you loud and clear. But no one may implement this beacuse it is = hard and expensive. We need to solve it another way and we are not ready = to document it yet. Dino= From jmh@joelhalpern.com Thu Oct 27 10:52:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1C11E807F for ; Thu, 27 Oct 2011 10:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.124 X-Spam-Level: X-Spam-Status: No, score=-103.124 tagged_above=-999 required=5 tests=[AWL=1.141, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzyPkjGa3y9d for ; Thu, 27 Oct 2011 10:52:41 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 21ECC11E8073 for ; Thu, 27 Oct 2011 10:52:39 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) by morbo.tigertech.net (Postfix) with ESMTP id C5E23CD0BD for ; Thu, 27 Oct 2011 10:52:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 797EC360B2D; Thu, 27 Oct 2011 10:52:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from [10.10.10.100] (pool-71-161-50-191.clppva.btas.verizon.net [71.161.50.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 29CE83603B4; Thu, 27 Oct 2011 10:52:36 -0700 (PDT) Message-ID: <4EA99A60.2040407@joelhalpern.com> Date: Thu, 27 Oct 2011 13:52:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4EA1FF24.7000902@piuha.net> <4EA32F7B.1060904@piuha.net> <6A8DA48E-6A42-4976-9A2D-6792D9C254DD@cisco.com> In-Reply-To: <6A8DA48E-6A42-4976-9A2D-6792D9C254DD@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp- reference categories X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:52:42 -0000 Dino, are any of these ones we asked you to move around earlier for some reason? (I want to try to avoid saying A, no B, no A...) Assuming these were not previously moved for some reason, I am happy with most of Jari's suggests. I do think referencing the registry for AFIs is the right thing. Referencing the RFC that defines the registry would merely cause an indirection, since what people generally need is the values. If they need the underlying definition, they can follow the links from there. I do not think the Interworking draft should be a normative reference. It is needed for understanding deployment with interworking. But it is not needed for understanding the base LISP spec. Yours, Joel On 10/27/2011 12:54 PM, Dino Farinacci wrote: ... > Terry needs to respond to this. > >>> [BGP-SEC] Lepinski, M., "An Overview of BGPSEC", >>> draft-lepinski-bgpsec-overview-00.txt (work in progress), >>> March 2011. >>> >>> [KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for >>> Routing Protocols (KARP)Design Guidelines", >>> draft-ietf-karp-design-guide-02.txt (work in progress), >>> March 2011. >> >>> [RPKI] Lepinski, M., "An Infrastructure to Support Secure >>> Internet Routing",draft-ietf-sidr-arch-13.txt (work in >>> progress), February 2011. >> >> >> I have a hard time seeing why these should be normative references. They are just mentioned as work that is in progress in securing the routing system. You do not need to read these to implement LISP as specified in this document, or even to understand what Lisp is or its impacts. > > Can yo and the chairs argue over this and make a decision. Then I will put it where you have agreed. > >>> [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", >>> STD 13,RFC 1034, November 1987. >>> >> >> If you look at the way this is referenced from the text, it is clear that this should be a non-normative reference. >> >> The host obtains >> a destination EID the same way it obtains an destination address >> today, for example through a Domain Name System (DNS) [RFC1034] >> lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. >> >>> [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, >>> A., Peterson, J., Sparks, R., Handley, M., and E. >>> Schooler, "SIP: Session Initiation Protocol", RFC 3261, >>> June 2002. >> >> Same as above. >> >>> [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. >>> Traina, "Generic Routing Encapsulation (GRE)",RFC 2784, >>> March 2000. >>> >> >> If you look at the way this is referenced from the text, I think this should be a non-normative reference. >> >> o On an ITR, prepending a new IP header consists of adding more >> bytes to a MAC rewrite string and prepending the string as part of >> the outgoing encapsulation procedure. Routers that support GRE >> tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already >> support this action. >> >> GRE is here use as an example, not as normative behavior. >> >>> [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains >>> via IPv4 Clouds",RFC 3056, February 2001. >>> >> >> Same as above. >> >>> >>> [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route >>> Optimization for Mobile IPv6",RFC 4866, May 2007. >> >> I think this one can be non-normative or even be removed, depending on how the mobility section rewrite goes. >> >>> >>> [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB >>> Workshop on Routing and Addressing",RFC 4984, >>> September 2007. >>> >> >> Background. Non-normative. >> >>> [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY >>> NUMBERS >>> http://www.iana.org/assignments/address-family-numbers. >>> >>> [AFI-REGISTRY] >>> IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY >>> NUMBER registryhttp://www.iana.org/assignments/ >>> address-family-numbers/ >>> address-family-numbers.xml#address-family-numbers-1. >> >> Is there really no better reference for this, an RFC perhaps? >> >> I wish there were... and that RFC could be put in to the normative-reference section. If there is no suitable RFC I'm fine with the current two references as-is. >> >>> [INTERWORK] >>> Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, >>> "Interworking LISP with IPv4 and IPv6", >>> draft-ietf-lisp-interworking-02.txt (work in progress). >>> >> >> I think this one should be normative. This is such a key piece of work to understanding Lisp, and the text seems to treat it as if it is a normative part. For instance: >> >> Proxy ITR (PITR): A PITR is also known as a PTR is defined and >> described in [INTERWORK], a PITR acts like an ITR but does so on >> behalf of non-LISP sites which send packets to destinations at >> LISP sites. >> >>> [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", >>> draft-ietf-lisp-ms-09.txt (work in progress). >>> >> >> Isn't this normative as well? Here's an example of how the text refers to it: >> >> Map-Requests can also be LISP encapsulated using UDP destination port >> 4342 with a LISP type value set to "Encapsulated Control Message", >> when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are >> LISP encapsulated the same way from a Map-Server to an ETR. Details >> on encapsulated Map-Requests and Map-Resolvers can be found in >> [LISP-MS]. > > You guys decide where all of this should go (from my last comment to this line), and I'll make one change. > >>> [VERSIONING] >>> Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping >>> Versioning",draft-ietf-lisp-map-versioning-01.txt (work >>> in progress). >>> >> >> I suspect this is normative, too. See Section 6.6.3. >> >> Jari > > Dino > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jmh@joelhalpern.com Thu Oct 27 10:55:20 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77631F0C36 for ; Thu, 27 Oct 2011 10:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.195 X-Spam-Level: X-Spam-Status: No, score=-102.195 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smw4bl49YEUi for ; Thu, 27 Oct 2011 10:55:20 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 68B961F0C34 for ; Thu, 27 Oct 2011 10:55:20 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) by morbo.tigertech.net (Postfix) with ESMTP id 414A1CD0C6 for ; Thu, 27 Oct 2011 10:55:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 32262360B1F; Thu, 27 Oct 2011 10:55:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from [10.10.10.100] (pool-71-161-50-191.clppva.btas.verizon.net [71.161.50.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id B2A7E361C4D; Thu, 27 Oct 2011 10:55:16 -0700 (PDT) Message-ID: <4EA99AFF.3010507@joelhalpern.com> Date: Thu, 27 Oct 2011 13:55:11 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> <4EA404E4.7040302@piuha.net> <5F86A59E-EECF-4662-A1E6-5E0E1E19C739@cisco.com> In-Reply-To: <5F86A59E-EECF-4662-A1E6-5E0E1E19C739@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:55:21 -0000 Given that, as far as I can tell, failing to perform the source checks leaves the site using the weak ETR at risk, but does not harm anyone else, and given that this is experimental, it seems sufficient to leave the text the way it is. Yours, Joel On 10/27/2011 1:04 PM, Dino Farinacci wrote: > On Oct 23, 2011, at 5:13 AM, Jari Arkko wrote: ... >>>> Second, I wish you would have specified the source address checks better. Are there situations where you would NOT want to make a pretty strict test, i.e., that source EID maps to source RLOC? >>> Because this is work still in progress. >> >> I understand that, but accepting tunnel packets without this validation just seems pretty open to attacks. And this is not just about LISP. In general, every IETF technique that comes out may have vulnerabilities that cause trouble not just for that technology but also for other things in the Internet. I'm worried that this coyld be an attack vector to attack other things in the Internet in the future. Can we agree on a middle ground, e.g., make the MAY a SHOULD? I'd be much happier with that… > > I hear you loud and clear. But no one may implement this beacuse it is hard and expensive. We need to solve it another way and we are not ready to document it yet. > > Dino From jari.arkko@piuha.net Thu Oct 27 13:24:16 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A356B21F8B46 for ; Thu, 27 Oct 2011 13:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUDl4QNfOZGA for ; Thu, 27 Oct 2011 13:24:16 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABEA21F8AFE for ; Thu, 27 Oct 2011 13:24:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0C0462CC44; Thu, 27 Oct 2011 23:24:14 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9Vk1GVc+bvD; Thu, 27 Oct 2011 23:24:13 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 146892CC34; Thu, 27 Oct 2011 23:24:13 +0300 (EEST) Message-ID: <4EA9BDEC.8080605@piuha.net> Date: Thu, 27 Oct 2011 23:24:12 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> <4EA404E4.7040302@piuha.net> <5F86A59E-EECF-4662-A1E6-5E0E1E19C739@cisco.com> <4EA99AFF.3010507@joelhalpern.com> In-Reply-To: <4EA99AFF.3010507@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 20:24:16 -0000 Joel, Dino: Not doing source address checks is not hurting just you as a receiver, but also whoever gets the response packet. It is hurting the rest of the Internet. Basically, a way to circumvent all the ingress filtering that exists in the Internet today. Note that I was not suggesting a MUST. I understand that the implementation may be costly, and that is why I was suggesting a SHOULD. Jari On 27.10.2011 20:55, Joel M. Halpern wrote: > Given that, as far as I can tell, failing to perform the source checks leaves the site using the weak ETR at risk, but does not harm anyone else, > and given that this is experimental, > it seems sufficient to leave the text the way it is. > > Yours, > Joel > > On 10/27/2011 1:04 PM, Dino Farinacci wrote: >> On Oct 23, 2011, at 5:13 AM, Jari Arkko wrote: > ... >>>>> Second, I wish you would have specified the source address checks better. Are there situations where you would NOT want to make a pretty strict test, i.e., that source EID maps to source RLOC? >>>> Because this is work still in progress. >>> >>> I understand that, but accepting tunnel packets without this validation just seems pretty open to attacks. And this is not just about LISP. In general, every IETF technique that comes out may have vulnerabilities that cause trouble not just for that technology but also for other things in the Internet. I'm worried that this coyld be an attack vector to attack other things in the Internet in the future. Can we agree on a middle ground, e.g., make the MAY a SHOULD? I'd be much happier with that… >> >> I hear you loud and clear. But no one may implement this beacuse it is hard and expensive. We need to solve it another way and we are not ready to document it yet. >> >> Dino > > From dino@cisco.com Thu Oct 27 13:43:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351F21F0C43 for ; Thu, 27 Oct 2011 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfykyoR7CrXv for ; Thu, 27 Oct 2011 13:43:49 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2AA1F0C41 for ; Thu, 27 Oct 2011 13:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2008; q=dns/txt; s=iport; t=1319748229; x=1320957829; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jrksesjyj/UCX5sPMzL0UiO1ak2/Ko7wDfEEZk6tK+4=; b=UM8ozNwYubdLDmAM9PU1lzfy1LxkUA6VVfyDHZmuXlIApDelWnAPWFhZ p9xiqDSGM9RBKduCI4WqOibXzmm0Gqq8FJeAGmYAkDwm7JVYs55xM9pwC gw7fXVPxIMJotdtkKkj57HJYoEPu5Z2zEiL5+qc8oeZZRyY9pjdn4y/lN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FADjBqU6rRDoI/2dsb2JhbABDp1GCD4EFgXIBAQEDARIBZgULCxguVwY1h2CWPQGeRogdYQSIBowHhS2MUg X-IronPort-AV: E=Sophos;i="4.69,414,1315180800"; d="scan'208";a="10784403" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Oct 2011 20:43:49 +0000 Received: from [10.34.153.93] ([10.34.153.93]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9RKhnFb021460; Thu, 27 Oct 2011 20:43:49 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Dino Farinacci In-Reply-To: <4EA9BDEC.8080605@piuha.net> Date: Thu, 27 Oct 2011 13:43:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <446F2185-C01A-4AD9-972D-960FBC45FB7B@cisco.com> References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> <4EA404E4.7040302@piuha.net> <5F86A59E-EECF-4662-A1E6-5E0E1E19C739@cisco.com> <4EA99AFF.3010507@joelhalpern.com> <4EA9BDEC.8080605@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 2) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 20:43:50 -0000 I'll change to SHOULD. You make good points. Dino On Oct 27, 2011, at 1:24 PM, Jari Arkko wrote: > Joel, Dino: >=20 > Not doing source address checks is not hurting just you as a receiver, = but also whoever gets the response packet. It is hurting the rest of the = Internet. Basically, a way to circumvent all the ingress filtering that = exists in the Internet today. >=20 > Note that I was not suggesting a MUST. I understand that the = implementation may be costly, and that is why I was suggesting a SHOULD. >=20 > Jari >=20 > On 27.10.2011 20:55, Joel M. Halpern wrote: >> Given that, as far as I can tell, failing to perform the source = checks leaves the site using the weak ETR at risk, but does not harm = anyone else, >> and given that this is experimental, >> it seems sufficient to leave the text the way it is. >>=20 >> Yours, >> Joel >>=20 >> On 10/27/2011 1:04 PM, Dino Farinacci wrote: >>> On Oct 23, 2011, at 5:13 AM, Jari Arkko wrote: >> ... >>>>>> Second, I wish you would have specified the source address checks = better. Are there situations where you would NOT want to make a pretty = strict test, i.e., that source EID maps to source RLOC? >>>>> Because this is work still in progress. >>>>=20 >>>> I understand that, but accepting tunnel packets without this = validation just seems pretty open to attacks. And this is not just about = LISP. In general, every IETF technique that comes out may have = vulnerabilities that cause trouble not just for that technology but also = for other things in the Internet. I'm worried that this coyld be an = attack vector to attack other things in the Internet in the future. Can = we agree on a middle ground, e.g., make the MAY a SHOULD? I'd be much = happier with that=85 >>>=20 >>> I hear you loud and clear. But no one may implement this beacuse it = is hard and expensive. We need to solve it another way and we are not = ready to document it yet. >>>=20 >>> Dino >>=20 >>=20 >=20 From Fred.L.Templin@boeing.com Fri Oct 28 09:31:19 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCA921F8753 for ; Fri, 28 Oct 2011 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.139 X-Spam-Level: X-Spam-Status: No, score=-7.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BD5YXwij8Vs for ; Fri, 28 Oct 2011 09:31:18 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 81EEC21F8610 for ; Fri, 28 Oct 2011 09:31:18 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p9SGVAsi024167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Oct 2011 11:31:13 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p9SGV9Gr018406; Fri, 28 Oct 2011 09:31:10 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p9SGV6Yd018252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Oct 2011 09:31:09 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 28 Oct 2011 09:31:08 -0700 From: "Templin, Fred L" To: "lisp@ietf.org" Date: Fri, 28 Oct 2011 09:31:07 -0700 Thread-Topic: recursive encapsulation terminology Thread-Index: AcyU6Tj6ALeUPgCZQ+qb6AJZjRbg0gAoKnjQ Message-ID: References: <4E86486A.6010402@piuha.net> <4E8A30DA.5080706@piuha.net> <4EA404E4.7040302@piuha.net> <5F86A59E-EECF-4662-A1E6-5E0E1E19C739@cisco.com> <4EA99AFF.3010507@joelhalpern.com> <4EA9BDEC.8080605@piuha.net> <446F2185-C01A-4AD9-972D-960FBC45FB7B@cisco.com> In-Reply-To: <446F2185-C01A-4AD9-972D-960FBC45FB7B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-lisp@tools.ietf.org" Subject: [lisp] recursive encapsulation terminology X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 16:31:19 -0000 LISP introduces the term "reencapsulating", and this is a useful term with practical application. However, LISP also uses the term "recursive (enapsulation)" in a way that is different than its uses elsewhere such as in RFC2473. What LISP is calling "recursive (encapsulation)" is called "nested encapsulation" in RFC2473, and it has many practical applications such as for traffic engineering. Indeed, the term "nested" is also used in other practical contexts, including "Nested Nemo". But, RFC2473 goes on to define "recursive encapsulation" as a harmful condition that arises from misconfigurations, routing loops, etc. In the RFC2473 terminology, nested encapsulation is a useful scenario that has a healthy terminating condition, whereas recursive encapsulation is unhealthy and, if left unchecked, results in an infinite loop. I would like to suggest that the LISP authors consider altering their terminology to use the term "nested" to refer to a healthy application of multiple layers of encapsulation and to use the term "recursive" to refer to an unhealthy application, i.e., the same as the terms are used elsewhere. Thanks - Fred fred.l.templin@boeing.com From acabello@ac.upc.edu Fri Oct 28 10:05:23 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD5F21F8663 for ; Fri, 28 Oct 2011 10:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPwRqiJ8skla for ; Fri, 28 Oct 2011 10:05:22 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id C21E321F85A8 for ; Fri, 28 Oct 2011 10:05:21 -0700 (PDT) Received: from [147.83.34.151] (dync-34-151.ac.upc.es [147.83.34.151]) by gw.ac.upc.edu (Postfix) with ESMTP id 47AE46B01A4 for ; Fri, 28 Oct 2011 19:05:19 +0200 (CEST) Message-ID: <4EAAE0B2.5060202@ac.upc.edu> Date: Fri, 28 Oct 2011 19:04:50 +0200 From: Albert Cabellos User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111019 Thunderbird/8.0 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:05:23 -0000 Hi, On 27/10/2011 7:10, Terry Manderson wrote: > WG hat on. > > This follow-up is initiated due to a recent observation gleaned from a > presentation request for the Taipei meeting. > > While this draft charter does not preclude taking on work items specifically > related to LISP VPN or LISP mobility, I think it's useful to tease out the > questions and put them to the WG for discussion. > > Should LISP mobility be specifically included in the work plan? > I would like to point out that we have a small but growing community of people interested into LISPmob, we open-sourced the code 1.5 months ago. Albert > Should LISP VPN modalities be specifically included in the work plan? > > Cheers > Terry > > On 20/10/11 9:23 AM, "Terry Manderson" wrote: > >> Hi All, >> >> Joel and I bounced the following charter around and have also passed it in >> front of AD's eyes. >> >> You obviously have time to chew on this for a while before Taipei. >> >> The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) >> rekindled interest in scalable routing and addressing architectures for >> the Internet. Among the many issues driving this renewed interest are >> concerns about the scalability of the routing system and the impending >> exhaustion of the IPv4 address space. Since the IAB workshop, several >> proposals have emerged which attempt to address the concerns expressed >> there and elsewhere. In general, these proposals are based on the >> "locator/identifier separation". >> >> The basic idea behind the separation is that the Internet architecture >> combines two functions, routing locators, (where you are attached to the >> network) and identifiers (who you are) in one number space: The IP >> address. Proponents of the separation architecture postulate that >> splitting these functions apart will yield several advantages, including >> improved scalability for the routing system. The separation aims to >> decouple locators and identifiers, thus allowing for efficient >> aggregation of the routing locator space and providing persistent >> identifiers in the identifier space. >> >> LISP supports the separation of the IPv4 and IPv6 address space >> following a network-based map-and-encapsulate scheme (RFC 1955). In >> LISP, both identifiers and locators are IP addresses. In LISP, >> identifiers are composed of two parts: a "global" portion that uniquely >> identifies a particular site and a "local" portion that identifies an >> interface within a site. The "local" portion may be subdivided to >> identify a particular network within the site. For a given identifier, >> LISP maps the "global" portion of the identifier into a set of locators >> that can be used by de-capsulation devices to reach the identified >> interface; as a consequence a host would typically change identifiers >> when it moves from one site to another or whenever it moves from one >> subnet to another within an site. Typically, the same IP address will >> not be used as an identifier >> and locator in LISP. >> >> LISP requires no changes to end-systems or to most routers. LISP aims >> for an incrementally deployable protocol. >> >> A number of approaches are being looked at in parallel in other >> contexts. The IRTF RRG examined several proposals, some of which were >> published as IRTF-track Experimental RFCs. >> >> The LISP WG is chartered to work on the LISP base protocol and any items >> which directly impact LISP. The working group will encourage and >> support interoperable LISP implementations as well as defining >> requirements for alternate mapping systems. The Working Group will also >> develop security profiles for LISP and the various LISP mapping systems. >> >> It is expected that the results of specifying, implementing, and testing >> LISP will be fed to the general efforts at the IETF and IRTF (e.g., the >> Routing Research Group) that attempts to understand which type of a >> solution is optimal. The LISP WG is NOT chartered to develop the final >> or standard solution for solving the routing scalability problem. Its >> specifications are Experimental and labeled with accurate disclaimers >> about their limitations and not fully understood implications for >> Internet traffic. In addition, as these issues are understood, the >> working group will analyze and document the implications of LISP on >> Internet traffic, applications, routers, and security. This analysis >> will explain what role LISP can play in scalable routing. The analysis >> should also look at scalability and levels of state required for >> encapsulation, decapsulation, liveness, and so on as well as the >> manageability and operability of LISP. >> >> >> Goals and Milestones >> >> Jun 2012 Forward draft-ietf-lisp-mib to the IESG. >> Jun 2012 Forward draft-ietf-lisp-sec to the IESG. >> Jun 2012 Forward draft-ietf-lisp-deployment to the IESG. >> Jun 2012 Forward a security proposal document (draft-ietf-lisp-threats) >> to the IESG. >> >> Dec 2013 Forward to the IESG an operational set of documents which should >> include cache management and ETR synchronization >> techniques inclusive of a cache management specification. >> >> Jun 2014 Forward to the IESG an evaluation of the security threat to >> cache management and ETR synchronization. >> Jun 2014 Evaluate the applicability and coverage for LISP from a >> reuse of SIDR technology. >> >> Dec 2014 Re-charter or close >> >> >> Cheers >> Terry >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jari.arkko@piuha.net Sun Oct 30 14:14:46 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977EE21F8515 for ; Sun, 30 Oct 2011 14:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-Cu6+IDbt4O for ; Sun, 30 Oct 2011 14:14:45 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 842D121F84CE for ; Sun, 30 Oct 2011 14:14:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D37272CC39; Sun, 30 Oct 2011 23:14:38 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fol3CgssvkC4; Sun, 30 Oct 2011 23:14:36 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 389F02CC34; Sun, 30 Oct 2011 23:14:36 +0200 (EET) Message-ID: <4EADBE3A.9080900@piuha.net> Date: Sun, 30 Oct 2011 23:14:34 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4EA1FF24.7000902@piuha.net> <24DD9327-60B2-4B35-A723-8E36C0AA82F9@cisco.com> In-Reply-To: <24DD9327-60B2-4B35-A723-8E36C0AA82F9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 6) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 21:14:46 -0000 Dino, >> Technical: >> >> Overall, the security considerations section is a bit thin. I don't think we need a lot of additional text, but there are some additional pieces of information that need to be added. Some suggested text below. >> >>> The nonce, coupled >>> with the ITR accepting only solicited Map-Replies goes a long way >>> toward providing decent authentication. >> Hmm. This is not really descriptive. How about this instead: >> >> The nonce, coupled with the ITR accepting only solicited Map-Replies provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these Lisp mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible, but would already by itself be a denial-of-service attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking or redirecting traffic. Lisp relies on the correct operation of a BGP-based routing system [LISP-ALT], but so do the current Internet routing mechanisms. > I will add this text modulo the last sentence. I don't understand how ALT plays into this. So I felt it was a random statement. OK > Did you mean LISP relies on a secure mapping database system? I just wanted to highlight that while LISP does need its mapping system to work correctly, so does the current Internet need BGP to run correctly. So there is no big difference in the security of these two as far as that part goes. But it is not important. If you don't want to include it, feel free to use the text that you like. > >>> It is a good idea to have instrumentation in place >>> to detect thrashing of the cache. Implementation experimentation >>> will be used to determine which cache management strategies work >>> best. >> Yes, but I think we should also acknowledge that defending against cache trashing attacks is hard: >> >> It is a good idea to have instrumentation in place >> to detect thrashing of the cache. Implementation experimentation >> will be used to determine which cache management strategies work >> best. In general, it is difficult to defend against cache trashing attacks. >> >> (Unless, of course, I'm missing some obvious schemes that show promise of avoiding some of these issues against determined attackers. It is also possible that if we described the situation in more detail, we'd be able to describe the threats in a more rational way. E.g., outsiders can cause some (limited) problems, insiders could cause big trouble but are generally a bit more trusted, etc.) > Schemes are work in progress and hence why we don't want to list them. We had mentioned this before from the Nanog-triggered thread which we moved over to the lisp@ietf.org list. I agree that we should not mention any schemes. But I do want to add the last sentence, because I think it is a true statement and more importantly, it provides IMO a fair assessment of the potential difficulties. > >>> This experimental specification does not address automated key >>> management (AKM).BCP 107 provides guidance in this area. >> Yes, but I think we should include two additional important pieces of information. 1. you need to acknowledge that you are not following BCP 107 in this case, as it requires AKM under certain conditions (we are within those conditions, right?). And 2) more importantly, you need to document the implications of not providing AKM. Personally, I do not necessarily consider it a panacea, and often the nonce etc. mechanisms are far more important. In any case, the reader needs to understand what we are losing without AKM. > This text was created, accepted, and agreed upon from the security ADs. So I dare not to touch it. Grumble. I think it would be better with a text that describes the implications. And I think we could actually do a better job than the security ADs are apparently telling you to do. It is not unheard to have a discuss waiting for us anyway even if some text was agreed, if we haven't done our homework. But I'll let this go in the interest of expediency, and because I happen to believe AKM in this case is an almost complete non-issue. But I do not want to take this approach in the other issues. > >>> 13. Network Management Considerations >>> >>> Considerations for Network Management tools exist so the LISP >>> protocol suite can be operationally managed. The mechanisms can be >>> found in [LISP-MIB] and [LISP-LIG]. >> It is good that you point to these specifications. I wonder if there are additional things you should say in this spec, however. Are there parameters that Lisp needs to operate? Are they and their default values described in LISP-MIB? There are many good pieces of advice about the management of a Lisp network in previous sections, should there be some kind of summary/pointers for these here as well? > All described in the LISP-MIB, which is still ongoing. I will make sure we put any configuration guidelines in there. OK Jari From jari.arkko@piuha.net Sun Oct 30 14:47:01 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406EE11E8086 for ; Sun, 30 Oct 2011 14:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he3c+pZzgjKc for ; Sun, 30 Oct 2011 14:47:00 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id EE94021F8B76 for ; Sun, 30 Oct 2011 14:46:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4B2052CC39; Sun, 30 Oct 2011 23:46:59 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAAM-EBUMHzg; Sun, 30 Oct 2011 23:46:58 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D26BE2CC34; Sun, 30 Oct 2011 23:46:57 +0200 (EET) Message-ID: <4EADC5CF.4070505@piuha.net> Date: Sun, 30 Oct 2011 23:46:55 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4EA1FF24.7000902@piuha.net> <4EA32F7B.1060904@piuha.net> <6A8DA48E-6A42-4976-9A2D-6792D9C254DD@cisco.com> In-Reply-To: <6A8DA48E-6A42-4976-9A2D-6792D9C254DD@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 21:47:01 -0000 Dino, >> This is the last part of my review, as far as the actual document contents go. I will send another summary e-mail. >> >> Technical: >> >>> 14.1. LISP Address Type Codes >>> >>> Instance ID type codes have a range from 0 to 15, of which 0 and 1 >>> have been allocated [LCAF]. New Type Codes MUST be allocated >>> starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. >>> Type Codes 11 - 15 are available on a First Come First Served policy. >>> >>> The following codes have been allocated: >>> >>> Type 0: Null Body Type >>> >>> Type 1: AFI List Type >>> >>> See [LCAF] for details for other possible unapproved address >>> encodings. The unapproved LCAF encodings are an area for further >>> study and experimentation. >> To begin with, I did not understand this definition. I'm trying to understand where the LCAF draft actually makes the instance ID allocations, and I can't see it. In addition, the "Null Body Type" string only appears twice in this and the LCAF draft, and neither occurrence explains what it is. I think something is missing here. > The source-EID in an RLOC-probe may contain a null body encoding. Because there was no data packet that triggered this Map-Request. I will add that to the RLOC-probe section. > > Instance-ID is defined in the LCAF draft as Type 2. Here is the packet format: > > Instance ID LISP Canonical Address Format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AFI = 16387 | Rsvd1 | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 2 | Rsvd2 | 4 + n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AFI = x | Address ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length value n: length in bytes of the AFI address that follows the > Instance ID field including the AFI field itself. > > Instance ID: the low-order 24-bits that can go into a LISP data > header when the I-bit is set. See [LISP] for details. > > AFI = x: x can be any AFI value from [AFI]. > > This LISP Canonical Address Type can be used to encode either EID or > RLOC addresses. > >> Finally, I do not understand why this section is in -lisp. The string "LISP Address Type Code" does not appear in the rest of the document AFAICT. The allocations in the LCAF draft seem to be inside a format defined in that draft. Shouldn't the IANA allocations and the creation of the registry be in that draft as well? This seems particularly important, given that the list of types in -lisp does not match the list in -lcaf. > We (the working group) have decided to put the in-charter values in this draft and keep the other values in the LCAF draft. So that is why values 0 and 1 are in this draft. Since instance-ID is part of a VPN use-case, this is why it is the next value assigned in the LCAF draft. > > We received direction from Terry on this since he is expert in registries et al. I now understand the background, thank you for the explanation. But I think the WG still made the wrong call on this. I would like to play the manager who tells you that the we need to ship your product and this feature still has bugs in it. Lets rip it out and not endanger our release schedule. In other words, I think other people will have the same questions as I did about this part and there is no technical reason why it needs to be here. I don't think the text is harmful by itself, but I predict unnecessary questions. Lets remove it and move on. > >> Suggested edit: delete this section. >> >>> o The following policies are used here with the meanings defined in >>> BCP 26: "Specification Required", "IETF Consensus", "Experimental >>> Use", "First Come First Served". >>> >> None of these terms are used in the rest of the document. (But see below.) > That is Terry text and seems to be standard. The standard model for this text is to include the terms that are used in subsequent text. In any case, the terms above are also outdated after RFC 5226 came out. I've taken this into account in my next proposed change (see below) and if you use that text you do not need the above text any more. > >>> 14. IANA Considerations >> This sections makes the right allocations from other, already existing registries (like UDP port numbers). But it should also define what the policies are for allocating new values with the various new number spaces that Lisp introduces: >> >> - flags >> - type >> - reserved >> - act >> - unused flags >> - … > Terry needs to respond to this. I'm not sure if we have seen a response, but I also don't think it is hard to develop the text for this. This one needs to go in, because otherwise we don't know how to manage the name spaces. It is a potential Discuss item from the other ADs or even IANA if the process isn't clear. Here's a strawman text: IANA should create a registry for managing the new namespaces within the LISP protocol. This registry contains initially the following two new namespaces. o New LISP Type values (Section 6.1.1) can be allocated through IETF Review or IESG Approval . Six values have already been allocated by this specification (Section 6.1.1). o New ACT values (Section 6.1.4) can be allocated through IETEF Review or IESG Approval. Four values have already been allocated by this specification (Section 6.1.4). In addition, the LISP protocol has a number of flag and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags can be taken into use from these fields through IETF Review or IESG Approval, but these need not be managed by IANA. Jari From terry.manderson@icann.org Sun Oct 30 21:20:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A664221F8BC3 for ; Sun, 30 Oct 2011 21:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wv3PaNjtDiy for ; Sun, 30 Oct 2011 21:20:23 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id DB71B21F8B80 for ; Sun, 30 Oct 2011 21:20:23 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 30 Oct 2011 21:20:23 -0700 From: Terry Manderson To: Albert Cabellos , "lisp@ietf.org" Date: Sun, 30 Oct 2011 21:20:21 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: AcyVk9alxcPoZfaRRwizI6mePENErQB8JCQk Message-ID: In-Reply-To: <4EAAE0B2.5060202@ac.upc.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 04:20:24 -0000 Hi Albert, On 29/10/11 3:04 AM, "Albert Cabellos" wrote: >>=20 >> Should LISP mobility be specifically included in the work plan? >>=20 >=20 > I would like to point out that we have a small but growing community of > people interested into LISPmob, we open-sourced the code 1.5 months ago. >=20 To be clear (as in crystal) does this mean you think that mobility should b= e included? or are you simply making the observation that there is a communit= y of people 'out there' who are yet to be vocal on this ML. Cheers Terry From dino@cisco.com Sun Oct 30 22:01:05 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D195B21F8C76 for ; Sun, 30 Oct 2011 22:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvE-yoHRqRGZ for ; Sun, 30 Oct 2011 22:01:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B008B21F8BCB for ; Sun, 30 Oct 2011 22:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=6596; q=dns/txt; s=iport; t=1320037264; x=1321246864; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=emedR/9zBWYio08MKTY4eCiiKbFXmiyfNHeOx5Km838=; b=B74mAX9WZAPx/oXwoy8T9klfIZCaMYS6+blOlbmMrFMcflOsVQFOFpZX EvYFbT3lXRxbYt2B8ATDK167WUCxCymRAWe7b/ga3i+venQ86euGDM9i7 YF2m2REdepVl+80SjQu+z+uQ1RluKI0E2GPPT6gVnCqqPi7sgzH+qd7Q0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA0rrk6rRDoJ/2dsb2JhbABDqTSBBYFyAQEBAQIBEgFmBQsLRlcGEyKHYAiVYQGdRoghYQSIBowIhS2MUg X-IronPort-AV: E=Sophos;i="4.69,429,1315180800"; d="scan'208";a="11322961" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 31 Oct 2011 05:01:03 +0000 Received: from [10.21.72.4] ([10.21.72.4]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9V5139w026437; Mon, 31 Oct 2011 05:01:03 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: <4EADBE3A.9080900@piuha.net> Date: Sun, 30 Oct 2011 22:01:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E2FF625-FD32-46B3-809A-268DA6356039@cisco.com> References: <4EA1FF24.7000902@piuha.net> <24DD9327-60B2-4B35-A723-8E36C0AA82F9@cisco.com> <4EADBE3A.9080900@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 6) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 05:01:06 -0000 > Dino, >=20 >>> Technical: >>>=20 >>> Overall, the security considerations section is a bit thin. I don't = think we need a lot of additional text, but there are some additional = pieces of information that need to be added. Some suggested text below. >>>=20 >>>> The nonce, coupled >>>> with the ITR accepting only solicited Map-Replies goes a long way >>>> toward providing decent authentication. >>> Hmm. This is not really descriptive. How about this instead: >>>=20 >>> The nonce, coupled with the ITR accepting only solicited Map-Replies = provides a basic level of security, in many ways similar to the security = experienced in the current Internet routing system. It is hard for = off-path attackers to launch attacks against these Lisp mechanisms, as = they do not have the nonce values. Sending a large number of packets to = accidentally find the right nonce value is possible, but would already = by itself be a denial-of-service attack. On-path attackers can perform = far more serious attacks, but on-path attackers can launch serious = attacks in the current Internet as well, including eavesdropping, = blocking or redirecting traffic. Lisp relies on the correct operation of = a BGP-based routing system [LISP-ALT], but so do the current Internet = routing mechanisms. >> I will add this text modulo the last sentence. I don't understand how = ALT plays into this. So I felt it was a random statement. >=20 > OK >=20 >> Did you mean LISP relies on a secure mapping database system? >=20 > I just wanted to highlight that while LISP does need its mapping = system to work correctly, so does the current Internet need BGP to run = correctly. So there is no big difference in the security of these two as = far as that part goes. >=20 > But it is not important. If you don't want to include it, feel free to = use the text that you like. Okay, I won't include it. >>>>=20 >>>> It is a good idea to have instrumentation in place >>>> to detect thrashing of the cache. Implementation experimentation >>>> will be used to determine which cache management strategies work >>>> best. >>> Yes, but I think we should also acknowledge that defending against = cache trashing attacks is hard: >>>=20 >>> It is a good idea to have instrumentation in place >>> to detect thrashing of the cache. Implementation experimentation >>> will be used to determine which cache management strategies work >>> best. In general, it is difficult to defend against cache trashing = attacks. >>>=20 >>> (Unless, of course, I'm missing some obvious schemes that show = promise of avoiding some of these issues against determined attackers. = It is also possible that if we described the situation in more detail, = we'd be able to describe the threats in a more rational way. E.g., = outsiders can cause some (limited) problems, insiders could cause big = trouble but are generally a bit more trusted, etc.) >> Schemes are work in progress and hence why we don't want to list = them. We had mentioned this before from the Nanog-triggered thread which = we moved over to the lisp@ietf.org list. >=20 > I agree that we should not mention any schemes. But I do want to add = the last sentence, because I think it is a true statement and more = importantly, it provides IMO a fair assessment of the potential = difficulties. I added this when I responded to you. Is it not sufficient: cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. In general, it is difficult to defend against cache trashing attacks. It should be noted that an undersized cache in an ITR/PTR not only causes adverse affect on the site or region they support, but may also cause increased Map-Request load on the mapping system. >>>>=20 >>>> This experimental specification does not address automated key >>>> management (AKM).BCP 107 = provides guidance in this area. >>> Yes, but I think we should include two additional important pieces = of information. 1. you need to acknowledge that you are not following = BCP 107 in this case, as it requires AKM under certain conditions (we = are within those conditions, right?). And 2) more importantly, you need = to document the implications of not providing AKM. Personally, I do not = necessarily consider it a panacea, and often the nonce etc. mechanisms = are far more important. In any case, the reader needs to understand what = we are losing without AKM. >> This text was created, accepted, and agreed upon from the security = ADs. So I dare not to touch it. >=20 > Grumble. I think it would be better with a text that describes the = implications. And I think we could actually do a better job than the = security ADs are apparently telling you to do. It is not unheard to have = a discuss waiting for us anyway even if some text was agreed, if we = haven't done our homework. But I'll let this go in the interest of = expediency, and because I happen to believe AKM in this case is an = almost complete non-issue. But I do not want to take this approach in = the other issues. The security ADs are very sensitive and particular about this text. Do = you really want to fight with them? Let's wait for them to comment if = you think this is going to happen. Plus the other ADs aren't terribly = happy right now not getting the main spec first. So I don't think we = should fuel the fire. I hope you can understand this. Dino >>=20 >>>> 13. Network Management Considerations >>>>=20 >>>> Considerations for Network Management tools exist so the LISP >>>> protocol suite can be operationally managed. The mechanisms can = be >>>> found in [LISP-MIB] and [LISP-LIG]. >>> It is good that you point to these specifications. I wonder if there = are additional things you should say in this spec, however. Are there = parameters that Lisp needs to operate? Are they and their default values = described in LISP-MIB? There are many good pieces of advice about the = management of a Lisp network in previous sections, should there be some = kind of summary/pointers for these here as well? >> All described in the LISP-MIB, which is still ongoing. I will make = sure we put any configuration guidelines in there. >=20 > OK >=20 > Jari >=20 From dino@cisco.com Sun Oct 30 22:06:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9B921F8C75 for ; Sun, 30 Oct 2011 22:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERbRrL87Ler0 for ; Sun, 30 Oct 2011 22:06:46 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BB26C21F8BF4 for ; Sun, 30 Oct 2011 22:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=7284; q=dns/txt; s=iport; t=1320037606; x=1321247206; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aNXEEVGCLDXfYP7G92EpvArQJRs/Vz3+r2OHjMQPoDA=; b=fLngUnbyXUB9NDZBBTAf1i6GOxqsUbr3lakjqa/pWvt3e8vX/EUAL7eH JzLXGgHFvNxjR3rhstJu5jWYY4/46G4ehxQ0IP5K9MzyCM5pQzAuOqJ29 PNUL4NdXuFat7xV6KKUXSTZQb630J+RvarBwlMhta3s/A91FB/QbUF7f4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADUsrk6rRDoH/2dsb2JhbABDqTSBBYFyAQEBAQIBEgFYDgULCy0ZVwY1h2CVZwGdRoVmgjthBIgGjAiFLYxS X-IronPort-AV: E=Sophos;i="4.69,429,1315180800"; d="scan'208";a="11289500" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 31 Oct 2011 05:06:46 +0000 Received: from [10.21.72.4] ([10.21.72.4]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9V56kjm011530; Mon, 31 Oct 2011 05:06:46 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Dino Farinacci In-Reply-To: <4EADC5CF.4070505@piuha.net> Date: Sun, 30 Oct 2011 22:06:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EA1FF24.7000902@piuha.net> <4EA32F7B.1060904@piuha.net> <6A8DA48E-6A42-4976-9A2D-6792D9C254DD@cisco.com> <4EADC5CF.4070505@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 05:06:47 -0000 > Dino, >=20 >>> This is the last part of my review, as far as the actual document = contents go. I will send another summary e-mail. >>>=20 >>> Technical: >>>=20 >>>> 14.1. LISP Address Type Codes >>>>=20 >>>> Instance ID type codes have a range from 0 to 15, of which 0 and = 1 >>>> have been allocated [LCAF]. New Type Codes MUST be allocated >>>> starting at 2. Type Codes 2 - 10 are to be assigned by IETF = Review. >>>> Type Codes 11 - 15 are available on a First Come First Served = policy. >>>>=20 >>>> The following codes have been allocated: >>>>=20 >>>> Type 0: Null Body Type >>>>=20 >>>> Type 1: AFI List Type >>>>=20 >>>> See [LCAF] for details for other possible unapproved address >>>> encodings. The unapproved LCAF encodings are an area for further >>>> study and experimentation. >>> To begin with, I did not understand this definition. I'm trying to = understand where the LCAF draft actually makes the instance ID = allocations, and I can't see it. In addition, the "Null Body Type" = string only appears twice in this and the LCAF draft, and neither = occurrence explains what it is. I think something is missing here. >> The source-EID in an RLOC-probe may contain a null body encoding. = Because there was no data packet that triggered this Map-Request. I will = add that to the RLOC-probe section. >>=20 >> Instance-ID is defined in the LCAF draft as Type 2. Here is the = packet format: >>=20 >> Instance ID LISP Canonical Address Format: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI =3D 16387 | Rsvd1 | Flags = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D 2 | Rsvd2 | 4 + n = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI =3D x | Address ... = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Length value n: length in bytes of the AFI address that follows = the >> Instance ID field including the AFI field itself. >>=20 >> Instance ID: the low-order 24-bits that can go into a LISP data >> header when the I-bit is set. See [LISP] for details. >>=20 >> AFI =3D x: x can be any AFI value from [AFI]. >>=20 >> This LISP Canonical Address Type can be used to encode either EID = or >> RLOC addresses. >>=20 >>> Finally, I do not understand why this section is in -lisp. The = string "LISP Address Type Code" does not appear in the rest of the = document AFAICT. The allocations in the LCAF draft seem to be inside a = format defined in that draft. Shouldn't the IANA allocations and the = creation of the registry be in that draft as well? This seems = particularly important, given that the list of types in -lisp does not = match the list in -lcaf. >> We (the working group) have decided to put the in-charter values in = this draft and keep the other values in the LCAF draft. So that is why = values 0 and 1 are in this draft. Since instance-ID is part of a VPN = use-case, this is why it is the next value assigned in the LCAF draft. >>=20 >> We received direction from Terry on this since he is expert in = registries et al. >=20 > I now understand the background, thank you for the explanation. But I = think the WG still made the wrong call on this. >=20 > I would like to play the manager who tells you that the we need to = ship your product and this feature still has bugs in it. Lets rip it out = and not endanger our release schedule. In other words, I think other = people will have the same questions as I did about this part and there = is no technical reason why it needs to be here. I don't think the text = is harmful by itself, but I predict unnecessary questions. Lets remove = it and move on. That is not what's going on here. How about we have an iPhone that has a = Settings configruation for screen size and one of the values is a = resolution that is larger than the iPhone screen size? What it means, is = that something larger is about to come. This is an experimental protocol. We are still doing the experiment and = the chairs wanted to make it easy for us to experiment with new = use-cases, even though out of charter. But they may come into charter in = the future. So let's make sure we don't let the IETF process get the best of us. >>=20 >>> Suggested edit: delete this section. >>>=20 >>>> o The following policies are used here with the meanings = defined in >>>> BCP 26: "Specification = Required", "IETF Consensus", "Experimental >>>> Use", "First Come First Served". >>>>=20 >>> None of these terms are used in the rest of the document. (But see = below.) >> That is Terry text and seems to be standard. >=20 > The standard model for this text is to include the terms that are used = in subsequent text. In any case, the terms above are also outdated after = RFC 5226 came out. >=20 > I've taken this into account in my next proposed change (see below) = and if you use that text you do not need the above text any more. >=20 >>=20 >>>> 14. IANA Considerations >>> This sections makes the right allocations from other, already = existing registries (like UDP port numbers). But it should also define = what the policies are for allocating new values with the various new = number spaces that Lisp introduces: >>>=20 >>> - flags >>> - type >>> - reserved >>> - act >>> - unused flags >>> - =85 >> Terry needs to respond to this. >=20 > I'm not sure if we have seen a response, but I also don't think it is = hard to develop the text for this. This one needs to go in, because = otherwise we don't know how to manage the name spaces. It is a potential = Discuss item from the other ADs or even IANA if the process isn't clear. = Here's a strawman text: We have not. I want to wait for Terry to respond. Dino >=20 > IANA should create a registry for managing the new namespaces within = the LISP protocol. This registry contains initially the following two = new namespaces. >=20 > o New LISP Type values (Section 6.1.1) can be allocated through IETF = Review or IESG Approval . Six values have = already been allocated by this specification (Section 6.1.1). >=20 > o New ACT values (Section 6.1.4) can be allocated through IETEF = Review or IESG Approval. Four values have already been allocated by this = specification (Section 6.1.4). >=20 > In addition, the LISP protocol has a number of flag and reserved = fields, such as the LISP header flags field (Section 5.3). New bits for = flags can be taken into use from these fields through IETF Review or = IESG Approval, but these need not be managed by IANA. >=20 > Jari >=20 From jari.arkko@piuha.net Sun Oct 30 22:38:30 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B9F21F8C7F for ; Sun, 30 Oct 2011 22:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uIosTcyarN7 for ; Sun, 30 Oct 2011 22:38:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2021F8C7E for ; Sun, 30 Oct 2011 22:38:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 558312CC3B; Mon, 31 Oct 2011 07:38:20 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3AOR5E9f7BV; Mon, 31 Oct 2011 07:38:18 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CBF272CC34; Mon, 31 Oct 2011 07:38:18 +0200 (EET) Message-ID: <4EAE3448.5060909@piuha.net> Date: Mon, 31 Oct 2011 07:38:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4EA1FF24.7000902@piuha.net> <24DD9327-60B2-4B35-A723-8E36C0AA82F9@cisco.com> <4EADBE3A.9080900@piuha.net> <2E2FF625-FD32-46B3-809A-268DA6356039@cisco.com> In-Reply-To: <2E2FF625-FD32-46B3-809A-268DA6356039@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 6) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 05:38:30 -0000 Dino, > >>>>> It is a good idea to have instrumentation in place >>>>> to detect thrashing of the cache. Implementation experimentation >>>>> will be used to determine which cache management strategies work >>>>> best. >>>> Yes, but I think we should also acknowledge that defending against cache trashing attacks is hard: >>>> >>>> It is a good idea to have instrumentation in place >>>> to detect thrashing of the cache. Implementation experimentation >>>> will be used to determine which cache management strategies work >>>> best. In general, it is difficult to defend against cache trashing attacks. >>>> >>>> (Unless, of course, I'm missing some obvious schemes that show promise of avoiding some of these issues against determined attackers. It is also possible that if we described the situation in more detail, we'd be able to describe the threats in a more rational way. E.g., outsiders can cause some (limited) problems, insiders could cause big trouble but are generally a bit more trusted, etc.) >>> Schemes are work in progress and hence why we don't want to list them. We had mentioned this before from the Nanog-triggered thread which we moved over to the lisp@ietf.org list. >> I agree that we should not mention any schemes. But I do want to add the last sentence, because I think it is a true statement and more importantly, it provides IMO a fair assessment of the potential difficulties. > I added this when I responded to you. Is it not sufficient: > > cache sizing and maintenance is an issue to be kept in mind during > implementation. It is a good idea to have instrumentation in place > to detect thrashing of the cache. Implementation experimentation > will be used to determine which cache management strategies work > best. In general, it is difficult to defend against cache trashing > attacks. It should be noted that an undersized cache in an ITR/PTR > not only causes adverse affect on the site or region they support, > but may also cause increased Map-Request load on the mapping system. Yes, this works well for me. Jari From dino@cisco.com Sun Oct 30 23:24:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C0F21F8BF4 for ; Sun, 30 Oct 2011 23:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=-2.191, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YFaboz5YN4I for ; Sun, 30 Oct 2011 23:24:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 03D2E11E809F for ; Sun, 30 Oct 2011 23:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=242838; q=dns/txt; s=iport; t=1320042240; x=1321251840; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=2EWKv1eoAjm13t8uGtZW30rNrghxREOxhrsEiNHz9mY=; b=bfVHtXM6cQB1jdgdFO/58Gi7pZNvcmSS5YwMNES6txUOwlyursuYcVAm xcYXno2+wiEZIs4E42Ym/Tt2t+IHCDOWEaZgITnk340p31otkHtBB/GFh 2ryQxmZthU+eKXQqM6UVtVTlE/3P0twAtZKTCxAJ8vJWE4KFwiF8rcN61 A=; X-Files: rfcdiff-lisp-15-to-16.html, draft-ietf-lisp-16.txt : 27163, 207835 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALU9rk6rRDoG/2dsb2JhbAA5AQkWgjefDgGHVYEFgXIBAQEBAgEOBAEFAgEMBjgCBQIIAwULCxImAQ1JDgYTCREBB4dgCJVUAZ1KBAEBhU0Bgk1hBIgGjAiFAiuFCoV+gUo X-IronPort-AV: E=Sophos;i="4.69,429,1315180800"; d="txt'?html'217?scan'217,208,217";a="11298425" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 31 Oct 2011 06:23:55 +0000 Received: from [10.21.72.4] ([10.21.72.4]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V6NsLo024794; Mon, 31 Oct 2011 06:23:54 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/mixed; boundary="Apple-Mail=_61F8ED11-9E2E-42CA-9E40-F7FA34D0BD35" From: Dino Farinacci In-Reply-To: <4EADC5CF.4070505@piuha.net> Date: Sun, 30 Oct 2011 23:23:57 -0700 Message-Id: References: <4EA1FF24.7000902@piuha.net> <4EA32F7B.1060904@piuha.net> <6A8DA48E-6A42-4976-9A2D-6792D9C254DD@cisco.com> <4EADC5CF.4070505@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 06:24:50 -0000 --Apple-Mail=_61F8ED11-9E2E-42CA-9E40-F7FA34D0BD35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > I'm not sure if we have seen a response, but I also don't think it is = hard to develop the text for this. This one needs to go in, because = otherwise we don't know how to manage the name spaces. It is a potential = Discuss item from the other ADs or even IANA if the process isn't clear. = Here's a strawman text: >=20 > IANA should create a registry for managing the new namespaces within = the LISP protocol. This registry contains initially the following two = new namespaces. >=20 > o New LISP Type values (Section 6.1.1) can be allocated through IETF = Review or IESG Approval . Six values have = already been allocated by this specification (Section 6.1.1). >=20 > o New ACT values (Section 6.1.4) can be allocated through IETEF = Review or IESG Approval. Four values have already been allocated by this = specification (Section 6.1.4). >=20 > In addition, the LISP protocol has a number of flag and reserved = fields, such as the LISP header flags field (Section 5.3). New bits for = flags can be taken into use from these fields through IETF Review or = IESG Approval, but these need not be managed by IANA. So see the enclosed changes to the IANA section. I think it is a good = compromise. Dino --Apple-Mail=_61F8ED11-9E2E-42CA-9E40-F7FA34D0BD35 Content-Disposition: attachment; filename=rfcdiff-lisp-15-to-16.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-15-to-16.html" Content-Transfer-Encoding: 7bit rfcdiff
 
IETF Home
About Tools
Tools:
diffs spell
xml2rfc idnits
tracker src
News
Get Passwd
IETF-82:
Rooms
Agenda
Calendar
Documents
RFCs
Doc fetch:
Wikis:
IESG IRTF
IAOC RSOC
Chairs Edu
Tools BOFs Development
NomCom
Areas
WGs:
concluded…
6lowpan
6man
6renum
Abfab*
Adslmib
Alto
Ancp
Appsawg
Armd
Atoca
Autoconf
Avtcore*
Avtext
Behave
Bfd
Bliss
Bmwg*
Ccamp*
Cdni
Clue
Codec
Conex*
Core
Csi
Cuss*
Dane*
Dccp
Decade
Dhc
Dime
Dispatch
Dnsext
Dnsop
Drinks
Eai*
Ecrit*
Eman*
Emu*
Fecframe
Forces
Ftpext2
Geopriv*
Grow
Hip*
Hokey*
Homenet
Httpbis
Hybi
Idr*
Intarea*
Ipfix
Ippm*
Ipsecme
Iri
Isis*
Jose
Karp
Kitten
Krb-wg*
L2tpext
L2vpn*
L3vpn
Ledbat
Lisp
Lwig
Manet
Marf
Mboned
Mediactrl
Mext
Mif*
Mile
Mip4
Mmusic*
Mpls*
Mptcp
Multimob
Nea
Netconf*
Netext*
Netmod*
Nfsv4*
Ntp
Oauth*
Opsawg
Opsec
Ospf*
P2psip*
Paws
Payload
Pce*
Pcn
Pcp
Pim*
Pkix
Pppext
Ppsp*
Precis*
Pwe3*
Radext
Rmt
Roll*
Rtcweb*
Rtgwg
Salud
Savi*
Sidr
Sieve
Simple
Sipclf
Sipcore*
Siprec*
Soc*
Softwire*
Speechsc*
Speermint
Splices
Storm
Tcpm
Tictoc
Tls
Trill*
Tsvwg*
Urnbis*
V6ops*
Vcarddav
Vipr
Websec
Xmpp
Xrblock*
Yam

* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rfcdiff Tool
Version: 0.11
Author:

Rfcdiff Web Service

File 1 -   Upload file:  
or enter URL:  
 
File 2 -   Upload file:  
or enter URL:  
 
Output format: Side-by-side diff
Before-after diff
Changebars
Html wdiff
Html Wdiff Options:
Colour of old text:
Colour of new text:
Larger diff text:
Column width:

You can also use this web-service with an URL query-string of the form:

http://tools.ietf.org//rfcdiff?url1=http-url-to-doc-1&url2=http-url-to-doc-2

which makes it possible to send around links to diffs between document versions withouth actually generating the diff yourself, as long as the two document versions are available by http.

Example (yes, it is long - no way to get around that... - but you could use tinyurl.com to get a short alias to one of these):

http://tools.ietf.org/rfcdiff?
  url1=http://tools.ietf.org/id/draft-ietf-atompub-format-10.txt
  &url2=http://tools.ietf.org/id/draft-ietf-atompub-format-11.txt




Generated from PyHt script /rfcdiff Latest update: 24 May 2011 09:22 GMT -
--Apple-Mail=_61F8ED11-9E2E-42CA-9E40-F7FA34D0BD35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 --Apple-Mail=_61F8ED11-9E2E-42CA-9E40-F7FA34D0BD35 Content-Disposition: attachment; filename=draft-ietf-lisp-16.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-16.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: May 2, 2012 D. Lewis cisco Systems October 30, 2011 Locator/ID Separation Protocol (LISP) draft-ietf-lisp-16 Abstract This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 2, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Farinacci, et al. Expires May 2, 2012 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 23 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 31 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 50 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 51 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 52 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 54 7. Router Performance Considerations . . . . . . . . . . . . . . 55 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56 Farinacci, et al. Expires May 2, 2012 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58 8.4. LISP Functionality with Conventional NATs . . . . . . . . 58 8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 59 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 60 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 61 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 61 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 61 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 63 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 63 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 65 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 13. Network Management Considerations . . . . . . . . . . . . . . 70 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 71 14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71 14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71 14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 15.1. Normative References . . . . . . . . . . . . . . . . . . . 73 15.2. Informative References . . . . . . . . . . . . . . . . . . 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 77 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 78 B.1. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 78 B.2. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 78 B.3. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 78 B.4. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 79 B.5. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 79 B.6. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 81 B.7. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 81 B.8. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 82 B.9. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 82 B.10. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 84 B.11. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 86 B.12. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 87 B.13. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 87 B.14. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 89 B.15. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 89 B.16. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 90 B.17. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 Farinacci, et al. Expires May 2, 2012 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 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]. Farinacci, et al. Expires May 2, 2012 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 2. Introduction This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from non-routeable Endpoint Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across an Internet that uses RLOCs for routing and forwarding. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October, 2006 (see [RFC4984]). A key conclusion of the workshop was that the Internet routing and addressing system was not scaling well in the face of the explosive growth of new sites; one reason for this poor scaling is the increasing number of multi-homed and other sites that cannot be addressed as part of topologically- or provider-based aggregated prefixes. Additional work that more completely described the problem statement may be found in [RADIR]. A basic observation, made many years ago in early networking research such as that documented in [CHIAPPA] and [RFC4984], is that using a single address field for both identifying a device and for determining where it is topologically located in the network requires optimization along two conflicting axes: for routing to be efficient, the address must be assigned topologically; for collections of devices to be easily and effectively managed, without the need for renumbering in response to topological change (such as that caused by adding or removing attachment points to the network or by mobility events), the address must explicitly not be tied to the topology. The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routeable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically- identical to IP addresses; it is the semantics of how they are used that differs. This document describes the protocol that implements these functions. The database which stores the mappings between EIDs and RLOCs is Farinacci, et al. Expires May 2, 2012 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 explicitly a separate "module" to facilitate experimentation with a variety of approaches. One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general- purpose service interface for accessing a mapping database; this interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed xTRs. This experimental specification does not address automated key management. Addressing automated key management is necessary for Internet standards. See Section 12 for further security details. Farinacci, et al. Expires May 2, 2012 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 3. Definition of Terms Provider Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g. from a particular service provider), and is therefore not topologically aggregatable in the routing system. Provider Assigned (PA) Addresses: PA addresses are an a address block assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multi-homed site acquiring its own, globally- visible prefix. LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the Farinacci, et al. Expires May 2, 2012 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 same entity in both cases. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called a "LEID". Throughout this document, any references to "EID" refers to an LEID. EID-prefix: An EID-prefix is a power-of-two block of EIDs which are allocated to a site by an address allocation authority. EID- prefixes are associated with a set of RLOC addresses which make up a "database mapping". EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID-prefix. A globally routed address block (whether PI or PA) is not inherently an EID-prefix. A globally routed address block may be used by its assignee as an EID block. The converse is not supported. That is, a site which receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally prefix. This would require coordination and cooperation with the entities managing the mapping infrastructure. Once this has been done, that block could be removed from the globally routed IP system, if other suitable transition and access mechanisms are in place. Discussion of such transition and access mechanisms can be found in [INTERWORK] and [LISP-DEPLOY]. End-system: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e. outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID- to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating hosts Farinacci, et al. Expires May 2, 2012 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 supplied EID). TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: A xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality is at the CE router. EID-to-RLOC Cache: The EID-to-RLOC cache is a short-lived, on- demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: The EID-to-RLOC database is a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. The same database mapping entries MUST be configured on all ETRs for a given site. In a steady state the EID-prefixes for the site and the locator-set for each EID-prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there may be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. This has no negative implications. Farinacci, et al. Expires May 2, 2012 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Recursive Tunneling: Recursive tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling may be employed to implement traffic engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. Reencapsulating Tunnels: Reencapsulating tunneling occurs when an ETR removes a LISP header, then acts as an ITR to prepend another LISP header. Doing this allows a packet to be re-routed by the re-encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. When using multiple mapping database systems, care must be taken to not create reencapsulation loops. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte header that follows the UDP header, an ITR prepends or an ETR strips. Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently pertains to an IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-prefix is advertised or stored with no RLOCs. That is, the locator-set for the EID-to-RLOC entry is empty or has an encoded locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well defined actions that are encoded in a Negative Map-Reply. Data Probe: A data-probe is a LISP-encapsulated data packet where the inner header destination address equals the outer header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-prefix range configured on the ETR. Otherwise, the packet is discarded. A Data Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design Farinacci, et al. Expires May 2, 2012 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 for details. Proxy ITR (PITR): A PITR is also known as a PTR is defined and described in [INTERWORK], a PITR acts like an ITR but does so on behalf of non-LISP sites which send packets to destinations at LISP sites. Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a PETR acts like an ETR but does so on behalf of LISP sites which send packets to destinations at non-LISP sites. Route-returnability: is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver limits off-path data insertion. LISP site: is a set of routers in an edge network that are under a single technical administration. LISP routers which reside in the edge network are the demarcation points to separate the edge network from the core network. Client-side: a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database map cache entries by sending Map-Request messages. Server-side: a term used in this document to indicate a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map- Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets. Locator Status Bits (LSBs): Locator status bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator Reachability Algorithms described in Section 6.3. Farinacci, et al. Expires May 2, 2012 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 4. Basic Overview One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets, connections, and for sending and receiving packets do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A tunnel router prepends LISP headers on host-originated packets and strip them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet and an egress tunnel router strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems (hosts) only send to addresses which are EIDs. They don't know addresses are EIDs versus RLOCs but assume packets get to LISP routers, which in turn, deliver packets to the destination the end-system has specified. The procedure a host uses to send IP packets does not change. o EIDs are always IP addresses assigned to hosts. o LISP routers mostly deal with Routing Locator addresses. See details later in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers; preferably, topologically-oriented addresses from provider CIDR blocks. o When a router originates packets it may use as a source address either an EID or RLOC. When acting as a host (e.g. when terminating a transport session such as SSH, TELNET, or SNMP), it may use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A Farinacci, et al. Expires May 2, 2012 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication. o EID prefixes are likely to be hierarchically assigned in a manner which is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on a address allocation hierarchy which is independent of the network topology. o EIDs may also be structured (subnetted) in a manner suitable for local routing within an autonomous system. An additional LISP header may be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform traffic engineering for packets flowing through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the egress tunnel router might be the last-hop router directly-connected to the destination host. Another example, perhaps for a VPN service out-sourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other tunnel routers is allowed for maximum flexibility. See Section 8 for more details. Farinacci, et al. Expires May 2, 2012 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow with the following conditions: o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. o Each site is multi-homed, so each tunnel router has an address (RLOC) assigned from the service provider address block for each provider to which that particular tunnel router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in LISP site. o Map-Requests can be sent on the underlying routing system topology or over an alternative topology [ALT]. o Map-Replies are sent on the underlying routing system topology. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally-assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the EID destination to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [ALT] or [CONS] for possible solutions. 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be rate-limited. 4. When an alternate mapping system is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise, the Map-Request packet is routed on an alternate logical topology, for example the [ALT] database mapping system. In either case, when the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. Farinacci, et al. Expires May 2, 2012 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity) and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC mapping cache. Note that the map cache is an on-demand cache. An ITR will manage its map cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note the packet may be sent to a different ETR than the one which returned the Map-Reply due to the source site's hashing policy or the destination site's locator-set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host. In order to defer the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner header source IP address) to the source RLOC (outer header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details. Farinacci, et al. Expires May 2, 2012 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is recommended in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source. This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two existing schemes are detailed in Section 5.4. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the other header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the other header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 combinations MUST be supported. Farinacci, et al. Expires May 2, 2012 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires May 2, 2012 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires May 2, 2012 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 5.3. Tunnel Header Field Descriptions Inner Header: The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer Header: The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used. UDP Header: The UDP header contains a ITR selected source port when encapsulating a packet. See Section 6.5 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA assigned port value 4341. UDP Checksum: The UDP checksum field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. UDP Length: The UDP length field is set for an IPv4 encapsulated packet to be the sum of the inner header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6 encapsulated packet, the UDP length field is the sum of the inner header IPv6 Payload Length, the size of the IPv6 header (40 bytes), and the size of the UDP and LISP headers. N: The N bit is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See Section 6.3.1 for details. Both N and V bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the "Nonce/Map-Version" field as Farinacci, et al. Expires May 2, 2012 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 having a Nonce value present. L: The L bit is the Locator Status Bits field enabled bit. When this bit is set to 1, the Locator Status Bits in the second 32-bits of the LISP header are in use. x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E bit is the echo-nonce-request bit. When this bit is set to 1, the N bit MUST be 1. This bit SHOULD be ignored and has no meaning when the N bit is set to 0. See Section 6.3.1 for details. V: The V bit is the Map-Version present bit. When this bit is set to 1, the N bit MUST be 0. Refer to Section 6.6.3 for more details. This bit indicates that the LISP header is encoded as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I bit is the Instance ID bit. See Section 5.5 for more details. When this bit is set to 1, the Locator Status Bits field is reduced to 8-bits and the high-order 24-bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like: Farinacci, et al. Expires May 2, 2012 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: The flags field is a 3-bit field is reserved for future flag use. It MUST be set to 0 on transmit and MUST be ignored on receipt. LISP Nonce: The LISP nonce field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo- nonce or providing a random nonce. See Section 6.3.1 for more details. LISP Locator Status Bits: The locator status bits field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least significant bit of field. The field is 32-bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator Status Bit is set to 1, the ITR is indicating to the ETR the RLOC associated with the bit ordinal has up status. See Section 6.3 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID- prefixes which result in multiple mappings (where each could have a different locator-set), the Locator Status Bits setting in an encapsulated packet MUST reflect the mapping for the EID-prefix that the inner-header source EID address matches. If the LSB for an anycast locator is set to 1, then there is at least one RLOC with that address the ETR is considered 'up'. When doing ITR/PITR encapsulation: o The outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. Farinacci, et al. Expires May 2, 2012 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing ETR/PETR decapsulation: o The inner header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the outer header Time to Live field, when the Time to Live field of the outer header is less than the Time to Live of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycle. This check is also performed when doing initial encapsulation when a packet comes to an ITR or PITR destined for a LISP site. o The inner header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the outer header Type of Service field (with one caveat, see below). Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the TTL serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 9.3 for TTL exception handling for traceroute packets. The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service field and the IPv6 Traffic Class field [RFC3168]. The ECN field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit ECN field from the stripped outer header to the new outer header. If the ECN field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve Congestion Experienced (CE) indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. Farinacci, et al. Expires May 2, 2012 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 5.4. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be used since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Reencapsulating and Recursive Tunneling. So any actions below referring to an ITR also apply to an TE-ITR. 5.4.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define an architectural constant S for the maximum size of a packet, in bytes, an ITR would like to receive from a source inside of its site. 2. Define L to be the maximum size, in bytes, a packet of size S would be after the ITR prepends the LISP header, UDP header, and outer network layer header of size H. 3. Calculate: S + H =3D L. When an ITR receives a packet from a site-facing interface and adds H bytes worth of encapsulation to yield a packet size greater than L bytes, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. This behavior is performed by the ITR when the source host originates a packet with the DF field of the IP header is set to 0. When the DF field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L, and sends an ICMP Too Big message to the Farinacci, et al. Expires May 2, 2012 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 source with a value of S, where S is (L - H). When the outer header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification recommends that L be defined as 1500. 5.4.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each locator per mapping cache entry. The effective MTU is what the core network can deliver along the path between ITR and ETR. 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which locator is affected by the effective MTU change and then record the new effective MTU value in the mapping cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the mapping cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 5.5. Using Virtualization and Segmentation with LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. See IANA Considerations Section 14.2 for details for possible address encodings. Farinacci, et al. Expires May 2, 2012 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 An Instance ID can be carried in a LISP encapsulated packet. An ITR that prepends a LISP header, will copy a 24-bit value, used by the LISP router to uniquely identify the address space. The value is copied to the Instance ID field of the LISP header and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. For example, a 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. Farinacci, et al. Expires May 2, 2012 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 6. EID-to-RLOC Mapping 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats The following UDP packet formats are used by the LISP control-plane. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol =3D 17 | Header Checksum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Farinacci, et al. Expires May 2, 2012 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 + Destination Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. The UDP Length field will reflect the length of the UDP header and the LISP Message payload. The UDP Checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register and ECM control messages. It MUST be checked on receipt and if the checksum fails, the packet MUST be dropped. LISP-CONS [CONS] uses TCP to send LISP control messages. The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries. This main LISP specification is the authoritative source for message format definitions for the Map-Request and Map-Reply messages. Farinacci, et al. Expires May 2, 2012 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 6.1.1. LISP Packet Type Allocations This section will be the authoritative source for allocating LISP Type values. Current allocations are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Encapsulated Control Message: 8 b'1000' 6.1.2. Map-Request Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D1 |A|M|P|S|p|s| Reserved | IRC | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI n | ITR-RLOC Address n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Reserved | EID mask-len | EID-prefix-AFI | Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | EID-prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Map-Reply Record ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires May 2, 2012 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Type: 1 (Map-Request) A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. M: This is the map-data-present bit, when set, it indicates a Map- Reply Record segment is included in the Map-Request. P: This is the probe-bit which indicates that a Map-Request SHOULD be treated as a locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating the Map-Reply is a locator reachability probe reply, with the nonce copied from the Map-Request. See Section 6.3.2 for more details. S: This is the Solicit-Map-Request (SMR) bit. See Section 6.6.2 for details. p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request. s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map- Request. Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. IRC: This 5-bit field is the ITR-RLOC Count which encodes the additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- Address) pair must always be encoded. Multiple ITR-RLOC Address fields are used so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31. For a value of 0, there is 1 ITR-RLOC address encoded, and for a value of 1, there are 2 ITR-RLOC addresses encoded and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. Record Count: The number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Farinacci, et al. Expires May 2, 2012 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. Source-EID-AFI: Address family of the "Source EID Address" field. Source EID Address: This is the EID of the source host which originated the packet which is invoking this Map-Request. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, an AFI value 0 is used and this field is of zero length or an LCAF Type "Null Body" encoding can be used where the length of this field is defined in [LCAF]. ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that follows this field. ITR-RLOC Address: Used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message. EID mask-len: Mask length for EID prefix. EID-prefix-AFI: Address family of EID-prefix according to [AFI] EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-prefix is set to the destination IP address of the data packet. And the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID- prefix used in the Map-Request has the same mask-length as the EID-prefix returned from the site when it sent a Map-Reply message. Map-Reply Record: When the M bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR which will receive this Map-Request to cache the data if it chooses to do so. Farinacci, et al. Expires May 2, 2012 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Mapping Protocol Data: See [CONS] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. 6.1.3. EID-to-RLOC UDP Map-Request Message A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure. For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the locator-set of the map cache entry. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. In all cases, the UDP source port number for the Map-Request message is an ITR/PITR selected 16-bit value and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply, which is one that has a nonce that matches an outstanding Map-Request nonce, will update the cached set of RLOCs associated with the EID prefix range. One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the IRC field. The ITR MAY include all locally configured locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on encapsulated Map-Requests and Map-Resolvers can be found in [LISP-MS]. Map-Requests MUST be rate-limited. It is recommended that a Map- Request for the same EID-prefix be sent no more than once per second. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the map-cache, it may originate a "verifying Map-Request", addressed to the map-requesting ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map- Farinacci, et al. Expires May 2, 2012 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Request" directly to the originating Map-Request source. If the RLOC is not in the locator-set, then the ETR MUST send the "verifying Map- Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in in the "piggybacked" mapping data. 6.1.4. Map-Reply Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D2 |P|E|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 2 (Map-Reply) P: This is the probe-bit which indicates that the Map-Reply is in response to a locator reachability probe Map-Request. The nonce field MUST contain a copy of the nonce value from the original Map-Request. See Section 6.3.2 for more details. Farinacci, et al. Expires May 2, 2012 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 E: Indicates that the ETR which sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. S: This is the Security bit. When set to 1 the field following the Mapping Protocol Data field will have the following format. The detailed format of the Authentication Data Content is for further study. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. Record Count: The number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of the Map- Reply. Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator Count: The number of Locator entries. A locator entry comprises what is labeled above as 'Loc'. The locator count can be 0 indicating there are no locators for the EID-prefix. EID mask-len: Mask length for EID prefix. ACT: This 3-bit field describes negative Map-Reply actions. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PTR when a destination EID matches a negative mapping cache entry. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: Farinacci, et al. Expires May 2, 2012 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 (0) No-Action: The map-cache is kept alive and no packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Unreachable message SHOULD be sent. A: The Authoritative bit, when sent by a UDP-based message is always set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-prefix. Map-Version Number: When this 12-bit value is non-zero the Map-Reply sender is informing the ITR what the version number is for the EID-record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other ETRs for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Section 6.6.3 for more details. EID-prefix-AFI: Address family of EID-prefix according to [AFI]. EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. Priority: each RLOC is assigned a unicast priority. Lower values are more preferable. When multiple RLOCs have the same priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding. Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example if there are 4 locators in a locator set, where the weights assigned are 30, 20, 20, and 10, the first locator will get 37.5% of the traffic, the 2nd and 3rd locators will get 25% of traffic and the 4th locator will get 12.5% of the traffic. If all weights for a locator-set are equal, receiver of the Map-Reply will decide how to load-split traffic. Farinacci, et al. Expires May 2, 2012 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 See Section 6.5 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values. M Priority: each RLOC is assigned a multicast priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. M Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance building multicast distribution trees across multiple ITRs. The weight is encoded as a relative weight (similar to the unicast Weights) of total number of trees built to the source site identified by the EID-prefix. If all weights for a locator-set are equal, the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. Unused Flags: set to 0 when sending and ignored on receipt. L: when this bit is set, the locator is flagged as a local locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to 0 for all locators in this locator-set. p: when this bit is set, an ETR informs the RLOC-probing ITR that the locator address, for which this bit is set, is the one being RLOC- probed and may be different from the source address of the Map- Reply. An ITR that RLOC-probes a particular locator, MUST use this locator for retrieving the data structure used to store the fact that the locator is reachable. The "p" bit is set for a single locator in the same locator set. If an implementation sets more than one "p" bit erroneously, the receiver of the Map-Reply MUST select the first locator. The "p" bit MUST NOT be set for locator-set records sent in Map-Request and Map-Register messages. R: set when the sender of a Map-Reply has a route to the locator in the locator data record. This receiver may find this useful to know if the locator is up but not necessarily reachable from the receiver's point of view. See also Section 6.4 for another way the R-bit may be used. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router), and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC Farinacci, et al. Expires May 2, 2012 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 SHOULD be a multicast address if it is being mapped from a multicast destination EID. Mapping Protocol Data: See [CONS] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. The Mapping Protocol Data is used when needed by the particular mapping system. 6.1.5. EID-to-RLOC UDP Map-Reply Message A Map-Reply returns an EID-prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are globally-routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requesters perspective. Separate testing of path reachability is required, See Section 6.3 for details. Note that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-prefixes that are covered by a Map- Reply containing one, less-specific prefix, replaces the entry with the less-specific EID-prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur but not by removing the less-specific prefix rather by adding the more-specific prefixes which during a lookup will override the less-specific prefix. When an ETR is configured with overlapping EID-prefixes, a Map- Request with an EID that longest matches any EID-prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-prefixes: 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-prefix of 10.1.1.0/24. A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes Farinacci, et al. Expires May 2, 2012 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Note that not all overlapping EID-prefixes need to be returned, only the more specifics (note in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) entries for the matching EID-prefix of the requesting EID. When more than one EID-prefix is returned, all SHOULD use the same Time-to-Live value so they can all time out at the same time. When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. When a less specific EID-prefix is received later, its map-cache expiration time SHOULD be set to the minimum expiration time of any more specific EID-prefix in the map-cache. This is done so the integrity of the EID-prefix set is wholly maintained so no more-specific entries are removed from the map-cache while keeping less-specific entries. Map-Replies SHOULD be sent for an EID-prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range thereby reducing the number of Map-Request messages. Map-Reply records can have an empty locator-set. A negative Map- Reply is a Map-Reply with an empty locator-set. Negative Map-Replies convey special actions by the sender to the ITR or PTR which have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PTR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non-allocated EIDs. For each Map-Reply record, the list of locators in a locator-set MUST appear in the same order for each ETR that originates a Map-Reply message. The locator-set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. When sending a Map-Reply message, the destination address is copied from the one of the ITR-RLOC fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local IP addresses chosen to allow uRPF checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data- Probe and the source port of the Map-Reply message is set to the well-known UDP port 4342. Farinacci, et al. Expires May 2, 2012 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 6.1.5.1. Traffic Redirection with Coarse EID-Prefixes When an ETR is misconfigured or compromised, it could return coarse EID-prefixes in Map-Reply messages it sends. The EID-prefix could cover EID-prefixes which are allocated to other sites redirecting their traffic to the locators of the compromised site. To solve this problem, there are two basic solutions that could be used. The first is to have Map-Servers proxy-map-reply on behalf of ETRs so their registered EID-prefixes are the ones returned in Map- Replies. Since the interaction between an ETR and Map-Server is secured with shared-keys, it is more difficult for an ETR to misbehave. The second solution is to have ITRs and PTRs cache EID- prefixes with mask-lengths that are greater than or equal to a configured prefix length. This limits the damage to a specific width of any EID-prefix advertised, but needs to be coordinated with the allocation of site prefixes. These solutions can be used independently or at the same time. At the time of this writing, other approaches are being considered and researched. 6.1.6. Map-Register Message Format The usage details of the Map-Register message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: Farinacci, et al. Expires May 2, 2012 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D3 |P| Reserved |M| Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 3 (Map-Register) P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map- Register message requesting for the Map-Server to proxy Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. Details on this usage will be provided in a future version of this draft. Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. M: This is the want-map-notify bit, when set to 1 an ETR is requesting for a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to an acknowledge receipt of a Map-Register message. Farinacci, et al. Expires May 2, 2012 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Record Count: The number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. See Section 14.4 for codepoint assignments. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-256-128 [RFC6234] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. 6.1.7. Map-Notify Message Format The usage details of the Map-Notify message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent inside a UDP packet with a source UDP port equal to 4342 and a destination port equal to the source port from the Map- Register message this Map-Notify message is responding to. The Map-Notify message format is: Farinacci, et al. Expires May 2, 2012 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D4 | Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 4 (Map-Notify) The Map-Notify message has the same contents as a Map-Register message. See Map-Register section for field descriptions. 6.1.8. Encapsulated Control Message Format An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires May 2, 2012 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 |S| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. S: This is the Security bit. When set to 1 the field following the Reserved field will have the following format. The detailed format of the Authentication Data Content is for further study. Farinacci, et al. Expires May 2, 2012 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is ITR/PITR selected and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages and PIM Join-Prune messages [MLISP] are allowed to be encapsulated. Encapsulating other types of LISP control messages are for further study. When Map-Requests are sent for RLOC-probing purposes (i.e the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. 6.2. Routing Locator Selection Both client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information may be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following enumerates different scenarios for choosing RLOCs and the controls that are available: o Server-side returns one RLOC. Client-side can only use one RLOC. Server-side has complete control of the selection. o Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list Farinacci, et al. Expires May 2, 2012 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. o Either side (more likely on the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner header source EID and the outer header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server- side ETR MUST assume each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-prefix encoding cannot be conveyed in data packets, the EID-to-RLOC cache on tunnel routers can grow to be very large. o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply or that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Farinacci, et al. Expires May 2, 2012 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Locator Status Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note, trusting ICMP messages may not be desirable but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Locator Status Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: Farinacci, et al. Expires May 2, 2012 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator Status Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Locator Status Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Locator Status Bits field. When a bit goes from 1 to 0, the ETR if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator Status Bit returns to a value of 1. Locator Status Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the Locator Status Bit that corresponds to that locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID- prefix. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators which are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Unreachable messages. If an ITR does receive an ICMP Network or Host Unreachable message, it MAY originate its own ICMP Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a locator-set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default Free Zone (DFZ), it can decide to not use the locator even though the Farinacci, et al. Expires May 2, 2012 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Locator Status Bits indicate the locator is up. In this case, the path from the ITR to the ETR that is assigned the locator is not available. More details are in [LOC-ID-ARCH]. Optionally, an ITR can send a Map-Request to a Locator and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by tunnel routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When an Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanisms to determine reachability. 6.3.1. Echo Nonce Algorithm When data flows bidirectionally between locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N bit set and E bit cleared. The ITR sees this "echoed nonce" and knows the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable Farinacci, et al. Expires May 2, 2012 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 and a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in echo-nonce-request state, then the path to the ETR is unreachable. This decision may be overridden by other locator reachability algorithms. Once the ITR determines the path to the ETR is down it can switch to another locator for that EID-prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR may both go into echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation specific setting. However, when an ITR is in echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and then subsequently, continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR which transmits traffic from that site or the site to site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may regard the locator unreachable erroneously. An ITR SHOULD only set the E-bit in a encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map- Reply message. Note that other locator reachability mechanisms are being researched and can be used to compliment or even override the Echo Nonce Algorithm. See next section for an example of control-plane probing. 6.3.2. RLOC Probing Algorithm RLOC Probing is a method that an ITR or PTR can use to determine the reachability status of one or more locators that it has cached in a map-cache entry. The probe-bit of the Map-Request and Map-Reply messages are used for RLOC Probing. RLOC probing is done in the control-plane on a timer basis where an ITR or PTR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the Farinacci, et al. Expires May 2, 2012 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 ALT like one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-prefix of the map-cache entry cached by the ITR or PTR. The ITR may include a mapping data record for its own database mapping information which contains the local EID-prefixes and RLOCs for its site. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in Section 6.1.5. The Map-Reply SHOULD contain mapping data for the EID-prefix contained in the Map-Request. This provides the opportunity for the ITR or PTR, which sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC Probing. The greatest benefit of RLOC Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another locator from the cached locator. RLOC Probing can also provide rough RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Continued research and testing will attempt to characterize the tradeoffs of failure detection times versus message overhead. 6.4. EID Reachability within a LISP Site A site may be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own locator. And when the ETR is also an ITR, it can clear its locator-status-bit in the encapsulation data header. It is recognized there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-prefix range is partitioned. And which locators can reach any sub-ranges of the EID-prefixes. This problem is under investigation with the expectation that experiments will tell us more. Note, this is not a new problem introduced by the LISP architecture. The Farinacci, et al. Expires May 2, 2012 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 problem exists today when a multi-homed site uses BGP to advertise its reachability upstream. 6.5. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the locator-set for the EID-prefix may contain different priority values for each locator address. When more than one best priority locator exists, the ITR can decide how to load share traffic against the corresponding locators. The following hash algorithm may be used by an ITR to select a locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash can be used or the traditional 5-tuple hash which includes the source and destination addresses, source and destination TCP, UDP, or SCTP port numbers and the IP protocol number field or IPv6 next- protocol fields of a packet a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of locators stored in the locator-set for the EID-to-RLOC mapping. 3. The remainder will be yield a value of 0 to "number of locators minus 1". Use the remainder to select the locator in the locator-set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers which are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets which are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. Farinacci, et al. Expires May 2, 2012 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 6.6. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When adding a new locator record in lexicographic order to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. When a locator record is inserted in the middle of a locator-set, to maintain lexicographic order, the SMR procedure in Section 6.6.2 is used to inform ITRs and PTRs of the new locator-status-bit mappings. When a locator record is removed from a locator-set, ITRs that have the mapping cached will not use the removed locator because the xTRs will set the loc-status-bit to 0. So even if the locator is in the list, it will not be used. For new mapping requests, the xTRs can set the locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding loc-status-bit to 0. This forces ITRs with old or new mappings to avoid using the removed locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the locator-set and new records appended to the locator-set. At some point, it would be useful to compact the locator-set so the loc-status-bit settings can be efficiently packed. We propose here three approaches for locator-set compaction, one operational and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. Farinacci, et al. Expires May 2, 2012 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 6.6.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So there is a 24 hour window to time out old mappings. The following clock sweep procedure is used: 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1 hour window the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. 4. At the end of the 1 hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a time to live equal to the TTL in the Map-Reply. 6.6.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data to for the last minute. In particular, an ETR will send an SMR an ITR to which it has recently sent encapsulated data. An SMR message is simply a bit set in a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limited these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. Farinacci, et al. Expires May 2, 2012 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 The following procedure shows how a SMR exchange occurs when a site is doing locator-set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. 2. A remote ITR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected and the EID-prefix used is the one copied from the SMR message. If the source locator is the only locator in the cached locator-set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map Versioning is used, described in Section 6.6.3, an SMR sender can detect if an ITR is using the most up to date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. 5. The ETRs, at the site with the changed mapping, record the fact that the site that sent the Map-Request has received the new mapping data in the mapping cache entry for the remote site so the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. Experimentation is in progress to determine the appropriate rate- limit parameters. For security reasons an ITR MUST NOT process unsolicited Map-Replies. To avoid map-cache entry corruption by a third-party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR- based Map-Request and the source is not in the locator-set for the stored map-cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. When an ITR receives an SMR-based Map-Request for which it does not Farinacci, et al. Expires May 2, 2012 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 have a cached mapping for the EID in the SMR message, it MAY not send a SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all locators in the locator-set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case, they will send Map-Requests to obtain a map-cache entry. 6.6.3. Database Map Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation can stop to a removed locator and start to a new locator in the locator-set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 6.6.2 occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects the Source Map-Version Number is greater than the last Map-Version Number sent in a Map- Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-prefix. So values that are greater, are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server can assure that all ETRs for a site registering to it will be Map-Version number synchronized. See [VERSIONING] for a more detailed analysis and description of Database Map Versioning. Farinacci, et al. Expires May 2, 2012 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. A few implementation techniques can be used to incrementally implement LISP: o When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data-plane. o On an ITR, prepending a new IP header consists of adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select a VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. For performance issues related to map-cache management, see section Section 12. Farinacci, et al. Expires May 2, 2012 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 8. Deployment Scenarios This section will explore how and where ITRs and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. For a more detailed deployment recommendation, refer to [LISP-DEPLOY]. There are two basic deployment trade-offs to consider: centralized versus distributed caches and flat, recursive, or re-encapsulating tunneling. When deciding on centralized versus distributed caching, the following issues should be considered: o Are the tunnel routers spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination locator. A distributed cache is when an ITR needs help from other re- encapsulating routers because it does not store all the cache entries for the EIDs is it encapsulating to. So the packet takes a path through re-encapsulating routers that have a different set of cache entries. o Should management "touch points" be minimized by choosing few tunnel routers, just enough for redundancy? o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, more ETRs does require more management since EID-prefix-to-RLOC mappings need to be explicitly configured. When deciding on flat, recursive, or re-encapsulation tunneling, the following issues should be considered: o Flat tunneling implements a single tunnel between source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path. o Recursive tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. Farinacci, et al. Expires May 2, 2012 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o The technique of re-encapsulation ensures that packets only require one tunnel header. So if a packet needs to be rerouted, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC. The next sub-sections will survey where tunnel routers can reside in the network. 8.1. First-hop/Last-hop Tunnel Routers By locating tunnel routers close to hosts, the EID-prefix set is at the granularity of an IP subnet. So at the expense of more EID- prefix-to-RLOC sets for the site, the caches in each tunnel router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these tunnel routers. With more tunnel routers doing encapsulation, the increase in control traffic grows as well: since the EID-granularity is greater, more Map-Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios then their core router counterparts. Memory is typically less expensive in these devices and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing state. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices as well. 8.2. Border/Edge Tunnel Routers Using customer-edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This is the default behavior envisioned in the rest of this specification. This offers the opposite benefit of the first-hop/last-hop tunnel router scenario: the number of mapping entries and network management touch points are reduced, allowing better scaling. One disadvantage is that less of the network's resources are used to reach host endpoints thereby centralizing the point-of-failure domain and creating network choke points at the CE router. Farinacci, et al. Expires May 2, 2012 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in the specification. This section attempts to capture some of reasoning behind this preference of implementing LISP on CE routers. Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. An obvious disadvantage is that the end site has no control over where its packets flow or the RLOCs used. Other disadvantages include the difficulty in synchronizing path liveness updates between CE and PE routers. As mentioned in earlier sections a combination of these scenarios is possible at the expense of extra packet header overhead, if both site and provider want control, then recursive or re-encapsulating tunnels are used. 8.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a globally routable address and therefore SHOULD NOT contain [RFC1918] addresses. If a LISP router is configured with private addresses, they MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST Farinacci, et al. Expires May 2, 2012 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device. More details on LISP address translation can be found in [INTERWORK]. 8.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. Deployment and experimentation will determine whether this issue requires more attention. Farinacci, et al. Expires May 2, 2012 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 9. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from ITR to ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Segment 1 (in source LISP site based on EIDs): source-host ---> first-hop ... next-hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next-hop ... next-hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next-hop ... last-hop ---> destination-host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal matter as they are today. The ITR performs a TTL decrement and test for 0 before encapsulating. So the ITR hop is seen by the traceroute source has an EID address (the address of site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destination of the ICMP messages are to the ITR RLOC address, the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client as well as retaining the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0 like the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be Farinacci, et al. Expires May 2, 2012 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 9.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above since the entire traceroute data packet is included in ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention for forwarding ICMP messages back to the traceroute source. 9.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 bytes that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value. 9.3. Traceroute using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, you Farinacci, et al. Expires May 2, 2012 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 cannot get all 3 segments of the traceroute. Segment 2 of the traceroute can not be conveyed to the traceroute source since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires May 2, 2012 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 10. Mobility Considerations There are several kinds of mobility of which only some might be of concern to LISP. Essentially they are as follows. 10.1. Site Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-RLOC mappings for sites are expected to be handled by configuration, outside of the LISP protocol. 10.2. Slow Endpoint Mobility An individual endpoint wishes to move, but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs. [RFC4984] 10.3. Fast Endpoint Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used, and primarily where interactions with LISP need to be explored. The problem is that as an endpoint moves, it may require changes to the mapping between its EID and a set of RLOCs for its new network location. When this is added to the overhead of mobile IP binding updates, some packets might be delayed or dropped. In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent which resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent which resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC mappings are required for communication between the mobile node and the home agent, whether via foreign agent or not. As a mobile endpoint changes networks, up to three LISP mapping changes may be required: Farinacci, et al. Expires May 2, 2012 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o The mobile node moves from an old location to a new visited network location and notifies its home agent that it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs a EID-RLOC mapping for the home agent. o The home agent might not have the EID-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them. o When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network, and the new visited network's ITR will need to obtain an EID-RLOC mapping for the correspondent node's site. In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case, the route-returnability check would not be needed but one more LISP mapping lookup may be required instead: o As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node. o In addition, another mapping will be needed in the correspondent node's ITR, in order for the correspondent node to send packets to the mobile node's "care-of" address (EID) at the new network location. When both endpoints are mobile the number of potential mapping lookups increases accordingly. As a mobile node moves there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-prefixes. The goal is to support rapid adaptation, with little delay or packet loss for the entire system. Also IP mobility can be modified to require fewer mapping changes. In order to increase overall system performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another. Farinacci, et al. Expires May 2, 2012 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have a internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything which decreases the number of new EID- RLOC mappings needed when a node moves, or maintains the validity of an EID-RLOC mapping for a longer time, is useful. 10.4. Fast Network Mobility In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. 10.5. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically-independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Farinacci, et al. Expires May 2, 2012 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Refer to the LISP Mobility Architecture specification [LISP-MN] for more details. Farinacci, et al. Expires May 2, 2012 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 11. Multicast Considerations A multicast group address, as defined in the original Internet architecture is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determines where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator. Having said that, only the source EID and source Routing Locator needs to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source Routing Locator field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address MUST be globally routable. Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID to Routing Locator translation is done at control-time. Another approach is to have the ITR not encapsulate a multicast packet and allow the host built packet to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core routers can RPF to the ITR (the Locator address which is injected into core routing) rather than the host source address (the EID address which is not injected into core routing). To avoid any EID-based multicast state in the network core, the first approach is chosen for LISP-Multicast. Details for LISP-Multicast and Interworking with non-LISP sites is described in specification [MLISP]. Farinacci, et al. Expires May 2, 2012 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 12. Security Considerations It is believed that most of the security mechanisms will be part of the mapping database service when using control plane procedures for obtaining EID-to-RLOC mappings. For data plane triggered mappings, as described in this specification, protection is provided against ETR spoofing by using Return-Routability mechanisms evidenced by the use of a 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. The nonce, coupled with the ITR accepting only solicited Map-Replies provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these LISP mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible, but would already by itself be a denial-of-service attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking or redirecting traffic. LISP does not rely on a PKI infrastructure or a more heavy weight authentication system. These systems challenge the scalability of LISP which was a primary design goal. DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate- limiting the number of data-triggered Map-Replies. An incorrectly implemented or malicious ITR might choose to ignore the priority and weights provided by the ETR in its Map-Reply. This traffic steering would be limited to the traffic that is sent by this ITR's site, and no more severe than if the site initiated a bandwidth DoS attack on (one of) the ETR's ingress links. The ITR's site would typically gain no benefit from not respecting the weights, and would likely to receive better service by abiding by them. To deal with map-cache exhaustion attempts in an ITR/PTR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PTRs. When overlapping EID-prefixes occur across multiple map-cache entries, the integrity of the set must be wholly maintained. So if a more-specific entry cannot be added due to reaching the maximum cap, then none of the less specifics should be stored in the map-cache. Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, Farinacci, et al. Expires May 2, 2012 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. In general, it is difficult to defend against cache trashing attacks. It should be noted that an undersized cache in an ITR/PTR not only causes adverse affect on the site or region they support, but may also cause increased Map-Request load on the mapping system. There is a security risk implicit in the fact that ETRs generate the EID prefix to which they are responding. An ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future, [LISP-SEC]. Spoofing of inner header addresses of LISP encapsulated packets is possible like with any tunneling mechanism. ITRs MUST verify the source address of a packet to be an EID that belongs to the site's EID-prefix range prior to encapsulation. An ETR must only decapsulate and forward datagrams with an inner header destination that matches one of its EID-prefix ranges. If, upon receipt and decapsulation, the destination EID of a datagram does not match one of the ETR's configured EID-prefixes, the ETR MUST drop the datagram. If a LISP encapsulated packet arrives at an ETR, it SHOULD compare the inner header source EID address and the outer header source RLOC address with the mapping that exists in the mapping database. Then when spoofing attacks occur, the outer header source RLOC address can be used to trace back the attack to the source site, using existing operational tools. This experimental specification does not address automated key management (AKM). BCP 107 provides guidance in this area. In addition, at the time of this writing, substantial work is being undertaken to improve security of the routing system [KARP], [RPKI], [BGP-SEC], [LISP-SEC]. Future work on LISP should address BCP-107 as well as other open security considerations, which may require changes to this specification. Farinacci, et al. Expires May 2, 2012 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 13. Network Management Considerations Considerations for Network Management tools exist so the LISP protocol suite can be operationally managed. The mechanisms can be found in [LISP-MIB] and [LISP-LIG]. Farinacci, et al. Expires May 2, 2012 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 14. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 and RFC 5226 [RFC5226]. There are two name spaces in LISP that require registration: o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Consensus", "Experimental Use", "First Come First Served". 14.1. LISP ACT and Flag Fields New ACT values (Section 6.1.5) can be allocated through IETF review or IESG approval. Four values have already been allocated by this specification (Section 6.1.5). In addition, the LISP protocol has a number of flag and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags can be taken into use from these fields through IETF review or IESG approval, but these need not be managed by IANA. 14.2. LISP Address Type Codes Instance ID type codes have a range from 0 to 15, of which 0 and 1 have been allocated [LCAF]. New Type Codes MUST be allocated starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. Type Codes 11 - 15 are available on a First Come First Served policy. The following codes have been allocated: Type 0: Null Body Type Type 1: AFI List Type See [LCAF] for details for other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation. 14.3. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for LISP data-plane and control-plane operation, respectively. Farinacci, et al. Expires May 2, 2012 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 14.4. LISP Key ID Numbers The following Key ID values are defined by this specification as used in any packet type that references a Key ID field: Name Number Defined in ----------------------------------------------- None 0 n/a HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-256-128 2 [RFC6234] Farinacci, et al. Expires May 2, 2012 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 15. References 15.1. Normative References [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-09.txt (work in progress). [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-12.txt (work in progress). [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010. Farinacci, et al. Expires May 2, 2012 [Page 73] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets", draft-eubanks-chimento-6man-01.txt (work in progress), October 2010. [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-ietf-lisp-map-versioning-05.txt (work in progress). 15.2. Informative References [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/assignments/address-family-numbers. [AFI-REGISTRY] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBER registry http://www.iana.org/assignments/ address-family-numbers/ address-family-numbers.xml#address-family-numbers-1. [BGP-SEC] Lepinski, M., "An Overview of BGPSEC", draft-lepinski-bgpsec-overview-00.txt (work in progress), March 2011. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", Internet- Draft http://www.chiappa.net/~jnc/tech/endpoints.txt. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-04.txt (work in progress). [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00.txt (work in progress). [INTERWORK] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress). Farinacci, et al. Expires May 2, 2012 [Page 74] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 [KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP)Design Guidelines", draft-ietf-karp-design-guide-06.txt (work in progress), October 2011. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-06.txt (work in progress). [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix . [LISP-DEPLOY] Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", draft-ietf-lisp-deployment-01.txt (work in progress). [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-06.txt (work in progress). [LISP-MAIN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-12.txt (work in progress). [LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", draft-ietf-lisp-mib-02.txt (work in progress). [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-06.txt (work in progress). [LISP-SEC] Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-00.txt (work in progress). [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01.txt (work in progress). [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-10.txt (work in progress). Farinacci, et al. Expires May 2, 2012 [Page 75] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress). [OPENLISP] Iannone, L. and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt (work in progress). [RADIR] Narten, T., "Routing and Addressing Problem Statement", draft-narten-radir-problem-statement-05.txt (work in progress). [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RPKI] Lepinski, M., "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-13.txt (work in progress), February 2011. [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol for Routing Protocol Meta-data Dissemination", draft-handley-p2ppush-unpublished-2007726.txt (work in progress). Farinacci, et al. Expires May 2, 2012 [Page 76] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed review of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussion and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, and Alia Atlas. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [LISP-MAIN] was converted into this IETF LISP working group draft. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time the set of LISP documents were being prepared for IESG last call, for his meticulous review and detail commentary on the 7 working group last call drafts progressing toward experimental RFCs. Farinacci, et al. Expires May 2, 2012 [Page 77] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-16.txt o Posted October 2011 after AD review by Jari. B.2. Changes to draft-ietf-lisp-15.txt o Posted July 2011. Fixing IDnits errors. o Change description on how to select a source address for RLOC- probe Map-Replies to refer to the "EID-to-RLOC Map-Reply Message" section. B.3. Changes to draft-ietf-lisp-14.txt o Post working group last call and pre-IESG last call review. o Indicate that an ICMP Unreachable message should be sent when a packet matches a drop-based negative map-cache entry. o Indicate how a map-cache set of overlapping EID-prefixes must maintain integrity when the map-cache maximum cap is reached. o Add Joel's description for the definition of an EID, that the bit string value can be an RLOC for another device in abstract but the architecture allows it to be an EID of one device and the same value as an RLOC for another device. o In the "Tunnel Encapsulation Details" section, indicate that 4 combinations of encapsulation are supported. o Add what ETR should do for a Data-Probe when received for a destination EID outside of its EID-prefix range. This was added in the Data Probe definition section. o Added text indicating that more-specific EID-prefixes must not be removed when less-specific entries stay in the map-cache. This is to preserve the integrity of the EID-prefix set. o Add clarifying text in the Security Considerations section about how an ETR must not decapsulate and forward a packet that is not for its configured EID-prefix range. Farinacci, et al. Expires May 2, 2012 [Page 78] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 B.4. Changes to draft-ietf-lisp-13.txt o Posted June 2011 to complete working group last call. o Tracker item 87. Put Yakov suggested wording in the EID-prefix definition section to reference [INTERWORK] and [LISP-DEPLOY] about discussion on transition and access mechanisms. o Change "ITRs" to "ETRs" in the Locator Status Bit definition section and data packet description section per Damien's comment. o Remove the normative reference to [LISP-SEC] when describing the S-bit in the ECM and Map-Reply headers. o Tracker item 54. Added text from John Scudder in the "Packets Egressing a LISP Site" section. o Add sentence to the "Reencapsulating Tunnel" definition about how reencapsulation loops can occur when not coordinating among multiple mapping database systems. o Remove "In theory" from a sentence in the Security Considerations section. o Remove Security Area Statement title and reword section with Eliot's provided text. The text was agreed upon by LISP-WG chairs and Security ADs. o Remove word "potential" from the over-claiming paragraph of the Security Considerations section per Stephen's request. o Wordsmithing and other editorial comments from Alia. B.5. Changes to draft-ietf-lisp-12.txt o Posted April 2011. o Tracker item 87. Provided rewording how an EID-prefix can be reused in the definition section of "EID-prefix". o Tracker item 95. Change "eliminate" to "defer" in section 4.1. o Tracker item 110. Added that the Mapping Protocol Data field in the Map-Reply message is only used when needed by the particular Mapping Database System. o Tracker item 111. Indicate that if an LSB that is associated with an anycast address, that there is at least one RLOC that is up. Farinacci, et al. Expires May 2, 2012 [Page 79] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Tracker item 108. Make clear the R-bit does not define RLOC path reachability. o Tracker item 107. Indicate that weights are relative to each other versus requiring an addition of up to 100%. o Tracker item 46. Add a sentence how LISP products should be sized for the appropriate demand so cache thrashing is avoided. o Change some references of RFC 5226 to [AFI] per Luigi. o Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix- AFI". o Tracker item 66. Indicate that appending locators to a locator- set is done when the added locators are lexicographically greater than the previous ones in the set. o Tracker item 87. Once again reword the definition of the EID- prefix to reflect recent comments. o Tracker item 70. Added text to security section on what the implications could be if an ITR does not obey priority and weights from a Map-Reply message. o Tracker item 54. Added text to the new section titled "Packets Egressing a LISP Site" to describe the implications when two or more ITRs exist at a site where only one ITR is used for egress traffic and when there is a shift of traffic to the others, how the map-cache will need to be populated in those new egress ITRs. o Tracker item 33. Make more clear in the Routing Locator Selection section what an ITR should do when it sees an R-bit of 0 in a locator-record of a Map-Reply. o Tracker item 33. Add paragraph to the EID Reachability section indicating that site partitioning is under investigation. o Tracker item 58. Added last paragraph of Security Considerations section about how to protect inner header EID address spoofing attacks. o Add suggested Sam text to indicate that all security concerns need not be addressed for moving document to Experimental RFC status. Put this in a subsection of the Security Considerations section. Farinacci, et al. Expires May 2, 2012 [Page 80] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 B.6. Changes to draft-ietf-lisp-11.txt o Posted March 30, 2011. o Change IANA URL. The URL we had pointed to a general protocol numbers page. o Added the "s" bit to the Map-Request to allow SMR-invoked Map- Requests to be sent to a MN ETR via the map-server. o Generalize text for the definition of Reencapsuatling tunnels. o Add paragraph suggested by Joel to explain how implementation experimentation will be used to determine the proper cache management techniques. o Add Yakov provided text for the definition of "EID-to-RLOC "Database". o Add reference in Section 8, Deployment Scenarios, to the draft-jakab-lisp-deploy-02.txt draft. o Clarify sentence about no hardware changes needed to support LISP encapsulation. o Add paragraph about what is the procedure when a locator is inserted in the middle of a locator-set. o Add a definition for Locator Status Bits so we can emphasize they are used as a hint for router up/down status and not path reachability. o Change "BGP RIB" to "RIB" per Clarence's comment. o Fixed complaints by IDnits. o Add subsection to Security Considerations section indicating how EID-prefix overclaiming in Map-Replies is for further study and add a reference to LISP-SEC. B.7. Changes to draft-ietf-lisp-10.txt o Posted March 2011. o Add p-bit to Map-Request so there is documentary reasons to know when a PITR has sent a Map-Request to an ETR. Farinacci, et al. Expires May 2, 2012 [Page 81] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Add Map-Notify message which is used to acknowledge a Map-Register message sent to a Map-Server. o Add M-bit to the Map-Register message so an ETR that wants an acknowledgment for the Map-Register can request one. o Add S-bit to the ECM and Map-Reply messages to describe security data that can be present in each message. Then refer to [LISP-SEC] for expansive details. o Add Network Management Considerations section and point to the MIB and LIG drafts. o Remove the word "simple" per Yakov's comments. B.8. Changes to draft-ietf-lisp-09.txt o Posted October 2010. o Add to IANA Consideration section about the use of LCAF Type values that accepted and maintained by the IANA registry and not the LCAF specification. o Indicate that implementations should be able to receive LISP control messages when either UDP port is 4342, so they can be robust in the face of intervening NAT boxes. o Add paragraph to SMR section to indicate that an ITR does not need to respond to an SMR-based Map-Request when it has no map-cache entry for the SMR source's EID-prefix. B.9. Changes to draft-ietf-lisp-08.txt o Posted August 2010. o In section 6.1.6, remove statement about setting TTL to 0 in Map- Register messages. o Clarify language in section 6.1.5 about Map-Replying to Data- Probes or Map-Requests. o Indicate that outer TTL should only be copied to inner TTL when it is less than inner TTL. o Indicate a source-EID for RLOC-probes are encoded with an AFI value of 0. Farinacci, et al. Expires May 2, 2012 [Page 82] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Indicate that SMRs can have a global or per SMR destination rate- limiter. o Add clarifications to the SMR procedures. o Add definitions for "client-side" and 'server-side" terms used in this specification. o Clear up language in section 6.4, last paragraph. o Change ACT of value 0 to "no-action". This is so we can RLOC- probe a PETR and have it return a Map-Reply with a locator-set of size 0. The way it is spec'ed the map-cache entry has action "dropped". Drop-action is set to 3. o Add statement about normalizing locator weights. o Clarify R-bit definition in the Map-Reply locator record. o Add section on EID Reachability within a LISP site. o Clarify another disadvantage of using anycast locators. o Reworded Abstract. o Change section 2.0 Introduction to remove obsolete information such as the LISP variant definitions. o Change section 5 title from "Tunneling Details" to "LISP Encapsulation Details". o Changes to section 5 to include results of network deployment experience with MTU. Recommend that implementations use either the stateful or stateless handling. o Make clarification wordsmithing to Section 7 and 8. o Identify that if there is one locator in the locator-set of a map- cache entry, that an SMR from that locator should be responded to by sending the the SMR-invoked Map-Request to the database mapping system rather than to the RLOC itself (which may be unreachable). o When describing Unicast and Multicast Weights indicate the the values are relative weights rather than percentages. So it doesn't imply the sum of all locator weights in the locator-set need to be 100. Farinacci, et al. Expires May 2, 2012 [Page 83] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Do some wordsmithing on copying TTL and TOS fields. o Numerous wordsmithing changes from Dave Meyer. He fine toothed combed the spec. o Removed Section 14 "Prototype Plans and Status". We felt this type of section is no longer appropriate for a protocol specification. o Add clarification text for the IRC description per Damien's commentary. o Remove text on copying nonce from SMR to SMR-invoked Map- Request per Vina's comment about a possible DoS vector. o Clarify (S/2 + H) in the stateless MTU section. o Add text to reflect Damien's comment about the description of the "ITR-RLOC Address" field in the Map-Request. that the list of RLOC addresses are local addresses of the Map-Requester. B.10. Changes to draft-ietf-lisp-07.txt o Posted April 2010. o Added I-bit to data header so LSB field can also be used as an Instance ID field. When this occurs, the LSB field is reduced to 8-bits (from 32-bits). o Added V-bit to the data header so the 24-bit nonce field can also be used for source and destination version numbers. o Added Map-Version 12-bit value to the EID-record to be used in all of Map-Request, Map-Reply, and Map-Register messages. o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR can decide what address to select for the destination of a Map- Reply. o Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to the Locator-Set record of an EID-record for a Map-Reply message. The L-bit indicates which RLOCs in the locator-set are local to the sender of the message. The P-bit indicates which RLOC is the source of a RLOC-probe Reply (Map-Reply) message. o Add reference to the LISP Canonical Address Format [LCAF] draft. Farinacci, et al. Expires May 2, 2012 [Page 84] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Made editorial and clarification changes based on comments from Dhirendra Trivedi. o Added wordsmithing comments from Joel Halpern on DF=3D1 setting. o Add John Zwiebel clarification to Echo Nonce Algorithm section 6.3.1. o Add John Zwiebel comment about expanding on proxy-map-reply bit for Map-Register messages. o Add NAT section per Ron Bonica comments. o Fix IDnits issues per Ron Bonica. o Added section on Virtualization and Segmentation to explain the use if the Instance ID field in the data header. o There are too many P-bits, keep their scope to the packet format description and refer to them by name every where else in the spec. o Scanned all occurrences of "should", "should not", "must" and "must not" and uppercased them. o John Zwiebel offered text for section 4.1 to modernize the example. Thanks Z! o Make it more clear in the definition of "EID-to-RLOC Database" that all ETRs need to have the same database mapping. This reflects a comment from John Scudder. o Add a definition "Route-returnability" to the Definition of Terms section. o In section 9.2, add text to describe what the signature of traceroute packets can look like. o Removed references to Data Probe for introductory example. Data- probes are still part of the LISP design but not encouraged. o Added the definition for "LISP site" to the Definition of Terms" section. Farinacci, et al. Expires May 2, 2012 [Page 85] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 B.11. Changes to draft-ietf-lisp-06.txt Editorial based changes: o Posted December 2009. o Fix typo for flags in LISP data header. Changed from "4" to "5". o Add text to indicate that Map-Register messages must contain a computed UDP checksum. o Add definitions for PITR and PETR. o Indicate an AFI value of 0 is an unspecified address. o Indicate that the TTL field of a Map-Register is not used and set to 0 by the sender. This change makes this spec consistent with [LISP-MS]. o Change "... yield a packet size of L bytes" to "... yield a packet size greater than L bytes". o Clarify section 6.1.5 on what addresses and ports are used in Map- Reply messages. o Clarify that LSBs that go beyond the number of locators do not to be SMRed when the locator addresses are greater lexicographically than the locator in the existing locator-set. o Add Gregg, Srini, and Amit to acknowledgment section. o Clarify in the definition of a LISP header what is following the UDP header. o Clarify "verifying Map-Request" text in section 6.1.3. o Add Xu Xiaohu to the acknowledgment section for introducing the problem of overlapping EID-prefixes among multiple sites in an RRG email message. Design based changes: o Use stronger language to have the outer IPv4 header set DF=3D1 so = we can avoid fragment reassembly in an ETR or PETR. This will also make IPv4 and IPv6 encapsulation have consistent behavior. o Map-Requests should not be sent in ECM with the Probe bit is set. These type of Map-Requests are used as RLOC-probes and are sent Farinacci, et al. Expires May 2, 2012 [Page 86] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 directly to locator addresses in the underlying network. o Add text in section 6.1.5 about returning all EID-prefixes in a Map-Reply sent by an ETR when there are overlapping EID-prefixes configure. o Add text in a new subsection of section 6.1.5 about dealing with Map-Replies with coarse EID-prefixes. B.12. Changes to draft-ietf-lisp-05.txt o Posted September 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. B.13. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? Farinacci, et al. Expires May 2, 2012 [Page 87] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Add Fred Templin in acknowledgment section. o Add Margaret and Sam to the acknowledgment section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom the mailing list: "You'd need to word it as an ITR = MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about spec'ing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o Margaret's comment on gleaning: "The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. Farinacci, et al. Expires May 2, 2012 [Page 88] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map-cache corruption by a 3rd party. Comment from Pedro. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. B.14. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from John Zwiebel in Echo-Nonce section. B.15. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. Farinacci, et al. Expires May 2, 2012 [Page 89] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference [LISP-MN]. B.16. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.17. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires May 2, 2012 [Page 90] =0C Internet-Draft Locator/ID Separation Protocol (LISP) October 2011 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Darrel Lewis cisco Systems 170 Tasman Drive San Jose, CA USA Email: darlewis@cisco.com Farinacci, et al. Expires May 2, 2012 [Page 91] =0C --Apple-Mail=_61F8ED11-9E2E-42CA-9E40-F7FA34D0BD35-- From jari.arkko@piuha.net Sun Oct 30 23:34:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78921F8BEC for ; Sun, 30 Oct 2011 23:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyV2fClfhxCs for ; Sun, 30 Oct 2011 23:34:41 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36621F8C22 for ; Sun, 30 Oct 2011 23:34:41 -0700 (PDT) Received: from localhost (188-67-180-201.bb.dnainternet.fi [188.67.180.201]) by p130.piuha.net (Postfix) with ESMTPSA id 1ABA22CC3B; Mon, 31 Oct 2011 08:34:40 +0200 (EET) Date: Mon, 31 Oct 2011 08:34:00 +0200 Message-ID: From: Jari Arkko To: Dino Farinacci MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 06:34:47 -0000 SWFuYSBzZWN0IGxvb2tzIGdvb2QgKGJ1dCBpIHdpbGwgcmV2aWV3IGxjYWYgcGFydHMgaW4gYW5v dGhlciBlbWFpbCkuIE9uZSBuaXQgdGhvdWdoOiBTZWN0IDE0LCBjaGFuZ2UgaWV0ZiBjb25zZW5z dXMgdG8gaWV0ZiByZXZpZXcuIFRoZSB0ZXJtIGNoYW5nZWQgaW4gcmZjIDUyMjYuCgpKYXJpCgpE aW5vIEZhcmluYWNjaSA8ZGlub0BjaXNjby5jb20+IHdyb3RlOgoKPj4gSSdtIG5vdCBzdXJlIGlm IHdlIGhhdmUgc2VlbiBhIHJlc3BvbnNlLCBidXQgSSBhbHNvIGRvbid0IHRoaW5rIGl0IGlzIGhh cmQgdG8gZGV2ZWxvcCB0aGUgdGV4dCBmb3IgdGhpcy4gVGhpcyBvbmUgbmVlZHMgdG8gZ28gaW4s IGJlY2F1c2Ugb3RoZXJ3aXNlIHdlIGRvbid0IGtub3cgaG93IHRvIG1hbmFnZSB0aGUgbmFtZSBz cGFjZXMuIEl0IGlzIGEgcG90ZW50aWFsIERpc2N1c3MgaXRlbSBmcm9tIHRoZSBvdGhlciBBRHMg b3IgZXZlbiBJQU5BIGlmIHRoZSBwcm9jZXNzIGlzbid0IGNsZWFyLiBIZXJlJ3MgYSBzdHJhd21h biB0ZXh0Ogo+PiAKPj4gSUFOQSBzaG91bGQgY3JlYXRlIGEgcmVnaXN0cnkgZm9yIG1hbmFnaW5n IHRoZSBuZXcgbmFtZXNwYWNlcyB3aXRoaW4gdGhlIExJU1AgcHJvdG9jb2wuIFRoaXMgcmVnaXN0 cnkgY29udGFpbnMgaW5pdGlhbGx5IHRoZSBmb2xsb3dpbmcgdHdvIG5ldyBuYW1lc3BhY2VzLgo+ PiAKPj4gbyAgTmV3IExJU1AgVHlwZSB2YWx1ZXMgKFNlY3Rpb24gNi4xLjEpIGNhbiBiZSBhbGxv Y2F0ZWQgdGhyb3VnaCBJRVRGIFJldmlldyBvciBJRVNHIEFwcHJvdmFsIDx4cmVmIHRhcmdldD0i UkZDNTIyNiIvPi4gU2l4IHZhbHVlcyBoYXZlIGFscmVhZHkgYmVlbiBhbGxvY2F0ZWQgYnkgdGhp cyBzcGVjaWZpY2F0aW9uIChTZWN0aW9uIDYuMS4xKS4KPj4gCj4+IG8gIE5ldyBBQ1QgdmFsdWVz IChTZWN0aW9uIDYuMS40KSBjYW4gYmUgYWxsb2NhdGVkIHRocm91Z2ggSUVURUYgUmV2aWV3IG9y IElFU0cgQXBwcm92YWwuIEZvdXIgdmFsdWVzIGhhdmUgYWxyZWFkeSBiZWVuIGFsbG9jYXRlZCBi eSB0aGlzIHNwZWNpZmljYXRpb24gKFNlY3Rpb24gNi4xLjQpLgo+PiAKPj4gSW4gYWRkaXRpb24s IHRoZSBMSVNQIHByb3RvY29sIGhhcyBhIG51bWJlciBvZiBmbGFnIGFuZCByZXNlcnZlZCBmaWVs ZHMsIHN1Y2ggYXMgdGhlIExJU1AgaGVhZGVyIGZsYWdzIGZpZWxkIChTZWN0aW9uIDUuMykuIE5l dyBiaXRzIGZvciBmbGFncyBjYW4gYmUgdGFrZW4gaW50byB1c2UgZnJvbSB0aGVzZSBmaWVsZHMg dGhyb3VnaCBJRVRGIFJldmlldyBvciBJRVNHIEFwcHJvdmFsLCBidXQgdGhlc2UgbmVlZCBub3Qg YmUgbWFuYWdlZCBieSBJQU5BLgo+Cj5TbyBzZWUgdGhlIGVuY2xvc2VkIGNoYW5nZXMgdG8gdGhl IElBTkEgc2VjdGlvbi4gSSB0aGluayBpdCBpcyBhIGdvb2QgY29tcHJvbWlzZS4KPgo+RGlubwo+ Cj4KPgo+Cg== From dino@cisco.com Sun Oct 30 23:41:19 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DD111E80BB for ; Sun, 30 Oct 2011 23:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTINCNMUeae1 for ; Sun, 30 Oct 2011 23:41:19 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3105511E80B8 for ; Sun, 30 Oct 2011 23:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1636; q=dns/txt; s=iport; t=1320043279; x=1321252879; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KA4mRneAX9TZuEV+Y8n5lwojQ5jiQifYlnL62/8FWtI=; b=LJofN+XupXPq5e9itcwmih7e0STgBbdDEdeaRKdUdzH8wNJcFZQmF0nl +NX+YHPkR8FYCxohRdOSqeqm7gCo54A3kb1sEYmkFKzIozdVMES9fNFh9 eapS3U5ToyoKQs4x3o2B5Q/Qg02pm38OcnKLGMkoLtERhSUILEAkTkH8p I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGtCrk6rRDoJ/2dsb2JhbABDqTGBBYFyAQEBAQIBEgEnPwULCxguVwYTIodglUsBnU6IIWEEiAaMCIUtjFI X-IronPort-AV: E=Sophos;i="4.69,429,1315180800"; d="scan'208";a="11300837" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 31 Oct 2011 06:41:19 +0000 Received: from [10.21.72.4] ([10.21.72.4]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9V6fI2g001944; Mon, 31 Oct 2011 06:41:18 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: Date: Sun, 30 Oct 2011 23:41:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0AFD56AF-5AC6-4FE8-BC7B-A96A04D2A8EF@cisco.com> References: To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 06:41:19 -0000 Done. Dino On Oct 30, 2011, at 11:34 PM, Jari Arkko wrote: > Iana sect looks good (but i will review lcaf parts in another email). = One nit though: Sect 14, change ietf consensus to ietf review. The term = changed in rfc 5226. >=20 > Jari >=20 > Dino Farinacci wrote: >=20 >>> I'm not sure if we have seen a response, but I also don't think it = is hard to develop the text for this. This one needs to go in, because = otherwise we don't know how to manage the name spaces. It is a potential = Discuss item from the other ADs or even IANA if the process isn't clear. = Here's a strawman text: >>>=20 >>> IANA should create a registry for managing the new namespaces within = the LISP protocol. This registry contains initially the following two = new namespaces. >>>=20 >>> o New LISP Type values (Section 6.1.1) can be allocated through = IETF Review or IESG Approval . Six values have = already been allocated by this specification (Section 6.1.1). >>>=20 >>> o New ACT values (Section 6.1.4) can be allocated through IETEF = Review or IESG Approval. Four values have already been allocated by this = specification (Section 6.1.4). >>>=20 >>> In addition, the LISP protocol has a number of flag and reserved = fields, such as the LISP header flags field (Section 5.3). New bits for = flags can be taken into use from these fields through IETF Review or = IESG Approval, but these need not be managed by IANA. >>=20 >> So see the enclosed changes to the IANA section. I think it is a good = compromise. >>=20 >> Dino >>=20 >>=20 >>=20 >>=20 From terry.manderson@icann.org Mon Oct 31 00:06:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF01121F8C8B for ; Mon, 31 Oct 2011 00:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTRhYPC8kXzJ for ; Mon, 31 Oct 2011 00:06:47 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id CE88421F8B3E for ; Mon, 31 Oct 2011 00:06:47 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 31 Oct 2011 00:06:44 -0700 From: Terry Manderson To: Jari Arkko , Dino Farinacci Date: Mon, 31 Oct 2011 00:06:39 -0700 Thread-Topic: [lisp] AD review of draft-ietf-lisp (part 7) Thread-Index: AcyXTYpgQZytahCITeyWdIaDt95x1wAThgwG Message-ID: In-Reply-To: <4EADC5CF.4070505@piuha.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-lisp@tools.ietf.org" , Joel Halpern , "lisp@ietf.org" Subject: Re: [lisp] AD review of draft-ietf-lisp (part 7) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 07:06:48 -0000 Sorry for my Lag, I had a long weekend of ice-hockey officiating. On 31/10/11 7:46 AM, "Jari Arkko" wrote: > Dino, >=20 >>> This is the last part of my review, as far as the actual document conte= nts >>> go. I will send another summary e-mail. >>>=20 >>> Technical: >>>=20 >>>> 14.1. LISP Address Type Codes >>>>=20 >>>> Instance ID type codes have a range from 0 to 15, of which 0 and 1 >>>> have been allocated [LCAF]. New Type Codes MUST be allocated >>>> starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review= . >>>> Type Codes 11 - 15 are available on a First Come First Served polic= y. >>>>=20 >>>> The following codes have been allocated: >>>>=20 >>>> Type 0: Null Body Type >>>>=20 >>>> Type 1: AFI List Type >>>>=20 >>>> See [LCAF] for details for other possible unapproved address >>>> encodings. The unapproved LCAF encodings are an area for further >>>> study and experimentation. >>> To begin with, I did not understand this definition. I'm trying to >>> understand where the LCAF draft actually makes the instance ID allocati= ons, >>> and I can't see it. In addition, the "Null Body Type" string only appea= rs >>> twice in this and the LCAF draft, and neither occurrence explains what = it >>> is. I think something is missing here. >> The source-EID in an RLOC-probe may contain a null body encoding. Becaus= e >> there was no data packet that triggered this Map-Request. I will add tha= t to >> the RLOC-probe section. >>=20 >> Instance-ID is defined in the LCAF draft as Type 2. Here is the packet >> format: >>=20 >> Instance ID LISP Canonical Address Format: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI =3D 16387 | Rsvd1 | Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D 2 | Rsvd2 | 4 + n | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI =3D x | Address ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Length value n: length in bytes of the AFI address that follows the >> Instance ID field including the AFI field itself. >>=20 >> Instance ID: the low-order 24-bits that can go into a LISP data >> header when the I-bit is set. See [LISP] for details. >>=20 >> AFI =3D x: x can be any AFI value from [AFI]. >>=20 >> This LISP Canonical Address Type can be used to encode either EID or >> RLOC addresses. >>=20 >>> Finally, I do not understand why this section is in -lisp. The string "= LISP >>> Address Type Code" does not appear in the rest of the document AFAICT. = The >>> allocations in the LCAF draft seem to be inside a format defined in tha= t >>> draft. Shouldn't the IANA allocations and the creation of the registry= be >>> in that draft as well? This seems particularly important, given that th= e >>> list of types in -lisp does not match the list in -lcaf. >> We (the working group) have decided to put the in-charter values in this >> draft and keep the other values in the LCAF draft. So that is why values= 0 >> and 1 are in this draft. Since instance-ID is part of a VPN use-case, th= is is >> why it is the next value assigned in the LCAF draft. >>=20 >> We received direction from Terry on this since he is expert in registrie= s et >> al. >=20 > I now understand the background, thank you for the explanation. But I thi= nk > the WG still made the wrong call on this. >=20 The important thing was understanding that the header had parts in it which fell (at the time) out of charter - yet still being as complete as possible in documenting what we can. It made very little sense to just specify the Instance ID type codes without pointing to one of the major reasons for having them in the first place. But not stomping all over the charter and making sensitive people angry at us for promulgating the LCAF values direct to an IANA registry without IETF review of the LCAF document. > I would like to play the manager who tells you that the we need to ship y= our > product and this feature still has bugs in it. Lets rip it out and not > endanger our release schedule. In other words, I think other people will = have > the same questions as I did about this part and there is no technical rea= son > why it needs to be here. I don't think the text is harmful by itself, but= I > predict unnecessary questions. Lets remove it and move on. >=20 Perhaps this text helps: Instance ID type codes have a range from 0 to 15, of which 0 and 1 have been allocated. New Type Codes MUST be allocated consecutively starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review or IESG Approval. =20 Type Codes 11 - 15 are available on a First Come First Served policy. The following codes have been allocated: Type 0: Null Body Type Type 1: AFI List Type Since Instance IDs are in the header format with the use of the I bit justifies it. >>=20 >>=20 >>>> 14. IANA Considerations >>> This sections makes the right allocations from other, already existing >>> registries (like UDP port numbers). But it should also define what the >>> policies are for allocating new values with the various new number spac= es >>> that Lisp introduces: >>>=20 >>> - flags >>> - type >>> - reserved >>> - act >>> - unused flags >>> - S >> Terry needs to respond to this. Yes, this needs to be done - sorry I didn't notice it in my review. For all the namespaces, I'm happy with IETF Review or IESG Approval. >=20 > I'm not sure if we have seen a response, but I also don't think it is har= d to > develop the text for this. This one needs to go in, because otherwise we = don't > know how to manage the name spaces. It is a potential Discuss item from t= he > other ADs or even IANA if the process isn't clear. Here's a strawman text= : >=20 > IANA should create a registry for managing the new namespaces within the = LISP > protocol. This registry contains initially the following two new namespac= es. >=20 > o New LISP Type values (Section 6.1.1) can be allocated through IETF Rev= iew > or IESG Approval . Six values have already been > allocated by this specification (Section 6.1.1). >=20 These are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Encapsulated Control Message: 8 b'1000' > o New ACT values (Section 6.1.4) can be allocated through IETEF Review o= r > IESG Approval. Four values have already been allocated by this specificat= ion > (Section 6.1.4). These are: (0) No-Action: The map-cache is kept alive and no packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Unreachable message SHOULD be sent. >=20 > In addition, the LISP protocol has a number of flag and reserved fields, = such > as the LISP header flags field (Section 5.3). New bits for flags can be t= aken > into use from these fields through IETF Review or IESG Approval, > but these need not be managed by IANA. >=20 For binary flags, I agree. For anything that has more than 2 options/types/sub-types and if it hits th= e wire, for interop, I always go looking at what a registry says, to then giv= e me the right set of RFCs to consider for behaviour. Or have I missed your meaning Jari? I would feel much more comfortable with IANA tracking a namespaces than having them sit untracked in RFCs. Cheers Terry From stephen.farrell@cs.tcd.ie Mon Oct 31 04:32:33 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8109B21F8D9D for ; Mon, 31 Oct 2011 04:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXWftWsCOOtq for ; Mon, 31 Oct 2011 04:32:30 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 323CA21F8D86 for ; Mon, 31 Oct 2011 04:32:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D2081171DAB; Mon, 31 Oct 2011 11:32:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1320060747; bh=0x6fzpaRPblqnC AM4MxU+bV8UzawYfTEqX38Hb1mZII=; b=yQ+1AQOMp7NhdHV+pnka1q6BNI2/fX txYFmdDuGE/9VD54Qr+fQxgGKkIxdK2EPSEr2+/dKDizUiepmfuZ47YymSjBsB1G txD6JOLcFbKH0hGYvuzvf7Hq1+1XHETzntn6TNYTEoyx2pQYN8ZZ2I4QVYX1FQ1J MsAgCfQ2EW4f+Q+D2dozCbNAwNoJCwZB8P9q1TSxAPl1GqKBij143GlNqStES8qb rMwSHjFXMC+jvGW7LwXwYzeNZav/I6fWQdLz8cYaAV7dI4YiW8aXQ1JT4ObHUU0j gMrcG/1nb5GptxOSuqyuA/1knSzyX9iYzcFeu8IXNTpccmkdjr1FrRJQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id N7zcrpDZ3jnz; Mon, 31 Oct 2011 11:32:27 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.45.58.43]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3AD21171D33; Mon, 31 Oct 2011 11:32:25 +0000 (GMT) Message-ID: <4EAE8749.2050800@cs.tcd.ie> Date: Mon, 31 Oct 2011 11:32:25 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4EA1FF24.7000902@piuha.net> <24DD9327-60B2-4B35-A723-8E36C0AA82F9@cisco.com> <4EADBE3A.9080900@piuha.net> <2E2FF625-FD32-46B3-809A-268DA6356039@cisco.com> In-Reply-To: <2E2FF625-FD32-46B3-809A-268DA6356039@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp@tools.ietf.org, Joel Halpern , lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp (part 6) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 11:32:33 -0000 Dino, On 10/31/2011 05:01 AM, Dino Farinacci wrote: >>>>> This experimental specification does not address automated key >>>>> management (AKM).BCP 107 provides guidance in this area. >>>> Yes, but I think we should include two additional important pieces of information. 1. you need to acknowledge that you are not following BCP 107 in this case, as it requires AKM under certain conditions (we are within those conditions, right?). And 2) more importantly, you need to document the implications of not providing AKM. Personally, I do not necessarily consider it a panacea, and often the nonce etc. mechanisms are far more important. In any case, the reader needs to understand what we are losing without AKM. >>> This text was created, accepted, and agreed upon from the security ADs. So I dare not to touch it. I'm not at all sure I agree about the genesis of that text, but it was the result of a protracted set of exchanges, (starting from what I thought was worse text:-), so I can understand not wanting to do that again. However, you can "dare" if you like - its just text and can no doubt be improved. In particular, Jari's suggested (2) above I think (might be wrong since I didn't look) was something I also wanted during that protracted discussion. So while Jari and I may disagree as to whether or not AKM is an issue here or not, I think we do agree that documenting the consequences of not having AKM would be an improvement. But, I did agree the current text without that so I'll live with leaving it as it is I guess if that's what the WG want. S. From internet-drafts@ietf.org Mon Oct 31 06:18:46 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD321F8C72; Mon, 31 Oct 2011 06:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgXH1TxHbZYB; Mon, 31 Oct 2011 06:18:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC9E21F8C30; Mon, 31 Oct 2011 06:18:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031131845.17420.3509.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 06:18:45 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:18:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP EID Block Author(s) : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-01.txt Pages : 10 Date : 2011-10-31 This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used by sites deploying LISP as EID (Endpoint IDentifier) addressing space for local intra-domain routing and global endpoint identification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt From luigi@net.t-labs.tu-berlin.de Mon Oct 31 06:21:15 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537FE21F8AFF for ; Mon, 31 Oct 2011 06:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmbx9lECmcyD for ; Mon, 31 Oct 2011 06:21:12 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 706DE21F85AA for ; Mon, 31 Oct 2011 06:21:11 -0700 (PDT) Received: from dyn112.net.t-labs.tu-berlin.de (dyn112.net.t-labs.tu-berlin.de [130.149.220.112]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id BD46070000E1 for ; Mon, 31 Oct 2011 14:21:09 +0100 (CET) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_22F92F7B-C36C-4A89-8EE1-396EFFE86DF3" Date: Mon, 31 Oct 2011 14:21:13 +0100 References: <20111031131845.17420.3509.idtracker@ietfa.amsl.com> To: lisp@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-eid-block-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:21:15 -0000 --Apple-Mail=_22F92F7B-C36C-4A89-8EE1-396EFFE86DF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, attached you can find the diff of the draft compared to previous = version. ciao Luigi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-01.txt > Date: October 31, 2011 14:18:45 GMT+01:00 > To: i-d-announce@ietf.org > Cc: lisp@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF. >=20 > Title : LISP EID Block > Author(s) : Luigi Iannone > Darrel Lewis > David Meyer > Vince Fuller > Filename : draft-ietf-lisp-eid-block-01.txt > Pages : 10 > Date : 2011-10-31 >=20 > This is a direction to IANA to allocate a /16 IPv6 prefix for use > with the Locator/ID Separation Protocol (LISP). The prefix will be > used by sites deploying LISP as EID (Endpoint IDentifier) addressing > space for local intra-domain routing and global endpoint > identification. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_22F92F7B-C36C-4A89-8EE1-396EFFE86DF3 Content-Type: multipart/mixed; boundary="Apple-Mail=_3A7A565F-1E92-44DD-A461-026D46E72F08" --Apple-Mail=_3A7A565F-1E92-44DD-A461-026D46E72F08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

attached you can find the diff of the draft = compared to previous = version.

ciao

Luigi



Begin forwarded = message:

Subject: [lisp] I-D Action: = draft-ietf-lisp-eid-block-01.txt
Date: October 31, 2011 = 14:18:45 GMT+01:00

A= New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF.

Title =           : LISP EID = Block
= Author(s)       : Luigi Iannone
=             &n= bsp;           &nbs= p;Darrel Lewis
=             &n= bsp;           &nbs= p;David Meyer
=             &n= bsp;           &nbs= p;Vince Fuller
Filename =        : = draft-ietf-lisp-eid-block-01.txt
Pages =           : = 10
= Date =            : = 2011-10-31

  This is a direction to IANA to allocate a = /16 IPv6 prefix for use
  with the Locator/ID Separation = Protocol (LISP).  The prefix will be
  used by sites = deploying LISP as EID (Endpoint IDentifier) addressing
=   space for local intra-domain routing and global endpoint
=   identification.


A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-01.txt=
_______________________________________________
lisp mailing = list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
= --Apple-Mail=_3A7A565F-1E92-44DD-A461-026D46E72F08 Content-Disposition: attachment; filename=WDiff-00-01.html Content-Type: text/html; x-mac-hide-extension=yes; x-unix-mode=0644; name="WDiff-00-01.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-eid-block-00-submitted.txt draft-ietf-lisp-eid-block-01.txt 

Network Working Group                                         L. Iannone
Internet-Draft                             Deutsche                           Telekom Innovation Laboratories
Intended status: Informational                                  D. Lewis
Expires: January May 3, 2012                                            D. Meyer
                                                               V. Fuller
                                                     Cisco Systems, Inc.
                                                            July 2,
                                                        October 31, 2011

                             LISP EID Block
                      draft-lisp-eid-block-00.txt
                    draft-ietf-lisp-eid-block-01.txt

Abstract

   This is a direction to IANA to allocate a /16 IPv6 prefix for use
   with the Locator/ID Separation Protocol (LISP).  The prefix will be
   used by sites deploying LISP as EID (Endpoint IDentifier) addressing
   space for local intra-domain routing and global endpoint
   identification.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January May 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Rationale and Intent . . . . . . . . . . . . . . . . . . . . .  5
   5.  Expected use . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Action Plan  Block Dimension  . . . . . . . . . . . . . . . . . . . . . . .  6
   7.  Action Plan  . . . . . 6
   7.  Routing Considerations . . . . . . . . . . . . . . . . . . . .  7
   8.  Security  Routing Considerations . . . . . . . . . . . . . . . . . . . .  7
   9.  Acknowledgments  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   10. Acknowledgments  . . . . . 7
   10. . . . . . . . . . . . . . . . . . .  8
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   12. References . 7
   11. . . . . . . . . . . . . . . . . . . . . . . . . .  8
     12.1.  Normative References  . . . . . . . . . . . . . . . . . .  8
     12.2.  Informative References  . . . 8 . . . . . . . . . . . . . .  9
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 8  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 10

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

   This document directs the IANA to allocate a /16 IPv6 prefix for use
   with the Locator/ID Separation Protocol (LISP - [I-D.ietf-lisp]),
   LISP Map Server ([I-D.ietf-lisp-ms]), LISP Alternative Topology
   (LISP+ALT - [I-D.ietf-lisp-alt]) (or other) mapping system, and LISP
   Interworking ([I-D.ietf-lisp-interworking]).

   This block will be used as global Endpoint IDentifier (EID) space
   (Section 3).

3.  Definition of Terms

   LISP operates on two name spaces and introduces several new network
   elements.  This section provides high-level definitions of the LISP
   name spaces and network elements and as such, it MUST NOT be
   considered as an authoritative source.  The reference to the
   authoritative document for each term is included in every term
   description.

   Legacy Internet:  The portion of the Internet which does not run LISP
      and does not participate in LISP+ALT or any other mapping system.

   LISP site:  A LISP site is a set of routers in an edge network that
      are under a single technical administration.  LISP routers that
      reside in the edge network are the demarcation points to separate
      the edge network from the core network.  See [I-D.ietf-lisp] for
      more details.

    Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  A packet that is
      emitted by a system contains EIDs in its headers and LISP headers
      are prepended only when the packet reaches an Ingress Tunnel
      Router (ITR) on the data path to the destination EID.  The source
      EID is obtained via existing mechanisms used to set a host's
      "local" IP address.  An EID is allocated to a host from an EID-
      prefix block associated with the site where the host is located.
      See [I-D.ietf-lisp] for more details.

   EID-prefix:  A power-of-two block of EIDs that are allocated to a
      site by an address allocation authority.  See [I-D.ietf-lisp] for
      more details.

   EID-Prefix Aggregate:  A set of EID-prefixes said to be aggregatable
      in the [RFC4632] sense.  That is, an EID-Prefix aggregate is
      defined to be a single contiguous power-of-two EID-prefix block.
      Such a block is characterized by a prefix and a length.  See
      [I-D.ietf-lisp] for more details.

   Routing LOCator (RLOC):  A RLOC is an IPv4 or IPv6 address of an
      egress tunnel router (ETR).  A RLOC is the output of an EID-to-
      RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Aggregatable (PA) addresses.  See [I-D.ietf-lisp] for
      more details.

    EID-to-RLOC Mapping:  A binding between an EID-Prefix and the RLOC-
      set that can be used to reach the EID-Prefix.  The general term
      "mapping" always refers to an EID-to-RLOC mapping.  See
      [I-D.ietf-lisp] for more details.

   Ingress Tunnel Router (ITR):  An Ingress Tunnel Router (ITR) is a
      router that accepts receives IP packets from site end-systems on
      one side and sends LISP-encapsulated IP packets toward the
      Internet on the other side.  The router treats the "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      See [I-D.ietf-lisp] for more details.

   Egress Tunnel Router (ETR):  An Egress Tunnel Router (ETR) receives
      LISP-encapsulated IP packets from the Internet on one side and
      sends decapsulated IP packets to site end-systems on the other
      side.  An ETR router accepts an IP packet where the destination
      address in the "outer" IP header is one of its own RLOCs.  The
      router strips the "outer" header and forwards the packet based on
      the next IP header found.  See [I-D.ietf-lisp] for more details.

   Proxy ITR (PITR):  A Proxy-ITR (PITR) acts like an ITR but does so on
      behalf of non-LISP sites which send packets to destinations at
      LISP sites.  See [I-D.ietf-lisp-interworking] for more details.

   Proxy ETR (PETR):  A Proxy-ETR (PETR) acts like an ETR but does so on
      behalf of LISP sites which send packets to destinations at non-
      LISP sites.  See [I-D.ietf-lisp-interworking] for more details.

   Map Server (MS):  A network infrastructure component that learns EID-
      to-RLOC mapping entries from an authoritative source (typically an
      ETR).  A Map-Server publishes these mappings in the distributed
      mapping system.  See [I-D.ietf-lisp-ms] for more details.

   Map Resolver (MR):  A network infrastructure component that accepts
      LISP Encapsulated Map-Requests, typically from an ITR, quickly
      determines whether or not the destination IP address is part of
      the EID namespace; if it is not, a Negative Map-Reply is
      immediately returned.  Otherwise, the Map-Resolver finds the
      appropriate EID-to-RLOC mapping by consulting the distributed
      mapping database system.  See [I-D.ietf-lisp-ms] for more details.

   The LISP Alternative Logical Topology (ALT):  The virtual overlay
      network made up of tunnels between LISP+ALT Routers.  The Border
      Gateway Protocol (BGP) runs between ALT Routers and is used to
      carry reachability information for EID-prefixes.  The ALT provides
      a way to forward Map-Requests toward the ETR that "owns" an EID-
      prefix.  See [I-D.ietf-lisp-alt] for more details.

   ALT Router:  The device on which runs the ALT.  The ALT is a static
      network built using tunnels between ALT Routers.  These routers
      are deployed in a roughly-hierarchical mesh in which routers at
      each level in the topology are responsible for aggregating EID-
      Prefixes learned from those logically "below" them and advertising
      summary prefixes to those logically "above" them.  Prefix learning
      and propagation between ALT Routers is done using BGP.  When an
      ALT Router receives an ALT Datagram, it looks up the destination
      EID in its forwarding table (composed of EID-Prefix routes it
      learned from neighboring ALT Routers) and forwards it to the
      logical next-hop on the overlay network.  The primary function of
      LISP+ALT routers is to provide a lightweight forwarding
      infrastructure for LISP control-plane messages (Map-Request and
      Map-Reply), and to transport data packets when the packet has the
      same destination address in both the inner (encapsulating)
      destination and outer destination addresses ((i.e., a Data Probe
      packet).  See [I-D.ietf-lisp-alt] for more details.

4.  Rationale and Intent

   With the current specifications, if an ITR is sending to all types of
   destinations (i.e., non-LISP destinations, LISP destinations not in
   the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the
   only way to understand whether or not to encapsulate the traffic is
   to perform a cache lookup and, in case of cache-miss, send a Map-
   Request to the mapping system.  In the meanwhile, packets can be
   dropped.

   By defining an IPv6 EID Block is possible to configure the router so
   to natively forward all packets that have not a destination address
   in the block, without performing any lookup whatsoever.  This will
   give a tighter control over the traffic in the initial experimental
   phase, while facilitating its large-scale deployment.

   The EID Block will be used only at configuration level, it is
   RECOMMENDED not to hard-code in any way the IPv6 EID Block in the
   router hardware.  This allows to avoid locking out sites that may
   want to switch to LISP while keeping their own IPv6 prefix, which is
   not in the IPv6 EID Block.

5.  Expected use

   Sites planning to deploy LISP may request a prefix in the IPv6 EID
   Block.  Such prefix will be used for routing and endpoint
   identification inside the site requesting it.  Mappings related to
   such prefix, or part of it, will be made available through the
   mapping system in use or registered to one or more Map-Server(s).
   Too guarantee reachability from the Legacy Internet the prefix could
   be announced in the BGP routing infrastructure by one or more
   PITR(s), possibly as part of a larger prefix, aggregating several
   prefixes of several sites.

6.  Block Dimension

   The working group reached consensus on an initial allocation of a /16
   prefix out of a /12 block which is asked to remain reserved for
   future use as EID b space.  The reason of such consensus is manifold:

   o  A /16 prefix is suffiently large to cover initial allocation and
      requests for prefoxes in the EID space in the next few years for
      very large scale experimentation and deployment.  As a comparison
      is worth to mention that the current LISP Beta Network ([BETA]) is
      using a /32 prefix, hence a /16 should be sufficiently large to
      accomodate growth in the near future.

   o  The request to reserve the /12 prefix covering the initial /16
      allocation is in line with IANA policies that fix to /12 the
      minimum IPv6 allocation.

   o  The proposed alignment provides as well a natural support for DNS.
      In particular, reverse DNS for IPv6 in the special ip6.arpa domain
      is represented as sequence of nibbles.  A different alignment
      would force to a binary representation.

7.  Action Plan

   This document requests IANA to initially allocate a /16 prefix out of
   the IPv6 addressing space for use as EID in LISP (Locator/ID
   Separation protocol).  It is suggested to IANA to temporarily avoid
   allocating any other address block the same /12 prefix the EID /16
   prefix belongs to.  This is to accommodate future requests of EID
   space without fragmenting the EID addressing space.  This will also
   help from an operational point of view, since it will be sufficient
   to change the subnet mask length in existing deployments.

   If in the future there will be need for a larger EID Block the
   address space adjacent the EID Block could be allocate by IANA
   according to the current policies.

7.

8.  Routing Considerations

   In order to provide connectivity between the Legacy Internet and LISP
   sites, PITRs announcing large aggregates of the IPv6 EID Block could
   be deployed.  By doing so, PITRs will attract traffic destined to
   LISP sites in order to encapsulate and forward it toward the specific
   destination LISP site.  Routers in the Legacy Internet MUST treat
   announcements of prefixes from the IPv6 EID Block as normal
   announcements, applying best current practice for traffic engineering
   and security.

   Even in a LISP site, not all routers need to run LISP elements.  In
   particular, routers that are not at the border of the local domain,
   used only for intra-domain routing, do not need to provide any
   specific LISP functionality but MUST be able to route traffic using
   addresses in the IPv6 EID Block.

   For the above-mentioned reasons, routers that do not run any LISP
   element, MUST NOT include any special handling code or hardware for
   addresses in the IPv6 EID Block.  In particular, it is RECOMMENDED
   that the default router configuration does not handle such addresses
   in any special way.  Doing differently could prevent communication
   between the Legacy Internet and LISP sites or even break local intra-
   domain connectivity.

8.

9.  Security Considerations

   This document does not introduce new security threats in the LISP
   architecture nor in the Legacy Internet architecture.

9.

10.  Acknowledgments

   Special thanks to Roque Gagliano for his suggestions and pointers to
   the IANA allocation policies.  Thanks to Marla Azinger, Chris Morrow,
   and Peter Schoenmaker Schoenmaker, all made insightful comments on early versions
   of this draft.

10.

11.  IANA Considerations

   This document instructs the IANA to assign a /16 IPv6 prefix for use
   as the global LISP EID space using an hierarchical allocation as
   outlined in [RFC2434].  During the discussion related to this
   document, the LISP Working Group agreed in suggesting to IANA to
   reserve adjacent addressing space for future use as EID space if
   needs come.  Following the policies outlined in [RFC2434], such space
   will be assigned only upon IETF Consensus.  This document does not
   specify any specific value for the requested address block.

11.

12.  References

12.1.  Normative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-14
              draft-ietf-lisp-15 (work in progress), June July 2011.

   [I-D.ietf-lisp-alt]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07 draft-ietf-lisp-alt-06
              (work in progress), June March 2011.

   [I-D.ietf-lisp-interworking]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-02 (work in progress),
              June 2011.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-09 Server Interface",
              draft-ietf-lisp-ms-12 (work in progress), June October 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

12.2.  Informative References

   [BETA]     LISP Beta Network, "http://www.lisp4.net", 2008-2011.

Appendix A.  Document Change Log

   Version 01 Posted October 2011.

   o  Added Section 6.

   Version 00 Posted July 2011.

   o  Updated section "IANA Considerations"

   o  Added section "Rationale and Intent" explaining why the EID block
      allocation is useful.

   o  Added section "Expected Use" explaining how sites can request and
      use a prefix in the IPv6 EID Block.

   o  Added section "Action Plan" suggesting IANA to avoid allocating
      address space adjacent the allocated EID block in order to
      accommodate future EID space requests.

   o  Added section "Routing Consideration" describing how routers not
      running LISP deal with the requested address block.

   o  Added the present section to keep track of changes.

   o  Rename of draft-meyer-lisp-eid-block-02.txt.

Authors' Addresses

   Luigi Iannone
   Deutsche
   Telekom Innovation Laboratories

   Email: luigi@net.t-labs.tu-berlin.de

   Darrel Lewis
   Cisco Systems, Inc.

   Email: darlewis@cisco.com

   David Meyer
   Cisco Systems, Inc.

   Email: dmm@cisco.com

   Vince Fuller
   Cisco Systems, Inc.

   Email: vaf@cisco.com
--Apple-Mail=_3A7A565F-1E92-44DD-A461-026D46E72F08 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_3A7A565F-1E92-44DD-A461-026D46E72F08-- --Apple-Mail=_22F92F7B-C36C-4A89-8EE1-396EFFE86DF3-- From internet-drafts@ietf.org Mon Oct 31 09:53:07 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8811E8120; Mon, 31 Oct 2011 09:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkWuaO8p-YSS; Mon, 31 Oct 2011 09:53:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9872611E80EA; Mon, 31 Oct 2011 09:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031165305.12363.78595.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 09:53:05 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:53:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map-Versioning Author(s) : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-map-versioning-06.txt Pages : 23 Date : 2011-10-31 This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-06.txt From luigi@net.t-labs.tu-berlin.de Mon Oct 31 09:56:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7144E11E8120 for ; Mon, 31 Oct 2011 09:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs5RYXDU0K1v for ; Mon, 31 Oct 2011 09:56:23 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id C37D311E8109 for ; Mon, 31 Oct 2011 09:56:22 -0700 (PDT) Received: from dyn112.net.t-labs.tu-berlin.de (dyn112.net.t-labs.tu-berlin.de [130.149.220.112]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 2273B70000E1 for ; Mon, 31 Oct 2011 17:56:11 +0100 (CET) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_C8AC2CA5-842B-41C3-9DB9-CF2F31F9C9DA" Date: Mon, 31 Oct 2011 17:56:14 +0100 References: <20111031165305.12363.78595.idtracker@ietfa.amsl.com> To: lisp@ietf.org Message-Id: <3E8FD0F6-5629-4181-B37E-624838EBABA9@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-map-versioning-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:56:27 -0000 --Apple-Mail=_C8AC2CA5-842B-41C3-9DB9-CF2F31F9C9DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, The document has been changed according with the DISCUSS of the IESG. Attached the diff from the previous version for an easy reading of the = differences. ciao Luigi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-06.txt > Date: October 31, 2011 17:53:05 GMT+01:00 > To: i-d-announce@ietf.org > Cc: lisp@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF. >=20 > Title : LISP Map-Versioning > Author(s) : Luigi Iannone > Damien Saucez > Olivier Bonaventure > Filename : draft-ietf-lisp-map-versioning-06.txt > Pages : 23 > Date : 2011-10-31 >=20 > This document describes the LISP (Locator/ID Separation Protocol) > Map-Versioning mechanism, which provides in-packet information about > Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to > encapsulate LISP data packets. The proposed approach is based on > associating a version number to EID-to-RLOC mappings and transport > such a version number in the LISP specific header of LISP- > encapsulated packets. LISP Map-Versioning is particularly useful to > inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel > Routers (ETRs) about modifications of the mappings used to > encapsulate packets. The mechanism is transparent to = implementations > not supporting this feature, since in the LISP-specific header and = in > the Map Records, bits used for Map-Versioning can be safely ignored > by ITRs and ETRs that do not support the mechanism. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-06.txt > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_C8AC2CA5-842B-41C3-9DB9-CF2F31F9C9DA Content-Type: multipart/mixed; boundary="Apple-Mail=_7CFD627F-7C8C-4130-923D-2FAA160B2310" --Apple-Mail=_7CFD627F-7C8C-4130-923D-2FAA160B2310 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

The document has been changed according with the = DISCUSS of the IESG.

Attached the diff from the = previous version for an easy reading of the = differences.

ciao

Luigi<= /div>


Begin forwarded message:

Subject: [lisp] I-D Action: = draft-ietf-lisp-map-versioning-06.txt
Date: October 31, 2011 = 17:53:05 GMT+01:00

A= New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF.

Title =           : LISP = Map-Versioning
Author(s) =       : Luigi Iannone
=             &n= bsp;           &nbs= p;Damien Saucez
=             &n= bsp;           &nbs= p;Olivier Bonaventure
Filename =        : = draft-ietf-lisp-map-versioning-06.txt
Pages =           : = 23
= Date =            : = 2011-10-31

  This document describes the LISP = (Locator/ID Separation Protocol)
  Map-Versioning = mechanism, which provides in-packet information about
=   Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used = to
  encapsulate LISP data packets.  The proposed = approach is based on
  associating a version number to = EID-to-RLOC mappings and transport
  such a version number = in the LISP specific header of LISP-
  encapsulated = packets.  LISP Map-Versioning is particularly useful to
=   inform communicating Ingress Tunnel Routers (ITRs) and = Egress Tunnel
  Routers (ETRs) about modifications of the = mappings used to
  encapsulate packets.  The = mechanism is transparent to implementations
  not = supporting this feature, since in the LISP-specific header and in
=   the Map Records, bits used for Map-Versioning can be safely = ignored
  by ITRs and ETRs that do not support the = mechanism.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versionin= g-06.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-0= 6.txt
_______________________________________________
lisp mailing = list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
= --Apple-Mail=_7CFD627F-7C8C-4130-923D-2FAA160B2310 Content-Disposition: attachment; filename=WDiff-05-06.html Content-Type: text/html; name="WDiff-05-06.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-map-versioning-05.txt draft-ietf-lisp-map-versioning-06.txt 

Network Working Group                                         L. Iannone
Internet-Draft                              TU Berlin - Deutsche                           Telekom Innovation Laboratories
Intended status: Experimental                            Laboratories AG
Expires: April 15, 2012                                  D. Saucez
Expires: May 3, 2012                                      O. Bonaventure
                                        Universite catholique de Louvain
                                                        October 13, 31, 2011

                          LISP Map-Versioning
                 draft-ietf-lisp-map-versioning-05.txt
                 draft-ietf-lisp-map-versioning-06.txt

Abstract

   This document describes the LISP (Locator/ID Separation Protocol)
   Map-Versioning mechanism, which provides in-packet information about
   Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to
   encapsulate LISP data packets.  The proposed approach is based on
   associating a version number to EID-to-RLOC mappings and transport
   such a version number in the LISP specific header of LISP-
   encapsulated packets.  LISP Map-Versioning is particularly useful to
   inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel
   Routers (ETRs) about modifications of the mappings used to
   encapsulate packets.  The mechanism is transparent to legacy
   implementations, implementations
   not supporting this feature, since in the LISP-specific header and in
   the Map Records, bits used for Map-Versioning can be safely ignored
   by ITRs and ETRs that do not support the mechanism.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 15, May 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions of Terms . . . . . . . . . . . . . . . . . . . . .  4
   4.  EID-to-RLOC Map-Version number . . . . . . . . . . . . . . . .  4
     4.1.  The Null Map-Version . . . . . . . . . . . . . . . . . . .  5
   5.  Dealing with Map-Version numbers . . . . . . . . . . . . . . .  6
     5.1.  Handling Destination Map-Version number  . . . . . . . . .  7
     5.2.  Handling Source Map-Version number . . . . . . . . . . . .  9
   6.  LISP header and Map-Version numbers  . . . . . . . . . . . . .  9 10
   7.  Map Record and Map-Version . . . . . . . . . . . . . . . . . . 10
   8.  Benefits and case studies for Map-Versioning . . . . . . . . . 11
     8.1.  Synchronization of different xTRs  . . . . . . . . . . . . 11
     8.2.  Map-Versioning and unidirectional traffic  . . . . . . . . 12
     8.3.  Map-Versioning and interworking  . . . . . . . . . . . . . 13
       8.3.1.  Map-Versioning and Proxy-ITRs  . . . . . . . . . . . . 13
       8.3.2.  Map-Versioning and LISP-NAT  . . . . . . . . . . . . . 14
       8.3.3.  Map-Versioning and Proxy-ETRs  . . . . . . . . . . . . 14
     8.4.  RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 15
     8.5.  Map-Version for lightweight LISP implementation  . . . . . 15
   9.  Incremental deployment and implementation status . . . . . . . 16
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
     10.1. Map-Versioning against traffic disruption  . . . . . . . . 16
     10.2. Map-Versioning against reachability information DoS  . . . 17
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17 18
   12. Open Issues and Considerations . . . . . . . . . . . . . . . . 18
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   13. 18
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     13.1.
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     13.2.
     14.2. Informative References . . . . . . . . . . . . . . . . . . 18 19
   Appendix A.  Estimation of time before Map-Version wrap-around . . 18 19
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 19 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 22

1.  Introduction

   This document describes the Map-Versioning mechanism used to provide
   information on changes in the EID-to-RLOC mappings used in the LISP
   ([I-D.ietf-lisp]) context to perform packet encapsulation.  The
   mechanism is totally transparent to xTRs not supporting such
   functionality.  It is not meant to replace any existing LISP
   mechanism, but rather to extend them providing new functionalities.
   If for any unforseen reason a normative conflict between the present
   document and the LISP main specifications is found, the latter
   ([I-D.ietf-lisp]) has precedence on the present document.

   The basic mechanism is to associate a Map-Version number to each LISP
   EID-to-RLOC mapping and transport such a version number in the LISP-
   specific header.  When a mapping changes, a new version number is
   assigned to the updated mapping.  A change in an EID-to-RLOC mapping
   can be a change in the RLOCs set, by adding or removing one or more
   RLOCs, but it can also be a change in the priority or weight of one
   or more RLOCs.

   When Map-Versioning is used, LISP-encapsulated data packets contain
   the version number of the two mappings used to select the RLOCs in
   the outer header (i.e., both source and destination).  These version
   numbers are encoded in the 24 low-order bits of the first longword of
   the LISP header and indicated by a specific bit in the flags (first 8
   high-order bits of the first longword of the LISP header).  Note that
   not all packets need to carry version numbers.

   When an ITR encapsulates a data packet, with a LISP header containing
   the Map-Version numbers, it puts in the LISP-specific header two
   version numbers:

   1.  The version number assigned to the mapping (contained in the EID-
       to-RLOC Database) used to select the source RLOC.

   2.  The version number assigned to the mapping (contained in the EID-
       to-RLOC Cache) used to select the destination RLOC.

   This operation is two-fold.  On the one hand, it enables the ETR
   receiving the packet to know if the ITR has the latest version number
   that any ETR at the destination EID site has provided to the ITR in a
   Map-Reply.  If it is not the case the ETR can send to the ITR a Map-
   Request containing the updated mapping or soliciting a Map-Request
   from the ITR (both cases are already defined in [I-D.ietf-lisp]).  In
   this way the ITR can update its cache. EID-to-RLOC Cache.  On the other
   hand, it enables an ETR receiving such a packet to know if it has in
   its EID-to-RLOC Cache the latest mapping for the source EID (in case
   of bidirectional traffic).  If it is not the case a Map-Request can
   be sent.

   Issues and concerns about the deployment of LISP for Internet traffic
   are discussed in [I-D.ietf-lisp].  Section 12 provides additional
   issues and concerns raised by this document.

2.  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].

3.  Definitions of Terms

   The present document uses terms already defined in main LISP
   specification [I-D.ietf-lisp].  Hereafter are defined only the terms
   that are specific to the Map-Versioning mechanism.  Throughout the
   whole document Big Endian bit ordering is used.

   Map-Version number:  An unsigned 12-bits assigned to an EID-to-RLOC
      mapping, not including the value 0 (0x000).

   Null Map-Version:  The 12-bits null value of 0 (0x000) is not used as
      Map-Version number.  It is used to signal that no Map-Version
      number is assigned to the EID-to-RLOC mapping.

   Source Map-Version number:  Map-Version number of the EID-to-RLOC
      mapping used to select the source address (RLOC) of the outer IP
      header of LISP-encapsulated packets.

   Destination Map-Version number:  Map-Version number of the EID-to-
      RLOC mapping used to select the destination address (RLOC) of the
      outer IP header of LISP-encapsulated packets.

4.  EID-to-RLOC Map-Version number

   The EID-to-RLOC Map-Version number consists in an unsigned 12-bits
   integer.  The version number is assigned on a per-mapping basis,
   meaning that different mappings have a different version number,
   which is also updated independently.  An update in the version number
   (i.e., a newer version) consists in incrementing by one the older
   version number.  Appendix A contains a rough estimation of the wrap-
   around time for the Map-Version number.

   The space of version numbers has a circular order where half of the
   version numbers is greater(i.e., newer) than the current Map-Version
   number and the other half is smaller (i.e., older) than current Map-
   Version number.  In a more formal way, assuming we have two version
   numbers V1 and V2 and that the numbers are expressed on N bits, the
   following steps MUST be performed (in the same order as hereafter) to
   strictly define their order:

   1.  V1 = V2 : The map-version number are the same.

   2.  V2 > V1 : if and only if

          V2 > V1 AND (V2 - V1) <= 2**(N-1)

          OR

          V1 > V2 AND (V1 - V2) > 2**(N-1)

   3.  V1 > V2 : otherwise.

   Using 12 bits, as defined in this document, and assuming a Map-
   Version value of 69, Map-Version numbers in the range [70; 69 + 2048]
   are greater than 69, while Map-Version numbers in the range [69 +
   2049; (69 + 4096) mod 4096] are smaller than 69.

   Map-version number are assigned to mappings by configuration.  The
   initial Map-Version number of a new EID-to-RLOC mapping SHOULD be
   assigned randomly, but it MUST NOT be set to the Null Map-Version
   value (0x000), because it has a special meaning (see Section 4.1).

   Upon reboot, an ETR will use mappings configured in its EID-to-RLOC
   Database.  If those mappings have a Map-Version number, it will be
   used according to the mechnisms described in this document.  ETRs
   MUST NOT automatically generate and assign Map-Version numbers to
   mappings in the EID-to-RLOC Database.

4.1.  The Null Map-Version

   The value 0x000 (zero) is not a valid Map-Version number indicating
   the version of the EID-to-RLOC mapping.  Such a value is used for
   special purposes and is named the Null Map-Version number.

   The Null Map-Version MAY appear in the LISP specific header as either
   Source Map-Version number (cf. Section 5.2) or Destination Map-
   Version number (cf. Section 5.1).  When the Source Map-Version number
   is set to the Null Map-version value it means that no map version
   information is conveyed for the source site.  This means that if a
   mapping exists for the source EID in the EID-to-RLOC Cache, then the
   ETR MUST NOT compare the received Null Map-Version with the content
   of the EID-to-RLOC cache. Cache.  When the Destination Map-version number is
   set to the Null Map-version value it means that no map version
   information is conveyed for the destination site.  This means that
   the ETR MUST NOT compare the value with the Map-Version number of the
   mapping for the destination EID present in the EID-to-RLOC Database.

   The other use of the Null Map-Version number is in the Map Records,
   which are part of the Map-Request, Map-Reply and Map-Register
   messages (defined in [I-D.ietf-lisp]).  Map Records that have a Null
   Map-Version number indicate that there is no Map-Version number
   associated with the mapping.  This means that LISP encapsulated
   packets, destined to the EID-Prefix the Map Record refers to, MUST
   either not contain any Map-Version numbers (V bit set to 0), or if it
   contains Map-Version numbers (V bit set to 1) then the destination
   Map-Version number MUST be set to the Null Map-Version number.  Any
   value different from zero means that Map-Versioning is supported and
   MAY be used.

   The fact that the 0 value has a special meaning for the Map-Version
   number implies that, when updating a Map-Version number because of a
   change in the mapping, if the next value is 0 then Map-Version number
   MUST be incremented by 2 (i.e., set to 1, which is the next valid
   value).

5.  Dealing with Map-Version numbers

   The main idea of using Map-Version numbers is that whenever there is
   a change in the mapping (e.g., adding/removing RLOCs, a change in the
   weights due to TE policies, or a change in the priorities) or a LISP
   site realizes that one or more of its own RLOCs are not reachable
   anymore from a local perspective (e.g., through IGP, or policy
   changes) the LISP site updates the mapping also assigning a new Map-
   Version number.

   To each mapping, a version number is associated and changes each time
   the mapping is changed.  Note that map-versioning does not introduce
   new problems concerning the coordination of different ETRs of a
   domain.  Indeed, ETRs belonging to the same LISP site must return for
   a specific EID-prefix the same mapping, including the same Map-
   Version number.  In principle this is orthogonal to whether or not
   map-versioning is used.  The synchronization problem and its
   implication on the traffic is out of the scope of this document. document (see
   Section 12).

   In order to announce in a data-driven fashion that the mapping has
   been updated, Map-Version numbers used to create the outer IP header
   of the LISP-encapsulated packet are embedded in the LISP-specific
   header.  This means that the header needs to contain two Map-Version
   numbers:

   o  The Source Map-Version number of the EID-to-RLOC mapping in the
      EID-to-RLOC Database used to select the source RLOC.

   o  The Destination Map-Version number of the EID-to-RLOC mapping in
      the EID-to-RLOC Cache used to select the destination RLOC.

   By embedding both Source Map-Version number and Destination Map-
   Version number an ETR receiving a LISP packet with Map-Version
   numbers, can perform the following checks:

   1.  The ITR that has sent the packet has an up-to-date mapping in its
       cache
       EID-to-RLOC Cache for the destination EID and is performing
       encapsulation correctly.

   2.  In case of bidirectional traffic, the mapping in the local ETR
       EID-to-RLOC cache Cache for the source EID is up-to-date.

   If one or both of the above conditions do not hold, the ETR can send
   a Map-Request either to make the ITR aware that a new mapping is
   available (see Section 5.1) or to update the mapping in the local
   cache
   EID-to-RLOC Cache (see Section 5.2).

5.1.  Handling Destination Map-Version number

   When an ETR receives a packet, the Destination Map-Version number
   relates to the mapping for the destination EID for which the ETR is a
   RLOC.  This mapping is part of the ETR EID-to-RLOC Database.  Since
   the ETR is authoritative for the mapping, it has the correct and up-
   to-date Destination Map-Version number.  A check on this version
   number can be done, where the following cases can arise:

   1.  The packets arrive with the same Destination Map-Version number
       stored in the EID-to-RLOC Database.  This is the regular case.
       The ITR sending the packet has in its EID-to-RLOC Cache an up-to-
       date mapping.  No further actions are needed.

   2.  The packet arrives with a Destination Map-Version number greater
       (i.e., newer) than the one stored in the EID-to-RLOC Database.
       Since the ETR is authoritative on the mapping, meaning that the
       Map-Version number of its mapping is the correct one, this
       implies that someone is not behaving correctly with respect to
       the specifications.  In this case the packet carries a version
       number that is not valid, otherwise the ETR would have the same,
       and SHOULD be silently dropped.

   3.  The packets arrive with a Destination Map-Version number smaller
       (i.e., older) than the one stored in the EID-to-RLOC Database.
       This means that the ITR sending the packet has an old mapping in
       its EID-to-RLOC Cache containing stale information.  The ITR
       sending the packet has to be informed that a newer mapping is
       available.  This is done with a Map-Request message sent back to
       the ITR.  The Map-Request will either trigger a Map-Request back
       using the Solicit-Map-Request (SMR) bit or it will piggyback the
       newer mapping.  These are not new mechanisms; how to SMR or
       piggyback mappings in Map-Request messages is already described
       in [I-D.ietf-lisp], while their security is discussed in
       [I-D.ietf-lisp-threats].  These Map-Request messages should be
       rate limited (rate limitation policies are also described in
       [I-D.ietf-lisp]).  The feature introduced by Map-Version numbers
       is the possibility of blocking traffic not using the latest
       mapping.  Indeed, after a certain number of retries, if the
       Destination Map-Version number in the packets is not updated, the
       ETR MAY drop packets with a stale Map-Version number while
       strongly reducing the rate of Map-Request messages.  This because
       either the ITR is refusing to use the mapping for which the ETR
       is authoritative or (worse) it might be some form of attack.
       Another case might be that the control-plane is experiencing
       transient failures so the Map-Requests cannot reach that ITR.  By
       keeping sending Map-Requests at very low rate it is possible to
       recover from this situation.

   The rule in the third case MAY be more restrictive.  If the mapping
   has been the same for a period of time as long as the TTL (defined in
   [I-D.ietf-lisp]) of the previous version of the mapping, all packets
   arriving with an old Map-Version SHOULD be silently dropped right
   away without issuing any Map-Request.  The reason that allows such
   action is the fact that if the new mapping with the updated version
   number has been unchanged for at least the same time as the TTL of
   the older mapping, all the entries in the caches EID-to-RLOC Caches of ITRs
   must have expired.  Hence, all ITRs sending traffic should have
   refreshed the mapping according to [I-D.ietf-lisp].  If packets with
   old Map-
   Version Map-Version number are still received, then either someone has
   not respected the TTL, or it is a form of spoof/attack.  In both
   cases this is not valid behavior with respect to the specifications
   and the packet SHOULD be silently dropped.

   LISP-encapsulated packets with the V-bit set, when the original
   mapping in the EID-to-RLOC Database has version number set to the
   Null Map-Version value, MAY be silently dropped.  As explained in
   Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it
   means that ITRs, using the mapping for encapsulation, MUST NOT use
   Map-Version number in the LISP-specific header.

   For LISP-encapsulated packets with the V-bit set, when the original
   mapping in the EID-to-RLOC Database has version number set to a value
   different from the Null Map-Version value, a Destination Map-Version
   number equal to the Null Map-Version value means that the Destination
   Map-Version number MUST be ignored.

5.2.  Handling Source Map-Version number

   When an ETR receives a packet, the Source Map-Version number relates
   to the mapping for the source EID for which the ITR that sent the
   packet is authoritative.  If the ETR has an entry in its EID-to-RLOC
   Cache for the source EID, then a check can be performed and the
   following cases can arise:

   1.  The packet arrives with the same Source Map-Version number stored
       in the EID-to-RLOC Cache.  This is the correct regular case.  The
       ITR has in its cache EID-to-RLOC Cache an up-to-date copy of the
       mapping.  No further actions are needed.

   2.  The packet arrives with a Source Map-Version number greater
       (i.e., newer) than the one stored in the local EID-to-RLOC Cache.
       This means that ETR has in its cache EID-to-RLOC Cache a mapping that
       is stale and needs to be updated.  A Map-Request SHOULD be sent
       to get the new mapping for the source EID.  This is a normal Map-Request Map-
       Request message sent through the mapping system and MUST respect
       the specifications in [I-D.ietf-lisp], including rate limitation
       policies.

   3.  The packet arrives with a Source Map-Version number smaller
       (i.e., older) than the one stored in the local EID-to-RLOC Cache.
       Such a case is not valid with respect to the specifications.
       Indeed, if the mapping is already present in the EID-to-RLOC
       Cache, this means that an explicit Map-Request has been sent and
       a Map-Reply has been received from an authoritative source.
       Assuming that the mapping system is not corrupted anyhow, the
       Map-Version in the EID-to-RLOC Cache is the correct one, while
       the one carried by the packet is stale.  In this situation the
       packet MAY be silently dropped.

   If the ETR does not have an entry in the EID-to-RLOC Cache for the
   source EID (e.g., in case of unidirectional traffic) then the Source
   Map-Version number can be safely ignored.

   For LISP-encapsulated packets with the V-bit set, if the Source Map-
   Version number is the Null Map-Version value, it means that the
   Source Map-Version number MUST be ignored.

6.  LISP header and Map-Version numbers

   In order for the versioning approach to work, the LISP specific
   header has to carry both Source Map-Version number and Destination
   Map-Version number.  This is done by setting the V-bit in the LISP
   specific header as defined in [I-D.ietf-lisp] Section 5.3.  When the
   V-bit is set the low-order 24-bits of the first longword are used to
   transport both source and destination Map-Version numbers.  In
   particular the first 12 bits are used for Source Map-Version number
   and the second 12 bits for the Destination Map-Version number.

   Hereafter is the example of LISP header carrying version numbers in
   the case of IPv4-in-IPv4 encapsulation.  The same setting can be used
   for any other case (IPv4-in-IPv6, IPv6-in-IPv4, and IPv6-in-IPv6).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |N|L|E|V|I|flags|  Source Map-Version   |Destination Map-Version|
   LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Instance ID/Locator Status Bits               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Source Map-Version number (12 bits):  Map-Version of the mapping used
      by the ITR to select the RLOC present in the "Source Routing
      Locator" field.  How to set on transmission and handle on
      reception this value is described in Section 5.2.

   Destination Map-Version number (12 bits):  Map-Version of the mapping
      used by the ITR to select the RLOC present in the "Destination
      Routing Locator" field.  How to set on transmission and handle on
      reception this value is described in Section 5.1.

   The present document just specifies how to use the low-order 24-bits
   of the first longword of the LISP-specific header when the V-bit is
   set to 1.  All other cases, including the bit fields of the rest of
   the LISP-specific header and the whole LISP packet format are
   specified in [I-D.ietf-lisp].  Not all of the LISP encapsulated
   packets need to carry version numbers.  When Map-Version numbers are
   carried the V-bit MUST be set to 1.  All legal combinations of the
   flags, when the V-bit is set to 1, are described in [I-D.ietf-lisp].

7.  Map Record and Map-Version

   To accommodate the proposed mechanism, the Map Records that are
   transported on Map-Request/Map-Reply/Map-Register messages need to
   carry the Map-Version number as well.  For this purpose the 12-bits
   before the EID-AFI field in the Record that describe a mapping is
   used.  This is defined in Section 6.1.4 of [I-D.ietf-lisp] and
   reported here as example.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Map-Version Number:  Map-Version of the mapping contained in the
      Record.  As explained in Section 4.1 this field can be zero (0),
      meaning that no Map-Version is associated to the mapping, hence
      packets that are LISP-encapsulated using this mapping MUST NOT
      contain Map-Version numbers in the LISP specific header and the
      V-bit MUST be set to 0.

   This packet format works perfectly with xTRs that do not support Map-
   Versioning, since they can simply ignore those bits.

8.  Benefits and case studies for Map-Versioning

   In the following sections we provide more discussion on various
   aspects and use of the Map-Versioning.  Security observations are
   instead grouped in Section 10.

8.1.  Synchronization of different xTRs

   Map-Versioning does not require additional synchronization mechanism
   compared to the normal functioning of LISP without Map-Versioning.
   Clearly all the ETRs have to reply with the same Map-Version number,
   otherwise there can be an inconsistency that creates additional
   control traffic, instabilities, traffic disruptions.  It is the same
   without Map-Versioning, with ETRs that have to reply with the same
   mapping, otherwise the same problems can arise.

   As an example, let's consider the topology of Figure 1 where ITR A.1
   of domain A is sending unidirectional traffic to the domain B, while
   A.2 of domain A exchange bidirectional traffic with domain B. In
   particular, ITR A.2 send traffic to ETR B and ETR A.2 receives
   traffic from ITR B.

    +-----------------+              +-----------------+
    | Domain A        |              | Domain B        |
    |       +---------+              |                 |
    |       | ITR A.1 |---           |                 |
    |       +---------+    \         +---------+       |
    |                 |      ------->| ETR B   |       |
    |                 |      ------->|         |       |
    |       +---------+    /         |         |       |
    |       | ITR A.2 |---      -----| ITR B   |       |
    |       |         |       /      +---------+       |
    |       | ETR A.2 |<-----        |                 |
    |       +---------+              |                 |
    |                 |              |                 |
    +-----------------+              +-----------------+

                                 Figure 1

   Obviously in the case of Map-Versioning both ITR A.1 and ITR A.2 of
   domain A must use the same value otherwise the ETR of domain B will
   start to send Map-Requests.

   The same problem can, however, arise without Map-Versioning.  For
   instance, if the two ITRs of domain A send different Loc Status Bits.
   In this case either the traffic is disrupted, if the ETR B trusts the
   Locator Status Bits, or if ETR B does not trusts the Locator Status
   Bits it will start sending Map-Requests to confirm the each change in
   the reachability.

   So far, LISP does not provide any specific synchronization mechanism,
   but assumes that synchronization is provided by configuring the
   different xTRs consistently.  The same applies for Map-Versioning.
   If in the future any synchronization mechanism is provided, Map-
   Versioning will take advantage of it automatically since it is
   included in the Record format, as described in Section 7.

8.2.  Map-Versioning and unidirectional traffic

   When using Map-Versioning the LISP specific header carries two Map-
   Version numbers, for both source and destination mappings.  This can
   raise the question on what will happen in the case of unidirectional
   flows, like for instance in the case presented in Figure 2, since
   LISP specification do not mandate for ETR to have a mapping for the
   source EID.

    +-----------------+            +-----------------+
    | Domain A        |            | Domain B        |
    |       +---------+            +---------+       |
    |       | ITR A   |----------->| ETR B   |       |
    |       +---------+            +---------+       |
    |                 |            |                 |
    +-----------------+            +-----------------+

                                 Figure 2

   For what concerns the ITR, it is able to put both source and
   destination version number in the LISP header since the Source Map-
   Version number is in ITR's database, while the Destination Map-
   Version number is in ITR's cache.

   For what concerns the ETR, it simply checks only the Destination Map-
   Version number in the same way as described in Section 5, ignoring
   the Source Map-Version number.

8.3.  Map-Versioning and interworking

   Map-Versioning is compatible with the LISP interworking between LISP
   and non-LISP sites as defined in [I-D.ietf-lisp-interworking].  LISP
   interworking defines three techniques to make LISP sites and non-LISP
   sites, namely Proxy-ITR, LISP-NAT, and Proxy-ETR.  Hereafter it is
   described how Map-Versioning relates to these three mechanisms.

8.3.1.  Map-Versioning and Proxy-ITRs

   The purpose of the Proxy-ITR (PITR) is to encapsulate traffic
   originating in a non-LISP site in order to deliver the packet to one
   of the ETRs of the LISP site (cf. Figure 3).  This case is very
   similar to the unidirectional traffic case described in Section 8.2,
   hence similar rules apply.

    +----------+                             +-------------+
    | LISP     |                             | non-LISP    |
    | Domain A |                             | Domain B    |
    |  +-------+        +-----------+        |             |
    |  | ETR A |<-------| Proxy ITR |<-------|             |
    |  +-------+        +-----------+        |             |
    |          |                             |             |
    +----------+                             +-------------+

                                 Figure 3

   The main difference is that a Proxy-ITR does not have any mapping,
   since it just encapsulate packets arriving from non-LISP site, thus
   cannot provide a Source Map-Version.  In this case, the proxy-ITR
   will just put the Null Map-Version value as Source Map-Version
   number, while the receiving ETR will ignore the field.

   With this setup the LISP Domain A is able to check whether or not the
   PITR is using the latest mapping.  If this is not the case the
   mapping for LISP Domain A on the PITR can be updated using one of the
   mechanisms defined in [I-D.ietf-lisp] and
   [I-D.ietf-lisp-interworking].

8.3.2.  Map-Versioning and LISP-NAT

   The LISP-NAT mechanism is based on address translation from non-
   routable EIDs to routable EIDs and does not involve any form of
   encapsulation.  As such Map-Versioning does not apply in this case.

8.3.3.  Map-Versioning and Proxy-ETRs

   The purpose of the Proxy-ETR (PETR) is to decapsulate traffic
   originating in a LISP site in order to deliver the packet to the non-
   LISP site (cf. Figure 4).  One of the main reasons of deploy PETRs is
   to bypass uRPF (Unicast Reverse Path Forwarding) checks on the
   provider edge.

    +----------+                             +-------------+
    | LISP     |                             | non-LISP    |
    | Domain A |                             | Domain B    |
    |  +-------+        +-----------+        |             |
    |  | ITR A |------->| Proxy ETR |------->|             |
    |  +-------+        +-----------+        |             |
    |          |                             |             |
    +----------+                             +-------------+

                                 Figure 4

   A Proxy-ETR does not have any mapping, since it just decapsulates
   packets arriving from LISP site.  In this case, the ITR will just put
   the Null Map-Version value as Destination Map-Version number, while
   the receiving Proxy-ETR will ignore the field.

   With this setup the Proxy-ETR is able to check whether or not the
   mapping has changed.  If this is the case the mapping for LISP Domain
   A on the PETR can be updated using one of the mechanisms defined in
   [I-D.ietf-lisp] and [I-D.ietf-lisp-interworking].

8.4.  RLOC shutdown/withdraw

   Map-Versioning can be even used to perform a graceful shutdown or
   withdraw of a specific RLOC.  This is achieved by simply issuing a
   new mapping, with an updated Map-Version number, where the specific
   RLOC to be shut down is withdrawn or announced as unreachable (R bit
   in the Map Record, see [I-D.ietf-lisp]), but without actually turning
   it off.

   Once no more traffic is received by the RLOC, it can be shut down
   gracefully, because at least all sites actively using the mapping
   have updated it.

   It should be pointed out that for frequent up/down changes such a
   mechanism should not be used since this can generate excessive load
   on the Mapping System.

8.5.  Map-Version for lightweight LISP implementation

   The use of Map-Versioning can help in developing a lightweight
   implementation of LISP.  This comes with the price of not supporting
   Loc-Status-Bit, which are useful in some contexts.

   In the current LISP specifications the set of RLOCs must always be
   maintained ordered and consistent with the content of the Loc Status
   Bits (see section 6.5 of [I-D.ietf-lisp]).  With Map-Versioning such
   type of mechanisms can be avoided.  When a new RLOC is added to a
   mapping, it is not necessary to "append" new locators to the existing
   ones as explained in Section 6.5 of [I-D.ietf-lisp].  A new mapping
   with a new Map-Version number will be issued, and since the old
   locators are still valid the transition will be with no disruptions.
   The same applies for the case a RLOC is withdrawn.  There is no need
   to maintain holes in the list of locators, as is the case when using
   Locator Status Bits, for sites that are not using the RLOC that has
   been withdrawn the transition will be with no disruptions.

   All of these operations, as already stated, do not need to maintain
   any consistency among Locator Status Bits, and the way RLOC are
   stored in the cache. EID-to-RLOC Cache.

   Further, Map-Version can be used to substitute the "clock sweep"
   operation described in Section 6.5.1 of [I-D.ietf-lisp].  Indeed,
   every LISP site communicating to a specific LISP site that has
   updated the mapping will be informed of the available new mapping in
   a data-driven manner.

   Note that what is proposed in the present section is just an example
   and MUST NOT be considered as specifications for a lightweight LISP
   implementation.  In case the IETF decides to undertake such a work,
   it will be documented elsewhere.

9.  Incremental deployment and implementation status

   Map-Versioning can be incrementally deployed without any negative
   impact on existing LISP elements (e.g., xTRs, Map-Servers, Proxy-
   ITRs, etc).  Any LISP element that does not support Map-Versioning
   can safely ignore them.  Further, there is no need of any specific
   mechanism to discover if an xTR supports or not Map-Versioning.  This
   information is already included in the Map Record.

   Map-Versioning is currently implemented in OpenLISP
   [I-D.iannone-openlisp-implementation].

   Note that the reference document for LISP implementation and
   interoperability tests remains [I-D.ietf-lisp].

10.  Security Considerations

   Map-Versioning does not introduce any security issue concerning both
   the data-plane and the control-plane.  On the contrary, as described
   in the following, if Map-Versioning may be used also to update
   mappings in case of change in the reachability information (i.e.,
   instead of the Locator Status Bits) it is possible to reduce the
   effects of some DoS or spoofing attacks that can happen in an
   untrusted environment.

   Robustness of the Map-Versioning mechanism leverages on a trusted
   Mapping Distribution System.  A thorough security analysis of LISP is
   documented in [I-D.ietf-lisp-threats].

10.1.  Map-Versioning against traffic disruption

   An attacker can try to disrupt ongoing communications by creating
   LISP encapsulated packets with wrong Locator Status Bits.  If the xTR
   blindly trusts the Locator Status Bits it will change the
   encapsulation accordingly, which can result in traffic disruption.

   This does not happen in the case of Map-Versioning.  As described in
   Section 5, upon a version number change the xTR first issues a Map-
   Request.  The assumption is that the mapping distribution system is
   sufficiently secure that Map-Request and Map-Reply messages and their
   content can be trusted.  Security issues concerning specific mapping
   distribution system are out of the scope of this document.  In the
   case of Map-Versioning the attacker should "guess" a valid version
   number that triggers a Map-Request, as described in Section 5,
   otherwise the packet is simply dropped.  Nevertheless, guessing a
   version number that generates a Map-Request is easy, hence it is
   important to follow the rate limitations policies described in
   [I-D.ietf-lisp] in order to avoid DoS attacks.

   Note that a similar level of security can be obtained with Loc Status
   Bits, by simply making mandatory to verify any change through a Map-
   Request.  However, in this case Locator Status Bits loose their
   meaning, because, it does not matter anymore which specific bits has
   changed, the xTR will query the mapping system and trust the content
   of the received Map-Reply.  Furthermore there is no way to perform
   filtering as in the Map-Versioning in order to drop packets that do
   not carry a valid Map-Version number.  In the case of Locator Status
   Bits, any random change can trigger a Map-Request (unless rate
   limitation is enabled which raise another type of attack discussed in
   Section 10.2).

10.2.  Map-Versioning against reachability information DoS

   Attackers can try to trigger a large amount of Map-Request by simply
   forging packets with random Map-Version or random Locator Status
   Bits.  In both cases the Map-Requests are rate limited as described
   in [I-D.ietf-lisp].  However, differently from Locator Status Bit
   where there is no filtering possible, in the case of Map-Versioning
   is possible to filter not valid version numbers before triggering a
   Map-Request, thus helping in reducing the effects of DoS attacks.  In
   other words the use of Map-Versioning enables a fine control on when
   to update a mapping or when to notify that a mapping has been
   updated.

   It is clear, that Map-Versioning does not protect against DoS and
   DDoS attacks, where an xTR looses processing power doing checks on
   the LISP header of packets sent by attackers.  This is independent
   from Map-Versioning and is the same for Loc Status Bits.

11.  IANA Considerations

   This document has no actions for IANA.

12.  Open Issues and Considerations

   There are a number of implications of the use of Map-Versioning that
   are not yet completely explored.  Among these are:

   o  Performance of the convergence time when an EID-to-RLOC mapping
      changes, i.e., how much time is needed to update mappings in the
      EID-to-RLOC Cache of the ITRs currently sending traffic to ETRs
      for the EID whose mapping has been changed.

   o  Support to ETR synchronization.  Even without Map-Versioning, LISP
      ([I-D.ietf-lisp]) requires ETRs to announce the same mapping for
      the same EID-Prefix to a requester.  The implications that a
      temporary lack of synchronization may have on the traffic is yet
      to be fully explored.  There are two ways Map-Versioning is
      helpful with respect to the synchronization problem.  On the one
      hand, assigning version numbers to mappings helps in debugging,
      since quick checks on the consistency of the mappings on different
      ETRs can be done by looking at the Map-Version number.  On the
      other hand, Map-Versioning can be used to control the traffic
      toward ETRs that announce the latest mapping.

   The authors expect that experimentation will help assess the
   performance and the limitations of the Map-Versioning mechanism.
   Issues and concerns about the deployment of LISP for Internet traffic
   are discussed in [I-D.ietf-lisp].

13.  Acknowledgements

   The authors would like to thank Alia Atlas, Jesper Skriver, Pierre
   Francois, Noel Chiappa, Dino Farinacci for their comments and review.

   This work has been partially supported by the INFSO-ICT-216372
   TRILOGY Project (www.trilogy-project.org).

13.

14.  References

13.1.

14.1.  Normative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-15 (work in progress), July 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2.

14.2.  Informative References

   [I-D.iannone-openlisp-implementation]
              Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
              Implementation Report",
              draft-iannone-openlisp-implementation-01 (work in
              progress), July 2008.

   [I-D.ietf-lisp-alt]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09
              (work in progress), September 2011.

   [I-D.ietf-lisp-interworking]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-02 (work in progress),
              June 2011.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-11 Server Interface",
              draft-ietf-lisp-ms-12 (work in progress), August October 2011.

   [I-D.ietf-lisp-threats]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
              Analysis", draft-ietf-lisp-threats-00 (work in progress),
              July 2011.

Appendix A.  Estimation of time before Map-Version wrap-around

   The present section proposes an estimation of the wrap-around time
   for the proposed 12 bits size for the Map-Version number.  Using a
   granularity of seconds and assuming as worst-case that a new version
   is issued each second, it takes slightly more than 1 hour before the
   version wraps around.  Note that the granularity of seconds is in
   line with the rate limitation policy for Map-Request messages, as
   proposed in the LISP main specifications ([I-D.ietf-lisp]).
   Alternatively a granularity of minutes can also be used, as for the
   TTL of the Map-Reply ([I-D.ietf-lisp]).  In this case the worst
   scenario is when a new version is issued every minute, leading to a
   much longer time before wrap-around.  In particular, when using 12
   bits, the wrap-around time is almost 3 days.

   For general information, hereafter there is a table with a rough
   estimation of the time before wrap-around in the worst-case scenario,
   considering different sizes (bits length) of the Map-Version number
   and different time granularity.

   +---------------+--------------------------------------------+
   |Version Number |           Time before wrap around          |
   |  Size (bits)  +---------------------+----------------------+
   |               |Granularity: Minutes | Granularity: Seconds |
   |               | (mapping changes    | (mapping changes     |
   |               |  every 1 minute)    |  every 1 second)     |
   +-------------------------------------+----------------------+
   |          32   |   8171   Years      |  136   Years         |
   |          30   |   2042   Years      |   34   Years         |
   |          24   |     31   Years      |  194   Days          |
   |          16   |     45   Days       |   18   Hours         |
   |          15   |     22   Days       |    9   Hours         |
   |          14   |     11   Days       |    4   Hours         |
   |          13   |      5.6 Days       |    2.2 Hours         |
   |          12   |      2.8 Days       |    1.1 Hours         |
   +---------------+---------------------+----------------------+

              Figure 5: Estimation of time before wrap-around

Appendix B.  Document Change Log

   o  Version 06 Posted October 2011.

      *  Added disclaimer in the Introduction about general issues
         concerning LISP as requested by A. Farrel.

      *  Fixed sentence about legacy systems in the abstract as
         requested by A. Farrel.

      *  Added Section 12 as requested by A. Farrel.

   o  Version 05 Posted October 2011.

      *  Added sentence in Section 3 on the use of Big Endian, as for
         comment of P. Resnick.

      *  Extended the end of Section 4 in order to clarify that Map-
         Version numbers are assigned to mappings by configuration and
         not automatically generated by ETRs, as for comments of R.
         Sparks

      *  Changed formal definition of Map-Version order (greater vs.
         smaller) in Section 4 as for comments from R. Housley and R.
         Sparks.

      *  Added disclaimer in Section 1 stating that in case of unforseen
         conflict with the main spec the base document has precedence on
         the present one, as for comment from Sthephen Farrell.

   o  Version 04 Posted September 2011.

      *  Added clarifications in Section 1, Section 4, Section 5.2, and
         Section 5.1 to address Stephen Farrell's comments.

      *  Used the term LISP Site instead of ISP in Section 5 as
         suggested by Stephen Farrell.

      *  Deleted "(usually contains the nonce)" from Section 6 because
         confusing, as suggested by Stephen Farrell.

      *  Fixed several typos pointed out by Stephen Farrell.

   o  Version 03 Posted September 2011.

      *  Added reference in Section 7 toward the main lisp documents
         specifying the section, as requested by Jari Arkko.

      *  Fixed all typos and editorial issues pointed out by Jari Arkko.

      *  Added clarification in Section 8.4 as requested by Jari Arkko.

      *  Extentend all acronyms in the abstract as requested by Jari
         Arkko.

      *  Clarified silent drop polocy in Section 5.2 as requested by
         both Richard Barnes and Jari Arkko.

      *  Fixed typos pointed out by Richard Barnes.

   o  Version 02 Posted July 2011.

      *  Added text in Section 5 about ETR synchronization, as suggested
         by Alia Atlas.

      *  Modified text in Section 8.5 concerning lightweight LISP
         implementation, as suggested by Alia Atlas.

      *  Deleted text concerning old versions of [I-D.ietf-lisp-ms] and
         [I-D.ietf-lisp-alt] in Section 7, as pointed out by Alia Atlas.

      *  Fixed section 4.1 to be less restrictive, as suggested by
         Jesper Skriver.

   o  Version 01 Posted March 2011.

      *  Changed the wording from "Map-Version number 0" to "Null Map-
         Version.

      *  Clarification of the use of the Null Map-Version value as
         Source Map-Version Number and Destination Map-Version Number.

      *  Extended the section describing Map-Versioning and LISP
         Interworking co-existence.

      *  Reduce packet format description to avoid double definitions
         with the main specs.

   o  Version 00 Posted September 2010.

      *  Added Section "Definitions of Terms".

      *  Editorial polishing of all sections.

      *  Added clarifications in section "Dealing with Map-Version
         numbers" for the case of the special Map-Version number 0.

      *  Rename of draft-iannone-mapping-versioning-02.txt.

Authors' Addresses

   Luigi Iannone
   TU Berlin - Deutsche
   Telekom Innovation Laboratories AG
   Ernst-Reuter Platz 7
   Berlin
   Germany

   Email: luigi@net.t-labs.tu-berlin.de

   Damien Saucez
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain-la-Neuve
   Belgium

   Email: damien.saucez@uclouvain.be
   Olivier Bonaventure
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain-la-Neuve
   Belgium

   Email: olivier.bonaventure@uclouvain.be
--Apple-Mail=_7CFD627F-7C8C-4130-923D-2FAA160B2310 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_7CFD627F-7C8C-4130-923D-2FAA160B2310-- --Apple-Mail=_C8AC2CA5-842B-41C3-9DB9-CF2F31F9C9DA-- From yakov@juniper.net Mon Oct 31 13:26:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D0C11E8216 for ; Mon, 31 Oct 2011 13:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1ja2MqGFyMR for ; Mon, 31 Oct 2011 13:26:10 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id AB89A11E81D7 for ; Mon, 31 Oct 2011 13:26:03 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 13:26:03 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 31 Oct 2011 13:25:27 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p9VKPRh48085; Mon, 31 Oct 2011 13:25:27 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201110312025.p9VKPRh48085@magenta.juniper.net> To: Terry Manderson In-Reply-To: References: X-MH-In-Reply-To: Terry Manderson message dated "Wed, 19 Oct 2011 16:23:26 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94729.1320092726.1@juniper.net> Date: Mon, 31 Oct 2011 13:25:27 -0700 From: Yakov Rekhter Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:26:22 -0000 Terry, > Hi All, > > Joel and I bounced the following charter around and have also passed it in > front of AD's eyes. couple of comment in-line... > You obviously have time to chew on this for a while before Taipei. > > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > rekindled interest in scalable routing and addressing architectures for > the Internet. Among the many issues driving this renewed interest are > concerns about the scalability of the routing system and the impending > exhaustion of the IPv4 address space. Since the IAB workshop, several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "locator/identifier separation". > > The basic idea behind the separation is that the Internet architecture > combines two functions, routing locators, (where you are attached to the > network) and identifiers (who you are) in one number space: The IP > address. Proponents of the separation architecture postulate that > splitting these functions apart will yield several advantages, including > improved scalability for the routing system. The separation aims to > decouple locators and identifiers, thus allowing for efficient > aggregation of the routing locator space and providing persistent > identifiers in the identifier space. > > LISP supports the separation of the IPv4 and IPv6 address space > following a network-based map-and-encapsulate scheme (RFC 1955). In > LISP, both identifiers and locators are IP addresses. In LISP, > identifiers are composed of two parts: a "global" portion that uniquely > identifies a particular site and a "local" portion that identifies an > interface within a site. The "local" portion may be subdivided to > identify a particular network within the site. For a given identifier, > LISP maps the "global" portion of the identifier into a set of locators > that can be used by de-capsulation devices to reach the identified > interface; as a consequence a host would typically change identifiers > when it moves from one site to another or whenever it moves from one > subnet to another within an site. Typically, the same IP address will > not be used as an identifier > and locator in LISP. > > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. > > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > The LISP WG is chartered to work on the LISP base protocol and any items > which directly impact LISP. The working group will encourage and > support interoperable LISP implementations as well as defining > requirements for alternate mapping systems. The Working Group will also > develop security profiles for LISP and the various LISP mapping systems. > > It is expected that the results of specifying, implementing, and testing > LISP will be fed to the general efforts at the IETF and IRTF (e.g., the > Routing Research Group) that attempts to understand which type of a > solution is optimal. The LISP WG is NOT chartered to develop the final > or standard solution for solving the routing scalability problem. Its > specifications are Experimental and labeled with accurate disclaimers > about their limitations and not fully understood implications for > Internet traffic. In addition, as these issues are understood, the > working group will analyze and document the implications of LISP on > Internet traffic, applications, routers, and security. This analysis > will explain what role LISP can play in scalable routing. The analysis > should also look at scalability and levels of state required for > encapsulation, decapsulation, liveness, and so on as well as the > manageability and operability of LISP. The charter needs to explicitly include in the Goals and Milestones the document(s) that cover the analysis. Furthermore, as John Scudder asked in his e-mail on 9/28, "the base spec calls out a number of areas that require more experimentation. A simple grep will find these. These experiments and what has been learned from them should be documented. The same applies if other specs have similar caveats (I just haven't looked for them)." The charter needs to explicitly include in the Goals and Milestones the document(s) that cover this. Yakov. > Goals and Milestones > > Jun 2012 Forward draft-ietf-lisp-mib to the IESG. > Jun 2012 Forward draft-ietf-lisp-sec to the IESG. > Jun 2012 Forward draft-ietf-lisp-deployment to the IESG. > Jun 2012 Forward a security proposal document (draft-ietf-lisp-threats) > to the IESG. > > Dec 2013 Forward to the IESG an operational set of documents which should > include cache management and ETR synchronization > techniques inclusive of a cache management specification. > > Jun 2014 Forward to the IESG an evaluation of the security threat to > cache management and ETR synchronization. > Jun 2014 Evaluate the applicability and coverage for LISP from a > reuse of SIDR technology. > > Dec 2014 Re-charter or close Yakov. From yakov@juniper.net Mon Oct 31 13:32:52 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096F311E8239 for ; Mon, 31 Oct 2011 13:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bktw1Jop0tL for ; Mon, 31 Oct 2011 13:32:51 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B611E8238 for ; Mon, 31 Oct 2011 13:32:51 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 13:32:51 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 31 Oct 2011 13:31:03 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p9VKV3h51435; Mon, 31 Oct 2011 13:31:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201110312031.p9VKV3h51435@magenta.juniper.net> To: Terry Manderson In-Reply-To: References: X-MH-In-Reply-To: Terry Manderson message dated "Wed, 26 Oct 2011 22:10:42 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95059.1320093063.1@juniper.net> Date: Mon, 31 Oct 2011 13:31:03 -0700 From: Yakov Rekhter Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:32:52 -0000 Terry, > WG hat on. > > This follow-up is initiated due to a recent observation gleaned from a > presentation request for the Taipei meeting. > > While this draft charter does not preclude taking on work items specifically > related to LISP VPN or LISP mobility, I think it's useful to tease out the > questions and put them to the WG for discussion. > > Should LISP mobility be specifically included in the work plan? > > Should LISP VPN modalities be specifically included in the work plan? If LISP VPN modality is an L2VPN, then such work should be pursued in L2VPN WG. If LISP VPN modality is an L3VPN, then such work should be pursued in L3VPN WG. Thus both of of the above LISP VPN modalities should be outside the scope of the LISP WG. Yakov. > > Cheers > Terry > > On 20/10/11 9:23 AM, "Terry Manderson" wrote: > > > Hi All, > > > > Joel and I bounced the following charter around and have also passed it in > > front of AD's eyes. > > > > You obviously have time to chew on this for a while before Taipei. > > > > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > > rekindled interest in scalable routing and addressing architectures for > > the Internet. Among the many issues driving this renewed interest are > > concerns about the scalability of the routing system and the impending > > exhaustion of the IPv4 address space. Since the IAB workshop, several > > proposals have emerged which attempt to address the concerns expressed > > there and elsewhere. In general, these proposals are based on the > > "locator/identifier separation". > > > > The basic idea behind the separation is that the Internet architecture > > combines two functions, routing locators, (where you are attached to the > > network) and identifiers (who you are) in one number space: The IP > > address. Proponents of the separation architecture postulate that > > splitting these functions apart will yield several advantages, including > > improved scalability for the routing system. The separation aims to > > decouple locators and identifiers, thus allowing for efficient > > aggregation of the routing locator space and providing persistent > > identifiers in the identifier space. > > > > LISP supports the separation of the IPv4 and IPv6 address space > > following a network-based map-and-encapsulate scheme (RFC 1955). In > > LISP, both identifiers and locators are IP addresses. In LISP, > > identifiers are composed of two parts: a "global" portion that uniquely > > identifies a particular site and a "local" portion that identifies an > > interface within a site. The "local" portion may be subdivided to > > identify a particular network within the site. For a given identifier, > > LISP maps the "global" portion of the identifier into a set of locators > > that can be used by de-capsulation devices to reach the identified > > interface; as a consequence a host would typically change identifiers > > when it moves from one site to another or whenever it moves from one > > subnet to another within an site. Typically, the same IP address will > > not be used as an identifier > > and locator in LISP. > > > > LISP requires no changes to end-systems or to most routers. LISP aims > > for an incrementally deployable protocol. > > > > A number of approaches are being looked at in parallel in other > > contexts. The IRTF RRG examined several proposals, some of which were > > published as IRTF-track Experimental RFCs. > > > > The LISP WG is chartered to work on the LISP base protocol and any items > > which directly impact LISP. The working group will encourage and > > support interoperable LISP implementations as well as defining > > requirements for alternate mapping systems. The Working Group will also > > develop security profiles for LISP and the various LISP mapping systems. > > > > It is expected that the results of specifying, implementing, and testing > > LISP will be fed to the general efforts at the IETF and IRTF (e.g., the > > Routing Research Group) that attempts to understand which type of a > > solution is optimal. The LISP WG is NOT chartered to develop the final > > or standard solution for solving the routing scalability problem. Its > > specifications are Experimental and labeled with accurate disclaimers > > about their limitations and not fully understood implications for > > Internet traffic. In addition, as these issues are understood, the > > working group will analyze and document the implications of LISP on > > Internet traffic, applications, routers, and security. This analysis > > will explain what role LISP can play in scalable routing. The analysis > > should also look at scalability and levels of state required for > > encapsulation, decapsulation, liveness, and so on as well as the > > manageability and operability of LISP. > > > > > > Goals and Milestones > > > > Jun 2012 Forward draft-ietf-lisp-mib to the IESG. > > Jun 2012 Forward draft-ietf-lisp-sec to the IESG. > > Jun 2012 Forward draft-ietf-lisp-deployment to the IESG. > > Jun 2012 Forward a security proposal document (draft-ietf-lisp-threats) > > to the IESG. > > > > Dec 2013 Forward to the IESG an operational set of documents which shoul d > > include cache management and ETR synchronization > > techniques inclusive of a cache management specification. > > > > Jun 2014 Forward to the IESG an evaluation of the security threat to > > cache management and ETR synchronization. > > Jun 2014 Evaluate the applicability and coverage for LISP from a > > reuse of SIDR technology. > > > > Dec 2014 Re-charter or close > > > > > > Cheers > > Terry > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Mon Oct 31 16:28:45 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D521F0D79; Mon, 31 Oct 2011 16:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RhCpBwqY7am; Mon, 31 Oct 2011 16:28:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C33E1F0D52; Mon, 31 Oct 2011 16:28:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031232845.29812.55596.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:28:45 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:28:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Network Element Deployment Considerations Author(s) : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-02.txt Pages : 22 Date : 2011-10-31 This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-deployment-02.txt From jari.arkko@piuha.net Mon Oct 31 16:57:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDE911E8420 for ; Mon, 31 Oct 2011 16:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id demSa1JKGEZk for ; Mon, 31 Oct 2011 16:57:47 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0099E11E83E8 for ; Mon, 31 Oct 2011 16:57:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5084B2CC45 for ; Tue, 1 Nov 2011 01:57:46 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqG5xu7hlikT for ; Tue, 1 Nov 2011 01:57:45 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C98552CC31 for ; Tue, 1 Nov 2011 01:57:45 +0200 (EET) Message-ID: <4EAF35F9.7040000@piuha.net> Date: Tue, 01 Nov 2011 01:57:45 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: lisp@ietf.org References: <201110312025.p9VKPRh48085@magenta.juniper.net> In-Reply-To: <201110312025.p9VKPRh48085@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:57:47 -0000 Yakov, > Furthermore, as John Scudder asked in his e-mail on 9/28, "the base > spec calls out a number of areas that require more experimentation. > A simple grep will find these. These experiments and what has been > learned from them should be documented. The same applies if other > specs have similar caveats (I just haven't looked for them)." > The charter needs to explicitly include in the Goals and Milestones > the document(s) that cover this. > I would love to see documents in the charter that describe experiences from simulation/implementation/measurement/real-world use, and shed light on these issues. Jari From ljakab@ac.upc.edu Mon Oct 31 17:09:11 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0270021F8E28 for ; Mon, 31 Oct 2011 17:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sImC0Hsrs4w3 for ; Mon, 31 Oct 2011 17:09:08 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF7921F8B8B for ; Mon, 31 Oct 2011 17:09:06 -0700 (PDT) Received: from [192.168.0.192] (unknown [89.7.81.17]) by gw.ac.upc.edu (Postfix) with ESMTP id 752B42D0002; Tue, 1 Nov 2011 01:09:03 +0100 (CET) Message-ID: <4EAF3896.6040802@ac.upc.edu> Date: Tue, 01 Nov 2011 01:08:54 +0100 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: "lisp@ietf.org" References: <20111031232845.29812.55596.idtracker@ietfa.amsl.com> In-Reply-To: <20111031232845.29812.55596.idtracker@ietfa.amsl.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc X-Forwarded-Message-Id: <20111031232845.29812.55596.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------010301040509060008060604" Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-deployment-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 00:09:11 -0000 This is a multi-part message in MIME format. --------------010301040509060008060604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, We made some minor updates to the document: * Addressed some of the comments sent to the list by Hannu Flinck on August 11 * Corrected discrepancies between text and Figure 4 * Updated references to newer draft versions See attached diff for details. Regards, -Lorand Jakab -------- Original Message -------- Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-02.txt Date: Mon, 31 Oct 2011 16:28:45 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: lisp@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Network Element Deployment Considerations Author(s) : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-02.txt Pages : 22 Date : 2011-10-31 This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-deployment-02.txt _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --------------010301040509060008060604 Content-Type: text/html; name="draft-ietf-lisp-deployment-01-02.diff.htm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-deployment-01-02.diff.htm" wdiff draft-ietf-lisp-deployment-01.txt draft-ietf-lisp-deployment-02.txt 

Network Working Group                                           L. Jakab
Internet-Draft                                      A. Cabellos-Aparicio
Intended status: Informational                                  F. Coras
Expires: January 12, May 4, 2012                                  J. Domingo-Pascual
                                       Technical University of Catalonia
                                                                D. Lewis
                                                           Cisco Systems
                                                           July 11,
                                                        November 1, 2011

             LISP Network Element Deployment Considerations
                   draft-ietf-lisp-deployment-01.txt
                   draft-ietf-lisp-deployment-02.txt

Abstract

   This document discusses the different scenarios for the deployment of
   the new network elements introduced by the Locator/Identifier
   Separation Protocol (LISP).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 12, May 4, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Customer Edge  . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Provider Edge  . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Split ITR/ETR  . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Inter-Service Provider Traffic Engineering . . . . . . . .  8
     2.5.  Tunnel Routers Behind NAT  . . . . . . . . . . . . . . . . 10
       2.5.1.  ITR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.5.2.  ETR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.6.  Summary and Feature Matrix . . . . . . . . . . . . . . . . 11
   3.  Map-Resolvers and Map-Servers  . . . . . . . . . . . . . . . . 11
     3.1.  Map-Servers  . . . . . . . . . . . . . . . . . . . . . . . 11
     3.2.  Map-Resolvers  . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  P-ITR  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  P-ETR  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Migration to LISP  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16
     5.3.  Proxy-ITR Route Distribution . . . . . (PITR-RD) . . . . . . . . . . 17
     5.4.  Migration Summary  . . . . . . . . . . . . . . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

1.  Introduction

   The Locator/Identifier Separation Protocol (LISP) addresses the
   scaling issues of the global Internet routing system by separating
   the current addressing scheme into Endpoint IDentifiers (EIDs) and
   Routing LOCators (RLOCs).  The main protocol specification
   [I-D.ietf-lisp] describes how the separation is achieved, which new
   network elements are introduced, and details the packet formats for
   the data and control planes.

   While the boundary between the core and edge is not strictly defined,
   one widely accepted definition places it at the border routers of
   stub autonomous systems, which may carry a partial or complete
   default-free zone (DFZ) routing table.  The initial design of LISP
   took this location as a baseline for protocol development.  However,
   the applications of LISP go beyond of just decreasing the size of the
   DFZ routing table, and include improved multihoming and ingress
   traffic engineering (TE) support for edge networks, and even
   individual hosts.  Throughout the draft we will use the term LISP
   site to refer to these networks/hosts behind a LISP Tunnel Router.
   We formally define it as:

   LISP site:  A single host or a set of network elements in an edge
      network under the administrative control of a single organization,
      delimited from other networks by LISP Tunnel Router(s).

   Since LISP is a protocol which can be used for different purposes, it
   is important to identify possible deployment scenarios and the
   additional requirements they may impose on the protocol specification
   and other protocols.  The main specification [I-D.ietf-lisp] mentions
   positioning of tunnel routers, but without an in-depth discussion.
   This document fills that gap, by exploring the most common cases.
   While the theoretical combinations of device placements are quite
   numerous, the more practical scenarios are given preference in the
   following.

   Additionally, this documents is intended as a guide for the
   operational community for LISP deployments in their networks.  It is
   expected to evolve as LISP deployment progresses, and the described
   scenarios are better understood or new scenarios are discovered.

   Each subsection considers an element type, discussing the impact of
   deployment scenarios on the protocol specification.  For definition
   of terms, please refer to the appropriate documents (as cited in the
   respective sections).

   Comments and discussions about this memo should be directed to the
   LISP working group mailing list: lisp@ietf.org.

2.  Tunnel Routers

   LISP is a map-and-encap protocol, with the main goal of improving
   global routing scalability.  To achieve its goal, it introduces
   several new network elements, each performing specific functions
   necessary to separate the edge from the core.  The device that is the
   gateway between the edge and the core is called Tunnel Router (xTR),
   performing one or both of two separate functions:

   1.  Encapsulating packets originating from an end host to be
       transported over intermediary (transit) networks towards the
       other end-point of the communication

   2.  Decapsulating packets entering from intermediary (transit)
       networks, originated at a remote end host.

   The first function is performed by an Ingress Tunnel Router (ITR),
   the second by an Egress Tunnel Router (ETR).

   Section 8 of the main LISP specification [I-D.ietf-lisp] has a short
   discussion of where Tunnel Routers can be deployed and some of the
   associated advantages and disadvantages.  This section adds more
   detail to the scenarios presented there, and provides additional
   scenarios as well.

2.1.  Customer Edge

   LISP was designed with deployment at the core-edge boundary in mind,
   which can be approximated as the set of DFZ routers belonging to non-
   transit ASes.  For the purposes of this document, we will consider
   this boundary to be consisting of the routers connecting LISP sites
   to their upstreams.  As such, this is the most common expected
   scenario for xTRs, and this document considers it the reference
   location, comparing the other scenarios to this one.

                                ISP1    ISP2
                                 |        |
                                 |        |
                               +----+  +----+
                            +--|xTR1|--|xTR2|--+
                            |  +----+  +----+  |
                            |                  |
                            |     LISP site    |
                            +------------------+

                    Figure 1: xTRs at the customer edge

   From the LISP site perspective the main advantage of this type of
   deployment (compared to the one described in the next section) is
   having direct control over its ingress traffic engineering.  This
   makes it is easy to set up and maintain active/active, active/backup,
   or more complex TE policies, without involving third parties.

   Being under the same administrative control, reachability information
   of all ETRs is easier to synchronize, because the necessary control
   traffic can be allowed between the locators of the ETRs.  A correct
   synchronous global view of the reachability status is thus available,
   and the Loc-Status-Bits can be set correctly in the LISP data header
   of outgoing packets.

   By placing the tunnel router at the edge of the site, existing
   internal network configuration does not need to be modified.
   Firewall rules, router configurations and address assignments inside
   the LISP site remain unchanged.  This helps with incremental
   deployment and allows a quick upgrade path to LISP.  For larger sites
   with many external connections, distributed in geographically diverse
   PoPs, and complex internal topology, it may however make more sense
   to both encapsulate and decapsulate as soon as possible, to benefit
   from the information in the IGP to choose the best path (see
   Section 2.3 for a discussion of this scenario).

   Another thing to consider when placing tunnel routers are MTU issues.
   Since encapsulating packets increases overhead, the MTU of the end-
   to-end path may decrease, when encapsulated packets need to travel
   over segments having close to minimum MTU.  Some transit networks are
   known to provide larger MTU than the typical value of 1500 bytes of
   popular access technologies used at end hosts (e.g., IEEE 802.3 and
   802.11).  However, placing the LISP router connecting to such a
   network at the customer edge could possibly bring up MTU issues,
   depending on the link type to the provider as opposed to the
   following scenario.

2.2.  Provider Edge

   The other location at the core-edge boundary for deploying LISP
   routers is at the Internet service provider edge.  The main incentive
   for this case is that the customer does not have to upgrade the CE
   router(s), or change the configuration of any equipment.
   Encapsulation/decapsulation happens in the provider's network, which
   may be able to serve several customers with a single device.  For
   large ISPs with many residential/business customers asking for LISP
   this can lead to important savings, since there is no need to upgrade
   the software (or hardware, if it's the case) at each client's
   location.  Instead, they can upgrade the software (or hardware) on a
   few PE routers serving the customers.  This scenario is depicted in
   Figure 2.

                  +----------+        +------------------+
                  |   ISP1   |        |       ISP2       |
                  |          |        |                  |
                  |  +----+  |        |  +----+  +----+  |
                  +--|xTR1|--+        +--|xTR2|--|xTR3|--+
                     +----+              +----+  +----+
                        |                  |       |
                        |                  |       |
                        +--<[LISP site]>---+-------+

                          Figure 2: xTR at the PE

   While this approach can make transition easy for customers and may be
   cheaper for providers, the LISP site looses one of the main benefits
   of LISP: ingress traffic engineering.  Since the provider controls
   the ETRs, additional complexity would be needed to allow customers to
   modify their mapping entries.

   The problem is aggravated when the LISP site is multihomed.  Consider
   the scenario in Figure 2: whenever a change to TE policies is
   required, the customer contacts both ISP1 and ISP2 to make the
   necessary changes on the routers (if they provide this possibility).
   It is however unlikely, that both ISPs will apply changes
   simultaneously, which may lead to inconsistent state for the mappings
   of the LISP site.  Since the different upstream ISPs are usually
   competing business entities, the ETRs may even be configured to
   compete, either to attract all the traffic or to get no traffic.  The
   former will happen if the customer pays per volume, the latter if the
   connectivity has a fixed price.  A solution could be to have the
   mappings in the Map-Server(s), and have their operator give control
   over the entries to customer, much like in today's DNS.

   Additionally, since xTR1, xTR2, and xTR3 are in different
   administrative domains, locator reachability information is unlikely
   to be exchanged among them, making it difficult to set Loc-Status-
   Bits correctly on encapsulated packets.

   Compared to the customer edge scenario, deploying LISP at the
   provider edge might have the advantage of diminishing potential MTU
   issues, because the tunnel router is closer to the core, where links
   typically have higher MTUs than edge network links.

2.3.  Split ITR/ETR

   In a simple LISP deployment, xTRs are located at the border of the
   LISP site (see Section 2.1).  In this scenario packets are routed
   inside the domain according to the EID.  However, more complex
   networks may want to route packets according to the destination RLOC.

   This would enable them to choose the best egress point.

   The LISP specification separates the ITR and ETR functionality and
   considers that both entities can be deployed in separated network
   equipment.  ITRs can be deployed closer to the host (i.e., access
   routers).  This way packets are encapsulated as soon as possible, and
   packets exit the network through the best egress point in terms of
   BGP policy.  In turn, ETRs can be deployed at the border routers of
   the network, and packets are decapsulated as soon as possible.
   Again, once decapsulated packets are routed according to the EID, and
   can follow the best path according to internal routing policy.

   In the following figure we can see an example.  The Source (S)
   transmits packets using its EID and in this particular case packets
   are encapsulated at ITR_1.  The encapsulated packets are routed
   inside the domain according to the destination RLOC, and can egress
   the network through the best point (i.e., closer to the RLOC's AS).
   On the other hand, inbound packets are received by ETR_1 which
   decapsulates them.  Then packets are routed towards S according to
   the EID, again following the best path.

      +---------------------------------------+
      |                                       |
      |       +-------+                   +-------+         +-------+
      |       | ITR_1 |---------+         | ETR_1 |-RLOC_A--| ISP_A |
      |       +-------+         |         +-------+         +-------+
      |  +-+        |           |             |
      |  |S|        |    IGP    |             |
      |  +-+        |           |             |
      |       +-------+         |         +-------+         +-------+
      |       | ITR_2 |---------+         | ETR_2 |-RLOC_B--| ISP_B |
      |       +-------+                   +-------+         +-------+
      |                                       |
      +---------------------------------------+

                     Figure 3: Split ITR/ETR Scenario

   This scenario has a set of implications:

   o  The site must carry at least partial BGP routes in order to choose
      the best egress point, increasing the complexity of the network.
      However, this is usually already the case for LISP sites that
      would benefit from this scenario.

   o  If the site is multihomed to different ISPs and any of the
      upstream ISPs is doing uRPF filtering, this scenario may become
      impractical.  ITRs need to determine the exit ETR, for setting the
      correct source RLOC in the encapsulation header.  This adds
      complexity and reliability concerns.

   o  In LISP, ITRs set the reachability bits when encapsulating data
      packets.  Hence, ITRs need a mechanism to be aware of the liveness
      of ETRs.

   o  ITRs encapsulate packets and in order to achieve efficient
      communications, the MTU of the site must be large enough to
      accommodate this extra header.

   o  In this scenario, each ITR is serving fewer hosts than in the case
      when it is deployed at the border of the network.  It has been
      shown that cache hit ratio grows logarithmically with the amount
      of users [cache].  Taking this into account, when ITRs are
      deployed closer to the host the effectiveness of the mapping cache
      may be lower (i.e., the miss ratio is higher).  Another
      consequence of this is that the site will transmit a higher amount
      of Map-Requests, increasing the load on the distributed mapping
      database.

2.4.  Inter-Service Provider Traffic Engineering

   With LISP, two LISP sites can route packets among them and control
   their ingress TE policies.  Typically, LISP is seen as applicable to
   stub networks, however the LISP protocol can also be applied to
   transit networks recursively.

   Consider the scenario depicted in Figure 4.  Packets originating from
   the LISP site Stub1, client of ISP_A, with destination Stub4, client
   of ISP_B, are LISP encapsulated at their entry point into the ISP_A's
   network.  The external IP header now has as the source RLOC an IP
   from ISP_A's address space (R_A1, R_A2, or R_A3) and destination RLOC from ISP_B's address space (R_B1 or R_B2).
   space.  One or more ASes separate ISP_A from ISP_B. With a single
   level of LISP encapsulation, Stub4 has control over its ingress
   traffic.  However, ISP_B only has the current tools (such as BGP
   prefix deaggregation) to control on which of his own upstream or
   peering links should packets enter.  This is either not feasible (if
   fine-grained per-customer control is required, the very specific
   prefixes may not be propagated) or increases DFZ table size.

                                  _.--.
    Stub1 ...   +-------+      ,-''     `--.      +-------+   ... Stub3
             \  |   R_A1|----,'             `. ---|R_B1   |  /
              --|   R_A2|---(     Transit     )   |       |--
    Stub2 .../  |   R_A3|-----.             ,' ---|R_B2   |  \... Stub4
                +-------+      `--.     _.-'      +-------+
          ...     ISP_A            `--''            ISP_B     ...

               Figure 4: Inter-Service provider TE scenario

   A solution for this is to apply LISP recursively.  ISP_A and ISP_B
   may reach a bilateral agreement to deploy their own private mapping
   system.  ISP_A then encapsulates packets destined for the prefixes of
   ISP_B, which are listed in the shared mapping system.  Note that in
   this case the packet is double-encapsulated. double-encapsulated (using R_A1, R_A2 or R_A3
   as source and R_B1 or R_B2 as destination in the example above).
   ISP_B's ETR removes the outer, second layer of LISP encapsulation
   from the incoming packet, and routes it towards the original RLOC,
   the ETR of Stub4, which does the final decapsulation.

   If ISP_A and ISP_B agree to share a private distributed mapping
   database, both can control their ingress TE without the need of
   disaggregating prefixes.  In this scenario the private database
   contains RLOC-to-RLOC bindings.  The convergence time on the TE
   policies updates is expected to be fast, since ISPs only have to
   update/query a mapping to/from the database.

   This deployment scenario includes two important recommendations.
   First, it is intended to be deployed only between two ISPs (ISP_A and
   ISP_B in Figure 4).  If more than two ISPs use this approach, then
   the xTRs deployed at the participating ISPs must either query
   multiple mapping systems, or the ISPs must agree on a common shared
   mapping system.  Second, the scenario is only recommended for ISPs
   providing connectivity to LISP sites, such that source RLOCs of
   packets to be reencapsulated belong to said ISP.  Otherwise the
   participating ISPs must register prefixes they do not own in the
   above mentioned private mapping system.  Failure to follow these
   recommendations may lead to operational and security issues when
   deploying this scenario.

   Besides these recommendations, the main disadvantages of this
   deployment case are:

   o  Extra LISP header is needed.  This increases the packet size and,
      for efficient communications, it requires that the MTU between
      both ISPs can accommodate double-encapsulated packets.

   o  The ISP ITR must encapsulate packets and therefore must know the
      RLOC-to-RLOC binding.  These bindings are stored in a mapping
      database and may be cached in the ITR's mapping cache.  Cache
      misses lead to an extra lookup latency, unless NERD
      [I-D.lear-lisp-nerd] is used for the lookups.

   o  The operational overhead of maintaining the shared mapping
      database.

   o  If an IPv6 address block is reserved for EID use, as specified in
      [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first
      level) can avoid LISP processing altogether for non-LISP
      destinations.  The ISP tunnel routers however will not be able to
      take advantage of this optimization, all RLOC-to-RLOC mappings
      need a lookup in the private database (or map-cache, once results
      are cached).

2.5.  Tunnel Routers Behind NAT

   NAT in this section refers to IPv4 network address and port
   translation.

2.5.1.  ITR

   Packets encapsulated by an ITR are just UDP packets from a NAT
   device's point of view, and they are handled like any UDP packet,
   there are no additional requirements for LISP data packets.

   Map-Requests sent by an ITR, which create the state in the NAT table
   have a different 5-tuple in the IP header than the Map-Reply
   generated by the authoritative ETR.  Since the source address of this
   packet is different from the destination address of the request
   packet, no state will be matched in the NAT table and the packet will
   be dropped.  To avoid this, the NAT device has to do the following:

   o  Send all UDP packets with source port 4342, regardless of the
      destination port, to the RLOC of the ITR.  The most simple way to
      achieve this is configuring 1:1 NAT mode from the external RLOC of
      the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer
      broadband routers).

   o  Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
      the payload.

   This setup supports a single ITR behind the NAT device.

2.5.2.  ETR

   An ETR placed behind NAT is reachable from the outside by the
   Internet-facing locator of the NAT device.  It needs to know this
   locator (and configure a loopback interface with it), so that it can
   use it in Map-Reply and Map-Register messages.  Thus support for
   dynamic locators for the mapping database is needed in LISP
   equipment.

   Again, only one ETR behind the NAT device is supported.

   An implication of the issues described above is that LISP sites with
   xTRs can not be behind carrier based NATs, since two different sites
   would collide on the port forwarding.

2.6.  Summary and Feature Matrix

          Feature                         CE    PE    Split   Rec.
          --------------------------------------------------------
          Control of ingress TE            x     -      x      x
          No modifications to existing
             int. network infrastructure   x     x      -      -
          Loc-Status-Bits sync             x     -      x      x
          MTU/PMTUD issues minimized       -     x      -      x

3.  Map-Resolvers and Map-Servers

3.1.  Map-Servers

   The Map-Server learns EID-to-RLOC mapping entries from an
   authoritative source and publishes them in the distributed mapping
   database.  These entries are learned through authenticated Map-
   Register messages sent by authoritative ETRs.  Also, upon reception
   of a Map-Request, the Map-Server verifies that the destination EID
   matches an EID-prefix for which it is authoritative for, and then re-
   encapsulates and forwards it to a matching ETR.  Map-Server
   functionality is described in detail in [I-D.ietf-lisp-ms].

   The Map-Server is provided by a Mapping Service Provider (MSP).  A
   MSP can be any of the following:

   o  EID registrar.  Since the IPv4 address space is nearing
      exhaustion, IPv4 EIDs will come from already allocated Provider
      Independent (PI) space.  The registrars in this case remain the
      current five Regional Internet Registries (RIRs).  In the case of
      IPv6, the possibility of reserving a /16 block as EID space is
      currently under consideration [I-D.ietf-lisp-eid-block].  If
      granted by IANA, the community will have to determine the body
      responsible for allocations from this block, and the associated
      policies.  For already allocated IPv6 prefixes the principles from
      IPv4 should be applied.

   o  Third parties.  Participating in the LISP mapping system is
      similar to participating in global routing or DNS: as long as
      there is at least another already participating entity willing to
      forward the newcomer's traffic, there is no barrier to entry.
      Still, just like routing and DNS, LISP mappings have the issue of
      trust, with efforts underway to make the published information
      verifiable.  When these mechanisms will be deployed in the LISP
      mapping system, the burden of providing and verifying trust should
      be kept away from MSPs, which will simply host the secured
      mappings.  This will keep the low barrier of entry to become an
      MSP for third parties.

   In all cases, the MSP configures its Map-Server(s) to publish the
   prefixes of its clients in the distributed mapping database and start
   encapsulating and forwarding Map-Requests to the ETRs of the AS.
   These ETRs register their prefix(es) with the Map-Server(s) through
   periodic authenticated Map-Register messages.  In this context, for
   some LISP end sites, there is a need for mechanisms to:

   o  Automatically distribute EID prefix(es) shared keys between the
      ETRs and the EID-registrar Map-Server.

   o  Dynamically obtain the address of the Map-Server in the ETR of the
      AS.

   The Map-Server plays a key role in the reachability of the EID-
   prefixes it is serving.  On the one hand it is publishing these
   prefixes into the distributed mapping database and on the other hand
   it is encapsulating and forwarding Map-Requests to the authoritative
   ETRs of these prefixes.  ITRs encapsulating towards EIDs under the
   responsibility of a failed Map-Server will be unable to look up any
   of their covering prefixes.  The only exception are the ITRs that
   already contain the mappings in their local cache.  In this case ITRs
   can reach ETRs until the entry expires (typically 24 hours).  For
   this reason, redundant Map-Server deployments are desirable.  A set
   of Map-Servers providing high-availability service to the same set of
   prefixes is called a redundancy group.  ETRs are configured to send
   Map-Register messages to all Map-Servers in the redundancy group.  To
   achieve fail-over (or load-balancing, if desired), current known BGP
   practices can be used on the LISP+ALT BGP overlay network.

   Additionally, if a Map-Server has no reachability for any ETR serving
   a given EID block, it should not originate that block into the
   mapping system.

3.2.  Map-Resolvers

   A Map-Resolver a is a network infrastructure component which accepts
   LISP encapsulated Map-Requests, typically from an ITR, and finds the
   appropriate EID-to-RLOC mapping by either consulting its local cache
   or by consulting the distributed mapping database.  Map-Resolver
   functionality is described in detail in [I-D.ietf-lisp-ms].

   Anyone with access to the distributed mapping database can set up a
   Map-Resolver and provide EID-to-RLOC mapping lookup service.  In the
   case of the LISP+ALT mapping system, the Map-Resolver needs to become
   part of the ALT overlay so that it can forward packets to the
   appropriate Map-Servers.  For more detail on how the ALT overlay
   works, see [I-D.ietf-lisp-alt]

   For performance reasons, it is recommended that LISP sites use Map-
   Resolvers that are topologically close to their ITRs.  ISPs
   supporting LISP will provide this service to their customers,
   possibly restricting access to their user base.  LISP sites not in
   this position can use open access Map-Resolvers, if available.
   However, regardless of the availability of open access resolvers, the
   MSP providing the Map-Server(s) for a LISP site should also make
   available Map-Resolver(s) for the use of that site.

   In medium to large-size ASes, ITRs must be configured with the RLOC
   of a Map-Resolver, operation which can be done manually.  However, in
   Small Office Home Office (SOHO) scenarios a mechanism for
   autoconfiguration should be provided.

   One solution to avoid manual configuration in LISP sites of any size
   is the use of anycast RLOCs for Map-Resolvers similar to the DNS root
   server infrastructure.  Since LISP uses UDP encapsulation, the use of
   anycast would not affect reliability.  LISP routers are then shipped
   with a preconfigured list of well know Map-Resolver RLOCs, which can
   be edited by the network administrator, if needed.

   The use of anycast also helps improving mapping lookup performance.
   Large MSPs can increase the number and geographical diversity of
   their Map-Resolver infrastructure, using a single anycasted RLOC.
   Once LISP deployment is advanced enough, very large content providers
   may also be interested running this kind of setup, to ensure minimal
   connection setup latency for those connecting to their network from
   LISP sites.

   While Map-Servers and Map-Resolvers implement different
   functionalities within the LISP mapping system, they can coexist on
   the same device.  For example, MSPs offering both services, can
   deploy a single Map-Resolver/Map-Server in each PoP where they have a
   presence.

4.  Proxy Tunnel Routers

4.1.  P-ITR

   Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP
   transition mechanism, allowing non-LISP sites to reach LISP sites.

   They announce via BGP certain EID prefixes (aggregated, whenever
   possible) to attract traffic from non-LISP sites towards EIDs in the
   covered range.  They do the mapping system lookup, and encapsulate
   received packets towards the appropriate ETR.  Note that for the
   reverse path LISP sites can reach non-LISP sites simply by not
   encapsulating traffic.  See [I-D.ietf-lisp-interworking] for a
   detailed description of P-ITR functionality.

   The success of new protocols depends greatly on their ability to
   maintain backwards compatibility and inter-operate with the
   protocol(s) they intend to enhance or replace, and on the incentives
   to deploy the necessary new software or equipment.  A LISP site needs
   an interworking mechanism to be reachable from non-LISP sites.  A
   P-ITR can fulfill this role, enabling early adopters to see the
   benefits of LISP, similar to tunnel brokers helping the transition
   from IPv4 to IPv6.  A site benefits from new LISP functionality
   (proportionally with existing global LISP deployment) when going
   LISP, so it has the incentives to deploy the necessary tunnel
   routers.  In order to be reachable from non-LISP sites it has two
   options: keep announcing its prefix(es) with BGP, or have a P-ITR
   announce prefix(es) covering them.

   If the goal of reducing the DFZ routing table size is to be reached,
   the second option is preferred.  Moreover, the second option allows
   LISP-based ingress traffic engineering from all sites.  However, the
   placement of P-ITRs significantly influences performance and
   deployment incentives.  Section Section 5 is dedicated to the
   migration to a LISP-enabled Internet, and includes deployment
   scenarios for P-ITRs.

4.2.  P-ETR

   In contrast to P-ITRs, P-ETRs are not required for the correct
   functioning of all LISP sites.  There are two cases, where they can
   be of great help:

   o  LISP sites with unicast reverse path forwarding (uRPF)
      restrictions, and

   o  LISP sites without native IPv6 communicating with LISP nodes with
      IPv6-only locators.

   In the first case, uRPF filtering is applied at their upstream PE
   router.  When forwarding traffic to non-LISP sites, an ITR does not
   encapsulate packets, leaving the original IP headers intact.  As a
   result, packets will have EIDs in their source address.  Since we are
   discussing the transition period, we can assume that a prefix
   covering the EIDs belonging to the LISP site is advertised to the
   global routing tables by a P-ITR, and the PE router has a route
   towards it.  However, the next hop will not be on the interface
   towards the CE router, so non-encapsulated packets will fail uRPF
   checks.

   To avoid this filtering, the affected ITR encapsulates packets
   towards the locator of the P-ETR for non-LISP destinations.  Now the
   source address of the packets, as seen by the PE router is the ITR's
   locator, which will not fail the uRPF check.  The P-ETR then
   decapsulates and forwards the packets.

   The second use case is IPv4-to-IPv6 transition.  Service providers
   using older access network hardware, which only supports IPv4 can
   still offer IPv6 to their clients, by providing a CPE device running
   LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP
   sites, with IPv6-only locators.  Packets originating from the client
   LISP site for these destinations would be encapsulated towards the
   P-ETR's IPv4 locator.  The P-ETR is in a native IPv6 network,
   decapsulating and forwarding packets.  For non-LISP destination, the
   packet travels natively from the P-ETR.  For LISP destinations with
   IPv6-only locators, the packet will go through a P-ITR, in order to
   reach its destination.

   For more details on P-ETRs see the [I-D.ietf-lisp-interworking]
   draft.

   P-ETRs can be deployed by ISPs wishing to offer value-added services
   to their customers.  As is the case with P-ITRs, P-ETRs too may
   introduce path stretch.  Because of this the ISP needs to consider
   the tradeoff of using several devices, close to the customers, to
   minimize it, or few devices, farther away from the customers,
   minimizing cost instead.

   Since the deployment incentives for P-ITRs and P-ETRs are different,
   it is likely they will be deployed in separate devices, except for
   the CDN case, which may deploy both in a single device.

   In all cases, the existence of a P-ETR involves another step in the
   configuration of a LISP router.  CPE routers, which are typically
   configured by DHCP, stand to benefit most from P-ETRs.  To enable
   autoconfiguration of the P-ETR locator, a DHCP option would be
   required.

   As a security measure, access to P-ETRs should be limited to
   legitimate users by enforcing ACLs.

5.  Migration to LISP

   This section discusses a deployment architecture to support the
   migration to a LISP-enabled Internet.  The loosely defined terms of
   "early transition phase", "late transition phase", and "LISP Internet
   phase" refer to time periods when LISP sites are a minority, a
   majority, or represent all edge networks respectively.

5.1.  LISP+BGP

   For sites wishing to go LISP with their PI prefix the least
   disruptive way is to upgrade their border routers to support LISP,
   register the prefix into the LISP mapping system, but keep announcing
   it with BGP as well.  This way LISP sites will reach them over LISP,
   while legacy sites will be unaffected by the change.  The main
   disadvantage of this approach is that no decrease in the DFZ routing
   table size is achieved.  Still, just increasing the number of LISP
   sites is an important gain, as an increasing LISP/non-LISP site ratio
   will slowly decrease the need for BGP-based traffic engineering that
   leads to prefix deaggregation.  That, in turn, may lead to a decrease
   in the DFZ size in the late transition phase.

   This scenario is not limited to sites that already have their
   prefixes announced with BGP.  Newly allocated EID blocks could follow
   this strategy as well during the early LISP deployment phase,
   depending on the cost/benefit analysis of the individual networks.
   Since this leads to an increase in the DFZ size, the following
   architecture should be preferred for new allocations.

5.2.  Mapping Service Provider (MSP) P-ITR Service

   In addition to publishing their clients' registered prefixes in the
   mapping system, MSPs with enough transit capacity can offer them
   P-ITR service as a separate service.  This service is especially
   useful for new PI allocations, to sites without existing BGP
   infrastructure, that wish to avoid BGP altogether.  The MSP announces
   the prefix into the DFZ, and the client benefits from ingress traffic
   engineering without prefix deaggregation.  The downside of this
   scenario is path stretch, which may be greater than 1.

   Routing all non-LISP ingress traffic through a third party which is
   not one of its ISPs is only feasible for sites with modest amounts of
   traffic (like those using the IPv6 tunnel broker services today),
   especially in the first stage of the transition to LISP, with a
   significant number of legacy sites.  When the LISP/non-LISP site
   ratio becomes high enough, this approach can prove increasingly
   attractive.

   Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
   deaggregation for traffic engineering purposes, resulting in slower
   routing table increase in the case of new allocations and potential
   decrease for existing ones.  Moreover, MSPs serving different clients
   with adjacent aggregable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

5.3.  Proxy-ITR Route Distribution (PITR-RD)

   Instead of a LISP site, or the MSP, announcing their EIDs with BGP to
   the DFZ, this function can be outsourced to a third party, a P-ITR
   Service Provider (PSP).  This will result in a decrease of the
   operational complexity both at the site and at the MSP.

   The PSP manages a set of distributed P-ITR(s) that will advertise the
   corresponding EID prefixes through BGP to the DFZ.  These P-ITR(s)
   will then encapsulate the traffic they receive for those EIDs towards
   the RLOCs of the LISP site, ensuring their reachability from non-LISP
   sites.

   While it is possible for a PSP to manually configure each client's
   EID routes to be announced, this approach offers little flexibility
   and is not scalable.  This section presents a scalable architecture
   that offers automatic distribution of EID routes to LISP sites and
   service providers.

   The architecture requires no modification to existing LISP network
   elements, but it introduces a new (conceptual) network element, the
   EID Route Server, defined as a router that either propagates routes
   learned from other EID Route Servers, or it originates EID Routes.
   The EID-Routes that it originates are those that it is authoritative
   for.  It propagates these routes to Proxy-ITRs within the AS of the
   EID Route Server.  It is worth to note that a BGP capable router can
   be also considered as an EID Route Server.

   Further, an EID-Route is defined as a prefix originated via the Route
   Server of the mapping service provider, which should be aggregated if
   the MSP has multiple customers inside a single netblock.  This prefix
   is propagated to other P-ITRs both within the MSP and to other P-ITR
   operators it peers with.  EID Route Servers are operated either by
   the LISP site, MSPs or PSPs, and they may be collocated with a Map-
   Server or P-ITR, but are a functionally discrete entity.  They
   distribute EID-Routes, using BGP, to other domains, according to
   policies set by participants.

                              MSP (AS64500)
                              RS ---> P-ITR
                               |        /
                               |  _.--./
                              ,-''    /`--.
             LISP site   ---,' |     v     `.
                           (   |   DFZ       )----- Mapping system
         non-LISP site   ----. |    ^      ,'
                              `--. /   _.-'
                               |  `--''
                               v /
                             P-ITR
                             PSP (AS64501)

            Figure 5: The P-ITR Route Distribution architecture

   The architecture described above decouples EID origination from route
   propagation, with the following benefits:

   o  Can accurately represent business relationships between P-ITR
      operators

   o  More mapping system agnostic (no reliance on ALT)

   o  Minor changes to P-ITR implementation, no changes to other
      components

   In the example in the figure we have a MSP providing services to the
   LISP site.  The LISP site does not run BGP, and gets an EID
   allocation directly from a RIR, or from the MSP, who may be a LIR.
   Existing PI allocations can be migrated as well.  The MSP ensures the
   presence of the prefix in the mapping system, and runs an EID Route
   Server to distribute it to P-ITR service providers.  Since the LISP
   site does not run BGP, the prefix will be originated with the AS
   number of the MSP.

   In the simple case depicted in Figure 5 the EID-Route of LISP Site
   will be originated by the Route Server, and announced to the DFZ by
   the PSP's P-ITRs with AS path 64501 64500.  From that point on, the
   usual BGP dynamics apply.  This way, routes announced by P-ITR are
   still originated by the authoritative Route Server.  Note that the
   peering relationships between MSP/PSPs and those in the underlying
   forwarding plane may not be congruent, making the AS path to a P-ITR
   shorter than it is in reality.

   The non-LISP site will select the best path towards the EID-prefix,
   according to its local BGP policies.  Since AS-path length is usually
   an important metric for selecting paths, a careful placement of P-ITR
   could significantly reduce path-stretch between LISP and non-LISP
   sites.

   The architecture allows for flexible policies between MSP/PSPs.
   Consider the EID Route Server networks as control plane overlays,
   facilitating the implementation of policies necessary to reflect the
   business relationships between participants.  The results are then
   injected to the common underlying forwarding plane.  For example,
   some MSP/PSPs may agree to exchange EID-Prefixes and only announce
   them to each of their forwarding plane customers.  Global
   reachability of an EID-prefix depends on the MSP the LISP site buys
   service from, and is also subject to agreement between the mentioned
   parties.

   In terms of impact on the DFZ, this architecture results in a slower
   routing table increase for new allocations, since traffic engineering
   will be done at the LISP level.  For existing allocations migrating
   to LISP, the DFZ may decrease since MSPs may be able to aggregate the
   prefixes announced.

   Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
   deaggregation for traffic engineering purposes, resulting in slower
   routing table increase in the case of new allocations and potential
   decrease for existing ones.  Moreover, MSPs serving different clients
   with adjacent aggregable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

   The flexibility and scalability of this architecture does not come
   without a cost however: A PSP operator has to establish either
   transit or peering relationships to improve their connectivity.

5.4.  Migration Summary

   The following table presents the expected effects of the different
   transition scenarios during a certain phase on the DFZ routing table
   size:

    Phase            | LISP+BGP     | MSP P-ITR       | PITR-RD
    -----------------+--------------+-----------------+----------------
    Early transition | no change    | slower increase | slower increase
    Late transition  | may decrease | slower increase | slower increase
    LISP Internet    |             considerable decrease

   It is expected that PITR-RD will co-exist with LISP+BGP during the
   migration, with the latter being more popular in the early transition
   phase.  As the transition progresses and the MSP P-ITR and PITR-RD
   ecosystem gets more ubiquitous, LISP+BGP should become less
   attractive, slowing down the increase of the number of routes in the
   DFZ.

6.  Security Considerations

   Security implications of LISP deployments are to be discussed in
   separate documents.  [I-D.saucez-lisp-security] gives an overview of
   LISP threat models, while securing mapping lookups is discussed in
   [I-D.ietf-lisp-sec].

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Acknowledgements

   Many thanks to Margaret Wasserman for her contribution to the IETF76
   presentation that kickstarted this work.  The authors would also like
   to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
   Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and
   everyone else who provided input.

9.  References

9.1.  Normative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-15 (work in progress), July 2011.

   [I-D.ietf-lisp-alt]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07 draft-ietf-lisp-alt-09
              (work in progress), June September 2011.

   [I-D.ietf-lisp-interworking]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-02 (work in progress),
              June 2011.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-10 Server Interface",
              draft-ietf-lisp-ms-12 (work in progress), July October 2011.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
              and O. Bonaventure, "LISP-Security (LISP-SEC)",
              draft-ietf-lisp-sec-00 (work in progress), July 2011.

   [I-D.saucez-lisp-security]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP
              Security Threats", draft-saucez-lisp-security-03 (work in
              progress), March 2011.

9.2.  Informative References

   [I-D.ietf-lisp-eid-block]
              Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
              EID Block", draft-ietf-lisp-eid-block-00 draft-ietf-lisp-eid-block-01 (work in
              progress), July October 2011.

   [I-D.lear-lisp-nerd]
              Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08 (work in progress), March 2010.

   [cache]    Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
              performance and the effectiveness of caching", 2002.

Authors' Addresses

   Lorand Jakab
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: ljakab@ac.upc.edu

   Albert Cabellos-Aparicio
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: acabello@ac.upc.edu
   Florin Coras
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: fcoras@ac.upc.edu

   Jordi Domingo-Pascual
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: jordi.domingo@ac.upc.edu

   Darrel Lewis
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com
--------------010301040509060008060604-- From terry.manderson@icann.org Mon Oct 31 18:25:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787BA11E80B5 for ; Mon, 31 Oct 2011 18:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlai4edRwN5n for ; Mon, 31 Oct 2011 18:25:27 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 08D6811E8097 for ; Mon, 31 Oct 2011 18:25:27 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 31 Oct 2011 18:25:09 -0700 From: Terry Manderson To: Yakov Rekhter Date: Mon, 31 Oct 2011 18:25:06 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: AcyYC1As+k/K5VDXRK6rKHVGI8e1bQAKcYFD Message-ID: In-Reply-To: <201110312025.p9VKPRh48085@magenta.juniper.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 01:25:27 -0000 Yakov, >=20 > The charter needs to explicitly include in the Goals and Milestones the > document(s) that cover the analysis. >=20 > Furthermore, as John Scudder asked in his e-mail on 9/28, "the base > spec calls out a number of areas that require more experimentation. > A simple grep will find these. These experiments and what has been > learned from them should be documented. The same applies if other > specs have similar caveats (I just haven't looked for them)." > The charter needs to explicitly include in the Goals and Milestones > the document(s) that cover this. >=20 I missed that - thanks for bringing it up again.. I'll send an update in a few days. Terry From terry.manderson@icann.org Mon Oct 31 18:54:31 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06BC1F0C61 for ; Mon, 31 Oct 2011 18:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uRPKkOnHc9T for ; Mon, 31 Oct 2011 18:54:31 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6026D1F0C42 for ; Mon, 31 Oct 2011 18:54:31 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 31 Oct 2011 18:54:31 -0700 From: Terry Manderson To: Yakov Rekhter Date: Mon, 31 Oct 2011 18:54:29 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: AcyYDEMLL+vBUGqQR16KQz4yjAX/vQALO350 Message-ID: In-Reply-To: <201110312031.p9VKV3h51435@magenta.juniper.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 01:54:31 -0000 Yakov, On 1/11/11 6:31 AM, "Yakov Rekhter" wrote: > Terry, > =20 > If LISP VPN modality is an L2VPN, then such work should be pursued > in L2VPN WG. >=20 > If LISP VPN modality is an L3VPN, then such work should be pursued > in L3VPN WG. >=20 > Thus both of of the above LISP VPN modalities should be outside the > scope of the LISP WG. >=20 Just to keep you (and the list) in the loop, I have escalated this question to the routing and internet area ADs. When I have a sense of their opinions I will respond further. Cheers Terry From terry.manderson@icann.org Mon Oct 31 23:10:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B422211E80DD for ; Mon, 31 Oct 2011 23:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v13WcH-CwQ0G for ; Mon, 31 Oct 2011 23:10:43 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64B11E80E8 for ; Mon, 31 Oct 2011 23:10:20 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 31 Oct 2011 23:10:13 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 31 Oct 2011 23:10:11 -0700 Thread-Topic: [lisp] WG meeting in Taipei, and call for agenda items. Thread-Index: AcyKEwY0EIuWDo6cnUuFIAwKor8L0QIn/5b6AWp5QX8= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] WG meeting in Taipei, and call for agenda items. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 06:10:48 -0000 Folks, The deadline for people to front with agenda requests has passed. I thank the two people that did front, however after some discussion with m= y co-chair we have decided to cancel the LISP slot at IETF 82 as 30 minutes o= f content does not justify using the IETF's time/space at this meeting. Joel and I will still be in Taipei for anyone who desires to speak with us. Next stop, Paris. ;-) Cheers Terry On 25/10/11 11:11 AM, "Terry Manderson" wrote: > Just a reminder folks, >=20 > Normally by this stage I have several requests in for speaking slots- so > far only one has fronted. >=20 > Cheers > Terry >=20 > On 14/10/11 11:46 AM, "Terry" wrote: >=20 >> Folks, >>=20 >> The draft agenda has been released. >>=20 >> https://datatracker.ietf.org/meeting/82/agenda.html >>=20 >> In this IETF 82 draft agenda LISP has the slot: >>=20 >> THURSDAY, November 17, 2011 >> 1740-1940 Afternoon Session III >> 102 INT lisp >> Locator/ID Separation Protocol WG >>=20 >> So the dates to keep in mind are: >>=20 >> 2011-10-17 (Monday): Working Group Chair approval for initial document >> (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). >>=20 >> 2011-10-21 (Friday): Final agenda to be published. >>=20 >> 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) >> submission by 17:00 PT (00:00 UTC). >>=20 >> 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT >> (00:00 UTC). >>=20 >> 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:= 00 >> UTC). >>=20 >> 2011-11-04 (Friday): Early Bird registration and payment cut-off at 17:0= 0 >> PT (00:00 UTC). >>=20 >> 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:0= 0 >> UTC). >>=20 >> So I am now open to receive requests for time on the LISP agenda in Taip= ei. >>=20 >> Please get these to me by 2011-11-01 UTC 00:00:00. >>=20 >> Cheers >> Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp