Sending complete IPv6 packets without bypassing netfilter/IPsec

Sending complete IPv6 packets without bypassing netfilter/IPsec

[jpo234]

Hello all,
the IPv4 socket interface had the nifty IP_HDRINCL option. It seems 
that an IPv6 version of this option is not available. The proposed 
solution for this seems to be to use libpcap to inject the packet. 
Unfortunately this completely bypasses both, netfilter and IPsec. So, 
am I lost or is there a way to do what I want/need?

Thanks in advance
   Joerg

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[Herbert Xu]

jpo234@netscape.net wrote:
> the IPv4 socket interface had the nifty IP_HDRINCL option. It seems 
> that an IPv6 version of this option is not available. The proposed 
> solution for this seems to be to use libpcap to inject the packet. 
> Unfortunately this completely bypasses both, netfilter and IPsec. So, 
> am I lost or is there a way to do what I want/need?

	socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)

should have the same effect as IP_HDRINCL.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[jpo234]

Herbert,
thanks for taking the time to answer. I thought about this, but was 
discouraged by the following passage in RFC 3542:

   Most IPv4 implementations give special treatment to a raw socket
   created with a third argument to socket() of IPPROTO_RAW, whose value
   is normally 255, to have it mean that the application will send down
   complete packets including the IPv4 header.  (Note: This feature was
   added to IPv4 in 1988 by Van Jacobson to support traceroute, allowing
   a complete IP header to be passed by the application, before the
   IP_HDRINCL socket option was added.)  We note that IPPROTO_RAW has no
   special meaning to an IPv6 raw socket (and the IANA currently
   reserves the value of 255 when used as a next-header field).

So, if you write "should have the same effect as IP_HDRINCL" does this 
mean "this is the way we designed it in Linux, so it should work" or 
"give it a try, I think it might work". The first one would make me try 
harder than the second one. If it does in fact work, than this should 
be documented more prominently somewhere. I did a long and IMHO 
thorough Google search and found no mention of this.

Thanks and kind reagrds
  Joerg

-----Original Message-----
From: Herbert Xu <herbert@gondor.apana.org.au>
To: jpo234@netscape.net
Cc: netdev@vger.kernel.org
Sent: Fri, 16 Jan 2009 12:54 am
Subject: Re: Sending complete IPv6 packets without bypassing 
netfilter/IPsec

jpo234@netscape.net wrote:
> the IPv4 socket interface had the nifty IP_HDRINCL option. It seems
> that an IPv6 version of this option is not available. The proposed
> solution for this seems to be to use libpcap to inject the packet.
> Unfortunately this completely bypasses both, netfilter and IPsec. So,
> am I lost or is there a way to do what I want/need?

    socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)

should have the same effect as IP_HDRINCL.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[Herbert Xu]

jpo234@netscape.net wrote:
>
> So, if you write "should have the same effect as IP_HDRINCL" does this 
> mean "this is the way we designed it in Linux, so it should work" or 

It's designed this way in Linux.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[jpo234]

Herbert,
once again thanks for your help! It works fine now.

Kind regards
  Joerg


-----Original Message-----
From: Herbert Xu <herbert@gondor.apana.org.au>
To: jpo234@netscape.net
Cc: netdev@vger.kernel.org
Sent: Fri, 16 Jan 2009 7:48 am
Subject: Re: Sending complete IPv6 packets without bypassing 
netfilter/IPsec

jpo234@netscape.net wrote:
>
> So, if you write "should have the same effect as IP_HDRINCL" does 
this
> mean "this is the way we designed it in Linux, so it should work" or

It's designed this way in Linux.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[jpo234]

Herbert,
sorry for bothering you (and everybody else on the list) again. It 
seems that the stack does not replace a "::" source address with a real 
one when using a PF_INET6/SOCK_RAW/IPPROTO_RAW socket the way it does 
with an IP_HDRINCL IPv4 socket for "0.0.0.0". Do I have to fill this 
one myself or is there another trick to achieve this?

Thanks and kind regards
  Joerg

-----Original Message-----
From: Herbert Xu <herbert@gondor.apana.org.au>
To: jpo234@netscape.net
Cc: netdev@vger.kernel.org
Sent: Fri, 16 Jan 2009 7:48 am
Subject: Re: Sending complete IPv6 packets without bypassing 
netfilter/IPsec

