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

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Feb 2007 21:37:47 +0100

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. 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. Caching  
anywhere else but the source host is a non-starter. ICMP is also  
completely useless because anyone can fake those.

What we need is a design that:

1. Aligns cost with benefit = must be done in provider networks, at  
least at first
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
5. Is less vulnerable to threats than current BGP
6. Supports rerouting after failures = a single global mapping  
database isn't enough

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

The details of the encapsulation are completely uninteresting at this  
stage. I would even go so far as to say that we shouldn't mandate  
any, but rather, allow vendors to implement different ones as  
required and supported by the hardware available.

We should also steer clear of philosophizing about the nature of  
names. We currently have IP addresses. We can't even renumber those  
or move from one version to another within a reasonable timeframe, so  
IP addresses as they are today are a given. Anything that happens  
below IP is very interesting to those that it concerns, but not to  
the architecture of the internet at large since layers below IP have  
no global significance. So, let the vendors or some sub-IP group  
figure this out, it doesn't matter in the grand scheme of things.

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

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 26 Feb 2007 12:45:32 -0800

On Feb 26, 2007, at 12:37 PM, Iljitsch van Beijnum wrote:

> since layers below IP have no global significance. So, let the  
> vendors or some sub-IP group figure this out, it doesn't matter in  
> the grand scheme of things.

I have to disagree with this statement - yes, that's how things work - 
today-, but it's not necessarily how they -have- to work tomorrow.   
Now, it may well be that whatever approaches we believe are valid  
keep this current separation, but I wouldn't suggest taking it off  
the table out of hand, until some sort of consensus on some of the  
grosser points of the desired architecture/paradigm is achieved.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

           The telephone demands complete participation.

                       -- Marshall McLuhan

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Feb 2007 23:51:21 -0800

> across the

Yes, and that could be a feature and not a bug. The solution is not  
revolutionary, it is trying to incrementally get deployed for *both*  
IPv4 and IPv6.

To make that statement requires some hard design decisions to be  
made. Ones that many people won't agree with.

But for one thing, we are listening to the operators, because he they  
say no way off the bat, then the proposal isn't going anywhere.

> DFZ where there is a central mapping database that's distributed  
> through

The database of Locators is not centralized. The locators are IP  
addresses of the various ETRs at destination sites.

> ICMP messages. Please, this has to stop. 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

There are lots of reasons why things didn't work in the past. Would  
you rather pass around all the EID-RLOC mappings around with a  
protocol and have everyone store every possible destination they  
might ever want to talk to?

You have to make this look something like DNS caching for the same  
scalability reasons.

> destination addresses. Caching anywhere else but the source host is  
> a non-starter. ICMP is also completely useless because anyone can  
> fake those.

Anyone can redirect my packets today as well. We will authenticate  
the ICMP packets but that won't be the end-all to security.

We made the choices we did with LISP because we are listening to the  
operators. And you heard them to at the IAB workshop. I assumed you  
were listening carefully.

They need something trivially to deploy and they want it quickly. If  
you want a full fledge solution, then go look at shim6, you know how  
long that is taking to get deployed.

They have said, their multi-homed customers want to control ingress  
traffic. They have said, they themselves want more control of doing  
traffic engineering without polluting the rest of the Internet with  
more specifics. They have said, less routes and stress to the system  
helps the entire routing system and the products they use.

> 1. Aligns cost with benefit = must be done in provider networks, at  

Yes, but the problem on this list is that different people have  
different cost thresholds and want different levels of benefit.

> 2. Enforces renumberability = the locator must be invisible to the  

It doesn't have to be invisible, it can serve your purpose by being  
opaque as well. GSE, in the host treats the RG as opaque, LISP, in  
the host doesn't even know about the inter-domain locator (so it is  
invisible).

> 3. Supports the necessary parallelism that allows scaling to  

Right, this is a motherhood and apple pie statement.

> million different addresses

Right, and your point?

> 5. Is less vulnerable to threats than current BGP

The -01 draft of LISP will have some security mechanisms in place.  
But don't expect much or the operators won't deploy it.

