netdev - Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

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-prev] [day] [month] [year] [list]

Message-Id: <8CB4601836E6983-2F30-1123@webmail-stg-d07.sysops.aol.com>
Date:	Fri, 16 Jan 2009 09:54:49 -0500
From:	jpo234@...scape.net
To:	remi.denis-courmont@...ia.com, netdev@...r.kernel.org
Subject: Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

> -----Original Message-----
> From: Rémi Denis-Courmont <remi.denis-courmont@...ia.com>
> To: ext jpo234@...scape.net <jpo234@...scape.net>
> Cc: netdev@...r.kernel.org
> Sent: Fri, 16 Jan 2009 3:09 pm
> Subject: Re: Sending complete IPv6 packets without bypassing 
netfilter/IPsec
> On Friday 16 January 2009 13:12:40 ext jpo234@...scape.net, you wrote:
> > Rémi,
> > sorry, but a transport-layer raw socket is something I'd like to 
avoid.
> > The reason is, that I get the ready made packets from a tun device.
>
> Then you have the source address from the packet read from the TUN 
device.

But in my case this is a meaningless address that must not be visible 
to the outside world.

Maybe I should really go into details here. Please be patient, this is 
going to be a lengthy mail.

What I'm trying to do is to send IPsec encrypted OLSR messages. OLSR 
messages as generated by the OLSR routing daemon are directed to the 
IPv4 broadcast address or the all hosts multicast address for IPv6. For 
reasons that I won't explain in detail here I'm stuck with 
255.255.255.255 and FE01::1.

One OLSR daemon can sent messages to multiple interfaces, all of them 
with the same destination address (e.g. the multicast/broadcast 
address). IPsec tunnels are identified by a tuple {protocol,spi,dest 
addr}. Protocol (ESP) and SPI are fixed and the destination address is 
the same. Bugger. This means I can't specify different IPsec tunne
l 
associations for different interfaces, because they would only differ 
in the source address which is not part of the tuple.

The scheme I came up with is the following:

I have a daemon that opens a tun device. This tun device has a local 
address, say 1.2.3.254/24 (for readability I'm using IPv4). Then I'm 
specifying IPsec SAs:

Tunnel1: 1.2.3.254->1.2.3.ifidx1 SPI KEY;
Tunnel2: 1.2.3.254->1.2.3.ifidx2 SPI KEY;

ifidx1 and ifidx2 are the interface indices of the two network 
interfaces that the OLSR daemon uses. Than I can add IPsec policies:

192.168.10.1->255.255.255.255 shall use Tunnel1
192.168.11.1->255.255.255.255 shall use Tunnel2

192.168.10.1 is the IP address of the first interface, 192.168.11.1 the 
address of the second interface.

IPsec dutifully encrypts the packets and then the routing code stuffs 
them into the above mentioned tun device. The encrypted packets have 
the following addresses:
for encrypted OLSR packets for interface 1: src 1.2.3.254 dst 
1.2.3.ifidx1
for encrypted OLSR packets for interface 2: src 1.2.3.254 dst 
1.2.3.ifidx2

Inside my daemon I simply extract the interface index from the 
destination address, put another one (broadcast/multicast) in its place 
and send the packet out over their original destination interface. OLSR 
requires that the packets have the correct source address, though. IPv4 
is easy: just use 0.0.0.0 as source address and the stack will fill in 
the right one. Works f
ine here. Unfortunately this does not work for 
IPv6, hence my question.

Thanks for your time and kind regards
   Joerg
--
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