Subject: Re: [lisp] Restarting last call on LISP threats

From: Ronald Bonica <[email-masked]>
Date: Tue, 10 Jun 2014 16:57:50 +0000

Folks,

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.

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.

Ron Bonica

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Jun 2014 10:03:51 -0700

> 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, w…

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…

What you can glean is that the source RLOC is up, but you cannot glean your path to it is reachable.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 10 Jun 2014 17:06:42 +0000

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-masked]]
> 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
> 
> 
> > 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.
> 
> > 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.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jun 2014 13:17:34 -0400

I think that the treat scopes for the two cases are different.  Gleaning 
new RLOCs is clearly a significant risk.
Gleaning the liveness of an RLOC from the fact that it appears to be 
talking to you is a much lower risk.  With a much higher benefit.  I 
have no problem with noting that there is a risk, albeit somewhat 
complex.  But it should not be viewed in the same manner.  (All security 
is a matter of costs and benefits.)

Yours,
Joel

On 6/10/14, 1:06 PM, Ronald Bonica wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Jun 2014 10:22:59 -0700

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

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 10 Jun 2014 19:37:41 +0000

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

> Sent: Tuesday, June 10, 2014 1:23 PM
> To: Ronald Bonica
> 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
> 
> >> 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.
> >>
> >> 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.
> >>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Jun 2014 12:46:50 -0700

> - An ITR receives a hint indicating that the RLOC is down (either through a LISP data packet or an ICMP message)

How? The way you say does not give any such indication.

> The ITR will verify RLOC reachability (possibly by polling the RLOC). But until the ITR has receives a response

It needs to verify the mapping first. It needs to determine if the source-EID in the data packet is associated with the RLOC that was in the data packet from the mapping database system.

>  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. 

Verify the mapping, then cache it locally as "verified" and then RLOC-probe the best priority RLOCs so you can see if they are reachable. You can do this before encapsulating packets to the RLOCs or concurrently. Depending if your implementation wants to take a leap of faith.

> However, both behaviors have their drawbacks and could be vectors for attack.

You did not describe the problem well, so no conclusions should be made.  ;-)

Dino

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 11 Jun 2014 22:28:39 +0000

On Jun 10, 2014, at 10:17 AM, Joel M. Halpern <[email-masked]> wrote:

> I think that the treat scopes for the two cases are different.  Gleaning new RLOCs is clearly a significant risk.
> Gleaning the liveness of an RLOC from the fact that it appears to be talking to you is a much lower risk.  With a much higher benefit.  I have no problem with noting that there is a risk, albeit somewhat complex.  But it should not be viewed in the same manner.  (All security is a matter of costs and benefits.)

And to add one more bit of detail here, gleaning the liveness of an RLOC who’s status bit has changed can be (and is in our IOS implementation) verified by a rate-limited RLOC Probe.

-Darrel

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Jun 2014 00:17:44 +0000

Hi Darrel,

Does IOS implement a single RLOC Probe rate limiter (i.e. one rate limiter per box)? Or does it implement one rate limiter per RLOC?

                                                                     Ron

> From: Darrel Lewis (darlewis) [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2014 6:29 PM
> To: Joel M. Halpern
> Cc: Darrel Lewis (darlewis); Ronald Bonica; Dino Farinacci; LISP mailing list list
> > complex.  But it should not be viewed in the same manner.  (All
> > security is a matter of costs and benefits.)
> 
> And to add one more bit of detail here, gleaning the liveness of an RLOC
> who's status bit has changed can be (and is in our IOS implementation)
> verified by a rate-limited RLOC Probe.
> 
> -Darrel
> 
> >
> > Yours,
> > Joel
> >
> >> 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
> >>
> >>
> >>> 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

---

From: Damien Saucez <[email-masked]>
Date: Thu, 12 Jun 2014 14:07:46 +0200

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

---

From: Ross Callon <[email-masked]>
Date: Thu, 12 Jun 2014 15:09:37 +0000

> 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. 

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. 

Ross

-----Original Message-----
From: lisp [mailto:[email-masked]] 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,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Jun 2014 08:24:31 -0700

> 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 ph…

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…

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

---

From: Ross Callon <[email-masked]>
Date: Thu, 12 Jun 2014 15:28:49 +0000

> 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

This I agree with. I will go off and digest the rest.

Thanks, Ross

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Jun 2014 08:37:35 -0700

But Ross I would like to clarify further. There are many issues with data packet gleaning. I think there are far less with control-plane packet payload gleaning since there are many more LISP designed control-plane mechanisms that can be used OUTSIDE of the data path.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Jun 2014 12:15:38 -0400

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Jun 2014 09:23:09 -0700

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 <[email-masked]> 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.
> 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.
> 
> Which means that peoples wonderful ideas on how to do more or better will never get publsihed.
> 
> Yours,
> Joel
>

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Jun 2014 17:20:59 +0000

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

> From: Damien Saucez [mailto:[email-masked]]
> Cc: Dino Farinacci; LISP mailing list list
> 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
> 
> > - 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.
> >
> >> 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
> >>
> >>> 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
> >>>
> >>>
> >>>> 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

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 16 Jun 2014 17:21:56 +0200

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

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 16 Jun 2014 15:48:43 +0000

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

> From: lisp [mailto:[email-masked]] On Behalf Of Luigi Iannone
> Sent: Monday, June 16, 2014 11:22 AM
> To: Dino Farinacci
> fair point. I guess that Joel's point was on the fact that this specific thread
> should focus on the LISP threats document.
> 
> > 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?
> >
> documents, operational practices, or people's heads, are not the topic for
> the WG at this time.
> >>
> >>>>> 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.
> >>>
> >>> 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.
> >>>
> >>>> 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.
> >>>>
> >>>>> 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
> >>>>>>>> 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
> >>>>>>>> What you can glean is that the source RLOC is up, but you
> >>>>>>>> cannot glean your path to it is reachable.
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>
> >>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Jun 2014 12:04:18 -0400

Personally, I don't see any need to analyse mitigations to discuss 
classes of attacks.

Yours,
Joel

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 16 Jun 2014 16:39:48 +0000

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

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, June 16, 2014 12:04 PM
> To: Ronald Bonica; Luigi Iannone; Dino Farinacci
> Personally, I don't see any need to analyse mitigations to discuss classes of
> attacks.
> 
> Yours,
> Joel
> 
> > 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:
> >
> >> fair point. I guess that Joel's point was on the fact that this
> >> specific thread should focus on the LISP threats document.
> >>
> >> So to clearly separate what is related to the threats document and
> >> what are new proposals to alleviate some threats.
> >>
> >> ciao
> >>
> >> Luigi
> >>
> >>
> >>
> >>>> Can we PLEASE not get into debating how we would solve the
> weakness
> >> in the protocol as documented.
> >>>>
> >> documents, operational practices, or people's heads, are not the
> >> topic for the WG at this time.
> >>>>
> >>>>> The source EID is encrypted so it can only see a cleartext source
> >>>>> RLOC
> >> and can't associated it with anything.
> >>>>>
> >> 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.
> >>>>>
> >> 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.
> >>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>>> - An ITR receives a hint indicating that the RLOC is down
> >>>>>>> (either through a LISP data packet or an ICMP message)
> >>>>>>>
> >> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica
> >>>>>>>> <[email-masked]>
> >> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Dino,
> >>>>>>>>>
> >>>>>>>>>> LISP data packets as described in RFC 6830, Section 6.3,
> >>>>>>>>>> bullet 1. If not, I think that we need to mention

---

From: Damien Saucez <[email-masked]>
Date: Mon, 16 Jun 2014 19:18:46 +0200

Hello Ron,

If ever a mitigation introduces a new threat, it does not mean that
it is impossible to make threat categories.

Actually, if a threat can be put in one category, the threat on the
mitigation can correspond to another.  That does not weaken the
document.

So all what we need is to be able to construct a complete threat
categorisation.

Thank you,

Damien Saucez

---

From: Brian Haberman <[email-masked]>
Date: Mon, 16 Jun 2014 14:32:54 -0400

Let's just say I am commenting as an interest observer...

> Personally, I don't see any need to analyse mitigations to discuss

Is the above meant to imply that the lisp-threats document should not
discuss the costs imposed by the mitigation technique?

If not, will lisp-sec document the approaches to mitigating all the
attacks listed in lisp-threats (and their perceived costs)?

Regards,
Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Jun 2014 14:43:55 -0400

My understanding is that security oriented threat analyses documents do 
not generally, and the charter item for this document does not 
specifically, call out mitigations.  Mitigation is, as your comment 
suggests, a complex tradeoff as different mitigations have different 
costs and different efficacy.  So the tradeoff in using mitigation 
would, it seems to me, need to be in the document that proposes the 
mechanisms.

Yours,
Joel

---

From: Brian Haberman <[email-masked]>
Date: Mon, 16 Jun 2014 14:50:05 -0400

Hi Joel,

> would, it seems to me, need to be in the document that proposes the

The charter work item says:

    - LISP security threats and solutions

My question was whether the WG plans to overhaul lisp-sec to describe
the mitigations/solutions to the threats described in lisp-threats or
just put them in one document.

Regards,
Brian

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 17 Jun 2014 10:43:09 +0200

Hi,

>    - LISP security threats and solutions

Previous versions of the threats document gave some “recommendations” (like fo instance the use of lisp-sec), but discuss on the ML and WG meetings lead to drop that section. So, why going back now?

> just put them in one document.

IMHO LISP-sec is a specific solution for a specific set of threats, hence, while it has to clearly state which attacks it solves I do not think that has to discuss all possible mitigations for the all possible threats. 

I was also thinking that similarly to the fact that threats are described by class, mitigation techniques (if we ever want to re-introduce them) should also be “cited” by class. 
I use the word “cited” because I do not think we need to document the details but just refer to existing techniques that can be used.
(note that this was more or less what we had in early versions of the document)

ciao

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 17 Jun 2014 10:43:26 +0200

Hi Ron,

I tend to agree with Joel on the fact that to class attacks we do not need the mitigations. 

Yet, I agree that if a possible mitigation for a threat can introduce another threat then this induced threat should be document.

ciao

Luigi

---

From: Ross Callon <[email-masked]>
Date: Wed, 18 Jun 2014 04:43:37 +0000

Is the goal to actually understand whether LISP would be secure if deployed operationally on Internet-wide scale, or is the goal to satisfy some checklist issue in order to complete the work? 

Ross

-----Original Message-----
From: lisp [mailto:[email-masked]] On Behalf Of Joel M. Halpern
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

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 Jun 2014 00:45:58 -0400

Both of course.
We as a working group agreed to separate the document tasks.  One 
document is to understand the threats, and others (because it is a 
continuing task) to address them.

Yours,
Joel