> 6. Supports rerouting after failures = a single global mapping  

The -00 draft talks about Locator reachability. There is a  
conservative solution written down.

> process 1/N of

The solution space will vary depending on how much mapping state  
there will be.

> the global updates. 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 there are some ideas from Compact Routing that we can use. If  
we can use a tunnel topology, with some strict hierarchy that doesn't  
have to change, we can keep the table size down for EID mappings to  
n**2 for 2**n EIDs.

If we use a tunnel topology and have some richness of connectivity  
underneath it (which I think we have in the Internet), there won't be  
reason for tunnel topology changes, so the lookup for a mapping won't  
have to be distributed, you can follow an independent-named tree to  
get you the answer you want to your EID lookup. This will scale much  
better. And I think it could even be static.

For IPv6, you can have the entire EID space come out of a single TLA  
prefix but for IPv4, you may need a collection of class As. But what  
if IANA could allocate 32.0.0.0/3 for EID assignments for the entire  
Internet! That would give us a half of a billion that could be  
assigned to only the hosts that needed global connectivity.

Just a thought.

I know a knee-jerk reaction is to do this in BGP, but if the EID- 
prefix space is too granular, we'll see the EID database just as  
large as the Locator database, and we don't need it to be that large.

> The details of the encapsulation are completely uninteresting at  
> this stage. I would even go so far as to say that we shouldn't  
> mandate any, but rather, allow vendors to implement different ones  
> as required and supported by the hardware available.

This is certainly a detail that we shouldn't screw up but there are  
bigger fish to fry at the moment.

Dino

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 27 Feb 2007 10:36:37 +0200

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: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Feb 2007 11:21:18 +0100

On 2007-02-27 09:36, Pekka Nikander wrote:
> 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.  

I can't speak for HIP, but from early work I've seen on proxying SHIM6,
I'm quite concerned that moving this function out of the host will
recreate some of the evils of NAT (deep packet inspection, transport
checksum munging, and potentially ALGs). The neat thing that host SHIM6
and LISP have in common is that they avoid this, by unambiguously
preserving e2e identifiers.

     Brian

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 27 Feb 2007 11:41:30 +0100

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

> 1. Aligns cost with benefit = must be done in provider networks, at 

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.

> 3. Supports the necessary parallelism that allows scaling to  arbitrary
> numbers

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.

> 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
> 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: Pekka Nikander <[email-masked]>
Date: Tue, 27 Feb 2007 12:52:27 +0200

>> generix draft, I think we can do basically what LISP tried to do  
>> by proxying SHIM6 or HIP.
>

Hmm.  Apparently I haven't seen the work(s) you are referring to, but  
my immediate reaction is to suspect deployment scenarios.  If you  
attempt to proxy full SHIM6 functionality without carefully planning  
the network structure and numbering, I can imagine such things to be  
needed.  However, if you dedicate one of your prefixes as  the only  
prefix the legacy hosts know, the only bigger problem I see is co- 
ordination between parallel SHIM6 proxies sitting at different site  
borders.  And that shouldn't be so hard to solve, either.

For early deployment, we should probably aim for even smaller subset  
of functionality, perhaps not even supporting multi-homing for legacy  
hosts.  Of course, that would foil the very SHIM6 goal for those  
hosts, but OTOH as far as I can see it might provide benefits similar  
to what LISP is designed to provide.

--Pekka Nikander

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 27 Feb 2007 18:53:11 +0800

> implementation problems in the past internet.

No but we might want to keep in mind architectural problems of the  
past Internet.  Knowing the difference between an architectural  
problem and a mere implementation foible is non-trivial in some  
cases, but the sorry history of cache-based routers from multiple  
different vendors is at least suggestive.

"Those who cannot remember the past are condemned to repeat it."  -- 
Santayana

--John

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 Feb 2007 12:42:39 +0100

> made. Ones that many people won't agree with.

Ah, but how do you know that people disagree because the idea is bad  
or disagree because they have it wrong?

> But for one thing, we are listening to the operators, because he  
> they say no way off the bat, then the proposal isn't going anywhere.

