Subject: [RAM] Pre-draft: mapper protocol

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 4 Mar 2007 17:49:16 +0100

Hi,

Since draft submission is now closed but I want to get this out  
before the IETF meeting, I decided to write a short "pre-draft". No  
boilerplate or much in the way of formatting yet. You can find it at  
http://www.muada.com/drafts/draft-van-beijnum-mapper-00.txt

Or just keep reading:

                           A mapping protocol
                     draft-van-beijnum-mapper-00.txt

Introduction

This document describes protocol that distributes mapping information.
The protocol takes a namespace with no explicit hierarchy and allows
data to be attached to any name in the namespace, providing the ability
to query for the data attached to a given name, and be automatically
informed of subsequent changes to this data.

The purpose of this protocol is to distribute the location of
decapsulation devices that are capable of receiving encapsulated IP
packets, decapsulate them and deliver them to the holder of the
destination IP address without the need for a prefix covering this IP
address to be present in the BGP default-free zone.

General overview

The idea is that users of IP address space are connected to one or more
ISPs (the examples will use two) in the following fashion:

          ISP A --- ISP B
        /       \ /       \
User 1          X          User 2
        \       / \       /
          ISP C --- ISP D

where each ISP operates a network with routers that have one (sometimes
more) of three functions:

1. Edge router: this type of router connects to customers
2. Border router: this type of router connects to other ISPs
3. Core router: these provide connectivity between edge and border  
routers

Edge routers don't necessarily need a copy of the full default-free BGP
routing table; they can forward packets according to a default route if
need be. Also, in most cases, they don't need to be extremely fast
because the majority of customers connects at modest speeds.

Border routers don't need a copy of the full default-free table either;
they only need routes for the destinations connected to the external
networks they interface with. Border routers may need to be fast because
a lot of traffic is exchanged between ISPs.

Core routers need a full BGP table and they need to be fast: all the
routing information and all the traffic comes together in these routers.

The idea is to implement encapsulation and decapsulation devices close
to the edge routers, where traffic volumes are relatively modest.
Certain IP address prefixes are then no longer carried in BGP in the
core or border routers. Rather, packets with these destinations are
forwarded to an encapsulation device, which encapsulates the packets in
some fashion and sends the packets on their way as per the encapsulating
protocol and/or the address in the encapsulating header. The examples
will assume IP-in-IP encapsulation, but other types are possible as
well, such as direct / on demand fiber paths or MPLS. When the packets
arrive at the decapsulation device close to the destination, they're
decapsulated and forwarded to the destination using the destination IP
address in the original IP packet. The routers between the
encapsulation device and the decapsulation device now no longer need
to have the IP address prefixes in question in their tables.

The mapping protocol makes sure that encapsulation devices know which
decapsulation devices serve a particular IP destination.

Mapping protocol overview

In addition to decapsulation devices that generate mapping information,
and encapsulation devices that use mapping information, there are also
authoritative mapping servers. The idea is that parts of the
name/address space are served by a small number of authoritative
servers. Decapsulation devices register their mappings with these
servers, and encapsulation devices query the authoritative servers. A
final type of mapping servers are the ones that only consolidate, cache
and redistribute mapping information.

Mapping information distributed in the protocol consists of:

1. Source: an AS number, a router identifier and a timestamp
2. Mapping data: for IP-in-IP, this would be the tunnel destination
    address
3. Refer to: a set of addresses that may be contacted for more detailed
    information
4. Source preference: traffic engineering information from the source

This information is put into packets along with an indentifier, which is
the IP prefix that the mapping information applies to. On its way from
the decapsulation device to the authoritative server, the data is
accompanied by an HMAC so the authoritative server knows the mapping
data is authorized by the legitimate holder of the address space. A
shared secret is communicated out of band. Additional security
mechanisms may be defined at a later date.

Authoritative and non-authoritative mapping servers consolidate sets of
mapping data pertaining to the same identifier into a single message.
This is possible because only mapping data with the same source AS and
routing ID overwrites an earlier message. The timestamp is used to
suppress duplicate messages. Mapping servers may also attach local
preference information to aid traffic engineering.

Operation

In order to advertise mapping information, a decapsulation device must
set up and maintain a TCP session towards one or more authoritative
servers, possibly aided by intermediate non-authoritative servers.

Encapsulation devices may either set up and maintain sessions towards
authoritative servers (in practice probably to non-authoritative
caching/redistributing servers). As long as the session remains, the
encapsulating device may receive updates for the information it
requested earlier. Alternatively, they can do a single lookup and then
connect directly towards one or more decapsulation devices to learn
reachability information directly, and/or request information that is
more granular that what the mapping/flooding system can accommodate. An
example of this would be host mobility.

Discussion: for just PI without multihoming, it's enough to do a single
lookup for mapping info, as this information isn't going to change.
However, for multihoming, it's essential to be informed of changes very
quickly: with only caching, the encapsulation device could be sending to
a dead decapsulation device. An alternative approach would be to always
cache, and let a decapsulation device reach back to the encapsulation
device when the decapsulation device is no longer capable of delivering
packets to a certain destination. With IP-in-IP this is easily done
through the tunnel source address. However, this trades off reliability
of the packet delivery against scalability of the mapper service.

Note that both encapsulation and decapsulation devices can be
implemented inside ISP networks or in end-user networks, or even in
hosts.

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Mar 2007 17:56:16 -0800

> boilerplate or much in the way of formatting yet. You can find it  
> at http://www.muada.com/drafts/draft-van-beijnum-mapper-00.txt

So, Iljitsch, you basically reinvented LISP here with one difference.  
The difference is that there is a third-party involved in doing the  
mapping service versus the decapsulation device telling the  
encapsulation device directly.

