Damien,
That's a very reasonable answer. Maybe Section 4.1 of the draft-ietf-lisp
should include a reference to Section 7.3 of draft-ietf-list-threats?
Ron
> -----Original Message-----
> From: Damien Saucez [mailto:[email protected]]
> Sent: Sunday, July 24, 2011 3:41 PM
> To: Ronald Bonica
> Cc: [email protected]
> Subject: Re: [lisp] gleaned mappings
>
> Hello,
> On 22 Jul 2011, at 15:48, Ronald Bonica wrote:
>
> > Folks,
> >
> > In Section 4.1 of the draft-ietf-lisp you say:
> >
> > In order to defer the need for a mapping lookup in the reverse
> > direction, an ETR MAY create a cache entry that maps the source EID
> > (inner header source IP address) to the source RLOC (outer header
> > source IP address) in a received LISP packet. Such a cache entry
> is
> > termed a "gleaned" mapping and only contains a single RLOC for the
> > EID in question. More complete information about additional RLOCs
> > SHOULD be verified by sending a LISP Map-Request for that EID.
> Both
> > ITR and the ETR may also influence the decision the other makes in
> > selecting an RLOC. See Section 6 for more details.
> >
> > Has anyone thought through the security implications and possible
> unexpected side effects of these "gleaned" mappings?
> >
>
> Gleaning can be used to leverage many attacks (see draft-ietf-lisp-
> threats). In
> this doc, we also provide a section related only to security issues
> with
> gleaning (Sec 7.3)
>
> Damien Saucez
>
> > Ron
> >
> >
> > _______________________________________________
> > lisp mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