I don't think we should only consider ideas that have operator  
support out of the gate. It's the end result that counts.

> addresses of the various ETRs at destination sites.

Ok, centralized is probably not the right word. The difference that I  
was trying to get at is the one between a (distributed) database  
where the information is the same from every vantage point, i.e., the  
DNS or something like it, or a distributed database where the  
information is processed as it flows through the system so certain  
attributes are different depending on where they are observed.  
Routing protocols work like this, the next hop address and path are  
different everywhere.

If we go for a DNS-like system, it's necessary to enrich the static  
information with reachability information. This is what the REAP  
protocol in shim6 does. Protocols like this don't lend themselves  
very well to being implemented in the middle rather than at the  
endpoints, like with shim6.

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

> There are lots of reasons why things didn't work in the past.

I don't see how things are different now.

> Would you rather pass around all the EID-RLOC mappings around with  
> a protocol and have everyone store every possible destination they  

Yes. This has the advantage that it doesn't introduce delays,  
different behavior for different traffic mixes or non-determinism.

> You have to make this look something like DNS caching for the same  

A DNS-like approach only works as long as you're talking to a  
relatively small subset of all possible destinations. I contend that  
this isn't true for most routers in large ISP networks. Maybe they  
don't see packets to 200k different prefixes every hour or every 5  
minutes, but I'm pretty sure it's still a fairly big fraction of all  
possible destinations, such as 50k or so. At these levels, the extra  
overhead of managing the caching defeats the advantage of not having  
to hold a full table, especially on DRAM based systems, because the  
issue with DRAM isn't the cost per size, but the access speed.

But maybe we can split the difference and build a design where there  
are two tiers of mapping devices (or clusters of mapping devices):  
ones that hold the full state, and ones that don't. Then the decision  
about whether to deploy a single tier 1 mapping device, a cluster of  
devices that holds the full mapping state or a tier 2 caching mapping  
device is up to individual operators.

> the ICMP packets but that won't be the end-all to security.

The current interdomain routing security situation isn't exactly the  
best possible one. Authenticating (ICMP) messages from unknown  
sources is a hard thing to do.

> We made the choices we did with LISP because we are listening to  
> the operators. And you heard them to at the IAB workshop. I assumed  
> you were listening carefully.

What I keep hearing is "make the problem go away without us having to  
change any of our current practices"...

> They need something trivially to deploy and they want it quickly.  
> If you want a full fledge solution, then go look at shim6, you know  
> how long that is taking to get deployed.

The internet isn't going to melt down tomorrow or next week. The IETF  
is fundamentally incapable of producing short term results, anyway.  
So if we can't have it really fast (as opposed to "IETF fast") we  
should make sure that at least, it's good. I don't know how long it  
takes for shim6 to be deployed, because it's not finished yet. I do  
know that it takes forever to develop it. There are many reasons for  
this, and an important one that doesn't apply here is that only few  
people are willing to put in the time and even fewer to put in the  
amounts of time that make it progress quickly. But that doesn't apply  
here.

If we can agree on an approach, split off the different parts so that  
different groups can work on the parts concurrently, we should have  
something ready for review this year and all the details hammered out  
and some early implementations next year.

> more specifics. They have said, less routes and stress to the  
> system helps the entire routing system and the products they use.

All of this sounds good to me.

>> 1. Aligns cost with benefit = must be done in provider networks,  
>> at least at first

> different cost thresholds and want different levels of benefit.

Economics is very simple: you buy a new box only if it either makes  
you money or saves you money. For end-users, new boxes don't make or  
save money. For ISPs they can if they're looking at six figures per  
new router with the old ones keeling over. Obviously this means that  
there must be incremental benefits with incremental deployment.

> the host doesn't even know about the inter-domain locator (so it is  

I'll use "invisible" for short here. It's not inconceivable that the  
locator is visible to the end-user with renumberability intact, but  
this requires a *very* strong argument. All previous renumbering  
efforts never went anywhere.

> Right, this is a motherhood and apple pie statement.