I did assume from your draft that you won't have routable-IDs. So if  
this is true, what does the encapsulation device do with packets when  
it doesn't have the mapping? That is, it gets a packet for which it  
does not have an EID-to-RLOC mapping, so it makes the request to the  
server over a TCP connection. While the encapsulation device is  
waiting for the reply, is it dropping packets on the floor?

This is why we have LISP 1 and 1.5, we don't want to drop packets. So  
if you want mapping on-demand, you have to route the EID. If you  
don't want to route the EID and you don't want to drop packets, you  
either have to push the mappings everywhere or you intercept packets  
the host uses to setup connections (like DNS-snooping). Tough choices.

The best part of your proposal is that you can authenticate the  
mappings. But once you buy into a third-party you can have all sorts  
of security tools at your disposal.

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 Mar 2007 12:55:31 +0100

On 8-mrt-2007, at 2:56, Dino Farinacci wrote:

>> before the IETF meeting, I decided to write a short "pre-draft".  
>> No boilerplate or much in the way of formatting yet. You can find  
>> it at http://www.muada.com/drafts/draft-van-beijnum-mapper-00.txt

> So, Iljitsch, you basically reinvented LISP here with one difference.

The difference is the mapping service. This is important.

> encapsulation device directly.

Yes, this is a bit like the TLD system in the DNS (although there is  
no equivalent of the root servers) which helps parallelism because  
you know where to find authoritative information for a specific part  
of the identifier space.

> I did assume from your draft that you won't have routable-IDs. So  
> if this is true, what does the encapsulation device do with packets  
> when it doesn't have the mapping?

Identifiers are just PI prefixes, so what happens is the same thing  
that happens today if the destination isn't in the routing tables:  
packet is dropped with a !N.

The idea is that every prefix is either in the regular BGP table like  
today, or it is in the mapping system. This can be a local decision,  
i.e., an AS can decide to run this system locally, encapsulating  
packets with the 90% destination prefixes that attract 10% of the  
traffic right at the edge, and decapsulating them again next to the  
border to the next hop AS. That way, the core routers don't need to  
carry a full table but no cooperation with external ASes is required.

> That is, it gets a packet for which it does not have an EID-to-RLOC  
> mapping, so it makes the request to the server over a TCP  
> connection. While the encapsulation device is waiting for the  
> reply, is it dropping packets on the floor?

Right. Originally, I wanted to make a flooding-only system, but I  
think having the option to work on-demand can be useful in certain  
cases, although then you have this problem. The case where it can be  
useful is if both the ISP and the source end-user have encapsulation  
devices, so at the source it's possible to dump the packets at the  
ISP and they're delivered, but if they obtain the mapping info they  
can do all of this themselves and make smarter traffic engineering  
decisions etc. The ISP would have the mapping state flooded to its  
encapsulation devices, while the end-user would work on-demand.

> mappings. But once you buy into a third-party you can have all  
> sorts of security tools at your disposal.

:-)

Iljitsch

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 9 Mar 2007 12:06:18 -0800

> The idea is that every prefix is either in the regular BGP table  
> like today, or it is in the mapping system. This can be a local  
> decision, i.e., an AS can decide to run this system locally,  
> encapsulating packets with the 90% destination prefixes that  
> attract 10% of the traffic right at the edge, and decapsulating  
> them again next to the border to the next hop AS. That way, the  
> core routers don't need to carry a full table but no cooperation  
> with external ASes is required.

This is what we defined in LISP as re-encapsulating versus recursive  
tunneling.

>> That is, it gets a packet for which it does not have an EID-to- 
>> RLOC mapping, so it makes the request to the server over a TCP  
> think having the

Don't you think dropping packets is a non-starter? Or are you saying  
the expense of dropping packets is for the benefit of using non- 
routable PI IDs?

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 Mar 2007 19:11:26 +0100

> Don't you think dropping packets is a non-starter? Or are you  
> saying the expense of dropping packets is for the benefit of using  
> non-routable PI IDs?

I don't envision any real-world use cases where packets would be  
dropped, even though it's certainly possible that someone could  
create one, just like with existing IP the idea is to make a best  
effort to deliver the packets but if you misconfigure a few or even a  
lot of dropped packets are possible.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 11 Mar 2007 11:21:45 -0700

> effort to deliver the packets but if you misconfigure a few or even  
> a lot of dropped packets are possible.

Are you saying that there will always be a mapping available at the  
encapsulating router?

Can you answer my question directly. I will repeat it:

What happens when a packet comes to an encapsulating router and there  
is no mapping for the ID? What happens to the packet?

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 Mar 2007 19:30:58 +0100

On 11-mrt-2007, at 19:21, Dino Farinacci wrote:

>> effort to deliver the packets but if you misconfigure a few or  
>> even a lot of dropped packets are possible.

> Are you saying that there will always be a mapping available at the  

When do engineers ever use the word "always"?

> What happens when a packet comes to an encapsulating router and  
> there is no mapping for the ID? What happens to the packet?

The exact same thing that happens when any packet enters any router  
that doesn't have a route for the packet's destination: it gets dropped.

Why would that be worthy of having an email exchange over?

You should only run the encap/mapping service in on-demand mode when  
there are either regular routers or another encap/mapping service  
further upstream that can handle the packets that are generated  
before there is a mapping in the on-demand encapsulation device.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2007 16:00:34 +0100

I think we should up-level and consider the generic options for
distributing mapping information, that are hinted at
in draft-wang-ietf-efit-00.txt. Actually I think there are more
options than covered there, but that is the first discussion IMHO
(since it seems obvious that mapping is needed in some shape
or form).

     Brian