On Tue, Apr 08, 2008 at 05:19:40PM +0200, Roland Bless wrote: > Hi Dave, > > thanks for your fast response, comments inline... Any time... > David Meyer wrote: > >> * Sec 3., p.11: "Data probe" definition: at this > >> point it is not clear whether the data probe packet > >> is a kind of special packet or whether it's a normal > >> packet (one could guess the latter since you don't > >> want end-host modifications...) > > > > Right, its not a special packet (in terms of there being a > > "Data Probe" packet format). Its just a packet in which > > the inner and outer destination are the same, and which > > is routed over the LAT to the ETR that is authoritative > > for the EID-prefix covering the EID in the destination > > address field in the outer header. > > My point was just that a reader doesn't know these details when > reading the terminology section. Ok, gotcha. We'll fix in the next version > > > The point of routing this packet over the LAT, of course, > > is to avoid losing the first packet in a flow (we've had > > a massive discussion on the list about packet loss, > > delay, etc). BTW, this is a fairly generic problem, and > > turns up in a wide variety of places (ARP, multicast > > bursty source, etc). > > Yep. > > > The crucial point to obsever here, however, is that the > > Data Probe packet is used only for the *first flow > > between sites*, not between individual flows or anything > > more granular than the EID-prefix returned to the ITR in > > the Map-Reply. In particular, after the first (Data > > Ok, good, probably this point should be emphasized in the next draft > version. Noted. > > > functionality. We're really working on LISP 3 (i.e., > > the case in which EIDs are not routable on the global > > Internet, and are used by the ITRs keys to lookup the > > EID-to-RLOC mapping in some database). The current focus > > is on LISP+ALT. > > Fine. > > >> * Sec. 4.1, number 5: > >> as probably already discussed on the list > >> is caching in the ITR basically a problem if > >> end-systems send packets to a large number of > >> different EIDs. IMHO this is a source for trouble > >> or target for DoS attacks as we experienced also > >> problems with (route) caching during sending probing > >> packets to randomly generated IP addresses (for some kind > >> of bootstrapping P2P overlays). So if the > >> cache is not something like a complete FIB today, > >> I see problems that such communication patterns > >> will not work properly with LISP. > > > > Can you be more specific about the problems you are > > concerned about? Is there something beyond the standard > > DoS case against a cache (distributed scanning attack or > > the like)? > > Probably not. What I meant was: > If a single end-system sends packets to all different EID prefixes > (e.g., as some kind of random probing mechanism...), then the > ITR is presumably in trouble if the cache cannot hold all the different > EID prefixes and their mappings, because it may have to preempt a large > portion of already cached entries. The effect will get worse if you have > several such end-systems behaving like this. This behavior may, however, > be not malicious but legitimate. > So is there any idea about the cache size? Would it be at the current > size of a FIB or much smaller? Understand. We think the cache will be much smaller (due EID aggregation, among other effects). There are a few studies on this exact topic underway was we speak. I'll see if I can get my hands on those tech reports (the only issue is that I'm not sure if they are finished yet). Dave
Attachment:
signature.asc
Description: Digital signature