> 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:[email protected]] >> Sent: Monday, January 21, 2013 10:15 PM >> To: Ronald Bonica >> Cc: Noel Chiappa; [email protected]; [email protected]; lisp- >> [email protected] >> 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 <[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