I take that to mean "something everyone agrees is good". That's not  
what I mean. The issue with current routing is that all information  
and a lot of packets come together in the same place. This requires  
lots of speed, power and money. The only way to get around that is  
make sure not all information has to come together for all of this to  
work. (In theory we could also reduce the amount of traffic in these  
hot spots, but traffic will continue to increase so even if we're  
successful that means effectively treading water, which doesn't help  
us enough to be useful.)

>> packets to one address works just as well as a million packets to  
>> a million different addresses

> Right, and your point?

Caching only works with a limited number of flows. Since there is no  
inherent limit on the number of flows, we can't depend on caching to  
save us.

> I think there are some ideas from Compact Routing that we can use.  
> If we can use a tunnel topology, with some strict hierarchy that  
> doesn't have to change, we can keep the table size down for EID  
> mappings to n**2 for 2**n EIDs.

Hierarchical tunneling?

Why not simply have hierarchical routing then?

Tunneling is just a mechanism to reduce the number of places where  
routing decisions have to be made. If we can do a hierarchy, then  
it's probably a good tradeoff to route in a few more places and ditch  
the tunnels.

> For IPv6, you can have the entire EID space come out of a single  
> TLA prefix but for IPv4, you may need a collection of class As. But  
> what if IANA could allocate 32.0.0.0/3 for EID assignments for the  
> entire Internet! That would give us a half of a billion that could  
> be assigned to only the hosts that needed global connectivity.

I don't like having separate ID and LOC address spaces. I doubt  
whether this will buy us anything useful, and I prefer having a knob  
that I can turn from "every ID is a LOC" like we have now to  
"complete separation" but also to settings somewhere in between as  
required and desired. For this, IDs must remain able to function as  
LOCs like they can today.

> I know a knee-jerk reaction is to do this in BGP

What I'd like to see is a new protocol that has some similarities to  
BGP, but rather than facilitate hop-by-hop forwarding by distributing  
next hop information, it distributes "last hop" information so that  
packets can be tunneled to a decapsulation box at or just before the  
destination. I don't want to look at real routing at this layer, but  
I do want to be able to dynamically switch from one tunnel to another  
as required by changes in reachability or TE.

> bigger fish to fry at the moment.

Exactly.

---

From: "Darrel Lewis \(darlewis\)" <[email-masked]>
Date: Tue, 27 Feb 2007 10:18:51 -0800

I'll leave most of this to others to comment on, however I feel that
there are a few points below that should be discussed further.  

Iljitsch van Beijnum wrote:
> 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. 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. Caching anywhere
> else but the source host is a non-starter. ICMP is also

I see two (main) fundamental security challenges to be addressed with
LISP.  

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.

-D

*Dave Oran gets credit for his succinct summary of this issue in an
email a couple of months ago.

---

From: <[email-masked]>
Date: Wed, 28 Feb 2007 09:49:44 +0200

Darrel Lewis wrote:
>I see two (main) fundamental security challenges to be 
>addressed with LISP.  
>
>The first, as you mention above, is the ability to 'fake' ICMP 
>request packets.  It is important to note that ICMP isn't the 
...
>
>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 

Aren't you dismissing an obvious third solution, 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?

In the ultimate deployment on first hop routers the CGAs would not even
need to be routable at all. Also, I would argue that rather increasingly
large domains can be made economically feasible with routing on flat
labels, like in rbridges (~ campus wide routing on flat MAC addresses).

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

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

All of this is unnecessary with CGAs. Indeed this is the major benefit
of them :-)

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

We have a solid foundation in understanding CGAs from the work of the
past 8 or so years. I see no reason why they would not be usable also
with LISP.

There are two issues, however:

1. CGAs work only with IPv6. Depending on your viewpoint this may not be
a problem at all. Indeed deploying IPv6 in LISP-style would help scaling
the DFZ routing, as there would be no need to have IPv6 locator routes
in the RIB in the DFZ.

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.

Regards,

	Jarno

---

From: "Darrel Lewis \(darlewis\)" <[email-masked]>
Date: Wed, 28 Feb 2007 10:12:47 -0800

