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

[Roland Bless <bless@tm.uka.de>]

Hi Dave,

thanks for your fast response, comments inline...

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.

> 	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.

> 	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?

Regards,
 Roland

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg