netdev - Implementation of the LISP protocol (GSOC 2010)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 May 2010 17:26:16 -0400
From:	Alex Lorca <alex.lorca@...il.com>
To:	netdev <netdev@...r.kernel.org>
Cc:	Johannes Berg <johannes@...solutions.net>
Subject: Implementation of the LISP protocol (GSOC 2010)

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html