[email-masked] wrote:
<snip>
> 1. CGAs work only with IPv6. Depending on your viewpoint this may not 
> be a problem at all. Indeed deploying IPv6 in LISP-style would help 
> scaling the DFZ routing, as there would be no need to have IPv6 
> locator routes in the RIB in the DFZ.
> 

It was my (unstated) viewpoint that LISP should work with IPv4 - so I
admit that I was not thinking in terms of a v6 only solution.  It
definitely does change your viewpoint to limit the problem space to v6!

I definitely think you have a point with regards to doing source
verification via CGA mechanisms in LISP.  I think further thought should
go into exploring the points that you've raised about its benefits for
authenticating the source of Request packets as well as the mapping of
EID/Loc values.

-D

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Feb 2007 13:12:11 -0800

> support out of the gate. It's the end result that counts.

Are you joking or is this a serious statement? There will be no end  
result without their buy-in.

> different behavior for different traffic mixes or non-determinism.

Tradeoffs.

> relatively small subset of all possible destinations.

For the reason you don't put ITRs (for prepending the locator header)  
in the ISP network. You put it at the source site.

> The current interdomain routing security situation isn't exactly  
> the best possible one. Authenticating (ICMP) messages from unknown  

Yes, you are right.

>> the operators. And you heard them to at the IAB workshop. I  
>> assumed you were listening carefully.
>
> What I keep hearing is "make the problem go away without us having  
> to change any of our current practices"...

Well, yes, that would be the path of least resistance for them. Of  
course, they know you never get a free lunch so it's a negotiating  
dance to see what changes more, practices or the solution space. They  
really want things to work. It's in their best interest.

>> If you want a full fledge solution, then go look at shim6, you  
>> know how long that is taking to get deployed.
>
> The internet isn't going to melt down tomorrow or next week. The  
> IETF is fundamentally

Right, but we have to start development now so we are ready when it  
does. This opportunity is taking a proactive rather than reactive  
approach. If we wait to reactive we will be rushed to do the right  
solution.

> If we can agree on an approach, split off the different parts so  
> that different groups can

The collective "we" will never agree. So this can't be a prerequisite  
for going to the next step.

> work on the parts concurrently, we should have something ready for  
> review this year and all the details hammered out and some early  
> implementations next year.

I think this is actually happening. I personally am interested in  
playing with GSE to see how a different approach can be used but  
still router-based with no host changes. GSE could be just as easy to  
deploy as LISP but serves IPv6 only.

I was wondering if anything thinks GSE could work for IPv4. Comments?  
It will limit the number of connections a host can make globally but  
I want to throw it out and see what folks think?

>> Right, and your point?
>
> Caching only works with a limited number of flows. Since there is  
> no inherent limit on the number of flows, we can't depend on  
> caching to save us.

Hmm. The BGP RIB is a sort of a cache. Anyways, the EID database can  
and must be highly aggregatable and since EID mappings won't change  
like ISP-connection-changes and links and nodes going up an down,  
there will not be entropy in the EID-prefix space.

So I think the EID cache could be considerably smaller and certainly  
so in many places.

>> mappings to n**2 for 2**n EIDs.

Yes, increasing stretch for bootstrapping a EID-to-RLOC mapping may  
be tolerable since it's just a lookup that is following this topology  
and not the real data flow. So a stretch of 3 for this control-plane  
operation is quite acceptable. At least in my mind.

> Why not simply have hierarchical routing then?

You can and we do, but there are too many backdoors at the edges of  
the network the way the Internet is today. The "EID-lookup-topology"  
doesn't need to have these backdoors IMO.

> it's probably a good tradeoff to route in a few more places and  
> ditch the tunnels.

Right.

>> TLA prefix but for IPv4, you may need a collection of class As.  
>> But what if IANA could allocate 32.0.0.0/3 for EID assignments for  
>> the entire Internet! That would give us a half of a billion that  
>> could be assigned to only the hosts that needed global connectivity.
>
> whether this will buy us anything useful, and I prefer having a  
> knob that I can turn from "every ID is a LOC" like we have now to  

