Re: [lisp] Progress on threats document

[Ross Callon <[e-mail]>]

> Hello Ross,
> 
> Thank you for the feedback.
>
> Answers and propositions inline.

I have deleted items on which we have already reached agreement. Otherwise comments in-line. Also, I thought of a few other issues, but for readability I will mention them in a separate email which I will send a few minutes after this one. 

-----Original Message-----
<some items deleted here for which we are in agreement>

>> Section 2.1.4: This section correctly mentions that it is possible for an attacker to operate 
>> in the data plane to mount attacks targeting the control plane (or vice versa). However, the
>> implication of this, in terms of the difference in speeds of the two planes, is not discussed
>> anywhere. I am not sure where this should be discussed, but this is a sufficiently important
>> issue that it should be discussed somewhere. I have wondered whether this should be mentioned
>> here, or in section 2.2.9 (since this could be thought of as a form of amplification attack).
>> Perhaps the most straightforward way to fix this would to be append to the second paragraph of
>> section 2.1.4 a couple of additional sentences that state: "In some cases, particularly in very
>> high performance routers, the data plane may operate faster, and potentially several orders of
>> magnitude faster, relative to the control plane. Launching an attack in the data plane that is
>> targeted at the control plane may therefore greatly amplify the affect of the attack (ie serve
>> a function similar to an amplification attack)." 

>
> What about adding this to the end of section 2.2.9?
>
> In some cases, the data-plane can be several order of magnitude faster than the control-plane
> at processing packets. This difference can be exploited to overload the control-plane via the
> data-plane without overloading the data-plane.

I think that this reads well and makes the point. 

<more deleted>

>> Section 3.9, fourth paragraph. This currently reads:
>> 
>>   A compromised ETR can also de-aggregate its EID prefix in order to
>>   register more EID prefixes than necessary to its Map Servers (see
>>   Section 3.7 for the impact of de-aggregation of prefixes by an
>>   attacker).
>> 
>> I think that it might be worth mentioning: De-aggregation could occur as part of an
>> intentional attack, but could also occur as an unintended side effect of normal
>> operation if over time too many LISP sites advertise relatively de-aggregated or
>> very fine grained mappings. 

> While technically the point you are making is correct, this document is only about security and is therefore preferable to focus on attacks.

Okay. 

>> Section 4, "Note on privacy". Second paragraph. This currently reads: 
>> 
>>   Note, however, that like public deployments of any other control
>>   plane protocol, in an Internet deployment mappings are public and
>>   hence provide information about the infrastructure and reachability
>>   of LISP sites (i.e., the addresses of the edge routers).
>> 
>> The amount of information made available with LISP, particularly in map replies, is
>> finer grained than what is available with current routing protocols. Certainly with
>> current protocols ping could in principle give fine grained information (if I trace
>> route across my ISP, and if they let me do it, then I would find out the IP addresses
>> of routers), but it is largely turned off just for this reason. I think that it would
>> be more accurate to say: 
>> 
>>   Like public deployments of any other control
>>   plane protocols, in an Internet deployment mappings are public and
>>   hence provide information about the infrastructure and reachability
>>   of LISP sites (i.e., the addresses of the edge routers). LISP map 
>>   replies may however provide finer grained and more detailed
>>   information to a wider set of Internet sites than is available with 
>>   currently control protocols.  

> The sentence you are proposing is not completely correct. 
> LISP does not provide fine grained information about the infrastructure. 
> LISP only allows to clearly identify ASBRs that are running LISP functions.
> Furthermore, being smart with BGP already allows you to infer business 
> relationship between ASes, this is a kind of very precise information 
> that can be retrieved with current control protocol. 

Yes, LISP does allow / cause identification of routers on borders (either CE or PE routers, which I think are correctly termed "ASBRs"). It does not, as far as I know, allow identification of other routers (such as provider core P routers, or routers that do not choose to implement/deploy LISP). BGP does already reveal the identification of some border routers. There is commonly abbreviation of some of the BGP information and not all of the border routers will be BGP speaking. My understanding is that there are many CE routers who might or might not run BGP with PE routers, but even if they do their identity does not get sent out in the broad Internet-wide routing updates (eg, because the CE router is advertising an address block that is in the Provider's PA space, so that it gets summarized before being spread widely). How about if we "adjust" the text that I proposed to read as follows (and noting that the first sentence here is from the current threats document): 

   Like public deployments of any other control
   plane protocols, in an Internet deployment mappings are public and
   hence provide information about the infrastructure and reachability
   of LISP sites (i.e., the addresses of the edge routers). Depending upon
   deployment details, LISP map replies might or might not provide finer
   grained and more detailed information than is available with 
   currently deployed routing and control protocols.  

Thanks, Ross