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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]> >>>>>> [mailto:[email protected] <mailto:[email protected]>] On Behalf Of >>>>>> Dino Farinacci >>>>>> Sent: Monday, January 21, 2013 5:51 PM >>>>>> To: Noel Chiappa >>>>>> Cc: [email protected] <mailto:[email protected]>; >>>>>> [email protected] <mailto:[email protected]>; lisp- >>>>>> [email protected] <mailto:[email protected]> >>>>>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/lisp >>> _______________________________________________ >>> lisp mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/lisp >> >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Engineer NTUA/GR-Net Network Management Center _____________________________________ skype: aweboy voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: [email protected] _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
