Subject: RE: [RAM] Can we forget LISP, please?

From: <[email-masked]>
Date: Thu, 1 Mar 2007 13:04:50 +0200

Iljitsch van Beijnum wrote:
><[email-masked]> wrote:
>
>> i.e. the use of
>> cryptographically bound identities as IDs? It seems to me that LISP 
>> would work rather well with CGAs as in SHIM6?
>
>But wouldn't that require changes to hosts? And if you accept 
>that, why not simply adopt shim6 itself, with or without some 
>modifications? (It's not like it's finished just yet.)
>

I think Pekka and Kristian nailed this down pretty well in the PASH
draft earlier today :-)

>> 2. Current practice allows only for ~64 crypto-bits in a 
>CGA. It would 
>> be better to carve out a portion of the IPv6 address space for e.g. 
>> /28 prefixes (for EID resolution aggregation) and ~100 bits for 
>> crypto.
>> Would be more secure and future proof.
>
>Like HIP, you mean?  :-)
>

This aspect also discussed in the PASH draft, it seems.

Regards,

	Jarno

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Eliot Lear <[email-masked]>
Date: Thu, 01 Mar 2007 12:07:57 +0100

Oh please.
>>
>>> Hmm. The BGP RIB is a sort of a cache.
>>
>> Huh?  How do you figure?
>
> Let me rephrase that:  No, it's not.

A cache is merely a temporary store.  So how about responding to the 
meat of Dino's proposal rather than being pedantic?

---

From: Ross Callon <[email-masked]>
Date: Thu, 01 Mar 2007 10:27:26 -0500

At 12:07 PM 3/1/2007 +0100, Eliot Lear wrote:
>A cache is merely a temporary store.  So how about responding to the meat 
>of Dino's proposal rather than being pedantic?

My understanding of a cache is that it is a temporary store
of **PART** of the database, and not all of the database. My
interpretation of John's comment is that he is concerned about
the partial nature of the cache, and not the temporary nature of
the cache.

 From Wikipedia:
     "Caches have proven to be extremely effective in many areas
     of computing because access patterns in typical computer
     applications have locality of reference."

Others may be able to comment better than I on the experience
with cache based routers. My impression is that these are okay
very close to the edge of small networks, but have experienced
significant problems in core service providers.

Ross

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 1 Mar 2007 11:01:23 -0500

On Feb 28, 2007, at 8:47 PM, Dino Farinacci wrote:

>> You can of course always find more address bits by adding extra  
>> tunnel headers, which also helps with keeping the whole thing more  
>> backward compatible. This could actually work, but then we're back  
>> at how to find outer tunnel addresses (LOCs) to go along with  
>> inner tunnel addresses (IDs).
>
> Yep.

Exactly.

Regardless of whether we use an IP-in-IP tunnel approach, or an IP-in- 
LISP approach, or any other tiered routing approach, we have the same  
mapping problem.  Given a non-local, non-globally-routable end-point  
identifier, how do we find a globally routable locator so that we can  
get our packets there?

Without a mapping mechanism that meets application requirements and  
scales better than current IP routing, we're just
moving the problem around.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 1 Mar 2007 10:59:12 -0500

Exactly.

Margaret

---

From: Tony Li <[email-masked]>
Date: Thu, 1 Mar 2007 14:18:01 -0800

> significant problems in core service providers.

I'll vouch for this, if folks are still doubtful.  In one experiment  
that we did, the "working set" for the forwarding cache worked out to  
be 85% of the RIB.  At that point, why bother?

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Mar 2007 17:06:16 -0800

> Aren't you dismissing an obvious third solution, i.e. the use of

Okay, I need a precise explanation here for me to get any value out  
of this email. Saying "LISP would work well with CGAs as in SHIM6"  
could mean so many things. So please enlighten me.

>> The second major challenge that I see in LISP is the case
>> where a source spoofs the ID of a third party and sends a
>> packet from a reachable/valid locator.  The ETR needs a
>> mechanism to validate the ITR/Locator mapping.
>
> This is trivial with CGAs.

