Hi Damien,
According to RFC 6830, Section 6.3, bullet 2:
"An ITR may receive an ICMP Network Unreachable or Host Unreachable message for
an RLOC it is using. This indicates that the RLOC is likely down. Note that
trusting ICMP messages may not be desirable, but neither is ignoring them
completely. Implementations are encouraged to follow current best practices in
treating these conditions."
Where are those best common practices defined? Since this is a trust issue, I
would look to the threats document.
Ron
> -----Original Message-----
> From: Damien Saucez [mailto:[email protected]]
> Sent: Thursday, June 12, 2014 8:08 AM
> To: Ronald Bonica
> Cc: Dino Farinacci; LISP mailing list list
> Subject: Re: [lisp] Restarting last call on LISP threats
>
> Hello,
>
> I am not sure I understand exactly what you are proposing. How can a LISP
> router decide that a RLOC is done by simply receiving an ICMP packet from an
> attacker (except with LSB that is discussed in Sec 4.3.2.1. )? All the other
> techniques are triggered by the LISP router and are protected by the nonce.
>
> Could you describe precisely the attack you have in mind? The only think I
> can see is relying on the birthday paradox but that is a completely different
> story.
>
> Damien Saucez
>
> On 10 Jun 2014, at 21:37, Ronald Bonica <[email protected]> wrote:
>
> > Dino,
> >
> > Exactly! So, assume the following:
> >
> > - LISP is deployed on the global Internet
> > - An RLOC is mapped to some number of EID prefixes
> > - For a subset of those EID prefixes, the above mentioned RLOC is
> > preferred
> > - An ITR receives a hint indicating that the RLOC is down (either
> > through a LISP data packet or an ICMP message)
> >
> > The ITR will verify RLOC reachability (possibly by polling the RLOC). But
> > until
> the ITR has receives a response to its poll, how should it behave? Should it
> continue sending traffic though the above mentioned RLOC? Or should it
> begin to send traffic through another RLOC, if one exists? I don't see a
> normative recommendation.
> >
> > However, both behaviors have their drawbacks and could be vectors for
> attack.
> >
> >
> > Ron
> >
> >
> >> -----Original Message-----
> >> From: Dino Farinacci [mailto:[email protected]]
> >> Sent: Tuesday, June 10, 2014 1:23 PM
> >> To: Ronald Bonica
> >> Cc: LISP mailing list list
> >> Subject: Re: [lisp] Restarting last call on LISP threats
> >>
> >> As I keep saying Ron, you need to verify anything you intend to
> >> glean. The spec says the gleaning is "a hint" and not gospel.
> >>
> >> Dino
> >>
> >> On Jun 10, 2014, at 10:06 AM, Ronald Bonica <[email protected]>
> wrote:
> >>
> >>> Hi Dino,
> >>>
> >>> Given that the LISP data packet or ICMP packet may be from an
> >>> attacker, is
> >> it even safe to glean that? I think not.
> >>>
> >>>
> >>> Ron
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Dino Farinacci [mailto:[email protected]]
> >>>> Sent: Tuesday, June 10, 2014 1:04 PM
> >>>> To: Ronald Bonica
> >>>> Cc: LISP mailing list list
> >>>> Subject: Re: [lisp] Restarting last call on LISP threats
> >>>>
> >>>>
> >>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica <[email protected]>
> wrote:
> >>>>
> >>>>> Earlier in this thread, we agreed that when LISP is deployed on
> >>>>> the global
> >>>> Internet, mapping information cannot be gleaned safely from
> >>>> incoming LISP data packets. Following that train of thought, when
> >>>> LISP is deployed on the global Internet, is it safe to glean
> >>>> routing locator reachability information from incoming LISP data
> >>>> packets as described in RFC 6830, Section 6.3, bullet 1. If not, I
> >>>> think that we need to mention
> >> this in the threats document.
> >>>>
> >>>> What you can glean is that the source RLOC is up, but you cannot
> >>>> glean your path to it is reachable.
> >>>>
> >>>>> Given that ICMP packets are easily spoofed, when LISP is deployed
> >>>>> on the
> >>>> global Internet, is it safe to glean routing locator reachability
> >>>> information from incoming ICMP packets as described in RFC 6830,
> >>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to
> >>>> mention this in the threats document.
> >>>>
> >>>> What you can glean is that the source RLOC is up, but you cannot
> >>>> glean your path to it is reachable.
> >>>>
> >>>> 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