jpo234@netscape.net wrote:
>
> So, if you write "should have the same effect as IP_HDRINCL" does 
this
> mean "this is the way we designed it in Linux, so it should work" or

It's designed this way in Linux.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[Rémi Denis-Courmont]

On Friday 16 January 2009 12:46:30 ext jpo234@netscape.net, you wrote:
> Herbert,
> sorry for bothering you (and everybody else on the list) again. It
> seems that the stack does not replace a "::" source address with a real
> one when using a PF_INET6/SOCK_RAW/IPPROTO_RAW socket the way it does
> with an IP_HDRINCL IPv4 socket for "0.0.0.0". Do I have to fill this
> one myself

Yes. That's the _whole_ point of writing the header yourself.

> or is there another trick to achieve this?

Use transport-layer raw sockets and let the kernel do the network header.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[jpo234]

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. 
This means I can't make assumptions about the protocol value. Using 
transport-layer raw sockets would mean that I had to open a new socket 
for every packet I'm forwarding (yeah, I would cache them). This was 
the way I had decided upon before Herbert's hint, but I think you 
understand why I'd rather not go this way.

Regards
  Joerg

-----Original Message-----
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
To: ext jpo234@netscape.net <jpo234@netscape.net>
Cc: herbert@gondor.apana.org.au; netdev@vger.kernel.org
Sent: Fri, 16 Jan 2009 11:56 am
Subject: Re: Sending complete IPv6 packets without bypassing 
netfilter/IPsec

On Friday 16 January 2009 12:46:30 ext jpo234@netscape.net, you wrote:
> Herbert,
> sorry for bothering you (and everybody else on the list) again. It
> seems that the stack does not replace a "::" source address with a 
real
> one when using a PF_INET6/SOCK_RAW/IPPROTO_RAW socket the way it does
> with an IP_HDRINCL IPv4 socket for "0.0.0.0". Do I have to fill this
> one myself

Yes. That's the _whole_ point of writing the header yourself.

> or is there another trick to achieve this?

Use transport-layer raw sockets and let the kernel do the network 
header.

--
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[Andi Kleen]

jpo234@netscape.net writes:

> Hello all,
> the IPv4 socket interface had the nifty IP_HDRINCL option. It seems
> that an IPv6 version of this option is not available. The proposed
> solution for this seems to be to use libpcap to inject the
> packet. Unfortunately this completely bypasses both, netfilter and
> IPsec. So, am I lost or is there a way to do what I want/need?

The theory is (the same on IPv4) is that the socket options should
allow you to specify everything legal you could put into a IPv6 header
by hand. 

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[jpo234]

Andi,
I read the rationale in RFC 3542. Unfortunately this makes the 
following assumptions:
1) You know the IP protocol value when you open the socket. This is not 
true in my case because I get packets from a tun device.
2) Packet injection using packet sockets/libpcap provides the same 
functionality. Bad luck that this completely bypasses IPsec and 
netfilter.

To overcome 1) I would have to strip off the IPv6 header and then have 
a separate socket for every next-header value I might encounter. Not 
very appealing.

I know I'm partial right now, but at least the suggestion in the RFC 
that "some other technique, such as the datalink interfaces BPF or 
DLPI, must be used" is misguided.

Regards
  Joerg


-----Original Message-----
From: Andi Kleen <andi@firstfloor.org>
To: jpo234@netscape.net
Cc: netdev@vger.kernel.org
Sent: Fri, 16 Jan 2009 1:18 pm
Subject: Re: Sending complete IPv6 packets without bypassing 
netfilter/IPsec

jpo234@netscape.net writes:

> Hello all,
> the IPv4 socket interface had the nifty IP_HDRINCL option. It seems
> that an IPv6 version of this option is not available. The proposed
> solution for this seems to be to use libpcap to inject the
> packet. Unfortunately this completely bypasses both, netfilter and
> IPsec. So, am I lost or is there a way to do what I want/need?

The theory is (the same on IPv4) is that the socket options should
allow you to specify everything legal you could put into a IPv6 header
by hand.

-Andi

--
ak@linux.intel.com -- Speaking for myself only.

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[Rémi Denis-Courmont]

On Friday 16 January 2009 13:12:40 ext jpo234@netscape.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.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

Re: Sending complete IPv6 packets without bypassing netfilter/IPsec

[jpo234]

> -----Original Message-----
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
> To: ext jpo234@netscape.net <jpo234@netscape.net>
> Cc: netdev@vger.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@netscape.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