Hello, On 26 Feb 2015, at 02:19, Ross Callon <[email protected]> wrote:
>> 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. > ok, we will integrate that. Thank you for all your efforts! Damien Saucez > Thanks, Ross > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
