Re: [lisp] Restarting last call on LISP threats

[Ronald Bonica <[e-mail]>]

Joel,

IMHO, there is a very distinct need. 

As we have seen previously in this email thread, some mitigations introduce new threats. For example, the ITR's self-imposed rate limit on map requests mitigates one threat and introduces another.

If we don't discuss mitigations at all, we sweep a very important fact under the carpet.

                                                                                                                                                                     Ron

> -----Original Message-----
> From: Joel M. Halpern [mailto:[e-mail]]
> Sent: Monday, June 16, 2014 12:04 PM
> To: Ronald Bonica; Luigi Iannone; Dino Farinacci
> Cc: LISP mailing list list
> Subject: Re: [lisp] Restarting last call on LISP threats
> 
> Personally, I don't see any need to analyse mitigations to discuss classes of
> attacks.
> 
> Yours,
> Joel
> 
> On 6/16/14, 11:48 AM, Ronald Bonica wrote:
> > Ciao Luigi,
> >
> > If only it were that easy! In the threats document, we have two choices:
> >
> > - enumerate every attack that we can imagine
> > - document abstractions that describe broad classes of threats
> >
> > If we enumerate every attack, we will never finish. Therefore, we are
> forced to document attack classes. IMHO, two attacks can be grouped
> together into a class if both of the following conditions are true:
> >
> > - the attacks exploit the same features of the protocol
> > - the attacks can be addressed using the same mitigation
> >
> > If we don't understand mitigations, how will we ever group attacks into
> classes?
> >
> >
> > Ron
> >
> >> -----Original Message-----
> >> From: lisp [mailto:[e-mail]] On Behalf Of Luigi Iannone
> >> Sent: Monday, June 16, 2014 11:22 AM
> >> To: Dino Farinacci
> >> Cc: LISP mailing list list
> >> Subject: Re: [lisp] Restarting last call on LISP threats
> >>
> >> Hi Dino,
> >>
> >> fair point. I guess that Joel's point was on the fact that this
> >> specific thread should focus on the LISP threats document.
> >>
> >> Obviously this mailing list is the place where all technical
> >> discussions about LISP can take place.
> >>
> >> We should just fork the discussion.
> >>
> >> So to clearly separate what is related to the threats document and
> >> what are new proposals to alleviate some threats.
> >>
> >> ciao
> >>
> >> Luigi
> >>
> >>
> >>
> >> On 12 Jun 2014, at 18:23, Dino Farinacci <[e-mail]> wrote:
> >>
> >>> I agree we should be focused Joel.
> >>>
> >>> But where else should we have open discussions about LISP?
> >>>
> >>> This mailing list membership is unique in that we have multiple
> >>> vendors,
> >> operators, and users all in one place. Wouldn't that make for better
> >> protocols?
> >>>
> >>> Yes we have business to take care of but let's not stifle ideas and
> >> openness. Do you agree?
> >>>
> >>> Dino
> >>>
> >>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern <[e-mail]>
> >> wrote:
> >>>
> >>>> I will repeat myself.
> >>>> Can we PLEASE not get into debating how we would solve the
> weakness
> >> in the protocol as documented.
> >>>>
> >>>> The question focus on is whether the protocol as specified has the
> >> behavior described, and if so does it result in the weakness described.
> >>>> If it does, that should be described in the threats document.
> >>>> if not, then it should not be so described.
> >>>>
> >>>> The presence, absence, validity, or possibility of solutions in
> >>>> other
> >> documents, operational practices, or people's heads, are not the
> >> topic for the WG at this time.
> >>>>
> >>>> PLEASE stay on topic, or we will never get our current work done.
> >>>> Which means that peoples wonderful ideas on how to do more or
> >>>> better
> >> will never get publsihed.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote:
> >>>>>
> >>>>>>> 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.
> >>>>>>
> >>>>>> If an attacker is on-path it could see the nonce's (assuming that
> >>>>>> the LISP
> >> header is not encrypted, regardless of whether the data packet is
> >> encrypted). This could be an issue if the attacker is physically on-path.
> >>>>>
> >>>>> The source EID is encrypted so it can only see a cleartext source
> >>>>> RLOC
> >> and can't associated it with anything.
> >>>>>
> >>>>> When we merge lisp-cryto logic with echo-noncing, one has to
> >> determine if an xTR should participate in echo-noncing if the payload
> >> is not decrypted properly. That is, if I get a echoed nonce back from
> >> an attacker for a nonce I know I have sent and set the E-bit, and I
> >> cannot decrypt the payload that comes from the attacker, then I don't
> >> believe any NEW reachability information about the RLOC.
> >>>>>
> >>>>>> This could also be an issue for attackers which are physically
> >>>>>> off-path if
> >> gleaning is used, since an attacker could use a gleaning attack to
> >> temporarily insert itself on-path, which in turn would allow it to see the
> nonce.
> >>>>>
> >>>>> So by now we know there are many issues with gleaning. So we
> >>>>> should
> >> document them and say they shouldn't be used for the general global
> >> Internet use-case.
> >>>>>
> >>>>> Dino
> >>>>>
> >>>>>>
> >>>>>> Ross
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: lisp [mailto:[e-mail]] On Behalf Of Damien
> >>>>>> Saucez
> >>>>>> Sent: Thursday, June 12, 2014 8:08 AM
> >>>>>> To: Ronald Bonica
> >>>>>> Cc: 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 <[e-mail]>
> 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:[e-mail]]
> >>>>>>>> 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
> >>>>>>>> <[e-mail]>
> >> 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:[e-mail]]
> >>>>>>>>>> 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
> >> <[e-mail]> 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
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> lisp mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> lisp mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>>>
> >>>>> _______________________________________________
> >>>>> lisp mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>>>
> >>>
> >>> _______________________________________________
> >>> lisp mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/lisp
> >>
> >> _______________________________________________
> >> lisp mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/lisp
> >
> > _______________________________________________
> > lisp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lisp
> >