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. > >> >> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
