From jmh@joelhalpern.com Fri Sep 2 09:45:06 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 9195021F8C29 for ; Fri, 2 Sep 2011 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 7B0i2KVN6JLt for ; Fri, 2 Sep 2011 09:45:05 -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 C636021F8C28 for ; Fri, 2 Sep 2011 09:45:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C43E4300E5; Fri, 2 Sep 2011 09:46:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-73.clppva.btas.verizon.net [71.161.50.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 41C0D430080; Fri, 2 Sep 2011 09:46:41 -0700 (PDT) Message-ID: <4E610857.6030404@joelhalpern.com> Date: Fri, 02 Sep 2011 12:46:15 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "lisp@ietf.org" References: <61C3980A-6A22-449B-9922-F5E197F9A3EB@bbn.com> In-Reply-To: <61C3980A-6A22-449B-9922-F5E197F9A3EB@bbn.com> X-Forwarded-Message-Id: <61C3980A-6A22-449B-9922-F5E197F9A3EB@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: [Gen-art] Gen-ART LC review of draft-ietf-lisp-map-versioning-02 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, 02 Sep 2011 16:45:06 -0000 (Terry, I believe you saw this, copying the WG for everyone's information.) This Genart review makes an interesting point. I would like to hear from the authors as to whether they agree. Yours, Joel M. Halpern -------- Original Message -------- Subject: [Gen-art] Gen-ART LC review of draft-ietf-lisp-map-versioning-02 Date: Fri, 2 Sep 2011 11:07:23 -0400 From: Richard L. Barnes To: General Area Review Team I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lisp-map-versioning-02.txt Reviewer: Richard Barnes Review Date: 02 September 2011 IETF LC End Date: 12 September 2011 IESG Telechat date: (if known) - Summary: Not ready Major issues: General Overall the distinction between "older" and "newer" version numbers does not seem meaningful. Treating the two cases differently doesn't add any value, and just causes synchronization problems with things like restarts. The salient distinction is "Is this version number the one I have in my cache or not?" If so, no action; if not, refresh the mapping. Cf. Section 5.1. bullet 2 This bullet needs to be reconsidered. Misbehavior is not the only situation in which this situation could arise. Consider, for example, if the ETR for a site reboots and creates a new random initial map version. Then everyone that has mappings cached will have the wrong map-version, and all traffic will get silently dropped. Suggest adding an error message here that indicates the proper version. Section 5.1. bullet 3 Having an ETR *force* an ITR to update its mapping seems intrusive and fraught with security risks. Suggest adding an error message here that indicates the proper version, so that the ITR can make its own decision as to whether to update the cache. Section 5.1. paragraph after bullet 3 Again, I'm concerned about silently dropping packets. ITRs are not required to renew mappings when TTLs expire, so it's very plausible that an ITR might have stale mappings. If such an ITR just has all its traffic dropped, then it has no signal to refresh. Suggest adding an error message here that indicates the proper version. Minor issues: Editorial: There are numerous grammatical errors, e.g.: "If it is not the case, a Map Request can be send." "... map-versioning does not introduce any new problem ..." "The ETR's synchronization problem is out of the scope of this document." Please expand "w.r.t." _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art From luigi@net.t-labs.tu-berlin.de Wed Sep 7 00:55: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 67E5F21F8B65 for ; Wed, 7 Sep 2011 00:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 OJfVBlEb7P+o for ; Wed, 7 Sep 2011 00:55:30 -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 1590021F8B56 for ; Wed, 7 Sep 2011 00:55:29 -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 733D4714669B; Wed, 7 Sep 2011 09:57:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <4E5C0AAD.2010209@piuha.net> Date: Wed, 7 Sep 2011 09:57:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <122C3494-2C09-4771-8721-5134EA34C3C8@net.t-labs.tu-berlin.de> References: <4E5C0AAD.2010209@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-lisp-map-versioning@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-map-versioning 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, 07 Sep 2011 07:55:31 -0000 Hi Jari, On Aug 29, 2011, at 23:54 , Jari Arkko wrote: > I have reviewed this draft. This is another well written and easy to = understand document. Thank you for that. >=20 > I only found minor editorial issues, one security aspect that you = should document, and couple of small technical comments. I have sent the = document forward to IETF Last Call anyway. Please revise the draft as = soon as you can (even during Last Call). Since the Gen-ART review is also available we were thinking to gather = all changes and submit one single update. (we answer the Gen-ART comments in a separate mail) > Ask me if something was unclear or I missed something. >=20 We put our answers inline. As you will see there is only one point were = we are not sure how to proceed. > Technical: >=20 >> The feature >> introduced by Map-Version numbers is the possibility of blocking >> traffic from ITRs 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 silently drop packets >> with a stale Map-Version number. 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. >=20 > I have two small comments about this. First, since an attack could = spoof the source address, it is important to restrict the blocking to = the offending traffic, not all traffic from a given ITR address. And = this is your intention, as can be seen from the second sentence. Could = you make the following change to make this even clearer in the first = sentence as well: s/blocking traffic from ITRs not using the latest = mapping/blocking traffic not using the latest mapping/. Yes this was our intention. We will change the text as you suggest. >=20 > Second, I'm not sure I understand the different failure cases here. = What if there's a network issue that causes unidirectional connectivity? = We'd receive lisp encapsulated packets, but our attempts to send = commands to update the mapping would be unsuccessful, as the traffic = does not get through. In light of this, is the right action to start = dropping packets on our side? Or maybe there is something else in Lisp = that prevents us from getting into this situation. Please explain. And = if you are not sure what the implications are, please indicate that in = the text. This is an interesting scenario. It must be noted that the return path = is not the same as the forward path. On the forward path there are = packets arriving to the ETR with a stale version number. These packets = follow the data path. The ETR seeing the stale mapping will send a = Map-Request with SMR bit set. This packet will follow the control path = through [LISP-MS] and [LISP-ALT] or any future mapping system. Now, if = the reverse control path fails it means that the there are important = partitioning problem on the mapping system.=20 Do you think we should take an explicit action in this case? Note as well that we use "MAY". What we want to say is "somebody has a = stale mapping and does want or is not able to update hence the ETR is = allowed to ignore that traffic if it wish".=20 >=20 >=20 >> 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 w.r.t. 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 and the packet MAY be >> silently dropped. >>=20 >=20 > I worry that there's a dependency on something which cannot be fully = secured in the real-world, and if someone starts to drop packets due to = an inconsistency there is no easy way to recover. I would suggest adding = something to the security considerations section about reliance on the = security of the mapping system and aggressive drop policies leading to = the possibility of difficult recovery from a temporary mapping system = issue. Again we put a "MAY" and we are not suggesting aggressive drop. But we = agree that we should more explicitly state in the security section that = versioning assumes a secured mapping system. If the mapping system is = compromised somehow versioning loses its robustness. =20 >=20 >> Once no more traffic is received by the RLOC, because all sites have >> updated the mapping, it can be shut down safely. >=20 > Technically, there might be a mapping on some other site that has not = had a reason to send a packet yet. But if it then sends a packet, it = might use a locally cached copy of the mapping and the packet goes to = the wrong place. >=20 > Perhaps you should clarify this. E.g. " ... received by the RLOC, it = can be shut down in relatively safety, because at least all sites = actively using the mapping have updated it." Yes. We will clarify this point as you suggest. >=20 >=20 > Editorial: >=20 >> This document describes the LISP Map-Versioning mechanism, which >> provides in-packet information about 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 xTRs 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 xTRs >> that do not support the mechanism. >=20 > You should expand EID, RLOC, and xTR, as this is the abstract (it can = be read by someone without seeing the rest of the document). OK. >=20 >> 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. >=20 > I'd prefer seeing a reference to draft-ietf-lisp and section number = that defines the Lisp header. We will put the reference. >=20 >> The Map-Request will either trigger a Map-Request back >> using the 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], >=20 > Expand SMR. >=20 OK. >=20 >> A Proxy-ETR does not have any mapping, since it just decapsulate >> packets arriving from LISP site. >=20 > s/decapsulate/decapsulates/ >=20 Thanks. Luigi on behalf of all authors. > Jari >=20 From luigi@net.t-labs.tu-berlin.de Wed Sep 7 01:46: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 4DBED21F86C1 for ; Wed, 7 Sep 2011 01:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 FYweDan3EZaW for ; Wed, 7 Sep 2011 01:46:19 -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 A4D5321F86EA for ; Wed, 7 Sep 2011 01:46:18 -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 EEB9071466B5; Wed, 7 Sep 2011 10:48:06 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Luigi Iannone Date: Wed, 7 Sep 2011 10:48:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F69C5BA-FD74-4D39-B691-D8B0110258C8@net.t-labs.tu-berlin.de> To: rbarnes@bbn.com X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org, draft-ietf-lisp-map-versioning.all@tools.ietf.org Subject: Re: [lisp] [Gen-art] Gen-ART LC review of draft-ietf-lisp-map-versioning-02 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, 07 Sep 2011 08:46:20 -0000 Hi Richard, thanks for your review.=20 Our answers can be found inline On Sep 2, 2011, at 18:46 , Joel M. Halpern wrote: > (Terry, I believe you saw this, copying the WG for everyone's = information.) > This Genart review makes an interesting point. I would like to hear = from the authors as to whether they agree. >=20 > Yours, > Joel M. Halpern >=20 > -------- Original Message -------- > Subject: [Gen-art] Gen-ART LC review of = draft-ietf-lisp-map-versioning-02 > Date: Fri, 2 Sep 2011 11:07:23 -0400 > From: Richard L. Barnes > To: General Area Review Team >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-lisp-map-versioning-02.txt > Reviewer: Richard Barnes > Review Date: 02 September 2011 > IETF LC End Date: 12 September 2011 > IESG Telechat date: (if known) - >=20 > Summary: > Not ready >=20 > Major issues: >=20 > General > Overall the distinction between "older" and "newer" version numbers = does not seem meaningful. Treating the two cases differently doesn't = add any value, and just causes synchronization problems with things like = restarts. The salient distinction is "Is this version number the one I = have in my cache or not?" If so, no action; if not, refresh the = mapping. Cf. Thanks for the pointer, but while the nomenclature looks pretty similar, = the context is quite different. AFAIK, in xmpp when a client contacts a = server it asks for the roster, to which a version number can be = associated since it changes not that often. This works perfectly in the = client-server model where for each query a check is done, if something = is different then an update takes place. In LISP there are scenarios where communication may be asymmetric and/or = triangular, e.g., two ITRs sending to the same ETR. The core idea of map-version is to have a mean for xTRs to understand if = they are using the "latest" mapping.=20 This must work also for ongoing flows, roughly it can be translated to a = changing version in the middle of a query in xmpp (may be a forced = parallel but it might give the idea). To this end it is necessary to introduce the notion of ordering in the = version number. This is necessary in several scenarios we describe in = the document. For instance, let's consider two ITRs from the same site that are = sending traffic to the same ETR of a remote site. If a mapping update happens during heavy traffic exchange due to obvious = path propagation differences even if the ITRs change mapping exactly at = the same time the ETR will receive for a certain period (which at high = bandwidth can mean a lot of packets) a series of interleaved packets = with different version number in its header.=20 With the simple policy you suggest above the risk is that the ETR will = send out a burst of requests because each time it will think that the = version has changed. This can potentially lead instabilities.=20 Hope this simple scenario clarifies the need of ordering. The question of sequential version vs. opaque version (nonce) has been = discussed in depth on the mailing list and ended with a WG consensus = during the Anaheim meeting (77th IETF). >=20 > Section 5.1. bullet 2 > This bullet needs to be reconsidered. Misbehavior is not the only = situation in which this situation could arise. Consider, for example, = if the ETR for a site reboots and creates a new random initial map = version. This could not happen. As we explain in section 8.1, all ETRs needs to = have (and announce to the mapping system) exactly the same mapping. Any = inconsistency can lead to traffic disruption. This is a general property = of LISP is not specific to versioning.=20 The Map-Version number is just another field in the Map-Record and like = any other field must be consistent on all ETRs. > Then everyone that has mappings cached will have the wrong = map-version, and all traffic will get silently dropped. Suggest adding = an error message here that indicates the proper version. >=20 > Section 5.1. bullet 3 > Having an ETR *force* an ITR to update its mapping seems intrusive and = fraught with security risks. This is an interesting point. In the LISP model the ETR is the = authoritative network element concerning mappings. This is a basic = principle of the LISP model and the security threats of this model are = analyzed in [LISP-THREATS] while how to secure mapping is covered in = [LISP-SEC]. > Suggest adding an error message here that indicates the proper = version, so that the ITR can make its own decision as to whether to = update the cache. >=20 > Section 5.1. paragraph after bullet 3 > Again, I'm concerned about silently dropping packets. ITRs are not = required to renew mappings when TTLs expire, so it's very plausible that = an ITR might have stale mappings. They should refresh the mapping if the TTL expires and they want to use = it. Failing to do so has obviously consequences.=20 The stale mapping can even have disappeared. This is independent from = map-versioning. > If such an ITR just has all its traffic dropped, then it has no signal = to refresh. Rightful observation, however, while the ETR MAY drop the traffic it can = as well signal back to the ITR to update the mapping. This is done = through a Map-Request with the SMR bit set. > Suggest adding an error message here that indicates the proper = version. >=20 > Minor issues: >=20 >=20 Thanks for pointing out these typos. > Editorial: >=20 > There are numerous grammatical errors, e.g.: > "If it is not the case, a Map Request can be send." > "... map-versioning does not introduce any new problem ..." > "The ETR's synchronization problem is out of the scope of this = document." >=20 > Please expand "w.r.t." was meant for "with respect to", will be expanded. Luigi on behalf of the authors > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Wed Sep 7 09:57: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 AAA0B21F8CDB; Wed, 7 Sep 2011 09:57:24 -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 PEfvFNZuS2MW; Wed, 7 Sep 2011 09:57:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A6321F8CC3; Wed, 7 Sep 2011 09:57:24 -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: <20110907165724.15929.53085.idtracker@ietfa.amsl.com> Date: Wed, 07 Sep 2011 09:57:24 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lig-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: Wed, 07 Sep 2011 16:57:24 -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 Internet Groper (LIG) Author(s) : Dino Farinacci Dave Meyer Filename : draft-ietf-lisp-lig-05.txt Pages : 19 Date : 2011-09-07 A simple tool called the LISP Internet Groper or 'lig' can be us= ed to query the LISP mapping database. This draft describes how it works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-lig-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-lig-05.txt From jari.arkko@piuha.net Wed Sep 7 15:10:13 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 1781A21F8E03 for ; Wed, 7 Sep 2011 15:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 rzwanl3wXRne for ; Wed, 7 Sep 2011 15:10:12 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 323ED21F8D6C for ; Wed, 7 Sep 2011 15:10:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 352832D546; Thu, 8 Sep 2011 01:11:56 +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 qnbu+ptlP7Tx; Thu, 8 Sep 2011 01:11:55 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1F94B2CE32; Thu, 8 Sep 2011 01:11:55 +0300 (EEST) Message-ID: <4E67EC2A.6000201@piuha.net> Date: Thu, 08 Sep 2011 01:11:54 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org, Terry Manderson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp-alt 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, 07 Sep 2011 22:10:13 -0000 I have reviewed this draft. Like the other drafts that I have read, it was well written and pleasure to read. Thanks for doing good work. This draft does have some hand waving in some aspects (like exactly how the ALT is built), but that's acceptable for an experimental specification. I did have four remaining issues that I would like to talk about though. One is a question and for the other three I have some suggested way forward. I also have a small set of editorial suggestions at the end of this mail. Please respond and/or revise draft so that we can send this one to IETF Last Call. The question is about the treatment of RLOC source and EID destination addresses when something bad happens in ALT (no route or some other problem, say MTU limitation). Do you expect ICMP messages be sent back, and if so, how? The use of RLOC source addresses seems to have an effect on intermixing IPv4 and IPv6 addresses. It would perhaps be desirable in some cases to allow IPv4 RLOCs while working with IPv6 EIDs, for instance. But those RLOCs cannot be directly used on IPv6 packets that carry IPv6 destination addresses. (At least not without agreeing that some form of mapped addresses are used. But that doesn't work for carrying an IPv6 source address in an IPv4 packet.) My suggestion is to add some text about this. As this is an experimental specification and because we do not fully understand all aspects of its operation, I think it is useful to add some description at the beginning about the areas where further experience is needed. Finally, I'm concerned about the Section 6.1 recommendation to use a "new numbering space that is unrelated to the ASNs used in the global routing system". First of all, its not clear to me what you are saying here. Are you (a) recommending that the 32-bit ASN space can just be reused and it doesn't matter if ALT uses the same numbers as someone in the current Internet? Or are you saying (b) that some new allocations (or perhaps even a small subspace) should be allocated from the existing ASN space and used for ALT, without colliding with any existing allocations? I think the former would be problematic, because its hard to prevent accidental leakage. But getting some new numbers for ALT usage would perfectly fine, IMO. I'm also wondering if we should just allocate a new SAFI (even if we do not require that legacy router implementations use it). Here's some suggested text changes for Section 6.1: OLD: To avoid confusion, it needs to be stressed that that these LISP+ALT ASNs use a new numbering space that is unrelated to the ASNs used by the global routing system. NEW: To avoid confusion, it needs to be stressed that that these LISP+ALT ASNs should use newly allocated ASN numbers that are unrelated to the ASNs used by the global routing system. And some suggested new text for Section 1, to be inserted just before the last paragraph: NEW: This specification is experimental, and there are areas where further experience is needed in order to understand the best implementation strategies, operational models, and impacts to the rest of the Internet. These areas include: - application effects of on-demand route map discovery - the impacts of using map requests versus carrying initial packets in ALT - the best practical ways to build ALT hierarchies - effects of route leakage from ALT to the current Internet - effects of exceptional situations, such as denial-of-service attacks Experimentation, measurements, and deployment experience on these aspects is appreciated. While the theoretical impacts are often understood (such as an ALT lookup causing a potential delay for the first packet destined to a given network), it is less clear what effects, if any, these may have with real world traffic patterns. ALT cannot support mixed use of IPv4 and IPv6 addresses, as it requires the use of the same address family for both RLOCs and EIDs. (Feel free to suggest alternate text.) Editorial: > ... little, if any, LISP-specific modifications should be > needed for such devices to be deployed on the ALT. Perhaps you could add a reference to Section 4.2 that discusses what is possible and is not possible with pure off-the-shelf routers. Otherwise the statement feels a little bit fuzzy. s/on the ALT./on the ALT (see Section 4.2)./ > == Outdated reference: A later version (-15) exists of draft-ietf-lisp-14 > > == Outdated reference: A later version (-11) exists of draft-ietf-lisp-ms-09 > (from idnits, please fix) > Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit (for ipv6) value > reachability is carried as IPv4 or ipv6 NLRI without modification > s/ipv6/IPv6/ > This might be done minimize packet loss and to > probe for the mapping. ... might be done to minimize ... > low performance expected of a tuneled topology, ALT Routers (and Map > s/tuneled/tunneled/ Jari From ljakab@ac.upc.edu Thu Sep 8 11:56: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 DFB7A21F8494 for ; Thu, 8 Sep 2011 11:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ZAJo9u13cle2 for ; Thu, 8 Sep 2011 11:56:22 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id EC94421F8492 for ; Thu, 8 Sep 2011 11:56:21 -0700 (PDT) Received: from [147.83.34.118] (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id B237B6B023B for ; Thu, 8 Sep 2011 20:58:09 +0200 (CEST) Message-ID: <4E691042.7080207@ac.upc.edu> Date: Thu, 08 Sep 2011 20:58:10 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org OpenPGP: id=90710D74; url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc X-OpenPGP-Fingerprint: 5EBC 8566 7524 D711 F210 9D80 954C 0DEF 9071 0D74 X-Philosophy: "Simplicity is the ultimate sophistication." --Leonardo da Vinci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] Announcing the first public release of LISPmob 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, 08 Sep 2011 18:56:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The LISPmob development team is pleased to announce the first public release of LISPmob for Linux. LISPmob was developed by Cisco Systems and it is now being released under the GPLv2, hosted and maintained at the Technical University of Catalonia (UPC). About LISPmob - ------------- LISPmob is an open source IP mobility solution for Linux hosts, implementing the LISP Mobile Node [1] specification, which is based on the Locator/Identifier Separation Protocol (LISP) [2]. LISP is being developed within the IETF as a potential solution to the routing scalability problem documented in RFC 4984 [3]. Getting LISPmob - --------------- LISPmob source code is available from the project web site, http://lispmob.org/ and the public git repository is available from Github: https://github.com/LISPmob/lispmob Features - -------- LISPmob supports the following features: * IPv4-in-IPv4 encapsulation and decapsulation of LISP data packets, based on the map-cache * Map-Register * Map-Request/Map-Reply * SMR * RLOC probing A more detailed feature list is available in the project wiki: https://github.com/LISPmob/lispmob/wiki/Features Getting Help - ------------ The 'users' mailing list offers community support, see the project web site for subscription information and web archives. Community support is also available on the Freenode Internet Relay Chat (IRC) network, by joining the #lispmob channel. References - ---------- [1] https://tools.ietf.org/html/draft-meyer-lisp-mn [2] https://tools.ietf.org/html/draft-ietf-lisp [3] https://tools.ietf.org/html/rfc4984 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk5pEEIACgkQlUwN75BxDXSoMACgsaW+0NnDroyV3fCiJBDGiZ/s MeMAnRb42gR43wtSy5uAa3bIFWilKM8Z =3DkK -----END PGP SIGNATURE----- From vaf@cisco.com Thu Sep 8 13:11:43 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 4668B21F899F for ; Thu, 8 Sep 2011 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.07 X-Spam-Level: X-Spam-Status: No, score=-5.07 tagged_above=-999 required=5 tests=[AWL=-3.071, BAYES_00=-2.599, 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 5GIp1tmOPHRh for ; Thu, 8 Sep 2011 13:11:42 -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 6728C21F8997 for ; Thu, 8 Sep 2011 13:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=6486; q=dns/txt; s=iport; t=1315512815; x=1316722415; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Dj2TMBeBcSbODWYDlYEzk3XX3mRvHWWPeHkcWoizjwI=; b=ag89pRcsZZQlKPh5hoKEUuChHiUK1M6eFwckbYv2cbK6J7r90oRB84PN tBztJD0qoJ6kugrfUmu7JUusD2+vvqNfqzX4i5+tjq4ppXEDkY/dlTuCp AMyDJqghBtmiqr1mOpoTMAV27KvFRD4emAJt4QYCzryo+gLWNhs7Y0rQ7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALIgaU6rRDoH/2dsb2JhbABCqAJ4gUYBAQEBAgESASc/BQsLRhQYMTWHU5oTAZ4thg1gBIdsnH0 X-IronPort-AV: E=Sophos;i="4.68,351,1312156800"; d="scan'208";a="1011088" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 08 Sep 2011 20:13:35 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p88KDZ1w025490; Thu, 8 Sep 2011 20:13:35 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 4EDCD1654CAB; Thu, 8 Sep 2011 13:13:36 -0700 (PDT) Date: Thu, 8 Sep 2011 13:13:36 -0700 From: Vince Fuller To: Jari Arkko Message-ID: <20110908201335.GA60444@vaf-mac1.cisco.com> References: <4E67EC2A.6000201@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E67EC2A.6000201@piuha.net> User-Agent: Mutt/1.4.2.3i Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 08 Sep 2011 20:11:43 -0000 Hi Jari- Thanks for the review, comments, and suggestions. Here are my thoughts in response. > The question is about the treatment of RLOC source and EID destination > addresses when something bad happens in ALT (no route or some other > problem, say MTU limitation). Do you expect ICMP messages be sent back, and > if so, how? An ALT node can attempt to return an ICMP message in response to an error condition (next hop unreachable, etc.) but there is obviously no guarantee that it will be received since the RLOC destination may not be reachable by a device which can only route on the ALT EID numbering space. Such a failure will result in the sender of the Map-Request (and MR or ETR) giving up after several retransmissions and treating the destination as unreachable via LISP. Depending on how the source is configured, it may then try to use LISP Interworking mechanisms to route "natively" to the destination. > The use of RLOC source addresses seems to have an effect on intermixing > IPv4 and IPv6 addresses. It would perhaps be desirable in some cases to > allow IPv4 RLOCs while working with IPv6 EIDs, for instance. But those > RLOCs cannot be directly used on IPv6 packets that carry IPv6 destination > addresses. (At least not without agreeing that some form of mapped > addresses are used. But that doesn't work for carrying an IPv6 source > address in an IPv4 packet.) My suggestion is to add some text about this. > > As this is an experimental specification and because we do not fully > understand all aspects of its operation, I think it is useful to add some > description at the beginning about the areas where further experience is > needed. This situation is supposed to be covered by use of the ITR RLOC field. Use of an ITR-provided RLOC is mentioned in section 5 and is further described in [LISP] section 6.1.2 (where the field is shown in the Map-Request message format) and section 6.2 (Routing Locator Section). I will add appropriate references to [LISP] regarding ITR RLOC usage and will explicitly mention the mixed-AF use case. Will that resolve this issue? Keep in mind that the ALT exists for one purpose: so that a Map-Request for an EID can be forwarded toward the ETR that can provide a Map-Reply. Traffic is not bi-directional and the ITR RLOC information is included in the Map-Request so that a responding ETR or MS can return a Map-Reply directly to the Map-Request originator, bypassing the ALT. > Finally, I'm concerned about the Section 6.1 recommendation to use a "new > numbering space that is unrelated to the ASNs used in the global routing > system". First of all, its not clear to me what you are saying here. Are > you (a) recommending that the 32-bit ASN space can just be reused and it > doesn't matter if ALT uses the same numbers as someone in the current > Internet? Or are you saying (b) that some new allocations (or perhaps even > a small subspace) should be allocated from the existing ASN space and used > for ALT, without colliding with any existing allocations? I think the > former would be problematic, because its hard to prevent accidental > leakage. But getting some new numbers for ALT usage would perfectly fine, > IMO. I'm also wondering if we should just allocate a new SAFI (even if we > do not require that legacy router implementations use it). > > Here's some suggested text changes for Section 6.1: > > OLD: > To avoid confusion, it needs to be stressed that that > these LISP+ALT ASNs use a new numbering space that is unrelated to > the ASNs used by the global routing system. > NEW: > To avoid confusion, it needs to be stressed that that > these LISP+ALT ASNs should use newly allocated ASN numbers that are > unrelated to > the ASNs used by the global routing system. Thanks for the suggested text; I'll add to draft-ietf-lisp-alt-08. > And some suggested new text for Section 1, to be inserted just before the > last paragraph: > > NEW: > This specification is experimental, and there are areas where further > experience is needed > in order to understand the best implementation strategies, operational > models, and impacts to > the rest of the Internet. These areas include: > > - application effects of on-demand route map discovery > - the impacts of using map requests versus carrying initial packets in ALT > - the best practical ways to build ALT hierarchies > - effects of route leakage from ALT to the current Internet > - effects of exceptional situations, such as denial-of-service attacks > > Experimentation, measurements, and deployment experience on these aspects > is appreciated. While the theoretical impacts are often understood (such > as an ALT lookup causing a potential delay for the first packet destined > to a given network), it is less clear what effects, if any, these may > have with real world traffic patterns. > > ALT cannot support mixed use of IPv4 and IPv6 addresses, as it requires > the use of the same > address family for both RLOCs and EIDs. > > (Feel free to suggest alternate text.) Again, thanks for the suggestion. I'll start with this and re-work it a bit for incorporation into section 1 of the -08 draft. > Editorial: > > > >... little, if any, LISP-specific modifications should be > >needed for such devices to be deployed on the ALT. > > Perhaps you could add a reference to Section 4.2 that discusses what is > possible and is not possible with pure off-the-shelf routers. Otherwise the > statement feels a little bit fuzzy. > > s/on the ALT./on the ALT (see Section 4.2)./ Thanks, will fix in -08. > > == Outdated reference: A later version (-15) exists of > > draft-ietf-lisp-14 > > > > == Outdated reference: A later version (-11) exists of > > draft-ietf-lisp-ms-09 > > > > (from idnits, please fix) Thanks, will fix in -08. Of course, creating -08 will result in an idnit for those documents, since they reference ALT-08; will plan to fix those as part of their AD reviews. > >This might be done minimize packet loss and to > > probe for the mapping. > > ... might be done to minimize ... Thanks, will fix in -08. > > low performance expected of a tuneled topology, ALT Routers (and Map > > > > s/tuneled/tunneled/ Thanks, will fix in -08. --Vince From jari.arkko@piuha.net Thu Sep 8 13:32:14 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 7F89E21F8B6F for ; Thu, 8 Sep 2011 13:32:14 -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 AhNUlajCyKc4 for ; Thu, 8 Sep 2011 13:32:14 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id DE42E21F8B42 for ; Thu, 8 Sep 2011 13:32:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1FB3D2CEFF; Thu, 8 Sep 2011 23:34:05 +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 4eIBGekCVkRA; Thu, 8 Sep 2011 23:34:04 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9CA5D2CE32; Thu, 8 Sep 2011 23:34:04 +0300 (EEST) Message-ID: <4E6926BC.3050102@piuha.net> Date: Thu, 08 Sep 2011 23:34:04 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Vince Fuller References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> In-Reply-To: <20110908201335.GA60444@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 08 Sep 2011 20:32:14 -0000 Vince, Thanks for your quick response. I think you solved my mixed case issue. I'd still like to understand the ICMP message situation better. I realize that the traffic is supposed to be unidirectional, but how would, say, lower MTU somewhere along the path be dealt with? I'm not necessarily asking for a change in what the spec does, but it should be clear about the consequences. Jari From dino@cisco.com Thu Sep 8 13:35: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 15C7621F8B72 for ; Thu, 8 Sep 2011 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.963, 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 gTqYNmfQK6Ll for ; Thu, 8 Sep 2011 13:35:48 -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 7D43A21F8B55 for ; Thu, 8 Sep 2011 13:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=911; q=dns/txt; s=iport; t=1315514261; x=1316723861; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oghIlhQiRAbphCkhpi1NGAY5uYl//cOZXJorWAm1a0E=; b=JuAH2ANDUjmJoJkYoGtRgDm1ylqT3jmzYBAG3jTjQ74WFeaDaCjnfAfm yIBu97p6o4AToH8KdCfK08+HUpuQf1B5BKdvbtj0X2BvHROPnCtKabNt3 k+ZGLQ2MiQa0aWHBnBwlgC7kKn2nceg8Vj9RX0jNrKIyHrKdMDE0n7kCf I=; X-IronPort-AV: E=Sophos;i="4.68,352,1312156800"; d="scan'208";a="1015704" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 08 Sep 2011 20:37:41 +0000 Received: from sjc-vpn4-701.cisco.com (sjc-vpn4-701.cisco.com [10.21.82.189]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p88Kbfj2008492; Thu, 8 Sep 2011 20:37:41 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <4E6926BC.3050102@piuha.net> Date: Thu, 8 Sep 2011 13:37:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 08 Sep 2011 20:35:49 -0000 > Vince, >=20 > Thanks for your quick response. I think you solved my mixed case = issue. >=20 > I'd still like to understand the ICMP message situation better. I = realize that the traffic is supposed to be unidirectional, but how = would, say, lower MTU somewhere along the path be dealt with? I'm not = necessarily asking for a change in what the spec does, but it should be = clear about the consequences. Since Map-Requets are small, it is unlikely that an MTU violation will = occur for a Map-Request forwarded on the ALT. But if the case did arise, = there would be fragmentation and reassembly at each GRE end-point since = a Map-Request, when sent from one ALT node to another, is encapsulated = in a GRE tunnel header. Dino >=20 > Jari >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From vaf@cisco.com Thu Sep 8 13:45: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 7E69221F8B63 for ; Thu, 8 Sep 2011 13:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[AWL=-2.387, 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 JQSS1Mk+dk8D for ; Thu, 8 Sep 2011 13:45:44 -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 EA30521F8B55 for ; Thu, 8 Sep 2011 13:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=1086; q=dns/txt; s=iport; t=1315514858; x=1316724458; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NFn7ksr9Ydip20kacgpZoYk/ZeDuxRpSW97wAgLXFtU=; b=EHEhLJGK1ZsY5pWifCvvSGqAGg0ZpbfzCCSztY45L5y89nAzmmWE4GV+ kapEz7RuNe9Rzfr/AUcMHkk3NRlf/jsWcahiaZrhQfqeUt2D1mO9cfJmg a7c4n/mdd43tPsP9JHhMNN90JMwiDOFRRChopQaU63n5VD/exjNBhKoIO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKcoaU6rRDoG/2dsb2JhbABCqAJ4gUYBAQEBAgESASc/BQsLRhQYMTWHU5oCAZ4whg1gBIdsnH0 X-IronPort-AV: E=Sophos;i="4.68,352,1312156800"; d="scan'208";a="1016805" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 08 Sep 2011 20:47:37 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p88KlbMS016882; Thu, 8 Sep 2011 20:47:37 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id A1AC41655489; Thu, 8 Sep 2011 13:47:37 -0700 (PDT) Date: Thu, 8 Sep 2011 13:47:37 -0700 From: Vince Fuller To: Jari Arkko Message-ID: <20110908204737.GA65661@vaf-mac1.cisco.com> References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6926BC.3050102@piuha.net> User-Agent: Mutt/1.4.2.3i Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 08 Sep 2011 20:45:45 -0000 > Thanks for your quick response. I think you solved my mixed case issue. > > I'd still like to understand the ICMP message situation better. I realize > that the traffic is supposed to be unidirectional, but how would, say, > lower MTU somewhere along the path be dealt with? I'm not necessarily > asking for a change in what the spec does, but it should be clear about the > consequences. Under normal circumstances, the only thing that should be send across the ALT would be a Map Request, which should not cause MTU problems. Of course, if a (deprecated) Data Probe were used, then all bets are off. If a Map Request or Data Probe were to hit an MTU problem or otherwise be undeliverable across the ALT and no ICMP message could be returned from the ALT node where the failure occurred to the Map Request originator, then the originator would retry sending the Map Request several times before timing-out. If such a timeout occurred, then the destination would be considered not LISP-capable and LISP encapsulation would not be done toward it. --Vince From internet-drafts@ietf.org Thu Sep 8 22:01: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 AF9FA21F8A95; Thu, 8 Sep 2011 22:01:37 -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 15iM-U0+OBXE; Thu, 8 Sep 2011 22:01:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA0621F8A7A; Thu, 8 Sep 2011 22:01: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.60 Message-ID: <20110909050136.6941.83636.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2011 22:01:36 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-alt-08.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, 09 Sep 2011 05:01: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 Alternative Topology (LISP+ALT) Author(s) : Vince Fuller Dino Farinacci Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-alt-08.txt Pages : 29 Date : 2011-09-08 This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-08.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-alt-08.txt From vaf@cisco.com Thu Sep 8 22:18:02 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 0468721F8B68 for ; Thu, 8 Sep 2011 22:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.721 X-Spam-Level: X-Spam-Status: No, score=-4.721 tagged_above=-999 required=5 tests=[AWL=-2.123, BAYES_00=-2.599, 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 AEPKu5j95c60 for ; Thu, 8 Sep 2011 22:18:00 -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 941D321F8B55 for ; Thu, 8 Sep 2011 22:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=26787; q=dns/txt; s=iport; t=1315545594; x=1316755194; h=date:from:to:subject:message-id:references:mime-version: in-reply-to; bh=s5cTMwHqx7VXQymQFoLWFj3fPNmE8RqxXKeAOc/UhTM=; b=CCFZRotPRaurlqJ40s0rWw8Es8vHq9JK6AOtLUrHdU/G2599oGBXfB42 +LlrvELkEAJhbbACI68VZiDIEg0bRVcpllYy+yz1x7cDHgGiA6TOH3Mb4 RyT6vR9JPyXiIWgvhmYVdnPSj8rPSPfHBV+grxIEVYERrWIIlQPqwvqQz A=; X-Files: rfcdiff-alt-07-to-08.html : 25419 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYGAKOhaU6rRDoI/2dsb2JhbABDgk2WVhCHEAGHQXiBRgEBAQEDEgEaXAsYIAENFBhECREIh1eZSgGeQYYNYASHbJVKhWqBSA X-IronPort-AV: E=Sophos;i="4.68,354,1312156800"; d="html'217?scan'217,208,217";a="1087198" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 09 Sep 2011 05:19:54 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p895JsHB027912 for ; Fri, 9 Sep 2011 05:19:54 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 299A4165B3B8; Thu, 8 Sep 2011 22:19:53 -0700 (PDT) Date: Thu, 8 Sep 2011 22:19:53 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110909051952.GA93717@vaf-mac1.cisco.com> References: <20110909050136.6941.83636.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20110909050136.6941.83636.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Subject: Re: [lisp] I-D Action: draft-ietf-lisp-alt-08.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, 09 Sep 2011 05:18:02 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 08, 2011 at 10:01:36PM -0700, internet-drafts@ietf.org wrote: > 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 Alternative Topology (LISP+ALT) > Author(s) : Vince Fuller > Dino Farinacci > Dave Meyer > Darrel Lewis > Filename : draft-ietf-lisp-alt-08.txt > Pages : 29 > Date : 2011-09-08 ... This version incorporates changes requested during Jari's AD review. An rfcdiff from the previous version (07) is attached below. Vince & Dino --liOOAslEiF7prFVr Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-alt-07-to-08.html" 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
Dkim
Dnsext
Dnsop
Drinks
Eai
Ecrit*
Eman
Emu
Fecframe
Forces
Ftpext2
Geopriv
Grow
Hip
Hokey
Homenet
Httpbis
Hybi*
Idr
Intarea
Ipfix
Ippm
Ipsecme
Iri
Isis
Karp
Kitten
Krb-wg
L2tpext
L2vpn
L3vpn
Ledbat
Lisp*
Lwig
Manet*
Marf
Mboned
Mediactrl
Mext
Mif
Mip4
Mmusic
Mpls*
Mptcp
Msec
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
Xcon
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 -
--liOOAslEiF7prFVr-- From rogerj@gmail.com Fri Sep 9 00:30: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 6165421F8AA8 for ; Fri, 9 Sep 2011 00:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 d2B3KTkrrCsM for ; Fri, 9 Sep 2011 00:30:05 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA67421F8906 for ; Fri, 9 Sep 2011 00:30:04 -0700 (PDT) Received: by bkaq10 with SMTP id q10so1436436bka.31 for ; Fri, 09 Sep 2011 00:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=VUWIHDpXbBgZyY9YTqGFnM95rog9Nl0jrnVbHnAX/G0=; b=oXDOrWmtRMVy2xy4w2/xrRD4Kmt+iNIprV9kDi0wv+JTFKfyLkN7H0q+dPuZ+HbOeX 3RnbHpKWH5g1sqFsyfMIROuRuBTpUvLJD3txl0bnJqdW8vvj2XsTJmVOzL6HD2s8r5lG fpKlQvyouKVrAvxhcGLDZpY19dCbr7kKFqkNE= MIME-Version: 1.0 Received: by 10.204.148.154 with SMTP id p26mr38115bkv.160.1315553518186; Fri, 09 Sep 2011 00:31:58 -0700 (PDT) Received: by 10.204.142.24 with HTTP; Fri, 9 Sep 2011 00:31:58 -0700 (PDT) Date: Fri, 9 Sep 2011 09:31:58 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [lisp] LISP is a topic at Cisco courses now:-) 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, 09 Sep 2011 07:30:07 -0000 I'm on a Cisco Nexus course right now, Nexus 5K/1Kv and it was interesting to see that one of the topic here is LISP. Not yet in the book but are an extra appendix (PDF) together with Fabricpath OTV and VXLAN. Nice to see standards reaching production environment :-) --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From internet-drafts@ietf.org Fri Sep 9 11:57:29 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 5638321F87FC; Fri, 9 Sep 2011 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 D4t0cn-Mk994; Fri, 9 Sep 2011 11:57:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E7721F869E; Fri, 9 Sep 2011 11:57:28 -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: <20110909185728.18329.69567.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2011 11:57:28 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lig-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: Fri, 09 Sep 2011 18:57:29 -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 Internet Groper (LIG) Author(s) : Dino Farinacci Dave Meyer Filename : draft-ietf-lisp-lig-06.txt Pages : 19 Date : 2011-09-09 A simple tool called the LISP Internet Groper or 'lig' can be us= ed to query the LISP mapping database. This draft describes how it works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-lig-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-lig-06.txt From dino@cisco.com Fri Sep 9 17:01:10 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 63E3A21F849E for ; Fri, 9 Sep 2011 17:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, 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 BpIMA5n-GkVc for ; Fri, 9 Sep 2011 17:01: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 9ED2221F85F5 for ; Fri, 9 Sep 2011 17:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=168530; q=dns/txt; s=iport; t=1315612978; x=1316822578; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=TCZlmyux5glBSpu+eJfN6YpWaXZhwH/doUZjy5HhivU=; b=VK4bkSkhRaVrzu2Ird8HsnBcjTn3kMoNtADfswsd9KjN2xEgJTIRZVWB nHC8U0HqUGXloITxYjB1skZpM49U9S0pDQF8hWbzTI+HVUo+HNKu0BzW3 ikGxRj8XTNOi5DOabyHCIgCnb7R2gkXqhjOuuigPb1xzAzjwY4fOqNAgg w=; X-Files: rfcdiff-lisp-multicast-07-to-08.html, draft-ietf-lisp-multicast-08.txt : 76005, 75110 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAOenak6rRDoJ/2dsb2JhbAA4AQmhWoY+eIFSAQEBAQIBEgEHAVAHBwULCxImAQ1JDgYRAhkCB4dUBJkxAZ5Ig0cBgkZgBIdti0uFFYwlHA X-IronPort-AV: E=Sophos;i="4.68,358,1312156800"; d="txt'?html'217?scan'217,208,217";a="1267698" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 10 Sep 2011 00:02:56 +0000 Received: from [10.21.70.38] ([10.21.70.38]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8A02tLh023516; Sat, 10 Sep 2011 00:02:55 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/mixed; boundary="Apple-Mail=_C9BE2C2D-EFA5-4200-8F8D-1023EBBF3890" From: Dino Farinacci In-Reply-To: <4E5023E1.4050803@piuha.net> Date: Fri, 9 Sep 2011 17:02:55 -0700 Message-Id: <2D8F559B-433C-428D-A9BF-B0B13DAE6640@cisco.com> References: <4E4EC57C.2090005@piuha.net> <4E5023E1.4050803@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org, draft-ietf-lisp-multicast@tools.ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-multicast (part 2/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: Sat, 10 Sep 2011 00:01:10 -0000 --Apple-Mail=_C9BE2C2D-EFA5-4200-8F8D-1023EBBF3890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > I am reviewing this draft. This is the first part of my review, I've = read up to end of Section 7. I should complete the review tomorrow but = wanted to send out these early comments already today. I have put part 1 and part 2 emails in this draft so I can give you one = reply. See a diff file and a new draft update enclosed.=20 Let me know if it is safe to post. ;-) > So far I've liked what I saw, with the exception of few places where I = think clarifications are needed (see below). Thanks Jari. > Technical: >=20 >> The fundamental multicast forwarding model is to encapsulate a >> multicast packet into another multicast packet. An ITR will >> encapsulate multicast packets received from sources that it serves in >> another LISP multicast header.=20 > ... but elsewhere you say ... >> Ingress Tunnel Router (ITR): a router which accepts an IP multicast >> 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 multicast address opaquely so it doesn't need to >> perform a map lookup on the group address because it is >> topologically insignificant. The router then prepends an "outer" >> IP header with one of its globally-routable RLOCs as the source >> address field. >=20 > I think the first text fragment should have said " An ITR will = encapsulate multicast packets received from sources that it serves in a = LISP multicast header. ", not " An ITR will encapsulate multicast = packets received from sources that it serves in another LISP multicast = header. " Fixed. Makes sense. >> MBGP: Even though MBGP is not a multicast routing protocol, it is >> used to find multicast sources when the unicast BGP peering >> topology and the multicast MBGP peering topology are not >> congruent. When MBGP is used in a LISP-Multicast environment, the >> prefixes which are advertised are from the RLOC namespace. This >> allows receiver multicast sites to find a path to the source >> multicast site's ITRs. MBGP peering addresses will be from the >> RLOC namespace. >> =20 >=20 > You should clearly state whether or not there are protocol changes = (not just configuration or address space differences). You say so later = in the conclusions of this section, but I think you should clearly state = it already here. >=20 > The same applies to the rest of the items in this section. I think it = will be beneficial to the reader to know if there are no impacts, if = some different configuration is needed or different address space is = used (IGMP and MBGP), implementation changes are needed for some address = mapping or other task (PIM-SM), or if the actual protocol needs to = change in order to support LISP-Multicast. I liked the way the = description was written for PIM-SM, maybe you can do the same for = others. MBGP, MSDP, PIM-Bidir, and PIM-ASM entries were unclear to me. I added a sentence to each part indicating when there are no protocol = changes to the specific protocol. > Editorial: >=20 > The terms EID, RLOC, ASM, SSM, Bidir-mode, TE-ITR, TE-ETR, uPITR, = oif-list, RPF should be expanded upon first use (and in some cases you = should point to the relevant reference). Note that some of the terms are = in Section 3 but used in Section 2. Done, I expanded on first use. But didn't want to put the Definition of = Terms before the Intro section where we have to make some claims up = front and need to use these acronyms. I think forward references to = definitions is not the end of the world. > Jari On Aug 20, 2011, at 2:15 PM, Jari Arkko wrote: > Continuing my review. >=20 > The document was a pleasure to read and is in very good shape, despite = some areas which were quite complex (such as the different interworking = cases). Thank you for that. I think it is ready to move forward soon = with a few small changes. I also had one question below and I want to = understand the answer to it. Please answer the question and review the = suggested changes. Send mail if there's anything that seems out of = order. Great, thanks for the review. See responses below.=20 > Technical: >=20 >> This specification focuses on what changes are needed to the >> multicast routing protocols to support LISP-Multicast as well as >> other protocols used for inter-domain multicast, such as Multi- >> protocol BGP (MBGP) [RFC4760 ]. = The approach proposed in this >> specification requires no changes to the multicast infrastructure >> inside of a site when all sources and receivers reside in that site, >> even when the site is LISP enabled. That is, internal operation of >> multicast is unchanged regardless of whether or not the site is LISP >> enabled or whether or not receivers exist in other sites which are >> LISP-enabled. >>=20 >> Therefore, we see changes only to PIM-ASM [RFC4601 = ], MSDP [RFC3618 = ], >> and PIM-SSM [RFC4607 ]. = Bidir-PIM [RFC5015 ], which = typically does not >> run in an inter-domain environment is not addressed in depth in this >> version of the specification. >> =20 >=20 > This text from the Introduction seems to say the protocols change. But = section 7 says >=20 >> Based on the protocol description above, the conclusion is that there >> are no protocol message format changes, just a translation function >> performed at the control-plane. It means there are no packet format changes. There is an element of = procedure type change. I will make that clear in the first reference. >=20 > I think you should soften the statement in the introduction to clarify = that only mapping operations and router implementation changes are = required, the protocols themselves are still as they were. Let me know what you think about the change I made. >> Since the ITR in the source multicast site has never received a >> unicast encapsulated PIM Join/Prune message from any ETR in a >> receiver multicast site, it knows there are no LISP-Multicast >> receiver sites. Therefore, there is no need for the ITR to >> encapsulate data. Since it will know a priori (via configuration) >> that its site's EIDs are not routable (and not registered to the >> mapping database system), it assumes that the multicast packets from >> the source host are sent by a routable address. That is, it is the >> responsibility of the multicast source host's system administrator to >> ensure that the source host sends multicast traffic using a routable >> source address. When this happens, the ITR acts simply as a router >> and forwards the multicast packet like an ordinary multicast router. >> =20 >=20 > I have a question about this. The source network is a LISP site, = right? When you say that it is an admin Right. > responsibility to ensure that the hosts send multicast traffic using a = routable source address, what exactly do you mean? That hosts are = configured with multiple addresses, and that they know which address to = use for which traffic? It means that if the source site knows there will be receivers in = non-LISP sites, those routers will need to build the distribution tree = to the source site. To do that the unicast infrastructure needs to let = the multicast protocol RPF correctly. That means the source host needs = to use an RLOC or an address that has been injected into the core = unicast routing system.=20 That is what a routable source address is. It means that anyone can send = unicast packets to it and PIM routers can send Join/Prune messages = toward it as well. >> Therefore, it is the responsibility of ETRs in multicast receiver >> sites to map the group address into a group address where the >> embedded-RP address is from the RLOC namespace. The mapped RP- >> address is obtained from a EID-to-RLOC mapping database lookup. The >> ETR will also send a unicast (*,G) Join/Prune message to the ITR so >> the branch of the distribution tree from the source site resident RP >> to the ITR is created. >> =20 > I'm not sure I fully understand the implications of this. What has to = be done by the source site to make this happen? Craft a specific = database entry and possibly configure an additional IP address for its = ITR? More One must understand embedded-RP (which is not deployed anywhere). But it = assumes a PIM RP address is derived from a group address. If PIM routers = are going to send (*,G) joins to the RP address, it must be routable. Or = like in your first comment, we can't build RPF distribution trees from = non-LISP receiver sites. > generally, this specification would benefit from a "Manageability = Considerations" section that talks about what expectations there are for = the network administrator to configure different parameters in the xTRs = and elsewhere. Well this isn't an op spec so I'd rather leave it out. And with more = experience, we could add this information to a multicast deployment = guide. > Finally, I think the introduction should provide a high-level overview = of what the "in progress" or otherwise uncertain areas of the = specification are, so that experimentation and future deployment = experience can confirm how well these actually work in practice. You = already do quite a bit of that, but I would still make the following I think everything is in progress. The spec makes recommendation for = practical purposes, to which tradeoffs should be taken (like don't do = mixed IPv6 and IPv4 multicast groups - meaning have receivers for the = same content join to different address-family based groups). > edit: >=20 > OLD: > Also, the current version of this specification does not describe > multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR > descriptions in [LISP]. > NEW: > Also, the current version of this specification does not describe > multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR > descriptions in [LISP]. Futher work is also needed to determine the > detailed behavior for multicast proxy ITRs (mPITRs, Section 9.1.3), = mtrace > (Section 12), and locator reachability (Section 6). Finally, further > deployment and experimentation would be useful to understand the > real-life performance of the LISP-Multicast solution. For instance, > the design optimizes for minimal state and control traffic in the = core, but > can in some cases cause extra multicast traffic to be sent (Section = 8.1.2). Changed. Thanks for the offered text. > These are just a few things that I collected from elsewhere in the = document. Feel free to edit the above text, I'm sure you can provide a = more accurate description. But I think some of these things should at = least be mentioned upfront. >=20 > Editorial: >=20 >> And to have the ITR use its own IP address (its RLOC), and >> as the source address.=20 >=20 > Shouldn't this be: "... use its own IP address (its RLOC) as the = source address."? Yep, fixed. >> 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites >=20 > Extra space Fixed. > Section 9 was hard to read. Maybe because its a complex topic. Well yes, it is complex. Multicast makes everything harder(=99). ;-) >> o A mixed multicast locator-set with the best multicast priority >> values MUST NOT be configured on multicast ITRs. A mixed locator- >> set can exist (for unicast use), but the multicast priorities MUST >> be the set for the same address family locators. >> =20 >=20 > I had trouble parsing this requirement. Do you mean that on a = multicast locator-set, there must always be one address family that is = preferred? I reworded. Let me know what you think. > Expand the term "RP" when first used. It is. First used here: MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will in section 7. >=20 > I think [INTWORK] should be a normative reference, given how it is = used in Section 9. Moved to the Normative section.=20 >> Therefore, this specifications >> focuses on to map a source EID address of a multicast flow during >> distribution tree setup and packet delivery. >> =20 >=20 > ... this specification focuses =85 Changed.=20 Thanks again, Dino --Apple-Mail=_C9BE2C2D-EFA5-4200-8F8D-1023EBBF3890 Content-Disposition: attachment; filename=rfcdiff-lisp-multicast-07-to-08.html Content-Type: text/html; name="rfcdiff-lisp-multicast-07-to-08.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-multicast-07.txt draft-ietf-lisp-multicast-08.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: January 10, March 12, 2012                                        S. Venaas
                                                           cisco Systems
                                                            July
                                                       September 9, 2011

                    LISP for Multicast Environments
                      draft-ietf-lisp-multicast-07
                      draft-ietf-lisp-multicast-08

Abstract

   This draft describes how inter-domain multicast routing will function
   in an environment where Locator/ID Separation is deployed using the
   LISP architecture.

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 10, March 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Source Addresses versus Group Addresses  . . . . . . . . . . . 12
   6.  Locator Reachability Implications on LISP-Multicast  . . . . . 13
   7.  Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
   8.  LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 17
     8.1.  ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 17
       8.1.1.  Multiple RLOCs for an ITR  . . . . . . . . . . . . . . 16 17
       8.1.2.  Multiple ITRs for a LISP Source Site . . . . . . . . . 17 18
     8.2.  ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 18
     8.3.  Replication Locations  . . . . . . . . . . . . . . . . . . 18 19
   9.  LISP-Multicast Interworking  . . . . . . . . . . . . . . . . . 19 20
     9.1.  LISP and non-LISP Mixed Sites  . . . . . . . . . . . . . . 19 20
       9.1.1.  LISP Source Site to non-LISP Receiver Sites  . . . . . 20 21
       9.1.2.  Non-LISP Source Site to non-LISP Receiver Sites  . . . 21 22
       9.1.3.  Non-LISP Source Site to Any Receiver Site  . . . . . . 22 23
       9.1.4.  Unicast LISP Source Site to Any Receiver Sites . . . . 23 24
       9.1.5.  LISP Source Site to Any Receiver Sites . . . . . . . . 23 24
     9.2.  LISP Sites with Mixed Address Families . . . . . . . . . . 24 25
     9.3.  Making a Multicast Interworking Decision . . . . . . . . . 26 27
   10. Considerations when RP Addresses are Embedded in Group
       Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28
   11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28 29
   12. Mtrace Considerations  . . . . . . . . . . . . . . . . . . . . 29 30
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 30 31
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31 32
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32 33
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 34
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 34
     16.2. Informative References . . . . . . . . . . . . . . . . . . 34 35
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 35 36
     A.1.  Changes to draft-ietf-lisp-multicast-07.txt draft-ietf-lisp-multicast-08.txt  . . . . . . . 35 36
     A.2.  Changes to draft-ietf-lisp-multicast-06.txt draft-ietf-lisp-multicast-07.txt  . . . . . . . 35 36
     A.3.  Changes to draft-ietf-lisp-multicast-05.txt draft-ietf-lisp-multicast-06.txt  . . . . . . . 35 36
     A.4.  Changes to draft-ietf-lisp-multicast-04.txt draft-ietf-lisp-multicast-05.txt  . . . . . . . 35 36
     A.5.  Changes to draft-ietf-lisp-multicast-03.txt draft-ietf-lisp-multicast-04.txt  . . . . . . . 35 36
     A.6.  Changes to draft-ietf-lisp-multicast-02.txt draft-ietf-lisp-multicast-03.txt  . . . . . . . 36
     A.7.  Changes to draft-ietf-lisp-multicast-01.txt draft-ietf-lisp-multicast-02.txt  . . . . . . . 36 37
     A.8.  Changes to draft-ietf-lisp-multicast-01.txt  . . . . . . . 37
     A.9.  Changes to draft-ietf-lisp-multicast-00.txt  . . . . . . . 36 37
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 38

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   The Locator/ID Separation Architecture [LISP] provides a mechanism to
   separate out Identification and Location semantics from the current
   definition of an IP address.  By creating two namespaces, an EID Endpoint
   ID (EID) namespace used by sites and a Routing Locator (RLOC)
   namespace used by core routing, the core routing infrastructure can
   scale by doing topological aggregation of routing information.

   Since LISP creates a new namespace, a mapping function must exist to
   map a site's EID prefixes to its associated locators.  For unicast
   packets, both the source address and destination address must be
   mapped.  For multicast packets, only the source address needs to be
   mapped.  The destination group address doesn't need to be mapped
   because the semantics of an IPv4 or IPv6 group address are logical in
   nature and not topology-dependent.  Therefore, this specifications specification
   focuses on to map a source EID address of a multicast flow during
   distribution tree setup and packet delivery.

   This specification will address the following scenarios:

   1.  How a multicast source host in a LISP site sends multicast
       packets to receivers inside of its site as well as to receivers
       in other sites that are LISP enabled.

   2.  How inter-domain (or between LISP sites) multicast distribution
       trees are built and how forwarding of multicast packets leaving a
       source site toward receivers sites is performed.

   3.  What protocols are affected and what changes are required to such
       multicast protocols.

   4.  How ASM-mode, SSM-mode, ASM-mode (Any Source Multicast), SSM-mode (Single Source
       Multicast), and Bidir-mode (Bidirectional Shared Trees) service
       models will operate.

   5.  How multicast packet flow will occur for multiple combinations of
       LISP and non-LISP capable source and receiver sites, for example:

       A.  How multicast packets from a source host in a LISP site are
           sent to receivers in other sites when they are all non-LISP
           sites.

       B.  How multicast packets from a source host in a LISP site are
           sent to receivers in both LISP-enabled sites and non-LISP
           sites.

       C.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in other sites when they are all LISP-
           enabled sites.

       D.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in both LISP-enabled sites and non-LISP
           sites.

   This specification focuses on what changes are needed to the
   multicast routing protocols to support LISP-Multicast as well as
   other protocols used for inter-domain multicast, such as Multi-
   protocol BGP (MBGP) [RFC4760].  The approach proposed in this
   specification requires no packet format changes to the protocol and
   no operational procedural changes to the multicast infrastructure
   inside of a site when all sources and receivers reside in that site,
   even when the site is LISP enabled.  That is, internal operation of
   multicast is unchanged regardless of whether or not the site is LISP
   enabled or whether or not receivers exist in other sites which are
   LISP-enabled.

   Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
   and PIM-SSM [RFC4607].  Bidir-PIM [RFC5015], which typically does not
   run in an inter-domain environment is not addressed in depth in this
   version of the specification.

   Also, the current version of this specification does not describe
   multicast-based Traffic Engineering relative to the TE-ITR (Traffic
   Engineering based Ingress Tunnel Router) and TE-ETR (Traffic
   Engineering based Egress Tunnel Router) descriptions in [LISP].
   Futher work is also needed to determine the detailed behavior for
   multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12),
   and locator reachability (Section 6).  Finally, further deployment
   and experimentation would be useful to understand the real-life
   performance of the LISP-Multicast solution.  For instance, the design
   optimizes for minimal state and control traffic in the core, but can
   in some cases cause extra multicast traffic to be sent Section 8.1.2.

3.  Definition of Terms

   The terminology in this section is consistent with the definitions in
   [LISP] but is extended specifically to deal with the application of
   the terminology to multicast routing.

   LISP-Multicast:   a reference to the design in this specification.
      That is, when any site that is participating in multicast
      communication has been upgraded to be a LISP site, the operation
      of control-plane and data-plane protocols is considered part of
      the LISP-Multicast architecture.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source address field of the first (most inner) LISP
      header of a multicast packet.  The host obtains a destination
      group address the same way it obtains one today, as it would when
      it is a non-LISP site.  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 the host is located in.  An EID can be used by a host to
      refer to another host, as when it joins an SSM (S-EID,G) route
      using IGMP version 3 [RFC4604].  LISP uses Provider Independent
      (PI) blocks for EIDs; such 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.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an ingress
      tunnel router (ITR), the router in the multicast source host's
      site that encapsulates multicast packets.  It 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
      Provider Assigned (PA) addresses.  Multiple RLOCs can be assigned
      to the same ITR device or to multiple ITR devices at a site.

   Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
      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 multicast address opaquely so it doesn't need to
      perform a map lookup on the group address because it is
      topologically insignificant.  The router then prepends an "outer"
      IP header with one of its globally-routable RLOCs as the source
      address field.  This RLOC is known to other multicast receiver
      sites which have used the mapping database to join a multicast
      tree for which the ITR is the root.  In general, an ITR receives
      IP packets from site end systems on one side and sends LISP-
      encapsulated multicast IP packets out all external interfaces
      which have been joined.

      An ITR would receive a multicast packet from a source inside of
      its site when 1) it is on the path from the multicast source to
      internally joined receivers, or 2) when it is on the path from the
      multicast source to externally joined receivers.

   Egress Tunnel Router (ETR):   a router that is on the path from a
      multicast source host in another site to a multicast receiver in
      its own site.  An ETR accepts a PIM Join/Prune message from a site
      internal PIM router destined for the source's EID in the multicast
      source site.  The ETR maps the source EID in the Join/Prune
      message to an RLOC address based on the EID-to-RLOC mapping.  This
      sets up the ETR to accept multicast encapsulated packets from the
      ITR in the source multicast site.  A multicast ETR decapsulates
      multicast encapsulated packets and replicates them on interfaces
      leading to internal receivers.

   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 can be at the
      CE router.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header.  An ITR
      prepends headers and an ETR strips headers.  A LISP encapsulated
      multicast packet will have an "inner" header with the source EID
      in the source field; an "outer" header with the source RLOC in the
      source field: and the same globally unique group address in the
      destination field of both the inner and outer header.

   (S,G) State:   the formal definition is in the PIM Sparse Mode
      [RFC4601] specification.  For this specification, the term is used
      generally to refer to multicast state.  Based on its topological
      location, the (S,G) state resides in routers can be either
      (S-EID,G) state (at a location where the (S,G) state resides) or
      (S-RLOC,G) state (in the Internet core).

   (S-EID,G) State:   refers to multicast state in multicast source and
      receiver sites where S-EID is the IP address of the multicast
      source host (its EID).  An S-EID can appear in an IGMPv3 report,
      an MSDP SA message or a PIM Join/Prune message that travels inside
      of a site.

   (S-RLOC,G) State:   refers to multicast state in the core where S is
      a source locator (the IP address of a multicast ITR) of a site
      with a multicast source.  The (S-RLOC,G) is mapped from (S-EID,G)
      entry by doing a mapping database lookup for the EID prefix that
      S-EID maps to.  An S-RLOC can appear in a PIM Join/Prune message
      when it travels from an ETR to an ITR over the Internet core.

   uLISP Site:   a unicast only LISP site according to [LISP] which has
      not deployed the procedures of this specification and therefore,
      for multicast purposes, follows the procedures from Section 9.

   mPETR:   this is a multicast proxy-ETR that is responsible for
      advertising a very coarse EID prefix which non-LISP and uLISP
      sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs
      are used so LISP source multicast sites can send multicast packets
      using source addresses from the EID namespace. mPETRs act as Proxy
      ETRs for supporting multicast routing in a LISP infrastructure.
      It is likely an uPITR [INTWORK] and a mPETR will be co-located
      since the single device advertises a coarse EID-prefix in the
      underlying unicast routing system.

   Mixed Locator-Sets:   this is a locator-set for a LISP database
      mapping entry where the RLOC addresses in the locator-set are in
      both IPv4 and IPv6 format.

   Unicast Encapsulated PIM Join/Prune Message:   this is a standard PIM
      Join/Prune message (encapsulated in a LISP Encapsulated Control
      Message with destination UDP port 4342) which is sent by ETRs at
      multicast receiver sites to an ITR at a multicast source site.
      This message is sent periodically as long as there are interfaces
      in the oif-list for the (S-EID,G) entry the ETR is joining for.

4.  Basic Overview

   LISP, when used for unicast routing, increases the site's ability to
   control ingress traffic flows.  Egress traffic flows are controlled
   by the IGP in the source site.  For multicast, the IGP coupled with
   PIM can decide which path multicast packets ingress.  By using the
   traffic engineering features of LISP, a multicast source site can
   control the egress of its multicast traffic.  By controlling the
   priorities of locators from a mapping database entry, a source
   multicast site can control which way multicast receiver sites join to
   the source site.

   At this point in time, we don't see a requirement for different
   locator-sets, priority, and weight policies for multicast than we
   have for unicast.  However, when traffic engineering policies are
   different for unicast versus multicast flows, it will be desirable to
   use multicast-based priority and weight values in Map-Reply messages.

   The fundamental multicast forwarding model is to encapsulate a
   multicast packet into another multicast packet.  An ITR will
   encapsulate multicast packets received from sources that it serves in
   another
   a LISP multicast header.  The destination group address from the
   inner header is copied to the destination address of the outer
   header.  The inner source address is the EID of the multicast source
   host and the outer source address is the RLOC of the encapsulating
   ITR.

   The LISP-Multicast architecture will follow this high-level protocol
   and operational sequence:

   1.  Receiver hosts in multicast sites will join multicast content the
       way they do today, they use IGMP.  When they use IGMPv3 where
       they specify source addresses, they use source EIDs, that is they
       join (S-EID,G).  If the multicast source is external to this
       receiver site, the PIM Join/Prune message flows toward the ETRs,
       finding the shortest exit (that is the closest exit for the Join/
       Prune message and the closest entrance for the multicast packet
       to the receiver).

   2.  The ETR does a mapping database lookup for S-EID.  If the mapping
       is cached from a previous lookup (from either a previous Join/
       Prune for the source multicast site or a unicast packet that went
       to the site), it will use the RLOC information from the mapping.
       The ETR will use the same priority and weighting mechanism as for
       unicast.  So the source site can decide which way multicast
       packets egress.

   3.  The ETR will build two PIM Join/Prune messages, one that contains
       a (S-EID,G) entry that is unicast to the ITR that matches the
       RLOC the ETR selects, and the other which contains a (S-RLOC,G)
       entry so the core network can create multicast state from this
       ETR to the ITR.

   4.  When the ITR gets the unicast Join/Prune message (see Section 3
       for formal definition), it will process (S-EID,G) entries in the
       message and propagate them inside of the site where it has
       explicit routing information for EIDs via the IGP.  When the ITR
       receives the (S-RLOC,G) PIM Join/Prune message it will process it
       like any other join it would get in today's Internet.  The S-RLOC
       address is the IP address of this ITR.

   5.  At this point there is (S-EID,G) state from the joining host in
       the receiver multicast site to the ETR of the receiver multicast
       site.  There is (S-RLOC,G) state across the core network from the
       ETR of the multicast receiver site to the ITR in the multicast
       source site and (S-EID,G) state in the source multicast site.
       Note, the (S-EID,G) state is the same S-EID in each multicast
       site.  As other ETRs join the same multicast tree, they can join
       through the same ITR (in which case the packet replication is
       done in the core) or a different ITR (in which case the packet
       replication is done at the source site).

   6.  When a packet is originated by the multicast host in the source
       site, it will flow to one or more ITRs which will prepend a LISP
       header by copying the group address to the outer destination
       address field and insert its own locator address in the outer
       source address field.  The ITR will look at its (S-RLOC,G) state,
       where S-RLOC is its own locator address, and replicate the packet
       on each interface a (S-RLOC,G) joined was received on.  The core
       has (S-RLOC,G) so where fanout occurs to multiple sites, a core
       router will do packet replication.

   7.  When either the source site or the core replicates the packet,
       the ETR will receive a LISP packet with a destination group
       address.  It will decapsulate packets because it has receivers
       for the group.  Otherwise, it would have not received the packets
       because it would not have joined.  The ETR decapsulates and does
       a (S-EID,G) lookup in its multicast FIB to forward packets out
       one or more interfaces to forward the packet to internal
       receivers.

   This architecture is consistent and scalable with the architecture
   presented in [LISP] where multicast state in the core operates on
   locators and multicast state at the sites operates on EIDs.

   Alternatively, [LISP] also has a mechanism where (S-EID,G) state can
   reside in the core through the use of RPF-vectors [RFC5496] in PIM
   Join/Prune messages.  However, few PIM implementations support RPF
   vectors and LISP should avoid S-EID state in the core.  See Section 5
   for details.

   However, we have some observations on the algorithm above.  We can
   scale the control plane but at the expense of sending data to sites
   which may have not joined the distribution tree where the
   encapsulated data is being delivered.  For example, one site joins
   (S-EID1,G) and another site joins (S-EID2,G).  Both EIDs are in the
   same multicast source site.  Both multicast receiver sites join to
   the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
   ITR.  The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
   site.  The ITR receives (S-RLOC,G) joins and populates the oif-list
   state for it.  Since both (S-EID1,G) and (S-EID2, G) map to the one
   (S-RLOC,G) packets will be delivered by the core to both multicast
   receiver sites even though each have joined a single source-based
   distribution tree.  This behavior is a consequence of the many-to-one
   mapping between S-EIDs and a S-RLOC.

   There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined.

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

   As for source addresses, as in the unicast LISP scenario, there is a
   decoupling of identification from location.  In a LISP site, packets
   are originated from hosts using their allocated EIDs, those addresses
   are used to identify the host as well as where in the site's topology
   the host resides but not how and where it is attached to the
   Internet.

   Therefore, when multicast distribution tree state is created anywhere
   in the network on the path from any multicast receiver to a multicast
   source, EID state is maintained at the source and receiver multicast
   sites, and RLOC state is maintained in the core.  That is, a
   multicast distribution tree will be represented as a 3-tuple of
   {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
   3-tuple is the state stored in routers from the source to one or more
   ITRs in the source multicast site, the second element of the 3-tuple
   is the state stored in routers downstream of the ITR, in the core, to
   all LISP receiver multicast sites, and the third element in the
   3-tuple is the state stored in the routers downstream of each ETR, in
   each receiver multicast site, reaching each receiver.  Note that
   (S-EID,G) is the same in both the source and receiver multicast
   sites.

   The concatenation/mapping from the first element to the second
   element of the 3-tuples is done by the ITR and from the second
   element to the third element is done at the ETRs.

6.  Locator Reachability Implications on LISP-Multicast

   Multicast state as it is stored in the core is always (S,G) state as
   it exists today or (S-RLOC,G) state as it will exist when LISP sites
   are deployed.  The core routers cannot distinguish one from the
   other.  They don't need to because it is state that RPFs against the
   core routing tables in the RLOC namespace.  The difference is where
   the root of the distribution tree for a particular source is.  In the
   traditional multicast core, the source S is the source host's IP
   address.  For LISP-Multicast the source S is a single ITR of the
   multicast source site.

   An ITR is selected based on the LISP EID-to-RLOC mapping used when an
   ETR propagates a PIM Join/Prune message out of a receiver multicast
   site.  The selection is based on the same algorithm an ITR would use
   to select an ETR when sending a unicast packet to the site.  In the
   unicast case, the ITR can change on a per-packet basis depending on
   the reachability of the ETR.  So an ITR can change relatively easily
   using local reachability state.  However, in the multicast case, when
   an ITR goes unreachable, new distribution tree state must be built
   because the encapsulating root has changed.  This is more significant
   than an RPF-change event, where any router would typically locally
   change its RPF-interface for its existing tree state.  But when an
   encapsulating LISP-Multicast ITR goes unreachable, new distribution
   state must be rebuilt and reflect the new encapsulator.  Therefore,
   when an ITR goes unreachable, all ETRs that are currently joined to
   that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
   to the new ITR as well as send a unicast encapsulated Join/Prune
   message telling the new ITR which (S-EID,G) is being joined.

   This issue can be mitigated by using anycast addressing for the ITRs
   so the problem does reduce to an RPF change in the core, but still
   requires a unicast encapsulated Join/Prune message to tell the new
   ITR about (S-EID,G).  The problem with this approach is that the ETR
   really doesn't know when the ITR has changed so the new anycast ITR
   will get the (S-EID,G) state only when the ETR sends it the next time
   during its periodic sending procedures.

7.  Multicast Protocol Changes

   A number of protocols are used today for inter-domain multicast
   routing:

   IGMPv1-v3, MLDv1-v2:   These protocols do not require any changes for
      LISP-Multicast for two reasons.  One being that they are link-
      local and not used over site boundaries and second they advertise
      group addresses that don't need translation.  Where source
      addresses are supplied in IGMPv3 and MLDv2 messages, they are
      semantically regarded as EIDs and don't need to be converted to
      RLOCs until the multicast tree-building protocol, such as PIM, is
      received by the ETR at the site boundary.  Addresses used for IGMP
      and MLD come out of the source site's allocated addresses which
      are therefore from the EID namespace.

   MBGP:   Even though MBGP is not a multicast routing protocol, it is
      used to find multicast sources when the unicast BGP peering
      topology and the multicast MBGP peering topology are not
      congruent.  When MBGP is used in a LISP-Multicast environment, the
      prefixes which are advertised are from the RLOC namespace.  This
      allows receiver multicast sites to find a path to the source
      multicast site's ITRs.  MBGP peering addresses will be from the
      RLOC namespace.  There are no MBGP protocol changes required to
      support LISP-Multicast.

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will
      semantically be from the EID namespace since they describe the
      identity of a source multicast host.  It will be true that the
      state stored in MSDP caches from core routers will be from the EID
      namespace.  An RP address inside of site will be from the EID
      namespace so it can be advertised and reached by internal unicast
      routing mechanism.  However, for MSDP peer-RPF checking to work
      properly across sites, the RP addresses must be converted or
      mapped into a routable address that is advertised and maintained
      in the BGP routing tables in the core.  MSDP peering addresses can
      come out of either the EID or a routable address namespace.  And
      the choice can be made unilaterally because the ITR at the site
      will determine which namespace the destination peer address is out
      of by looking in the mapping database service.  There are no MSDP
      protocol changes required to support LISP-Multicast.

   PIM-SSM:   In the simplest form of distribution tree building, when
      PIM operates in SSM mode, a source distribution tree is built and
      maintained across site boundaries.  In this case, there is a small
      modification to the operation of the PIM protocol (but not to any
      message format) to support taking a Join/Prune message originated
      inside of a LISP site with embedded addresses from the EID
      namespace and converting them to addresses from the RLOC namespace
      when the Join/Prune message crosses a site boundary.  This is
      similar to the requirements documented in [RFC5135].

   PIM-Bidir:   Bidirectional PIM is typically run inside of a routing
      domain, but if deployed in an inter-domain environment, one would
      have to decide if the RP address of the shared-tree would be from
      the EID namespace or the RLOC namespace.  If the RP resides in a
      site-based router, then the RP address is from the EID namespace.
      If the RP resides in the core where RLOC addresses are routed,
      then the RP address is from the RLOC namespace.  This could be
      easily distinguishable if the EID address were well-known address
      allocation block from the RLOC namespace.  Also, when using
      Embedded-RP for RP determination [RFC3956], the format of the
      group address could indicate the namespace the RP address is from.
      However, refer to Section 10 for considerations core routers need
      to make when using Embedded-RP IPv6 group addresses.  When using
      Bidir-PIM for inter-domain multicast routing, it is recommended to
      use staticly configured RPs so core routers think the Bidir group
      is associated with an ITR's RLOC as the RP address and site
      routers think the Bidir group is associated with the site resident
      RP with an EID address.  With respect to DF-election in Bidir PIM,
      no changes are required since all messaging and addressing is
      link-local.

   PIM-ASM:   The ASM mode of PIM, the most popular form of PIM, is
      deployed in the Internet today is by having shared-trees within a
      site and using source-trees across sites.  By the use of MSDP and
      PIM-SSM techniques described above, we can get multicast
      connectivity across LISP sites.  Having said that, that means
      there are no special actions required for processing (*,G) or
      (S,G,R) Join/Prune messages since they all operate against the
      shared-tree which is site resident.  Just like with ASM, there is
      no (*,G) in the core when LISP-Multicast is in use.  This is also
      true for the RP-mapping mechanisms Auto-RP and BSR.

   Based on the protocol description above, the conclusion is that there
   are no protocol message format changes, just a translation function
   performed at the control-plane.  This will make for an easier and
   faster transition for LISP since fewer components in the network have
   to change.

   It should also be stated just like it is in [LISP] that no host
   changes, whatsoever, are required to have a multicast source host
   send multicast packets and for a multicast receiver host to receive
   multicast packets.

8.  LISP-Multicast Data-Plane Architecture

   The LISP-Multicast data-plane operation conforms to the operation and
   packet formats specified in [LISP].  However, encapsulating a
   multicast packet from an ITR is a much simpler process.  The process
   is simply to copy the inner group address to the outer destination
   address.  And to have the ITR use its own IP address (its RLOC), and RLOC) as
   the source address.  The process is simpler for multicast because
   there is no EID-to-RLOC mapping lookup performed during packet
   forwarding.

   In the decapsulation case, the ETR simply removes the outer header
   and performs a multicast routing table lookup on the inner header
   (S-EID,G) addresses.  Then the oif-list for the (S-EID,G) entry is
   used to replicate the packet on site-facing interfaces leading to
   multicast receiver hosts.

   There is no Data-Probe logic for ETRs as there can be in the unicast
   forwarding case.

8.1.  ITR Forwarding Procedure

   The following procedure is used by an ITR, when it receives a
   multicast packet from a source inside of its site:

   1.  A multicast data packet sent by a host in a LISP site will have
       the source address equal to the host's EID and the destination
       address equal to the group address of the multicast group.  It is
       assumed the group information is obtained by current methods.
       The same is true for a multicast receiver to obtain the source
       and group address of a multicast flow.

   2.  When the ITR receives a multicast packet, it will have both S-EID
       state and S-RLOC state stored.  Since the packet was received on
       a site-facing interface, the RPF lookup is based on the S-EID
       state.  If the RPF check succeeds, then the oif-list contains
       interfaces that are site-facing and external-facing.  For the
       site-facing interfaces, no LISP header is prepended.  For the
       external-facing interfaces a LISP header is prepended.  When the
       ITR prepends a LISP header, it uses its own RLOC address as the
       source address and copies the group address supplied by the IP
       header the host built as the outer destination address.

8.1.1.  Multiple RLOCs for an ITR

   Typically, an ITR will have a single RLOC address but in some cases
   there could be multiple RLOC addresses assigned from either the same
   or different service providers.  In this case when (S-RLOC,G) Join/
   Prune messages are received for each RLOC, there is a oif-list
   merging action that must take place.  Therefore, when a packet is
   received from a site-facing interface that matches on a (S-EID,G)
   entry, the interfaces of the oif-list from all (RLOC,G) entries
   joined to the ITR as well as the site-facing oif-list joined for
   (S-EID,G) must be part be included in packet replication.  In
   addition to replicating for all types of oif-lists, each oif entry
   must be tagged with the RLOC address, so encapsulation uses the outer
   source address for the RLOC joined.

8.1.2.  Multiple ITRs for a LISP Source Site

   Note when ETRs from different multicast receiver sites receive
   (S-EID,G) joins, they may select a different S-RLOC for a multicast
   source site due to policy (the multicast ITR can return different
   multicast priority and weight values per ETR Map-Request).  In this
   case, the same (S-EID,G) is being realized by different (S-RLOC,G)
   state in the core.  This will not result in duplicate packets because
   each ITR in the multicast source site will choose their own RLOC for
   the source address for encapsulated multicast traffic.  The RLOC
   addresses are the ones joined by remote multicast ETRs.

   When different (S-EID,G) traffic is combined into a single (RLOC,G)
   core distribution tree, this may cause traffic to go to a receiver
   multicast site when it does not need to.  This happens when one
   receiver multicast site joins (S1-EID,Gi) through a core distribution
   tree of (RLOC1,Gi) and another multicast receiver site joins (S2-
   EID,Gi) through the same core distribution tree of (RLOC1,Gi).  When
   ETRs decapsulate such traffic, they should know from their local
   (S-EID,G) state if the packet should be forwarded.  If there is no
   (S-EID,G) state that matches the inner packet header, the packet is
   discarded.

8.2.  ETR Forwarding Procedure

   The following procedure is used by an ETR, when it receives a
   multicast packet from a source outside of its site:

   1.  When a multicast data packet is received by an ETR on an
       external-facing interface, it will do an RPF lookup on the S-RLOC
       state it has stored.  If the RPF check succeeds, the interfaces
       from the oif-list are used for replication to interfaces that are
       site-facing as well as interfaces that are external-facing (this
       ETR can also be a transit multicast router for receivers outside
       of its site).  When the packet is to be replicated for an
       external-facing interface, the LISP encapsulation header are not
       stripped.  When the packet is replicated for a site-facing
       interface, the encapsulation header is stripped.

   2.  The packet without a LISP header is now forwarded down the
       (S-EID,G) distribution tree in the receiver multicast site.

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

   o  In an IGP multicast router inside a site which operates on S-EIDs.

   o  In a transit multicast router inside of the core which operates on
      S-RLOCs.

   o  At one or more ETR routers depending on the path a Join/Prune
      message exits a receiver multicast site.

   o  At one or more ITR routers in a source multicast site depending on
      what priorities are returned in a Map-Reply to receiver multicast
      sites.

   In the last case the source multicast site can do replication rather
   than having a single exit from the site.  But this only can occur
   when the priorities in the Map-Reply are modified for different
   receiver multicast site so that the PIM Join/Prune messages arrive at
   different ITRs.

   This policy technique, also used in [ALT] for unicast, is useful for
   multicast to mitigate the problems of changing distribution tree
   state as discussed in Section 6.

9.  LISP-Multicast Interworking

   This section will describe the multicast corollary to [INTWORK] which
   describes the interworking of multicast routing among LISP and non-
   LISP sites.

9.1.  LISP and non-LISP Mixed Sites

   Since multicast communication can involve more than two entities to
   communicate together, the combinations of interworking scenarios are
   more involved.  However, the state maintained for distribution trees
   at the sites is the same regardless of whether or not the site is
   LISP enabled or not.  So most of the implications are in the core
   with respect to storing routable EID prefixes from either PA or PI
   blocks.

   Before we enumerate the multicast interworking scenarios, we must
   define 3 deployment states of a site:

   o  A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
      does today.  The addresses for the site are globally routable.

   o  A site that deploys LISP for unicast routing.  The addresses for
      the site are not globally routable.  Let's define the name for
      this type of site as a uLISP site.

   o  A site that deploys LISP for both unicast and multicast routing.
      The addresses for the site are not globally routable.  Let's
      define the name for this type of site as a LISP-Multicast site.

   We will not consider a LISP site enabled for multicast purposes only
   but do consider a uLISP site as documented in [INTWORK].  In this
   section we don't discuss how a LISP site sends multicast packets when
   all receiver sites are LISP-Multicast enabled; that has been
   discussed in previous sections.

   The following scenarios exist to make LISP-Multicast sites interwork
   with non-LISP-Multicast sites:

   1.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of non-LISP sites and uLISP sites.

   2.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of non-LISP sites and uLISP sites.

   3.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of LISP sites, uLISP sites, and
       non-LISP sites.

   4.  A uLISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

   5.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

9.1.1.  LISP Source Site to non-LISP Receiver Sites

   In the first scenario, a site is LISP capable for both unicast and
   multicast traffic and as such operates on EIDs.  Therefore there is a
   possibility that the EID prefix block is not routable in the core.
   For LISP receiver multicast sites this isn't a problem but for non-
   LISP or uLISP receiver multicast sites, when a PIM Join/Prune message
   is received by the edge router, it has no route to propagate the
   Join/Prune message out of the site.  This is no different than the
   unicast case that LISP-NAT in [INTWORK] solves.

   LISP-NAT allows a unicast packet that exits a LISP site to get its
   source address mapped to a globally routable address before the ITR
   realizes that it should not encapsulate the packet destined to a non-
   LISP site.  For a multicast packet to leave a LISP site, distribution
   tree state needs to be built so the ITR can know where to send the
   packet.  So the receiver multicast sites need to know about the
   multicast source host by its routable address and not its EID
   address.  When this is the case, the routable address is the
   (S-RLOC,G) state that is stored and maintained in the core routers.
   It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built.

   Using a globally routable source address allows non-LISP and uLISP
   multicast receiver to join, create, and maintain a multicast
   distribution tree.  However, the LISP multicast receiver site will
   want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
   Prune message is received on a site-facing interface.  It does this
   because it wants to find a (S-RLOC,G) entry to Join in the core.  So
   we have a conflict of behavior between the two types of sites.

   The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the
   mapping database because the source multicast site is using a
   routable address and not an EID prefix address.  So the ETR knows to
   simply propagate the PIM Join/Prune message to a external-facing
   interface without converting the (S-EID,G) because it is an (S,G)
   where S is routable and reachable via core routing tables.

   Now that the multicast distribution tree is built and maintained from
   any non-LISP or uLISP receiver multicast site, the way packet
   forwarding model is performed can be explained.

   Since the ITR in the source multicast site has never received a
   unicast encapsulated PIM Join/Prune message from any ETR in a
   receiver multicast site, it knows there are no LISP-Multicast
   receiver sites.  Therefore, there is no need for the ITR to
   encapsulate data.  Since it will know a priori (via configuration)
   that its site's EIDs are not routable (and not registered to the
   mapping database system), it assumes that the multicast packets from
   the source host are sent by a routable address.  That is, it is the
   responsibility of the multicast source host's system administrator to
   ensure that the source host sends multicast traffic using a routable
   source address.  When this happens, the ITR acts simply as a router
   and forwards the multicast packet like an ordinary multicast router.

   There is an alternative to using a LISP-NAT scheme just like there is
   for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
   (PxTRs).  This can work the same way for multicast routing as well,
   but the difference is that non-LISP and uLISP sites will send PIM
   Join/Prune messages for (S-EID,G) which make their way in the core to
   multicast PxTRs.  Let's call this use of a PxTR as a "Multicast
   Proxy-ETR" (or mPETR).  Since the mPETRs advertise very coarse EID
   prefixes, they draw the PIM Join/Prune control traffic making them
   the target of the distribution tree.  To get multicast packets from
   the LISP source multicast sites, the tree needs to be built on the
   path from the mPETR to the LISP source multicast site.  To make this
   happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a
   "Proxy ITR", or an uPITR [INTWORK]).

   The existence of mPETRs in the core allows source multicast site ITRs
   to encapsulate multicast packets according to (S-RLOC,G) state.  The
   (S-RLOC,G) state is built from the mPETRs to the multicast ITRs.  The
   encapsulated multicast packets are decapsulated by mPETRs and then
   forwarded according to (S-EID,G) state.  The (S-EID,G) state is built
   from the non-LISP and uLISP receiver multicast sites to the mPETRs.

9.1.2.  Non-LISP Source Site to non-LISP Receiver Sites

   Clearly non-LISP multicast sites can send multicast packets to non-
   LISP receiver multicast sites.  That is what they do today.  However,
   discussion is required to show how non-LISP multicast sites send
   multicast packets to uLISP receiver multicast sites.

   Since uLISP receiver multicast sites are not targets of any (S,G)
   state, they simply send (S,G) PIM Join/Prune messages toward the non-
   LISP source multicast site.  Since the source multicast site, in this
   case has not been upgraded to LISP, all multicast source host
   addresses are routable.  So this case is simplified to where a uLISP
   receiver multicast site looks to the source multicast site as a non-
   LISP receiver multicast site.

9.1.3.  Non-LISP Source Site to Any Receiver Site

   When a non-LISP source multicast site has receivers in either a non-
   LISP/uLISP site or a LISP site, one needs to decide how the LISP
   receiver multicast site will attach to the distribution tree.  We
   know from Section 9.1.2 that non-LISP and uLISP receiver multicast
   sites can join the distribution tree, but a LISP receiver multicast
   site ETR will need to know if the source address of the multicast
   source host is routable or not.  We showed in Section 9.1.1 that an
   ETR, before it sends a PIM Join/Prune message on an external-facing
   interface, does a EID-to-RLOC mapping lookup to determine if it
   should convert the (S,G) state from a PIM Join/Prune message received
   on a site-facing interface to a (S-RLOC,G).  If the lookup fails, the
   ETR can conclude the source multicast site is a non-LISP site so it
   simply forwards the Join/Prune message (it also doesn't need to send
   a unicast encapsulated Join/Prune message because there is no ITR in
   a non-LISP site and there is namespace continuity between the ETR and
   source).

   For a non-LISP source multicast site, (S-EID,G) state could be
   limited to the edges of the network with the use of multicast proxy-
   ITRs (mPITRs).  The mPITRs can take native, unencapsulated multicast
   packets from non-LISP source multicast and uLISP sites and
   encapsulate them to ETRs in receiver multicast sites or to mPETRs
   that can decapsulate for non-LISP receiver multicast or uLISP sites.
   The mPITRs are responsible for sending (S-EID,G) joins to the non-
   LISP source multicast site.  To connect the distribution trees
   together, multicast ETRs will need to be configured with the mPITR's
   RLOC addresses so they can send both (S-RLOC,G) joins to build a
   distribution tree to the mPITR as well as for sending unicast joins
   to mPITRs so they can propogate (S-EID,G) joins into source multicast
   sites.  The use of mPITRs is undergoing more study and is work in
   progress.

9.1.4.  Unicast LISP Source Site to Any Receiver Sites

   In the last section, it was explained how an ETR in a multicast
   receiver site can determine if a source multicast site is LISP-
   enabled by looking into the mapping database.  When the source
   multicast site is a uLISP site, it is LISP enabled but the ITR, by
   definition is not capable of doing multicast encapsulation.  So for
   the purposes of multicast routing, the uLISP source multicast site is
   treated as non-LISP source multicast site.

   Non-LISP receiver multicast sites can join distribution trees to a
   uLISP source multicast site since the source site behaves, from a
   forwarding perspective, as a non-LISP source site.  This is also the
   case for a uLISP receiver multicast site since the ETR does not have
   multicast functionality built-in or enabled.

   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.

9.1.5.  LISP Source Site to Any Receiver Sites

   When a LISP source multicast site has receivers in LISP, non-LISP,
   and uLISP receiver multicast sites, it has a conflict about how it
   sends multicast packets.  The ITR can either encapsulate or natively
   forward multicast packets.  Since the receiver multicast sites are
   heterogeneous in their behavior, one packet forwarding mechanism
   cannot satisfy both.  However, if a LISP receiver multicast site acts
   like a uLISP site then it could receive packets like a non-LISP
   receiver multicast site making all receiver multicast sites have
   homogeneous behavior.  However, this poses the following issues:

   o  LISP-NAT techniques with routable addresses would be required in
      all cases.

   o  Or alternatively, mPETR deployment would be required forcing
      coarse EID prefix advertisement in the core.

   o  But what is most disturbing is that when all sites that
      participate are LISP-Multicast sites but then a non-LISP or uLISP
      site joins the distribution tree, then the existing joined LISP
      receiver multicast sites would have to change their behavior.
      This would create too much dynamic tree-building churn to be a
      viable alternative.

   So the solution space options are:

   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.

   2.  Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
       reach LISP-Multicast sites and to reach mPETRs that can
       decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
       receiver multicast sites.

9.2.  LISP Sites with Mixed Address Families

   A LISP database mapping entry that describes the locator-set,
   Mpriority and Mweight per locator address (RLOC), for an EID prefix
   associated with a site could have RLOC addresses in either IPv4 or
   IPv6 format.  When a mapping entry has a mix of RLOC formatted
   addresses, it is an implicit advertisement by the site that it is a
   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
   packets.

   To distinguish if the site can receive dual-stack unicast packets as
   well as dual-stack multicast packets, the Mpriority value setting
   will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
   details.

   If you consider the combinations of LISP, non-LISP, and uLISP sites
   sharing the same distribution tree and considering the capabilities
   of supporting IPv4, IPv6, or dual-stack, the number of total
   combinations grows beyond comprehension.

   Using some combinatorial math, we have the following profiles of a
   site and the combinations that can occur:

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site
   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

   Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
   illustrate some combinatorial math below.

   When 1 site talks to another site, the combinatorial is (9 2), when 1
   site talks to another 2 sites, the combinatorial is (9 3).  If sum
   this up to (9 9), we have:

   (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

     36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

   Which results in the total number of cases to be considered at 502.

   This combinatorial gets even worse when you consider a site using one
   address family inside of the site and the xTRs use the other address
   family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
   RLOCs).

   To rationalize this combinatorial nightmare, there are some
   guidelines which need to be put in place:

   o  Each distribution tree shared between sites will either be an IPv4
      distribution tree or an IPv6 distribution tree.  Therefore, we can
      avoid head-end replication by building and sending packets on each
      address family based distribution tree.  Even though there might
      be an urge to do multicast packet translation from one address
      family format to the other, it is a non-viable over-complicated
      urge.  Multicast ITRs will only encapsulate packets where the
      inner and outer headers are from the same address family.

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.  When a receiver
      multicast site ETR receives a (S-EID,G) join, it must select a
      S-RLOC for the same address family as S-EID.

   o  A mixed  When a multicast locator-set with has more than one locator, only
      locators from the best multicast priority
      values same address-family MUST NOT be configured on multicast ITRs. set to the same best
      priority value.  A mixed locator-
      set locator-set can exist (for unicast use),
      but the multicast priorities MUST be the set for the same address
      family locators.

   o  When the source site is not LISP capable, it is up to how
      receivers find the source and group information for a multicast
      flow.  That mechanism decides the address family for the flow.

9.3.  Making a Multicast Interworking Decision

   This Multicast Interworking section has shown all combinations of
   multicast connectivity that could occur.  As you might have already
   concluded, this can be quite complicated and if the design is too
   ambitious, the dynamics of the protocol could cause a lot of
   instability.

   The trade-off decisions are hard to make and we want the same single
   solution to work for both IPv4 and IPv6 multicast.  It is imperative
   to have an incrementally deployable solution for all of IPv4 unicast
   and multicast and IPv6 unicast and multicast while minimizing (or
   eliminating) both unicast and multicast EID namespace state.

   Therefore the design decision to go with uPITRs [INTWORK] for unicast
   routing and mPETRs for multicast routing seems to be the sweet spot
   in the solution space so we can optimize state requirements and avoid
   head-end data replication at ITRs.

10.  Considerations when RP Addresses are Embedded in Group Addresses

   When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
   technique exists to embed the unicast address of an RP in a IPv6
   group address [RFC3956].  When routers in end sites process a PIM
   Join/Prune message which contain an embedded-RP group address, they
   extract the RP address from the group address and treat it from the
   EID namespace.  However, core routers do not have state for the EID
   namespace, need to extract an RP address from the RLOC namespace.

   Therefore, it is the responsibility of ETRs in multicast receiver
   sites to map the group address into a group address where the
   embedded-RP address is from the RLOC namespace.  The mapped RP-
   address is obtained from a EID-to-RLOC mapping database lookup.  The
   ETR will also send a unicast (*,G) Join/Prune message to the ITR so
   the branch of the distribution tree from the source site resident RP
   to the ITR is created.

   This technique is no different than the techniques described in this
   specification for translating (S,G) state and propagating Join/Prune
   messages into the core.  The only difference is that the (*,G) state
   in Join/Prune messages are mapped because they contain unicast
   addresses encoded in an Embedded-RP group address.

11.  Taking Advantage of Upgrades in the Core

   If the core routers are upgraded to support [RFC5496], then we can
   pass EID specific data through the core without, possibly, having to
   store the state in the core.

   By doing this we can eliminate the ETR from unicast encapsulating PIM
   Join/Prune messages to the source site's ITR.

   However, this solution is restricted to a small set of workable cases
   which would not be good for general use of LISP-Multicast.  In
   addition due to slow convergence properties, it is not being
   recommended for LISP-Multicast.

12.  Mtrace Considerations

   Mtrace functionality must be consistent with unicast traceroute
   functionality where all hops from multicast receiver to multicast
   source are visible.

   The design for mtrace for use in LISP-Multicast environments is to be
   determined but should build upon the mtrace version 2 specified in
   [MTRACE].

13.  Security Considerations

   Refer to the [LISP] specification.

14.  Acknowledgments

   The authors would like to gratefully acknowledge the people who have
   contributed discussion, ideas, and commentary to the making of this
   proposal and specification.  People who provided expert review were
   Scott Brim, Greg Shepherd, and Dave Oran.  Other commentary from
   discussions at Summer 2008 Dublin IETF were Toerless Eckert and
   Ijsbrand Wijnands.

   We would also like to thank the MBONED working group for constructive
   and civil verbal feedback when this draft was presented at the Fall
   2008 IETF in Minneapolis.  In particular, good commentary came from
   Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
   Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango. Arango, and Jari Arkko.

   An expert review of this specification was done by Yiqun Cai and
   Liming Wei. We thank them for their detailed comments.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [MLISP] was converted into this IETF LISP
   working group draft.

15.  IANA Considerations

   This document makes no request of the IANA.

16.  References

16.1.  Normative References

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt
              (work in progress).

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

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

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5135]  Wing, D. and T. Eckert, "IP Multicast Requirements for a
              Network Address Translator (NAT) and a Network Address
              Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

16.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
              Topology (LISP-ALT)", draft-ietf-lisp-alt-07.txt (work in
              progress).

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt draft-ietf-lisp-alt-08.txt (work in
              progress).

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-farinacci-lisp-multicast-01.txt (work in progress).

   [MTRACE]   Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
              Version 2: Traceroute Facility for IP Multicast",
              draft-ietf-mboned-mtrace-v2-08.txt (work in progress).

Appendix A.  Document Change Log

A.1.  Changes to draft-ietf-lisp-multicast-08.txt

   o  Posted September 2011.  Minor editorial changes from Jari's
      commentary.

A.2.  Changes to draft-ietf-lisp-multicast-07.txt

   o  Posted July 2011.  Fixing IDnits errors.

A.2.

A.3.  Changes to draft-ietf-lisp-multicast-06.txt

   o  Posted June 2011 to complete working group last call.

   o  Added paragraph to section 8.1.2 based on Jesus comment about
      making it more clear what happens when two (S-EID,G) trees use the
      same (RLOC,G) tree.

   o  Make more references to [INTWORK] when mentioning uPITRs and
      uPETRs.

   o  Made many changes based on editorial and wordsmithing comments
      from Alia.

A.3.

A.4.  Changes to draft-ietf-lisp-multicast-05.txt

   o  Posted April 2011 to reset expiration timer.

   o  Updated references.

A.4.

A.5.  Changes to draft-ietf-lisp-multicast-04.txt

   o  Posted October 2010 to reset expiration timer.

   o  Updated references.

A.5.

A.6.  Changes to draft-ietf-lisp-multicast-03.txt

   o  Posted April 2010.

   o  Added section 8.1.2 to address Joel Halpern's comment about
      receiver sites joining the same source site via 2 different RLOCs,
      each being a separate ITR.

   o  Change all occurences of "mPTR" to "mPETR" to become more
      consistent with uPITRs and uPETRs described in [INTWORK].  That
      is, an mPETR is a LISP multicast router that decapsulates
      multicast packets that are encapsulated to it by ITRs in multicast
      source sites.

   o  Add clarifications in section 9 about how homogeneous multicast
      encapsulation should occur.  As well as describing in this
      section, how to deal with mixed-locator sets to avoid
      heterogeneous encapsulation.

   o  Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
      of LISP global multicast network.

A.6.

A.7.  Changes to draft-ietf-lisp-multicast-02.txt

   o  Posted September 2009.

   o  Added Document Change Log appendix.

   o  Specify that the LISP Encapsulated Control Message be used for
      unicasting PIM Join/Prune messages from ETRs to ITRs.

A.7.

A.8.  Changes to draft-ietf-lisp-multicast-01.txt

   o  Posted November 2008.

   o  Specified that PIM Join/Prune unicast messages that get sent from
      ETRs to ITRs of a source multicast site get LISP encapsulated in
      destination UDP port 4342.

   o  Add multiple RLOCs per ITR per Yiqun's comments.

   o  Indicate how static RPs can be used when LISP is run using Bidir-
      PIM in the core.

   o  Editorial changes per Liming comments.

   o  Add Mttrace Considersations section.

A.8.

A.9.  Changes to draft-ietf-lisp-multicast-00.txt

   o  Posted April 2008.

   o  Renamed from draft-farinacci-lisp-multicast-01.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: stig@cisco.com
--Apple-Mail=_C9BE2C2D-EFA5-4200-8F8D-1023EBBF3890 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_C9BE2C2D-EFA5-4200-8F8D-1023EBBF3890 Content-Disposition: attachment; filename=draft-ietf-lisp-multicast-08.txt Content-Type: text/plain; name="draft-ietf-lisp-multicast-08.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel Expires: March 12, 2012 S. Venaas cisco Systems September 9, 2011 LISP for Multicast Environments draft-ietf-lisp-multicast-08 Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. 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 March 12, 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. Farinacci, et al. Expires March 12, 2012 [Page 1] =0C Internet-Draft LISP for Multicast Environments September 2011 Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25 9.3. Making a Multicast Interworking Decision . . . . . . . . . 27 10. Considerations when RP Addresses are Embedded in Group Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . . 35 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 36 A.1. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 36 A.2. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 36 A.3. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 36 A.4. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 36 A.5. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 36 A.6. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 36 A.7. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 37 A.8. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 37 A.9. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Farinacci, et al. Expires March 12, 2012 [Page 2] =0C Internet-Draft LISP for Multicast Environments September 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 March 12, 2012 [Page 3] =0C Internet-Draft LISP for Multicast Environments September 2011 2. Introduction The Locator/ID Separation Architecture [LISP] provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an Endpoint ID (EID) namespace used by sites and a Routing Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information. Since LISP creates a new namespace, a mapping function must exist to map a site's EID prefixes to its associated locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology-dependent. Therefore, this specification focuses on to map a source EID address of a multicast flow during distribution tree setup and packet delivery. This specification will address the following scenarios: 1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled. 2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed. 3. What protocols are affected and what changes are required to such multicast protocols. 4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source Multicast), and Bidir-mode (Bidirectional Shared Trees) service models will operate. 5. How multicast packet flow will occur for multiple combinations of LISP and non-LISP capable source and receiver sites, for example: A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites. B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. Farinacci, et al. Expires March 12, 2012 [Page 4] =0C Internet-Draft LISP for Multicast Environments September 2011 C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP- enabled sites. D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no packet format changes to the protocol and no operational procedural changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not run in an inter-domain environment is not addressed in depth in this version of the specification. Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR (Traffic Engineering based Ingress Tunnel Router) and TE-ETR (Traffic Engineering based Egress Tunnel Router) descriptions in [LISP]. Futher work is also needed to determine the detailed behavior for multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator reachability (Section 6). Finally, further deployment and experimentation would be useful to understand the real-life performance of the LISP-Multicast solution. For instance, the design optimizes for minimal state and control traffic in the core, but can in some cases cause extra multicast traffic to be sent Section 8.1.2. Farinacci, et al. Expires March 12, 2012 [Page 5] =0C Internet-Draft LISP for Multicast Environments September 2011 3. Definition of Terms The terminology in this section is consistent with the definitions in [LISP] but is extended specifically to deal with the application of the terminology to multicast routing. LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. 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 the host is located in. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider Independent (PI) blocks for EIDs; such 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. Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress tunnel router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It 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 Provider Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site. Ingress Tunnel Router (ITR): a router which accepts an IP multicast 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 multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally-routable RLOCs as the source address field. This RLOC is known to other multicast receiver Farinacci, et al. Expires March 12, 2012 [Page 6] =0C Internet-Draft LISP for Multicast Environments September 2011 sites which have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end systems on one side and sends LISP- encapsulated multicast IP packets out all external interfaces which have been joined. An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers. Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers. 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 can be at the CE router. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR prepends headers and an ETR strips headers. A LISP encapsulated multicast packet will have an "inner" header with the source EID in the source field; an "outer" header with the source RLOC in the source field: and the same globally unique group address in the destination field of both the inner and outer header. (S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core). (S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside Farinacci, et al. Expires March 12, 2012 [Page 7] =0C Internet-Draft LISP for Multicast Environments September 2011 of a site. (S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) entry by doing a mapping database lookup for the EID prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message when it travels from an ETR to an ITR over the Internet core. uLISP Site: a unicast only LISP site according to [LISP] which has not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. It is likely an uPITR [INTWORK] and a mPETR will be co-located since the single device advertises a coarse EID-prefix in the underlying unicast routing system. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the oif-list for the (S-EID,G) entry the ETR is joining for. Farinacci, et al. Expires March 12, 2012 [Page 8] =0C Internet-Draft LISP for Multicast Environments September 2011 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the traffic engineering features of LISP, a multicast source site can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we have for unicast. However, when traffic engineering policies are different for unicast versus multicast flows, it will be desirable to use multicast-based priority and weight values in Map-Reply messages. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in a LISP multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they join (S-EID,G). If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is the closest exit for the Join/ Prune message and the closest entrance for the multicast packet to the receiver). 2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping. The ETR will use the same priority and weighting mechanism as for unicast. So the source site can decide which way multicast packets egress. Farinacci, et al. Expires March 12, 2012 [Page 9] =0C Internet-Draft LISP for Multicast Environments September 2011 3. The ETR will build two PIM Join/Prune messages, one that contains a (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other which contains a (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR. 4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR. 5. At this point there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site). 6. When a packet is originated by the multicast host in the source site, it will flow to one or more ITRs which will prepend a LISP header by copying the group address to the outer destination address field and insert its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface a (S-RLOC,G) joined was received on. The core has (S-RLOC,G) so where fanout occurs to multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will decapsulate packets because it has receivers for the group. Otherwise, it would have not received the packets because it would not have joined. The ETR decapsulates and does a (S-EID,G) lookup in its multicast FIB to forward packets out one or more interfaces to forward the packet to internal receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. Farinacci, et al. Expires March 12, 2012 [Page 10] =0C Internet-Draft LISP for Multicast Environments September 2011 Alternatively, [LISP] also has a mechanism where (S-EID,G) state can reside in the core through the use of RPF-vectors [RFC5496] in PIM Join/Prune messages. However, few PIM implementations support RPF vectors and LISP should avoid S-EID state in the core. See Section 5 for details. However, we have some observations on the algorithm above. We can scale the control plane but at the expense of sending data to sites which may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the oif-list state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G) packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but we can reduce the "n" to a smaller number in the "n-to-1" relationship. And in turn, reduce the opportunity for data packets to be delivered to sites for groups not joined. Farinacci, et al. Expires March 12, 2012 [Page 11] =0C Internet-Draft LISP for Multicast Environments September 2011 5. Source Addresses versus Group Addresses Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast. As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs, those addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet. Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site, the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites, and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites. The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR and from the second element to the third element is done at the ETRs. Farinacci, et al. Expires March 12, 2012 [Page 12] =0C Internet-Draft LISP for Multicast Environments September 2011 6. Locator Reachability Implications on LISP-Multicast Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that RPFs against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast the source S is a single ITR of the multicast source site. An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR goes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be rebuilt and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined. This issue can be mitigated by using anycast addressing for the ITRs so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures. Farinacci, et al. Expires March 12, 2012 [Page 13] =0C Internet-Draft LISP for Multicast Environments September 2011 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for LISP-Multicast for two reasons. One being that they are link- local and not used over site boundaries and second they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and MLDv2 messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses which are therefore from the EID namespace. MBGP: Even though MBGP is not a multicast routing protocol, it is used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes which are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. There are no MBGP protocol changes required to support LISP-Multicast. MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. There are no MSDP protocol changes required to support LISP-Multicast. Farinacci, et al. Expires March 12, 2012 [Page 14] =0C Internet-Draft LISP for Multicast Environments September 2011 PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode, a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to the operation of the PIM protocol (but not to any message format) to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [RFC5135]. PIM-Bidir: Bidirectional PIM is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared-tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using Bidir-PIM for inter-domain multicast routing, it is recommended to use staticly configured RPs so core routers think the Bidir group is associated with an ITR's RLOC as the RP address and site routers think the Bidir group is associated with the site resident RP with an EID address. With respect to DF-election in Bidir PIM, no changes are required since all messaging and addressing is link-local. PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites. By the use of MSDP and PIM-SSM techniques described above, we can get multicast connectivity across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared-tree which is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. Farinacci, et al. Expires March 12, 2012 [Page 15] =0C Internet-Draft LISP for Multicast Environments September 2011 It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets. Farinacci, et al. Expires March 12, 2012 [Page 16] =0C Internet-Draft LISP for Multicast Environments September 2011 8. LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [LISP]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC) as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding. In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts. There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case. 8.1. ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site: 1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the group address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow. 2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the oif-list contains interfaces that are site-facing and external-facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header the host built as the outer destination address. 8.1.1. Multiple RLOCs for an ITR Typically, an ITR will have a single RLOC address but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case when (S-RLOC,G) Join/ Farinacci, et al. Expires March 12, 2012 [Page 17] =0C Internet-Draft LISP for Multicast Environments September 2011 Prune messages are received for each RLOC, there is a oif-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on a (S-EID,G) entry, the interfaces of the oif-list from all (RLOC,G) entries joined to the ITR as well as the site-facing oif-list joined for (S-EID,G) must be part be included in packet replication. In addition to replicating for all types of oif-lists, each oif entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined. 8.1.2. Multiple ITRs for a LISP Source Site Note when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs. When different (S-EID,G) traffic is combined into a single (RLOC,G) core distribution tree, this may cause traffic to go to a receiver multicast site when it does not need to. This happens when one receiver multicast site joins (S1-EID,Gi) through a core distribution tree of (RLOC1,Gi) and another multicast receiver site joins (S2- EID,Gi) through the same core distribution tree of (RLOC1,Gi). When ETRs decapsulate such traffic, they should know from their local (S-EID,G) state if the packet should be forwarded. If there is no (S-EID,G) state that matches the inner packet header, the packet is discarded. 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header are not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped. Farinacci, et al. Expires March 12, 2012 [Page 18] =0C Internet-Draft LISP for Multicast Environments September 2011 2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site. 8.3. Replication Locations Multicast packet replication can happen in the following topological locations: o In an IGP multicast router inside a site which operates on S-EIDs. o In a transit multicast router inside of the core which operates on S-RLOCs. o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site. o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites. In the last case the source multicast site can do replication rather than having a single exit from the site. But this only can occur when the priorities in the Map-Reply are modified for different receiver multicast site so that the PIM Join/Prune messages arrive at different ITRs. This policy technique, also used in [ALT] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6. Farinacci, et al. Expires March 12, 2012 [Page 19] =0C Internet-Draft LISP for Multicast Environments September 2011 9. LISP-Multicast Interworking This section will describe the multicast corollary to [INTWORK] which describes the interworking of multicast routing among LISP and non- LISP sites. 9.1. LISP and non-LISP Mixed Sites Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same regardless of whether or not the site is LISP enabled or not. So most of the implications are in the core with respect to storing routable EID prefixes from either PA or PI blocks. Before we enumerate the multicast interworking scenarios, we must define 3 deployment states of a site: o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable. o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site. o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site. We will not consider a LISP site enabled for multicast purposes only but do consider a uLISP site as documented in [INTWORK]. In this section we don't discuss how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections. The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites: 1. A LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 2. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 3. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. Farinacci, et al. Expires March 12, 2012 [Page 20] =0C Internet-Draft LISP for Multicast Environments September 2011 4. A uLISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 9.1.1. LISP Source Site to non-LISP Receiver Sites In the first scenario, a site is LISP capable for both unicast and multicast traffic and as such operates on EIDs. Therefore there is a possibility that the EID prefix block is not routable in the core. For LISP receiver multicast sites this isn't a problem but for non- LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP-NAT in [INTWORK] solves. LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non- LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site because we want the ITRs to process a received PIM Join/Prune message from an external-facing interface to be propagated inside of the site so the site-part of the distribution tree is built. Using a globally routable source address allows non-LISP and uLISP multicast receiver to join, create, and maintain a multicast distribution tree. However, the LISP multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find a (S-RLOC,G) entry to Join in the core. So we have a conflict of behavior between the two types of sites. The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires March 12, 2012 [Page 21] =0C Internet-Draft LISP for Multicast Environments September 2011 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way packet forwarding model is performed can be explained. Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable (and not registered to the mapping database system), it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) which make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a "Proxy ITR", or an uPITR [INTWORK]). The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Clearly non-LISP multicast sites can send multicast packets to non- LISP receiver multicast sites. That is what they do today. However, Farinacci, et al. Expires March 12, 2012 [Page 22] =0C Internet-Draft LISP for Multicast Environments September 2011 discussion is required to show how non-LISP multicast sites send multicast packets to uLISP receiver multicast sites. Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non- LISP source multicast site. Since the source multicast site, in this case has not been upgraded to LISP, all multicast source host addresses are routable. So this case is simplified to where a uLISP receiver multicast site looks to the source multicast site as a non- LISP receiver multicast site. 9.1.3. Non-LISP Source Site to Any Receiver Site When a non-LISP source multicast site has receivers in either a non- LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. We know from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. We showed in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source). For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy- ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non- LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as for sending unicast joins to mPITRs so they can propogate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is work in progress. Farinacci, et al. Expires March 12, 2012 [Page 23] =0C Internet-Draft LISP for Multicast Environments September 2011 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled. Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. 9.1.5. LISP Source Site to Any Receiver Sites When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site then it could receive packets like a non-LISP receiver multicast site making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases. o Or alternatively, mPETR deployment would be required forcing coarse EID prefix advertisement in the core. o But what is most disturbing is that when all sites that participate are LISP-Multicast sites but then a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a Farinacci, et al. Expires March 12, 2012 [Page 24] =0C Internet-Draft LISP for Multicast Environments September 2011 viable alternative. So the solution space options are: 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites. 9.2. LISP Sites with Mixed Address Families A LISP database mapping entry that describes the locator-set, Mpriority and Mweight per locator address (RLOC), for an EID prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets. To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format details. If you consider the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension. Using some combinatorial math, we have the following profiles of a site and the combinations that can occur: 1. LISP-Multicast IPv4 Site 2. LISP-Multicast IPv6 Site 3. LISP-Multicast Dual-Stack Site 4. uLISP IPv4 Site 5. uLISP IPv6 Site Farinacci, et al. Expires March 12, 2012 [Page 25] =0C Internet-Draft LISP for Multicast Environments September 2011 6. uLISP Dual-Stack Site 7. non-LISP IPv4 Site 8. non-LISP IPv6 Site 9. non-LISP Dual-Stack Site Lets define (m n) =3D m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below. When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If sum this up to (9 9), we have: (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =3D 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 Which results in the total number of cases to be considered at 502. This combinatorial gets even worse when you consider a site using one address family inside of the site and the xTRs use the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: o Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, we can avoid head-end replication by building and sending packets on each address family based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family. o All LISP sites on a multicast distribution tree must share a common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- based policy modification is prohibited. When a receiver multicast site ETR receives a (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID. Farinacci, et al. Expires March 12, 2012 [Page 26] =0C Internet-Draft LISP for Multicast Environments September 2011 o When a multicast locator-set has more than one locator, only locators from the same address-family MUST be set to the same best priority value. A mixed locator-set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. The trade-off decisions are hard to make and we want the same single solution to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. Therefore the design decision to go with uPITRs [INTWORK] for unicast routing and mPETRs for multicast routing seems to be the sweet spot in the solution space so we can optimize state requirements and avoid head-end data replication at ITRs. Farinacci, et al. Expires March 12, 2012 [Page 27] =0C Internet-Draft LISP for Multicast Environments September 2011 10. Considerations when RP Addresses are Embedded in Group Addresses When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in a IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace, need to extract an RP address from the RLOC namespace. Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the embedded-RP address is from the RLOC namespace. The mapped RP- address is obtained from a EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created. This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address. Farinacci, et al. Expires March 12, 2012 [Page 28] =0C Internet-Draft LISP for Multicast Environments September 2011 11. Taking Advantage of Upgrades in the Core If the core routers are upgraded to support [RFC5496], then we can pass EID specific data through the core without, possibly, having to store the state in the core. By doing this we can eliminate the ETR from unicast encapsulating PIM Join/Prune messages to the source site's ITR. However, this solution is restricted to a small set of workable cases which would not be good for general use of LISP-Multicast. In addition due to slow convergence properties, it is not being recommended for LISP-Multicast. Farinacci, et al. Expires March 12, 2012 [Page 29] =0C Internet-Draft LISP for Multicast Environments September 2011 12. Mtrace Considerations Mtrace functionality must be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible. The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon the mtrace version 2 specified in [MTRACE]. Farinacci, et al. Expires March 12, 2012 [Page 30] =0C Internet-Draft LISP for Multicast Environments September 2011 13. Security Considerations Refer to the [LISP] specification. Farinacci, et al. Expires March 12, 2012 [Page 31] =0C Internet-Draft LISP for Multicast Environments September 2011 14. Acknowledgments The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at Summer 2008 Dublin IETF were Toerless Eckert and Ijsbrand Wijnands. We would also like to thank the MBONED working group for constructive and civil verbal feedback when this draft was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko. An expert review of this specification was done by Yiqun Cai and Liming Wei. We thank them for their detailed comments. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [MLISP] was converted into this IETF LISP working group draft. Farinacci, et al. Expires March 12, 2012 [Page 32] =0C Internet-Draft LISP for Multicast Environments September 2011 15. IANA Considerations This document makes no request of the IANA. Farinacci, et al. Expires March 12, 2012 [Page 33] =0C Internet-Draft LISP for Multicast Environments September 2011 16. References 16.1. Normative References [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress). [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15.txt (work in progress). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Farinacci, et al. Expires March 12, 2012 [Page 34] =0C Internet-Draft LISP for Multicast Environments September 2011 16.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-08.txt (work in progress). [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress). [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-08.txt (work in progress). Farinacci, et al. Expires March 12, 2012 [Page 35] =0C Internet-Draft LISP for Multicast Environments September 2011 Appendix A. Document Change Log A.1. Changes to draft-ietf-lisp-multicast-08.txt o Posted September 2011. Minor editorial changes from Jari's commentary. A.2. Changes to draft-ietf-lisp-multicast-07.txt o Posted July 2011. Fixing IDnits errors. A.3. Changes to draft-ietf-lisp-multicast-06.txt o Posted June 2011 to complete working group last call. o Added paragraph to section 8.1.2 based on Jesus comment about making it more clear what happens when two (S-EID,G) trees use the same (RLOC,G) tree. o Make more references to [INTWORK] when mentioning uPITRs and uPETRs. o Made many changes based on editorial and wordsmithing comments from Alia. A.4. Changes to draft-ietf-lisp-multicast-05.txt o Posted April 2011 to reset expiration timer. o Updated references. A.5. Changes to draft-ietf-lisp-multicast-04.txt o Posted October 2010 to reset expiration timer. o Updated references. A.6. Changes to draft-ietf-lisp-multicast-03.txt o Posted April 2010. o Added section 8.1.2 to address Joel Halpern's comment about receiver sites joining the same source site via 2 different RLOCs, each being a separate ITR. o Change all occurences of "mPTR" to "mPETR" to become more consistent with uPITRs and uPETRs described in [INTWORK]. That is, an mPETR is a LISP multicast router that decapsulates Farinacci, et al. Expires March 12, 2012 [Page 36] =0C Internet-Draft LISP for Multicast Environments September 2011 multicast packets that are encapsulated to it by ITRs in multicast source sites. o Add clarifications in section 9 about how homogeneous multicast encapsulation should occur. As well as describing in this section, how to deal with mixed-locator sets to avoid heterogeneous encapsulation. o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges of LISP global multicast network. A.7. Changes to draft-ietf-lisp-multicast-02.txt o Posted September 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. A.8. Changes to draft-ietf-lisp-multicast-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. o Add Mttrace Considersations section. A.9. Changes to draft-ietf-lisp-multicast-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Farinacci, et al. Expires March 12, 2012 [Page 37] =0C Internet-Draft LISP for Multicast Environments September 2011 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA USA Email: dino@cisco.com Dave Meyer cisco Systems Tasman Drive San Jose, CA USA Email: dmm@cisco.com John Zwiebel cisco Systems Tasman Drive San Jose, CA USA Email: jzwiebel@cisco.com Stig Venaas cisco Systems Tasman Drive San Jose, CA USA Email: stig@cisco.com Farinacci, et al. Expires March 12, 2012 [Page 38] =0C --Apple-Mail=_C9BE2C2D-EFA5-4200-8F8D-1023EBBF3890 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_C9BE2C2D-EFA5-4200-8F8D-1023EBBF3890-- From internet-drafts@ietf.org Mon Sep 12 22:54: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 C9A9421F8C14; Mon, 12 Sep 2011 22:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 KzKy-YBKM9lx; Mon, 12 Sep 2011 22:54:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6787421F8B9D; Mon, 12 Sep 2011 22:54:18 -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: <20110913055418.9041.82829.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 22:54:18 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-08.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, 13 Sep 2011 05:54:19 -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-08.txt Pages : 38 Date : 2011-09-12 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-08.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-08.txt From jari.arkko@piuha.net Tue Sep 13 12:49:58 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 D6A1311E80F7 for ; Tue, 13 Sep 2011 12:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 R2mXOW+QYMGT for ; Tue, 13 Sep 2011 12:49:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 980C811E80F3 for ; Tue, 13 Sep 2011 12:49:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F31032CEFF; Tue, 13 Sep 2011 22:52:01 +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 vFRe2KJdDaik; Tue, 13 Sep 2011 22:52:01 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D746B2CE32; Tue, 13 Sep 2011 22:52:00 +0300 (EEST) Message-ID: <4E6FB45B.3080902@piuha.net> Date: Tue, 13 Sep 2011 22:51:55 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Dino Farinacci References: <4E4EC57C.2090005@piuha.net> <4E5023E1.4050803@piuha.net> <2D8F559B-433C-428D-A9BF-B0B13DAE6640@cisco.com> In-Reply-To: <2D8F559B-433C-428D-A9BF-B0B13DAE6640@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org, draft-ietf-lisp-multicast@tools.ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-multicast (part 2/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: Tue, 13 Sep 2011 19:49:58 -0000 Dino, Thanks for the updated draft. I have sent the draft to IETF Last Call. Jari From jari.arkko@piuha.net Tue Sep 13 13:43: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 EAE9F21F8C9F for ; Tue, 13 Sep 2011 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 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 9ZLn1qEExYgU for ; Tue, 13 Sep 2011 13:43:22 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3BB21F8C9E for ; Tue, 13 Sep 2011 13:43:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5E6CE2CEFF; Tue, 13 Sep 2011 23:45:25 +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 eIL06tY202mK; Tue, 13 Sep 2011 23:45:24 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 31E7D2CE32; Tue, 13 Sep 2011 23:45:24 +0300 (EEST) Message-ID: <4E6FC0E3.8030502@piuha.net> Date: Tue, 13 Sep 2011 23:45:23 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Dino Farinacci , Vince Fuller References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> In-Reply-To: <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 13 Sep 2011 20:43:23 -0000 Vince, Dino, I wrote: > I'd still like to understand the ICMP message situation better. I realize > that the traffic is supposed to be unidirectional, but how would, say, > lower MTU somewhere along the path be dealt with? I'm not necessarily > asking for a change in what the spec does, but it should be clear about the > consequences. Vince wrote: > Under normal circumstances, the only thing that should be send across the > ALT would be a Map Request, which should not cause MTU problems. Of course, > if a (deprecated) Data Probe were used, then all bets are off. > > If a Map Request or Data Probe were to hit an MTU problem or otherwise be > undeliverable across the ALT and no ICMP message could be returned from the > ALT node where the failure occurred to the Map Request originator, then > the originator would retry sending the Map Request several times before > timing-out. If such a timeout occurred, then the destination would be > considered not LISP-capable and LISP encapsulation would not be done > toward it. Dino wrote: > Since Map-Requets are small, it is unlikely that an MTU violation will occur for a Map-Request forwarded on the ALT. But if the case did arise, there would be fragmentation and reassembly at each GRE end-point since a Map-Request, when sent from one ALT node to another, is encapsulated in a GRE tunnel header. I'm looking at the Map-Request message format and cannot quite convince myself that there would never be a situation where MTU would be exceeded. 99.999% of the time it would be fine, but I think we need to describe (if not fix) what happens when its not. How about adding the following item to the Section 1 experimental list: "o effects of limited possibilities for returning an ICMP message from ALT" and this text somewhere: "Given that packets delivered through ALT have an RLOC source address and an EID destination address, returning an ICMP error may not always be possible. Since Map-Request messages are typically small, it is unlikely that an MTU violation will occur for a Map-Request forwarded on the ALT and if it did, it may be possible to deal with it through fragmentation of GRE packets. But in the unlikely event of having to generate an ICMP error due to MTU or other problems, an ALT node MAY attempt to deliver the error to the source RLOC outside ALT. If it turns out to be not possible to deliver the ICMP error, the sender of the Map-Request message will retry, and failing again, will time out.This could lead to considering the dstination not LISP-capable. Note that ICMP errors are more likely with Data Probes, and may lead to the unreported loss of the encapsulated data packet." Or something along those lines. Jari From iesg-secretary@ietf.org Tue Sep 13 13:44: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 C63F321F8CB6; Tue, 13 Sep 2011 13:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 kvIRlWre6qZD; Tue, 13 Sep 2011 13:44:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BCF21F8C9C; Tue, 13 Sep 2011 13:44:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110913204442.13725.43869.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 13:44:42 -0700 Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP for Multicast Environments) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 13 Sep 2011 20:44:42 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP for Multicast Environments' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-multicast/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-multicast/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Tue Sep 13 14:49: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 0DFE011E811C; Tue, 13 Sep 2011 14:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 394b+QLZqsPB; Tue, 13 Sep 2011 14:49:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE3211E80BC; Tue, 13 Sep 2011 14:49:06 -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: <20110913214906.31333.43895.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 14:49:06 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-03.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, 13 Sep 2011 21:49:11 -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-03.txt Pages : 21 Date : 2011-09-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-03.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-03.txt From luigi@net.t-labs.tu-berlin.de Tue Sep 13 14:53:14 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 9FCBC11E8121 for ; Tue, 13 Sep 2011 14:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.962 X-Spam-Level: X-Spam-Status: No, score=0.962 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 U4foZ5gm98hT for ; Tue, 13 Sep 2011 14:53:09 -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 E6ADF11E811C for ; Tue, 13 Sep 2011 14:53:07 -0700 (PDT) Received: from [192.168.2.101] (p4FC2537C.dip.t-dialin.net [79.194.83.124]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 003DB701F393; Tue, 13 Sep 2011 23:55:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/mixed; boundary="Apple-Mail=_CD36DDEE-3A52-4B7B-BF8A-698EFF743D10" From: Luigi Iannone In-Reply-To: Date: Tue, 13 Sep 2011 23:55:08 +0200 Message-Id: References: <0F69C5BA-FD74-4D39-B691-D8B0110258C8@net.t-labs.tu-berlin.de> To: lisp@ietf.org X-Mailer: Apple Mail (2.1244.3) Cc: rbarnes@bbn.com, lisp-chairs@tools.ietf.org, draft-ietf-lisp-map-versioning.all@tools.ietf.org Subject: Re: [lisp] [Gen-art] Gen-ART LC review of draft-ietf-lisp-map-versioning-02 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, 13 Sep 2011 21:53:14 -0000 --Apple-Mail=_CD36DDEE-3A52-4B7B-BF8A-698EFF743D10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, We just updated draft-ietf-lisp-map-versioning taking into account both = Jari's and Richard's comments. Attached you can find the new document as well as the diff with the = previous version. ciao Luigi On Sep 7, 2011, at 10:48 , Luigi Iannone wrote: > Hi Richard, >=20 > thanks for your review.=20 >=20 > Our answers can be found inline >=20 >=20 > On Sep 2, 2011, at 18:46 , Joel M. Halpern wrote: >=20 >> (Terry, I believe you saw this, copying the WG for everyone's = information.) >> This Genart review makes an interesting point. I would like to hear = from the authors as to whether they agree. >>=20 >> Yours, >> Joel M. Halpern >>=20 >> -------- Original Message -------- >> Subject: [Gen-art] Gen-ART LC review of = draft-ietf-lisp-map-versioning-02 >> Date: Fri, 2 Sep 2011 11:07:23 -0400 >> From: Richard L. Barnes >> To: General Area Review Team >>=20 >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> . >>=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. >>=20 >> Document: draft-ietf-lisp-map-versioning-02.txt >> Reviewer: Richard Barnes >> Review Date: 02 September 2011 >> IETF LC End Date: 12 September 2011 >> IESG Telechat date: (if known) - >>=20 >> Summary: >> Not ready >>=20 >> Major issues: >>=20 >> General >> Overall the distinction between "older" and "newer" version numbers = does not seem meaningful. Treating the two cases differently doesn't = add any value, and just causes synchronization problems with things like = restarts. The salient distinction is "Is this version number the one I = have in my cache or not?" If so, no action; if not, refresh the = mapping. Cf. >=20 > Thanks for the pointer, but while the nomenclature looks pretty = similar, the context is quite different. AFAIK, in xmpp when a client = contacts a server it asks for the roster, to which a version number can = be associated since it changes not that often. This works perfectly in = the client-server model where for each query a check is done, if = something is different then an update takes place. >=20 > In LISP there are scenarios where communication may be asymmetric = and/or triangular, e.g., two ITRs sending to the same ETR. >=20 > The core idea of map-version is to have a mean for xTRs to understand = if they are using the "latest" mapping.=20 > This must work also for ongoing flows, roughly it can be translated to = a changing version in the middle of a query in xmpp (may be a forced = parallel but it might give the idea). >=20 > To this end it is necessary to introduce the notion of ordering in the = version number. This is necessary in several scenarios we describe in = the document. >=20 > For instance, let's consider two ITRs from the same site that are = sending traffic to the same ETR of a remote site. > If a mapping update happens during heavy traffic exchange due to = obvious path propagation differences even if the ITRs change mapping = exactly at the same time the ETR will receive for a certain period = (which at high bandwidth can mean a lot of packets) a series of = interleaved packets with different version number in its header.=20 > With the simple policy you suggest above the risk is that the ETR will = send out a burst of requests because each time it will think that the = version has changed. This can potentially lead instabilities.=20 >=20 > Hope this simple scenario clarifies the need of ordering. >=20 > The question of sequential version vs. opaque version (nonce) has been = discussed in depth on the mailing list and ended with a WG consensus = during the Anaheim meeting (77th IETF). >=20 >=20 >>=20 >> Section 5.1. bullet 2 >> This bullet needs to be reconsidered. Misbehavior is not the only = situation in which this situation could arise. Consider, for example, = if the ETR for a site reboots and creates a new random initial map = version. >=20 > This could not happen. As we explain in section 8.1, all ETRs needs to = have (and announce to the mapping system) exactly the same mapping. Any = inconsistency can lead to traffic disruption. This is a general property = of LISP is not specific to versioning.=20 > The Map-Version number is just another field in the Map-Record and = like any other field must be consistent on all ETRs. >=20 >> Then everyone that has mappings cached will have the wrong = map-version, and all traffic will get silently dropped. Suggest adding = an error message here that indicates the proper version. >>=20 >> Section 5.1. bullet 3 >> Having an ETR *force* an ITR to update its mapping seems intrusive = and fraught with security risks. >=20 > This is an interesting point. In the LISP model the ETR is the = authoritative network element concerning mappings. This is a basic = principle of the LISP model and the security threats of this model are = analyzed in [LISP-THREATS] while how to secure mapping is covered in = [LISP-SEC]. >=20 >> Suggest adding an error message here that indicates the proper = version, so that the ITR can make its own decision as to whether to = update the cache. >>=20 >> Section 5.1. paragraph after bullet 3 >> Again, I'm concerned about silently dropping packets. ITRs are not = required to renew mappings when TTLs expire, so it's very plausible that = an ITR might have stale mappings. >=20 > They should refresh the mapping if the TTL expires and they want to = use it. Failing to do so has obviously consequences.=20 > The stale mapping can even have disappeared. This is independent from = map-versioning. >=20 >=20 >> If such an ITR just has all its traffic dropped, then it has no = signal to refresh. >=20 > Rightful observation, however, while the ETR MAY drop the traffic it = can as well signal back to the ITR to update the mapping. This is done = through a Map-Request with the SMR bit set. >=20 >> Suggest adding an error message here that indicates the proper = version. >>=20 >> Minor issues: >>=20 >>=20 >=20 > Thanks for pointing out these typos. >=20 >> Editorial: >>=20 >> There are numerous grammatical errors, e.g.: >> "If it is not the case, a Map Request can be send." >> "... map-versioning does not introduce any new problem ..." >> "The ETR's synchronization problem is out of the scope of this = document." >>=20 >> Please expand "w.r.t." >=20 > was meant for "with respect to", will be expanded. >=20 >=20 > Luigi on behalf of the authors >=20 >=20 >=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_CD36DDEE-3A52-4B7B-BF8A-698EFF743D10 Content-Disposition: attachment; filename=draft-ietf-lisp-map-versioning-03.txt Content-Type: text/plain; name="draft-ietf-lisp-map-versioning-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group L. Iannone Internet-Draft TU Berlin - Deutsche Telekom Intended status: Experimental Laboratories AG Expires: March 16, 2012 D. Saucez O. Bonaventure Universite catholique de Louvain September 13, 2011 LISP Map-Versioning draft-ietf-lisp-map-versioning-03.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, 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 March 16, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Iannone, et al. Expires March 16, 2012 [Page 1] =0C Internet-Draft LISP Map-Versioning September 2011 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 . . . . . . . . . . . . 8 6. LISP header and Map-Version numbers . . . . . . . . . . . . . 9 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 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Estimation of time before Map-Version wrap-around . . 18 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Iannone, et al. Expires March 16, 2012 [Page 2] =0C Internet-Draft LISP Map-Versioning September 2011 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 complete them providing new functionalities. 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. 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. Iannone, et al. Expires March 16, 2012 [Page 3] =0C Internet-Draft LISP Map-Versioning September 2011 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. 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 in a per-mapping fashion, meaning that different mappings will have assigned a different version number, which is also updated independently. An update in the version number (i.e., a newer version) consist 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 than the current Map-Version number and the other half is smaller 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 three cases may happen: Iannone, et al. Expires March 16, 2012 [Page 4] =0C Internet-Draft LISP Map-Versioning September 2011 V1 =3D V2 : This is the exact match case. V1 < V2 : True if and only if V1 < V2 < (V1 + 2**(N-1)). V1 > V2 : True if and only if V1 > V2 > (V1 - 2**(N-1)). Using 12 bits, as defined in this document, and assuming a Map- Version value of 69, Map-Version numbers in the range [70; 69 + 2047] are greater than 69, while Map-Version numbers in the range [69 + 2048; (69 + 4095) mod 4096] are smaller than 69. The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be randomly generated. However, it MUST NOT be set to the Null Map- Version value (0x000), because it has a special meaning (see Section 4.1). 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. 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 Iannone, et al. Expires March 16, 2012 [Page 5] =0C Internet-Draft LISP Map-Versioning September 2011 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 an ISP 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 ISP 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 is out of the scope of this document. 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 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 for the source EID is up-to-date. If one or both of the above conditions do not hold, the ETR can send Iannone, et al. Expires March 16, 2012 [Page 6] =0C Internet-Draft LISP Map-Versioning September 2011 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 (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, this means that someone is not behaving correctly with respect to the specifications, thus the packet carries a not valid version number 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 Iannone, et al. Expires March 16, 2012 [Page 7] =0C Internet-Draft LISP Map-Versioning September 2011 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 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 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 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 a mapping that is stale and needs to be updated. A Map-Request SHOULD be sent to get the new Iannone, et al. Expires March 16, 2012 [Page 8] =0C Internet-Draft LISP Map-Versioning September 2011 mapping for the source EID. This is a normal 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 and 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 (which usually contains the nonce) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Iannone, et al. Expires March 16, 2012 [Page 9] =0C Internet-Draft LISP Map-Versioning September 2011 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 [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-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Iannone, et al. Expires March 16, 2012 [Page 10] =0C Internet-Draft LISP Map-Versioning September 2011 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. Iannone, et al. Expires March 16, 2012 [Page 11] =0C Internet-Draft LISP Map-Versioning September 2011 +-----------------+ +-----------------+ | 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. Iannone, et al. Expires March 16, 2012 [Page 12] =0C Internet-Draft LISP Map-Versioning September 2011 +-----------------+ +-----------------+ | 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 Iannone, et al. Expires March 16, 2012 [Page 13] =0C Internet-Draft LISP Map-Versioning September 2011 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]. Iannone, et al. Expires March 16, 2012 [Page 14] =0C Internet-Draft LISP Map-Versioning September 2011 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. 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 Iannone, et al. Expires March 16, 2012 [Page 15] =0C Internet-Draft LISP Map-Versioning September 2011 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. Robusteness 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 Iannone, et al. Expires March 16, 2012 [Page 16] =0C Internet-Draft LISP Map-Versioning September 2011 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. 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 Iannone, et al. Expires March 16, 2012 [Page 17] =0C Internet-Draft LISP Map-Versioning September 2011 TRILOGY Project (www.trilogy-project.org). 13. References 13.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. 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-08 (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 (work in progress), August 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 Iannone, et al. Expires March 16, 2012 [Page 18] =0C Internet-Draft LISP Map-Versioning September 2011 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 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. Iannone, et al. Expires March 16, 2012 [Page 19] =0C Internet-Draft LISP Map-Versioning September 2011 * 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. Iannone, et al. Expires March 16, 2012 [Page 20] =0C Internet-Draft LISP Map-Versioning September 2011 Authors' Addresses Luigi Iannone TU Berlin - Deutsche Telekom 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 Iannone, et al. Expires March 16, 2012 [Page 21] =0C --Apple-Mail=_CD36DDEE-3A52-4B7B-BF8A-698EFF743D10 Content-Disposition: attachment; filename="Wdiff-02->03.html" Content-Type: text/html; name="Wdiff-02->03.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-map-versioning-02.txt draft-ietf-lisp-map-versioning-03.txt 

Network Working Group                                         L. Iannone
Internet-Draft                              TU Berlin - Deutsche Telekom
Intended status: Experimental                            Laboratories AG
Expires: January 6, March 16, 2012                                        D. Saucez
                                                          O. Bonaventure
                                        Universite catholique de Louvain
                                                            July 5,
                                                      September 13, 2011

                          LISP Map-Versioning
                 draft-ietf-lisp-map-versioning-02.txt
                 draft-ietf-lisp-map-versioning-03.txt

Abstract

   This document describes the LISP (Locator/ID Separation Protocol)
   Map-Versioning mechanism, which provides in-packet information about EID-to-RLOC
   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 xTRs 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 xTRs 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 January 6, March 16, 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 . . . . . . . . . . . .  8
   6.  LISP header and Map-Version numbers  . . . . . . . . . . . . .  9
   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  . . . . . . . . . . . . . 12 13
       8.3.1.  Map-Versioning and Proxy-ITRs  . . . . . . . . . . . . 13
       8.3.2.  Map-Versioning and LISP-NAT  . . . . . . . . . . . . . 13 14
       8.3.3.  Map-Versioning and Proxy-ETRs  . . . . . . . . . . . . 13 14
     8.4.  RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 14 15
     8.5.  Map-Version for lightweight LISP implementation  . . . . . 14 15
   9.  Incremental deployment and implementation status . . . . . . . 15 16
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15 16
     10.1. Map-Versioning against traffic disruption  . . . . . . . . 16
     10.2. Map-Versioning against reachability information DoS  . . . 16 17
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 18
     13.2. Informative References . . . . . . . . . . . . . . . . . . 17 18
   Appendix A.  Estimation of time before Map-Version wrap-around . . 18
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 21

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 complete them providing new functionalities.
   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.  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 send. sent.

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.

   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 in a per-mapping fashion,
   meaning that different mappings will have assigned a different
   version number, which is also updated independently.  An update in
   the version number (i.e., a newer version) consist 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 than the current Map-Version number and
   the other half is smaller 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 three cases may
   happen:

   V1 = V2 :  This is the exact match case.

   V1 < V2 :  True if and only if V1 < V2 < (V1 + 2**(N-1)).

   V1 > V2 :  True if and only if V1 > V2 > (V1 - 2**(N-1)).

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

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

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.  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 an ISP
   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
   ISP 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
   any
   new problem 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. mapping, including the same Map-
   Version number.  In principle this is orthogonal to whether or not
   map-versioning is used.  The ETR's synchronization problem is out of the
   scope of this document.

   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 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 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 (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, this means that
       someone is not behaving correctly w.r.t. with respect to the
       specifications, thus the packet carries a not valid version
       number 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 SMR 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 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 from ITRs 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 silently drop packets with a stale Map-Version number. 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 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 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 w.r.t. 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 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 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 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 w.r.t. 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 and 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. 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 (which
   usually contains the nonce) 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 [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-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 decapsulate 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, because all sites have
   updated the mapping, it can be shut down safely.
   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.

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

   Robusteness 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.  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.  References

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

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

13.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-07 draft-ietf-lisp-alt-08
              (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-09
              draft-ietf-lisp-ms-11 (work in progress), June August 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 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 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=_CD36DDEE-3A52-4B7B-BF8A-698EFF743D10-- From jari.arkko@piuha.net Wed Sep 14 01:40: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 AECA621F8C66 for ; Wed, 14 Sep 2011 01:40:19 -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.022, 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 w1eRXhLyXaEE for ; Wed, 14 Sep 2011 01:40:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB1A21F8C61 for ; Wed, 14 Sep 2011 01:40:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 97CC32D543; Wed, 14 Sep 2011 11:42:15 +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 Jh6KX8daGJ-k; Wed, 14 Sep 2011 11:42: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 D3A4E2CE32; Wed, 14 Sep 2011 11:42:14 +0300 (EEST) Message-ID: <4E7068E6.4010509@piuha.net> Date: Wed, 14 Sep 2011 11:42:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: draft-ietf-lisp-ms@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: [lisp] AD review of draft-ietf-list-ms 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, 14 Sep 2011 08:40:19 -0000 I have reviewed this specification. I think it is ready to move forward, and I have sent it to IETF Last Call. I did see a couple of minor editorial issues, however (see below). You may fix those either by issuing a new draft or wait until further issues are brought up in directorate or other reviews. > In addition to the set of EID-prefixes defined for each ETR that may > register, a Map Server is typically also be configured with one or > more aggregate prefixes that define the part of the EID numbering > space assigned to it. s/also be/also/ > An ETR may also request, by setting the "proxy-map-reply" flag > (P-bit) in the Map-Regsiter message Map-Register Jari From subinoy_das_82@yahoo.com Wed Sep 14 03:01:17 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 AA8E021F8BE8 for ; Wed, 14 Sep 2011 03:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 fl1t-mglbvPR for ; Wed, 14 Sep 2011 03:01:17 -0700 (PDT) Received: from nm4-vm1.bullet.mail.in.yahoo.com (nm4-vm1.bullet.mail.in.yahoo.com [121.101.151.209]) by ietfa.amsl.com (Postfix) with SMTP id B2C0321F8BE9 for ; Wed, 14 Sep 2011 03:01:16 -0700 (PDT) Received: from [121.101.151.236] by nm4.bullet.mail.in.yahoo.com with NNFMP; 14 Sep 2011 10:05:53 -0000 Received: from [121.101.151.232] by tm1.bullet.mail.in.yahoo.com with NNFMP; 14 Sep 2011 10:05:08 -0000 Received: from [127.0.0.1] by omp1001.mail.in.yahoo.com with NNFMP; 14 Sep 2011 10:03:21 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 590446.89624.bm@omp1001.mail.in.yahoo.com Received: (qmail 20898 invoked by uid 60001); 14 Sep 2011 10:03:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315994601; bh=34HIbtHTrSWQZqfzvvzCUjL+NgdqIQGX1PjfJe4zuOA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=bsJnMHfAgXhcR0y7uPFW442UCgxTuZ6P9hTEaSPyKsmaoXE4H5ieZrG+2uJgmdCnZ1PMOTWOFlm6NHB7ccB2virx0sfHlQaeYyMwdI7J7uH0WSP7sJyNwuO9c9wyBMuBJlDdo49mOBBEmUES1SONfNyOuchsxS5yGUbV45Dv50k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ddPZz49cTct7azkjbmQ8efEkaLVllXDK92VQt27pN0r6qdH38t19KW636MIbDKJ25AkstLjXlHECRwibxdLsfgd30JCjCxGl7qQXGN2vUaibCDs/IhNyp3CeOqWorwwu+6a6hMWIrv+eoQ03/dPoqM5B8yY738+tQrKIUeeYp/A=; X-YMail-OSG: XGWQz6sVM1lqJGB2pb2PVPanhd_tkIeVv1PZeWyixHlCuzn n3frQTRFQjq2OqXPwXK_GnzTA81CiFHAGtu7J7pgfN1k42HQJf2lkAu5TPg5 ww76.GaJHq90GtypLilr.e5250kSHIjXjXJQAoGcyTRg.6kL.QPBPFxhnPaj Bh5L5lL6gaa6R.nrppI4kBt2B4joqFrsD5KhEs0f3PtdBF_fOihjNFTBiHvk vKEOG7aOlu.T2UzMiAMOQlMZq2ZE4b_YSC5Oe7DrL9abQwaGCHE86yDVYzDx xxXsEux4HExViqS7_YBgOM73.D0H4Lk_LFgyss40ezHONdAkCQegXZAqPuzS 2g1A9oJR6M3tzHkn9Lmm9g3fb8Jhb.OcZ0pnUrtk6inHSt_yYke.3g5Vv1kb VuuWhBBDlyzkR4XveI870ew-- Received: from [121.242.14.67] by web95614.mail.in.yahoo.com via HTTP; Wed, 14 Sep 2011 15:33:21 IST X-Mailer: YahooMailWebService/0.8.113.315625 Message-ID: <1315994601.19234.YahooMailNeo@web95614.mail.in.yahoo.com> Date: Wed, 14 Sep 2011 15:33:21 +0530 (IST) From: Subinoy Das To: "lisp@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1385347869-1315994601=:19234" Subject: [lisp] Query regarding draft-ietf-lisp-ms-10 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Subinoy Das 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, 14 Sep 2011 10:01:17 -0000 --0-1385347869-1315994601=:19234 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AHi,=0A=0AI am little bit confused about functionality of Map Resolver= .=0A=0AIn section 2. Definition of Terms it says "the Map Resolver finds th= e=0Aappropriate EID-to-RLOC mapping by consulting the distributed=0Amapping= database system".=0A=0AIn section 4.4. Map Resolver Processing it says "A = non-caching Map Resolver simply forwards the unencapsulated=0AMap-Request".= Cashing Map Resolver also forwards Map-Request after changing RLOC and nou= nce.=0A=0ASo, what actually a Map Resolver does? It finds EID-to-RLOC mappi= ng in database of just forward the request?=0A=0AAlso, in draft it says abo= ut distributed mapping database. Does that mean all Map Servers will update= to a single distributed database system so that any Map Server can reply t= o Map Request?=0A=0AAlso, from the drafts it is not clear that if any singl= e ETR can send Map Resister to multiple Map Server or not. And what happens= if any Map Servers goes down? Is there any backup Map Server?=0A=0ARegards= ,=0ASubinoy=0A --0-1385347869-1315994601=:19234 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

I am little bit confused about functionality of Map Re= solver.

In section 2. Definition of Terms it says = "the Map Resolver finds the
appropriate EID-to-RLOC mapping by consultin= g the distributed
mapping database system".

In = section 4.4. Map Resolver Processing it says "A non-cac= hing Map Resolver simply forwards the unencapsulated
Map-Request". Cashi= ng Map Resolver also forwards Map-Request after changing RLOC and nounce.

So, what actually a Map Resolver does? It fi= nds EID-to-RLOC mapping in database of just forward the request?
=
Also, in draft it says about distributed mapping database. D= oes that mean all Map Servers will update to a single distributed database system so that any Map Server can reply to Map Request?

Also, from the drafts it is not clear that if any single ET= R can send Map Resister to multiple Map Server or not. And what happens if = any Map Servers goes down? Is there any backup Map Server?

Regards,
Subinoy
--0-1385347869-1315994601=:19234-- From iesg-secretary@ietf.org Wed Sep 14 07:29:34 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 F008221F8CC6; Wed, 14 Sep 2011 07:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 qtIRDSR4RyXt; Wed, 14 Sep 2011 07:29:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D93A21F8C10; Wed, 14 Sep 2011 07:29:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 07:29:29 -0700 Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP Map Server) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 14 Sep 2011 14:29:34 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Map Server' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-ms/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-ms/ No IPR declarations have been submitted directly on this I-D. From Fred.L.Templin@boeing.com Wed Sep 14 10:13:43 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 B505221F8CA3 for ; Wed, 14 Sep 2011 10:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 6MCw5QAPWlgQ for ; Wed, 14 Sep 2011 10:13:43 -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 1965321F8BBB for ; Wed, 14 Sep 2011 10:13:43 -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 p8EHFiJi025141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Sep 2011 12:15:50 -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 p8EHFiEZ016620 for ; Wed, 14 Sep 2011 10:15:44 -0700 (PDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8EHFhRW016607 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 14 Sep 2011 10:15:44 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 14 Sep 2011 10:15:43 -0700 From: "Templin, Fred L" To: "lisp@ietf.org" Date: Wed, 14 Sep 2011 10:15:42 -0700 Thread-Topic: Source address spoofing by a node pretending to be an ITR? Thread-Index: Acxy6wqy0eLdJK/2SNirqJWhPx1HjgAEjoAA Message-ID: References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> In-Reply-To: <20110914142929.11906.18076.idtracker@ietfa.amsl.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 Subject: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 14 Sep 2011 17:13:43 -0000 I have a question about source address spoofing by a node in the Internet pretending to be an ITR. The document says that the ETR: "MAY compare the inner header source EID address and the outer header source RLOC address with the mapping that exists in the mapping database". But a few questions arise from that. First, what if the ETR does not observe the MAY, and simply lets anonymous nodes pretend to be ITRs that send inner packets with spoofed EID source addresses? Those packets could result in a target node in the ETR's site sending replies to a victim node in the Internet. Is it OK to just let that happen? Second, what if the ETR does observe the MAY, but the ITR's RLOC source addresses change dynamically; perhaps due to mobility. Would the ETR be able to keep up with all of the RLOC address changes in real time? Third, I'm also wondering whether it is just end nodes that could pretend to be ITRs, or whether there is also a concern for middleboxes that can examine LISP exchanges and then pretend to be ITRs based on what they observe? I'm not trying to poke holes in the proposal; I'm just trying to understand if the LISP ITR/ETR relationship increases the attack surface for source address spoofing beyond the current state of affairs for the non-LISP Internet. Thanks in advance for any insights. =20 Fred fred.l.templin@boeing.com= From damien.saucez@uclouvain.be Wed Sep 14 11:05:09 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 A45ED21F8B8D for ; Wed, 14 Sep 2011 11:05:09 -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 q2rARt0zKNvF for ; Wed, 14 Sep 2011 11:05:09 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id F401821F8B7D for ; Wed, 14 Sep 2011 11:05:08 -0700 (PDT) Received: from [172.16.165.220] (rrcs-70-62-49-50.central.biz.rr.com [70.62.49.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 81E6611E160; Wed, 14 Sep 2011 20:07:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Damien Saucez In-Reply-To: Date: Wed, 14 Sep 2011 11:07:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=70.62.49.50; helo=[172.16.165.220] Received-SPF: Pass (sender authenticated); receiver=; client-ip=70.62.49.50; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 81E6611E160.AF90D X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 14 Sep 2011 18:05:09 -0000 Fred, You are totally right, obviously if you increase the number of source addressees in a packet you increase the spoofing risk. In the threats draft, two different spoofing techniques are presented (EID Spoofing and RLOC Spoofing). We then show the different attacks that can be conducted with such spoofing. One "funny" attack is by spoofing at the same time the EID and the RLOC. Without cryptography, there is no perfect solution to avoid spoofing. Your example with dynamic RLOC is interesting. If everything goes well, you should never have a TTL longer than the RLOC lease time. However, in the case the RLOC changes before the expiration, you will need SMR or version change implying the retrieval of the new mapping. But in this particular case, you also have a security threat that is a DoS=85 Regards, Damien Saucez On 14 Sep 2011, at 10:15, Templin, Fred L wrote: > I have a question about source address spoofing by a > node in the Internet pretending to be an ITR. The > document says that the ETR: "MAY compare the inner > header source EID address and the outer header source > RLOC address with the mapping that exists in the > mapping database". But a few questions arise from that. >=20 > First, what if the ETR does not observe the MAY, and > simply lets anonymous nodes pretend to be ITRs that > send inner packets with spoofed EID source addresses? > Those packets could result in a target node in the > ETR's site sending replies to a victim node in the > Internet. Is it OK to just let that happen? >=20 > Second, what if the ETR does observe the MAY, but > the ITR's RLOC source addresses change dynamically; > perhaps due to > ity. Would the ETR be able to > keep up with all of the RLOC address changes in real > time? >=20 > Third, I'm also wondering whether it is just end nodes > that could pretend to be ITRs, or whether there is also > a concern for middleboxes that can examine LISP exchanges > and then pretend to be ITRs based on what they observe? >=20 > I'm not trying to poke holes in the proposal; I'm just > trying to understand if the LISP ITR/ETR relationship > increases the attack surface for source address spoofing > beyond the current state of affairs for the non-LISP > Internet. Thanks in advance for any insights. >=20 > Fred > fred.l.templin@boeing.com > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From vaf@cisco.com Wed Sep 14 14:10: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 D333621F8D37 for ; Wed, 14 Sep 2011 14:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.509 X-Spam-Level: X-Spam-Status: No, score=-8.509 tagged_above=-999 required=5 tests=[AWL=2.090, 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 02sUueEiwdlV for ; Wed, 14 Sep 2011 14:10:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D9ACB21F8D3E for ; Wed, 14 Sep 2011 14:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=931; q=dns/txt; s=iport; t=1316034747; x=1317244347; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1+1t5XAXJrdc2DINpX38d3MzkSTnUymTtqH3zyWDziE=; b=NSRavZ0zs/uW9iFWSVNijUJ9amhG/yfPiJDb4fuJRLreiUvb9TwfWsAO bbL5UaJH3eLgdz8kr9CRrfaUMHdGQAkFQLGg6JcUS2CbUpC/E+fM920NQ q/kbI+AwjeOLeqRsRy80t7YvTJ+Ypw366ThiSC5higIEsVWA2jqSw1Rq1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI8XcU5Io8UQ/2dsb2JhbABCp0h4gVMBAQQBEgEnPwULC0YUGDE1h1WVSwGeUoYOYASHbp0W X-IronPort-AV: E=Sophos;i="4.68,382,1312156800"; d="scan'208";a="115464357" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2011 21:12:03 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8ELC2UO022788; Wed, 14 Sep 2011 21:12:02 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 367B5169DFF2; Wed, 14 Sep 2011 14:12:00 -0700 (PDT) Date: Wed, 14 Sep 2011 14:12:00 -0700 From: Vince Fuller To: Jari Arkko Message-ID: <20110914211200.GA86318@vaf-mac1.cisco.com> References: <4E7068E6.4010509@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7068E6.4010509@piuha.net> User-Agent: Mutt/1.4.2.3i Cc: draft-ietf-lisp-ms@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-list-ms 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, 14 Sep 2011 21:10:19 -0000 > I have reviewed this specification. I think it is ready to move forward, > and I have sent it to IETF Last Call. I did see a couple of minor editorial > issues, however (see below). You may fix those either by issuing a new > draft or wait until further issues are brought up in directorate or other > reviews. > > > In addition to the set of EID-prefixes defined for each ETR that may > > register, a Map Server is typically also be configured with one or > > more aggregate prefixes that define the part of the EID numbering > > space assigned to it. > > s/also be/also/ > > > An ETR may also request, by setting the "proxy-map-reply" flag > > (P-bit) in the Map-Regsiter message > > Map-Register Thanks. Will fix in the current draft but won't submit a new version until other, more substantive changes, are requested or the review completes, whichever comes first. --Vince From Fred.L.Templin@boeing.com Wed Sep 14 14:16: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 2AD5A21F8C58 for ; Wed, 14 Sep 2011 14:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 WgcEzhA4782F for ; Wed, 14 Sep 2011 14:16:36 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1B521F8C57 for ; Wed, 14 Sep 2011 14:16:36 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8ELIdMG017113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Sep 2011 14:18:40 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p8ELIc4Y017528; Wed, 14 Sep 2011 14:18:38 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8ELIcWE017514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 14 Sep 2011 14:18:38 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 14 Sep 2011 14:18:38 -0700 From: "Templin, Fred L" To: Damien Saucez Date: Wed, 14 Sep 2011 14:18:37 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: AcxzCSenij+xfi+sSMyYEh1RWbvmrAAGGxiA Message-ID: References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> In-Reply-To: <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> 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: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 14 Sep 2011 21:16:37 -0000 Hi Damien,=20 > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@uclouvain.be]=20 > Sent: Wednesday, September 14, 2011 11:07 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] Source address spoofing by a node=20 > pretending to be an ITR? >=20 > Fred, >=20 > You are totally right, obviously if you increase the number of > source addressees in a packet you increase the spoofing risk. >=20 > In the threats draft, two different spoofing techniques are presented > (EID Spoofing and RLOC Spoofing). We then show the different > attacks that can be conducted with such spoofing. Thanks for pointing out the threats document. In Section 4, it says: "We do not consider that LISP has to cope with [on-path] attackers.". Can you say more about that - for example, are you saying that on-path attacks will never happen, or that they can happen but are harmless and therfore not a matter for concern? I personally would prefer to not have to worry about on-path attacks, but I'm not sure that they can simply be ignored and pretend that they won't happen. But, perhaps a case can be made that on-path attacks are no more a matter for concern for LISP than they are for the non-LISP public Internet? In any case, I'd be interested to know the rationale behind the Section 4 text. > One "funny" attack is by spoofing at the same time the EID and > the RLOC. >=20 > Without cryptography, there is no perfect solution to avoid > spoofing. Your example with dynamic RLOC is interesting. > If everything goes well, you should never have a TTL > longer than the RLOC lease time. However, in the case > the RLOC changes before the expiration, you will need > SMR or version change implying the retrieval of the new > mapping. But in this particular case, you also have a > security threat that is a DoS... Do you see a clear way past these and other threats? Will it be the case that LISP and its ilk will be hard to secure and thus difficult to deploy? Thanks - Fred > Regards, >=20 > Damien Saucez >=20 > On 14 Sep 2011, at 10:15, Templin, Fred L wrote: >=20 > > I have a question about source address spoofing by a > > node in the Internet pretending to be an ITR. The > > document says that the ETR: "MAY compare the inner > > header source EID address and the outer header source > > RLOC address with the mapping that exists in the > > mapping database". But a few questions arise from that. > >=20 > > First, what if the ETR does not observe the MAY, and > > simply lets anonymous nodes pretend to be ITRs that > > send inner packets with spoofed EID source addresses? > > Those packets could result in a target node in the > > ETR's site sending replies to a victim node in the > > Internet. Is it OK to just let that happen? > >=20 > > Second, what if the ETR does observe the MAY, but > > the ITR's RLOC source addresses change dynamically; > > perhaps due to >=20 > > ity. Would the ETR be able to > > keep up with all of the RLOC address changes in real > > time? > >=20 > > Third, I'm also wondering whether it is just end nodes > > that could pretend to be ITRs, or whether there is also > > a concern for middleboxes that can examine LISP exchanges > > and then pretend to be ITRs based on what they observe? > >=20 > > I'm not trying to poke holes in the proposal; I'm just > > trying to understand if the LISP ITR/ETR relationship > > increases the attack surface for source address spoofing > > beyond the current state of affairs for the non-LISP > > Internet. Thanks in advance for any insights. > >=20 > > Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > = From vaf@cisco.com Wed Sep 14 22:16:38 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 CA9F621F8558 for ; Wed, 14 Sep 2011 22:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-2.100, 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 Pz5JuPhKwrVB for ; Wed, 14 Sep 2011 22:16:38 -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 09F6721F854E for ; Wed, 14 Sep 2011 22:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=3406; q=dns/txt; s=iport; t=1316063929; x=1317273529; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=oFUJIevoaciIGRSBkEmUbcudMGV5iQGgun2Oin5k1h8=; b=XZGqHeG8vz/gif1tqQ90tyLMMdu9rvX2bSlXgRxva1TD3/Qyy4GiKIH+ gQbknUSFbG9tas/rcJ3YVd06x19DZdyOukwYUwa6TcCFAfJgSJeyJWUc1 MslaSS9vp2oJPgxtjsHCwZykBlN5yP1A+RoYouICcvQZIEeTHvWLuV8QA U=; X-IronPort-AV: E=Sophos;i="4.68,385,1312156800"; d="scan'208";a="2238311" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 15 Sep 2011 05:18:49 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8F5ImW0012550; Thu, 15 Sep 2011 05:18:48 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 10D4516A27E1; Wed, 14 Sep 2011 22:18:48 -0700 (PDT) Date: Wed, 14 Sep 2011 22:18:47 -0700 From: Vince Fuller To: Jari Arkko Message-ID: <20110915051847.GA14702@vaf-mac1.cisco.com> References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> <4E6FC0E3.8030502@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6FC0E3.8030502@piuha.net> User-Agent: Mutt/1.4.2.3i Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 15 Sep 2011 05:16:38 -0000 > I'm looking at the Map-Request message format and cannot quite convince > myself that there would never be a situation where MTU would be exceeded. > 99.999% of the time it would be fine, but I think we need to describe (if > not fix) what happens when its not. How about adding the following item to > the Section 1 experimental list: I don't really understand how MTU could be an issue here. If there is an MTU restriction, fragmentation would occur upon entry into an ALT GRE tunnel and reassembly would be done when the ALT datagram is received by an ETR. > "o effects of limited possibilities for returning an ICMP message from ALT" It is certainly possible for an intermediate ALT router to be unable to forward an ALT Datagram for some other reason, such as there being no matching next hop (i.e. the destination is not an EID and therefore is not reachable via the ALT). In such cases, the ALT router which cannot forward the datagram would drop it. Section 4.2 describes what an ETR can do if it receives an ALT datagram destined for a non-EID: it returns a negative Map-Reply. An ALT router that understands LISP (i.e. a Map Server or Map Resolver connected to ALT) could similarly send a negative Map-Reply if it cannot forward a Map-Request over the ALT. An ALT router could attempt to return an ICMP message to the RLOC source in a Map-Request received over the ALT. Whether that ICMP message would be received by the Map-Request source (ITR) would depend on whether the ALT router has legacy Internet connectivity in addition to being on the ALT virtual network. The current Cisco LISP implementations do not attempt to return ICMP messages when a failure occurs forwarding on the ALT VRF. If an ITR were to send a Map-Request into the ALT that cannot be delivered over the ALT due to some IP-layer problem, it may very well not receive any positive failure indication. Since such a scenario could only arise through misconfiguration or another serious problem on the ALT network, having an ITR treat the destination as non-LISP-reachable is, in my opinion, the right thing to do, so I don't see a need for additional machinery. > and this text somewhere: > > "Given that packets delivered through ALT have an RLOC source address and > an EID destination address, returning an ICMP error may not always be > possible. Since Map-Request messages are typically small, it is unlikely > that an MTU violation will occur for a Map-Request forwarded on the ALT and > if it did, it may be possible to deal with it through fragmentation of GRE > packets. But in the unlikely event of having to generate an ICMP error due > to MTU or other problems, an ALT node MAY attempt to deliver the error to > the source RLOC outside ALT. If it turns out to be not possible to deliver > the ICMP error, the sender of the Map-Request message will retry, and > failing again, will time out.This could lead to considering the dstination > not LISP-capable. Note that ICMP errors are more likely with Data Probes, > and may lead to the unreported loss of the encapsulated data packet." If you feel it is important enough, we can certainly add text of this sort stating that an ALT router may attempt to return an ICMP message if it cannot forward an ALT Datagram. None of the authors think that this is really necessary. --Vince From rani@paname.org Wed Sep 14 13:37: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 4EA9D21F8A91 for ; Wed, 14 Sep 2011 13:37:20 -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 elV+d6FHryv6 for ; Wed, 14 Sep 2011 13:37:19 -0700 (PDT) Received: from jabba.paname.org (jabba.paname.org [88.191.111.75]) by ietfa.amsl.com (Postfix) with ESMTP id A92F521F88B7 for ; Wed, 14 Sep 2011 13:37:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jabba.paname.org (Postfix) with ESMTP id 807BD585445D; Wed, 14 Sep 2011 22:39:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jabba.paname.org Received: from jabba.paname.org ([127.0.0.1]) by localhost (jabba.paname.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJbAHmVslHVf; Wed, 14 Sep 2011 22:39:21 +0200 (CEST) Received: from jabba.paname.org (jabba.paname.org [88.191.109.75]) by jabba.paname.org (Postfix) with ESMTP id DC74C5854454; Wed, 14 Sep 2011 22:39:21 +0200 (CEST) Date: Wed, 14 Sep 2011 22:39:21 +0200 (CEST) From: Rani Assaf To: Fred L Templin Message-ID: <882f8a14-0e54-4cc1-96c1-63f69468cce1@jabba> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [88.174.22.24] X-Mailer: Zimbra 7.1.0_GA_3140 (ZimbraWebClient - SAF3 (Linux)/7.1.0_GA_3140) X-Mailman-Approved-At: Thu, 15 Sep 2011 08:23:25 -0700 Cc: lisp@ietf.org Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 14 Sep 2011 20:38:35 -0000 Hi, ----- Original Message ----- > First, what if the ETR does not observe the MAY, and > simply lets anonymous nodes pretend to be ITRs that > send inner packets with spoofed EID source addresses? You have a worst attack: what happens to an ETR that uses the RLOC status bits and someone forge data packets from another ITR toward this ETR and plays with those bits? Best, Rani From luigi@net.t-labs.tu-berlin.de Thu Sep 15 13:39:00 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 DA30011E80A1 for ; Thu, 15 Sep 2011 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.936 X-Spam-Level: X-Spam-Status: No, score=0.936 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 JH2mZn-Ma3Ur for ; Thu, 15 Sep 2011 13:39:00 -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 BF92311E80A2 for ; Thu, 15 Sep 2011 13:38:59 -0700 (PDT) Received: from [192.168.2.101] (p4FC25DD8.dip.t-dialin.net [79.194.93.216]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 2D2ED71078D0; Thu, 15 Sep 2011 22:41:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <882f8a14-0e54-4cc1-96c1-63f69468cce1@jabba> Date: Thu, 15 Sep 2011 22:41:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73DD3336-0959-4754-A30E-D2BB2613745C@net.t-labs.tu-berlin.de> References: <882f8a14-0e54-4cc1-96c1-63f69468cce1@jabba> To: Rani Assaf X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 15 Sep 2011 20:39:01 -0000 Hi, On Sep 14, 2011, at 22:39 , Rani Assaf wrote: > Hi, >=20 >=20 > ----- Original Message ----- >> First, what if the ETR does not observe the MAY, and >> simply lets anonymous nodes pretend to be ITRs that >> send inner packets with spoofed EID source addresses? >=20 > You have a worst attack: what happens to an ETR that uses > the RLOC status bits and someone forge data packets from another > ITR toward this ETR and plays with those bits? >=20 Both the LISP main document and the lisp-threats document already = pointed out this. They state that a change in the Loc-Status-Bit should = be confirmed with a Map-Request/Map-Reply exchange. Luigi >=20 >=20 > Best, > Rani > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@uclouvain.be Thu Sep 15 23:10:32 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 78E1A21F8BC5 for ; Thu, 15 Sep 2011 23:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 UxA3-97wAKMc for ; Thu, 15 Sep 2011 23:10:31 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9852421F8BBD for ; Thu, 15 Sep 2011 23:10:30 -0700 (PDT) Received: from facehugger.home (unknown [91.86.22.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1E97F11E48E; Fri, 16 Sep 2011 08:12:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: Date: Thu, 15 Sep 2011 15:53:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=91.86.22.37; helo=facehugger.home Received-SPF: Pass (sender authenticated); receiver=; client-ip=91.86.22.37; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1E97F11E48E.A220D X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 16 Sep 2011 06:10:32 -0000 Hello Fred, On 14 Sep 2011, at 17:18, Templin, Fred L wrote: > Hi Damien, > >> -----Original Message----- >> From: Damien Saucez [mailto:damien.saucez@uclouvain.be] >> Sent: Wednesday, September 14, 2011 11:07 AM >> To: Templin, Fred L >> Cc: lisp@ietf.org >> Subject: Re: [lisp] Source address spoofing by a node >> pretending to be an ITR? >> >> Fred, >> >> You are totally right, obviously if you increase the number of >> source addressees in a packet you increase the spoofing risk. >> >> In the threats draft, two different spoofing techniques are presented >> (EID Spoofing and RLOC Spoofing). We then show the different >> attacks that can be conducted with such spoofing. > > Thanks for pointing out the threats document. In > Section 4, it says: "We do not consider that LISP > has to cope with [on-path] attackers.". Can you > say more about that - for example, are you saying > that on-path attacks will never happen, or that > they can happen but are harmless and therfore not > a matter for concern? No, these attacks exist, can be very harmful but unfortunately, except with some cryptography, I do not see how we can protect the system against on-path attackers. > > I personally would prefer to not have to worry about > on-path attacks, but I'm not sure that they can simply > be ignored and pretend that they won't happen. But, > perhaps a case can be made that on-path attacks are > no more a matter for concern for LISP than they are > for the non-LISP public Internet? In any case, I'd be > interested to know the rationale behind the Section 4 > text. As far as I know the current Internet is not protected against on-path attackers. To protect against them you either need ipsec, SSL or even application specific tricks. The hidden idea behind the threat draft is "if we do not manage to make a system more secured than the current Internet, at least we must have a system that is not less secure." > >> One "funny" attack is by spoofing at the same time the EID and >> the RLOC. >> >> Without cryptography, there is no perfect solution to avoid >> spoofing. Your example with dynamic RLOC is interesting. >> If everything goes well, you should never have a TTL >> longer than the RLOC lease time. However, in the case >> the RLOC changes before the expiration, you will need >> SMR or version change implying the retrieval of the new >> mapping. But in this particular case, you also have a >> security threat that is a DoS... > > Do you see a clear way past these and other threats? > Will it be the case that LISP and its ilk will be > hard to secure and thus difficult to deploy? I think that by taking care of how LISP is deployed and how the features are used, it is possible to achieve the same level of security than today. Doing more is possible, but I am not sure that people are ready to have to deal with cryptography. For example, if you want to protect against spoofing, you can sign the packets (or part of) but then you need a way to know the key used to sign. Do you really want to go to that direction? Damien Saucez > > Thanks - Fred > >> Regards, >> >> Damien Saucez >> >> On 14 Sep 2011, at 10:15, Templin, Fred L wrote: >> >>> I have a question about source address spoofing by a >>> node in the Internet pretending to be an ITR. The >>> document says that the ETR: "MAY compare the inner >>> header source EID address and the outer header source >>> RLOC address with the mapping that exists in the >>> mapping database". But a few questions arise from that. >>> >>> First, what if the ETR does not observe the MAY, and >>> simply lets anonymous nodes pretend to be ITRs that >>> send inner packets with spoofed EID source addresses? >>> Those packets could result in a target node in the >>> ETR's site sending replies to a victim node in the >>> Internet. Is it OK to just let that happen? >>> >>> Second, what if the ETR does observe the MAY, but >>> the ITR's RLOC source addresses change dynamically; >>> perhaps due to >> >>> ity. Would the ETR be able to >>> keep up with all of the RLOC address changes in real >>> time? >>> >>> Third, I'm also wondering whether it is just end nodes >>> that could pretend to be ITRs, or whether there is also >>> a concern for middleboxes that can examine LISP exchanges >>> and then pretend to be ITRs based on what they observe? >>> >>> I'm not trying to poke holes in the proposal; I'm just >>> trying to understand if the LISP ITR/ETR relationship >>> increases the attack surface for source address spoofing >>> beyond the current state of affairs for the non-LISP >>> Internet. Thanks in advance for any insights. >>> >>> Fred >>> fred.l.templin@boeing.com >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> From iesg-secretary@ietf.org Fri Sep 16 08:11:17 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 7B03821F8CBF; Fri, 16 Sep 2011 08:11:17 -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 ywqIh5WrbWk3; Fri, 16 Sep 2011 08:11:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95D721F8CC4; Fri, 16 Sep 2011 08:10:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110916151048.4407.22352.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2011 08:10:48 -0700 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'LISP Internet Groper (LIG)' to Informational RFC (draft-ietf-lisp-lig-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: Fri, 16 Sep 2011 15:11:17 -0000 The IESG has approved the following document: - 'LISP Internet Groper (LIG)' (draft-ietf-lisp-lig-06.txt) as an Informational RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lisp-lig/ Technical Summary This document describes a debugging tool for the LISP system. Working Group Summary There was consensus to send this document forward. Document Quality There are at least two implementations of this specification. Personnel The responsible Area Director is Jari Arkko. RFC-Editor note Please change document class in the header to Informational (currently Experimental) From jari.arkko@piuha.net Mon Sep 19 04:37:02 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 A6B7921F8485 for ; Mon, 19 Sep 2011 04:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 saukWI5waRT5 for ; Mon, 19 Sep 2011 04:37:02 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id AB27A21F847B for ; Mon, 19 Sep 2011 04:37:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4DCC62CEFF; Mon, 19 Sep 2011 14:39:17 +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 6VKuM0adIcfh; Mon, 19 Sep 2011 14:39:16 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6DD9B2CE32; Mon, 19 Sep 2011 14:39:16 +0300 (EEST) Message-ID: <4E7729E4.6070107@piuha.net> Date: Mon, 19 Sep 2011 14:39:16 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Vince Fuller References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> <4E6FC0E3.8030502@piuha.net> <20110915051847.GA14702@vaf-mac1.cisco.com> In-Reply-To: <20110915051847.GA14702@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 19 Sep 2011 11:37:02 -0000 Vince, >> I'm looking at the Map-Request message format and cannot quite convince >> myself that there would never be a situation where MTU would be exceeded. >> 99.999% of the time it would be fine, but I think we need to describe (if >> not fix) what happens when its not. How about adding the following item to >> the Section 1 experimental list: > I don't really understand how MTU could be an issue here. If there is an > MTU restriction, fragmentation would occur upon entry into an ALT GRE > tunnel and reassembly would be done when the ALT datagram is received by > an ETR. OK. (Maybe this should be said somewhere in the draft. Or maybe it already is and I just missed it...) >> "o effects of limited possibilities for returning an ICMP message from ALT" > It is certainly possible for an intermediate ALT router to be unable to > forward an ALT Datagram for some other reason, such as there being no > matching next hop (i.e. the destination is not an EID and therefore is not > reachable via the ALT). OK. Lets focus on the general issue, not the specific MTU problem. > In such cases, the ALT router which cannot forward > the datagram would drop it. Section 4.2 describes what an ETR can do if > it receives an ALT datagram destined for a non-EID: it returns a negative > Map-Reply. An ALT router that understands LISP (i.e. a Map Server or Map > Resolver connected to ALT) could similarly send a negative Map-Reply if > it cannot forward a Map-Request over the ALT. Yes, and this is good. But FWIW -- and maybe this is one reason why the issue has been unclear to me -- Section 4.2 seemed to talk about this only in the context of aggregate prefixes and their holes. And it does talk about only ETRs, not ALT routers. Would it be possible to add something from your above description to the text? > An ALT router could attempt to return an ICMP message to the RLOC source > in a Map-Request received over the ALT. Whether that ICMP message would > be received by the Map-Request source (ITR) would depend on whether the > ALT router has legacy Internet connectivity in addition to being on the > ALT virtual network. The current Cisco LISP implementations do not attempt > to return ICMP messages when a failure occurs forwarding on the ALT VRF. > > If an ITR were to send a Map-Request into the ALT that cannot be delivered > over the ALT due to some IP-layer problem, it may very well not receive > any positive failure indication. Since such a scenario could only arise > through misconfiguration or another serious problem on the ALT network, > having an ITR treat the destination as non-LISP-reachable is, in my opinion, > the right thing to do, so I don't see a need for additional machinery. This may well be so. And I agree that additional machinery might not be helpful. >> and this text somewhere: >> >> "Given that packets delivered through ALT have an RLOC source address and >> an EID destination address, returning an ICMP error may not always be >> possible. Since Map-Request messages are typically small, it is unlikely >> that an MTU violation will occur for a Map-Request forwarded on the ALT and >> if it did, it may be possible to deal with it through fragmentation of GRE >> packets. But in the unlikely event of having to generate an ICMP error due >> to MTU or other problems, an ALT node MAY attempt to deliver the error to >> the source RLOC outside ALT. If it turns out to be not possible to deliver >> the ICMP error, the sender of the Map-Request message will retry, and >> failing again, will time out.This could lead to considering the dstination >> not LISP-capable. Note that ICMP errors are more likely with Data Probes, >> and may lead to the unreported loss of the encapsulated data packet." > If you feel it is important enough, we can certainly add text of this sort > stating that an ALT router may attempt to return an ICMP message if it cannot > forward an ALT Datagram. None of the authors think that this is really > necessary. I think I understand the situation now better, thanks for the explanation. I don't think we need to specify a way to send ICMP messages, but I still think it would be reasonable to explain the situation to the reader. Here's a second try for new text: "Given that packets delivered through ALT have an RLOC source address and an EID destination address, returning an ICMP error may not be possible. As described in Section 4.2., the reception of a packet that has no destination in ALT can be treated by ETRs or even the ALT routers by sending a negative Map-Reply. It is expected that MTU problems are handled as a part of GRE tunnels. Other problems can only occur through misconfiguration or other serious problems with the ALT network. The ALT design treats the remaining cases as packet loss. The sender of a Map-Request may retry sending a message, and failing again, will eventually time out. This leads to treating the destination as not reachable through LISP, which is is the the best or only course of action that can be performed under such circumstances." Comments? Feel free to propose your own text. But I'd like to have something in the draft about this, and this is the only thing preventing the draft going to Last Call... Jari From jmh@joelhalpern.com Mon Sep 19 08:33:38 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 D28F521F8BF4; Mon, 19 Sep 2011 08:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 nADAf1Nn2Vyc; Mon, 19 Sep 2011 08:33:38 -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 45BE021F8B8C; Mon, 19 Sep 2011 08:33:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C12E4300FC; Mon, 19 Sep 2011 08:36:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-99.clppva.btas.verizon.net [71.161.52.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id D079D4300C4; Mon, 19 Sep 2011 08:35:59 -0700 (PDT) Message-ID: <4E77615D.80700@joelhalpern.com> Date: Mon, 19 Sep 2011 11:35:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" References: <20110918020538.C7C5821F86EC@ietfa.amsl.com> In-Reply-To: <20110918020538.C7C5821F86EC@ietfa.amsl.com> X-Forwarded-Message-Id: <20110918020538.C7C5821F86EC@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------060105010908010501040304" Subject: [lisp] Fwd: Nomcom 2011-2012: Second Call for Nominations 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, 19 Sep 2011 15:33:38 -0000 This is a multi-part message in MIME format. --------------060105010908010501040304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Please help by nominating folks (yourself, or other people you beleive can do the job well.) Thank you, Joel -------- Original Message -------- Subject: Nomcom 2011-2012: Second Call for Nominations Date: Sat, 17 Sep 2011 19:05:38 -0700 (PDT) From: NomCom Chair To: IETF Announcement list CC: ietf@ietf.org Hi All, We are halfway through the nomination period (it ends on October 2, 2011) and we need more nominees than we have received so far. We appreciate the folks that have taken the time to nominate people and those who have accepted so far. But the fact remains that the number of nominations have been below average and the acceptance rates of those nominated has also been low. We need **YOUR** input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations – it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come next March and to ensure we have chosen the best candidate. There are several ways you can help the Nomcom - You can nominate yourself. - You can nominate someone you know whom you think would do a good job. Don't worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/3049/ You can enter a nomination by going to the following URL: https://www.ietf.org/group/nomcom/2011/nominate You can also nominate someone by sending an email to nomcom11@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login and password. If you need a login and password, request one from the following URL: https://datatracker.ietf.org/accounts/create/ Open List: ---------- As you already know, NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- 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/ Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com --------------060105010908010501040304 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklldGYg bWFpbGluZyBsaXN0DQpJZXRmQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lldGYNCg0K --------------060105010908010501040304-- From Fred.L.Templin@boeing.com Mon Sep 19 14:20: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 5307A21F8DD1 for ; Mon, 19 Sep 2011 14:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 eY3jP30062gh for ; Mon, 19 Sep 2011 14:20:32 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 479B621F8DCE for ; Mon, 19 Sep 2011 14:20:31 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8JLMqSA028631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Sep 2011 14:22:53 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p8JLMpZc017199; Mon, 19 Sep 2011 16:22:51 -0500 (CDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8JLMpOK017192 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 19 Sep 2011 16:22:51 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 19 Sep 2011 14:22:51 -0700 From: "Templin, Fred L" To: Damien Saucez Date: Mon, 19 Sep 2011 14:22:49 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: Acx0N6Mt/22kTHoPTWGopZxzMgAkygC1+18g Message-ID: References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> In-Reply-To: <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> 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: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 19 Sep 2011 21:20:33 -0000 Hi Damien,=20 > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@uclouvain.be]=20 > Sent: Thursday, September 15, 2011 12:53 PM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] Source address spoofing by a node=20 > pretending to be an ITR? >=20 > Hello Fred, >=20 > On 14 Sep 2011, at 17:18, Templin, Fred L wrote: >=20 > > Hi Damien,=20 > >=20 > >> -----Original Message----- > >> From: Damien Saucez [mailto:damien.saucez@uclouvain.be]=20 > >> Sent: Wednesday, September 14, 2011 11:07 AM > >> To: Templin, Fred L > >> Cc: lisp@ietf.org > >> Subject: Re: [lisp] Source address spoofing by a node=20 > >> pretending to be an ITR? > >>=20 > >> Fred, > >>=20 > >> You are totally right, obviously if you increase the number of > >> source addressees in a packet you increase the spoofing risk. > >>=20 > >> In the threats draft, two different spoofing techniques=20 > are presented > >> (EID Spoofing and RLOC Spoofing). We then show the different > >> attacks that can be conducted with such spoofing. > >=20 > > Thanks for pointing out the threats document. In > > Section 4, it says: "We do not consider that LISP > > has to cope with [on-path] attackers.". Can you > > say more about that - for example, are you saying > > that on-path attacks will never happen, or that > > they can happen but are harmless and therfore not > > a matter for concern? >=20 >=20 > No, these attacks exist, can be very harmful but=20 > unfortunately, except with > some cryptography, I do not see how we can protect the system against > on-path attackers. As far as I can tell, an on-path attacker can mount a spoofing attack and be exempt from ingress filtering. I think the same condition is true both in the current day non-LISP Internet and in the (future) LISP Internet, however LISP also needs to deal with both RLOC and EID spoofing. > > I personally would prefer to not have to worry about > > on-path attacks, but I'm not sure that they can simply > > be ignored and pretend that they won't happen. But, > > perhaps a case can be made that on-path attacks are > > no more a matter for concern for LISP than they are > > for the non-LISP public Internet? In any case, I'd be > > interested to know the rationale behind the Section 4 > > text. >=20 > As far as I know the current Internet is not protected against > on-path attackers. To protect against them you either need ipsec, > SSL or even application specific tricks. Right.=20 > The hidden idea behind the threat draft is "if we do not manage to > make a system more secured than the current Internet, at least we > must have a system that is not less secure." That's why I said: "But, perhaps a case can be made that on-path attacks are no more a matter for concern for LISP than they are for the non-LISP public Internet?". Still, if an off-path attacker can spoof the EID source address even if it cannot spoof the RLOC source address, the end result is a system that is less secure than the current Internet - right? > >> One "funny" attack is by spoofing at the same time the EID and > >> the RLOC. > >>=20 > >> Without cryptography, there is no perfect solution to avoid > >> spoofing. Your example with dynamic RLOC is interesting. > >> If everything goes well, you should never have a TTL > >> longer than the RLOC lease time. However, in the case > >> the RLOC changes before the expiration, you will need > >> SMR or version change implying the retrieval of the new > >> mapping. But in this particular case, you also have a > >> security threat that is a DoS... > >=20 > > Do you see a clear way past these and other threats? > > Will it be the case that LISP and its ilk will be > > hard to secure and thus difficult to deploy? >=20 > I think that by taking care of how LISP is deployed and how > the features are used, it is possible to achieve the same level > of security than today. Doing more is possible, but I am not sure > that people are ready to have to deal with cryptography. For > example, if you want to protect against spoofing, you can sign > the packets (or part of) but then you need a way to know the key > used to sign. >=20 > Do you really want to go to that direction? Do I really want to go in the direction of requiring cryptography? I can't answer that unless you first tell me the intended domain of applicability. I don't think I have yet seen a use case analysis of the various scenarios where LISP xTRs and mapping systems would be deployed and used. There seems to be an unspoken assumption of deployment "in the public Internet", but what about Enterprise networks? What about MANETs? What about aviation networks? What about tactical military networks? What about cellular networks? What about home networks? My team has already taken a look at those and other use cases, and we have shown our approach to be broadly applicable: http://www.rfc-editor.org/rfc/rfc6139.txt We have also arguably already won the acronym arms-race with IRON, RANGER, VET, SEAL and AERO. Thanks - Fred fred.l.templin@boeing.com > Damien Saucez >=20 > >=20 > > Thanks - Fred > >=20 > >> Regards, > >>=20 > >> Damien Saucez > >>=20 > >> On 14 Sep 2011, at 10:15, Templin, Fred L wrote: > >>=20 > >>> I have a question about source address spoofing by a > >>> node in the Internet pretending to be an ITR. The > >>> document says that the ETR: "MAY compare the inner > >>> header source EID address and the outer header source > >>> RLOC address with the mapping that exists in the > >>> mapping database". But a few questions arise from that. > >>>=20 > >>> First, what if the ETR does not observe the MAY, and > >>> simply lets anonymous nodes pretend to be ITRs that > >>> send inner packets with spoofed EID source addresses? > >>> Those packets could result in a target node in the > >>> ETR's site sending replies to a victim node in the > >>> Internet. Is it OK to just let that happen? > >>>=20 > >>> Second, what if the ETR does observe the MAY, but > >>> the ITR's RLOC source addresses change dynamically; > >>> perhaps due to > >>=20 > >>> ity. Would the ETR be able to > >>> keep up with all of the RLOC address changes in real > >>> time? > >>>=20 > >>> Third, I'm also wondering whether it is just end nodes > >>> that could pretend to be ITRs, or whether there is also > >>> a concern for middleboxes that can examine LISP exchanges > >>> and then pretend to be ITRs based on what they observe? > >>>=20 > >>> I'm not trying to poke holes in the proposal; I'm just > >>> trying to understand if the LISP ITR/ETR relationship > >>> increases the attack surface for source address spoofing > >>> beyond the current state of affairs for the non-LISP > >>> Internet. Thanks in advance for any insights. > >>>=20 > >>> Fred > >>> fred.l.templin@boeing.com > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >>=20 >=20 > = From vaf@cisco.com Mon Sep 19 15:42:54 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 7C91721F84BA for ; Mon, 19 Sep 2011 15:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.376 X-Spam-Level: X-Spam-Status: No, score=-4.376 tagged_above=-999 required=5 tests=[AWL=-1.777, 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 SnkI-rN2D421 for ; Mon, 19 Sep 2011 15:42:53 -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 9F11121F84B7 for ; Mon, 19 Sep 2011 15:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=2482; q=dns/txt; s=iport; t=1316472318; x=1317681918; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=JlYEf79+93jIO3MAAA+YECOpu8BSOWX34cP74shR/XQ=; b=XDShclL3L8K/ikkKNicw2sS5N+30FtaWG0eNqcjjTkyILXdXkKtBChWE sKt+DgcsZIkAg435FpCl5O2F1DgsH6Jo3aPnNLnVcKllI7R2/HrwVsjl3 vbGTibfxFnDSS2FTl9xHh0lQCzTYhRdpsIc/vCouZZEoA5OMHbHfllaro o=; X-IronPort-AV: E=Sophos;i="4.68,407,1312156800"; d="scan'208";a="3065747" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 19 Sep 2011 22:45:17 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8JMjHee017963; Mon, 19 Sep 2011 22:45:17 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 45A6B16E1F10; Mon, 19 Sep 2011 15:45:17 -0700 (PDT) Date: Mon, 19 Sep 2011 15:45:17 -0700 From: Vince Fuller To: Jari Arkko Message-ID: <20110919224516.GA95502@vaf-mac1.cisco.com> References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> <4E6FC0E3.8030502@piuha.net> <20110915051847.GA14702@vaf-mac1.cisco.com> <4E7729E4.6070107@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7729E4.6070107@piuha.net> User-Agent: Mutt/1.4.2.3i Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 19 Sep 2011 22:42:54 -0000 > Yes, and this is good. But FWIW -- and maybe this is one reason why the > issue has been unclear to me -- Section 4.2 seemed to talk about this only > in the context of aggregate prefixes and their holes. And it does talk > about only ETRs, not ALT routers. Would it be possible to add something > from your above description to the text? It turns out that there was a placeholder for a section 5.3 that was intended to describe special processing by intermediate ALT routers. Here's what I propose to put there to describe forwarding failures: | 5.3. ALT Datagram forwarding falure | | Intermediate ALT routers, forward ALT Datagrams using normal, hop-by- | hop routing on the ALT overlay network. Should an ALT router not be | able to forward an ALT Datagram, whether due to an unreachable next- | hop, TTL exceeded, or other problem, it has several choices: | | o If the ALT router understands the LISP protocol, as is the case | for a Map Resolver or Map Server, it may respond to a forwarding | failure by returning a negative Map-Reply, as described in | Section 4.2 and [LISP-MS]. | | o If the ALT router does not understand LISP, it may attempt to | return an ICMP message to the source IP address of the packet that | cannot be forwarded. Since the source address is an RLOC, an ALT | router can only do this if it has "native" Internet connectivity | in addition to its ALT overlay network connectivity. | | o A non-LISP-capable ALT router that does not have "native" Internet | connectivity will drop the packet. | | [LISP] and [LISP-MS] define how the source of an ALT Datagram should | handle each of these cases. The last case, where an ALT Datagram is | silently discarded, will generally result in several retransmissions | by the source, followed by treating the destination as unreachable | via LISP when no Map-Reply is received. If a problem on the ALT is | severe enough to prevent ALT Datagrams from being delivered to a | specific EID, this is probably the only sensible way to handle this | case. | | Note that the use of GRE tunnels should prevent MTU problems from | ever occurring on the ALT; an ALT Datagram that exceeds an | intermediate MTU will be fragmented at that point and will be | reassembled by the target of the GRE tunnel. Does this address your concerns? --Vince From vaf@cisco.com Mon Sep 19 16:31:43 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 2E61421F84C1 for ; Mon, 19 Sep 2011 16:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-1.650, 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 mamfoyVl68KL for ; Mon, 19 Sep 2011 16:31:42 -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 806BD21F84BC for ; Mon, 19 Sep 2011 16:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=2116; q=dns/txt; s=iport; t=1316475247; x=1317684847; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qHYkHvTr4X1zX1hTTgItfqjXi6LO52Z+2SgzqboeIxc=; b=WI4Gv06FcFeQk703QnetzXFqlLQWDh37aZXQfn6c897UilnbPyb777w8 M65XzNQKPgTqpXeyvGxyPuk4QXboq/LbkqYDYtpLt/CnLpGO2C5JG0p0H D9yKqqnUathjSB1u3GljUSStiPLDOpANmCmxUtAzfMwY4fhdLYy0dtrOT 0=; X-IronPort-AV: E=Sophos;i="4.68,408,1312156800"; d="scan'208";a="3072600" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 19 Sep 2011 23:34:06 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8JNY6cs029581; Mon, 19 Sep 2011 23:34:06 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 6A22016E279D; Mon, 19 Sep 2011 16:34:05 -0700 (PDT) Date: Mon, 19 Sep 2011 16:34:05 -0700 From: Vince Fuller To: Jari Arkko Message-ID: <20110919233405.GA99869@vaf-mac1.cisco.com> References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> <4E6FC0E3.8030502@piuha.net> <20110915051847.GA14702@vaf-mac1.cisco.com> <4E7729E4.6070107@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E7729E4.6070107@piuha.net> User-Agent: Mutt/1.4.2.3i Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 19 Sep 2011 23:31:43 -0000 As Dino pointed out in a private message to me, the fact that the ALT network is an overlay on the Internet means that it is unlikely that an ALT Router would not have "native" connectivity. Here's a slightly simplified section 5.3 that eliminates the reference to such an unlikely situation. --Vince -------------------- 5.3. ALT Datagram forwarding falure Intermediate ALT Routers, forward ALT Datagrams using normal, hop-by- hop routing on the ALT overlay network. Should an ALT router not be able to forward an ALT Datagram, whether due to an unreachable next- hop, TTL exceeded, or other problem, it has several choices: o If the ALT Router understands the LISP protocol, as is the case for a Map Resolver or Map Server, it may respond to a forwarding failure by returning a negative Map-Reply, as described in Section 4.2 and [LISP-MS]. o If the ALT Router does not understand LISP, it may attempt to return an ICMP message to the source IP address of the packet that cannot be forwarded. Since the source address is an RLOC, an ALT Router would send this ICMP message using "native" Internet connectivity, not via the ALT overlay. o A non-LISP-capable ALT Router may also choose to silently drop the non-forwardable ALT Datagram. [LISP] and [LISP-MS] define how the source of an ALT Datagram should handle each of these cases. The last case, where an ALT Datagram is silently discarded, will generally result in several retransmissions by the source, followed by treating the destination as unreachable via LISP when no Map-Reply is received. If a problem on the ALT is severe enough to prevent ALT Datagrams from being delivered to a specific EID, this is probably the only sensible way to handle this case. Note that the use of GRE tunnels should prevent MTU problems from ever occurring on the ALT; an ALT Datagram that exceeds an intermediate MTU will be fragmented at that point and will be reassembled by the target of the GRE tunnel. From jari.arkko@piuha.net Mon Sep 19 21:54: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 C5B5821F8B2B for ; Mon, 19 Sep 2011 21:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 ZANaQJ0dzF+D for ; Mon, 19 Sep 2011 21:54:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2CC21F8753 for ; Mon, 19 Sep 2011 21:54:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7DDE62D543; Tue, 20 Sep 2011 07:56:18 +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 EX37To8UBzIn; Tue, 20 Sep 2011 07:56:18 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 7B4DC2CE32; Tue, 20 Sep 2011 07:56:16 +0300 (EEST) Message-ID: <4E781CEF.7060802@piuha.net> Date: Tue, 20 Sep 2011 07:56:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Vince Fuller References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> <4E6FC0E3.8030502@piuha.net> <20110915051847.GA14702@vaf-mac1.cisco.com> <4E7729E4.6070107@piuha.net> <20110919224516.GA95502@vaf-mac1.cisco.com> In-Reply-To: <20110919224516.GA95502@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 20 Sep 2011 04:54:26 -0000 Yes, this text is great. Thank you. Put it in the draft and lets move forward. Jari From jari.arkko@piuha.net Mon Sep 19 21:55:44 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 C7E7621F8B2B for ; Mon, 19 Sep 2011 21:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 SaOSP0L8TYkH for ; Mon, 19 Sep 2011 21:55:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id EC96121F8753 for ; Mon, 19 Sep 2011 21:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6D4E92D543; Tue, 20 Sep 2011 07:57:38 +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 kcs8ScA2s3ku; Tue, 20 Sep 2011 07:57:37 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 88FCA2CE32; Tue, 20 Sep 2011 07:57:37 +0300 (EEST) Message-ID: <4E781D40.80803@piuha.net> Date: Tue, 20 Sep 2011 07:57:36 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Vince Fuller References: <4E67EC2A.6000201@piuha.net> <20110908201335.GA60444@vaf-mac1.cisco.com> <4E6926BC.3050102@piuha.net> <6E5EFBD4-1061-431D-B6D5-A35A06E71FD4@cisco.com> <4E6FC0E3.8030502@piuha.net> <20110915051847.GA14702@vaf-mac1.cisco.com> <4E7729E4.6070107@piuha.net> <20110919233405.GA99869@vaf-mac1.cisco.com> In-Reply-To: <20110919233405.GA99869@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-alt@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-alt 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, 20 Sep 2011 04:55:44 -0000 This makes sense. Jari On 20.09.2011 02:34, Vince Fuller wrote: > As Dino pointed out in a private message to me, the fact that the ALT network > is an overlay on the Internet means that it is unlikely that an ALT Router > would not have "native" connectivity. Here's a slightly simplified section > 5.3 that eliminates the reference to such an unlikely situation. > > --Vince > > -------------------- > > 5.3. ALT Datagram forwarding falure > > Intermediate ALT Routers, forward ALT Datagrams using normal, hop-by- > hop routing on the ALT overlay network. Should an ALT router not be > able to forward an ALT Datagram, whether due to an unreachable next- > hop, TTL exceeded, or other problem, it has several choices: > > o If the ALT Router understands the LISP protocol, as is the case > for a Map Resolver or Map Server, it may respond to a forwarding > failure by returning a negative Map-Reply, as described in > Section 4.2 and [LISP-MS]. > > o If the ALT Router does not understand LISP, it may attempt to > return an ICMP message to the source IP address of the packet that > cannot be forwarded. Since the source address is an RLOC, an ALT > Router would send this ICMP message using "native" Internet > connectivity, not via the ALT overlay. > > o A non-LISP-capable ALT Router may also choose to silently drop the > non-forwardable ALT Datagram. > > [LISP] and [LISP-MS] define how the source of an ALT Datagram should > handle each of these cases. The last case, where an ALT Datagram is > silently discarded, will generally result in several retransmissions > by the source, followed by treating the destination as unreachable > via LISP when no Map-Reply is received. If a problem on the ALT is > severe enough to prevent ALT Datagrams from being delivered to a > specific EID, this is probably the only sensible way to handle this > case. > > Note that the use of GRE tunnels should prevent MTU problems from > ever occurring on the ALT; an ALT Datagram that exceeds an > intermediate MTU will be fragmented at that point and will be > reassembled by the target of the GRE tunnel. > From internet-drafts@ietf.org Mon Sep 19 22:05:44 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 8507C21F8B35; Mon, 19 Sep 2011 22:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 5ztiBT9Niprb; Mon, 19 Sep 2011 22:05:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB71821F8A7D; Mon, 19 Sep 2011 22:05:43 -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: <20110920050543.29705.42828.idtracker@ietfa.amsl.com> Date: Mon, 19 Sep 2011 22:05:43 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-alt-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: Tue, 20 Sep 2011 05:05:44 -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 Alternative Topology (LISP+ALT) Author(s) : Vince Fuller Dino Farinacci Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-alt-09.txt Pages : 30 Date : 2011-09-19 This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-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-alt-09.txt From vaf@cisco.com Mon Sep 19 22:11:41 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 A56EF21F84A6 for ; Mon, 19 Sep 2011 22:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.781 X-Spam-Level: X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_00=-2.599, HTML_COMMENT_SAVED_URL=0.114, 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 fy1jQKPt3Rvr for ; Mon, 19 Sep 2011 22:11:38 -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 ECC6F21F88A0 for ; Mon, 19 Sep 2011 22:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=148361; q=dns/txt; s=iport; t=1316495643; x=1317705243; h=date:from:to:subject:message-id:mime-version; bh=x4HipAfyokKlKsCeiAuRRR5yz6FAmBdtrpYiZhFq0ps=; b=gvthMgjItLFcx+8UW+UTTTZNXKxn7g1Tvvn9iqX1WA1XQwhSBtb/ueHY ui59mNDiP3MiDqBF5Nfgx1xCKjz+Q/I2Q4SaDxmnfAY8B+JNtlJk+2+Ww 3mk0nfsZGkDpcuM6S7Lx9S+1pnff/+60ikcbzWj1pPhdxztBqr3zOPkDK Y=; X-Files: rfcdiff-alt-07-to-09.html : 141038 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFggeE6rRDoG/2dsb2JhbAA4BAamWml3gVMBAhYBBQIBEjoEAgUFLgECAQIOARIBIRgdBAIfAhQHB4dZlWqBJgGeN4NSC4I8YASHcJ0pHA X-IronPort-AV: E=Sophos;i="4.68,409,1312156800"; d="html'217?scan'217,208,217";a="3103493" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 20 Sep 2011 05:14:01 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8K5E1tM024599 for ; Tue, 20 Sep 2011 05:14:01 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 7FF8616E54B0; Mon, 19 Sep 2011 22:14:00 -0700 (PDT) Date: Mon, 19 Sep 2011 22:14:00 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110920051400.GA18951@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Fwd: New Version Notification for draft-ietf-lisp-alt-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: Tue, 20 Sep 2011 05:11:41 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This version includes all changes received during the IESG review, most notably, new text in section 1 (the introduction) emphasizing that additional experimentation is needed to answer unresolved questions and a new section 5.3 that describes how an intermediate ALT Router should deal with an ALT Datagram that cannot be forwarded. rfcdiff between version 7 (pre-IESG review) and this version 9 is attached. --Vince (for the LISP+ALT authors) ----- Forwarded message from internet-drafts@ietf.org ----- Date: Mon, 19 Sep 2011 22:05:44 -0700 From: internet-drafts@ietf.org To: vaf@cisco.com Cc: darlewis@cisco.com, vaf@cisco.com, dmm@cisco.com, dino@cisco.com Subject: New Version Notification for draft-ietf-lisp-alt-09.txt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtECAI4feE4MFjoekmdsb2JhbABChFeUQwEBjicUAQEBAQkLCwcSJ4FsARBUAjUCJgJJS55qAYw6kX2BLIQ8gREEh3CLW5FO X-Virus-Scanned: amavisd-new at amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 3.60 A new version of I-D, draft-ietf-lisp-alt-09.txt has been successfully submitted by Vince Fuller and posted to the IETF repository. Filename: draft-ietf-lisp-alt Revision: 09 Title: LISP Alternative Topology (LISP+ALT) Creation date: 2011-09-20 WG ID: lisp Number of pages: 30 Abstract: This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. The IETF Secretariat ----- End forwarded message ----- --1yeeQ81UyVL57Vl7 Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-alt-07-to-09.html" Content-Transfer-Encoding: quoted-printable wdiff draft-ietf-lisp-alt-07.txt draft-ietf-lisp-alt-= 09.txt 
Network Working Group                                          V. Fuller
Internet-Draft                                              D. Farinacci
Intended status: Experimental                                   D. Meyer
Expires: December 31, 2011 March 23, 2012                   =
                      D. Lewis
                                                                   Cisco
                                                           June 29,
                                                      September 20, 2011

                  LISP Alternative Topology (LISP+ALT)
                       draft-ietf-lisp-alt-07.t=
xt
                       draft-ietf-lisp-alt-09=
.txt

Abstract

   This document describes a simple distributed index system to be used
   by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
   (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
   which holds the mapping information for a particular Endpoint
   Identifier (EID).  The MR can then query that ETR to obtain the
   actual mapping information, which consists of a list of Routing
   Locators (RLOCs) for the EID.  Termed the Alternative Logical
   Topology (ALT), the index is built as an overlay network on the
   public Internet using the Border Gateway Protocol (BGP) and the
   Generic Routing Encapsulation (GRE).  Using these proven protocols,
   the ALT can be built and deployed relatively quickly without any
   changes to the existing routing infrastructure.

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 December =
31, 2011. March 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   3.  The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Routeability of EIDs . . . . . . . . . . . . . . . . . . .  9
       3.1.1.  Mechanisms for an ETR to originate EID-prefixes  . . . 10
       3.1.2.  Mechanisms for an ITR to forward to EID-prefixes . . . 10
       3.1.3.  Map Server Model preferred . . . . . . . . . . . . . . 10
     3.2.  Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
     3.3.  Caveats on the use of Data Probes  . . . . . . . . . . . . 11
   4.  LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
     4.2.  EID Assignment - Hierarchy and Topology  . . . . . . . . . 13
     4.3.  Use of GRE and BGP between LISP+ALT Routers  . . . . . . . 15
   5.  EID-prefix Propagation and Map-Request Forwarding  . . . . . . 16
     5.1.  Changes to ITR behavior with LISP+ALT  . . . . . . . . . . 16
     5.2.  Changes to ETR behavior with LISP+ALT  . . . . . . . . . . 16 17
     5.3.  ALT Datagram forwarding falure . . . . . . . . . . . . . . 17
   6.  BGP configuration and protocol considerations  . . . . . . . . 18 19<=
/font>
     6.1.  Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18 19<=
/font>
     6.2.  Sub-Address Family Identifier (SAFI) for LISP+ALT  . . . . 18 19<=
/font>
   7.  EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19 20<=
/font>
     7.1.  Stability of the ALT . . . . . . . . . . . . . . . . . . . 19 20<=
/font>
     7.2.  Traffic engineering using LISP . . . . . . . . . . . . . . 19 20<=
/font>
     7.3.  Edge aggregation and dampening . . . . . . . . . . . . . . 20 21<=
/font>
     7.4.  EID assignment flexibility vs. ALT scaling . . . . . . . . 20 21<=
/font>
   8.  Connecting sites to the ALT network  . . . . . . . . . . . . . 22 23<=
/font>
     8.1.  ETRs originating information into the ALT  . . . . . . . . 22 23<=
/font>
     8.2.  ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 22 23<=
/font>
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24 25<=
/font>
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 25 26<=
/font>
     10.1. Apparent LISP+ALT Vulnerabilities  . . . . . . . . . . . . 25 26<=
/font>
     10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 26 27<=
/font>
     10.3. Use of new IETF standard BGP Security mechanisms . . . . . 26 27<=
/font>
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27 28<=
/font>
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 29<=
/font>
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 29<=
/font>
     12.2. Informative References . . . . . . . . . . . . . . . . . . 28 29<=
/font>
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 30<=
/font>

1.  Introduction

   This document describes the LISP+ALT system, used by a [LISP] ITR or
   MR to find the ETR that holds the RLOC mapping information for a
   particular EID.  The ALT network is built using the Border Gateway
   Protocol (BGP, [RFC4271]), the BGP multi-protocol extension
   [RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to
   construct an overlay network of devices (ALT Routers) which operate
   on EID-prefixes and use EIDs as forwarding destinations.

   ALT Routers advertise hierarchically-delegated segments of the EID
   namespace (i.e., prefixes) toward the rest of the ALT; they also
   forward traffic destined for an EID covered by one of those prefixes
   toward the network element that is authoritative for that EID and is
   the origin of the BGP advertisement for that EID-prefix.  An Ingress
   Tunnel Router (ITR) uses this overlay to send a LISP Map-Request
   (defined in [LISP]) to the Egress Tunnel Router (ETR) that holds the
   EID-to-RLOC mapping for a matching EID-prefix.  In most cases, an ITR
   does not connect directly to the overlay network but instead sends
   Map-Requests via a Map-Resolver (described in [LISP-MS]) which does.
   Likewise, in most cases, an ETR does not connect directly to the
   overlay network but instead registers its EID-prefixes with a Map-
   Server that advertises those EID-prefixes on to the ALT and forwards
   Map-Requests for them to the ETR.

   It is important to note that the ALT does not distribute actual EID-
   to-RLOC mappings.  What it does provide is a forwarding path from an
   ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which
   holds that mapping.  The ITR/MR uses this path to send an ALT
   Datagram (see Section 3) to an ETR which then responds with a Map-
   Reply containing the needed mapping information.

   One design goal for LISP+ALT is to use existing technology wherever
   possible.  To this end, the ALT is intended to be built using off-
   the-shelf routers which already implement the required protocols (BGP
   and GRE); little, if any, LISP-specific modifications should be
   needed for such devices to be deployed on the ALT. ALT (see Section 7 for
   aggregation requirements).  Note, though, that organizat=
ional and
   operational considerations suggest that ALT Routers be both logically
   and physically separate from the "native" Internet packet transport
   system; deploying this overlay on those routers which are already
   participating in the global routing system and actively forwarding
   Internet traffic is not recommended.

   This specification is experimental, and th=
ere are areas where further
   experience is needed to understand the best implementation strategy,
   operational model, and effects on Internet operations.  These areas
   include:

   o  application effects of on-demand route map discovery

   o  tradeoff in connection setup time vs. ALT design and performance
      when using a Map Request instead of carring initial user data in a
      Data Probe

   o  best practical ways to build ALT hierarchies

   o  effects of route leakage from ALT to the current Internet,
      particularly for LISP-to-non-LISP interworking

   o  effects of exceptional situations, such as denial-of-service
      attacks

   Experimentation, measurements, and deployment experience on these
   aspects is appreciated.  While these issues are conceptually well-
   understood (e.g. an ALT lookup causes potential delay for the first
   packet destined to a given network), the real-world operational
   effects are much less clear.

   The remainder of this document is organized as follows: Section 2
   provides the definitions of terms used in this document.  Section 3
   outlines the LISP ALT model, where EID prefixes are routed across an
   overlay network.  Section 4 provides a basic overview of the LISP
   Alternate Topology architecture, and Section 5 describes how the ALT
   uses BGP to propagate Endpoint Identifier reachability over the
   overlay network and Section 6 describes other considerations for
   using BGP on the ALT.  Section 7 describes the construction of the
   ALT aggregation hierarchy, and Section 8 discusses how LISP+ALT
   elements are connected to form the overlay network.

2.  Definition of Terms

   This section provides high-level definitions of LISP concepts and
   components involved with and affected by LISP+ALT.

    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 (and, if supported, Data Probes) toward
      the ETR that "owns" an EID-prefix.  As a tunneled overlay, its
      performance is expected to be quite limited so use of it to
      forward high-bandwidth flows of Data Probes is strongly
      discouraged (see Section 3.3 for additional discussion).

    Legacy Internet:  The portion of the Internet which does not run
      LISP and does not participate in LISP+ALT.

    ALT Router:  The devices which run on 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.  An ALT
      Router at the lowest level, or "edge" of the ALT, learns EID-
      prefixes from its "client" ETRs.  See Section 3.1 for a
      description of how EID-prefixes are learned at the "edge" of the
      ALT.  See also Section 6 for details on how BGP is configured
      between the different network elements.  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.

    Endpoint ID (EID):  A 32-bit (for IPv4) or 128-bit (for ipv6) value
      used to identify the ultimate source or destination for a LISP-
      encapsulated packet.  See [LISP] for details.

    EID-prefix:  A set of EIDs delegated in a power-of-two block.  EID-
      prefixes are routed on the ALT (not on the global Internet) and
      are expected to be assigned in a hierarchical manner such that
      they can be aggregated by ALT Routers.  Such a block is
      characterized by a prefix and a length.  Note that while the ALT
      routing system considers an EID-prefix to be an opaque block of
      EIDs, an end site may put site-local, topologically-relevant
      structure (subnetting) into an EID-prefix for intra-site routing.

    Aggregated EID-prefixes:  A set of individual EID-prefixes that have
      been aggregated in the [RFC4632] sense.

    Map Server (MS):   An edge ALT Router that provides a registration
      function for non-ALT-connected ETRs, originates EID-prefixes into
      the ALT on behalf of those ETRs, and forwards Map-Requests to
      them.  See [LISP-MS] for details.

    Map Resolver (MR):   An edge ALT Router that accepts an Encapsulated
      Map-Request from a non-ALT-connected ITR, decapsulates it, and
      forwards it on to the ALT toward the ETR which owns the requested
      EID-prefix.  See [LISP-MS] for details.

    Ingress Tunnel Router (ITR):   A router which sends LISP Map-
      Requests or encapsulates IP datagrams with LISP headers, as
      defined in [LISP].  In this document, the term refers to any
      device implementing ITR functionality, including a Proxy-ITR (see
      [LISP-IW]).  Under some circumstances, a LISP Map Resolver may
      also originate Map-Requests (see [LISP-MS]).

    Egress Tunnel Router (ETR):   A router which sends LISP Map-Replies
      in response to LISP Map-Requests and decapsulates LISP-
      encapsulated IP datagrams for delivery to end systems, as defined
      in [LISP].  In this document, the term refers to any device
      implementing ETR functionality, including a Proxy-ETR (see
      [LISP-IW]).  Under some circumstances, a LISP Map Server may also
      respond to Map-Requests (see [LISP-MS]).

    Routing Locator (RLOC):  A routable IP address for a LISP tunnel
      router (ITR or ETR).  Interchangeably referred to as a "locator"
      in this document.  An RLOC is also the output of an EID-to-RLOC
      mapping lookup; an EID-prefix maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point where 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.  Routing for RLOCs is not
      carried on the ALT.

    EID-to-RLOC Mapping:  A binding between an EID-prefix and the set of
      RLOCs that can be used to reach it; sometimes referred to simply
      as a "mapping".

    EID-prefix Reachability:  An EID-prefix is said to be "reachable" if
      at least one of its locators is reachable.  That is, an EID-prefix
      is reachable if the ETR that is authoritative for a given EID-to-
      RLOC mapping is reachable.

    Default Mapping:  A Default Mapping is a mapping entry for EID-
      prefix 0.0.0.0/0 (0::/0 for ipv6).  It maps to a locator-set used
      for all EIDs in the Internet.  If there is a more specific EID-
      prefix in the mapping cache it overrides the Default Mapping
      entry.  The Default Mapping can be learned by configuration or
      from a Map-Reply message.

    ALT Default Route:  An EID-prefix value of 0.0.0.0/0 (or 0::/0 for
      ipv6) which may be learned from the ALT or statically configured
      on an edge ALT Router.  The ALT-Default Route defines a forwarding
      path for a packet to be sent into the ALT on a router which does
      not have a full ALT forwarding database.

3.  The LISP+ALT model

   The LISP+ALT model uses the same basic query/response protocol that
   is documented in [LISP].  In particular, LISP+ALT provides two types
   of packet that an ITR can originate to obtain EID-to-RLOC mappings:

   Map-Request:  A Map-Request message is sent into the ALT to request
      an EID-to-RLOC mapping.  The ETR which owns the mapping will
      respond to the ITR with a Map-Reply message.  Since the ALT only
      forwards on EID destinations, the destination address of the Map-
      Request sent on the ALT must be an EID.

   Data Probe:  Alternatively, an ITR may encapsulate and send the first
      data packet destined for an EID with no known RLOCs into the ALT
      as a Data Probe.  This might be done to=
 minimize packet loss and
      to probe for the mapping.  As above, the authoritative ETR for the
      EID-prefix will respond to the ITR with a Map-Reply message when
      it receives the data packet over the ALT.  As a side-effect, the
      encapsulated data packet is delivered to the end-system at the ETR
      site.  Note that the Data Probe's inner IP destination address,
      which is an EID, is copied to the outer IP destination address so
      that the resulting packet can be routed over the ALT.  See
      Section 3.3 for caveats on the usability of Data Probes.

   The term "ALT Datagram" is short-hand for a Map-Request or Data Probe
   to be sent into or forwarded on the ALT.  Note that such packets use
   an RLOC as the outer header source IP address and an EID as the outer
   header destination IP address.

   Detailed descriptions of the LISP packet types referenced by this
   document may be found in [LISP].

3.1.  Routeability of EIDs

   A LISP EID has the same syntax as IP address and can be used,
   unaltered, as the source or destination of an IP datagram.  In
   general, though, EIDs are not routable on the public Internet; LISP+
   ALT provides a separate, virtual network, known as the LISP
   Alternative Logical Topology (ALT) on which a datagram using an EID
   as an IP destination address may be transmitted.  This network is
   built as an overlay on the public Internet using tunnels to
   interconnect ALT Routers.  BGP runs over these tunnels to propagate
   path information needed to forward ALT Datagrams.  Importantly, while
   the ETRs are the source(s) of the unaggregated EID-prefixes, LISP+ALT
   uses existing BGP mechanisms to aggregate this information.

3.1.1.  Mechanisms for an ETR to originate EID-prefixes

   There are three ways that an ETR may originate its mappings into the
   ALT:

   1.  By registration with a Map Server as documented in [LISP-MS].
       This is the common case and is expected to be used by the
       majority of ETRs.

   2.  Using a "static route" on the ALT.  Where no Map-Server is
       available, an edge ALT Router may be configured with a "static
       EID-prefix route" pointing to an ETR.

   3.  Edge connection to the ALT.  If a site requires fine- grained
       control over how its EID-prefixes are advertised into the ALT, it
       may configure its ETR(s) with tunnel and BGP connections to edge
       ALT Routers.

3.1.2.  Mechanisms for an ITR to forward to EID-prefixes

   There are three ways that an ITR may send ALT Datagrams:

   1.  Through a Map Resolver as documented in [LISP-MS].  This is the
       common case and is expected to be used by the majority of ITRs.

   2.  Using a "default route".  Where a Map Resolver is not available,
       an ITR may be configured with a static ALT Default Route pointing
       to an edge ALT Router.

   3.  Edge connection to the ALT.  If a site requires fine-grained
       knowledge of what prefixes exist on the ALT, it may configure its
       ITR(s) with tunnel and BGP connections to edge ALT Routers.

3.1.3.  Map Server Model preferred

   The ALT-connected ITR and ETR cases are expected to be rare, as the
   Map Server/Map Resolver model is both simpler for an ITR/ETR operator
   to use, and provides a more general service interface to not only the
   ALT, but also to other mapping databases that may be developed in the
   future.

3.2.  Connectivity to non-LISP sites

   As stated above, EIDs used as IP addresses by LISP sites are not
   routable on the public Internet.  This implies that, absent a
   mechanism for communication between LISP and non-LISP sites,
   connectivity between them is not possible.  To resolve this problem,
   an "interworking" technology has been defined; see [LISP-IW] for
   details.

3.3.  Caveats on the use of Data Probes

   It is worth noting that there has been a great deal of discussion and
   controversy about whether Data Probes are a good idea.  On the one
   hand, using them offers a method of avoiding the "first packet drop"
   problem when an ITR does not have a mapping for a particular EID-
   prefix.  On the other hand, forwarding data packets on the ALT would
   require that it either be engineered to support relatively high
   traffic rates, which is not generally feasible for a tunneled
   network, or that it be carefully designed to aggressively rate-limit
   traffic to avoid congestion or DoS attacks.  There may also be issues
   caused by different latency or other performance characteristics
   between the ALT path taken by an initial Data Probe and the
   "Internet" path taken by subsequent packets on the same flow once a
   mapping is in place on an ITR.  For these reasons, the use of Data
   Probes is not recommended at this time; they should only be
   originated an ITR when explicitly configured to do so and such
   configuration should only be enabled when performing experiments
   intended to test the viability of using Data Probes.

4.  LISP+ALT: Overview

   LISP+ALT is a hybrid push/pull architecture.  Aggregated EID-prefixes
   are advertised among the ALT Routers and to those (rare) ITRs that
   are directly connected via a tunnel and BGP to the ALT.  Specific
   EID-to-RLOC mappings are requested by an ITR (and returned by an ETR)
   using LISP when it sends a request either via a Map Resolver or to an
   edge ALT Router.

   The basic idea embodied in LISP+ALT is to use BGP, running on a
   tunneled overlay network (the ALT), to establish reachability between
   ALT Routers.  The ALT BGP Route Information Base (RIB) is comprised
   of EID-prefixes and associated next hops.  ALT Routers interconnect
   using BGP and propagate EID-prefix updates among themselves.  EID-
   prefix information is learned from ETRs at the "edge" of the ALT
   either through the use of the Map Server interface (the commmon
   case), static configuration, or by BGP-speaking ETRs.

   An ITR uses the ALT to learn the best path for forwarding an ALT
   Datagram destined to a particular EID-prefix.  An ITR will normally
   use a Map Resolver to send its ALT Datagrams on to the ALT but may,
   in unusual circumstances, use a static ALT Default Route or connect
   to the ALT using BGP.

   Note that while this document specifies the use of Generic Routing
   Encapsulation (GRE) as a tunneling mechanism, there is no reason that
   parts of the ALT cannot be built using other tunneling technologies,
   particularly in cases where GRE does not meet security, management,
   or other operational requirements.  References to "GRE tunnel" in
   later sections of this document should therefore not be taken as
   prohibiting or precluding the use of other tunneling mechanisms.
   Note also that two ALT Routers that are directly adjacent (with no
   layer-3 router hops between them) need not use a tunnel between them;
   in this case, BGP may be configured across the interfaces that
   connect to their common subnet and that subnet is then considered to
   be part of the ALT topology.  Use of techniques such as "eBGP
   multihop" to connect ALT Routers that do not share a tunnel or common
   subnet is not recommended as the non-ALT Routers in between the ALT
   Routers in such a configuration may not have information necessary to
   forward ALT Datagrams destined to EID-prefixes exchanged across that
   BGP session.

   In summary, LISP+ALT uses BGP to build paths through ALT Routers so
   that an ALT Datagram sent into the ALT can be forwarded to the ETR
   that holds the EID-to-RLOC mapping for that EID-prefix.  This
   reachability is carried as IPv4 or ipv6 NLRI without modification
   (since an EID-prefix has the same syntax as IPv4 or ipv6 address
   prefix).  ALT Routers establish BGP sessions with one another,
   forming the ALT.  An ALT Router at the "edge" of the topology learns
   EID-prefixes originated by authoritative ETRs.  Learning may be
   though the Map Server interface, by static configuration, or via BGP
   with the ETRs.  An ALT Router may also be configured to aggregate
   EID-prefixes received from ETRs or from other LISP+ALT routers Routers that
   are topologically "downstream" from it.

4.1.  ITR traffic handling

   When an ITR receives a packet originated by an end system within its
   site (i.e. a host for which the ITR is the exit path out of the site)
   and the destination EID for that packet is not known in the ITR's
   mapping cache, the ITR creates either a Map-Request for the
   destination EID or the original packet encapsulated as a Data Probe
   (see Section 3.3 for caveats on the usability of Data Probes).  The
   result, known as an ALT Datagram, is then sent to an ALT Router (see
   also [LISP-MS] for non-ALT-connected ITRs, noting that Data Probes
   cannot be sent to a Map-Resolver).  This "first hop" ALT Router uses
   EID-prefix routing information learned from other ALT Routers via BGP
   to guide the packet to the ETR which "owns" the prefix.  Upon receipt
   by the ETR, normal LISP processing occurs: the ETR responds to the
   ITR with a LISP Map-Reply that lists the RLOCs (and, thus, the ETRs
   to use) for the EID-prefix.  For Data Probes, the ETR also
   decapsulates the packet and transmits it toward its destination.

   Upon receipt of the Map-Reply, the ITR installs the RLOC information
   for a given prefix into a local mapping database.  With these mapping
   entries stored, additional packets destined to the given EID-prefix
   are routed directly to an RLOC without use of the ALT, until either
   the entry's TTL has expired, or the ITR can otherwise find no
   reachable ETR.  Note that a current mapping may exist that contains
   no reachable RLOCs; this is known as a Negative Cache Entry and it
   indicates that packets destined to the EID-prefix are to be dropped.

   Full details on Map-Request/Map-Reply processing may be found in
   [LISP].

   Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.
   Map-Requests and Data Probes (if supported).  Given the relatively
   low performance expected of a tuneled=
 tunneled topology, =
ALT Routers (and Map
   Resolvers) should aggressively rate-limit the ingress of ALT
   Datagrams from ITRs and, if possible, should be configured to not
   accept packets that are not ALT Datagrams.

4.2.  EID Assignment - Hierarchy and Topology

   EID-prefixes are expected to be allocated to a LISP site by Internet
   Registries.  Where a site has multiple allocations which are aligned
   on a power-of-2 block boundary, they should be aggregated into a
   single EID-prefix for advertisement.  The ALT network is built in a
   roughly hierarchical, partial mesh which is intended to allow
   aggregation where clearly-defined hierarchical boundaries exist.
   Building such a structure should minimize the number of EID-prefixes
   carried by LISP+ALT nodes near the top of the hierarchy.

   Routes on the ALT do not need to respond to changes in policy,
   subscription, or underlying physical connectivity, so the topology
   can remain relatively static and aggregation can be sustained.
   Because routing on the ALT uses BGP, the same rules apply for
   generating aggregates; in particular, a ALT Router should only be
   configured to generate an aggregate if it is configured with BGP
   sessions to all of the originators of components (more-specific
   prefixes) of that aggregate.  Not all of the components of need to be
   present for the aggregate to be originated (some may be holes in the
   covering prefix and some may be down) but the aggregating router must
   be configured to learn the state of all of the components.

   Under what circumstances the ALT Router actually generates the
   aggregate is a matter of local policy: in some cases, it will be
   statically configured to do so at all times with a "static discard"
   route.  In other cases, it may be configured to only generate the
   aggregate prefix if at least one of the components of the aggregate
   is learned via BGP.

   An ALT Router must not generate an aggregate that includes a non-
   LISP-speaking hole unless it can be configured to return a Negative
   Map-Reply with action=3D"Natively-Forward" (see [LISP]) if it receives
   an ALT Datagram that matches that hole.  If it receives an ALT
   Datagram that matches a LISP-speaking hole that is currently not
   reachable, it should return a Negative Map-Reply with action=3D"drop".
   Negative Map-Replies should be returned with a short TTL, as
   specified in [LISP-MS].  Note that an off-the-shelf, non-LISP-
   speaking router configured as an aggregating ALT Router cannot send
   Negative Map-Replies, so such a router must never originate an
   aggregate that includes a non-LISP-speaking hole.

   This implies that two ALT Routers that share an overlapping set of
   prefixes must exchange those prefixes if either is to generate and
   export a covering aggregate for those prefixes.  It also implies that
   an ETR which connects to the ALT using BGP must maintain BGP sessions
   with all of the ALT Routers that are configured to originate an
   aggregate which covers that prefix and that each of those ALT Routers
   must be explicitly configured to know the set of EID-prefixes that
   make up any aggregate that it originates.  See also [LISP-MS] for an
   example of other ways that prefix origin consistency and aggregation
   can be maintained.

   As an example, consider ETRs that are originating EID-prefixes for
   10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24.  An ALT
   Router should only be configured to generate an aggregate for
   10.1.0.0/16 if it has BGP sessions configured with all of these ETRs,
   in other words, only if it has sufficient knowledge about the state
   of those prefixes to summarize them.  If the Router originating
   10.1.0.0/16 receives an ALT Datagram destined for 10.1.77.88, a non-
   LISP destination covered by the aggregate, it returns a Negative Map-
   Reply with action "Natively-Forward".  If it receives an ALT Datagram
   destined for 10.1.128.199 but the configured LISP prefix
   10.1.128.0/24 is unreachable, it returns a Negative Map-Reply with
   action "drop".

   Note: much is currently uncertain about the best way to build the ALT
   network; as testing and prototype deployment proceeds, a guide to how
   to best build the ALT network will be developed.

4.3.  Use of GRE and BGP between LISP+ALT Routers

   The ALT network is built using GRE tunnels between ALT Routers.  BGP
   sessions are configured over those tunnels, with each ALT Router
   acting as a separate AS "hop" in a Path Vector for BGP.  For the
   purposes of LISP+ALT, the AS-path is used solely as a shortest-path
   determination and loop-avoidance mechanism.  Because all next-hops
   are on tunnel interfaces, no IGP is required to resolve those next-
   hops to exit interfaces.

   LISP+ALT's use of GRE and BGP facilities deployment and operation of
   LISP because no new protocols need to be defined, implemented, or
   used on the overlay topology; existing BGP/GRE tools and operational
   expertise are also re-used.  Tunnel address assignment is also easy:
   since the addresses on an ALT tunnel are only used by the pair of
   routers connected to the tunnel, the only requirement of the IP
   addresses used to establish that tunnel is that the attached routers
   be reachable by each other; any addressing plan, including private
   addressing, can therefore be used for ALT tunnels.

5.  EID-prefix Propagation and Map-Request Forwarding

   As described in Section 8.2, an ITR sends an ALT Datagram to a given
   EID-to-RLOC mapping.  The ALT provides the infrastructure that allows
   these requests to reach the authoritative ETR.

   Note that under normal circumstances Map-Replies are not sent over
   the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned
   from the original Map-Request.  See sectio=
ns 6.1.2 and 6.2 of [LISP]
   for more information on the use of the Map-Request ITR RLOC field.
   Keep in mind that the ITR RLOC field supports mulitple RLOCs in
   multiple address families, so a Map-Reply sent in response to a Map-
   Request is not necessarily sent to back to the Map-Request RLOC
   source.

   There may be scenarios, perhaps to encourage caching of EID-to-RLOC
   mappings by ALT Routers, where Map-
   Replies Map-Replies=
 could be sent over the ALT
   or where a "first-hop" ALT router Router might modify the=
 originating RLOC
   on a Map-Request received from an ITR to force the Map-Reply to be
   returned to the "first-hop" ALT Router.  These cases will not be
   supported by initial LISP+ALT implementations but may be subject to
   future experimentation.

   ALT Routers propagate path information via BGP ([RFC4271]) that is
   used by ITRs to send ALT Datagrams toward the appropriate ETR for
   each EID-prefix.  BGP is run on the inter-ALT Router links, and
   possibly between an edge ("last hop") ALT Router and an ETR or
   between an edge ("first hop") ALT Router and an ITR.  The ALT BGP RIB
   consists of aggregated EID-prefixes and their next hops toward the
   authoritative ETR for that EID-prefix.

5.1.  Changes to ITR behavior with LISP+ALT

   As previously described, an ITR will usually use the Map Resolver
   interface and will send its Map Requests to a Map Resolver.  When an
   ITR instead connects via tunnels and BGP to the ALT, it sends ALT
   Datagrams to one of its "upstream" ALT Routers; these are sent only
   to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh
   Map-Requests are not sent on the ALT.  As in basic LISP, it should
   use one of its RLOCs as the source address of these queries; it
   should not use a tunnel interface as the source address as doing so
   will cause replies to be forwarded over the tunneled topology and may
   be problematic if the tunnel interface address is not routed
   throughout the ALT.  If the ITR is running BGP with the LISP+ALT
   router(s), it selects the appropriate ALT Router based on the BGP
   information received.  If it is not running BGP, it uses a
   statically-configued ALT Default Route to select an ALT Router.

5.2.  Changes to ETR behavior with LISP+ALT

   As previously described, an ETR will usually use the Map Server
   interface (see [LISP-MS]) and will register its EID-prefixes with its
   configured Map Servers.  When an ETR instead connects using BGP to
   one or more ALT Routers, it announces its EID-prefix(es) to those ALT
   Routers.

   As documented in [LISP], when an ETR generates a Map-Reply message to
   return to a querying ITR, it sets the outer header IP destination
   address to one of the requesting ITR's RLOCs so that the Map-Reply
   will be sent on the underlying Internet topology, not on the ALT;
   this avoids any latency penalty (or "stretch") that might be incurred
   by sending the Map-Reply via the ALT, reduces load on the ALT, and
   ensures that the Map-Reply can be routed even if the original ITR
   does not have an ALT-routed EID.  For details on how an ETR selects
   which ITR RLOC to use, see section 6.1.5 of [LISP].

5.3.  ALT Datagram forwarding falure

   Intermediate ALT Routers, forward ALT Datagrams using normal, hop-by-
   hop routing on the ALT overlay network.  Should an ALT router not be
   able to forward an ALT Datagram, whether due to an unreachable next-
   hop, TTL exceeded, or other problem, it has several choices:

   o  If the ALT Router understands the LISP protocol, as is the case
      for a Map Resolver or Map Server, it may respond to a forwarding
      failure by returning a negative Map-Reply, as described in
      Section 4.2 and [LISP-MS].

   o  If the ALT Router does not understand LISP, it may attempt to
      return an ICMP message to the source IP address of the packet that
      cannot be forwarded.  Since the source address is an RLOC, an ALT
      Router would send this ICMP message using "native" Internet
      connectivity, not via the ALT overlay.

   o  A non-LISP-capable ALT Router may also choose to silently drop the
      non-forwardable ALT Datagram.

   [LISP] and [LISP-MS] define how the source of an ALT Datagram should
   handle each of these cases.  The last case, where an ALT Datagram is
   silently discarded, will generally result in several retransmissions
   by the source, followed by treating the destination as unreachable
   via LISP when no Map-Reply is received.  If a problem on the ALT is
   severe enough to prevent ALT Datagrams from being delivered to a
   specific EID, this is probably the only sensible way to handle this
   case.

   Note that the use of GRE tunnels should prevent MTU problems from
   ever occurring on the ALT; an ALT Datagram that exceeds an
   intermediate MTU will be fragmented at that point and will be
   reassembled by the target of the GRE tunnel.

6.  BGP configuration and protocol considerations

6.1.  Autonomous System Numbers (ASNs) in LISP+ALT

   The primary use of BGP today is to define the global Internet routing
   topology in terms of its participants, known as Autonomous Systems.
   LISP+ALT specifies the use of BGP to create a global overlay network
   (the ALT) for finding EID-to-RLOC mappings.  While related to the
   global routing database, the ALT serves a very different purpose and
   is organized into a very different hierarchy.  Because LISP+ALT does
   use BGP, however, it uses ASNs in the paths that are propagated among
   ALT Routers.  To avoid confusion, it needs t=
o be stressed that that
   these LISP+ALT ASNs should use a new numbering space newly-assigned
   AS numbers that is are unrelated to the A=
SNs used by the global routing
   system.  Exactly how this new space will be assigned and managed will
   be determined during the deployment of LISP+ALT.

   Note that the ALT Routers that make up the "core" of the ALT will not
   be associated with any existing core-Internet ASN because the ALT
   topology is completely separate from, and independent of, the global
   Internet routing system.

6.2.  Sub-Address Family Identifier (SAFI) for LISP+ALT

   As defined by this document, LISP+ALT may be implemented using BGP
   without modification.  Given the fundamental operational difference
   between propagating global Internet routing information (the current
   dominant use of BGP) and creating an overlay network for finding EID-
   to-RLOC mappings (the use of BGP proposed by this document), it may
   be desirable to assign a new SAFI [RFC4760] to prevent operational
   confusion and difficulties, including the inadvertent leaking of
   information from one domain to the other.  Use of a separate SAFI
   would make it easier to debug many operational problems but would
   come at a significant cost: unmodified, off-the-shelf routers which
   do not understand the new SAFI could not be used to build any part of
   the ALT network.  At present, this document does not request the
   assignment of a new SAFI; additional experimentation may suggest the
   need for one in the future.

7.  EID-prefix Aggregation

   The ALT BGP peering topology should be arranged in a tree-like
   fashion (with some meshiness), with redundancy to deal with node and
   link failures.  A basic assumption is that as long as the routers are
   up and running, the underlying Internet will provide alternative
   routes to maintain BGP connectivity among ALT Routers.

   Note that, as mentioned in Section 4.2, the use of BGP by LISP+ALT
   requires that information only be aggregated where all active more-
   specific prefixes of a generated aggregate prefix are known.  This is
   no different than the way that BGP route aggregation works in the
   existing global routing system: a service provider only generates an
   aggregate route if it is configured to learn to all prefixes that
   make up that aggregate.

7.1.  Stability of the ALT

   It is worth noting that LISP+ALT does not directly propagate EID-to-
   RLOC mappings.  What it does is provide a mechanism for an ITR to
   commonicate with the ETR that holds the mapping for a particular EID-
   prefix.  This distinction is important when considering the stability
   of BGP on the ALT network as compared to the global routing system.
   It also has implications for how site-specific EID-prefix information
   may be used by LISP but not propagated by LISP+ALT (see Section 7.2
   below).

   RLOC prefixes are not propagated through the ALT so their
   reachability is not determined through use of LISP+ALT.  Instead,
   reachability of RLOCs is learned through the LISP ITR-ETR exchange.
   This means that link failures or other service disruptions that may
   cause the reachability of an RLOC to change are not known to the ALT.
   Changes to the presence of an EID-prefix on the ALT occur much less
   frequently: only at subscription time or in the event of a failure of
   the ALT infrastructure itself.  This means that "flapping" (frequent
   BGP updates and withdrawals due to prefix state changes) is not
   likely and mapping information cannot become "stale" due to slow
   propagation through the ALT BGP mesh.

7.2.  Traffic engineering using LISP

   Since an ITR learns an EID-to-RLOC mapping directly from the ETR that
   owns it, it is possible to perform site-to-site traffic engineering
   by setting the preference and/or weight fields, and by including
   more-specific EID-to-RLOC information in Map-Reply messages.

   This is a powerful mechanism that can conceivably replace the
   traditional practice of routing prefix deaggregation for traffic
   engineering purposes.  Rather than propagating more-specific
   information into the global routing system for local- or regional-
   optimization of traffic flows, such more-specific information can be
   exchanged, through LISP (not LISP+ALT), on an as-needed basis between
   only those ITRs/ETRs (and, thus, site pairs) that need it.  Should a
   receiving ITR decide that it does not wish to store such more-
   specific information, it has the option of discarding it as long as a
   shorter, covering EID-prefix exists.  Such an
   exchange of "more-
   specifics" "more-specifics=
" between sites facilitates traffic
   engineering, by allowing richer and more fine-grained policies to be
   applied without advertising additional prefixes into either the ALT
   or the global routing system.

   Note that these new traffic engineering capabilities are an attribute
   of LISP and are not specific to LISP+ALT; discussion is included here
   because the BGP-based global routing system has traditionally used
   propagation of more-specific routes as a crude form of traffic
   engineering.

7.3.  Edge aggregation and dampening

   Normal BGP best common practices apply to the ALT network.  In
   particular, first-hop ALT Routers will aggregate EID prefixes and
   dampen changes to them in the face of excessive updates.  Since EID-
   prefix assignments are not expected to change as frequently as global
   routing BGP prefix reachability, such dampening should be very rare,
   and might be worthy of logging as an exceptional event.  It is again
   worth noting that the ALT carries only EID-prefixes, used to a
   construct BGP path to each ETR (or Map-Server) that originates each
   prefix; the ALT does not carry reachability about RLOCs.  In
   addition, EID-prefix information may be aggregated as the topology
   and address assignment hierarchy allow.  Since the topology is all
   tunneled and can be modified as needed, reasonably good aggregation
   should be possible.  In addition, since most ETRs are expected to
   connect to the ALT using the Map Server interface, Map Servers will
   implement a natural "edge" for the ALT where dampening and
   aggregation can be applied.  For these reasons, the set of prefix
   information on the ALT can be expected to be both better aggregated
   and considerably less volatile than the actual EID-to-RLOC mappings.

7.4.  EID assignment flexibility vs. ALT scaling

   There are major open questions regarding how the ALT will be deployed
   and what organization(s) will operate it.  In a simple, non-
   distributed world, centralized administration of EID prefix
   assignment and ALT network design would facilitate a well- aggregated
   ALT routing system.  Business and other realities will likely result
   in a more complex, distributed system involving multiple levels of
   prefix delegation, multiple operators of parts of the ALT
   infrastructure, and a combination of competition and cooperation
   among the participants.  In addition, re-use of existing IP address
   assignments, both "PI" and "PA", to avoid renumbering when sites
   transition to LISP will further complicate the processes of building
   and operating the ALT.

   A number of conflicting considerations need to be kept in mind when
   designing and building the ALT.  Among them are:

   1.  Target ALT routing state size and level of aggregation.  As
       described in Section 7.1, the ALT should not suffer from some of
       the performance constraints or stability issues as the Internet
       global routing system, so some reasonable level of deaggregation
       and increased number of EID prefixes beyond what might be
       considered ideal should be acceptable.  That said, measures, such
       as tunnel rehoming to preserve aggregation when sites move from
       one mapping provider to another and implementing aggregation at
       multiple levels in the hierarchy to collapse de-aggregation at
       lower levels, should be taken to reduce unnecessary explosion of
       ALT routing state.

   2.  Number of operators of parts of the ALT and how they will be
       organized (hierarchical delegation vs. shared administration).
       This will determine not only how EID prefixes are assigned but
       also how tunnels are configured and how EID prefixes can be
       aggregated between different parts of the ALT.

   3.  Number of connections between different parts of the ALT.  Trade-
       offs will need to be made among resilience, performance, and
       placement of aggregation boundaries.

   4.  EID prefix portability between competing operators of the ALT
       infrastructure.  A significant benefit for an end-site to adopt
       LISP is the availability of EID space that is not tied to a
       specific connectivity provider; it is important to ensure that an
       end site doesn't trade lock-in to a connectivity provider for
       lock-in to a provider of its EID assignment, ALT connectivity, or
       Map Server facilities.

   This is, by no means, an exhaustive list.

   While resolving these issues is beyond the scope of this document,
   the authors recommend that existing distributed resource structures,
   such as the IANA/Regional Internet Registries and the ICANN/Domain
   Registrar, be carefully considered when designing and deploying the
   ALT infrastructure.

8.  Connecting sites to the ALT network

8.1.  ETRs originating information into the ALT

   EID-prefix information is originated into the ALT by three different
   mechanisms:

   Map Server:  In most cases, a site will configure its ETR(s) to
      register with one or more Map Servers (see [LISP-MS]), and does
      not participate directly in the ALT.

   BGP:  For a site requiring complex control over their EID-prefix
      origination into the ALT, an ETR may connect to the LISP+ALT
      overlay network by running BGP to one or more ALT Router(s) over
      tunnel(s).  The ETR advertises reachability for its EID-prefixes
      over these BGP connection(s).  The edge ALT Router(s) that
      receive(s) these prefixes then propagate(s) them into the ALT.
      Here the ETR is simply an BGP peer of ALT Router(s) at the edge of
      the ALT.  Where possible, an ALT Router that receives EID-prefixes
      from an ETR via BGP should aggregate that information.

   Configuration:  One or more ALT Router(s) may be configured to
      originate an EID-prefix on behalf of the non-BGP-speaking ETR that
      is authoritative for a prefix.  As in the case above, the ETR is
      connected to ALT Router(s) using GRE tunnel(s) but rather than BGP
      being used, the ALT Router(s) are configured with what are in
      effect "static routes" for the EID-prefixes "owned" by the ETR.
      The GRE tunnel is used to route Map-Requests to the ETR.

   Note:  in all cases, an ETR may register to multiple Map Servers or
      connect to multiple ALT Routers for the following reasons:

      *  redundancy, so that a particular ETR is still reachable even if
         one path or tunnel is unavailable.

      *  to connect to different parts of the ALT hierarchy if the ETR
         "owns" multiple EID-to-RLOC mappings for EID-prefixes that
         cannot be aggregated by the same ALT Router (i.e. are not
         topologically "close" to each other in the ALT).

8.2.  ITRs Using the ALT

   In the common configuration, an ITR does not need to know anything
   about the ALT, since it sends Map-Requests to one of its configured
   Map-Resolvers (see [LISP-MS]).  There are two exceptional cases:

   Static default:  If a Map Resolver is not available but an ITR is
      adjacent to an ALT Router (either over a common subnet or through
      the use of a tunnel), it can use an ALT Default Route route to
      cause all ALT Datagrams to be sent that ALT Router.  This case is
      expected to be rare.

   Connection to ALT:  A site with complex Internet connectivity needs
      may need more fine-grained distinction between traffic to LISP-
      capable and non-LISP-capable sites.  Such a site may configure
      each of its ITRs to connect directly to the ALT, using a tunnel
      and BGP connection.  In this case, the ITR will receive EID-prefix
      routes from its BGP connection to the ALT Router and will LISP-
      encapsulate and send ALT Datagrams through the tunnel to the ALT
      Router.  Traffic to other destinations may be forwarded (without
      LISP encapsulation) to non-LISP next-hop routers that the ITR
      knows.

      In general, an ITR that connects to the ALT does so only to to ALT
      Routers at the "edge" of the ALT (typically two for redundancy).
      There may, though, be situations where an ITR would connect to
      other ALT Routers to receive additional, shorter path information
      about a portion of the ALT of interest to it.  This can be
      accomplished by establishing GRE tunnels between the ITR and the
      set of ALT Routers with the additional information.  This is a
      purely local policy issue between the ITR and the ALT Routers in
      question.

   As described in [LISP-MS], Map-Resolvers do not accept or forward
   Data Probes; in the rare scenario that an ITR does support and
   originate Data Probes, it must do so using one of the exceptional
   configurations described above.  Note that the use of Data Probes is
   discouraged at this time (see Section 3.3).

9.  IANA Considerations

   This document makes no request of the IANA.

10.  Security Considerations

   LISP+ALT shares many of the security characteristics of BGP.  Its
   security mechanisms are comprised of existing technologies in wide
   operational use today, so securing the ALT should be mostly a matter
   of applying the same technology that is used to secure the BGP-based
   global routing system (see Section 10.3 below).

10.1.  Apparent LISP+ALT Vulnerabilities

   This section briefly lists the known potential vulnerabilities of
   LISP+ALT.

   Mapping Integrity:  Can an attacker insert bogus mappings to black-
      hole (create Denial-of-Service, or DoS attack) or intercept LISP
      data-plane packets?

   ALT Router Availability:  Can an attacker DoS the ALT Routers
      connected to a given ETR?  If a site's ETR cannot advertise its
      EID-to-RLOC mappings, the site is essentially unavailable.

   ITR Mapping/Resources:  Can an attacker force an ITR or ALT Router to
      drop legitimate mapping requests by flooding it with random
      destinations for which it will generate large numbers of Map-
      Requests and fill its mapping cache?  Further study is required to
      see the impact of admission control on the overlay network.

   EID Map-Request Exploits for Reconnaissance:  Can an attacker learn
      about a LISP site's TE policy by sending legitimate mapping
      requests and then observing the RLOC mapping replies?  Is this
      information useful in attacking or subverting peer relationships?
      Note that any public LISP mapping database will have similar data-
      plane reconnaissance issue.

   Scaling of ALT Router Resources:  Paths through the ALT may be of
      lesser bandwidth than more "direct" paths; this may make them more
      prone to high-volume denial-of-service attacks.  For this reason,
      all components of the ALT (ETRs and ALT Routers) should be
      prepared to rate-limit traffic (ALT Datagrams) that could be
      received across the ALT.

   UDP Map-Reply from ETR:  Since Map-Replies are sent directly from the
      ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various
      types of DoS attacks (this is a general property of LISP, not an
      LISP+ALT vulnerability).

   More-specific prefix leakage:  Because EID-prefixes on the ALT are
      expected to be fairly well-aggregated and EID-prefixes propagated
      out to the global Internet (see [LISP-IW] much more so, accidental
      leaking or malicious advertisement of an EID-prefix into the
      global routing system could cause traffic redirection away from a
      LISP site.  This is not really a new problem, though, and its
      solution can only be achieved by much more strict prefix filtering
      and authentication on the global routing system.

10.2.  Survey of LISP+ALT Security Mechanisms

   Explicit peering:  The devices themselves can both prioritize
      incoming packets, as well as potentially do key checks in hardware
      to protect the control plane.

   Use of TCP to connect elements:  This makes it difficult for third
      parties to inject packets.

   Use of HMAC Protected BGP/TCP Connections:  HMAC is used to verify
      message integrity and authenticity, making it nearly impossible
      for third party devices to either insert or modify messages.

   Message Sequence Numbers and Nonce Values in Messages:  This allows
      an ITR to verify that the Map-Reply from an ETR is in response to
      a Map-Request originated by that ITR (this is a general property
      of LISP; LISP+ALT does not change this behavior).

10.3.  Use of new IETF standard BGP Security mechanisms

   LISP+ALT's use of BGP allows the ALT to take advantage of BGP
   security features designed for existing Internet BGP use.  Should the
   Internet community converge on the work currently being done in the
   IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr]
   or soBGP [I-D.white-sobgparchitecture] be implemented and widely-
   deployed, LISP+ALT can readily use these mechanisms to provide
   authentication of EID-prefix origination and EID-to-RLOC mappings.

11.  Acknowledgments

   The authors would like to specially thank J. Noel Chiappa who was a
   key contributer to the design of the LISP-CONS mapping database (many
   ideas from which made their way into LISP+ALT) and who has continued
   to provide invaluable insight as the LISP effort has evolved.  Others
   who have provided valuable contributions include John Zwiebel, Hannu
   Flinck, Amit Jain, John Scudder, and<=
/strike> Scott Brim. Brim, and Jari Arkko.

12.  References

12.1.  Normative References

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

   [LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-09.txt<=
/strike>
              draft-ietf-lisp-ms-12.txt (work in progress), May
              September 2011.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

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

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

12.2.  Informative References

   [I-D.murphy-bgp-secr]
              Murphy, S., "BGP Security Analysis",
              draft-murphy-bgp-secr-04 (work in progress),
              November 2001.

   [I-D.white-sobgparchitecture]
              White, R., "Architecture and Deployment Considerations for
              Secure Origin BGP (soBGP)",
              draft-white-sobgparchitecture-00 (work in progress),
              May 2004.

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

Authors' Addresses

   Vince Fuller
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dino Farinacci
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Dave Meyer
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   Cisco
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com
--1yeeQ81UyVL57Vl7-- From internet-drafts@ietf.org Tue Sep 20 00:15: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 639BE11E8080; Tue, 20 Sep 2011 00:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 30NxADLYK-uQ; Tue, 20 Sep 2011 00:15:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9A811E808B; Tue, 20 Sep 2011 00:15:57 -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: <20110920071557.31221.61134.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2011 00:15:57 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-04.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, 20 Sep 2011 07:15:59 -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-04.txt Pages : 21 Date : 2011-09-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 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-04.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-04.txt From luigi@net.t-labs.tu-berlin.de Tue Sep 20 00:28: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 1205321F84D7 for ; Tue, 20 Sep 2011 00:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.058, 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 3A9uDht8xrS5 for ; Tue, 20 Sep 2011 00:28:15 -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 C1ABF21F8482 for ; Tue, 20 Sep 2011 00:28:14 -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 5669871418C2; Tue, 20 Sep 2011 09:30:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_08AC5063-D508-46B2-A522-573AECFA5C04" From: Luigi Iannone In-Reply-To: Date: Tue, 20 Sep 2011 09:30:38 +0200 Message-Id: <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1244.3) Cc: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 20 Sep 2011 07:28:16 -0000 --Apple-Mail=_08AC5063-D508-46B2-A522-573AECFA5C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fred, On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: [snip] >=20 >> The hidden idea behind the threat draft is "if we do not manage to >> make a system more secured than the current Internet, at least we >> must have a system that is not less secure." >=20 > That's why I said: "But, perhaps a case can be made that > on-path attacks are no more a matter for concern for LISP > than they are for the non-LISP public Internet?". >=20 > Still, if an off-path attacker can spoof the EID source > address even if it cannot spoof the RLOC source address, > the end result is a system that is less secure than the > current Internet - right? Can you explain why?=20 I would say the contrary. If an attacker cannot spoof RLOC it means that = the DFZ is more robust - right? >=20 >>>> One "funny" attack is by spoofing at the same time the EID and >>>> the RLOC. >>>>=20 >>>> Without cryptography, there is no perfect solution to avoid >>>> spoofing. Your example with dynamic RLOC is interesting. >>>> If everything goes well, you should never have a TTL >>>> longer than the RLOC lease time. However, in the case >>>> the RLOC changes before the expiration, you will need >>>> SMR or version change implying the retrieval of the new >>>> mapping. But in this particular case, you also have a >>>> security threat that is a DoS... >>>=20 >>> Do you see a clear way past these and other threats? >>> Will it be the case that LISP and its ilk will be >>> hard to secure and thus difficult to deploy? >>=20 >> I think that by taking care of how LISP is deployed and how >> the features are used, it is possible to achieve the same level >> of security than today. Doing more is possible, but I am not sure >> that people are ready to have to deal with cryptography. For >> example, if you want to protect against spoofing, you can sign >> the packets (or part of) but then you need a way to know the key >> used to sign. >>=20 >> Do you really want to go to that direction? >=20 > Do I really want to go in the direction of requiring > cryptography? I can't answer that unless you first > tell me the intended domain of applicability. I don't > think I have yet seen a use case analysis of the > various scenarios where LISP xTRs and mapping systems > would be deployed and used. There seems to be an > unspoken assumption of deployment "in the public > Internet", but what about Enterprise networks? > What about MANETs? What about aviation networks? > What about tactical military networks? What about > cellular networks? What about home networks? >=20 That is the purpose of the deployment document. http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 Luigi --Apple-Mail=_08AC5063-D508-46B2-A522-573AECFA5C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Fred,

On Sep 19, 2011, at 23:22 , Templin, Fred L = wrote:

[snip]

The hidden idea = behind the threat draft is "if we do not manage = to
make a system more secured = than the current Internet, at least we
must have a system that is not less = secure."

That's why I said: "But, perhaps a case can = be made that
on-path attacks are no more a matter for concern for = LISP
than they are for the non-LISP public Internet?".

Still, = if an off-path attacker can spoof the EID source
address even if it = cannot spoof the RLOC source address,
the end result is a system that = is less secure than the
current Internet - = right?

Can you explain = why? 

I would say the contrary. If an = attacker cannot spoof RLOC it means that the DFZ is more robust - = right?



One "funny" attack is by = spoofing at the same time the EID = and
the = RLOC.

Without = cryptography, there is no perfect solution to = avoid
spoofing. Your example with dynamic RLOC is = interesting.
If = everything goes well, you should never have a = TTL
longer = than the RLOC lease time. However, in the = case
the = RLOC changes before the expiration, you will = need
SMR or = version change implying the retrieval of the = new
mapping.= But in this particular case, you also have = a
security= threat that is a = DoS...

Do you see a clear way past = these and other threats?
Will it be the case that LISP = and its ilk will be
hard to secure and thus = difficult to deploy?

I think that by = taking care of how LISP is deployed and how
the features are used, it is possible to achieve the same = level
of security than today. = Doing more is possible, but I am not sure
that people are ready to have to deal with cryptography. = For
example, if you want to = protect against spoofing, you can sign
the packets (or part of) but then you need a way to know = the key
used to = sign.

Do you really = want to go to that direction?

Do I really want to go = in the direction of requiring
cryptography? I can't answer that = unless you first
tell me the intended domain of applicability. I = don't
think I have yet seen a use case analysis of the
various = scenarios where LISP xTRs and mapping systems
would be deployed and = used. There seems to be an
unspoken assumption of deployment "in the = public
Internet", but what about Enterprise networks?
What about = MANETs? What about aviation networks?
What about tactical military = networks? What about
cellular networks? What about home = networks?


That is the = purpose of the deployment document.


<= div>Luigi

= --Apple-Mail=_08AC5063-D508-46B2-A522-573AECFA5C04-- From iesg-secretary@ietf.org Tue Sep 20 07:47: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 B3C1F21F8C33; Tue, 20 Sep 2011 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 GgNeI6Uh2Esl; Tue, 20 Sep 2011 07:47:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2466A21F8A71; Tue, 20 Sep 2011 07:47:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110920144715.15182.47983.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2011 07:47:15 -0700 Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP Alternative Topology (LISP+ALT)) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 20 Sep 2011 14:47:15 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Alternative Topology (LISP+ALT)' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-alt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-alt/ No IPR declarations have been submitted directly on this I-D. From Fred.L.Templin@boeing.com Tue Sep 20 08:19:28 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 34B4911E8086 for ; Tue, 20 Sep 2011 08:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 drEPXfL3+ox8 for ; Tue, 20 Sep 2011 08:19:27 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2671B11E8083 for ; Tue, 20 Sep 2011 08:19:26 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8KFLfEO024494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Sep 2011 08:21:42 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p8KFLe35024551; Tue, 20 Sep 2011 10:21:40 -0500 (CDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8KFLdfY024530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 20 Sep 2011 10:21:40 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 20 Sep 2011 08:21:39 -0700 From: "Templin, Fred L" To: Luigi Iannone Date: Tue, 20 Sep 2011 08:21:38 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: Acx3ZzdlEcsSmClATcKDNAo7ckmPJQAP9F3Q Message-ID: References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> In-Reply-To: <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C77282413XCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 20 Sep 2011 15:19:28 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C77282413XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Luigi, I really, really hate trying to annotate things when people turn them into html instead of leaving them as plaintext. But since you insist: ________________________________ From: Luigi Iannone [mailto:luigi@net.t-labs.tu-berlin.de] Sent: Tuesday, September 20, 2011 12:31 AM To: Templin, Fred L Cc: Damien Saucez; lisp@ietf.org Subject: Re: [lisp] Source address spoofing by a node pretending to be an I= TR? Hi Fred, On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: [snip] The hidden idea behind the threat draft is "if we do not manage to make a system more secured than the current Internet, at least we must have a system that is not less secure." That's why I said: "But, perhaps a case can be made that on-path attacks are no more a matter for concern for LISP than they are for the non-LISP public Internet?". Still, if an off-path attacker can spoof the EID source address even if it cannot spoof the RLOC source address, the end result is a system that is less secure than the current Internet - right? Can you explain why? I would say the contrary. If an attacker cannot spoof RLOC it means that th= e DFZ is more robust - right? Ingress filtering can prevent the spoofing of an RLOC, but not necessarily the spoofing of an EID. If a middlebox produces packets that have correct RLOCs but incorrect EIDs, and if the ETR accepts them, then a reflection attack is enabled. One "funny" attack is by spoofing at the same time the EID and the RLOC. Without cryptography, there is no perfect solution to avoid spoofing. Your example with dynamic RLOC is interesting. If everything goes well, you should never have a TTL longer than the RLOC lease time. However, in the case the RLOC changes before the expiration, you will need SMR or version change implying the retrieval of the new mapping. But in this particular case, you also have a security threat that is a DoS... Do you see a clear way past these and other threats? Will it be the case that LISP and its ilk will be hard to secure and thus difficult to deploy? I think that by taking care of how LISP is deployed and how the features are used, it is possible to achieve the same level of security than today. Doing more is possible, but I am not sure that people are ready to have to deal with cryptography. For example, if you want to protect against spoofing, you can sign the packets (or part of) but then you need a way to know the key used to sign. Do you really want to go to that direction? Do I really want to go in the direction of requiring cryptography? I can't answer that unless you first tell me the intended domain of applicability. I don't think I have yet seen a use case analysis of the various scenarios where LISP xTRs and mapping systems would be deployed and used. There seems to be an unspoken assumption of deployment "in the public Internet", but what about Enterprise networks? What about MANETs? What about aviation networks? What about tactical military networks? What about cellular networks? What about home networks? That is the purpose of the deployment document. http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 >From a brief look, that document appears to have quite a ways to go until it considers a wider variety of use cases such as we have addressed in RANGERS. The document also seems to carefully step around the MTU issue, as if it were a booby trap to be always on guard for. IRON (with SEAL) *solves* the MTU issue so that there is no longer any need to worry about it. Until LISP truly addresses the MTU issue (including accounting for the common case of operators misconfiguring link MTUs) all LISP-related documents will have to carefully dance around it. Fred fred.l.templin@boeing.com Luigi --_000_E1829B60731D1740BB7A0626B4FAF0A65C77282413XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Luigi,
 
I really, really hate trying to annotate things wh= en people=20 turn them
into html instead of leaving them as plaintext. Bu= t since=20 you insist:

From: Luigi Iannone=20 [mailto:luigi@net.t-labs.tu-berlin.de]
Sent: Tuesday, Septembe= r 20,=20 2011 12:31 AM
To: Templin, Fred L
Cc: Damien Saucez;= =20 lisp@ietf.org
Subject: Re: [lisp] Source address spoofing by a = node=20 pretending to be an ITR?

Hi Fred,

On Sep 19, 2011, at 23:22 , Templin, Fred L wrote:

[snip]
The hidden idea behind the threat draft is "i= f we=20 do not manage to
make a system more secured than the current=20 Internet, at least we
must have a system that is not less=20 secure."

That's why I said: "But, perhaps a case ca= n be=20 made that
on-path attacks are no more a matter for concern for=20 LISP
than they are for the non-LISP public Internet?".

Still,= if=20 an off-path attacker can spoof the EID source
address even if it can= not=20 spoof the RLOC source address,
the end result is a system that is le= ss=20 secure than the
current Internet - right?

Can you explain why? 

I would say the contrary. If an attacker cannot spoof RLOC it means = that=20 the DFZ is more robust - right?<= FONT=20 size=3D2> 
 
=
Ingress filtering can prevent the spoofing of an= RLOC,=20 but not necessarily
the spoofing of an EID. If a middlebox produces = packets=20 that have correct
RLOCs but incorrect EIDs, and if the ETR accepts= them,=20 then a reflection

= --Apple-Mail=_E0C98E74-B3BE-4160-893B-AC62EFFAC089-- From jmh@joelhalpern.com Tue Sep 20 10:23: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 6BBA911E80B8 for ; Tue, 20 Sep 2011 10:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 ERSFMoehiz7U for ; Tue, 20 Sep 2011 10:23:11 -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 C48CB11E8073 for ; Tue, 20 Sep 2011 10:23:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2EBD24300A4; Tue, 20 Sep 2011 10:25:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-175.clppva.btas.verizon.net [71.161.51.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 8622E4300D0; Tue, 20 Sep 2011 10:25:27 -0700 (PDT) Message-ID: <4E78CC81.80507@joelhalpern.com> Date: Tue, 20 Sep 2011 13:25:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Luigi Iannone References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> <3901ED5D-BC5C-4C0D-B859-1FAF5510EDB5@net.t-labs.tu-berlin.de> In-Reply-To: <3901ED5D-BC5C-4C0D-B859-1FAF5510EDB5@net.t-labs.tu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 20 Sep 2011 17:23:12 -0000 I believe his point is that 1) We have a bunch of efforts to prevent spoofed source IP addresses (RLOCs) in the net today. No tehy don't work perfectly, but we are working on improving them. Assume for discussion they work. 2) In the pwesence of LISP, under a variety of circumstances, it is possible to get a packet with an apparently valid source RLOC (ITR IP address) but a false Source EID. 3) If this message is one which provokes a response, it can become an attack on the spoofed inner EID. In particular, if the responses are noticeably large than the requests, it becomes an amplifying reflection attack. I believe we already have some text noting this. It is an unfortunate consequence of the system. There are mechanisms that can be used to ameliorate this, and I would hope that part of the experiment will be to determine the relative costs and benefits of these mechanisms. Yours, Joel On 9/20/2011 1:06 PM, Luigi Iannone wrote: > Hi Fred, > > thanks for the effort…. > > About your middle box example, why this example is different any other > reflection attack? > > The middle box must be somewhere in the network so that its traffic is > not filtered due to the use of a specific source RLOC. > > But in that case you do not need LISP to carry out a reflection attack. > Hence LISP does not introduce any security hole. > > Or I misunderstand something? > > Luigi > > > > On Sep 20, 2011, at 17:21 , Templin, Fred L wrote: > >> Luigi, >> I really, really hate trying to annotate things when people turn them >> into html instead of leaving them as plaintext. But since you insist: >> >> *From:* Luigi Iannone [mailto:luigi@net.t-labs.tu-berlin.de] >> *Sent:* Tuesday, September 20, 2011 12:31 AM >> *To:* Templin, Fred L >> *Cc:* Damien Saucez; lisp@ietf.org >> *Subject:* Re: [lisp] Source address spoofing by a node pretending >> to be an ITR? >> >> Hi Fred, >> >> On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: >> >> [snip] >>> >>>> The hidden idea behind the threat draft is "if we do not manage to >>>> make a system more secured than the current Internet, at least we >>>> must have a system that is not less secure." >>> >>> That's why I said: "But, perhaps a case can be made that >>> on-path attacks are no more a matter for concern for LISP >>> than they are for the non-LISP public Internet?". >>> >>> Still, if an off-path attacker can spoof the EID source >>> address even if it cannot spoof the RLOC source address, >>> the end result is a system that is less secure than the >>> current Internet - right? >> >> Can you explain why? >> >> I would say the contrary. If an attacker cannot spoof RLOC it >> means that the DFZ is more robust - right? >> >> Ingress filtering can prevent the spoofing of an RLOC, but not >> necessarily >> the spoofing of an EID. If a middlebox produces packets that have correct >> RLOCs but incorrect EIDs, and if the ETR accepts them, then a reflection >> attack is enabled. >> >>> >>>>>> One "funny" attack is by spoofing at the same time the EID and >>>>>> the RLOC. >>>>>> >>>>>> Without cryptography, there is no perfect solution to avoid >>>>>> spoofing. Your example with dynamic RLOC is interesting. >>>>>> If everything goes well, you should never have a TTL >>>>>> longer than the RLOC lease time. However, in the case >>>>>> the RLOC changes before the expiration, you will need >>>>>> SMR or version change implying the retrieval of the new >>>>>> mapping. But in this particular case, you also have a >>>>>> security threat that is a DoS... >>>>> >>>>> Do you see a clear way past these and other threats? >>>>> Will it be the case that LISP and its ilk will be >>>>> hard to secure and thus difficult to deploy? >>>> >>>> I think that by taking care of how LISP is deployed and how >>>> the features are used, it is possible to achieve the same level >>>> of security than today. Doing more is possible, but I am not sure >>>> that people are ready to have to deal with cryptography. For >>>> example, if you want to protect against spoofing, you can sign >>>> the packets (or part of) but then you need a way to know the key >>>> used to sign. >>>> >>>> Do you really want to go to that direction? >>> >>> Do I really want to go in the direction of requiring >>> cryptography? I can't answer that unless you first >>> tell me the intended domain of applicability. I don't >>> think I have yet seen a use case analysis of the >>> various scenarios where LISP xTRs and mapping systems >>> would be deployed and used. There seems to be an >>> unspoken assumption of deployment "in the public >>> Internet", but what about Enterprise networks? >>> What about MANETs? What about aviation networks? >>> What about tactical military networks? What about >>> cellular networks? What about home networks? >>> >> >> That is the purpose of the deployment document. >> >> http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 >> >> From a brief look, that document appears to have quite a ways to >> go until it considers a wider variety of use cases such as we have >> addressed in RANGERS. The document also seems to carefully >> step around the MTU issue, as if it were a booby trap to be always >> on guard for . IRON (with SEAL) *solves* the MTU issue so that >> there is no longer any need to worry about it. Until LISP truly >> addresses the MTU issue (including accounting for the common >> case of operators misconfiguring link MTUs) all LISP-related >> documents will have to carefully dance around it. >> Fred >> fred.l.templin@boeing.com >> >> >> Luigi >> > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From Fred.L.Templin@boeing.com Tue Sep 20 11:04: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 354F01F0C43 for ; Tue, 20 Sep 2011 11:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 qYQCCS99U0KI for ; Tue, 20 Sep 2011 11:04:48 -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 5079F1F0C3D for ; Tue, 20 Sep 2011 11:04:48 -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 p8KI79wE010860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Sep 2011 13:07:10 -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 p8KI78FQ002200; Tue, 20 Sep 2011 11:07:08 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8KI78ee002181 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 20 Sep 2011 11:07:08 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 20 Sep 2011 11:07:08 -0700 From: "Templin, Fred L" To: "Joel M. Halpern" , Luigi Iannone Date: Tue, 20 Sep 2011 11:07:07 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: Acx3ulFp+Hlk5ZnTR+e+PPbyqdQ4/AABVYTw Message-ID: References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> <3901ED5D-BC5C-4C0D-B859-1FAF5510EDB5@net.t-labs.tu-berlin.de> <4E78CC81.80507@joelhalpern.com> In-Reply-To: <4E78CC81.80507@joelhalpern.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: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 20 Sep 2011 18:04:49 -0000 Hi Joel, > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 > Sent: Tuesday, September 20, 2011 10:25 AM > To: Luigi Iannone > Cc: Templin, Fred L; lisp@ietf.org > Subject: Re: [lisp] Source address spoofing by a node=20 > pretending to be an ITR? >=20 > I believe his point is that > 1) We have a bunch of efforts to prevent spoofed source IP addresses=20 > (RLOCs) in the net today. No tehy don't work perfectly, but we are=20 > working on improving them. Assume for discussion they work. > 2) In the pwesence of LISP, under a variety of circumstances, it is=20 > possible to get a packet with an apparently valid source RLOC (ITR IP=20 > address) but a false Source EID. > 3) If this message is one which provokes a response, it can become an=20 > attack on the spoofed inner EID. In particular, if the responses are=20 > noticeably large than the requests, it becomes an amplifying=20 > reflection=20 > attack. That's correct. And, depending on the links on the path to the target a successful attack could truly clog some arteries. > I believe we already have some text noting this. It is an=20 > unfortunate=20 > consequence of the system. There are mechanisms that can be used to=20 > ameliorate this, and I would hope that part of the experiment=20 > will be to=20 > determine the relative costs and benefits of these mechanisms. OK. The IRON family already has a solution which may or may not be adaptable for LISP. The IRON family also has a solution for MTU, which again may of may not be adaptable for LISP. Thanks - Fred fred.l.templin@boeing.com > Yours, > Joel >=20 > On 9/20/2011 1:06 PM, Luigi Iannone wrote: > > Hi Fred, > > > > thanks for the effort.... > > > > About your middle box example, why this example is=20 > different any other > > reflection attack? > > > > The middle box must be somewhere in the network so that its=20 > traffic is > > not filtered due to the use of a specific source RLOC. > > > > But in that case you do not need LISP to carry out a=20 > reflection attack. > > Hence LISP does not introduce any security hole. > > > > Or I misunderstand something? > > > > Luigi > > > > > > > > On Sep 20, 2011, at 17:21 , Templin, Fred L wrote: > > > >> Luigi, > >> I really, really hate trying to annotate things when=20 > people turn them > >> into html instead of leaving them as plaintext. But since=20 > you insist: > >> > >> *From:* Luigi Iannone [mailto:luigi@net.t-labs.tu-berlin.de] > >> *Sent:* Tuesday, September 20, 2011 12:31 AM > >> *To:* Templin, Fred L > >> *Cc:* Damien Saucez; lisp@ietf.org > >> *Subject:* Re: [lisp] Source address spoofing by a=20 > node pretending > >> to be an ITR? > >> > >> Hi Fred, > >> > >> On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: > >> > >> [snip] > >>> > >>>> The hidden idea behind the threat draft is "if we do=20 > not manage to > >>>> make a system more secured than the current=20 > Internet, at least we > >>>> must have a system that is not less secure." > >>> > >>> That's why I said: "But, perhaps a case can be made that > >>> on-path attacks are no more a matter for concern for LISP > >>> than they are for the non-LISP public Internet?". > >>> > >>> Still, if an off-path attacker can spoof the EID source > >>> address even if it cannot spoof the RLOC source address, > >>> the end result is a system that is less secure than the > >>> current Internet - right? > >> > >> Can you explain why? > >> > >> I would say the contrary. If an attacker cannot spoof RLOC it > >> means that the DFZ is more robust - right? > >> > >> Ingress filtering can prevent the spoofing of an RLOC, but not > >> necessarily > >> the spoofing of an EID. If a middlebox produces packets=20 > that have correct > >> RLOCs but incorrect EIDs, and if the ETR accepts them,=20 > then a reflection > >> attack is enabled. > >> > >>> > >>>>>> One "funny" attack is by spoofing at the same time=20 > the EID and > >>>>>> the RLOC. > >>>>>> > >>>>>> Without cryptography, there is no perfect solution to avoid > >>>>>> spoofing. Your example with dynamic RLOC is interesting. > >>>>>> If everything goes well, you should never have a TTL > >>>>>> longer than the RLOC lease time. However, in the case > >>>>>> the RLOC changes before the expiration, you will need > >>>>>> SMR or version change implying the retrieval of the new > >>>>>> mapping. But in this particular case, you also have a > >>>>>> security threat that is a DoS... > >>>>> > >>>>> Do you see a clear way past these and other threats? > >>>>> Will it be the case that LISP and its ilk will be > >>>>> hard to secure and thus difficult to deploy? > >>>> > >>>> I think that by taking care of how LISP is deployed and how > >>>> the features are used, it is possible to achieve the=20 > same level > >>>> of security than today. Doing more is possible, but=20 > I am not sure > >>>> that people are ready to have to deal with cryptography. For > >>>> example, if you want to protect against spoofing,=20 > you can sign > >>>> the packets (or part of) but then you need a way to=20 > know the key > >>>> used to sign. > >>>> > >>>> Do you really want to go to that direction? > >>> > >>> Do I really want to go in the direction of requiring > >>> cryptography? I can't answer that unless you first > >>> tell me the intended domain of applicability. I don't > >>> think I have yet seen a use case analysis of the > >>> various scenarios where LISP xTRs and mapping systems > >>> would be deployed and used. There seems to be an > >>> unspoken assumption of deployment "in the public > >>> Internet", but what about Enterprise networks? > >>> What about MANETs? What about aviation networks? > >>> What about tactical military networks? What about > >>> cellular networks? What about home networks? > >>> > >> > >> That is the purpose of the deployment document. > >> > >> http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 > >> > >> From a brief look, that document appears to have quite a ways to > >> go until it considers a wider variety of use cases such as we have > >> addressed in RANGERS. The document also seems to carefully > >> step around the MTU issue, as if it were a booby trap to be always > >> on guard for . IRON (with SEAL) *solves* the MTU issue so that > >> there is no longer any need to worry about it. Until LISP truly > >> addresses the MTU issue (including accounting for the common > >> case of operators misconfiguring link MTUs) all LISP-related > >> documents will have to carefully dance around it. > >> Fred > >> fred.l.templin@boeing.com > >> > >> > >> Luigi > >> > > > > > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > = From ljakab@ac.upc.edu Wed Sep 21 07:47: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 73CA321F8B8E for ; Wed, 21 Sep 2011 07:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, 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 a-h18JRucriS for ; Wed, 21 Sep 2011 07:47:26 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id A50A821F8B8D for ; Wed, 21 Sep 2011 07:47:25 -0700 (PDT) Received: from [147.83.34.118] (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id 0F5E36B0245; Wed, 21 Sep 2011 16:49:52 +0200 (CEST) Message-ID: <4E79F990.30600@ac.upc.edu> Date: Wed, 21 Sep 2011 16:49:52 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: "Templin, Fred L" References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> In-Reply-To: OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-deployment@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 21 Sep 2011 14:47:26 -0000 Hi Fred, On 09/20/11 17:21, Templin, Fred L wrote: > >> Do I really want to go in the direction of requiring >> cryptography? I can't answer that unless you first >> tell me the intended domain of applicability. I don't >> think I have yet seen a use case analysis of the >> various scenarios where LISP xTRs and mapping systems >> would be deployed and used. There seems to be an >> unspoken assumption of deployment "in the public >> Internet", but what about Enterprise networks? >> What about MANETs? What about aviation networks? >> What about tactical military networks? What about >> cellular networks? What about home networks? >> > > That is the purpose of the deployment document. > > http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 > > > From a brief look, that document appears to have quite a ways to > go until it considers a wider variety of use cases such as we have > addressed in RANGERS. We know of other interesting use cases for LISP, but so far only documented the ones related to DFZ size, to stay on the WG charter. > The document also seems to carefully > step around the MTU issue, as if it were a booby trap to be always > on guard for. IRON (with SEAL) *solves* the MTU issue so that > there is no longer any need to worry about it. Until LISP truly > addresses the MTU issue (including accounting for the common > case of operators misconfiguring link MTUs) all LISP-related > documents will have to carefully dance around it. The main spec discusses two possible solutions to MTU issues in Section 5.4. I think we need more experimentation with LISP to discuss it at more detail in a deployment document (we do call attention to it at the end of Section 2.1). Best regards, Lorand Jakab From Fred.L.Templin@boeing.com Wed Sep 21 14:20: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 7BC0A11E815C for ; Wed, 21 Sep 2011 14:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 GKmlVPcbewmt for ; Wed, 21 Sep 2011 14:20:14 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id C913311E815B for ; Wed, 21 Sep 2011 14:20:14 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8LLMHXu010228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Sep 2011 14:22:21 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p8LLMHwL001337; Wed, 21 Sep 2011 16:22:17 -0500 (CDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8LLMFwn001285 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 21 Sep 2011 16:22:16 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 21 Sep 2011 14:22:15 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?Lor=E1nd_Jakab?= Date: Wed, 21 Sep 2011 14:22:14 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: Acx4bccNAmvRUi8lQPKUprMo36ANPAAM8yHw Message-ID: References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> <4E79F990.30600@ac.upc.edu> In-Reply-To: <4E79F990.30600@ac.upc.edu> Accept-Language: en-US Content-Language: en-US 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-deployment@tools.ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 21 Sep 2011 21:20:15 -0000 Hi Lorand,=20 > -----Original Message----- > From: Lor=E1nd Jakab [mailto:ljakab@ac.upc.edu]=20 > Sent: Wednesday, September 21, 2011 7:50 AM > To: Templin, Fred L > Cc: lisp@ietf.org; draft-ietf-lisp-deployment@tools.ietf.org > Subject: Re: [lisp] Source address spoofing by a node=20 > pretending to be an ITR? >=20 > Hi Fred, >=20 > On 09/20/11 17:21, Templin, Fred L wrote: > > > >> Do I really want to go in the direction of requiring > >> cryptography? I can't answer that unless you first > >> tell me the intended domain of applicability. I don't > >> think I have yet seen a use case analysis of the > >> various scenarios where LISP xTRs and mapping systems > >> would be deployed and used. There seems to be an > >> unspoken assumption of deployment "in the public > >> Internet", but what about Enterprise networks? > >> What about MANETs? What about aviation networks? > >> What about tactical military networks? What about > >> cellular networks? What about home networks? > >> > > > > That is the purpose of the deployment document. > > > > http://tools.ietf.org/html/draft-ietf-lisp-deployment-01=20 > > =20 > > > > From a brief look, that document appears to have quite a ways to > > go until it considers a wider variety of use cases such as we have > > addressed in RANGERS. >=20 > We know of other interesting use cases for LISP, but so far only > documented the ones related to DFZ size, to stay on the WG charter. OK. It would be interesting to note the areas of overlap and mutual exclusion between the LISP and IRON domains of applicability. > > The document also seems to carefully > > step around the MTU issue, as if it were a booby trap to be always > > on guard for. IRON (with SEAL) *solves* the MTU issue so that > > there is no longer any need to worry about it. Until LISP truly > > addresses the MTU issue (including accounting for the common > > case of operators misconfiguring link MTUs) all LISP-related > > documents will have to carefully dance around it. >=20 > The main spec discusses two possible solutions to MTU issues=20 > in Section > 5.4. I think we need more experimentation with LISP to discuss it at > more detail in a deployment document (we do call attention to=20 > it at the > end of Section 2.1). And also in Sections 2.2, 2.3, 2.4 and 2.6. That is quite a bit of deliberation about MTU, and I think goes to show the degree of uncertainty in the main document's approach even before an experiment is conducted. So what makes more sense? To go forward with a "slacker's" approach that is riddled with doubts which might not even be satisfied through extensive experimentation, or to adopt a lightweight mechanism from IRON/SEAL that stands a good chance of erasing all doubts?=20 Thanks - Fred fred.l.templin@boeing.com > Best regards, > Lorand Jakab >=20 > = From terry.manderson@icann.org Wed Sep 21 16:34:00 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 E702A1F0C59 for ; Wed, 21 Sep 2011 16:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.31 X-Spam-Level: X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 yADsjhtJWqY0 for ; Wed, 21 Sep 2011 16:34:00 -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 7E20A1F0C56 for ; Wed, 21 Sep 2011 16:34:00 -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, 21 Sep 2011 16:36:30 -0700 From: Terry Manderson To: "Templin, Fred L" , =?iso-8859-1?Q?Lor=E1nd_Jakab?= Date: Wed, 21 Sep 2011 16:36:28 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: Acx4bccNAmvRUi8lQPKUprMo36ANPAAM8yHwAAVtRPY= 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 Cc: "draft-ietf-lisp-deployment@tools.ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 21 Sep 2011 23:34:01 -0000 Hi Fred, Working group co-chair safari jacket on. On 22/09/11 7:22 AM, "Templin, Fred L" wrote: >=20 > And also in Sections 2.2, 2.3, 2.4 and 2.6. That is > quite a bit of deliberation about MTU, and I think > goes to show the degree of uncertainty in the main > document's approach even before an experiment is > conducted. Surely that is why the LISP documents are moving forward as experimental. I don't think anyone is deluded to think that all of the answers are provided= , and if they are - send them my way in Taipei for a chat. However in my read of the documents every time I thought "What about ...?" there existed some words to identify it as an issue for investigation or consideration during experimental deployment. Uncertainty is, I think, justifiable here.. To take an absolute stance that any implementation is free from hazards is known well in the IETF as folly (aside: yet many repeat the lesson). >=20 > So what makes more sense? To go forward with a > "slacker's" approach that is riddled with doubts ?? really?=20 I appreciate that you have a strong opinion, although please omit subjectiv= e nouns from your posts. I fail to see how that adds to the technical discussion. > which might not even be satisfied through extensive > experimentation, or to adopt a lightweight mechanism > from IRON/SEAL that stands a good chance of erasing > all doubts? >=20 Cheers Terry From terry.manderson@icann.org Wed Sep 21 17:02: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 E411F11E8080 for ; Wed, 21 Sep 2011 17:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 K076fimdutyk for ; Wed, 21 Sep 2011 17:02:20 -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 4900821F8CF8 for ; Wed, 21 Sep 2011 17:02:20 -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; Wed, 21 Sep 2011 17:04:50 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Wed, 21 Sep 2011 17:04:48 -0700 Thread-Topic: LISP (re-)Charter discussion Thread-Index: Acx4uz3s1/gPJmaQPEa2DzHbfsdlYw== 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] 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, 22 Sep 2011 00:02:21 -0000 Hi Folks, In Prague there was no strong consensus on modifying the LISP Charter from what it currently is, perhaps only updating the existing Goals/Milestones. So no clear decision could be made. What I would like to do is push out a 'idea generating' draft charter that is _almost_ identical to what we have today.=20 You can find the existing charter here: https://datatracker.ietf.org/wg/lisp/charter/ The draft is below. So in light of such an approach, Joel and I discussed some work items that came from what was said at the mic in Prague and to us individually. They are: * Finish the deployment document * Get the two security documents done * Get an operational document at least started, which should include cache management and ETR synchronization techniques. * Either in the second security document, or in complementary documents we need to evaluate the security threat to cache maintenance, and evaluate the applicability and coverage we get from a reuse of SIDR technology. Is anything not represented here that you believe necessary? and conversely is there something here that is out of scope in your eyes? Are there work areas not covered by the draft below which you believe shoul= d be? Draft Charter ------------ 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 the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. 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 the ALT and/or other 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. Cheers Terry From dino@cisco.com Wed Sep 21 18:27: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 F05AB1F0C57 for ; Wed, 21 Sep 2011 18:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=-0.773, 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 X2R7CXmXxlR1 for ; Wed, 21 Sep 2011 18:27:35 -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 622011F0C3B for ; Wed, 21 Sep 2011 18:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=640; q=dns/txt; s=iport; t=1316655005; x=1317864605; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=64QLe1fkpcTn/hafWyVNfqp1/Iin75YRefWyqBI1To8=; b=MtN9WYaN/zv1ZtM5T1Czf7HV5IwglOGWdMLz5LxgrroCbw1J4E7AM1v2 01/EdkX9qf0OOubXLLsHTLo3WdO1O/tSIXmV8YWLp8hHbnBTJV3DbQ5DX d0f+28x7MIi4iNfKn7ECo4IpcHWfvpab0n6x0NekFjKCkFzvDF8CitOpY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIWOek6rRDoG/2dsb2JhbABCp254gVMBAQEBAgESAWYFCwtGVwY1h1WWTwGeK4YdYASHcItdkU8 X-IronPort-AV: E=Sophos;i="4.68,420,1312156800"; d="scan'208";a="3547254" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 22 Sep 2011 01:30:05 +0000 Received: from sjc-vpn3-778.cisco.com (sjc-vpn3-778.cisco.com [10.21.67.10]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8M1U5Zj001911; Thu, 22 Sep 2011 01:30:05 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Wed, 21 Sep 2011 18:30:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65947096-16FC-4D66-A4AD-1E5606EB6E60@cisco.com> References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> <4E79F990.30600@ac.upc.edu> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1244.3) Cc: "draft-ietf-lisp-deployment@tools.ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 22 Sep 2011 01:27:36 -0000 > And also in Sections 2.2, 2.3, 2.4 and 2.6. That is > quite a bit of deliberation about MTU, and I think > goes to show the degree of uncertainty in the main > document's approach even before an experiment is > conducted. >=20 > So what makes more sense? To go forward with a > "slacker's" approach that is riddled with doubts > which might not even be satisfied through extensive > experimentation, or to adopt a lightweight mechanism > from IRON/SEAL that stands a good chance of erasing > all doubts?=20 There are no doubts or uncertainty. The text is written to satisfy all = commenters, that is a compromise. Dino From ljakab@ac.upc.edu Thu Sep 22 00:02: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 435E321F8C9A for ; Thu, 22 Sep 2011 00:02:36 -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 RswByW14-aUc for ; Thu, 22 Sep 2011 00:02:35 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7652121F8C99 for ; Thu, 22 Sep 2011 00:02:35 -0700 (PDT) Received: from [192.168.155.190] (unknown [84.78.182.70]) by gw.ac.upc.edu (Postfix) with ESMTP id 7246A6B0237; Thu, 22 Sep 2011 09:05:04 +0200 (CEST) Message-ID: <4E7ADE21.1030907@ac.upc.edu> Date: Thu, 22 Sep 2011 09:05:05 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: X-OpenPGP-Fingerprint: 5EBC 8566 7524 D711 F210 9D80 954C 0DEF 9071 0D74 X-Philosophy: "Simplicity is the ultimate sophistication." --Leonardo da Vinci Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 22 Sep 2011 07:02:36 -0000 Hi Terry, El 9/22/2011 2:04 AM, Terry Manderson escribió: > [...] > So in light of such an approach, Joel and I discussed some work items that > came from what was said at the mic in Prague and to us individually. > > They are: > > * Finish the deployment document > * Get the two security documents done > * Get an operational document at least started, which should include > cache management and ETR synchronization techniques. > * Either in the second security document, or in complementary documents we > need to evaluate the security threat to cache maintenance, and > evaluate the applicability and coverage we get from a reuse of SIDR > technology. > > Is anything not represented here that you believe necessary? I think it would be interesting to include mobility in the charter as well. The LISP-MN draft is mature and there are some implementations already of that spec. -Lori > and conversely > is there something here that is out of scope in your eyes? > > Are there work areas not covered by the draft below which you believe should > be? From luigi@net.t-labs.tu-berlin.de Thu Sep 22 01:16: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 37D0D21F8C9D for ; Thu, 22 Sep 2011 01:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 DBHCBEtmsisW for ; Thu, 22 Sep 2011 01:16:19 -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 D96EC21F8D1A for ; Thu, 22 Sep 2011 01:16:18 -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 D8F1B70629E9 for ; Thu, 22 Sep 2011 10:18:48 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Luigi Iannone In-Reply-To: <4E78CC81.80507@joelhalpern.com> Date: Thu, 22 Sep 2011 10:18:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0232E616-DF6C-4F6B-AD7D-C6AD114E6E9B@net.t-labs.tu-berlin.de> References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> <3901ED5D-BC5C-4C0D-B859-1FAF5510EDB5@net.t-labs.tu-berlin.de> <4E78CC81.80507@joelhalpern.com> To: lisp@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 22 Sep 2011 08:16:20 -0000 Hi, On Sep 20, 2011, at 19:25 , Joel M. Halpern wrote: > I believe his point is that > 1) We have a bunch of efforts to prevent spoofed source IP addresses = (RLOCs) in the net today. No tehy don't work perfectly, but we are = working on improving them. Assume for discussion they work. > 2) In the pwesence of LISP, under a variety of circumstances, it is = possible to get a packet with an apparently valid source RLOC (ITR IP = address) but a false Source EID. > 3) If this message is one which provokes a response, it can become an = attack on the spoofed inner EID. In particular, if the responses are = noticeably large than the requests, it becomes an amplifying reflection = attack. >=20 Yes I got the point. We have text in the threats draft for this. However, my point was that similar attacks can be carried out without = LISP, so I think that on this side LISP is not opening any new security = threat. Luigi > I believe we already have some text noting this. It is an unfortunate = consequence of the system. There are mechanisms that can be used to = ameliorate this, and I would hope that part of the experiment will be to = determine the relative costs and benefits of these mechanisms. >=20 > Yours, > Joel >=20 > On 9/20/2011 1:06 PM, Luigi Iannone wrote: >> Hi Fred, >>=20 >> thanks for the effort=85. >>=20 >> About your middle box example, why this example is different any = other >> reflection attack? >>=20 >> The middle box must be somewhere in the network so that its traffic = is >> not filtered due to the use of a specific source RLOC. >>=20 >> But in that case you do not need LISP to carry out a reflection = attack. >> Hence LISP does not introduce any security hole. >>=20 >> Or I misunderstand something? >>=20 >> Luigi >>=20 >>=20 >>=20 >> On Sep 20, 2011, at 17:21 , Templin, Fred L wrote: >>=20 >>> Luigi, >>> I really, really hate trying to annotate things when people turn = them >>> into html instead of leaving them as plaintext. But since you = insist: >>>=20 >>> *From:* Luigi Iannone [mailto:luigi@net.t-labs.tu-berlin.de] >>> *Sent:* Tuesday, September 20, 2011 12:31 AM >>> *To:* Templin, Fred L >>> *Cc:* Damien Saucez; lisp@ietf.org >>> *Subject:* Re: [lisp] Source address spoofing by a node = pretending >>> to be an ITR? >>>=20 >>> Hi Fred, >>>=20 >>> On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: >>>=20 >>> [snip] >>>>=20 >>>>> The hidden idea behind the threat draft is "if we do not manage = to >>>>> make a system more secured than the current Internet, at least = we >>>>> must have a system that is not less secure." >>>>=20 >>>> That's why I said: "But, perhaps a case can be made that >>>> on-path attacks are no more a matter for concern for LISP >>>> than they are for the non-LISP public Internet?". >>>>=20 >>>> Still, if an off-path attacker can spoof the EID source >>>> address even if it cannot spoof the RLOC source address, >>>> the end result is a system that is less secure than the >>>> current Internet - right? >>>=20 >>> Can you explain why? >>>=20 >>> I would say the contrary. If an attacker cannot spoof RLOC it >>> means that the DFZ is more robust - right? >>>=20 >>> Ingress filtering can prevent the spoofing of an RLOC, but not >>> necessarily >>> the spoofing of an EID. If a middlebox produces packets that have = correct >>> RLOCs but incorrect EIDs, and if the ETR accepts them, then a = reflection >>> attack is enabled. >>>=20 >>>>=20 >>>>>>> One "funny" attack is by spoofing at the same time the EID = and >>>>>>> the RLOC. >>>>>>>=20 >>>>>>> Without cryptography, there is no perfect solution to avoid >>>>>>> spoofing. Your example with dynamic RLOC is interesting. >>>>>>> If everything goes well, you should never have a TTL >>>>>>> longer than the RLOC lease time. However, in the case >>>>>>> the RLOC changes before the expiration, you will need >>>>>>> SMR or version change implying the retrieval of the new >>>>>>> mapping. But in this particular case, you also have a >>>>>>> security threat that is a DoS... >>>>>>=20 >>>>>> Do you see a clear way past these and other threats? >>>>>> Will it be the case that LISP and its ilk will be >>>>>> hard to secure and thus difficult to deploy? >>>>>=20 >>>>> I think that by taking care of how LISP is deployed and how >>>>> the features are used, it is possible to achieve the same level >>>>> of security than today. Doing more is possible, but I am not = sure >>>>> that people are ready to have to deal with cryptography. For >>>>> example, if you want to protect against spoofing, you can sign >>>>> the packets (or part of) but then you need a way to know the = key >>>>> used to sign. >>>>>=20 >>>>> Do you really want to go to that direction? >>>>=20 >>>> Do I really want to go in the direction of requiring >>>> cryptography? I can't answer that unless you first >>>> tell me the intended domain of applicability. I don't >>>> think I have yet seen a use case analysis of the >>>> various scenarios where LISP xTRs and mapping systems >>>> would be deployed and used. There seems to be an >>>> unspoken assumption of deployment "in the public >>>> Internet", but what about Enterprise networks? >>>> What about MANETs? What about aviation networks? >>>> What about tactical military networks? What about >>>> cellular networks? What about home networks? >>>>=20 >>>=20 >>> That is the purpose of the deployment document. >>>=20 >>> http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 >>>=20 >>> =46rom a brief look, that document appears to have quite a ways to >>> go until it considers a wider variety of use cases such as we have >>> addressed in RANGERS. The document also seems to carefully >>> step around the MTU issue, as if it were a booby trap to be always >>> on guard for . IRON (with SEAL) *solves* the MTU issue so that >>> there is no longer any need to worry about it. Until LISP truly >>> addresses the MTU issue (including accounting for the common >>> case of operators misconfiguring link MTUs) all LISP-related >>> documents will have to carefully dance around it. >>> Fred >>> fred.l.templin@boeing.com >>>=20 >>>=20 >>> Luigi >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From pfrejborg@gmail.com Thu Sep 22 02:03: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 5C7FC21F8B3C for ; Thu, 22 Sep 2011 02:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 t7hMINqfVQJQ for ; Thu, 22 Sep 2011 02:03:46 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1FC21F8B2E for ; Thu, 22 Sep 2011 02:03:46 -0700 (PDT) Received: by wwn22 with SMTP id 22so6322561wwn.1 for ; Thu, 22 Sep 2011 02:06:17 -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; bh=oW5rXiJQAWb3BL6DovDbBw26C1rda2qPq7g2K6KCOFo=; b=MJdLLYvC5p/3noUVg12+na7tG3BGjSOyTivLzCO9s/Zq1NpKZgxdl/EjGgutai0lzt AY10qWBBuge9EH25mGg5f91UB8roBKOpj9NvX3osPWF+uDwRy/P05sZ1r6ZsyTOY0BxF cQNo5ITG+x1S1gt7ljIYlOPgK+5U+QxZq+RN0= MIME-Version: 1.0 Received: by 10.227.10.67 with SMTP id o3mr290990wbo.113.1316682376979; Thu, 22 Sep 2011 02:06:16 -0700 (PDT) Received: by 10.227.181.202 with HTTP; Thu, 22 Sep 2011 02:06:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Sep 2011 12:06:16 +0300 Message-ID: From: Patrick Frejborg To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 22 Sep 2011 09:03:47 -0000 Hi Terry On Thu, Sep 22, 2011 at 3:04 AM, Terry Manderson wrote: > They are: > > * Finish the deployment document > * Get the two security documents done > * Get an operational document at least started, which should include > cache management and ETR synchronization techniques. > * Either in the second security document, or in complementary documents we > need to evaluate the security threat to cache maintenance, and > evaluate the applicability and coverage we get from a reuse of SIDR > technology. > > Is anything not represented here that you believe necessary? and conversely > is there something here that is out of scope in your eyes? > > Are there work areas not covered by the draft below which you believe should > be? > Are there any interest to look further into to future and discuss what is needed to have a long term solution of LISP, as discussed in RFC 1955? This scheme could be extended to not require globally unique IP address. Effectively the combination of AD-Address and IP-Address is the globally unique address. To use this scheme without globally unique IP-Addresses and without changing in the hosts would require a NAT mechanism in the border routers. I think it would be preferable to change the hosts to have them do the DNS query and add the AD- header. This could be the basis for the long term solution. Another interesting aspect of this scheme is that if we were to relax the current architecture where one IP-Address is always in only one AD, to allow an IP-Address to be in more than one AD, it would provide a solution to the issue of allowing a IP entity to get service from more than one service provider. Patrick From Fred.L.Templin@boeing.com Thu Sep 22 07:02: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 9D6E221F8C98 for ; Thu, 22 Sep 2011 07:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 bA0MEFxffcbn for ; Thu, 22 Sep 2011 07:02:37 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 04F1E21F8C94 for ; Thu, 22 Sep 2011 07:02:36 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8ME2Zx9025035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Sep 2011 07:02:35 -0700 (PDT) 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 p8ME2Zni006371; Thu, 22 Sep 2011 07:02:35 -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 p8ME2QRu005878 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Sep 2011 07:02:33 -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; Thu, 22 Sep 2011 07:02:32 -0700 From: "Templin, Fred L" To: Terry Manderson , =?iso-8859-1?Q?Lor=E1nd_Jakab?= Date: Thu, 22 Sep 2011 07:02:32 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: Acx4bccNAmvRUi8lQPKUprMo36ANPAAM8yHwAAVtRPYAHhwawA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US 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-deployment@tools.ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 22 Sep 2011 14:02:37 -0000 Terry, > -----Original Message----- > From: Terry Manderson [mailto:terry.manderson@icann.org]=20 > Sent: Wednesday, September 21, 2011 4:36 PM > To: Templin, Fred L; Lor=E1nd Jakab > Cc: draft-ietf-lisp-deployment@tools.ietf.org; lisp@ietf.org > Subject: Re: [lisp] Source address spoofing by a node=20 > pretending to be an ITR? >=20 > Hi Fred, >=20 > Working group co-chair safari jacket on. If you want to censure me that's one thing, but please don't put on articles of clothing that you do not own. You have a hat. You do not have a big game hunting license. Fred fred.l.templin@boeing.com, > On 22/09/11 7:22 AM, "Templin, Fred L"=20 > wrote: >=20 > >=20 > > And also in Sections 2.2, 2.3, 2.4 and 2.6. That is > > quite a bit of deliberation about MTU, and I think > > goes to show the degree of uncertainty in the main > > document's approach even before an experiment is > > conducted. >=20 > Surely that is why the LISP documents are moving forward as=20 > experimental. I > don't think anyone is deluded to think that all of the=20 > answers are provided, > and if they are - send them my way in Taipei for a chat.=20 > However in my read > of the documents every time I thought "What about ...?" there=20 > existed some > words to identify it as an issue for investigation or=20 > consideration during > experimental deployment. > Uncertainty is, I think, justifiable here.. To take an=20 > absolute stance that > any implementation is free from hazards is known well in the=20 > IETF as folly > (aside: yet many repeat the lesson). >=20 > >=20 > > So what makes more sense? To go forward with a > > "slacker's" approach that is riddled with doubts >=20 > ?? really? > > I appreciate that you have a strong opinion, although please=20 > omit subjective > nouns from your posts. I fail to see how that adds to the technical > discussion. >=20 > > which might not even be satisfied through extensive > > experimentation, or to adopt a lightweight mechanism > > from IRON/SEAL that stands a good chance of erasing > > all doubts? > >=20 >=20 > Cheers > Terry >=20 > = From Fred.L.Templin@boeing.com Thu Sep 22 07:03: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 6ED7121F8C04 for ; Thu, 22 Sep 2011 07:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 gPpnbN-VRQVr for ; Thu, 22 Sep 2011 07:03:26 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8942721F862F for ; Thu, 22 Sep 2011 07:03:26 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8ME5if9012551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Sep 2011 07:05:45 -0700 (PDT) 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 p8ME5i2j016052; Thu, 22 Sep 2011 07:05:44 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8ME5hpg016027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Sep 2011 07:05:44 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 22 Sep 2011 07:05:44 -0700 From: "Templin, Fred L" To: Luigi Iannone , "lisp@ietf.org" Date: Thu, 22 Sep 2011 07:05:42 -0700 Thread-Topic: [lisp] Source address spoofing by a node pretending to be an ITR? Thread-Index: Acx5AEbEAaHzqrcxRuuhi77+0ReYwQAMCSCQ Message-ID: References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> <3901ED5D-BC5C-4C0D-B859-1FAF5510EDB5@net.t-labs.tu-berlin.de> <4E78CC81.80507@joelhalpern.com> <0232E616-DF6C-4F6B-AD7D-C6AD114E6E9B@net.t-labs.tu-berlin.de> In-Reply-To: <0232E616-DF6C-4F6B-AD7D-C6AD114E6E9B@net.t-labs.tu-berlin.de> 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 Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 22 Sep 2011 14:03:27 -0000 Hi Luigi,=20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Luigi Iannone > Sent: Thursday, September 22, 2011 1:19 AM > To: lisp@ietf.org > Subject: Re: [lisp] Source address spoofing by a node=20 > pretending to be an ITR? >=20 > Hi, >=20 > On Sep 20, 2011, at 19:25 , Joel M. Halpern wrote: >=20 > > I believe his point is that > > 1) We have a bunch of efforts to prevent spoofed source IP=20 > addresses (RLOCs) in the net today. No tehy don't work=20 > perfectly, but we are working on improving them. Assume for=20 > discussion they work. > > 2) In the pwesence of LISP, under a variety of=20 > circumstances, it is possible to get a packet with an=20 > apparently valid source RLOC (ITR IP address) but a false Source EID. > > 3) If this message is one which provokes a response, it can=20 > become an attack on the spoofed inner EID. In particular, if=20 > the responses are noticeably large than the requests, it=20 > becomes an amplifying reflection attack. > >=20 >=20 > Yes I got the point. We have text in the threats draft for this. >=20 > However, my point was that similar attacks can be carried out=20 > without LISP, so I think that on this side LISP is not=20 > opening any new security threat. Yes it is; it allows off-path attackers to circumvent ingress filtering of the inner address even if they cannot circumvent ingress filtering of the outer address. Fred fred.l.templin@boeing.com > Luigi >=20 > > I believe we already have some text noting this. It is an=20 > unfortunate consequence of the system. There are mechanisms=20 > that can be used to ameliorate this, and I would hope that=20 > part of the experiment will be to determine the relative=20 > costs and benefits of these mechanisms. > >=20 > > Yours, > > Joel > >=20 > > On 9/20/2011 1:06 PM, Luigi Iannone wrote: > >> Hi Fred, > >>=20 > >> thanks for the effort.... > >>=20 > >> About your middle box example, why this example is=20 > different any other > >> reflection attack? > >>=20 > >> The middle box must be somewhere in the network so that=20 > its traffic is > >> not filtered due to the use of a specific source RLOC. > >>=20 > >> But in that case you do not need LISP to carry out a=20 > reflection attack. > >> Hence LISP does not introduce any security hole. > >>=20 > >> Or I misunderstand something? > >>=20 > >> Luigi > >>=20 > >>=20 > >>=20 > >> On Sep 20, 2011, at 17:21 , Templin, Fred L wrote: > >>=20 > >>> Luigi, > >>> I really, really hate trying to annotate things when=20 > people turn them > >>> into html instead of leaving them as plaintext. But since=20 > you insist: > >>>=20 > >>> *From:* Luigi Iannone [mailto:luigi@net.t-labs.tu-berlin.de] > >>> *Sent:* Tuesday, September 20, 2011 12:31 AM > >>> *To:* Templin, Fred L > >>> *Cc:* Damien Saucez; lisp@ietf.org > >>> *Subject:* Re: [lisp] Source address spoofing by a=20 > node pretending > >>> to be an ITR? > >>>=20 > >>> Hi Fred, > >>>=20 > >>> On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: > >>>=20 > >>> [snip] > >>>>=20 > >>>>> The hidden idea behind the threat draft is "if we do=20 > not manage to > >>>>> make a system more secured than the current=20 > Internet, at least we > >>>>> must have a system that is not less secure." > >>>>=20 > >>>> That's why I said: "But, perhaps a case can be made that > >>>> on-path attacks are no more a matter for concern for LISP > >>>> than they are for the non-LISP public Internet?". > >>>>=20 > >>>> Still, if an off-path attacker can spoof the EID source > >>>> address even if it cannot spoof the RLOC source address, > >>>> the end result is a system that is less secure than the > >>>> current Internet - right? > >>>=20 > >>> Can you explain why? > >>>=20 > >>> I would say the contrary. If an attacker cannot spoof RLOC it > >>> means that the DFZ is more robust - right? > >>>=20 > >>> Ingress filtering can prevent the spoofing of an RLOC, but not > >>> necessarily > >>> the spoofing of an EID. If a middlebox produces packets=20 > that have correct > >>> RLOCs but incorrect EIDs, and if the ETR accepts them,=20 > then a reflection > >>> attack is enabled. > >>>=20 > >>>>=20 > >>>>>>> One "funny" attack is by spoofing at the same time=20 > the EID and > >>>>>>> the RLOC. > >>>>>>>=20 > >>>>>>> Without cryptography, there is no perfect solution to avoid > >>>>>>> spoofing. Your example with dynamic RLOC is interesting. > >>>>>>> If everything goes well, you should never have a TTL > >>>>>>> longer than the RLOC lease time. However, in the case > >>>>>>> the RLOC changes before the expiration, you will need > >>>>>>> SMR or version change implying the retrieval of the new > >>>>>>> mapping. But in this particular case, you also have a > >>>>>>> security threat that is a DoS... > >>>>>>=20 > >>>>>> Do you see a clear way past these and other threats? > >>>>>> Will it be the case that LISP and its ilk will be > >>>>>> hard to secure and thus difficult to deploy? > >>>>>=20 > >>>>> I think that by taking care of how LISP is deployed and how > >>>>> the features are used, it is possible to achieve the=20 > same level > >>>>> of security than today. Doing more is possible, but=20 > I am not sure > >>>>> that people are ready to have to deal with cryptography. For > >>>>> example, if you want to protect against spoofing,=20 > you can sign > >>>>> the packets (or part of) but then you need a way to=20 > know the key > >>>>> used to sign. > >>>>>=20 > >>>>> Do you really want to go to that direction? > >>>>=20 > >>>> Do I really want to go in the direction of requiring > >>>> cryptography? I can't answer that unless you first > >>>> tell me the intended domain of applicability. I don't > >>>> think I have yet seen a use case analysis of the > >>>> various scenarios where LISP xTRs and mapping systems > >>>> would be deployed and used. There seems to be an > >>>> unspoken assumption of deployment "in the public > >>>> Internet", but what about Enterprise networks? > >>>> What about MANETs? What about aviation networks? > >>>> What about tactical military networks? What about > >>>> cellular networks? What about home networks? > >>>>=20 > >>>=20 > >>> That is the purpose of the deployment document. > >>>=20 > >>> http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 > >>>=20 > >>> From a brief look, that document appears to have quite a ways to > >>> go until it considers a wider variety of use cases such as we have > >>> addressed in RANGERS. The document also seems to carefully > >>> step around the MTU issue, as if it were a booby trap to be always > >>> on guard for . IRON (with SEAL) *solves* the MTU issue so that > >>> there is no longer any need to worry about it. Until LISP truly > >>> addresses the MTU issue (including accounting for the common > >>> case of operators misconfiguring link MTUs) all LISP-related > >>> documents will have to carefully dance around it. > >>> Fred > >>> fred.l.templin@boeing.com > >>>=20 > >>>=20 > >>> Luigi > >>>=20 > >>=20 > >>=20 > >>=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 > = From dino@cisco.com Thu Sep 22 10:21:54 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 2FE4921F85D1 for ; Thu, 22 Sep 2011 10:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, J_CHICKENPOX_13=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 M4YFZiVSFtZc for ; Thu, 22 Sep 2011 10:21:53 -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 F24CE21F851F for ; Thu, 22 Sep 2011 10:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=8591; q=dns/txt; s=iport; t=1316712265; x=1317921865; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8ogF3f8Zyv87DMnpj3B7AuHNckU5YWdic3QRHbAELa4=; b=RJuJBXrF/liQxko/+3hIevLEw+c15xtRCgv7Ss39eqdR9SpqxgiIxhrF Qm+wywVq7s55bm1HPVGMViOefs0UISXYXKIhZXWF1OuiZTmAa32F4+cjK h8rzCQu+NKnOUbWNhxF1mK6c2pFdHoZXo93KGABfMQ4KydUIyVNDK3gCN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABdue06rRDoJ/2dsb2JhbAA4CqgBeIFTAQEBAQIBAQEBDwEnLQcGBQULCxI0JyIOBhMbB4dWBpZ5AZ4pg1WCSGAEh3GLX5FP X-IronPort-AV: E=Sophos;i="4.68,424,1312156800"; d="scan'208";a="3703836" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 22 Sep 2011 17:24:24 +0000 Received: from sjc-vpn2-878.cisco.com (sjc-vpn2-878.cisco.com [10.21.115.110]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8MHOOfd005007; Thu, 22 Sep 2011 17:24:24 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: Date: Thu, 22 Sep 2011 10:24:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <64989934-E075-4620-9547-63635173B18B@cisco.com> References: To: Terry Manderson X-Mailer: Apple Mail (2.1244.3) 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: Thu, 22 Sep 2011 17:21:54 -0000 Terry, what I would like to know first and foremost, before adding any = specific feature or use-cases to the charter is if they *should* belong = in the LISP working group charter versus being owne by another working = group. And what the working group thinks about this. I will give some = examples to get some clarity and to be more specific. (1) LISP could be used for many data-center use-cases. (2) LISP could be used for device mobility. (3) LISP could be used as a IPv6 coexistence solution while delivering = route table reduction and low opex multihoming. (4) LISP could be used as a VPN solution. (5) The mapping database could be used for other applications like = keeping track of multicast group membership. So, to enumerate each one: For (1), does the LISP WG take this on or is there a data-center = specific protocol solution working group (ARMD is not that working group = because it is a requirement definition working group)? For (2), the MOBOPTs IRTF research group seem to take interest in = LISP-MN. Does it do the initial work and have it spin off a mobility = working group, which there are many already. To add, there is a = cross-product issue too since LISP-Multicast can run in a LISP-MN = implementation and there is a multimob working group already = established. For (3), there are zillions of solutions and places where this occurs = over the last decade, I would suggest not spinning another working group = for this and have the LISP working group be "address-family" agnostic = which would also include MAC addressing as a address-family as well a = GPS coordinates. For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, as = well as the other 2 combinations, does the VPN use-case stay in the LISP = working group or is it fragmented to be taken to each L2VPN and L3VPN = working groups. For (5), we do not want to error where everything is put into DNS = (because it is the only applicaiton level wide-area/multi-organizational = distributed database). In our case the mapping database. And moreoever, = if the use-case functionality is distributed to other working groups, = will there be design change requests to the mapping database design = coming from too many source points. As you can see, this can get very complex and confusing and could result = in design fragmentation and opportunity for competitive proposals. All = which turn out to add more inefficiencies to the protocol design process = which nearly always results in undeployable compromises. Dino On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote: > Hi Folks, >=20 > In Prague there was no strong consensus on modifying the LISP Charter = from > what it currently is, perhaps only updating the existing = Goals/Milestones. >=20 > So no clear decision could be made. What I would like to do is push = out a > 'idea generating' draft charter that is _almost_ identical to what we = have > today.=20 >=20 > You can find the existing charter here: > https://datatracker.ietf.org/wg/lisp/charter/ >=20 > The draft is below. >=20 > So in light of such an approach, Joel and I discussed some work items = that > came from what was said at the mic in Prague and to us individually. >=20 > They are: >=20 > * Finish the deployment document > * Get the two security documents done > * Get an operational document at least started, which should include > cache management and ETR synchronization techniques. > * Either in the second security document, or in complementary = documents we > need to evaluate the security threat to cache maintenance, and > evaluate the applicability and coverage we get from a reuse of SIDR > technology. >=20 > Is anything not represented here that you believe necessary? and = conversely > is there something here that is out of scope in your eyes? >=20 > Are there work areas not covered by the draft below which you believe = should > be? >=20 > Draft Charter > ------------ >=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 the IRTF and > IETF. At this time, these proposals are at an early stage. All = proposals > (including LISP) have potentially harmful side-effects to Internet > traffic carried by the involved routers, have parts where deployment > incentives may be lacking, and are NOT RECOMMENDED for deployment = beyond > experimental situations at this stage. Many of the proposals have > components (such as the identifier to locator mapping system) where it > is not yet known what kind of design alternative is the best one among > many. >=20 > However, despite these issues it would be valuable to write concrete > protocol specifications and develop implementations that can be used = to > understand the characteristics of these designs. 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 the ALT and/or other 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 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Mon Sep 26 21:14: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 D28925E8003 for ; Mon, 26 Sep 2011 21:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.164 X-Spam-Level: X-Spam-Status: No, score=-106.164 tagged_above=-999 required=5 tests=[AWL=-0.165, 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 ndd3LthBSFJQ for ; Mon, 26 Sep 2011 21:14:21 -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 D70B55E8002 for ; Mon, 26 Sep 2011 21:14:21 -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, 26 Sep 2011 21:17:06 -0700 From: Terry Manderson To: Dino Farinacci Date: Mon, 26 Sep 2011 21:17:02 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx5TIaevaA3w2i0T9e8wLpgRLaj2gDf8fv2 Message-ID: In-Reply-To: <64989934-E075-4620-9547-63635173B18B@cisco.com> 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, 27 Sep 2011 04:14:22 -0000 Thanks Dino, I encourage all LISP WG members to reflect on the questions below and voice an opinion. To paraphrase what Dino has written, one proposal (and Dino correct me if I've oversimplified) is that the LISP WG should become a working group that contains ALL things LISP. So wherever a body of work uses LISP encapsulation, or LISP mapping it may gravitate to here to maintain LISP interoperability and (where appropriate) protocol cohesion. ..discuss. :) Cheers Terry On 23/09/11 3:24 AM, "Dino Farinacci" wrote: > Terry, what I would like to know first and foremost, before adding any > specific feature or use-cases to the charter is if they *should* belong i= n the > LISP working group charter versus being owne by another working group. An= d > what the working group thinks about this. I will give some examples to ge= t > some clarity and to be more specific. >=20 > (1) LISP could be used for many data-center use-cases. > (2) LISP could be used for device mobility. > (3) LISP could be used as a IPv6 coexistence solution while delivering ro= ute > table reduction and low opex multihoming. > (4) LISP could be used as a VPN solution. > (5) The mapping database could be used for other applications like keepin= g > track of multicast group membership. >=20 > So, to enumerate each one: >=20 > For (1), does the LISP WG take this on or is there a data-center specific > protocol solution working group (ARMD is not that working group because i= t is > a requirement definition working group)? >=20 > For (2), the MOBOPTs IRTF research group seem to take interest in LISP-MN= . > Does it do the initial work and have it spin off a mobility working group= , > which there are many already. To add, there is a cross-product issue too = since > LISP-Multicast can run in a LISP-MN implementation and there is a multimo= b > working group already established. >=20 > For (3), there are zillions of solutions and places where this occurs ove= r the > last decade, I would suggest not spinning another working group for this = and > have the LISP working group be "address-family" agnostic which would also > include MAC addressing as a address-family as well a GPS coordinates. >=20 > For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, as = well > as the other 2 combinations, does the VPN use-case stay in the LISP worki= ng > group or is it fragmented to be taken to each L2VPN and L3VPN working gro= ups. >=20 > For (5), we do not want to error where everything is put into DNS (becaus= e it > is the only applicaiton level wide-area/multi-organizational distributed > database). In our case the mapping database. And moreoever, if the use-ca= se > functionality is distributed to other working groups, will there be desig= n > change requests to the mapping database design coming from too many sourc= e > points. >=20 > As you can see, this can get very complex and confusing and could result = in > design fragmentation and opportunity for competitive proposals. All which= turn > out to add more inefficiencies to the protocol design process which nearl= y > always results in undeployable compromises. >=20 > Dino >=20 > On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote: >=20 >> Hi Folks, >>=20 >> In Prague there was no strong consensus on modifying the LISP Charter fr= om >> what it currently is, perhaps only updating the existing Goals/Milestone= s. >>=20 >> So no clear decision could be made. What I would like to do is push out = a >> 'idea generating' draft charter that is _almost_ identical to what we ha= ve >> today. >>=20 >> You can find the existing charter here: >> https://datatracker.ietf.org/wg/lisp/charter/ >>=20 >> The draft is below. >>=20 >> So in light of such an approach, Joel and I discussed some work items th= at >> came from what was said at the mic in Prague and to us individually. >>=20 >> They are: >>=20 >> * Finish the deployment document >> * Get the two security documents done >> * Get an operational document at least started, which should include >> cache management and ETR synchronization techniques. >> * Either in the second security document, or in complementary documents = we >> need to evaluate the security threat to cache maintenance, and >> evaluate the applicability and coverage we get from a reuse of SIDR >> technology. >>=20 >> Is anything not represented here that you believe necessary? and convers= ely >> is there something here that is out of scope in your eyes? >>=20 >> Are there work areas not covered by the draft below which you believe sh= ould >> be? >>=20 >> Draft Charter >> ------------ >>=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 the IRTF and >> IETF. At this time, these proposals are at an early stage. All proposals >> (including LISP) have potentially harmful side-effects to Internet >> traffic carried by the involved routers, have parts where deployment >> incentives may be lacking, and are NOT RECOMMENDED for deployment beyond >> experimental situations at this stage. Many of the proposals have >> components (such as the identifier to locator mapping system) where it >> is not yet known what kind of design alternative is the best one among >> many. >>=20 >> However, despite these issues it would be valuable to write concrete >> protocol specifications and develop implementations that can be used to >> understand the characteristics of these designs. 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 the ALT and/or other 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 >> Cheers >> Terry >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From vimoreno@cisco.com Mon Sep 26 22:00: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 87CBA21F8C79 for ; Mon, 26 Sep 2011 22:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_13=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 IGPNqwyXtZXa for ; Mon, 26 Sep 2011 22:00:17 -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 1D70221F8D17 for ; Mon, 26 Sep 2011 22:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vimoreno@cisco.com; l=10495; q=dns/txt; s=iport; t=1317099782; x=1318309382; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=od4xtmMW7Y87Ni/L0ZtTy5zLTcpsQr3QpNBa4O89m6w=; b=GcFzje2qpq2HhHwYGLlSaOtF5G9SxbnBfbRkmxdfMwAzcCjeaXzfxStD EQqqcFHpM4He6G6+qe2RmvxhU8U8fm4wil3pdw9hPdXo2jy4yIFU9FU/j +99Zavz/Pd98N4racS5khkhvB4RmQlWl0Fx4qu+OZzTARl+Loiz4lA0/N 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAJ1YgU6rRDoG/2dsb2JhbAA4Cphqjwt4gVMBAQEBAwEBAQ8BHQotBwYFDAQCAQgRAQMBAQEKBhcBBgEmHwMGCAEBBAESCBMHh1yaDgGeXYNhgkpgBIdykQuMKQ X-IronPort-AV: E=Sophos;i="4.68,448,1312156800"; d="scan'208";a="4468091" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 27 Sep 2011 05:03:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8R531Pc013514; Tue, 27 Sep 2011 05:03:01 GMT Received: from xmb-sjc-212.amer.cisco.com ([171.70.151.141]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 22:03:01 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 22:02:52 -0700 Message-ID: <40966CDBEF22C64F84F20BD68D445B210168BD8C@xmb-sjc-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx5TIaevaA3w2i0T9e8wLpgRLaj2gDf8fv2AAF3XfA= References: <64989934-E075-4620-9547-63635173B18B@cisco.com> From: "Victor Moreno (vimoreno)" To: "Terry Manderson" , "Dino Farinacci (dino)" X-OriginalArrivalTime: 27 Sep 2011 05:03:01.0338 (UTC) FILETIME=[BB3F83A0:01CC7CD2] 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, 27 Sep 2011 05:00:18 -0000 LISP is a bit unique in that it can enable many applications concurrently. If the effort for each application is spun off to different groups, each thread will evolve independently and with that the cohesion of the protocol may quickly be lost. IMO it is important that the WG retains ownership/authority over all things LISP. -v > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Terry Manderson > Sent: Monday, September 26, 2011 9:17 PM > To: Dino Farinacci (dino) > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP (re-)Charter discussion >=20 > Thanks Dino, >=20 > I encourage all LISP WG members to reflect on the questions below and voice > an opinion. >=20 > To paraphrase what Dino has written, one proposal (and Dino correct me if > I've oversimplified) is that the LISP WG should become a working group that > contains ALL things LISP. So wherever a body of work uses LISP > encapsulation, or LISP mapping it may gravitate to here to maintain LISP > interoperability and (where appropriate) protocol cohesion. >=20 > ..discuss. >=20 > :) >=20 > Cheers > Terry >=20 >=20 > On 23/09/11 3:24 AM, "Dino Farinacci" wrote: >=20 > > Terry, what I would like to know first and foremost, before adding any > > specific feature or use-cases to the charter is if they *should* belong > in the > > LISP working group charter versus being owne by another working group. > And > > what the working group thinks about this. I will give some examples to > get > > some clarity and to be more specific. > > > > (1) LISP could be used for many data-center use-cases. > > (2) LISP could be used for device mobility. > > (3) LISP could be used as a IPv6 coexistence solution while delivering > route > > table reduction and low opex multihoming. > > (4) LISP could be used as a VPN solution. > > (5) The mapping database could be used for other applications like > keeping > > track of multicast group membership. > > > > So, to enumerate each one: > > > > For (1), does the LISP WG take this on or is there a data-center specific > > protocol solution working group (ARMD is not that working group because > it is > > a requirement definition working group)? > > > > For (2), the MOBOPTs IRTF research group seem to take interest in LISP- > MN. > > Does it do the initial work and have it spin off a mobility working > group, > > which there are many already. To add, there is a cross-product issue too > since > > LISP-Multicast can run in a LISP-MN implementation and there is a > multimob > > working group already established. > > > > For (3), there are zillions of solutions and places where this occurs > over the > > last decade, I would suggest not spinning another working group for this > and > > have the LISP working group be "address-family" agnostic which would also > > include MAC addressing as a address-family as well a GPS coordinates. > > > > For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, as > well > > as the other 2 combinations, does the VPN use-case stay in the LISP > working > > group or is it fragmented to be taken to each L2VPN and L3VPN working > groups. > > > > For (5), we do not want to error where everything is put into DNS > (because it > > is the only applicaiton level wide-area/multi-organizational distributed > > database). In our case the mapping database. And moreoever, if the use- > case > > functionality is distributed to other working groups, will there be > design > > change requests to the mapping database design coming from too many > source > > points. > > > > As you can see, this can get very complex and confusing and could result > in > > design fragmentation and opportunity for competitive proposals. All which > turn > > out to add more inefficiencies to the protocol design process which > nearly > > always results in undeployable compromises. > > > > Dino > > > > On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote: > > > >> Hi Folks, > >> > >> In Prague there was no strong consensus on modifying the LISP Charter > from > >> what it currently is, perhaps only updating the existing > Goals/Milestones. > >> > >> So no clear decision could be made. What I would like to do is push out > a > >> 'idea generating' draft charter that is _almost_ identical to what we > have > >> today. > >> > >> You can find the existing charter here: > >> https://datatracker.ietf.org/wg/lisp/charter/ > >> > >> The draft is below. > >> > >> So in light of such an approach, Joel and I discussed some work items > that > >> came from what was said at the mic in Prague and to us individually. > >> > >> They are: > >> > >> * Finish the deployment document > >> * Get the two security documents done > >> * Get an operational document at least started, which should include > >> cache management and ETR synchronization techniques. > >> * Either in the second security document, or in complementary documents > we > >> need to evaluate the security threat to cache maintenance, and > >> evaluate the applicability and coverage we get from a reuse of SIDR > >> technology. > >> > >> Is anything not represented here that you believe necessary? and > conversely > >> is there something here that is out of scope in your eyes? > >> > >> Are there work areas not covered by the draft below which you believe > should > >> be? > >> > >> Draft Charter > >> ------------ > >> > >> 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 the IRTF and > >> IETF. At this time, these proposals are at an early stage. All proposals > >> (including LISP) have potentially harmful side-effects to Internet > >> traffic carried by the involved routers, have parts where deployment > >> incentives may be lacking, and are NOT RECOMMENDED for deployment beyond > >> experimental situations at this stage. Many of the proposals have > >> components (such as the identifier to locator mapping system) where it > >> is not yet known what kind of design alternative is the best one among > >> many. > >> > >> However, despite these issues it would be valuable to write concrete > >> protocol specifications and develop implementations that can be used to > >> understand the characteristics of these designs. 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 the ALT and/or other 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. > >> > >> > >> Cheers > >> Terry > >> > >> _______________________________________________ > >> 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 From dino@cisco.com Mon Sep 26 22:00: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 9DA9521F8D26 for ; Mon, 26 Sep 2011 22:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.025 X-Spam-Level: X-Spam-Status: No, score=-3.025 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, J_CHICKENPOX_13=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 p7VQ+0p3AYs7 for ; Mon, 26 Sep 2011 22:00:29 -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 CE97021F8C79 for ; Mon, 26 Sep 2011 22:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=9832; q=dns/txt; s=iport; t=1317099794; x=1318309394; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eibkVcmNC8k3c/JoMCwkdHcLx/vQs4RSwgttm3NmGpI=; b=K+zATuxbbnDFB5Hfel1XIqZUU5+qFwODMBJR2ZAF0fhK+LRK9vUG+mIK 4R1tesFHg4oPXRMLSlhPseMuwt3IeTSV2Ttq6GJ5WIy0V0FC8HS+9gRhE yMO3y4BccFD9omq97JnV9DlUUP0kSgbCkdnP5FGV4KZZmygMBmzyhvLOa A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ1YgU6rRDoH/2dsb2JhbAA4Cqd1eIFTAQEBAQIBAQEBDwFUBwYFBQsLEgYuJyIOBhMbB4dWBpoOAZ5dg2GCSmAEh3KLYJFU X-IronPort-AV: E=Sophos;i="4.68,448,1312156800"; d="scan'208";a="4468117" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Sep 2011 05:03:14 +0000 Received: from sjc-vpn2-617.cisco.com (sjc-vpn2-617.cisco.com [10.21.114.105]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8R53DQB014154; Tue, 27 Sep 2011 05:03:14 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Mon, 26 Sep 2011 22:03:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <784C23DF-96FE-4922-BD53-60D4560B368D@cisco.com> References: To: Terry Manderson X-Mailer: Apple Mail (2.1244.3) 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, 27 Sep 2011 05:00:30 -0000 > Thanks Dino, >=20 > I encourage all LISP WG members to reflect on the questions below and = voice > an opinion. >=20 > To paraphrase what Dino has written, one proposal (and Dino correct me = if > I've oversimplified) is that the LISP WG should become a working group = that > contains ALL things LISP. So wherever a body of work uses LISP > encapsulation, or LISP mapping it may gravitate to here to maintain = LISP > interoperability and (where appropriate) protocol cohesion. Right, I was not direct about this point but it can be inferred from = below. Thanks for clarifying Terry. Dino >=20 > ..discuss. >=20 > :) >=20 > Cheers > Terry >=20 >=20 > On 23/09/11 3:24 AM, "Dino Farinacci" wrote: >=20 >> Terry, what I would like to know first and foremost, before adding = any >> specific feature or use-cases to the charter is if they *should* = belong in the >> LISP working group charter versus being owne by another working = group. And >> what the working group thinks about this. I will give some examples = to get >> some clarity and to be more specific. >>=20 >> (1) LISP could be used for many data-center use-cases. >> (2) LISP could be used for device mobility. >> (3) LISP could be used as a IPv6 coexistence solution while = delivering route >> table reduction and low opex multihoming. >> (4) LISP could be used as a VPN solution. >> (5) The mapping database could be used for other applications like = keeping >> track of multicast group membership. >>=20 >> So, to enumerate each one: >>=20 >> For (1), does the LISP WG take this on or is there a data-center = specific >> protocol solution working group (ARMD is not that working group = because it is >> a requirement definition working group)? >>=20 >> For (2), the MOBOPTs IRTF research group seem to take interest in = LISP-MN. >> Does it do the initial work and have it spin off a mobility working = group, >> which there are many already. To add, there is a cross-product issue = too since >> LISP-Multicast can run in a LISP-MN implementation and there is a = multimob >> working group already established. >>=20 >> For (3), there are zillions of solutions and places where this occurs = over the >> last decade, I would suggest not spinning another working group for = this and >> have the LISP working group be "address-family" agnostic which would = also >> include MAC addressing as a address-family as well a GPS coordinates. >>=20 >> For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, = as well >> as the other 2 combinations, does the VPN use-case stay in the LISP = working >> group or is it fragmented to be taken to each L2VPN and L3VPN working = groups. >>=20 >> For (5), we do not want to error where everything is put into DNS = (because it >> is the only applicaiton level wide-area/multi-organizational = distributed >> database). In our case the mapping database. And moreoever, if the = use-case >> functionality is distributed to other working groups, will there be = design >> change requests to the mapping database design coming from too many = source >> points. >>=20 >> As you can see, this can get very complex and confusing and could = result in >> design fragmentation and opportunity for competitive proposals. All = which turn >> out to add more inefficiencies to the protocol design process which = nearly >> always results in undeployable compromises. >>=20 >> Dino >>=20 >> On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote: >>=20 >>> Hi Folks, >>>=20 >>> In Prague there was no strong consensus on modifying the LISP = Charter from >>> what it currently is, perhaps only updating the existing = Goals/Milestones. >>>=20 >>> So no clear decision could be made. What I would like to do is push = out a >>> 'idea generating' draft charter that is _almost_ identical to what = we have >>> today. >>>=20 >>> You can find the existing charter here: >>> https://datatracker.ietf.org/wg/lisp/charter/ >>>=20 >>> The draft is below. >>>=20 >>> So in light of such an approach, Joel and I discussed some work = items that >>> came from what was said at the mic in Prague and to us individually. >>>=20 >>> They are: >>>=20 >>> * Finish the deployment document >>> * Get the two security documents done >>> * Get an operational document at least started, which should include >>> cache management and ETR synchronization techniques. >>> * Either in the second security document, or in complementary = documents we >>> need to evaluate the security threat to cache maintenance, and >>> evaluate the applicability and coverage we get from a reuse of SIDR >>> technology. >>>=20 >>> Is anything not represented here that you believe necessary? and = conversely >>> is there something here that is out of scope in your eyes? >>>=20 >>> Are there work areas not covered by the draft below which you = believe should >>> be? >>>=20 >>> Draft Charter >>> ------------ >>>=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 the IRTF = and >>> IETF. At this time, these proposals are at an early stage. All = proposals >>> (including LISP) have potentially harmful side-effects to Internet >>> traffic carried by the involved routers, have parts where deployment >>> incentives may be lacking, and are NOT RECOMMENDED for deployment = beyond >>> experimental situations at this stage. Many of the proposals have >>> components (such as the identifier to locator mapping system) where = it >>> is not yet known what kind of design alternative is the best one = among >>> many. >>>=20 >>> However, despite these issues it would be valuable to write concrete >>> protocol specifications and develop implementations that can be used = to >>> understand the characteristics of these designs. 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 the ALT and/or other 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 >>> Cheers >>> Terry >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 From jgs@juniper.net Wed Sep 28 12:21: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 718571F0CEE for ; Wed, 28 Sep 2011 12:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 n5Ft8mwR9Eak for ; Wed, 28 Sep 2011 12:21:20 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4241F0CE1 for ; Wed, 28 Sep 2011 12:21:09 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKToN0OZXdRXV3FrjQHRQW/vc4/nmboIm/@postini.com; Wed, 28 Sep 2011 12:23:58 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 28 Sep 2011 12:21:32 -0700 From: John Scudder To: Terry Manderson Date: Wed, 28 Sep 2011 12:21:31 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+E9RgLKQsbJQhT7SJS+XHFqk8iA== Message-ID: References: In-Reply-To: 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: "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: Wed, 28 Sep 2011 19:21:26 -0000 Terry, I think your list of bullet points is almost right. I would something that= Joel proposed in Quebec City: * Publish an example cache management specification. As a reminder, the purpose of this is to provide something that is amenable= to analysis to make it possible to meaningfully "evaluate the security thr= eat to cache maintenance" as you say in your last bullet. =20 The relevant excerpt from the IETF-81 minutes (http://www.ietf.org/proceedi= ngs/81/minutes/lisp.txt) is the "b" part below (Terry's final bullet point = covers the "a" part): ----- Joel Halpern =3D> Let me paraphrase because what I heard sound very reasonable. a) In the threats doc, we should put a little more attention on this. b) We should put as WG item a new document that addresses what is the right answer to this problem is. Alia Atlas =3D> What the minimum answer to the problem is. Joel Halpern =3D> OK. ----- Second, the base spec calls out a number of areas that require more experim= entation. A simple grep will find these. These experiments and what has b= een learned from them should be documented. The same applies if other spec= s have similar caveats (I just haven't looked for them). =20 --John =20 On Sep 21, 2011, at 8:04 PM, Terry Manderson wrote: > Hi Folks, >=20 > In Prague there was no strong consensus on modifying the LISP Charter fro= m > what it currently is, perhaps only updating the existing Goals/Milestones= . >=20 > So no clear decision could be made. What I would like to do is push out a > 'idea generating' draft charter that is _almost_ identical to what we hav= e > today.=20 >=20 > You can find the existing charter here: > https://datatracker.ietf.org/wg/lisp/charter/ >=20 > The draft is below. >=20 > So in light of such an approach, Joel and I discussed some work items tha= t > came from what was said at the mic in Prague and to us individually. >=20 > They are: >=20 > * Finish the deployment document > * Get the two security documents done > * Get an operational document at least started, which should include > cache management and ETR synchronization techniques. > * Either in the second security document, or in complementary documents w= e > need to evaluate the security threat to cache maintenance, and > evaluate the applicability and coverage we get from a reuse of SIDR > technology. >=20 > Is anything not represented here that you believe necessary? and converse= ly > is there something here that is out of scope in your eyes? >=20 > Are there work areas not covered by the draft below which you believe sho= uld > be? >=20 > Draft Charter > ------------ >=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 the IRTF and > IETF. At this time, these proposals are at an early stage. All proposals > (including LISP) have potentially harmful side-effects to Internet > traffic carried by the involved routers, have parts where deployment > incentives may be lacking, and are NOT RECOMMENDED for deployment beyond > experimental situations at this stage. Many of the proposals have > components (such as the identifier to locator mapping system) where it > is not yet known what kind of design alternative is the best one among > many. >=20 > However, despite these issues it would be valuable to write concrete > protocol specifications and develop implementations that can be used to > understand the characteristics of these designs. 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 the ALT and/or other 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 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jgs@juniper.net Wed Sep 28 12:21: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 7C2A51F0CF3 for ; Wed, 28 Sep 2011 12:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.285 X-Spam-Level: X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_13=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 iDza4lZTKuWd for ; Wed, 28 Sep 2011 12:21:43 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id CB73D1F0CE1 for ; Wed, 28 Sep 2011 12:21:42 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKToN0WsrpoUuwXNVwc+R79Euxr8EkORRV@postini.com; Wed, 28 Sep 2011 12:24:32 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 28 Sep 2011 12:21:34 -0700 From: John Scudder To: Terry Manderson Date: Wed, 28 Sep 2011 12:21:34 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+E9XyMdXoPxtXQQKmtCkQMJjnLw== Message-ID: References: In-Reply-To: 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: "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: Wed, 28 Sep 2011 19:21:45 -0000 Terry, It seems inappropriate to me that LISP be the sole WG that works on all thi= ngs related to LISP. It's standard IETF procedure for one WG to build on a= nother WG's protocol. There are many examples of this. Of course review b= y the LISP WG of any relevant specs (both prior to and during last call) ma= y be appropriate. This is also SOP. --John =20 On Sep 27, 2011, at 12:17 AM, Terry Manderson wrote: > Thanks Dino, >=20 > I encourage all LISP WG members to reflect on the questions below and voi= ce > an opinion. >=20 > To paraphrase what Dino has written, one proposal (and Dino correct me if > I've oversimplified) is that the LISP WG should become a working group th= at > contains ALL things LISP. So wherever a body of work uses LISP > encapsulation, or LISP mapping it may gravitate to here to maintain LISP > interoperability and (where appropriate) protocol cohesion. >=20 > ..discuss. >=20 > :) >=20 > Cheers > Terry >=20 >=20 > On 23/09/11 3:24 AM, "Dino Farinacci" wrote: >=20 >> Terry, what I would like to know first and foremost, before adding any >> specific feature or use-cases to the charter is if they *should* belong = in the >> LISP working group charter versus being owne by another working group. A= nd >> what the working group thinks about this. I will give some examples to g= et >> some clarity and to be more specific. >>=20 >> (1) LISP could be used for many data-center use-cases. >> (2) LISP could be used for device mobility. >> (3) LISP could be used as a IPv6 coexistence solution while delivering r= oute >> table reduction and low opex multihoming. >> (4) LISP could be used as a VPN solution. >> (5) The mapping database could be used for other applications like keepi= ng >> track of multicast group membership. >>=20 >> So, to enumerate each one: >>=20 >> For (1), does the LISP WG take this on or is there a data-center specifi= c >> protocol solution working group (ARMD is not that working group because = it is >> a requirement definition working group)? >>=20 >> For (2), the MOBOPTs IRTF research group seem to take interest in LISP-M= N. >> Does it do the initial work and have it spin off a mobility working grou= p, >> which there are many already. To add, there is a cross-product issue too= since >> LISP-Multicast can run in a LISP-MN implementation and there is a multim= ob >> working group already established. >>=20 >> For (3), there are zillions of solutions and places where this occurs ov= er the >> last decade, I would suggest not spinning another working group for this= and >> have the LISP working group be "address-family" agnostic which would als= o >> include MAC addressing as a address-family as well a GPS coordinates. >>=20 >> For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, as= well >> as the other 2 combinations, does the VPN use-case stay in the LISP work= ing >> group or is it fragmented to be taken to each L2VPN and L3VPN working gr= oups. >>=20 >> For (5), we do not want to error where everything is put into DNS (becau= se it >> is the only applicaiton level wide-area/multi-organizational distributed >> database). In our case the mapping database. And moreoever, if the use-c= ase >> functionality is distributed to other working groups, will there be desi= gn >> change requests to the mapping database design coming from too many sour= ce >> points. >>=20 >> As you can see, this can get very complex and confusing and could result= in >> design fragmentation and opportunity for competitive proposals. All whic= h turn >> out to add more inefficiencies to the protocol design process which near= ly >> always results in undeployable compromises. >>=20 >> Dino >>=20 >> On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote: >>=20 >>> Hi Folks, >>>=20 >>> In Prague there was no strong consensus on modifying the LISP Charter f= rom >>> what it currently is, perhaps only updating the existing Goals/Mileston= es. >>>=20 >>> So no clear decision could be made. What I would like to do is push out= a >>> 'idea generating' draft charter that is _almost_ identical to what we h= ave >>> today. >>>=20 >>> You can find the existing charter here: >>> https://datatracker.ietf.org/wg/lisp/charter/ >>>=20 >>> The draft is below. >>>=20 >>> So in light of such an approach, Joel and I discussed some work items t= hat >>> came from what was said at the mic in Prague and to us individually. >>>=20 >>> They are: >>>=20 >>> * Finish the deployment document >>> * Get the two security documents done >>> * Get an operational document at least started, which should include >>> cache management and ETR synchronization techniques. >>> * Either in the second security document, or in complementary documents= we >>> need to evaluate the security threat to cache maintenance, and >>> evaluate the applicability and coverage we get from a reuse of SIDR >>> technology. >>>=20 >>> Is anything not represented here that you believe necessary? and conver= sely >>> is there something here that is out of scope in your eyes? >>>=20 >>> Are there work areas not covered by the draft below which you believe s= hould >>> be? >>>=20 >>> Draft Charter >>> ------------ >>>=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 th= e >>> 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, includin= g >>> 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 the IRTF and >>> IETF. At this time, these proposals are at an early stage. All proposal= s >>> (including LISP) have potentially harmful side-effects to Internet >>> traffic carried by the involved routers, have parts where deployment >>> incentives may be lacking, and are NOT RECOMMENDED for deployment beyon= d >>> experimental situations at this stage. Many of the proposals have >>> components (such as the identifier to locator mapping system) where it >>> is not yet known what kind of design alternative is the best one among >>> many. >>>=20 >>> However, despite these issues it would be valuable to write concrete >>> protocol specifications and develop implementations that can be used to >>> understand the characteristics of these designs. The LISP WG is >>> chartered to work on the LISP base protocol and any items which directl= y >>> 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 the ALT and/or other mapping systems. >>>=20 >>> It is expected that the results of specifying, implementing, and testin= g >>> 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 >>> Cheers >>> Terry >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From robert@raszuk.net Wed Sep 28 13:25:06 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 8EBD91F0D02 for ; Wed, 28 Sep 2011 13:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_14=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 TJH1f8mYo5S9 for ; Wed, 28 Sep 2011 13:25:06 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id DBD051F0D0B for ; Wed, 28 Sep 2011 13:25:05 -0700 (PDT) Received: (qmail 3980 invoked by uid 399); 28 Sep 2011 20:27:54 -0000 Received: from unknown (HELO ?216.69.73.168?) (216.69.73.168) by mail37.opentransfer.com with SMTP; 28 Sep 2011 20:27:54 -0000 Message-ID: <4E838349.7090400@raszuk.net> Date: Wed, 28 Sep 2011 22:27:53 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: John Scudder , Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP (re-)Charter discussion X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net 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, 28 Sep 2011 20:25:06 -0000 All, I agree here with John .. the way how I read what is being proposed here I would call also impractical. It seems to me that LISP WG just like any other WG should be involved in the core LISP work and not in any potential new application which will choose to use LISP. As example if I would like to propose an overlay which uses LISP to interconnect set of ALTO servers I would rather work on it in ALTO WG not in LISP. LISP WG could be just involved as far as being aware about such work. That practice has worked very well in the past for large number of other IETF solutions. L3VPNs or L2VPNs while heavily using BGP are not standardized in IDR. They are standardized in their respective WGs. MPLS TE has been topic of MPLS WG and not ISIS, OSPF or RSVP WGs which extensions are critical part of it. Best, R. > Terry, > > It seems inappropriate to me that LISP be the sole WG that works on > all things related to LISP. It's standard IETF procedure for one WG > to build on another WG's protocol. There are many examples of this. > Of course review by the LISP WG of any relevant specs (both prior to > and during last call) may be appropriate. This is also SOP. > > --John > > On Sep 27, 2011, at 12:17 AM, Terry Manderson wrote: > >> Thanks Dino, >> >> I encourage all LISP WG members to reflect on the questions below >> and voice an opinion. >> >> To paraphrase what Dino has written, one proposal (and Dino correct >> me if I've oversimplified) is that the LISP WG should become a >> working group that contains ALL things LISP. So wherever a body of >> work uses LISP encapsulation, or LISP mapping it may gravitate to >> here to maintain LISP interoperability and (where appropriate) >> protocol cohesion. >> >> ..discuss. >> >> :) >> >> Cheers Terry From Fred.L.Templin@boeing.com Wed Sep 28 19:17:54 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 DD38F11E80F9 for ; Wed, 28 Sep 2011 19:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 j9muf9UzwXcz for ; Wed, 28 Sep 2011 19:17:54 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 133E711E80D6 for ; Wed, 28 Sep 2011 19:17:54 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8T2KGqW002205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2011 19:20:17 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p8T2KF3N027937; Wed, 28 Sep 2011 21:20:15 -0500 (CDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8T2KCuY027905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 28 Sep 2011 21:20:13 -0500 (CDT) 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; Wed, 28 Sep 2011 19:20:12 -0700 From: "Templin, Fred L" To: Terry Manderson , "lisp@ietf.org" Date: Wed, 28 Sep 2011 19:20:11 -0700 Thread-Topic: LISP (re-)Charter discussion Thread-Index: Acx4uz3s1/gPJmaQPEa2DzHbfsdlYwFjdMig Message-ID: References: In-Reply-To: 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 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, 29 Sep 2011 02:17:55 -0000 Hi Terry, Regarding the 5th paragraph of the Draft Charter: > A number of approaches are being looked at in parallel in the IRTF and > IETF. At this time, these proposals are at an early stage. This needs to be updated; here is a proposed rewrite: "A number of approaches have been published in parallel in the IRTF and IETF. In particular, the IRTF Routing Research Group (RRG) has published its recommendations [RFC6115] and design goals [RFC6227], and has authorized the publication of three solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and ILNP [ILNP]." Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Terry Manderson > Sent: Wednesday, September 21, 2011 5:05 PM > To: lisp@ietf.org > Subject: [lisp] LISP (re-)Charter discussion >=20 > Hi Folks, >=20 > In Prague there was no strong consensus on modifying the LISP=20 > Charter from > what it currently is, perhaps only updating the existing=20 > Goals/Milestones. >=20 > So no clear decision could be made. What I would like to do=20 > is push out a > 'idea generating' draft charter that is _almost_ identical to=20 > what we have > today.=20 >=20 > You can find the existing charter here: > https://datatracker.ietf.org/wg/lisp/charter/ >=20 > The draft is below. >=20 > So in light of such an approach, Joel and I discussed some=20 > work items that > came from what was said at the mic in Prague and to us individually. >=20 > They are: >=20 > * Finish the deployment document > * Get the two security documents done > * Get an operational document at least started, which should include > cache management and ETR synchronization techniques. > * Either in the second security document, or in complementary=20 > documents we > need to evaluate the security threat to cache maintenance, and > evaluate the applicability and coverage we get from a reuse of SIDR > technology. >=20 > Is anything not represented here that you believe necessary?=20 > and conversely > is there something here that is out of scope in your eyes? >=20 > Are there work areas not covered by the draft below which you=20 > believe should > be? >=20 > Draft Charter > ------------ >=20 > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > rekindled interest in scalable routing and addressing=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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 the IRTF and > IETF. At this time, these proposals are at an early stage.=20 > All proposals > (including LISP) have potentially harmful side-effects to Internet > traffic carried by the involved routers, have parts where deployment > incentives may be lacking, and are NOT RECOMMENDED for=20 > deployment beyond > experimental situations at this stage. Many of the proposals have > components (such as the identifier to locator mapping system) where it > is not yet known what kind of design alternative is the best one among > many. >=20 > However, despite these issues it would be valuable to write concrete > protocol specifications and develop implementations that can=20 > be used to > understand the characteristics of these designs. The LISP WG is > chartered to work on the LISP base protocol and any items=20 > 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=20 > will also > develop security profiles for the ALT and/or other mapping systems. >=20 > It is expected that the results of specifying, implementing,=20 > and testing > LISP will be fed to the general efforts at the IETF and IRTF=20 > (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 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > = From jmh@joelhalpern.com Wed Sep 28 20:08:10 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 64D7E1F0D4A for ; Wed, 28 Sep 2011 20:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 bIauCwMrHOgf for ; Wed, 28 Sep 2011 20:08:09 -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 92EDA1F0C6C for ; Wed, 28 Sep 2011 20:08:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 802F04300D2; Wed, 28 Sep 2011 20:10:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-60.clppva.btas.verizon.net [71.161.52.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 61F38430076; Wed, 28 Sep 2011 20:10:58 -0700 (PDT) Message-ID: <4E83E1C1.7050709@joelhalpern.com> Date: Wed, 28 Sep 2011 23:10:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "Templin, Fred L" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 29 Sep 2011 03:08:10 -0000 Fred, "Authorized" is I think the wrong word to use to describe the publication. Or at least a misleading word. The IRTF process is such that the RG did not actually approve the publication of any of the solutions. The RG Chair sponsored the publication as an output of the RG. IRTF procedures explicitly recognize and allow for multiple minority reports from an RG. I do agree that we should recognize that a number of ideas have been published as RFCs. And we should probably not be too specific about what the RG is doing, since that is liable to change. Yours, Joel On 9/28/2011 10:20 PM, Templin, Fred L wrote: > Hi Terry, > > Regarding the 5th paragraph of the Draft Charter: > >> A number of approaches are being looked at in parallel in the IRTF and >> IETF. At this time, these proposals are at an early stage. > > This needs to be updated; here is a proposed rewrite: > > "A number of approaches have been published in parallel in the > IRTF and IETF. In particular, the IRTF Routing Research Group > (RRG) has published its recommendations [RFC6115] and design > goals [RFC6227], and has authorized the publication of three > solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and > ILNP [ILNP]." > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On >> Behalf Of Terry Manderson >> Sent: Wednesday, September 21, 2011 5:05 PM >> To: lisp@ietf.org >> Subject: [lisp] LISP (re-)Charter discussion >> >> Hi Folks, >> >> In Prague there was no strong consensus on modifying the LISP >> Charter from >> what it currently is, perhaps only updating the existing >> Goals/Milestones. >> >> So no clear decision could be made. What I would like to do >> is push out a >> 'idea generating' draft charter that is _almost_ identical to >> what we have >> today. >> >> You can find the existing charter here: >> https://datatracker.ietf.org/wg/lisp/charter/ >> >> The draft is below. >> >> So in light of such an approach, Joel and I discussed some >> work items that >> came from what was said at the mic in Prague and to us individually. >> >> They are: >> >> * Finish the deployment document >> * Get the two security documents done >> * Get an operational document at least started, which should include >> cache management and ETR synchronization techniques. >> * Either in the second security document, or in complementary >> documents we >> need to evaluate the security threat to cache maintenance, and >> evaluate the applicability and coverage we get from a reuse of SIDR >> technology. >> >> Is anything not represented here that you believe necessary? >> and conversely >> is there something here that is out of scope in your eyes? >> >> Are there work areas not covered by the draft below which you >> believe should >> be? >> >> Draft Charter >> ------------ >> >> 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 the IRTF and >> IETF. At this time, these proposals are at an early stage. >> All proposals >> (including LISP) have potentially harmful side-effects to Internet >> traffic carried by the involved routers, have parts where deployment >> incentives may be lacking, and are NOT RECOMMENDED for >> deployment beyond >> experimental situations at this stage. Many of the proposals have >> components (such as the identifier to locator mapping system) where it >> is not yet known what kind of design alternative is the best one among >> many. >> >> However, despite these issues it would be valuable to write concrete >> protocol specifications and develop implementations that can >> be used to >> understand the characteristics of these designs. 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 the ALT and/or other 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. >> >> >> 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 lear@cisco.com Thu Sep 29 00:21: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 B908221F8BA8 for ; Thu, 29 Sep 2011 00:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 H8gCkTPAANe4 for ; Thu, 29 Sep 2011 00:21:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB621F8CC2 for ; Thu, 29 Sep 2011 00:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=589; q=dns/txt; s=iport; t=1317281042; x=1318490642; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FEv0zqVKigYrmlojC+y29Wbd9F/pMW2Rf7sz3Z0VKYg=; b=UcXskE3nJgazvAgRR9tB8wq/I5sqA/6UsmP/ZZU4iSWwpC3XyGmvrvyC g5cf4H9QwX0ap467V/DleI6fad6/MoK3YU+3aHdLetHbcXDjQ4UagNWDO JjzSUjk9B1QlOKeDic9KI2BTmwJwNX6/qBjY+ubu30SmE0EiZhm51VCYI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMgbhE6Q/khL/2dsb2JhbABBhGSjIniBUwEBAQEDEgEQVQEQCw4KAgIFFgsCAgkDAgECAUUGDQEHAQEeoUEBjEWRWoEshE6BEgSTVpE7 X-IronPort-AV: E=Sophos;i="4.68,459,1312156800"; d="scan'208";a="117802533" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 Sep 2011 07:23:51 +0000 Received: from ams3-vpn-dhcp6313.cisco.com (ams3-vpn-dhcp6313.cisco.com [10.61.88.168]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8T7Noen022227; Thu, 29 Sep 2011 07:23:50 GMT Message-ID: <4E841CC0.9070805@cisco.com> Date: Thu, 29 Sep 2011 09:22:40 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: John Scudder References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Thu, 29 Sep 2011 07:21:12 -0000 John, On 9/28/11 9:21 PM, John Scudder wrote: > Terry, > > I think your list of bullet points is almost right. I would something that Joel proposed in Quebec City: > > * Publish an example cache management specification. > > As a reminder, the purpose of this is to provide something that is amenable to analysis to make it possible to meaningfully "evaluate the security threat to cache maintenance" as you say in your last bullet. I generally like to see things in charters that have (at least in the background) names attached to them. Are you volunteering? Eliot From Fred.L.Templin@boeing.com Thu Sep 29 05:14: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 529C621F8C09 for ; Thu, 29 Sep 2011 05:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 3IH1G3R5XVyJ for ; Thu, 29 Sep 2011 05:14:03 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5CA21F8C04 for ; Thu, 29 Sep 2011 05:14:03 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8TCGOnK000977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2011 05:16:24 -0700 (PDT) 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 p8TCGNFn003827; Thu, 29 Sep 2011 05:16:23 -0700 (PDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8TCGN3D003815 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 29 Sep 2011 05:16:23 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Thu, 29 Sep 2011 05:16:22 -0700 From: "Templin, Fred L" To: "Joel M. Halpern" Date: Thu, 29 Sep 2011 05:16:21 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+VWrzdmq1dUSIRyaBHAHIA/vhmgAS6pWQ Message-ID: References: <4E83E1C1.7050709@joelhalpern.com> In-Reply-To: <4E83E1C1.7050709@joelhalpern.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: "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: Thu, 29 Sep 2011 12:14:04 -0000 Hi Joel,=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 > Sent: Wednesday, September 28, 2011 8:11 PM > To: Templin, Fred L > Cc: Terry Manderson; lisp@ietf.org > Subject: Re: [lisp] LISP (re-)Charter discussion >=20 > Fred, "Authorized" is I think the wrong word to use to describe the=20 > publication. Or at least a misleading word. The IRTF=20 > process is such=20 > that the RG did not actually approve the publication of any of the=20 > solutions. The RG Chair sponsored the publication as an=20 > output of the=20 > RG. IRTF procedures explicitly recognize and allow for multiple=20 > minority reports from an RG. >=20 > I do agree that we should recognize that a number of ideas have been=20 > published as RFCs. And we should probably not be too specific about=20 > what the RG is doing, since that is liable to change. OK. How does this look for a rewrite: "A number of approaches have been published in parallel in the IRTF and IETF. In particular, the IRTF Routing Research Group (RRG) has published recommendations [RFC6115] and design goals [RFC6227], and has released three solution proposals for publication in IRON [RFC6179], hIPv4 [RFC6306] and ILNP [ILNP]." Thanks - Fred fred.l.templin@boeing.com > Yours, > Joel >=20 > On 9/28/2011 10:20 PM, Templin, Fred L wrote: > > Hi Terry, > > > > Regarding the 5th paragraph of the Draft Charter: > > > >> A number of approaches are being looked at in parallel in=20 > the IRTF and > >> IETF. At this time, these proposals are at an early stage. > > > > This needs to be updated; here is a proposed rewrite: > > > > "A number of approaches have been published in parallel in the > > IRTF and IETF. In particular, the IRTF Routing Research Group > > (RRG) has published its recommendations [RFC6115] and design > > goals [RFC6227], and has authorized the publication of three > > solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and > > ILNP [ILNP]." > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On > >> Behalf Of Terry Manderson > >> Sent: Wednesday, September 21, 2011 5:05 PM > >> To: lisp@ietf.org > >> Subject: [lisp] LISP (re-)Charter discussion > >> > >> Hi Folks, > >> > >> In Prague there was no strong consensus on modifying the LISP > >> Charter from > >> what it currently is, perhaps only updating the existing > >> Goals/Milestones. > >> > >> So no clear decision could be made. What I would like to do > >> is push out a > >> 'idea generating' draft charter that is _almost_ identical to > >> what we have > >> today. > >> > >> You can find the existing charter here: > >> https://datatracker.ietf.org/wg/lisp/charter/ > >> > >> The draft is below. > >> > >> So in light of such an approach, Joel and I discussed some > >> work items that > >> came from what was said at the mic in Prague and to us=20 > individually. > >> > >> They are: > >> > >> * Finish the deployment document > >> * Get the two security documents done > >> * Get an operational document at least started, which=20 > should include > >> cache management and ETR synchronization techniques. > >> * Either in the second security document, or in complementary > >> documents we > >> need to evaluate the security threat to cache maintenance, and > >> evaluate the applicability and coverage we get from a reuse of SIDR > >> technology. > >> > >> Is anything not represented here that you believe necessary? > >> and conversely > >> is there something here that is out of scope in your eyes? > >> > >> Are there work areas not covered by the draft below which you > >> believe should > >> be? > >> > >> Draft Charter > >> ------------ > >> > >> 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=20 > interest are > >> concerns about the scalability of the routing system and=20 > the impending > >> exhaustion of the IPv4 address space. Since the IAB=20 > workshop, several > >> proposals have emerged which attempt to address the=20 > 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=20 > 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=20 > identifies an > >> interface within a site. The "local" portion may be subdivided to > >> identify a particular network within the site. For a given=20 > 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=20 > identifiers > >> when it moves from one site to another or whenever it=20 > moves from one > >> subnet to another within an site. Typically, the same IP=20 > address will > >> not be used as an identifier and locator in LISP. > >> > >> LISP requires no changes to end-systems or to most=20 > routers. LISP aims > >> for an incrementally deployable protocol. > >> > >> A number of approaches are being looked at in parallel in=20 > the IRTF and > >> IETF. At this time, these proposals are at an early stage. > >> All proposals > >> (including LISP) have potentially harmful side-effects to Internet > >> traffic carried by the involved routers, have parts where=20 > deployment > >> incentives may be lacking, and are NOT RECOMMENDED for > >> deployment beyond > >> experimental situations at this stage. Many of the proposals have > >> components (such as the identifier to locator mapping=20 > system) where it > >> is not yet known what kind of design alternative is the=20 > best one among > >> many. > >> > >> However, despite these issues it would be valuable to=20 > write concrete > >> protocol specifications and develop implementations that can > >> be used to > >> understand the characteristics of these designs. 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 the ALT and/or other 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=20 > develop the final > >> or standard solution for solving the routing scalability=20 > problem. Its > >> specifications are Experimental and labeled with accurate=20 > 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.=20 > This analysis > >> will explain what role LISP can play in scalable routing.=20 > 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. > >> > >> > >> 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 lear@cisco.com Thu Sep 29 05:29:43 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 3147521F8CC5 for ; Thu, 29 Sep 2011 05:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 sB9aEac-asMh for ; Thu, 29 Sep 2011 05:29:39 -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 3CE1721F8CBE for ; Thu, 29 Sep 2011 05:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1779; q=dns/txt; s=iport; t=1317299549; x=1318509149; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=GVEBkCQfgJEtdv2AnJL6EOgHCR3VLOLMaMZSFx0KDns=; b=QhMVUltAl0RnWaz4txm6VLxR80b0l3vbm3S7kdE9zAaaxGUg5ewbUsgp yhfmXp5EkgHe6qRsj2IHyBRCYDeO1BJ3A+4xE+SJRqA2apX3Y5HGxdur6 WVIvbtvPxMlaA+CmMm+SUtfBIP6JszNqX8eWT2wFIyz6dWXoYqckXB0W4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8HAPZkhE6Q/khL/2dsb2JhbABBhGSUb445d4FKBQQBAQEBAxIBEEgNARALAwEdFgsCAgkDAgECAUUTAQcBAR6HUJlmAYxFkWuGAYESBJNWkTw X-IronPort-AV: E=Sophos;i="4.68,461,1312156800"; d="scan'208,217";a="56749138" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Sep 2011 12:32:28 +0000 Received: from elear-mac.local (ams3-vpn-dhcp2992.cisco.com [10.61.75.176]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8TCWSsd027677; Thu, 29 Sep 2011 12:32:28 GMT Message-ID: <4E846515.7030804@cisco.com> Date: Thu, 29 Sep 2011 14:31:17 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: robert@raszuk.net References: <4E838349.7090400@raszuk.net> In-Reply-To: <4E838349.7090400@raszuk.net> X-Enigmail-Version: 1.3.2 Content-Type: multipart/alternative; boundary="------------080708010607020904000104" 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: Thu, 29 Sep 2011 12:29:43 -0000 This is a multi-part message in MIME format. --------------080708010607020904000104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Robert, I think the question hangs on (1) where will the expertise be? Are they in ALTO or LISP or both? What expertise is needed? The IETF has addressed this problem in both dimensions that have been discussed. For example, the DHCP and DNSEXT groups are long standing precisely because the expertise necessary to extend those protocols can really only be found in those groups. It DOES require a flexible management view from within a working group. If orthodoxy sets in (and we've seen that before) clever engineers find ways to route around the damage. I am *not* here speaking of LISP, mind you. --------------080708010607020904000104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Robert, I think the question hangs on (1) where will the expertise be?  Are they in ALTO or LISP or both?  What expertise is needed?  The IETF has addressed this problem in both dimensions that have been discussed.  For example, the DHCP and DNSEXT groups are long standing precisely because the expertise necessary to extend those protocols can really only be found in those groups.  It DOES require a flexible management view from within a working group.  If orthodoxy sets in (and we've seen that before) clever engineers find ways to route around the damage.  I am not here speaking of LISP, mind you.
--------------080708010607020904000104-- From terry.manderson@icann.org Thu Sep 29 17:02: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 27E7B21F8C12 for ; Thu, 29 Sep 2011 17:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 1pse7vr1x2O6 for ; Thu, 29 Sep 2011 17:02:55 -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 4223121F8B91 for ; Thu, 29 Sep 2011 17:02:55 -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, 29 Sep 2011 17:05:47 -0700 From: Terry Manderson To: John Scudder Date: Thu, 29 Sep 2011 17:05:42 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+E9XyMdXoPxtXQQKmtCkQMJjnLwA8Nt2b 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 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: Fri, 30 Sep 2011 00:02:56 -0000 Hi John, On 29/09/11 5:21 AM, "John Scudder" wrote: > Terry, >=20 > It seems inappropriate to me that LISP be the sole WG that works on all t= hings > related to LISP.=20 I thought my words captured an openness stance, perhaps not. There is simply no way for LISP WG to mandate that all things LISP be here. And such a thing would not be healthy long term, and starts down the "not invented here" path. What I would like to see captured is that the LISP WG is there for people who wish to do work on LISP in the LISP WG in various applications. If a standards developer so chooses to push a work item that uses LISP in another WG, then that is their choice, and the choice of the target WG. Similarly, what I don't want to say is that "I'm sorry - LISP encapsulation of Carrier Pigeon doesn't belong here, see the Carrier Pigeon WG." For precisely the same reasons you mention. > It's standard IETF procedure for one WG to build on another > WG's protocol. There are many examples of this. Of course review by the= LISP > WG of any relevant specs (both prior to and during last call) may be > appropriate. This is also SOP. >=20 It will be a normal exercise to maintain awareness and communication with the other WGs when there is such a spec. Cheers Terry From terry.manderson@icann.org Thu Sep 29 17:15: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 133DF21F8DFC for ; Thu, 29 Sep 2011 17:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 ve1Qg5qo-AQO for ; Thu, 29 Sep 2011 17:15:35 -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 29CFC21F8D1B for ; Thu, 29 Sep 2011 17:15:35 -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; Thu, 29 Sep 2011 17:18:27 -0700 From: Terry Manderson To: "Templin, Fred L" , "Joel M. Halpern" Date: Thu, 29 Sep 2011 17:18:23 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+VWrzdmq1dUSIRyaBHAHIA/vhmgAS6pWQABlYbuI= 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 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: Fri, 30 Sep 2011 00:15:37 -0000 Fred, I'm not keen on specifically listing _any_ RFCs in the charter. It just doesn't add meaning at this stage of the WG lifecycle, in my opinion. How about a simpler: 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. This provides the reader of the charter with knowledge that there is a body of work "out there" and points to the RRG as a place to look first. Beyond that we would probably fall into the trap of listing almost every RFC that has (had) anything to do with scaling, EID/LOC split, encapsulation .. .. .= . etc. Cheers Terry On 29/09/11 10:16 PM, "Templin, Fred L" wrote: > Hi Joel, >=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, September 28, 2011 8:11 PM >> To: Templin, Fred L >> Cc: Terry Manderson; lisp@ietf.org >> Subject: Re: [lisp] LISP (re-)Charter discussion >>=20 >> Fred, "Authorized" is I think the wrong word to use to describe the >> publication. Or at least a misleading word. The IRTF >> process is such >> that the RG did not actually approve the publication of any of the >> solutions. The RG Chair sponsored the publication as an >> output of the >> RG. IRTF procedures explicitly recognize and allow for multiple >> minority reports from an RG. >>=20 >> I do agree that we should recognize that a number of ideas have been >> published as RFCs. And we should probably not be too specific about >> what the RG is doing, since that is liable to change. >=20 > OK. How does this look for a rewrite: >=20 > "A number of approaches have been published in parallel in the > IRTF and IETF. In particular, the IRTF Routing Research Group > (RRG) has published recommendations [RFC6115] and design goals > [RFC6227], and has released three solution proposals for > publication in IRON [RFC6179], hIPv4 [RFC6306] and ILNP [ILNP]." >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> Yours, >> Joel >>=20 >> On 9/28/2011 10:20 PM, Templin, Fred L wrote: >>> Hi Terry, >>>=20 >>> Regarding the 5th paragraph of the Draft Charter: >>>=20 >>>> A number of approaches are being looked at in parallel in >> the IRTF and >>>> IETF. At this time, these proposals are at an early stage. >>>=20 >>> This needs to be updated; here is a proposed rewrite: >>>=20 >>> "A number of approaches have been published in parallel in the >>> IRTF and IETF. In particular, the IRTF Routing Research Group >>> (RRG) has published its recommendations [RFC6115] and design >>> goals [RFC6227], and has authorized the publication of three >>> solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and >>> ILNP [ILNP]." >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>>> -----Original Message----- >>>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On >>>> Behalf Of Terry Manderson >>>> Sent: Wednesday, September 21, 2011 5:05 PM >>>> To: lisp@ietf.org >>>> Subject: [lisp] LISP (re-)Charter discussion >>>>=20 >>>> Hi Folks, >>>>=20 >>>> In Prague there was no strong consensus on modifying the LISP >>>> Charter from >>>> what it currently is, perhaps only updating the existing >>>> Goals/Milestones. >>>>=20 >>>> So no clear decision could be made. What I would like to do >>>> is push out a >>>> 'idea generating' draft charter that is _almost_ identical to >>>> what we have >>>> today. >>>>=20 >>>> You can find the existing charter here: >>>> https://datatracker.ietf.org/wg/lisp/charter/ >>>>=20 >>>> The draft is below. >>>>=20 >>>> So in light of such an approach, Joel and I discussed some >>>> work items that >>>> came from what was said at the mic in Prague and to us >> individually. >>>>=20 >>>> They are: >>>>=20 >>>> * Finish the deployment document >>>> * Get the two security documents done >>>> * Get an operational document at least started, which >> should include >>>> cache management and ETR synchronization techniques. >>>> * Either in the second security document, or in complementary >>>> documents we >>>> need to evaluate the security threat to cache maintenance, and >>>> evaluate the applicability and coverage we get from a reuse of SIDR >>>> technology. >>>>=20 >>>> Is anything not represented here that you believe necessary? >>>> and conversely >>>> is there something here that is out of scope in your eyes? >>>>=20 >>>> Are there work areas not covered by the draft below which you >>>> believe should >>>> be? >>>>=20 >>>> Draft Charter >>>> ------------ >>>>=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 >> the IRTF and >>>> IETF. At this time, these proposals are at an early stage. >>>> All proposals >>>> (including LISP) have potentially harmful side-effects to Internet >>>> traffic carried by the involved routers, have parts where >> deployment >>>> incentives may be lacking, and are NOT RECOMMENDED for >>>> deployment beyond >>>> experimental situations at this stage. Many of the proposals have >>>> components (such as the identifier to locator mapping >> system) where it >>>> is not yet known what kind of design alternative is the >> best one among >>>> many. >>>>=20 >>>> However, despite these issues it would be valuable to >> write concrete >>>> protocol specifications and develop implementations that can >>>> be used to >>>> understand the characteristics of these designs. 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 the ALT and/or other 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 >>>> Cheers >>>> Terry >>>>=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 >>=20 From terry.manderson@icann.org Thu Sep 29 17:30: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 75DCF21F85CE for ; Thu, 29 Sep 2011 17:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 vVddmunyWY6X for ; Thu, 29 Sep 2011 17:30:51 -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 128C221F85AE for ; Thu, 29 Sep 2011 17:30:51 -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; Thu, 29 Sep 2011 17:33:43 -0700 From: Terry Manderson To: Eliot Lear , "robert@raszuk.net" Date: Thu, 29 Sep 2011 17:33:39 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+o+aeAK+tBkKhTV+/0306gqAalgAZLJed Message-ID: In-Reply-To: <4E846515.7030804@cisco.com> 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: Fri, 30 Sep 2011 00:30:51 -0000 Taking the workgroup 'hat' off for a moment (I was going to say 'underpants', but that is just a _bad_ mental image :) I think what Eliot says here holds true. In respect to LISP there is a level of expertise here. However adopting a view that we be exclusive to a core is a little premature. Perhaps in time = a LISP-EXT might pop up, perhaps not. Your observation about preferring ALTO is actually a perfect example of preference. You might prefer to go to ALTO, others may choose LISP. The bottom line for me is not seeing a meaningless turf war commence over standards work. The ultimate win is that the work gets done. Not specifically which WG it ends up in, as I'm sure that there will be sufficient review (both volunteered and requested) by many parties from various WGs and areas. Cheers Terry On 29/09/11 10:31 PM, "Eliot Lear" wrote: > Robert, I think the question hangs on (1) where will the expertise be?= =A0 Are > they in ALTO or LISP or both?=A0 What expertise is needed?=A0 The IETF ha= s > addressed this problem in both dimensions that have been discussed.=A0 Fo= r > example, the DHCP and DNSEXT groups are long standing precisely because t= he > expertise necessary to extend those protocols can really only be found in > those groups.=A0 It DOES require a flexible management view from within a > working group.=A0 If orthodoxy sets in (and we've seen that before) cleve= r > engineers find ways to route around the damage.=A0 I am not here speaking= of > LISP, mind you. > =20 From terry.manderson@icann.org Thu Sep 29 17:38: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 314DF21F8B94 for ; Thu, 29 Sep 2011 17:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.168 X-Spam-Level: X-Spam-Status: No, score=-106.168 tagged_above=-999 required=5 tests=[AWL=-0.169, 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 gfuCRpVrP7ne for ; Thu, 29 Sep 2011 17:38:45 -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 3046621F8B1D for ; Thu, 29 Sep 2011 17:38:45 -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, 29 Sep 2011 17:41:37 -0700 From: Terry Manderson To: "Victor Moreno (vimoreno)" , Dino Farinacci Date: Thu, 29 Sep 2011 17:41:33 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx5TIaevaA3w2i0T9e8wLpgRLaj2gDf8fv2AAF3XfAAjeHhlA== Message-ID: In-Reply-To: <40966CDBEF22C64F84F20BD68D445B210168BD8C@xmb-sjc-212.amer.cisco.com> 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: Fri, 30 Sep 2011 00:38:46 -0000 Hi Victor, I think authority and ownership are stretches of the vocabulary. I am concerned about protocol cohesion, and I'd like the WG to be the preferred place (i.e "gravitate") for LISP related work. But saying that LISP is the locus of control for all this LISP might be a tad far :) I think we should also keep in mind that LISP is heading for Experimental publication which means any work that uses LISP in the majority at this point in time will probably/possibly also end up as Experimental given downref considerations. Cheers Terry On 27/09/11 3:02 PM, "Victor Moreno (vimoreno)" wrote: > LISP is a bit unique in that it can enable many applications > concurrently. >=20 > If the effort for each application is spun off to different groups, each > thread will evolve independently and with that the cohesion of the > protocol may quickly be lost. >=20 > IMO it is important that the WG retains ownership/authority over all > things LISP. >=20 > -v >=20 >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf > Of >> Terry Manderson >> Sent: Monday, September 26, 2011 9:17 PM >> To: Dino Farinacci (dino) >> Cc: lisp@ietf.org >> Subject: Re: [lisp] LISP (re-)Charter discussion >>=20 >> Thanks Dino, >>=20 >> I encourage all LISP WG members to reflect on the questions below and > voice >> an opinion. >>=20 >> To paraphrase what Dino has written, one proposal (and Dino correct me > if >> I've oversimplified) is that the LISP WG should become a working group > that >> contains ALL things LISP. So wherever a body of work uses LISP >> encapsulation, or LISP mapping it may gravitate to here to maintain > LISP >> interoperability and (where appropriate) protocol cohesion. >>=20 >> ..discuss. >>=20 >> :) >>=20 >> Cheers >> Terry >>=20 >>=20 >> On 23/09/11 3:24 AM, "Dino Farinacci" wrote: >>=20 >>> Terry, what I would like to know first and foremost, before adding > any >>> specific feature or use-cases to the charter is if they *should* > belong >> in the >>> LISP working group charter versus being owne by another working > group. >> And >>> what the working group thinks about this. I will give some examples > to >> get >>> some clarity and to be more specific. >>>=20 >>> (1) LISP could be used for many data-center use-cases. >>> (2) LISP could be used for device mobility. >>> (3) LISP could be used as a IPv6 coexistence solution while > delivering >> route >>> table reduction and low opex multihoming. >>> (4) LISP could be used as a VPN solution. >>> (5) The mapping database could be used for other applications like >> keeping >>> track of multicast group membership. >>>=20 >>> So, to enumerate each one: >>>=20 >>> For (1), does the LISP WG take this on or is there a data-center > specific >>> protocol solution working group (ARMD is not that working group > because >> it is >>> a requirement definition working group)? >>>=20 >>> For (2), the MOBOPTs IRTF research group seem to take interest in > LISP- >> MN. >>> Does it do the initial work and have it spin off a mobility working >> group, >>> which there are many already. To add, there is a cross-product issue > too >> since >>> LISP-Multicast can run in a LISP-MN implementation and there is a >> multimob >>> working group already established. >>>=20 >>> For (3), there are zillions of solutions and places where this > occurs >> over the >>> last decade, I would suggest not spinning another working group for > this >> and >>> have the LISP working group be "address-family" agnostic which would > also >>> include MAC addressing as a address-family as well a GPS > coordinates. >>>=20 >>> For (4), again, coupled with (3), LISP can do L2-over-L3, > L3-over-L3, as >> well >>> as the other 2 combinations, does the VPN use-case stay in the LISP >> working >>> group or is it fragmented to be taken to each L2VPN and L3VPN > working >> groups. >>>=20 >>> For (5), we do not want to error where everything is put into DNS >> (because it >>> is the only applicaiton level wide-area/multi-organizational > distributed >>> database). In our case the mapping database. And moreoever, if the > use- >> case >>> functionality is distributed to other working groups, will there be >> design >>> change requests to the mapping database design coming from too many >> source >>> points. >>>=20 >>> As you can see, this can get very complex and confusing and could > result >> in >>> design fragmentation and opportunity for competitive proposals. All > which >> turn >>> out to add more inefficiencies to the protocol design process which >> nearly >>> always results in undeployable compromises. >>>=20 >>> Dino >>>=20 >>> On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote: >>>=20 >>>> Hi Folks, >>>>=20 >>>> In Prague there was no strong consensus on modifying the LISP > Charter >> from >>>> what it currently is, perhaps only updating the existing >> Goals/Milestones. >>>>=20 >>>> So no clear decision could be made. What I would like to do is push > out >> a >>>> 'idea generating' draft charter that is _almost_ identical to what > we >> have >>>> today. >>>>=20 >>>> You can find the existing charter here: >>>> https://datatracker.ietf.org/wg/lisp/charter/ >>>>=20 >>>> The draft is below. >>>>=20 >>>> So in light of such an approach, Joel and I discussed some work > items >> that >>>> came from what was said at the mic in Prague and to us > individually. >>>>=20 >>>> They are: >>>>=20 >>>> * Finish the deployment document >>>> * Get the two security documents done >>>> * Get an operational document at least started, which should > include >>>> cache management and ETR synchronization techniques. >>>> * Either in the second security document, or in complementary > documents >> we >>>> need to evaluate the security threat to cache maintenance, and >>>> evaluate the applicability and coverage we get from a reuse of SIDR >>>> technology. >>>>=20 >>>> Is anything not represented here that you believe necessary? and >> conversely >>>> is there something here that is out of scope in your eyes? >>>>=20 >>>> Are there work areas not covered by the draft below which you > believe >> should >>>> be? >>>>=20 >>>> Draft Charter >>>> ------------ >>>>=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 the IRTF > and >>>> IETF. At this time, these proposals are at an early stage. All > proposals >>>> (including LISP) have potentially harmful side-effects to Internet >>>> traffic carried by the involved routers, have parts where > deployment >>>> incentives may be lacking, and are NOT RECOMMENDED for deployment > beyond >>>> experimental situations at this stage. Many of the proposals have >>>> components (such as the identifier to locator mapping system) where > it >>>> is not yet known what kind of design alternative is the best one > among >>>> many. >>>>=20 >>>> However, despite these issues it would be valuable to write > concrete >>>> protocol specifications and develop implementations that can be > used to >>>> understand the characteristics of these designs. 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 the ALT and/or other 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 >>>> Cheers >>>> Terry >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From Fred.L.Templin@boeing.com Fri Sep 30 08:03:06 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 C223D21F8B54 for ; Fri, 30 Sep 2011 08:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 WkS14vHiHvLl for ; Fri, 30 Sep 2011 08:03:05 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD421F8B3F for ; Fri, 30 Sep 2011 08:03:05 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8UF5SJX027389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Sep 2011 08:05:29 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p8UF5RcJ000362; Fri, 30 Sep 2011 10:05:27 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8UF57KZ029699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 30 Sep 2011 10:05:26 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 30 Sep 2011 08:05:26 -0700 From: "Templin, Fred L" To: Terry Manderson , "Joel M. Halpern" Date: Fri, 30 Sep 2011 08:05:23 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+VWrzdmq1dUSIRyaBHAHIA/vhmgAS6pWQABlYbuIAHsMcsA== Message-ID: References: In-Reply-To: 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: "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: Fri, 30 Sep 2011 15:03:06 -0000 Hi Terry,=20 > -----Original Message----- > From: Terry Manderson [mailto:terry.manderson@icann.org]=20 > Sent: Thursday, September 29, 2011 5:18 PM > To: Templin, Fred L; Joel M. Halpern > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP (re-)Charter discussion >=20 > Fred, >=20 > I'm not keen on specifically listing _any_ RFCs in the=20 > charter. It just > doesn't add meaning at this stage of the WG lifecycle, in my opinion. >=20 > How about a simpler: >=20 > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of=20 > which were > published as IRTF-track Experimental RFCs. > This provides the reader of the charter with knowledge that=20 > there is a body > of work "out there" and points to the RRG as a place to look=20 > first. Beyond > that we would probably fall into the trap of listing almost=20 > every RFC that > has (had) anything to do with scaling, EID/LOC split,=20 > encapsulation .. .. .. > etc. >=20 > Cheers > Terry >=20 >=20 > On 29/09/11 10:16 PM, "Templin, Fred L"=20 > wrote: >=20 > > Hi Joel, > >=20 > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Wednesday, September 28, 2011 8:11 PM > >> To: Templin, Fred L > >> Cc: Terry Manderson; lisp@ietf.org > >> Subject: Re: [lisp] LISP (re-)Charter discussion > >>=20 > >> Fred, "Authorized" is I think the wrong word to use to describe the > >> publication. Or at least a misleading word. The IRTF > >> process is such > >> that the RG did not actually approve the publication of any of the > >> solutions. The RG Chair sponsored the publication as an > >> output of the > >> RG. IRTF procedures explicitly recognize and allow for multiple > >> minority reports from an RG. > >>=20 > >> I do agree that we should recognize that a number of ideas=20 > have been > >> published as RFCs. And we should probably not be too=20 > specific about > >> what the RG is doing, since that is liable to change. > >=20 > > OK. How does this look for a rewrite: > >=20 > > "A number of approaches have been published in parallel in the > > IRTF and IETF. In particular, the IRTF Routing Research Group > > (RRG) has published recommendations [RFC6115] and design goals > > [RFC6227], and has released three solution proposals for > > publication in IRON [RFC6179], hIPv4 [RFC6306] and=20 > ILNP [ILNP]." > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >> Yours, > >> Joel > >>=20 > >> On 9/28/2011 10:20 PM, Templin, Fred L wrote: > >>> Hi Terry, > >>>=20 > >>> Regarding the 5th paragraph of the Draft Charter: > >>>=20 > >>>> A number of approaches are being looked at in parallel in > >> the IRTF and > >>>> IETF. At this time, these proposals are at an early stage. > >>>=20 > >>> This needs to be updated; here is a proposed rewrite: > >>>=20 > >>> "A number of approaches have been published in parallel in the > >>> IRTF and IETF. In particular, the IRTF Routing Research Group > >>> (RRG) has published its recommendations [RFC6115] and design > >>> goals [RFC6227], and has authorized the publication of three > >>> solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and > >>> ILNP [ILNP]." > >>>=20 > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>>=20 > >>>> -----Original Message----- > >>>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On > >>>> Behalf Of Terry Manderson > >>>> Sent: Wednesday, September 21, 2011 5:05 PM > >>>> To: lisp@ietf.org > >>>> Subject: [lisp] LISP (re-)Charter discussion > >>>>=20 > >>>> Hi Folks, > >>>>=20 > >>>> In Prague there was no strong consensus on modifying the LISP > >>>> Charter from > >>>> what it currently is, perhaps only updating the existing > >>>> Goals/Milestones. > >>>>=20 > >>>> So no clear decision could be made. What I would like to do > >>>> is push out a > >>>> 'idea generating' draft charter that is _almost_ identical to > >>>> what we have > >>>> today. > >>>>=20 > >>>> You can find the existing charter here: > >>>> https://datatracker.ietf.org/wg/lisp/charter/ > >>>>=20 > >>>> The draft is below. > >>>>=20 > >>>> So in light of such an approach, Joel and I discussed some > >>>> work items that > >>>> came from what was said at the mic in Prague and to us > >> individually. > >>>>=20 > >>>> They are: > >>>>=20 > >>>> * Finish the deployment document > >>>> * Get the two security documents done > >>>> * Get an operational document at least started, which > >> should include > >>>> cache management and ETR synchronization techniques. > >>>> * Either in the second security document, or in complementary > >>>> documents we > >>>> need to evaluate the security threat to cache maintenance, and > >>>> evaluate the applicability and coverage we get from a=20 > reuse of SIDR > >>>> technology. > >>>>=20 > >>>> Is anything not represented here that you believe necessary? > >>>> and conversely > >>>> is there something here that is out of scope in your eyes? > >>>>=20 > >>>> Are there work areas not covered by the draft below which you > >>>> believe should > >>>> be? > >>>>=20 > >>>> Draft Charter > >>>> ------------ > >>>>=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=20 > 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=20 > 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=20 > (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=20 > 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 > >> the IRTF and > >>>> IETF. At this time, these proposals are at an early stage. > >>>> All proposals > >>>> (including LISP) have potentially harmful side-effects=20 > to Internet > >>>> traffic carried by the involved routers, have parts where > >> deployment > >>>> incentives may be lacking, and are NOT RECOMMENDED for > >>>> deployment beyond > >>>> experimental situations at this stage. Many of the proposals have > >>>> components (such as the identifier to locator mapping > >> system) where it > >>>> is not yet known what kind of design alternative is the > >> best one among > >>>> many. > >>>>=20 > >>>> However, despite these issues it would be valuable to > >> write concrete > >>>> protocol specifications and develop implementations that can > >>>> be used to > >>>> understand the characteristics of these designs. 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 the ALT and/or other=20 > 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=20 > 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=20 > understood, the > >>>> working group will analyze and document the implications=20 > 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 > >>>> Cheers > >>>> Terry > >>>>=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 > >>=20 >=20 > = From Fred.L.Templin@boeing.com Fri Sep 30 08:32:58 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 3D2A621F8B14 for ; Fri, 30 Sep 2011 08:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 fBmPRHcFZenG for ; Fri, 30 Sep 2011 08:32:57 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9C321F8AD3 for ; Fri, 30 Sep 2011 08:32:57 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p8UFWvmn013576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Sep 2011 08:32:57 -0700 (PDT) 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 p8UFWuEg019203; Fri, 30 Sep 2011 08:32:56 -0700 (PDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p8UFWYHw018333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 30 Sep 2011 08:32:56 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 30 Sep 2011 08:32:46 -0700 From: "Templin, Fred L" To: Terry Manderson , "Joel M. Halpern" Date: Fri, 30 Sep 2011 08:32:45 -0700 Thread-Topic: [lisp] LISP (re-)Charter discussion Thread-Index: Acx+VWrzdmq1dUSIRyaBHAHIA/vhmgAS6pWQABlYbuIAHwCCwA== Message-ID: References: In-Reply-To: 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: "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: Fri, 30 Sep 2011 15:32:58 -0000 Hi Terry, > -----Original Message----- > From: Terry Manderson [mailto:terry.manderson@icann.org]=20 > Sent: Thursday, September 29, 2011 5:18 PM > To: Templin, Fred L; Joel M. Halpern > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP (re-)Charter discussion >=20 > Fred, >=20 > I'm not keen on specifically listing _any_ RFCs in the=20 > charter. It just > doesn't add meaning at this stage of the WG lifecycle, in my opinion. >=20 > How about a simpler: >=20 > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of=20 > which were > published as IRTF-track Experimental RFCs. >=20 > This provides the reader of the charter with knowledge that=20 > there is a body > of work "out there" and points to the RRG as a place to look=20 > first.=20 I would agree if the charter could point to a webpage that lists the RRG RFC publications, i.e., in the same way that IETF working group wepages do. But, the only RRG webpages I have found have outdated and incomplete information, and do not cite the RFC publications. So, I would prefer to include the text I proposed, or something close to it, since the work is so closely related to LISP. > Beyond > that we would probably fall into the trap of listing almost=20 > every RFC that > has (had) anything to do with scaling, EID/LOC split,=20 > encapsulation .. .. .. > etc. I don't think this would become a slippery slope. LISP spun off out of the RRG albeit in a slightly different manner than did IRON, hIPv4 and ILNP. But, as of this time (and for the forseeable future AFAICT) those are the only four solution proposals to emerge out of the RRG. Thanks - Fred fred.l.templin@boeing.com =20 > Cheers > Terry >=20 >=20 > On 29/09/11 10:16 PM, "Templin, Fred L"=20 > wrote: >=20 > > Hi Joel, > >=20 > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Wednesday, September 28, 2011 8:11 PM > >> To: Templin, Fred L > >> Cc: Terry Manderson; lisp@ietf.org > >> Subject: Re: [lisp] LISP (re-)Charter discussion > >>=20 > >> Fred, "Authorized" is I think the wrong word to use to describe the > >> publication. Or at least a misleading word. The IRTF > >> process is such > >> that the RG did not actually approve the publication of any of the > >> solutions. The RG Chair sponsored the publication as an > >> output of the > >> RG. IRTF procedures explicitly recognize and allow for multiple > >> minority reports from an RG. > >>=20 > >> I do agree that we should recognize that a number of ideas=20 > have been > >> published as RFCs. And we should probably not be too=20 > specific about > >> what the RG is doing, since that is liable to change. > >=20 > > OK. How does this look for a rewrite: > >=20 > > "A number of approaches have been published in parallel in the > > IRTF and IETF. In particular, the IRTF Routing Research Group > > (RRG) has published recommendations [RFC6115] and design goals > > [RFC6227], and has released three solution proposals for > > publication in IRON [RFC6179], hIPv4 [RFC6306] and=20 > ILNP [ILNP]." > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >> Yours, > >> Joel > >>=20 > >> On 9/28/2011 10:20 PM, Templin, Fred L wrote: > >>> Hi Terry, > >>>=20 > >>> Regarding the 5th paragraph of the Draft Charter: > >>>=20 > >>>> A number of approaches are being looked at in parallel in > >> the IRTF and > >>>> IETF. At this time, these proposals are at an early stage. > >>>=20 > >>> This needs to be updated; here is a proposed rewrite: > >>>=20 > >>> "A number of approaches have been published in parallel in the > >>> IRTF and IETF. In particular, the IRTF Routing Research Group > >>> (RRG) has published its recommendations [RFC6115] and design > >>> goals [RFC6227], and has authorized the publication of three > >>> solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and > >>> ILNP [ILNP]." > >>>=20 > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>>=20 > >>>> -----Original Message----- > >>>> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On > >>>> Behalf Of Terry Manderson > >>>> Sent: Wednesday, September 21, 2011 5:05 PM > >>>> To: lisp@ietf.org > >>>> Subject: [lisp] LISP (re-)Charter discussion > >>>>=20 > >>>> Hi Folks, > >>>>=20 > >>>> In Prague there was no strong consensus on modifying the LISP > >>>> Charter from > >>>> what it currently is, perhaps only updating the existing > >>>> Goals/Milestones. > >>>>=20 > >>>> So no clear decision could be made. What I would like to do > >>>> is push out a > >>>> 'idea generating' draft charter that is _almost_ identical to > >>>> what we have > >>>> today. > >>>>=20 > >>>> You can find the existing charter here: > >>>> https://datatracker.ietf.org/wg/lisp/charter/ > >>>>=20 > >>>> The draft is below. > >>>>=20 > >>>> So in light of such an approach, Joel and I discussed some > >>>> work items that > >>>> came from what was said at the mic in Prague and to us > >> individually. > >>>>=20 > >>>> They are: > >>>>=20 > >>>> * Finish the deployment document > >>>> * Get the two security documents done > >>>> * Get an operational document at least started, which > >> should include > >>>> cache management and ETR synchronization techniques. > >>>> * Either in the second security document, or in complementary > >>>> documents we > >>>> need to evaluate the security threat to cache maintenance, and > >>>> evaluate the applicability and coverage we get from a=20 > reuse of SIDR > >>>> technology. > >>>>=20 > >>>> Is anything not represented here that you believe necessary? > >>>> and conversely > >>>> is there something here that is out of scope in your eyes? > >>>>=20 > >>>> Are there work areas not covered by the draft below which you > >>>> believe should > >>>> be? > >>>>=20 > >>>> Draft Charter > >>>> ------------ > >>>>=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=20 > 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=20 > 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=20 > (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=20 > 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 > >> the IRTF and > >>>> IETF. At this time, these proposals are at an early stage. > >>>> All proposals > >>>> (including LISP) have potentially harmful side-effects=20 > to Internet > >>>> traffic carried by the involved routers, have parts where > >> deployment > >>>> incentives may be lacking, and are NOT RECOMMENDED for > >>>> deployment beyond > >>>> experimental situations at this stage. Many of the proposals have > >>>> components (such as the identifier to locator mapping > >> system) where it > >>>> is not yet known what kind of design alternative is the > >> best one among > >>>> many. > >>>>=20 > >>>> However, despite these issues it would be valuable to > >> write concrete > >>>> protocol specifications and develop implementations that can > >>>> be used to > >>>> understand the characteristics of these designs. 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 the ALT and/or other=20 > 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=20 > 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=20 > understood, the > >>>> working group will analyze and document the implications=20 > 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 > >>>> Cheers > >>>> Terry > >>>>=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 > >>=20 >=20 > = From scott.brim@gmail.com Fri Sep 30 09:15:13 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 C52F221F8CCE for ; Fri, 30 Sep 2011 09:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 JYNXMBXMCVgW for ; Fri, 30 Sep 2011 09:15:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38E0121F8C4C for ; Fri, 30 Sep 2011 09:15:13 -0700 (PDT) Received: by gyd12 with SMTP id 12so2034241gyd.31 for ; Fri, 30 Sep 2011 09:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QFNIckJKx+JPE5QYzE2JRFo/3s3WIdUr22cPMvKg7Y8=; b=EPEr+NEIbQ8a77/pRfW4L7l5GnNF7A2GHrmNLtfQWGTq9EdEBPmGtM+oVNZ5UUIpy2 k1FYy3ej61/gc3xFc6cL0T/tuKKSdshDSDc9Xpu+4jSvcC+lWPy9krE75z+UhC6Acx8/ 905FGEw6kLL3iwYiHPzQYs+KFLM/kzE8+7o1Y= Received: by 10.236.156.67 with SMTP id l43mr56291995yhk.10.1317399487207; Fri, 30 Sep 2011 09:18:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.82.18 with HTTP; Fri, 30 Sep 2011 09:17:47 -0700 (PDT) In-Reply-To: References: From: Scott Brim Date: Fri, 30 Sep 2011 12:17:47 -0400 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 30 Sep 2011 16:15:13 -0000 On Fri, Sep 30, 2011 at 11:32, Templin, Fred L wrote: > I would agree if the charter could point to a webpage > that lists the RRG RFC publications, i.e., in the same > way that IETF working group wepages do. But, the only > RRG webpages I have found have outdated and incomplete > information, and do not cite the RFC publications. So, > I would prefer to include the text I proposed, or > something close to it, since the work is so closely > related to LISP. IMHO a WG charter is not the place to have a listing of other drafts/RFCs that are not in scope, even if they are related somehow. If other pages are outdated, that's where the problem should be fixed. Scott From dino@cisco.com Fri Sep 30 10:24: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 83C0E21F8C80 for ; Fri, 30 Sep 2011 10:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=-0.683, 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 qaQykmvOZosU for ; Fri, 30 Sep 2011 10:24:14 -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 D0B9D21F8C33 for ; Fri, 30 Sep 2011 10:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1172; q=dns/txt; s=iport; t=1317403629; x=1318613229; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pJH32V3I+9xFDrGSYeLImNSrm8Vd3yxhfZVCSb77n6A=; b=UqZNnomWkZKw0B7v8sqXDr61Icx+w4HiulsZHU/TzdLkA6DZyMCf4ukW gfbN+BV4K35luQseAE4K2H2JFrDEarxhyHXyZD50+f+q6WWICJRv7CbOc ZeYAGedb6JokUqzcjTP0JCIygH94oczpMSdhi4l7gczDH/fL8qYHjy18B M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMz6hU6rRDoI/2dsb2JhbABBqDKBBYFTAQEBAwEBAQEPASc0CwULCxguJzAGEyKHWQaZYAGeEQOGP2EEh3aLZpFd X-IronPort-AV: E=Sophos;i="4.68,468,1312156800"; d="scan'208";a="5267024" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 30 Sep 2011 17:27:09 +0000 Received: from sjc-vpn3-467.cisco.com (sjc-vpn3-467.cisco.com [10.21.65.211]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8UHR9kh012545; Fri, 30 Sep 2011 17:27:09 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: Date: Fri, 30 Sep 2011 10:27:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85EECE4F-6AA6-4A19-BEA2-3D7BBA0BAA74@cisco.com> References: To: Scott Brim X-Mailer: Apple Mail (2.1244.3) 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: Fri, 30 Sep 2011 17:24:15 -0000 If we can't agree what is going into a charter, how we are going to = agree where work is going to happen with even a bigger audience to = decide. The focus is all wrong. The focus should be on the work and not the = process. Dino On Sep 30, 2011, at 9:17 AM, Scott Brim wrote: > On Fri, Sep 30, 2011 at 11:32, Templin, Fred L > wrote: >> I would agree if the charter could point to a webpage >> that lists the RRG RFC publications, i.e., in the same >> way that IETF working group wepages do. But, the only >> RRG webpages I have found have outdated and incomplete >> information, and do not cite the RFC publications. So, >> I would prefer to include the text I proposed, or >> something close to it, since the work is so closely >> related to LISP. >=20 > IMHO a WG charter is not the place to have a listing of other > drafts/RFCs that are not in scope, even if they are related somehow. > If other pages are outdated, that's where the problem should be fixed. >=20 > Scott > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jari.arkko@piuha.net Fri Sep 30 15:50: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 D18C91F0C3E for ; Fri, 30 Sep 2011 15:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 LA1TtCyzH+Fx for ; Fri, 30 Sep 2011 15:50:39 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5C06921F8AE9 for ; Fri, 30 Sep 2011 15:50:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6B9BF2CEFF; Sat, 1 Oct 2011 01:53:32 +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 aGcvr6f5PY1I; Sat, 1 Oct 2011 01:53:31 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 109812CE32; Sat, 1 Oct 2011 01:53:31 +0300 (EEST) Message-ID: <4E86486A.6010402@piuha.net> Date: Sat, 01 Oct 2011 01:53:30 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp (part 1) 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, 30 Sep 2011 22:50:41 -0000 I am reviewing this draft. Here's the first part of my review. So far I like what I've seen, but there are a few small observations below. I'm at the beginning of Section 4, and will continue tomorrow with the rest. Technical: > 2. Introduction I liked how this section was written. I would like to add a little bit of information, however. The section already talks about experimentation around the mapping system, but like with the other documents it would be useful to explicitly point out the areas where some further testing is needed. I presume it is more than just the mapping system. > 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. It is of course fine to have transient conditions like this. But I'm trying hard to convince myself that this would never have negative implications. Why would this be the case? What if we for some reason needed to quickly add or remove an EID prefix? Wouldn't there be a short negative implication if a particular ETR did not yet add a new prefix, for instance? I guess I'm wondering why you are making such an absolute statement about the lack of implications. Maybe saying nothing or saying "This has usually no negative implications" would be better. Editorial: > This document describes the protocol that implements these functions. > The database which stores the mappings between EIDs and RLOCs is > 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. > I think the introduction would be a good place to add some pointers to not just ALT/MS and their competing alternatives but also to -interworking and perhaps also -map-versioning and -multicast. > LISP can be incrementally deployed, without a "flag > day", and offers traffic engineering, multi-homing, and mobility > benefits even to early adopters, when there are relatively few LISP- > capable sites. s/when/even when/ (sounds better to me, but I'm not a native speaker) I think the mobility benefits could be left to another document, since there is nothing about this in the current set of documents. I think your message about the benefits will be stronger if you just say "traffic engineeering and multi-homing benefits". > == Outdated reference: A later version (-05) exists of > draft-ietf-karp-design-guide-02 > > ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) > > == Outdated reference: A later version (-09) exists of > draft-ietf-lisp-alt-07 > > == Outdated reference: A later version (-06) exists of > draft-ietf-lisp-lig-02 > > == Outdated reference: A later version (-11) exists of draft-ietf-lisp-ms-09 > > == Outdated reference: A later version (-08) exists of > draft-ietf-lisp-multicast-06 > > -- Unexpected draft version: The latest known version of > draft-iannone-openlisp-implementation is -01, but you're referring to -02. > > -- No information found for draft-handley-p2ppush-unpublished-2007726 - is > the name correct? > > == Outdated reference: A later version (-04) exists of > draft-ietf-lisp-map-versioning-01 > These could perhaps be fixed. > == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the > document. > o Source host "host1.example.abc.com" is sending a packet to > "host2.example.xyz.com", exactly what host1 would do if the site > was not using LISP. > These need to change. We should not use non-RFC2606 FQDNs. For instance, abc.com in particular is someone else's domain. Use host1.abc.example.com or example.com vs. example.net. > Reachability Algoriths described in Section 6.3. typo > homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 homogeneous Jari
attack is enabled.
<= FONT=20 color=3D#0000ff>   

One "funny" attack is by spoofing at the = same=20 time the EID and
the RLOC.

Without cryptography, there is no perfect= =20 solution to avoid
spoofing. Your example with dynamic RLOC = is=20 interesting.
If everything goes well, you should never= have=20 a TTL
longer than the RLOC lease time. However,= in=20 the case
the RLOC changes before the expiration, y= ou=20 will need
SMR or version change implying the retrie= val=20 of the new
mapping. But in this particular case, you= also=20 have a
security threat that is a=20 DoS...

Do you see a clear way past these and other= =20 threats?
Will it be the case that LISP and its ilk w= ill=20 be
hard to secure and thus difficult to=20 deploy?

I think that by taking care of how LISP is=20 deployed and how
the features are used, it is possible to achi= eve=20 the same level
of security than today. Doing more is possibl= e,=20 but I am not sure
that people are ready to have to deal with=20 cryptography. For
example, if you want to protect against spoof= ing,=20 you can sign
the packets (or part of) but then you need a = way=20 to know the key
used to sign.

Do you really want to go to that=20 direction?

Do I really want to go in the direction of=20 requiring
cryptography? I can't answer that unless you first
tell= me=20 the intended domain of applicability. I don't
think I have yet seen = a use=20 case analysis of the
various scenarios where LISP xTRs and mapping=20 systems
would be deployed and used. There seems to be an
unspoken= =20 assumption of deployment "in the public
Internet", but what about=20 Enterprise networks?
What about MANETs? What about aviation=20 networks?
What about tactical military networks? What about
cellu= lar=20 networks? What about home networks?


That is the purpose of the deployment document.

http://= tools.ietf.org/html/draft-ietf-lisp-deployment-01 
 
From a brief look, that document appears to have quite a ways=20 to
go until it considers a wider variety of use cases such as we= =20 have
addressed in RANGERS. The document also seems to=20 carefully
step around the MTU issue, as if it were a booby trap to be=20 always
on guard for. IRON (with SEAL) *solves* the MTU issue so=20 that
there is no longer any need to worry about it. Until LISP=20 truly
addresses the MTU issue (including accounting for the=20 common
case of operators misconfiguring link MTUs) all=20 LISP-related
documents will have to carefully dance around=20 it.
 
Fred
fred.l.templin@boeing.com

Luigi

--_000_E1829B60731D1740BB7A0626B4FAF0A65C77282413XCHNW01Vnwnos_-- From luigi@net.t-labs.tu-berlin.de Tue Sep 20 10:03: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 A081C21F8B51 for ; Tue, 20 Sep 2011 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.129, 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 GU1HLkkLLtOO for ; Tue, 20 Sep 2011 10:03:52 -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 183CF21F8B50 for ; Tue, 20 Sep 2011 10:03:52 -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 D7E5B70629E9; Tue, 20 Sep 2011 19:06:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_E0C98E74-B3BE-4160-893B-AC62EFFAC089" From: Luigi Iannone In-Reply-To: Date: Tue, 20 Sep 2011 19:06:14 +0200 Message-Id: <3901ED5D-BC5C-4C0D-B859-1FAF5510EDB5@net.t-labs.tu-berlin.de> References: <20110914142929.11906.18076.idtracker@ietfa.amsl.com> <7A372F62-7BE2-47B9-902D-536AB0910C09@uclouvain.be> <599D27DB-35D6-4044-88F5-C576EAF9242A@uclouvain.be> <6C577345-67B1-47C6-891D-BDDCD5DBF08E@net.t-labs.tu-berlin.de> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1244.3) Cc: "lisp@ietf.org" Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? 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, 20 Sep 2011 17:03:53 -0000 --Apple-Mail=_E0C98E74-B3BE-4160-893B-AC62EFFAC089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Fred,=20 thanks for the effort=85. About your middle box example, why this example is different any other = reflection attack? The middle box must be somewhere in the network so that its traffic is = not filtered due to the use of a specific source RLOC. But in that case you do not need LISP to carry out a reflection attack. = Hence LISP does not introduce any security hole. Or I misunderstand something? Luigi On Sep 20, 2011, at 17:21 , Templin, Fred L wrote: > Luigi, > =20 > I really, really hate trying to annotate things when people turn them > into html instead of leaving them as plaintext. But since you insist: >=20 > From: Luigi Iannone [mailto:luigi@net.t-labs.tu-berlin.de]=20 > Sent: Tuesday, September 20, 2011 12:31 AM > To: Templin, Fred L > Cc: Damien Saucez; lisp@ietf.org > Subject: Re: [lisp] Source address spoofing by a node pretending to be = an ITR? >=20 > Hi Fred, >=20 > On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: >=20 > [snip] >>=20 >>> The hidden idea behind the threat draft is "if we do not manage to >>> make a system more secured than the current Internet, at least we >>> must have a system that is not less secure." >>=20 >> That's why I said: "But, perhaps a case can be made that >> on-path attacks are no more a matter for concern for LISP >> than they are for the non-LISP public Internet?". >>=20 >> Still, if an off-path attacker can spoof the EID source >> address even if it cannot spoof the RLOC source address, >> the end result is a system that is less secure than the >> current Internet - right? >=20 > Can you explain why?=20 >=20 > I would say the contrary. If an attacker cannot spoof RLOC it means = that the DFZ is more robust - right?=20 > =20 > Ingress filtering can prevent the spoofing of an RLOC, but not = necessarily > the spoofing of an EID. If a middlebox produces packets that have = correct > RLOCs but incorrect EIDs, and if the ETR accepts them, then a = reflection > attack is enabled. > =20 >>=20 >>>>> One "funny" attack is by spoofing at the same time the EID and >>>>> the RLOC. >>>>>=20 >>>>> Without cryptography, there is no perfect solution to avoid >>>>> spoofing. Your example with dynamic RLOC is interesting. >>>>> If everything goes well, you should never have a TTL >>>>> longer than the RLOC lease time. However, in the case >>>>> the RLOC changes before the expiration, you will need >>>>> SMR or version change implying the retrieval of the new >>>>> mapping. But in this particular case, you also have a >>>>> security threat that is a DoS... >>>>=20 >>>> Do you see a clear way past these and other threats? >>>> Will it be the case that LISP and its ilk will be >>>> hard to secure and thus difficult to deploy? >>>=20 >>> I think that by taking care of how LISP is deployed and how >>> the features are used, it is possible to achieve the same level >>> of security than today. Doing more is possible, but I am not sure >>> that people are ready to have to deal with cryptography. For >>> example, if you want to protect against spoofing, you can sign >>> the packets (or part of) but then you need a way to know the key >>> used to sign. >>>=20 >>> Do you really want to go to that direction? >>=20 >> Do I really want to go in the direction of requiring >> cryptography? I can't answer that unless you first >> tell me the intended domain of applicability. I don't >> think I have yet seen a use case analysis of the >> various scenarios where LISP xTRs and mapping systems >> would be deployed and used. There seems to be an >> unspoken assumption of deployment "in the public >> Internet", but what about Enterprise networks? >> What about MANETs? What about aviation networks? >> What about tactical military networks? What about >> cellular networks? What about home networks? >>=20 >=20 > That is the purpose of the deployment document. >=20 > http://tools.ietf.org/html/draft-ietf-lisp-deployment-01=20 > =20 > =46rom a brief look, that document appears to have quite a ways to > go until it considers a wider variety of use cases such as we have > addressed in RANGERS. The document also seems to carefully > step around the MTU issue, as if it were a booby trap to be always > on guard for. IRON (with SEAL) *solves* the MTU issue so that > there is no longer any need to worry about it. Until LISP truly > addresses the MTU issue (including accounting for the common > case of operators misconfiguring link MTUs) all LISP-related > documents will have to carefully dance around it. > =20 > Fred > fred.l.templin@boeing.com >=20 > Luigi >=20 --Apple-Mail=_E0C98E74-B3BE-4160-893B-AC62EFFAC089 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Luigi,
 
I really, really hate trying = to annotate things when people=20 turn them
into html instead of leaving = them as plaintext. But since=20 you insist:

From: Luigi Iannone=20 [mailto:luigi@net.t-labs.tu-berlin.de]
Sent: Tuesday, = September 20,=20 2011 12:31 AM
To: Templin, Fred L
Cc: Damien = Saucez;=20 lisp@ietf.org
Subject: = Re: [lisp] Source address spoofing by a node=20 pretending to be an ITR?

Hi Fred,

On Sep 19, 2011, at 23:22 , Templin, Fred L wrote:

[snip]
The hidden idea behind the threat draft is = "if we=20 do not manage to
make a system more secured than the = current=20 Internet, at least we
must have a system that is not less=20 secure."

That's why I said: "But, perhaps a case = can be=20 made that
on-path attacks are no more a matter for concern for=20 LISP
than they are for the non-LISP public = Internet?".

Still, if=20 an off-path attacker can spoof the EID source
address even if it = cannot=20 spoof the RLOC source address,
the end result is a system that is = less=20 secure than the
current Internet - right?

Can you explain why? 

I would say the contrary. If an attacker cannot spoof RLOC it = means that=20 the DFZ is more robust - right? 
 
Ingress filtering can = prevent the spoofing of an RLOC,=20 but not necessarily
the spoofing of an EID. If = a middlebox produces packets=20 that have correct
RLOCs but incorrect EIDs, = and if the ETR accepts them,=20 then a reflection
attack is = enabled.
   

One "funny" attack is by spoofing at = the same=20 time the EID and
the = RLOC.

Without cryptography, there is no = perfect=20 solution to avoid
spoofing. Your example with dynamic = RLOC is=20 interesting.
If everything goes well, you should = never have=20 a TTL
longer than the RLOC lease time. = However, in=20 the case
the RLOC changes before the = expiration, you=20 will need
SMR or version change implying the = retrieval=20 of the new
mapping. But in this particular case, = you also=20 have a
security threat that is a=20 DoS...

Do you see a clear way past these and = other=20 threats?
Will it be the case that LISP and its = ilk will=20 be
hard to secure and thus difficult to=20 deploy?

I think that by taking care of how LISP is=20= deployed and how
the features are used, it is possible to = achieve=20 the same level
of security than today. Doing more is = possible,=20 but I am not sure
that people are ready to have to deal with=20= cryptography. For
example, if you want to protect against = spoofing,=20 you can sign
the packets (or part of) but then you need = a way=20 to know the key
used to sign.

Do you really want to go to that=20 direction?

Do I really want to go in the direction of=20 requiring
cryptography? I can't answer that unless you = first
tell me=20 the intended domain of applicability. I don't
think I have yet = seen a use=20 case analysis of the
various scenarios where LISP xTRs and = mapping=20 systems
would be deployed and used. There seems to be = an
unspoken=20 assumption of deployment "in the public
Internet", but what about=20= Enterprise networks?
What about MANETs? What about aviation=20 networks?
What about tactical military networks? What = about
cellular=20 networks? What about home networks?


That is the purpose of the deployment document.

 
=
=46rom a brief look, that document appears = to have quite a ways=20 to
go until it considers a wider variety = of use cases such as we=20 have
addressed in RANGERS. The document also = seems to=20 carefully
step around the MTU issue, as if it were a = booby trap to be=20 always
on guard for. IRON (with SEAL) *solves* the MTU issue so=20 that
there is no longer any need to worry about it. Until LISP=20 truly
addresses the MTU issue (including = accounting for the=20 common
case of operators misconfiguring link MTUs) = all=20 LISP-related
documents will have to carefully dance around=20 it.
 
Fred

Luigi