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

From: Roland Bless <[email-masked]>
Date: Fri, 04 Apr 2008 14:03:51 +0200

Hi Dino,

while reading draft-farinacci-lisp-06 some questions
came up, so here are my comments as hopefully useful
feedback:

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

* Sec. 4.1, number 3:
  "LISP 1...In either case the packet arrives at the ETR."
  I asked myself at which ETR the packet actually arrives
  in case of multi-homing, esp. how would this work for PI-like
  EID prefixes? If I understood the proposal correctly, in LISP 1
  there are entries in the DFZ tables that map the EID prefix
  to ETR RLOCs. So in LISP 1 there would be not much
  reduction in the DFZ tables for these cases?

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

* Sec. 5:
  "it is recommended, in IPv4 that packet do not get
  fragmented..." sure that there is no fragmentation
  by routers in IPv6, but something should be said about
  IPv6 as packets can become too large by tunneling, too.

* Sec. 6.2.:
  The text refers to "client-side" and "server-side"
  which were not introduced before. Wouldn't it be better
  to speak of source site and destination site?

Regards,
 Roland

--
to unsubscribe send a message to [email-masked] 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

---

From: David Meyer <[email-masked]>
Date: Fri, 4 Apr 2008 07:17:10 -0700

Hey Roland,

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

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

	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
	Probe) packet from site A to site B and after the ITR
	(in site A) receives the Map-Reply from the ETR (in site
	B), all traffic for this or any other flow between site
	A and B flows over the the "native" Internet, and not
	over the ALT topology.  

	That said, you could force the ITR to send a Map-Request
	over the LAT rather than sending a Data Probe (we're in
	the process of doing some measurement of the effect of
	this). You could also pre-populate the ITR's cache this
	way if you knew you were going to have popular sites and
	wanted to prime the cache, say with google or something
	like that. Whether pre-populating your cache in this way
	buys you anything is the subject of ongoing experimentation
	and analysis. IMO it doesn't seem like pre-population
	would be too useful, since as soon as the first person
	gets to work (or whatever) and fires up a web browser,
	most (or all) of these sites are going to be populated in
	the ITR' cache, and everyone else at the site will use
	take advantage of the fact that those mappings are
	already available.

>   reduction in the DFZ tables for these cases?

	First, which ETR a packet arrives at (if there is more
	than one) is controlled by the information returned to
	the ITR by the mapping system (or by local config). You
	are also right that in LISP 1 EIDs need to be routable
	"through the RLOC topology for bootstrapping EID-to-RLOC
	mappings." 

	That said, LISP 1, 1.5, 2, 3 were just ways enumerating
	the possibilities with respect to EID-to-RLOC mapping
	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.

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

>   IPv6 as packets can become too large by tunneling, too.

	Noted, thnx.

>   to speak of source site and destination site?

	I see your point. We'll fix it in the next rev.

	Thnx,

	Dave

---

From: Roland Bless <[email-masked]>
Date: Tue, 08 Apr 2008 17:19:40 +0200

Hi Dave,

thanks for your fast response, comments inline...

> 	address field in the outer header.

My point was just that a reader doesn't know these details when
reading the terminology section.

> 	turns up in a wide variety of places (ARP, multicast

Yep.

> 	the Map-Reply. In particular, after the first (Data

Ok, good, probably this point should be emphasized in the next draft
version.

> 	EID-to-RLOC mapping in some database). The current focus

Fine.

> 	DoS case against a cache (distributed scanning attack or

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

---

From: David Meyer <[email-masked]>
Date: Tue, 8 Apr 2008 11:43:46 -0700

> thanks for your fast response, comments inline...

	Any time...

> reading the terminology section.

	Ok, gotcha. We'll fix in the next version

> Ok, good, probably this point should be emphasized in the next draft

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