Hi Lorand, > -----Original Message----- > From: Loránd Jakab [mailto:[email protected]] > Sent: Wednesday, September 21, 2011 7:50 AM > To: Templin, Fred L > Cc: [email protected]; [email protected] > Subject: Re: [lisp] Source address spoofing by a node > pretending to be an ITR? > > Hi Fred, > > On 09/20/11 17:21, Templin, Fred L wrote: > > > >> Do I really want to go in the direction of requiring > >> cryptography? I can't answer that unless you first > >> tell me the intended domain of applicability. I don't > >> think I have yet seen a use case analysis of the > >> various scenarios where LISP xTRs and mapping systems > >> would be deployed and used. There seems to be an > >> unspoken assumption of deployment "in the public > >> Internet", but what about Enterprise networks? > >> What about MANETs? What about aviation networks? > >> What about tactical military networks? What about > >> cellular networks? What about home networks? > >> > > > > That is the purpose of the deployment document. > > > > http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 > > > > > > From a brief look, that document appears to have quite a ways to > > go until it considers a wider variety of use cases such as we have > > addressed in RANGERS. > > We know of other interesting use cases for LISP, but so far only > documented the ones related to DFZ size, to stay on the WG charter.
OK. It would be interesting to note the areas of overlap and mutual exclusion between the LISP and IRON domains of applicability. > > The document also seems to carefully > > step around the MTU issue, as if it were a booby trap to be always > > on guard for. IRON (with SEAL) *solves* the MTU issue so that > > there is no longer any need to worry about it. Until LISP truly > > addresses the MTU issue (including accounting for the common > > case of operators misconfiguring link MTUs) all LISP-related > > documents will have to carefully dance around it. > > The main spec discusses two possible solutions to MTU issues > in Section > 5.4. I think we need more experimentation with LISP to discuss it at > more detail in a deployment document (we do call attention to > it at the > end of Section 2.1). And also in Sections 2.2, 2.3, 2.4 and 2.6. That is quite a bit of deliberation about MTU, and I think goes to show the degree of uncertainty in the main document's approach even before an experiment is conducted. So what makes more sense? To go forward with a "slacker's" approach that is riddled with doubts which might not even be satisfied through extensive experimentation, or to adopt a lightweight mechanism from IRON/SEAL that stands a good chance of erasing all doubts? Thanks - Fred [email protected] > Best regards, > Lorand Jakab > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
