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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4BEDC1DD.6070807@trash.net>
Date:	Fri, 14 May 2010 23:34:21 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Alex Lorca <alex.lorca@...il.com>
CC:	netdev <netdev@...r.kernel.org>,
	Johannes Berg <johannes@...solutions.net>
Subject: Re: Implementation of the LISP protocol (GSOC 2010)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