I think you just described LISP and didn't realize it.

> What I'd like to see is a new protocol that has some similarities  
> to BGP, but rather than facilitate hop-by-hop forwarding by  
> distributing next hop information, it distributes "last hop"  
> information so that packets can be tunneled to a decapsulation box  
> at or just before the destination. I don't want to look at real  
> routing at this layer, but I do want to be able to dynamically  
> switch from one tunnel to another as required by changes in  
> reachability or TE.

Understand.

>> This is certainly a detail that we shouldn't screw up but there  
>> are bigger fish to fry at the moment.
>
> Exactly.

Then why did you bring up an issue about encapsulation. It detracted  
from your other more important points.

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 28 Feb 2007 22:57:07 +0100

> result without their buy-in.

What I mean is that obviously, the finished solution should have  
operator support. But since most operators aren't protocol designers,  
I don't necessarily trust them as a group to be able to judge a  
solution before it's finished.

> For the reason you don't put ITRs (for prepending the locator  
> header) in the ISP network. You put it at the source site.

Then how do you get end-users to deploy those boxes? We haven't  
exactly been successful in getting them to turn IPv6 on even though  
they got it for free with the hardware they bought for IPv4. (At  
least, a good number of them did.)

The ISPs benefit, this means the ISPs must be the ones that make the  
decision whether to deploy the mechanism. People who don't benefit  
don't deploy.

>> The internet isn't going to melt down tomorrow or next week.

> approach. If we wait to reactive we will be rushed to do the right  

Agree. And we shouldn't be _too_ ambitious or we won't get anything  
done. But if we aren't ambitious enough, we'll only succeed in  
creating something that doesn't really solve much.

> The collective "we" will never agree. So this can't be a  
> prerequisite for going to the next step.

:-)

Well we agreed more than I would have expected in october, so why not  
see if we can agree some more?

> I personally am interested in playing with GSE to see how a  
> different approach can be used but still router-based with no host  
> changes. GSE could be just as easy to deploy as LISP but serves  
> IPv6 only.

Would be nice if someone could fill in the missing pieces to make GSE  
a complete solution, though...

> I was wondering if anything thinks GSE could work for IPv4.  
> Comments? It will limit the number of connections a host can make  
> globally but I want to throw it out and see what folks think?

GSE splits the address into two parts, hard to do with only 32 or  
even 48 (NAT...) bits.

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

So that brings us back to the core of what we were discussing already.

> Hmm. The BGP RIB is a sort of a cache. Anyways, the EID database  
> can and must be highly aggregatable and since EID mappings won't  
> change like ISP-connection-changes and links and nodes going up an  
> down, there will not be entropy in the EID-prefix space.

> So I think the EID cache could be considerably smaller and  
> certainly so in many places.

Aggregation is no magic bullet. What this gives you is the ability to  
have a bunch of routers that handle 0/1 and another bunch of routers  
that handle 128/1 so that each set only needs to know about half the  
internet = the required parallelism. But you still need to have the  
full global information in the aggregate set of routers, so you're  
still dealing with large dynamic tables, the difference is that when  
the tables get _too_ large you can add boxes.

>> required and desired. For this, IDs must remain able to function  
>> as LOCs like they can today.

> I think you just described LISP and didn't realize it.

Could be, the draft isn't the easiest one to decipher...

I'm not saying there is nothing useful in LISP, what I'm saying is  
that it attacks the problem from the wrong end: it's the mapping  
distribution that's the core of the problem, if we figure that out  
everything else will fall into place.

> Then why did you bring up an issue about encapsulation. It  
> detracted from your other more important points.

It seemed like the right thing to say at the time.  :-)

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 28 Feb 2007 23:01:03 +0100

On 28-feb-2007, at 8:49, <[email-masked]>  
<[email-masked]> wrote:

> i.e. the use of

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

> Would be more secure and future proof.

Like HIP, you mean?  :-)

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Feb 2007 17:47:10 -0800

> least, a good number of them did.)

They want ingress packet selection. They want more determinism how  
their packets come into their site.