Again, explain.

Dino

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 2 Mar 2007 09:40:20 +0800

On Mar 1, 2007, at 11:27 PM, Ross Callon wrote:
> My interpretation of John's comment is that he is concerned about  

That's as good a summary as any, and I'll also associate myself with  
Tony's later comment.

The corollary is that *if* the LISP encapsulator/decapsulator could  
be guaranteed to be far enough out on the edge of the network that  
the working set could reasonably be expected to be small, then this  
concern would diminish.  (Though I'm not sure that helps for high- 
fanout hosts, e.g. some kinds of server farms.)

--John

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Mar 2007 00:13:42 -0500

Not sure I agree but do support continued work with SHIM6 but HIP is not
going to fly is my view but maybe move all energy to SHIM6 and take what
can be taken from HIP.  As far as tossing LISP I don't see that on this
list at all on the contrary my read is signficant interest and support
to keep going.

/jim 

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 3:37 AM
> To: Dino Farinacci; Iljitsch van Beijnum
> Cc: [email-masked]
> Subject: Re: [RAM] Can we forget LISP, please?
> 
> Firstly, as I have stated earlier, and tried to outline in 
> the generix draft, I think we can do basically what LISP 
> tried to do by proxying SHIM6 or HIP.  That should lead to 
> roughly equal deployment speed.  The system might not be as 
> "simple" as what LISP appears to be, but not necessarily that 
> complex either.
> 
> Secondly, what I've heard from multiple sources is that 
> people don't agree on the necessity of getting this out 
> "quickly".  Yes, there is a looming problem, but people seem 
> to disagree how many years we have time still.  Apparently at 
> least a couple of years, though.
> 
> So, my take on this is that we shouldn't just forget LISP.  
> IMHO, there are a few good ideas there.  However, I still 
> believe that we should aim for a more "proper" ID/loc split 
> than what LISP at its current state can provide.  IMHO, that 
> would bring forth multiple benefits in the form of really 
> upgrading the architecture in the slightly longer run, such 
> as proper support for all kinds middle boxes (and not just 
> TRs), ability to better integrated IPv4 and IPv6 (something 
> which HIP provides today), optimised support for mobile 
> routers, combined support for host mobility and multi-homing 
> (HIP does that) and site multi-homing and TE (an open issue, 
> see Elwyn Davie's very good mail on the arch-d list), etc.
> 
> We should not commit ourselves to any single proposal at this time.   
> Instead, we should try to understand the strengths and 
> drawbacks of the different proposals, aiming for something 
> more comprehensive (but of course not try to boil the oceans).
> 
> It would be a mistake to focus only on the routing table problem.   
> Given the current looming crisis, we have a great opportunity 
> to finally upgrade the architecture by adding a proper new 
> name space, something that Saltzer called for already in 1982.
> 
> --Pekka Nikander
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Mar 2007 00:18:42 -0500

When we get to LISP 3 DHTs are a good idea Planet Labs has been using
them for some time.  Much better than DNS for edge routers.  But as
others have said devil is in the details.  In addition I can see how
LISP DHTs can help with pre-congestion notification as a note when
designed.

http://www.planet-lab.org/

/jim

> From: Olivier Bonaventure [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 5:42 AM
> To: Iljitsch van Beijnum
> Cc: [email-masked]
> Iljitsch,
> > It looks to me that lisp is nothing more than tunneling packets  
> > across the DFZ where there is a central mapping database that's  
> > distributed through ICMP messages. Please, this has to stop.
> 
> I disagree, LISP has the potential of bringing additional 
> benefits and is worth being considered.
> 
> > Three  years ago, 40%
> > of the internet melted because routers couldn't keep  up 
> with filling 
> > their forwarding caches from a LOCALLY AVAILABLE  mapping database 
> > when a worm hit that made hosts send out 15000  packets per second 
> > with random destination addresses.
> 
> We should not based architectural decisions for the future 
> internet on implementation problems in the past internet.
> 
> > Caching  anywhere else but the source host is a 
> non-starter. ICMP is 
> > also  completely useless because anyone can fake those.
> 
> ICMP looks to me like an interim solution, let's consider 
> also lisp 1.5, LISP2, ...
> 
> > What we need is a design that:
> > 
> > 1. Aligns cost with benefit = must be done in provider networks, at 
> > least at first
> 
> LISP-like solutions could also provide benefits for the 
> customer networks. For example LISP can allow a stub AS to 
> control its incoming and outgoing traffic, which can be a 
> strong incentive for stub ASes to request from their 
> providers the deployment of LISP-like solutions.
> 
> > 2. Enforces renumberability = the locator must be invisible to the 
> > end-user 3. Supports the necessary parallelism that allows 
> scaling to  
> > arbitrary numbers 4. Doesn't depend on a particular type of 
> traffic, 
> > i.e., a million packets to one address works just as well 
> as a million 
> > packets to a million different addresses
> 
> The type of traffic to support will be an engineering 
> decision. For me, it would seem reasonable to optimise a 
> platform to better support a million packets sent to one 
> address than a million packets to a million different 
> addresses, especially at the edge. At the edge, there are few 
> real applications needing to send packets to millions of destinations.
> 
> > 5. Is less vulnerable to threats than current BGP 6. Supports 
> > rerouting after failures = a single global mapping  database isn't 
> > enough
> 
> The rerouting after failure is orthogonal for me. To achieve 
> fast recovery after failures, local solutions are better than 
> global solutions because they react faster and do not require 
> a full routing convergence. In fact, tunnels can also be used 
> to provide fast failover of BGP peering links in case of 
> failures, see:
> http://www.info.ucl.ac.be/people/OBO/papers/f41-bonaventure.pdf
> 
> > The way I see it, this means that we must come up with a protocol  
> > that floods mapping state throughout the network but in a way that  
> > allows N devices to each hold 1/N part of the full global 
> state and  
> > process 1/N of the global updates.
> 
> You basically propose to use a DHT to distribute the mapping, 
> this is one of the possible implementations of the mapping.
> 
> > This protocol needs good security  and quick reaction to outages, 
> > which are things that current BGP  doesn't do adequately. But since 
> > there are no users yet, we get to do  a greenfield design 
> so it should 
> > be doable.
> 
> I think that greenfield design could be an objective for version 2.
> 
> 
> 
> Olivier
> 
> --
> CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Mar 2007 00:32:32 -0500

ITR and ETR are very close to the edges.  I don't see how large or small
networks affects the cache for parsing with current technology?  did you
mean the AS domains within the site or network path for small or large?
 
/jim

________________________________

	From: Ross Callon [mailto:[email-masked]] 
	Sent: Thursday, March 01, 2007 10:27 AM
	To: Eliot Lear; John G. Scudder
	Cc: [email-masked]
	Subject: Re: [RAM] Can we forget LISP, please?

		Oh please.

				Huh?  How do you figure?

		A cache is merely a temporary store.  So how about
responding to the meat of Dino's proposal rather than being pedantic?

	From Wikipedia:

	Ross

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Mar 2007 00:38:51 -0500

I don't agree with the way you say it. A positive view is LISP provides
another level of indirection, which is entirely OK to identify short
term network computer science solutions.  LISP moved the locator
distribution to the edge and this is a good design center to alleviate a
segment of the problems identified within the RAM processes, and I think
will not cause to much additional operator management overhead or cost.
I am not concerned about tunneling.  Everyone designing most additions
at any IP Reference Model layer are using tunnels it is life, we will
deal with it as IT vendors, it will perform, and scale. The security
ramifications I believe will be resolved though I am absolutely against
use of CGA but not going there for now we have far more important
discussions before we go off on that thread, at least for me.

/jim

> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Thursday, March 01, 2007 11:01 AM
> To: Dino Farinacci
> Cc: [email-masked]
> >> backward compatible. This could actually work, but then 
> we're back at 
> >> how to find outer tunnel addresses (LOCs) to go along with inner 
> >> tunnel addresses (IDs).
> >
> > Yep.
> 
> Exactly.
> 
> Regardless of whether we use an IP-in-IP tunnel approach, or 
> an IP-in- LISP approach, or any other tiered routing 
> approach, we have the same mapping problem.  Given a 
> non-local, non-globally-routable end-point identifier, how do 
> we find a globally routable locator so that we can get our 
> packets there?
> 
> Without a mapping mechanism that meets application 
> requirements and scales better than current IP routing, we're 
> just moving the problem around.
> 
> Margaret
> 
> 
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 2 Mar 2007 08:24:29 +0100

Hi Dino,

El 02/03/2007, a las 2:06, Dino Farinacci escribió:

> Okay, I need a precise explanation here for me to get any value out of 
> this email. Saying "LISP would work well with CGAs as in SHIM6" could 
> mean so many things. So please enlighten me.
>

Darrel identified two main security aspects that he described as:

> The first, as you mention above, is the ability to 'fake' ICMP request
> packets.  It is important to note that ICMP isn't the problem, LISP
> could have picked a new IP protocol number and packet, used UDP, or any
> number of things, but the problem would remain.  When a new mapping
> request packet arrives at the ETR, the ETR cannot just process this
> packet without some way to validate that this packet came from the
> source in the source address field.  Rate limiting these packets is not
> a solution due to the inability to classify good from bad by just
> looking at the initial packet.

> There are two ways to solve this problem today* (maybe more...?), one 
> is
> a multi-packet exchange that uses nonce values and return routability 
> to
> verify the source.  TCP syn-cookies is an example of this type of
> approach.  The second is some sort of proof of identity using
> symmetrical keying.  Both of these approaches can be implemented in the
> dataplane, which will be a requirement to avoid the DoS.
>
>
> The second major challenge that I see in LISP is the case where a 
> source
> spoofs the ID of a third party and sends a packet from a 
> reachable/valid
> locator.  The ETR needs a mechanism to validate the ITR/Locator 
> mapping.
> (Today this is done with return routability, which makes it very
> difficult to fake establishment of TCP connections without being a MITM
> attack, or L2 spoofing).  Some sort of cert based ID/Loc mapping
> database needs to exist for the ETR to be able to use to verify that 
> the
> source ID/Loc is valid.
>
> There may be many other security issues out there, but if we can solve
> these two and not break LISP, IMHO we'll have a good foundation to work
> on.

As i see it, both are about validating the source of the packet, 
wwhether the source locator or the source identifier
In order to validate that the source address contained in the source 
address field of the packet, you could use CGAs as the source address.
since CGA are derived from a public key, containing some form of 
signature inside the packet itself generated with the associated 
private key would prove that the actual owner of the source address did 
generated the packet.

i can go further into details if you are itnerested, but this is the 
main idea i think

Regards, marcelo

hope this helps

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Mar 2007 10:00:10 -0500

Other options for LISP are deep packet inspection being deployed today on the market by very capable vendors, likewise Intrusion Detection/Prevention products.
/jim 

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 2:24 AM
> To: Dino Farinacci
> Cc: [email-masked]
> > could have picked a new IP protocol number and packet, used UDP, or 
> > any number of things, but the problem would remain.  When a new 
> > mapping request packet arrives at the ETR, the ETR cannot 
> just process 
> > this packet without some way to validate that this packet came from 
> > the source in the source address field.  Rate limiting 
> these packets 
> > is not a solution due to the inability to classify good from bad by 
> > just looking at the initial packet.
> 
> > is a multi-packet exchange that uses nonce values and return 
> > routability to verify the source.  TCP syn-cookies is an example of 
> > this type of approach.  The second is some sort of proof of 
> identity 
> > using symmetrical keying.  Both of these approaches can be 
> implemented 
> > in the dataplane, which will be a requirement to avoid the DoS.
> >
> >
> > source spoofs the ID of a third party and sends a packet from a 
> > reachable/valid locator.  The ETR needs a mechanism to validate the 
> > ITR/Locator mapping.
> > difficult to fake establishment of TCP connections without being a 
> > MITM attack, or L2 spoofing).  Some sort of cert based 
> ID/Loc mapping 
> > the source ID/Loc is valid.
> >
> > these two and not break LISP, IMHO we'll have a good foundation to 
> > work on.
> 
> As i see it, both are about validating the source of the 
> packet, wwhether the source locator or the source identifier 
> In order to validate that the source address contained in the 
> source address field of the packet, you could use CGAs as the 
> source address.
> since CGA are derived from a public key, containing some form 
> of signature inside the packet itself generated with the 
> associated private key would prove that the actual owner of 
> the source address did generated the packet.
> 
> i can go further into details if you are itnerested, but this 
> is the main idea i think
> 
> Regards, marcelo
> 
> 
> hope this helps
> 
> >>> source spoofs the ID of a third party and sends a packet from a 
> >>> reachable/valid locator.  The ETR needs a mechanism to 
> validate the 
> >>> ITR/Locator mapping.
> >>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Mar 2007 16:11:59 -0800

> private key would prove that the actual owner of the source address  
> did generated the packet.

Why not pass the public key in the message payload and have the  
source sign with the private key. Then it can work for any addresses  
you decide to use, plus IPv4.

Alternately, you could send the public key in another packet, less  
often (only when you might want to rekey), and keep the state with  
the EID-RLOC mapping.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 3 Mar 2007 11:57:39 +0100

El 03/03/2007, a las 1:11, Dino Farinacci escribió:

> Why not pass the public key in the message payload and have the source 
> sign with the private key. Then it can work for any addresses you 
> decide to use, plus IPv4.
>

the problem with this is that there is no way to bind the identifier 
itself (which is what you want to protect) and the public/private key 
pair. So anyone could send such a message, including its own key pair.
In order to prevent this, you need to protect the binding between the 
identifier and the key pair.

One option is using certificates, but this would rely on having a 
common trusted anchor point which for a general environment like the 
one we are cosnidering here, would mean a global pki

the other option is to have the identifier intrinsically bound to the 
key pair, which is what CGA does, since the iid of the CGAis a hash of 
the public key

> often (only when you might want to rekey), and keep the state with the 
> EID-RLOC mapping.
>

Yes, the public key is send only in the first message when you send the 
identifier for the first time (included in what is called the CGA 
parameter data strucutre) and the rest of the additional locators that 
may need to send only include the signature, (using the associated key 
pair)

regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 13 Mar 2007 18:15:18 -0700

Today I finally got the chance to sit down and look at the LISP
and eFIT proposals. What the LISP proposal is calling "LISP 2"
(and possibly also "LISP 3") is basically the same thing as the
IPvLX proposal, which has been around for a few years. LISP 1
and LISP 1.5 use an interesting mechanism for locator/identifer
mapping, but they do seem to require that identifiers be routable
across a global topology rather than just within the local site
which could (perhaps) limit their applicability to near-term only.

IPvLX on the other hand separates the user address space from the
provider address space by using a mapping service that is separate
from the global routing infrastructure, as suggested by eFIT. But
also, IPvLX is just the core proposal of a suite of inter-related
proposals (see: http://ipvlx.org) that provide building blocks for
the future Internet vision such as articulated by eFIT.

I could talk more about the other proposals if anyone is interested
(which I think they should be, because they apply equally well to
LISP and eFIT as they do to IPvLX). But, I'll stop here for now
because I don't pretend to have all the answers; only an inkling
of a few pieces to the puzzle. I am of course open to comments and
questions on IPvLX and its relation to LISP and eFIT also.

Thanks - Fred
[email-masked]