Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
On 01/22/13 12:22, Damien Saucez wrote: On 22 Jan 2013, at 10:15, Luigi Iannone g...@gigix.net mailto:g...@gigix.net wrote: Hi All, the definition of LSB as of the to-be-soon-rfc lisp specification is: LISP Locator Status Bits (LSBs): When the L-bit is also set, the locator status bits field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. I think that this clears Damien's question since LSB has no reachability meaning, rather it is a message from the site telling from my perspective ETR X is up and running. Yes, it is not a problem of reachability but a question of status. However, how is the status defined but the router that sends the LSB? How does it know that the locator is up or down? How can we make sure that the LSB will be the same, whatever router is building it? I think this depends a lot on the implementation. For example, if you wanted to have the LSBs synced, you could use the status from the locator records in the Map-Notify messages, and you would get the Map Server view of status. With a more complex implementation, you could probably get a better view. But I think it depends a lot on the implementation. Another question, how bad/good would it be for the traffic if two routers give different LSBs? Again, that's something implementation specific, I don't think it's specced. (BTW this may help debugging, since if the ETR is running but not reachable from the outside this clearly shows that the problem is along the path somewhere. Yeah… could be a long path… but it is still useful information). I agree, that in a controlled environment LSB can be very helpful to debug the network. In the Internet where the topology is unknown I don't know if it is a very relevant information, but it depends how the LSB is constructed. Exactly, depends on the implementation. But the document we discuss is about deployment, so operators can only do what implementations allow them to do. The main concern is about security. Obviously LSB can be easily spoofed in a public environment and this is documented in section 6.4.1 of the draft-ietf-lisp-threats, which recommends: Locator Status Bits can be blindly trusted only in secure environments. In the general unsecured Internet environment, the safest practice for xTRs is to confirm the status change through the mapping system. So IMHO the thing to do is to simply put a reference to the lisp-threats draft about the use of LSBs. If the LSB has to be verified, I would then prefer to use versioning. I will put a reference to the threats draft, and suggest versioning as an alternative. Thanks for all the input! -Lori Damien Saucez ciao Luigi On 22 Jan. 2013, at 04:15 , Dino Farinacci farina...@gmail.com mailto:farina...@gmail.com wrote: They have the same meaning in all environment. It is a question when they should be verified. An LSB that changes in a public environment can cause a Map-Request to be sent and a signed Map-Reply can verify the LSB in an authenticated matter. Dino On Jan 21, 2013, at 6:05 PM, Ronald Bonica rbon...@juniper.net mailto:rbon...@juniper.net wrote: Dino, But isn't it troubling that the bits have one meaning in a controlled environment and another in the great-wide Internet? Ron -Original Message- From: lisp-boun...@ietf.org mailto:lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org mailto:boun...@ietf.org] On Behalf Of Dino Farinacci Sent: Monday, January 21, 2013 5:51 PM To: Noel Chiappa Cc: lisp-inter...@cisco.com mailto:lisp-inter...@cisco.com; lisp@ietf.org mailto:lisp@ietf.org; lisp- b...@external.cisco.com mailto:b...@external.cisco.com Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet deployment? (I don't remember off the top of my head why I didn't like them: I think it was a combination of the fixed number of bits, the fact that it might be difficult for ETR X to know the state of ETR Y, the fact that 'reachable from ITR A' [which you _really_ need to have anyway] is a subset of 'up', etc, etc. But we didn't desperately need the header bits, and the mechanism wasn't positively harmful, so I didn't bother to put up a big fight over it... :-) Maybe because they could be spoofed? But they are good in control environments to take ETRs out of service without having to update the mapping database. Dino ___ lisp mailing list lisp@ietf.org mailto:lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org mailto:lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org mailto:lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___
Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
On 23/1/2013 11:08 πμ, Lori Jakab wrote: On 01/22/13 12:22, Damien Saucez wrote: On 22 Jan 2013, at 10:15, Luigi Iannone g...@gigix.net mailto:g...@gigix.net wrote: Hi All, the definition of LSB as of the to-be-soon-rfc lisp specification is: LISP Locator Status Bits (LSBs): When the L-bit is also set, the locator status bits field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. I think that this clears Damien's question since LSB has no reachability meaning, rather it is a message from the site telling from my perspective ETR X is up and running. Yes, it is not a problem of reachability but a question of status. However, how is the status defined but the router that sends the LSB? How does it know that the locator is up or down? How can we make sure that the LSB will be the same, whatever router is building it? I think this depends a lot on the implementation. For example, if you wanted to have the LSBs synced, you could use the status from the locator records in the Map-Notify messages, and you would get the Map Server view of status. With a more complex implementation, you could probably get a better view. But I think it depends a lot on the implementation. Another question, how bad/good would it be for the traffic if two routers give different LSBs? Again, that's something implementation specific, I don't think it's specced. (BTW this may help debugging, since if the ETR is running but not reachable from the outside this clearly shows that the problem is along the path somewhere. Yeah… could be a long path… but it is still useful information). I agree, that in a controlled environment LSB can be very helpful to debug the network. In the Internet where the topology is unknown I don't know if it is a very relevant information, but it depends how the LSB is constructed. Exactly, depends on the implementation. But the document we discuss is about deployment, so operators can only do what implementations allow them to do. I agree with Lori, I assume that this bit carries different meanings whether there is an hot association with another instance or some cold association, where hot and cold could have relevant meanings when used in standby scenarios --Dimitris The main concern is about security. Obviously LSB can be easily spoofed in a public environment and this is documented in section 6.4.1 of the draft-ietf-lisp-threats, which recommends: Locator Status Bits can be blindly trusted only in secure environments. In the general unsecured Internet environment, the safest practice for xTRs is to confirm the status change through the mapping system. So IMHO the thing to do is to simply put a reference to the lisp-threats draft about the use of LSBs. If the LSB has to be verified, I would then prefer to use versioning. I will put a reference to the threats draft, and suggest versioning as an alternative. Thanks for all the input! -Lori Damien Saucez ciao Luigi On 22 Jan. 2013, at 04:15 , Dino Farinacci farina...@gmail.com mailto:farina...@gmail.com wrote: They have the same meaning in all environment. It is a question when they should be verified. An LSB that changes in a public environment can cause a Map-Request to be sent and a signed Map-Reply can verify the LSB in an authenticated matter. Dino On Jan 21, 2013, at 6:05 PM, Ronald Bonica rbon...@juniper.net mailto:rbon...@juniper.net wrote: Dino, But isn't it troubling that the bits have one meaning in a controlled environment and another in the great-wide Internet? Ron -Original Message- From: lisp-boun...@ietf.org mailto:lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org mailto:boun...@ietf.org] On Behalf Of Dino Farinacci Sent: Monday, January 21, 2013 5:51 PM To: Noel Chiappa Cc: lisp-inter...@cisco.com mailto:lisp-inter...@cisco.com; lisp@ietf.org mailto:lisp@ietf.org; lisp- b...@external.cisco.com mailto:b...@external.cisco.com Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet deployment? (I don't remember off the top of my head why I didn't like them: I think it was a combination of the fixed number of bits, the fact that it might be difficult for ETR X to know the state of ETR Y, the fact that 'reachable from ITR A' [which you _really_ need to have anyway] is a subset of 'up', etc, etc. But we didn't desperately need the header bits, and the mechanism wasn't positively harmful, so I didn't bother to put up a big fight over it... :-) Maybe because they could be spoofed? But they are good in control environments to take ETRs out of service without having to update the mapping database. Dino ___ lisp mailing list lisp@ietf.org mailto:lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing
Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
Hi Dino, Sorry to be slow, but this is one of those cases where a complete expansion might be called for: 1) On the public Internet, we shouldn't trust the LSB at all. If an ITR detects any transition (0-to-1 or 1-to-0), verify it with the mapping system. 2) In a controlled Environment, we can trust the LSB 2a) If the ITR detects a transition from 1-to-0, we should believe it. There is no need to verify. In fact, if we did check with the mapping system, we might find that the mapping system still reports the bit as 1. This is because, as you say below, LSB are good in control[ed] environments to take ETRs out of service without having to update the mapping database. 2b) If the ITR detects a transition from 0-to-1, we should believe it. There is no need to verify. But if we did verify, it would be more likely that the mapping system would report the same thing. Also, in the bullet points above, I am not quite sure what the definition of a controlled environment is. Am I correct in assuming that an environment is controlled if it satisfies both of the following requirements: -controlled from a security perspective. Bad guys cannot spoof LISP control information on the data plane. -controlled from a routing perspective. ETRs are aware of each others' status (and, therefore, can report on each others' status) because the participate in a common IGP. Ron -Original Message- From: Dino Farinacci [mailto:farina...@gmail.com] Sent: Monday, January 21, 2013 10:15 PM To: Ronald Bonica Cc: Noel Chiappa; lisp-inter...@cisco.com; lisp@ietf.org; lisp- b...@external.cisco.com Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet deployment? They have the same meaning in all environment. It is a question when they should be verified. An LSB that changes in a public environment can cause a Map-Request to be sent and a signed Map-Reply can verify the LSB in an authenticated matter. Dino On Jan 21, 2013, at 6:05 PM, Ronald Bonica rbon...@juniper.net wrote: Dino, But isn't it troubling that the bits have one meaning in a controlled environment and another in the great-wide Internet? Ron -Original Message- From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf Of Dino Farinacci Sent: Monday, January 21, 2013 5:51 PM To: Noel Chiappa Cc: lisp-inter...@cisco.com; lisp@ietf.org; lisp- b...@external.cisco.com Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet deployment? (I don't remember off the top of my head why I didn't like them: I think it was a combination of the fixed number of bits, the fact that it might be difficult for ETR X to know the state of ETR Y, the fact that 'reachable from ITR A' [which you _really_ need to have anyway] is a subset of 'up', etc, etc. But we didn't desperately need the header bits, and the mechanism wasn't positively harmful, so I didn't bother to put up a big fight over it... :-) Maybe because they could be spoofed? But they are good in control environments to take ETRs out of service without having to update the mapping database. Dino ___ 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
Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
On 1/23/13 5:54 PM, Eliot Lear wrote: Ron, Sorry to be repeating myself... On 1/23/13 5:35 PM, Ronald Bonica wrote: Hi Dino, Sorry to be slow, but this is one of those cases where a complete expansion might be called for: 1) On the public Internet, we shouldn't trust the LSB at all. If an ITR detects any transition (0-to-1 or 1-to-0), verify it with the mapping system. ... verify it out of band or externally (through the mapping system being one approach). Oh and s/ITR/ETR/ right? ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
From: Eliot Lear l...@cisco.com If an ITR detects any transition (0 -to-1 or 1-to-0), verify it Oh and s/ITR/ETR/ right? No, I don't think so. LSBs are used to tell ITRs the status of ETRs, so ITRs are the things which will use them - and should verify them. But, to make a larger point, I don't think asking the mapping system is really going to be the way to verify any changes - the whole point of LSBs (I thought) was to cover an interim level of dynamics between i) changing the mappings (i.e. updating the mapping system) and really dynamic stuff (e.g. reachability failures). So I don't think status changes reflected in the LSB would _necessarily_ show up in the mapping database.* (* One use I heard postulated for LSBs was if you wanted to change the mapping, and permanently _remove_ an ETR, since ITRs might not pick up a new mapping entry right away, you could mark it 'down' in the LSBs. Or something like that... I forget how you tell which bits in an LSB correspond to what RLOCs. And of course I think that was before mapping sequence/version numbers came in, which allow an ITR to quickly discover that it has an outdate mapping.) Maybe I'm confused, but I'm still not hearing why the LSB buys us anything above and beyond what we have to have anyway: i) mappings, and some way to detect that an ITR has an outdated copy of one, and ii) reachability (which necessarily has to discover, on a fairly real-time basis, a superset of 'up'). Noel ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
Maybe I'm confused, but I'm still not hearing why the LSB buys us anything above and beyond what we have to have anyway: i) mappings, and some way to detect that an ITR has an outdated copy of one, and ii) reachability (which necessarily has to discover, on a fairly real-time basis, a superset of 'up'). Noel, Dino, Thanks for clearing up my misconceptions regarding LSB function. Now, I think that we are in a better position to discuss Noel's question, above. Dino has suggested that the LSB provides a convenient way for ETRs to inform ITRs that locators have been taken in or out of service. This can be done without involving the mapping service. However, the mechanism only works in controlled environments. Furthermore, even in controlled environments, when the LSB==1, the ITR still has to test for reachability. This is because a locator can be in service, but unreachable from a particular ITR. (I am not sure about this, but when the LSB==0, might the ITR have to test for reachability anyway, just to ensure that things haven't changed). Do I have this much right? If so, does the LSB offer enough to be worth the complexity and processor load. Ron ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] RFC 6831 on The Locator/ID Separation Protocol (LISP) for Multicast Environments
A new Request for Comments is now available in online RFC libraries. RFC 6831 Title: The Locator/ID Separation Protocol (LISP) for Multicast Environments Author: D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas Status: Experimental Stream: IETF Date: January 2013 Mailbox:farina...@gmail.com, d...@cisco.com, jzwie...@cruzio.com, s...@cisco.com Pages: 28 Characters: 71901 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lisp-multicast-14.txt URL:http://www.rfc-editor.org/rfc/rfc6831.txt This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community. This document is a product of the Locator/ID Separation Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] RFC 6832 on Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
A new Request for Comments is now available in online RFC libraries. RFC 6832 Title: Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites Author: D. Lewis, D. Meyer, D. Farinacci, V. Fuller Status: Experimental Stream: IETF Date: January 2013 Mailbox:darle...@cisco.com, d...@1-4-5.net, farina...@gmail.com, v...@vaf.net Pages: 19 Characters: 43758 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lisp-interworking-06.txt URL:http://www.rfc-editor.org/rfc/rfc6832.txt This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Locator/ID Separation Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] RFC 6833 on Locator/ID Separation Protocol (LISP) Map-Server Interface
A new Request for Comments is now available in online RFC libraries. RFC 6833 Title: Locator/ID Separation Protocol (LISP) Map-Server Interface Author: V. Fuller, D. Farinacci Status: Experimental Stream: IETF Date: January 2013 Mailbox:v...@vaf.net, farina...@gmail.com Pages: 13 Characters: 30144 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lisp-ms-16.txt URL:http://www.rfc-editor.org/rfc/rfc6833.txt This document describes the Mapping Service for the Locator/ID 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 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. This document defines an Experimental Protocol for the Internet community. This document is a product of the Locator/ID Separation Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] RFC 6834 on Locator/ID Separation Protocol (LISP) Map-Versioning
A new Request for Comments is now available in online RFC libraries. RFC 6834 Title: Locator/ID Separation Protocol (LISP) Map-Versioning Author: L. Iannone, D. Saucez, O. Bonaventure Status: Experimental Stream: IETF Date: January 2013 Mailbox:luigi.iann...@telecom-paristech.fr, damien.sau...@inria.fr, olivier.bonavent...@uclouvain.be Pages: 21 Characters: 51447 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lisp-map-versioning-09.txt URL:http://www.rfc-editor.org/rfc/rfc6834.txt 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 the transport of 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. This document defines an Experimental Protocol for the Internet community. This document is a product of the Locator/ID Separation Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] RFC 6835 on The Locator/ID Separation Protocol Internet Groper (LIG)
A new Request for Comments is now available in online RFC libraries. RFC 6835 Title: The Locator/ID Separation Protocol Internet Groper (LIG) Author: D. Farinacci, D. Meyer Status: Informational Stream: IETF Date: January 2013 Mailbox:farina...@gmail.com, d...@cisco.com Pages: 12 Characters: 26810 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lisp-lig-06.txt URL:http://www.rfc-editor.org/rfc/rfc6835.txt A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Locator/ID Separation Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] RFC 6836 on Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)
A new Request for Comments is now available in online RFC libraries. RFC 6836 Title: Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) Author: V. Fuller, D. Farinacci, D. Meyer, D. Lewis Status: Experimental Stream: IETF Date: January 2013 Mailbox:v...@vaf.net, farina...@gmail.com, d...@1-4-5.net, darle...@cisco.com Pages: 25 Characters: 62093 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lisp-alt-11.txt URL:http://www.rfc-editor.org/rfc/rfc6836.txt 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) that 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 Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community. This document is a product of the Locator/ID Separation Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
Hi Dino, Sorry to be slow, but this is one of those cases where a complete expansion might be called for: 1) On the public Internet, we shouldn't trust the LSB at all. If an ITR detects any transition (0-to-1 or 1-to-0), verify it with the mapping system. Yes, the LSBs are hints and can be trusted, if chosen to, or with paranoia tested to be in sync or the truth. There is a control-plane/security/fast-convergence tradeoff. 2) In a controlled Environment, we can trust the LSB 2a) If the ITR detects a transition from 1-to-0, we should believe it. There is no need to verify. In fact, if we did check with the mapping system, we might find that the mapping system still reports the bit as 1. This is because, as you say below, LSB are good in control[ed] environments to take ETRs out of service without having to update the mapping database. The mapping system transports the Map-Request and the devices which advertise the LSBs are the ones that report their status of them via a returned Map-Reply. And as I said in a previous email, the Map-Reply can be signed. You get more validation *from the mapping system* because the two parties (Map-Requestor and Map-Replier) have a shared trusted anchor point. That is the Map-Server(s) the ETR is registering with. 2b) If the ITR detects a transition from 0-to-1, we should believe it. There is no need to verify. But if we did verify, it would be more likely that the mapping system would report the same thing. If the LSB transition to either state, it should be verified. The only point where I can relate to what you are saying is to route away to the 1-to-0 transition. And to not route to new when the 0-to-1 transition has not been verified. But this could be splitting hairs. Also, in the bullet points above, I am not quite sure what the definition of a controlled environment is. Am I correct in assuming that an environment is controlled if it satisfies both of the following requirements: Controlled means trusted. For instance, a leaf/top-of-rack router in a data center who is encapsulating to another leaf router in the same data center or another one controlled and managed by the same organizational entity. -controlled from a security perspective. Bad guys cannot spoof LISP control information on the data plane. -controlled from a routing perspective. ETRs are aware of each others' status (and, therefore, can report on each others' status) because the participate in a common IGP. I believe solely on trust. Dino Ron -Original Message- From: Dino Farinacci [mailto:farina...@gmail.com] Sent: Monday, January 21, 2013 10:15 PM To: Ronald Bonica Cc: Noel Chiappa; lisp-inter...@cisco.com; lisp@ietf.org; lisp- b...@external.cisco.com Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet deployment? They have the same meaning in all environment. It is a question when they should be verified. An LSB that changes in a public environment can cause a Map-Request to be sent and a signed Map-Reply can verify the LSB in an authenticated matter. Dino On Jan 21, 2013, at 6:05 PM, Ronald Bonica rbon...@juniper.net wrote: Dino, But isn't it troubling that the bits have one meaning in a controlled environment and another in the great-wide Internet? Ron -Original Message- From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf Of Dino Farinacci Sent: Monday, January 21, 2013 5:51 PM To: Noel Chiappa Cc: lisp-inter...@cisco.com; lisp@ietf.org; lisp- b...@external.cisco.com Subject: Re: [lisp] Should we use Locator-Status-Bits in Internet deployment? (I don't remember off the top of my head why I didn't like them: I think it was a combination of the fixed number of bits, the fact that it might be difficult for ETR X to know the state of ETR Y, the fact that 'reachable from ITR A' [which you _really_ need to have anyway] is a subset of 'up', etc, etc. But we didn't desperately need the header bits, and the mechanism wasn't positively harmful, so I didn't bother to put up a big fight over it... :-) Maybe because they could be spoofed? But they are good in control environments to take ETRs out of service without having to update the mapping database. Dino ___ 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
Re: [lisp] Should we use Locator-Status-Bits in Internet deployment?
Maybe I'm confused, but I'm still not hearing why the LSB buys us anything above and beyond what we have to have anyway: i) mappings, and some way to detect that an ITR has an outdated copy of one, and ii) reachability (which necessarily has to discover, on a fairly real-time basis, a superset of 'up'). Noel, Dino, Thanks for clearing up my misconceptions regarding LSB function. Now, I think that we are in a better position to discuss Noel's question, above. Dino has suggested that the LSB provides a convenient way for ETRs to inform ITRs that locators have been taken in or out of service. This can be done without involving the mapping service. What the LSBs buy us is fast convergence. Let me explain. (1) An IGP operating in a small part of the network can converge faster than propagating control messages to remote ASes. (2) Once the IGP tells the data-plane, the data-plane sets these control bits. That means the control bits are sent from one AS to another very fast, via fast-switching of packets in the core routers. (3) The LSBs are NOT reachability status. They are source up/down status that the source knows about. Where the source here is the site that operates the xTRs. However, the mechanism only works in controlled environments. Furthermore, even in controlled environments, when the LSB==1, the ITR still has to test for reachability. This is because a locator can be in service, but unreachable from a particular ITR. (I am not sure about this, but when the LSB==0, might the ITR have to test for reachability anyway, just to ensure that things haven't changed). If your LSB bit is 0, it doesn't matter if the reachability to you is up, because if you are down, then it doesn't matter. However, if your LSB bit is 1, it means you are up. But from my part of the topology you may be unreachable, but from Noel's part of the topology you may be reachable. So up/down is global and reachability is pairwise. Do I have this much right? If so, does the LSB offer enough to be worth the complexity and processor load. I believe it is worth it and it is being used in different use-cases and environments. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
