On 22 Jan 2013, at 10:15, Luigi Iannone <[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? Another question, how bad/good would it be for the traffic if two routers give different LSBs? > (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. > > 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. Damien Saucez > ciao > > Luigi > > > > > > On 22 Jan. 2013, at 04:15 , Dino Farinacci <[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]> 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]] On Behalf Of >>>> Dino Farinacci >>>> Sent: Monday, January 21, 2013 5:51 PM >>>> To: Noel Chiappa >>>> Cc: [email protected]; [email protected]; lisp- >>>> [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] >>>> 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
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
