From jari.arkko@piuha.net Mon Jan 2 01:28:08 2012 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 E3F0821F8EE1 for ; Mon, 2 Jan 2012 01:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 Hx11wKYzvn-N for ; Mon, 2 Jan 2012 01:28:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A45DC21F8ED0 for ; Mon, 2 Jan 2012 01:28:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2C9C02CC4D; Mon, 2 Jan 2012 11:27:32 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVrxrFZozUWw; Mon, 2 Jan 2012 11:27:30 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 04E932CC31; Mon, 2 Jan 2012 11:27:29 +0200 (EET) Message-ID: <4F017880.3060500@piuha.net> Date: Mon, 02 Jan 2012 11:27:28 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: lisp@ietf.org, draft-ietf-lisp-interworking@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp-interworking 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, 02 Jan 2012 09:28:09 -0000 I have reviewed this document. In general, it is well written and almost ready to go forward. There are a couple of areas that need further text, however. The main issue is a clear description of the to-experiment and problematic areas of LISP interworking. (Making those is also needed in order to get the document approved, based on experience of taking the other Lisp documents to the IESG.) Another issue is that I think the security considerations text needs work. In moder detail: Technical issue: As with the other documents from the group, Section 1 should include a high-level explanation of what issues are uncertain, potentially problematic, or worth experimenting on. For instance, I presume you should say something about the effects of having to NAT traffic, finding deployment motivations to set up proxy ITRs, possible inclusion of too much non-aggregated EID space in the DFZ, effects of the asymmetric PITR routing, and so on. Please suggest text. > An ITR can also know explicitly that the > destination is non-LISP if the destination IP address matches a > Negative Map Reply found in its Map Cache. Technical issue: This is normally the case, but the text seems to avoid going into the details that I think are relevant in this case. The base spec says There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PITR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non-allocated EIDs. and The actions defined are used by an ITR or PITR when a destination EID matches a negative mapping cache entry. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: (0) No-Action: The map-cache is kept alive and no packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Unreachable message SHOULD be sent. That is, first of all there are other situations for which negative map cache entries are used (but it is probably fine to route to the Internet in those cases). Secondly, there are some controls on whether native forwarding is the appropriate action. Can you add a note about these and/or reformulate the text a bit? > 3. In either of the two exceptions mentioned above there could be > Editorial issue: I was unsure what "the two exceptions mentioned above" refer to. Also, your list starts with "This can be achieved by using one of two mechanisms:", so it is odd to find three items in the list. I would suggest making this paragraph a regular paragraph and not a numbered item, and starting it with "In either of the two mechanisms listed above there could be ...". > 5. Proxy Ingress Tunnel Routers Editorial issue: It may be too obvious perhaps, but I think this section should state up front that highly aggregated EID space advertisement implies an entity that routes on the behalf of many LISP sites. > 240.0.0.0/24. For the purposes of this example, this prefix and no > Editorial issue: Is there a reason why we are using 240 addresses as examples? I'd prefer using normal example addresses or 10/8 addresses if you need shorter prefixes... > For the purposes of this example, this prefix and no > covering aggregate is present in the global routing system. Editorial issue: Shouldn't this be "... neither this prefix or any covering aggregate are present ...". The way that you have written it now had me confused for a moment, thinking that this prefix is present but no covering prefix is present. I don't think that is what you mean. > > 6 . LISP-NAT > > > Technical issue: Section 6 should probably point to some BEHAVE WG RFCs on how the NAT operation should technically work. > An example of this translation follows. For this example, a site has > been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize > LISP-NAT, the site has also been provided the PA EID of > 128.200.1.0/24, and uses the first address (128.200.1.1) as the > site's RLOC. The rest of this PA space (128.200.1.2 to > 128.200.1.254) is used as a translation pool for this site's hosts > who need to send packets to non-LISP hosts. > Editorial issue: Please use the officially allocated example addresses. > > 6.4 . LISP-NAT and multiple EIDs > > > > When a site has two addresses that a host might use for global > reachability, care must be chosen on which EID is found in DNS. For > example, whether applications such as DNS use the LISP-R EID or the > LISP-NR EID. This problem exists for NAT in general, but the > specific issue described above is unique to LISP. Using PITRs can > mitigate this problem, since the LISP-NR EID can be reached in all > cases. Technical issue: but if you had a PITR, you would not need LISP-NAT, or am I missing something? > > 6.5 . When LISP-NAT and PITRs used by the same LISP Site > > > > With LISP-NAT, there are two EIDs possible for a given host, the > LISP-R EID and the LISP-NR EID. When a site has two addresses that a > host might use for global reachability, name-to-address directories > may need to be modified. > > This problem, global vs. local addressability, exists for NAT in > general, but the specific issue described above is unique to > location/identity separation schemes. Some of these have suggested > running a separate DNS instance for new types of EIDs. This solves > the problem but introduces complexity for the site. Alternatively, > using PITRs can mitigate this problem, because the LISP-NR EID can be > reached in all cases. Editorial issue: what's the difference between Sections 6.4 and 6.5? It seems that they both talk about the problem of two addresses in a name mapping system. Technical issue: I don't think "introduces complexity for the site" begins to explain the type of problems caused by having to separate naming systems from each other. Please expand or otherwise highlight that this approach is problematic. > > 8 . Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) > > > > In summary, there are three mechanisms for interworking LISP with > non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the > LISP site can manage and control the interworking on its own. In the > PITR case, the site is not required to manage the advertisement of > it's EID prefix into the DFZ, with the cost of potentially adding > stretch to the connections of non-LISP sites sending packets to the > LISP site. The third option is Proxy-ETRs, which are optionally used > by sites relying on PITRs case to mitigate two caveats for LISP sites > sending packets to non-LISP sites. This means Proxy-ETRs are not > usually expected to be deployed by themselves, rather they will be > used to assist LISP-NR sites which are already using PITRs. > Technical issue: This paragraph and Setion 8 in general would greatly from a discussion of the tradeoffs involved in these three mechanisms. Just one downside, stretch, is mentioned above. But I think there are others... impacts to naming systems, asymmetric traffic, etc. Please expand. > 9. Security Considerations Technical issue: This section seems a bit thin. I'd love to see a discussion of the following additional issues: Implications to firewalls? Are there any? What about asymmetric routing? Are there Denial-of-service attacks on PITRs and PETRs? Are there DNSSEC implications on the naming system implications? > Like any router or LISP ITR, PITRs will have the opportunity to > inspect traffic at the time that they encapsulate. The location of > these devices in the network can have implications for discarding > malicious traffic on behalf of ETRs which request this behavior (via > the drop action bit in Map-Reply packets for an EID or EID prefix). > You should also talk about these devices being trusted to route your traffic to begin with, and how both non-Lisp and Lisp networks should be careful in not peering with untrustworthy networks. This is very similar to, say, peering with someone who says they can reach everything in the Internet but in reality their quality or security leaves something to be desired. (Of course, all additions to the security considerations text could be pointers elsewhere, if the issues have already been noted in other documents.) Jari From internet-drafts@ietf.org Tue Jan 3 11:11:28 2012 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 4457E1F0C3E; Tue, 3 Jan 2012 11:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 GVW2jFkX+WlL; Tue, 3 Jan 2012 11:11:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D253321F847C; Tue, 3 Jan 2012 11:11:27 -0800 (PST) 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.64p1 Message-ID: <20120103191127.22810.62062.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 11:11:27 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:11:28 -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-12.txt Pages : 40 Date : 2012-01-03 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-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-multicast-12.txt From internet-drafts@ietf.org Thu Jan 5 15:36:03 2012 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 54D3821F88F8; Thu, 5 Jan 2012 15:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 Y9NgSS8yuT5z; Thu, 5 Jan 2012 15:36:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E592E21F88D9; Thu, 5 Jan 2012 15:36:02 -0800 (PST) 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.64p1 Message-ID: <20120105233602.12777.19917.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2012 15:36:02 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-19.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:36:03 -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 : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-19.txt Pages : 95 Date : 2012-01-05 This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-19.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-19.txt From adrian@olddog.co.uk Sun Jan 8 12:48:58 2012 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 48E1321F851C; Sun, 8 Jan 2012 12:48:58 -0800 (PST) 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=[AWL=0.000, 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 0WZSte0Kj54D; Sun, 8 Jan 2012 12:48:57 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E93E421F8505; Sun, 8 Jan 2012 12:48:56 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q08Kmr2w010244; Sun, 8 Jan 2012 20:48:53 GMT Received: from 950129200 (adsl-84-227-210-28.adslplus.ch [84.227.210.28]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q08KmjjW010187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jan 2012 20:48:50 GMT From: "Adrian Farrel" To: Date: Sun, 8 Jan 2012 20:48:44 -0000 Message-ID: <005e01ccce46$ecf20ba0$c6d622e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczORuDnkSm4mdvDSpeHi36uheOTng== Content-Language: en-gb Cc: lisp@ietf.org, iesg@ietf.org Subject: [lisp] Proposed caveat text for draft-ietf-lisp X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 20:48:58 -0000 All (including the LISP list who have a right to be involved in this sort of discussion), During IESG review of draft-ietf-lisp-16 I undertook to suggest modifications that would address a major part of my Discuss and would help me to be able to clear my Discusses on a couple of other LISP documents by insertion of direct references to this document. Sorry that it has taken me so long (I plead ITU-T and Judaeo-Christian culture). Here are my suggestions based on draft-ietf-lisp-19. The point of the changes is to provide suitable caveats about the known (and unknown) qualities of LISP and its suitability for deployment. This helps address the requirements of the LISP WG Charter to make such clear statements in *all* LISP I-Ds. What I am suggesting is that this I-D contains the strong statements below, and all other documents are able to include a very simple (one line?) caveat that points to this document. If/when LISP is upgraded as a result of experimentation, it will be easier to perform the updates since only this one document has to be modified to change the caveat. Cheers, Adrian === Abstract second paragraph (text taken largely from Charter) OLD Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. NEW Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. LISP remains an early-stage, experimental proposal with unevaluated and potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives are unclear, and is not recommended for deployment beyond experimental situations END --- Section 2 - Final paragraph (text taken largely from Charter) OLD This experimental specification has areas that require additional experience and measurement. Results of such work may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and prototype deployment. NEW LISP is an early-stage, experimental proposal with unevaluated and potentially harmful side-effects to Internet traffic carried by the involved routers, has parts where deployment incentives are unclear, and is NOT RECOMMENDED for deployment beyond experimental situations. Furthermore, some components of the LISP solution (such as the identifier to locator mapping system) need to be evaluated against other experimental proposals to determine which of many design alternative is the best. This experimental specification has areas that require additional experience and measurement. Results of such work may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 2.1 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. END --- New Section 2.1 (Text taken from Section 15 with deltas [punctuation, final bullet, and final para]) NEW 2.1. Known Open Issues and Areas of Future Work As an experimental specification, this work is, by definition, incomplete. Specific areas where additional experience and work are needed include: o At present, only [ALT] is defined for implementing a database of EID-to-RLOC mapping information. Additional research on other mapping database systems is strongly encouraged. o Failure and recovery of LISP site partitioning (see Section 6.4), in the presence of redundant configuration (see Section 8.5) needs further research and experimentation. o The characteristics of map-cache management under exceptional conditions, such as denial-of-service attacks are not fully understood. Further experience is needed to determine whether current caching methods are practical or in need of further development. In particular, the performance, scaling and security characteristics of the map-cache will be discovered as part of this experiment. Performance metrics to be observed are packet reordering associated with the LISP data probe and loss of the first packet in a flow associated with map-caching. The impact of these upon TCP will be observed. See Section 12 for additional thoughts and considerations. o Preliminary work has been done to ensure that sites employing LISP can interconnect with the rest of the Internet. This work is documented in [INTERWORK], but further experimentation and experience is needed. o At present, no mechanism for automated key management for message authentication is defined. Addressing automated key management is necessary before this specification could be developed into a standards track RFC. See Section 12 for further details regarding security considerations. o In order to maintain security and stability, Internet Protocols typically isolate the control and data planes. Therefore, user activity cannot cause control plane state to be created or destroyed. LISP does not maintain this separation. The degree to which the loss of separation impacts security and stability is a topic for experimental observation. o LISP allows for different mapping database systems to be used. While only one [ALT] is currently well-defined, each mapping database will likely have some impact on the security of the EID- to-RLOC mappings. How each mapping database system's security properties impact on LISP overall is for further study. o An examination of the implications of LISP on Internet traffic, applications, routers, and security is needed. This will help to understand the consequences for network stability, routing protocol function, routing scalability, migration and backward compatibility, and implementation scalability (as influenced by additional protocol components, additional state, and additional processing for encapsulation, decapsulation, liveness). Other LISP documents may also include open issues and areas for future work. END --- Remove Section 15 (Moved to 2.1) DELETE 2.1. Known Open Issues and Areas of Future Work As an experimental specification, this work is, by definition, incomplete. Specific areas where additional experience and work are needed include: o At present, only [ALT] is defined for implementing a database of EID-to-RLOC mapping information. Additional research on other mapping database systems is strongly encouraged. o Failure and recovery of LISP site partitioning (see Section 6.4), in the presence of redundant configuration (see Section 8.5) needs further research and experimentation. o The characteristics of map-cache management under exceptional conditions, such as denial-of-service attacks are not fully understood. Further experience is needed to determine whether current caching methods are practical or in need of further development. In particular, the performance, scaling and security characteristics of the map-cache will be discovered as part of this experiment. Performance metrics to be observed are packet reordering associated with the LISP data probe and loss of the first packet in a flow associated with map-caching. The impact of these upon TCP will be observed. See Section 12 for additional thoughts and considerations. o Preliminary work has been done to ensure that sites employing LISP can interconnect with the rest of the Internet. This work is documented in [INTERWORK] but further experimentation and experience is needed. o At present, no mechanism for automated key management for message authentication is defined. Addressing automated key management is necessary before this specification could be developed into a standards track RFC. See Section 12 for further details regarding security considerations. o In order to maintain security and stability, Internet Protocols typically isolate the control and data planes. Therefore, user activity cannot cause control plane state to be created or destroyed. LISP does not maintain this separation. The degree to which the loss of separation impacts security and stability is a topic for experimental observation. o LISP allows for different mapping database systems to be used. While only one [ALT] is currently well-defined, each mapping database will likely have some impact on the security of the EID- to-RLOC mappings. How each mapping database system's security properties impact on LISP overall is for further study. END From internet-drafts@ietf.org Wed Jan 11 11:39:02 2012 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 E8DA711E80B1; Wed, 11 Jan 2012 11:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCliq0aM6w5W; Wed, 11 Jan 2012 11:39:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7B11E8094; Wed, 11 Jan 2012 11:39:02 -0800 (PST) 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.64p1 Message-ID: <20120111193902.12167.63641.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 11:39:02 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-15.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, 11 Jan 2012 19:39:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-15.txt Pages : 16 Date : 2012-01-11 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-15.txt From vaf@cisco.com Wed Jan 11 11:57:15 2012 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 51CA321F85E9 for ; Wed, 11 Jan 2012 11:57:15 -0800 (PST) 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 iGt8abvRX4a2 for ; Wed, 11 Jan 2012 11:57:14 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34E21F85D7 for ; Wed, 11 Jan 2012 11:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=3113; q=dns/txt; s=iport; t=1326311834; x=1327521434; h=date:from:to:subject:message-id:mime-version; bh=tW5rscw7iMZdQnavOzDQcZec3C68GCFQcmvqjdZ0MKg=; b=hb41zbIVnJQXYtkosM81lYMXU2QpEoMlIP12f0iJRH0HikgZ+/HD8TL6 EL7T+nZMw6/ymD3wScA16egbeZxjzdRuHDEajU86UESuINnvEGUsDavtx uVEWIEGTD2GMuOkkNU7a9DDHMIng4P8iKXpenjidUcmHXKYFDHQOmUlXJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFDpDU+rRDoG/2dsb2JhbABDrQaBBYFyAQEBBQEBDwEUEzQ3AwECDzQTBSECIQkZh2CXXYEnAZ5PiQGCOWMEiDqMUZJe X-IronPort-AV: E=Sophos;i="4.71,494,1320624000"; d="scan'208";a="24920050" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Jan 2012 19:57:07 +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 q0BJv7BA029851 for ; Wed, 11 Jan 2012 19:57:07 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 44D9F1C873B8; Wed, 11 Jan 2012 11:57:07 -0800 (PST) Date: Wed, 11 Jan 2012 11:57:07 -0800 From: Vince Fuller To: lisp@ietf.org Message-ID: <20120111195707.GB12691@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-ms-15.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, 11 Jan 2012 19:57:15 -0000 This version includes exactly three changes: - insertion of a new section 7, paragraph 5 that reads: The currently-defined authentication mechanism for Map-Register messages does not provide protection against "replay" attacks by a "man-in-the-middle". Additional work is needed in this area. - correct typo in section 7 paragraph six ("reply" -> "replay") - update of the reference to draft-ietf-lisp ----- Forwarded message from internet-drafts@ietf.org ----- Date: Wed, 11 Jan 2012 11:39:02 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-15.txt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoCAJPkDU8MFjoenGdsb2JhbABDrQYiAQEBAQEICwkJFCWBdAEFAQEPAScGAQEECh4LAQIDAQIGAkAICAMBI0kFBBmHYJh9AYt4hCEBji0HiQGDHIg+jFEBkl0 X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol Errors-To: lisp-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-15.txt Pages : 16 Date : 2012-01-11 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-15.txt _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ----- End forwarded message ----- From stephen.farrell@cs.tcd.ie Thu Jan 12 02:58:12 2012 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 22B7921F857D for ; Thu, 12 Jan 2012 02:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MukvjXKzN3sq for ; Thu, 12 Jan 2012 02:58:11 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 55AD721F8554 for ; Thu, 12 Jan 2012 02:58:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 852BD171C78 for ; Thu, 12 Jan 2012 10:58:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1326365890; bh=vIP5r+qQCqJB9vURLRC0NIU2 KmNhVNruG/iPmluXBC8=; b=2rnfgvbMEBczkCNlAX0oSH4n+m6BHqYtFavhpE0t bl/Q5mObwX3oLdAgCkhHfHEMRtCpGUcF1VSmNj792/sfwgXBth4J+5qjyftOOqFL DNMPs84QsrtLcYHTL1VgeLqgifmundabqcFfFKaD738w5vczlhbqDtoz+Ol5xeFE qGGY+T3xUboUIUzjsdguWsr8J1tO7YnDGt5VabELgEXMsnFiv2OAJQihvLTFXaGB 0/oNv3NLk8M8+mZC6D4mUTQ9qbHz2UB0+bpufm9sLeBYzIgHKu4eBGTI+mdD5swc jrD80RGKZHzoZNRGJKUWgI2zjE1YwCS3QrVgIO3PrEvShg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ojUPjNSSWljB for ; Thu, 12 Jan 2012 10:58:10 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EACFE171C77 for ; Thu, 12 Jan 2012 10:58:09 +0000 (GMT) Message-ID: <4F0EBCC1.8040203@cs.tcd.ie> Date: Thu, 12 Jan 2012 10:58:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Map-Register replays 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, 12 Jan 2012 10:58:12 -0000 Hi, I have a DISCUSS on the base document [1] and -ms [2] (same thing really) noting that Map-Register messages, while authenticated, can be replayed which is not great, especially since there doesn't seem to be any easy way to add replay protection right now without changing stuff I guess you don't want to change. The authors have added a new security consideration to -ms noting this and the base document now notes that the nonce field in that message, while specified to be zero, may be used for some form of replay protection in future. Since LISP is experimental I'm ok to clear my DISCUSS on that basis, *if* the WG will actually address the problem in the not-too-distant future. (I'll leave the DISCUSS there for now so the link at [1] works for a bit:-) Since you're now in the process of re-chartering it seems like adding that as a bit of work with a milestone would be the easiest thing to do, if the WG are happy to take on that work. I'd suggest adding a bit of text saying the WG will also: "examine the implications of Map-Register replays and develop a solution." That could go maybe as the 2nd item in the list that currently says: "Specifically, the group will work on: - LISP security threats and solutions - MIBs - deployment models - allocation of EID space - alternate mapping system designs." And I think that really needs a milestone, to close the loop, such as: "MMM YYYY Forward a solution to Map-Register replays to IESG" Note that it is possible in principle that the "solution" might be "its not a problem and here's why" but I don't think that's the case. When the issue is tackled it might or might not have implications for e.g. Map-Notify as well since the same format is used. I'd guess that that should be doable in the same timeframe as LISP-SEC (or could even be incorporated into that document maybe if that's what you want) since its a small piece of work really if someone's available to do it. If the WG just don't want to take on that work then we probably need to revisit the resolution of the DISCUSS point to further figure out the implications of replayed Map-Register messages. So, does the above sound like a plan? Thanks, Stephen. [1] https://datatracker.ietf.org/doc/draft-ietf-lisp/ballot/#stephen-farrell [2] https://datatracker.ietf.org/doc/draft-ietf-lisp-ms/ballot/#stephen-farrell From dino@cisco.com Thu Jan 12 10:00:28 2012 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 38DB921F85CE for ; Thu, 12 Jan 2012 10:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 zLuJCiYsWuox for ; Thu, 12 Jan 2012 10:00:27 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B121F8527 for ; Thu, 12 Jan 2012 10:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2946; q=dns/txt; s=iport; t=1326391227; x=1327600827; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=u5S2h6jv6f6x5C72fTULWlCrtShj+O7Rz6s9DJ/PQBI=; b=Tv5tjXZrJHRXXFbpXx4KiKju+6U3BxLUFw0nkpZ9k7XsPAPDWh6kvh5T Z1bd8eSKNXSa9+QcvUYDnI3bGjQgezsmvfLZUBJR6g4ZdoWk5HrKo8C5S zQnnf/yv5ww/F7NQNihCAtZ8w42STPmKo8wCwOwqjKQtm8W33GL7Apu+l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEoeD0+rRDoG/2dsb2JhbABDrQqBBYFyAQEBAwEBAQEPASc0CxALRicwBhMbB4dYCJk3AZ4PBIs6YwSIO4xTkl0 X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; d="scan'208";a="23381925" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 12 Jan 2012 18:00:27 +0000 Received: from sjc-vpn3-958.cisco.com (sjc-vpn3-958.cisco.com [10.21.67.190]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0CHxaCW031688; Thu, 12 Jan 2012 18:00:26 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <4F0EBCC1.8040203@cs.tcd.ie> Date: Thu, 12 Jan 2012 10:00:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <95D0224B-8DD2-4800-A6FD-4FC60EA5126F@cisco.com> References: <4F0EBCC1.8040203@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: lisp@ietf.org Subject: Re: [lisp] Map-Register replays 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, 12 Jan 2012 18:00:28 -0000 I second the motion. We should take on this relatively minor work after = the experimental RFCs are published. Dino On Jan 12, 2012, at 2:58 AM, Stephen Farrell wrote: >=20 > Hi, >=20 > I have a DISCUSS on the base document [1] and -ms [2] > (same thing really) noting that Map-Register messages, > while authenticated, can be replayed which is not great, > especially since there doesn't seem to be any easy way > to add replay protection right now without changing > stuff I guess you don't want to change. >=20 > The authors have added a new security consideration to -ms > noting this and the base document now notes that the nonce > field in that message, while specified to be zero, may be > used for some form of replay protection in future. >=20 > Since LISP is experimental I'm ok to clear my DISCUSS > on that basis, *if* the WG will actually address the problem > in the not-too-distant future. (I'll leave the DISCUSS > there for now so the link at [1] works for a bit:-) >=20 > Since you're now in the process of re-chartering it seems > like adding that as a bit of work with a milestone would > be the easiest thing to do, if the WG are happy to take on > that work. >=20 > I'd suggest adding a bit of text saying the WG will also: >=20 > "examine the implications of Map-Register replays and > develop a solution." >=20 > That could go maybe as the 2nd item in the list that > currently says: >=20 > "Specifically, the group will work on: >=20 > - LISP security threats and solutions > - MIBs > - deployment models > - allocation of EID space > - alternate mapping system designs." >=20 > And I think that really needs a milestone, to close > the loop, such as: >=20 > "MMM YYYY Forward a solution to Map-Register replays to IESG" >=20 > Note that it is possible in principle that the "solution" > might be "its not a problem and here's why" but I don't > think that's the case. When the issue is tackled it might > or might not have implications for e.g. Map-Notify as well > since the same format is used. >=20 > I'd guess that that should be doable in the same timeframe > as LISP-SEC (or could even be incorporated into that document > maybe if that's what you want) since its a small piece of > work really if someone's available to do it. >=20 > If the WG just don't want to take on that work then we probably > need to revisit the resolution of the DISCUSS point to further > figure out the implications of replayed Map-Register messages. >=20 > So, does the above sound like a plan? >=20 > Thanks, > Stephen. >=20 > [1] = https://datatracker.ietf.org/doc/draft-ietf-lisp/ballot/#stephen-farrell > [2] = https://datatracker.ietf.org/doc/draft-ietf-lisp-ms/ballot/#stephen-farrel= l >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From iesg-secretary@ietf.org Thu Jan 12 13:40:57 2012 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 573C921F8603; Thu, 12 Jan 2012 13:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 eIYOqlSOuDN8; Thu, 12 Jan 2012 13:40:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E7121F8606; Thu, 12 Jan 2012 13:40:56 -0800 (PST) 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.64p1 Message-ID: <20120112214056.19730.45171.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 13:40:56 -0800 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'LISP Alternative Topology (LISP+ALT)' to Experimental RFC (draft-ietf-lisp-alt-10.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 21:40:57 -0000 The IESG has approved the following document: - 'LISP Alternative Topology (LISP+ALT)' (draft-ietf-lisp-alt-10.txt) as an Experimental 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-alt/ Technical Summary 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. Working Group Summary Many of the comments received during last call were complex and difficult for the working group to understand. The working group last call was held open for an extended time to ensure sufficient discussion and sufficient effort to address those objections. Document Quality Several (3+) LISP implementations exist using the ALT topology. Personnel Terry Manderson is the Document Shepherd, and Jari Arkko is the responsible Area Director. From stephen.farrell@cs.tcd.ie Mon Jan 16 17:52:00 2012 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 7528D21F84DE for ; Mon, 16 Jan 2012 17:52:00 -0800 (PST) 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 fCNLjYd7NVvT for ; Mon, 16 Jan 2012 17:51:51 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7111011E8076 for ; Mon, 16 Jan 2012 17:51:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B54BE171C29; Tue, 17 Jan 2012 01:51:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326765108; bh=3QeI3Ut0LZM7y8 NilcmUUl/MBS4VeiHOMqqR3WzaCw4=; b=nmwn2J0x0N9fbCN4WkKUrwHbVRLPvh pYohhAUALUEzxdhg/CKhog2CPjAAWsSfo28Y+5nOW4vZBioY39xCLBJnruuKWj5+ f9jYco4e041ZSQYTOdSxRvEayNs5ZfRXmv7OV4fWjMEcFYqPseJjVoArVW5kSEV7 j6QhoZxgz2SmXA9Cg3fbemo9dbcJ5wFwi0RK5TfwuiCZUucjRqBoD6qLUtjnCG2N WdpqhAv2MFJ80FCjXu3QtthD5mNH2HsEQHKabz5h/HVY7W9euvEDx60niISpxFig pNyNBEpUsH06dmeFx1dzHOjGAK3+ws7pGroJbuitcMWQasYKdWc4QyiQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id d4K3I7dXfFdg; Tue, 17 Jan 2012 01:51:48 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.44.65.1]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 33170171C27; Tue, 17 Jan 2012 01:51:47 +0000 (GMT) Message-ID: <4F14D432.90500@cs.tcd.ie> Date: Tue, 17 Jan 2012 01:51:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <4F0EBCC1.8040203@cs.tcd.ie> <95D0224B-8DD2-4800-A6FD-4FC60EA5126F@cisco.com> In-Reply-To: <95D0224B-8DD2-4800-A6FD-4FC60EA5126F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Map-Register replays 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, 17 Jan 2012 01:52:00 -0000 Okey dokey, given one ok and no objections I've cleared my discusses on these documents and look forward to seeing a milestone for this in the new charter when it comes up for review at the iesg. Thanks, Stephen. On 01/12/2012 06:00 PM, Dino Farinacci wrote: > I second the motion. We should take on this relatively minor work after the experimental RFCs are published. > > Dino > > On Jan 12, 2012, at 2:58 AM, Stephen Farrell wrote: > >> >> Hi, >> >> I have a DISCUSS on the base document [1] and -ms [2] >> (same thing really) noting that Map-Register messages, >> while authenticated, can be replayed which is not great, >> especially since there doesn't seem to be any easy way >> to add replay protection right now without changing >> stuff I guess you don't want to change. >> >> The authors have added a new security consideration to -ms >> noting this and the base document now notes that the nonce >> field in that message, while specified to be zero, may be >> used for some form of replay protection in future. >> >> Since LISP is experimental I'm ok to clear my DISCUSS >> on that basis, *if* the WG will actually address the problem >> in the not-too-distant future. (I'll leave the DISCUSS >> there for now so the link at [1] works for a bit:-) >> >> Since you're now in the process of re-chartering it seems >> like adding that as a bit of work with a milestone would >> be the easiest thing to do, if the WG are happy to take on >> that work. >> >> I'd suggest adding a bit of text saying the WG will also: >> >> "examine the implications of Map-Register replays and >> develop a solution." >> >> That could go maybe as the 2nd item in the list that >> currently says: >> >> "Specifically, the group will work on: >> >> - LISP security threats and solutions >> - MIBs >> - deployment models >> - allocation of EID space >> - alternate mapping system designs." >> >> And I think that really needs a milestone, to close >> the loop, such as: >> >> "MMM YYYY Forward a solution to Map-Register replays to IESG" >> >> Note that it is possible in principle that the "solution" >> might be "its not a problem and here's why" but I don't >> think that's the case. When the issue is tackled it might >> or might not have implications for e.g. Map-Notify as well >> since the same format is used. >> >> I'd guess that that should be doable in the same timeframe >> as LISP-SEC (or could even be incorporated into that document >> maybe if that's what you want) since its a small piece of >> work really if someone's available to do it. >> >> If the WG just don't want to take on that work then we probably >> need to revisit the resolution of the DISCUSS point to further >> figure out the implications of replayed Map-Register messages. >> >> So, does the above sound like a plan? >> >> Thanks, >> Stephen. >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-lisp/ballot/#stephen-farrell >> [2] https://datatracker.ietf.org/doc/draft-ietf-lisp-ms/ballot/#stephen-farrell >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > From jari.arkko@piuha.net Thu Jan 19 07:31:54 2012 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 5177521F85DA for ; Thu, 19 Jan 2012 07:31:54 -0800 (PST) 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=[AWL=0.000, 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 4jn5uuWhyudm for ; Thu, 19 Jan 2012 07:31:53 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B346D21F85D6 for ; Thu, 19 Jan 2012 07:31:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 236752DA07; Thu, 19 Jan 2012 17:31:52 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BMFhOfqVagO; Thu, 19 Jan 2012 17:31:51 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 826E22CC44; Thu, 19 Jan 2012 17:31:51 +0200 (EET) Message-ID: <4F183767.3040706@piuha.net> Date: Thu, 19 Jan 2012 17:31:51 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: lisp@ietf.org, draft-ietf-lisp-interworking@tools.ietf.org References: <4F017880.3060500@piuha.net> In-Reply-To: <4F017880.3060500@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking 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, 19 Jan 2012 15:31:54 -0000 Was there a response on this, and a new document version, or did I miss something? I'd like to take this document forward but we need those changes first. I realize that you have many documents still in the IESG discussion, but part of the criticism that we've gotten in IESG review is that they wanted to see the whole system, not just pieces. The interworking document is an important part of the system, so it would be good to get it up for the final review as well. Jari From internet-drafts@ietf.org Thu Jan 19 09:00:27 2012 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 D01B221F86A7; Thu, 19 Jan 2012 09:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOjRYSXgnD1X; Thu, 19 Jan 2012 09:00:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D761521F869A; Thu, 19 Jan 2012 09:00:25 -0800 (PST) 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.64p1 Message-ID: <20120119170025.21557.39203.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2012 09:00:25 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:00:27 -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-07.txt Pages : 23 Date : 2012-01-19 This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-07.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-07.txt From wwwrun@ietfa.amsl.com Thu Jan 19 13:39:05 2012 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 250E121F8613; Thu, 19 Jan 2012 13:39:05 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120119213905.250E121F8613@ietfa.amsl.com> Date: Thu, 19 Jan 2012 13:39:05 -0800 (PST) Cc: lisp@ietf.org Subject: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@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: Thu, 19 Jan 2012 21:39:05 -0000 A modified charter has been submitted for the Locator/ID Separation Protocol (lisp) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, January 26, 2012 Locator/ID Separation Protocol (lisp) ------------------------------------- Current Status: Active Last updated: 2012-01-19 Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: 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. 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 requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - LISP security threats and solutions - MIBs - deployment models - allocation of EID space - alternate mapping system designs In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for LISP and the various LISP mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG 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. Specifically, the group will work on: - documenting areas that need experimentation - summarizing the results of implementation, experiments, and deployment experience - describing the implications of employing LISP - operational guidance for using LISP Goals and Milestones Jun 2012 Forward draft-ietf-lisp-mib to the IESG Jun 2012 Forward draft-ietf-lisp-sec to the IESG Jun 2012 Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Oct 2012 Forward to the IESG a document providing a solution to replay issues with Map-Register/Map-Notify Dec 2013 Publish an example cache management specification. Dec 2013 Forward to the IESG an evaluation of the security threat to cache maintenance (draft-ietf-lisp-threats) Dec 2013 Forward to the IESG a document addressing the areas which require further experimentation. Jun 2014 Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Jun 2014 Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014 Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. Dec 2014 Re-charter or close From internet-drafts@ietf.org Sun Jan 22 20:10:07 2012 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 38F3621F85F3; Sun, 22 Jan 2012 20:10:07 -0800 (PST) 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=[AWL=0.000, 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 CBOGCkjAOA8p; Sun, 22 Jan 2012 20:10:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93921F85E0; Sun, 22 Jan 2012 20:10:06 -0800 (PST) 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.64p1 Message-ID: <20120123041006.5148.2344.idtracker@ietfa.amsl.com> Date: Sun, 22 Jan 2012 20:10:06 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-20.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 04:10:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-20.txt Pages : 97 Date : 2012-01-22 This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-20.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-20.txt From darlewis@cisco.com Mon Jan 23 13:06:18 2012 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 C9CFF21F86C9 for ; Mon, 23 Jan 2012 13:06:18 -0800 (PST) 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 T1bR+iVDuZns for ; Mon, 23 Jan 2012 13:06:18 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 38DB821F86C6 for ; Mon, 23 Jan 2012 13:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=843; q=dns/txt; s=iport; t=1327352778; x=1328562378; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8EdGxilGu0r+HJpdE1lXpeiTWLxw1T+5HvnW5UzVM5Y=; b=Ziy45DD1/NDS5swp+MoNPiiHT3XEQbpfYTKmhHuQDs2C4wUQR9r2Wmm7 ltOb0CHbx1NNjyqDc/35j1yeVtRWdubdWFuv6gHFImZhAdytT0Hf9vUf1 xc8k+vULPWwsGw0B+NZjESKEzPI1t4kJRCo7qtOT053sJXeZtBs/txRQm M=; X-IronPort-AV: E=Sophos;i="4.71,557,1320624000"; d="scan'208";a="26587642" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 23 Jan 2012 21:06:18 +0000 Received: from sjc-vpn5-934.cisco.com (sjc-vpn5-934.cisco.com [10.21.91.166]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0NL6HLJ019733; Mon, 23 Jan 2012 21:06:17 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: <4F183767.3040706@piuha.net> Date: Mon, 23 Jan 2012 13:06:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3E2EB03D-0259-4B8F-99B1-2C7A4B80867A@cisco.com> References: <4F017880.3060500@piuha.net> <4F183767.3040706@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-lisp-interworking@tools.ietf.org, lisp@ietf.org Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking 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, 23 Jan 2012 21:06:18 -0000 Hi Jari,=20 Sorry I was sick last week and this has been on my queue. I am responding to your text now. Thanks! -Darrel On Jan 19, 2012, at 7:31 AM, Jari Arkko wrote: > Was there a response on this, and a new document version, or did I = miss something? I'd like to take this document forward but we need those = changes first. >=20 > I realize that you have many documents still in the IESG discussion, = but part of the criticism that we've gotten in IESG review is that they = wanted to see the whole system, not just pieces. The interworking = document is an important part of the system, so it would be good to get = it up for the final review as well. >=20 > Jari >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp