Subject: [lisp] LISP Threats Document Review

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Dec 2012 20:24:45 -0500

In conjunction with the WG last call on this document, I performed my 
own review.

I am confused by the attack remediation in section 5.3.  This seems t 
say that an ETR should reject any packet whose source RLOC is not valid 
for the source EID. This would seem to frequently doubling the packet 
drop for initial communication between two sites, which seems 
unfortunate.  This recommendation is repeated in the first bullet of 
section 11.  Is this really the WG recommendation?

Also, I have some minor issues.
Section 5.2.2 on EID-to-RLOC Cache overflow is written as if this can 
only be caused by control plane attacks, or by a device performing 
gleaning.  This seems to ignore one other attack vector.  It is not a 
vector which can inject fake entries, but it can disrupt operation. 
Namely, an insider sending packets to a broad range of EIDs.  By 
assumption, the cache is not big enough to hold the whole mapping table 
(otherwise it would not be subject to overflow).  It would therefore 
seem that this sort of attack could disrupt valid entries and interfere 
with proper ITR operation.  Shouldn't this be mentioned?

Could / should the caveat about rate limiting queries in section 5.4.1 
be moved up in the section, so that the reader realizes early what is 
needed?

I am wondering about the tradeoff of including DDT in this document.  On 
the one hand, DDT is where we likely are going.  On the other hand, 
including that material will mean that this document gets an RFC Editor 
hold until LISP DDT is published.  Would it make more sense to defer the 
DDT specific section to the DDT document?

Editorial:
     The title of section 5.3, "Attacks not leveraging on the LISP 
header" seems to have a grammatical error.  I think the word "on" is 
extraneous.  (And similarly for section 5.4)

Yours,
Joel M. Halpern

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 13 Dec 2012 09:27:57 +0100

Hi Joel,

thank you very much for your review. Few comments inline.

On 13 Dec. 2012, at 02:24 , Joel M. Halpern <[email-masked]> wrote:

> In conjunction with the WG last call on this document, I performed my own review.
> 
> 
> I am confused by the attack remediation in section 5.3.  This seems t say that an ETR should reject any packet whose source RLOC is not valid for the source EID. This would seem to frequently doubling the packet drop for initial communication between two sites, which seems unfortunate.  This recommendation is repeated in the first bullet of section 11.  Is this really the WG recommendation?

Yes and No. This has been discussed several times in between other things. My suggestion is to change the following sentence of section 5.3 from:

   "the LISP ETR should reject the packet and possibly
   query the mapping system to obtain a mapping for the encapsulated
   source EID (HA)."

to:

   "the LISP ETR should reject the packet and query the 
    mapping system to obtain a mapping for the encapsulated
    source EID (HA). Note that this may increase communication 
    setup latency due to the delay in retrieving a mapping for
    the source EID on the ETR."

I would not mention packet drops since LISP does not enforce any specific action for packets with missing mappings (yes current implementations drop the packets but  is not part of the specifications.)

> Section 5.2.2 on EID-to-RLOC Cache overflow is written as if this can only be caused by control plane attacks, or by a device performing gleaning.  This seems to ignore one other attack vector.  It is not a vector which can inject fake entries, but it can disrupt operation. Namely, an insider sending packets to a broad range of EIDs.  By assumption, the cache is not big enough to hold the whole mapping table (otherwise it would not be subject to overflow).  It would therefore seem that this sort of attack could disrupt valid entries and interfere with proper ITR operation.  Shouldn't this be mentioned?

Good point. We can add a small paragraph mentioning it. 

> 
> Could / should the caveat about rate limiting queries in section 5.4.1 be moved up in the section, so that the reader realizes early what is needed?

Could: Yes
Should: IMO no.
Rate Limitation is not the key point of the section.

> 
> I am wondering about the tradeoff of including DDT in this document.  On the one hand, DDT is where we likely are going.  On the other hand, including that material will mean that this document gets an RFC Editor hold until LISP DDT is published.  Would it make more sense to defer the DDT specific section to the DDT document?

Another good point but actually goes beyond DDT IMO. If we put ALT and MS make sense to me to put DDT as well. 

> 
> Editorial:
>    The title of section 5.3, "Attacks not leveraging on the LISP header" seems to have a grammatical error.  I think the word "on" is extraneous.  (And similarly for section 5.4)
> 

Thanks, we'll fix.

Luigi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Dec 2012 11:39:46 -0500

Thank you for responding to my comments.
With regard to the discussion of MS, ALT, and DDT, it seems to me that 
there are a couple of reasons for splitting DDT out:

1) MS and ALT are already documented, and need better security 
description.  This seems the sensible place to fill that.  IN contrast, 
the security information for DDT can be included in that document.

2) In theory there can be yet other mapping systems.  This document can 
not deal with all future cases.

I would like t be able to complete this short term deliverable without 
making it dependent upon a long term deliverable.

Yours,
Joel

On 12/13/2012 3:27 AM, Luigi Iannone wrote:
>>> I am wondering about the tradeoff of including DDT in this
>>> document.  On the one hand, DDT is where we likely are going.  On
>>> the other hand, including that material will mean that this
>>> document gets an RFC Editor hold until LISP DDT is published.
>>> Would it make more sense to defer the DDT specific section to the
>>> DDT document?
> Another good point but actually goes beyond DDT IMO. If we put ALT
> and MS make sense to me to put DDT as well.
>
>

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 14 Dec 2012 12:01:38 +0100

Hi Joel,

I've got your point. 

Your suggestion is to take out the DDT section and put it in the DDT document (right?).

For the first part (take it out from this doc) I have no problems. For the second part (put it in the DDT doc) is up to the DDT authors, according with their plans for the document. 
(simplest solution is to cut & paste as it is  ;-) )

ciao

Luigi

On 13 Dec. 2012, at 17:39 , Joel M. Halpern <[email-masked]> wrote:

> With regard to the discussion of MS, ALT, and DDT, it seems to me that there are a couple of reasons for splitting DDT out:
> 
> 1) MS and ALT are already documented, and need better security description.  This seems the sensible place to fill that.  IN contrast, the security information for DDT can be included in that document.
> 
> 2) In theory there can be yet other mapping systems.  This document can not deal with all future cases.
> 
> I would like t be able to complete this short term deliverable without making it dependent upon a long term deliverable.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Dec 2012 11:27:15 -0500

Agreed, your action would be to remove the DDT material from this document.
The question of how the DDT spec handles having sufficient security 
discussion is a separate matter.

Yours,
Joel

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 17 Dec 2012 09:34:41 +0100

Hi,

Ack.

Should we issue a new version of the document now or wait after the closure of the LC?

L.

On 14 Dec. 2012, at 17:27 , Joel M. Halpern <[email-masked]> wrote:

> The question of how the DDT spec handles having sufficient security discussion is a separate matter.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Dec 2012 11:28:48 -0500

I hope that there will be more comments from the working group.
So let's wait to issue the revision.
Thank you,
Joel