> Would be nice if someone could fill in the missing pieces to make  
> GSE a complete solution, though...

Right, will come in due time.

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

> Aggregation is no magic bullet. What this gives you is the ability  
> to have a bunch of routers that handle 0/1 and another bunch of  
> routers that handle 128/1 so that each set only needs to know about  
> half the internet = the required parallelism. But you still need to  
> have the full global information in the aggregate set of routers,  
> so you're still dealing with large dynamic tables, the difference  
> is that when the tables get _too_ large you can add boxes.

I am not following at all. But don't bother explaining.

>>> "complete separation" but also to settings somewhere in between  
>>> as required and desired. For this, IDs must remain able to  
>>> function as LOCs like they can today.
>

You are using a cipher that you don't need to use.  ;-)

Dino

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 01 Mar 2007 11:05:53 +0900

Dino Farinacci <[email-masked]> writes:
>>> They need something trivially to deploy and they want it
>>> quickly. If you want a full fledge solution, then go look at shim6,
>>> you  know how long that is taking to get deployed.
>>

Well, what I'm mostly questioning is the IPv4 angle; no matter how you cut
it, the solution that includes IPv4 will be a horrid hack (i.e. effectively
everyone will be NAT'ed) and still not maintain the end-to-end nature of
the traffic (if one of the boxes along the way loses state, or you want
multiple redundant paths, I don't see elegant recovery path just from the
IPv4 traffic). IPv6 'big' prefix EID-space (something like Orchid) at least
would work while actually providing for end-to-end consistent addresses..

These caveats apply at least if the solution implemented with no changes in
endpoints approach that LISP seems to advocate. So why is this desirable
approach? From my point of view, any solution that cannot be really
end-to-end isn't desirable. And that requires globally unique identifiers,
and that requires more bits than IPv4 unfortunately has (assuming you don't
have central identifier repository, which doesn't sound scalable to
me). Assuming both our machines picked 10.0.0.1 'identifier', how will they
talk to each other without NAT again?

Main problem with any non-host-based solution (from my limited
understanding) is that you wind up in NATland whether you're talking IPv4
or IPv6; and you have rather difficult time tying the identifiers to
locators securely.

On the other hand, using something with crypto basis on hosts (CGA, HIP)
you can actually get trusted identifiers.. I've been long-time fan of HIP
due to it actually providing proof of ownership of the identifier you're
communicating with. How does LISP address this? I don't see this angle in
current draft at all. Similar proof of ownership should be needed for also
say, doing DHT of the EIDs (or the ICMP messages for that matter), and
without cryptographic proof of ownership the system would be simply broken.

I'm not saying toss LISP, but I'd rather see version of it that addresses
_all_ of the issues HIP/SHIM6 have played with over the years, and then
call it 'simple', or better yet, 'elegant'.. *grin*

I'd argue that IPv6 deployment is hard because it requires changes to both
hosts and routers in the middle, but endpoints are happily routing around
network damage (NATs, firewalls and other miracles within application
gateways) nowadays and if someone pushed it one level or two down in the host
stack, I couldn't be happier. Having every application do their own
high-availability mobility, security and end-to-end communication hacks
does get old after all.

Microsoft put IPv6+toredo in Vista, I'd have more faith in their next OS
doing the right thing than some router-only solution actually having all
characteristics that at least I want. Disclaimer: My home and office
setups are Microsoft-free, but that's 'the' host OS these days; cellphone
OSes might be getting there sooner or later, but they're seldom outside
walled gardens anyway so I'm not sure if they count.

> I want to throw it out and see what folks think?

I don't think it'd limit number of connections enough, but re-using whole
IPv4 space is not an option, I think, and without that, you have simply too
few bits? 

Cheers,

-Markus

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 1 Mar 2007 10:17:37 +0800

On Mar 1, 2007, at 5:12 AM, Dino Farinacci wrote:
> Hmm. The BGP RIB is a sort of a cache.

Huh?  How do you figure?

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 1 Mar 2007 12:31:46 +0800

>> Hmm. The BGP RIB is a sort of a cache.

Let me rephrase that:  No, it's not.

--John