[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Some comments on draft-farinacci-lisp-06



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