Implementation of the LISP protocol (GSOC 2010)

Implementation of the LISP protocol (GSOC 2010)

[Alex Lorca]

Hi

My name is Alex Lorca and I'm working in the implementation of LISP
[0] in Linux for the Google Summer of Code 2010 program, so I'll be
bothering the list with silly questions for the next months. Any
feedback is much appreciated.

Basically, LISP is somewhat of a tunneling protocol that creates
tunnels on demand between routers called Ingress Tunnel Router (ITR)
and Egress Tunnel Router (ETR). ITRs encapsulate normal traffic
appending a special header and send it to ETRs where it gets
decapsulated. The purpose of this is to forward packets from hosts
behind then ITR to hosts behind the ETR because they can't reach
each other directly using their public IPs (more info in [0]). The
encapsulation is done like this:

 IP | UDP | LISP | IP | ...

The idea is to implement something like ipip or ip_gre: a virtual
interface that takes care of the LISP packets, creating and
maintaining tunnels, decapsulating/encapsulating and forwarding
packets. This includes also the userspace tools for administration.
Ideally, for the implementation to be useful, the process has to have
as lowest latency as possible since almost all the traffic directed to
the LISP interface is to be forwarded.

I've come across the first problem: since the IP protocol number field
in the LISP packets is UDP (17) I can't send the packet to a layer 4
handler function via the registered protocols table. The only thing
that comes to my mind is just replace the l4 handler for UDP (udp_rcv)
in the protocol table. Is there a cleaner way to do this?

Also, is there others tunnel like implementations in linux, aside from
ipip, gre and sit?


Regards


[0] http://www.lisp4.net/

-- 
Alex Lorca

Re: Implementation of the LISP protocol (GSOC 2010)

[Patrick McHardy]

Alex Lorca wrote:
> Hi
> 
> My name is Alex Lorca and I'm working in the implementation of LISP
> [0] in Linux for the Google Summer of Code 2010 program, so I'll be
> bothering the list with silly questions for the next months. Any
> feedback is much appreciated.
> 
> Basically, LISP is somewhat of a tunneling protocol that creates
> tunnels on demand between routers called Ingress Tunnel Router (ITR)
> and Egress Tunnel Router (ETR). ITRs encapsulate normal traffic
> appending a special header and send it to ETRs where it gets
> decapsulated. The purpose of this is to forward packets from hosts
> behind then ITR to hosts behind the ETR because they can't reach
> each other directly using their public IPs (more info in [0]). The
> encapsulation is done like this:
> 
>  IP | UDP | LISP | IP | ...
> 
> The idea is to implement something like ipip or ip_gre: a virtual
> interface that takes care of the LISP packets, creating and
> maintaining tunnels, decapsulating/encapsulating and forwarding
> packets. This includes also the userspace tools for administration.
> Ideally, for the implementation to be useful, the process has to have
> as lowest latency as possible since almost all the traffic directed to
> the LISP interface is to be forwarded.
> 
> I've come across the first problem: since the IP protocol number field
> in the LISP packets is UDP (17) I can't send the packet to a layer 4
> handler function via the registered protocols table. The only thing
> that comes to my mind is just replace the l4 handler for UDP (udp_rcv)
> in the protocol table. Is there a cleaner way to do this?

You can use an encapsulation socket - check out udp_queue_rcv_skb().

> Also, is there others tunnel like implementations in linux, aside from
> ipip, gre and sit?

L2TP.