Change proposal for consistent "skb->pkt_type" after re-injection

Change proposal for consistent "skb->pkt_type" after re-injection

[Christian Riechmann]

Hello,

sometimes ago I came up with a question to this list asking,
whether iptables would allow the following processing:

Iptables filters and queues broadcasted or multicasted
UDP packets for a user space program:

   iptables -t mangle -A PREROUTING -i eth0 -p udp \
	--destination-port 140 -j QUEUE

Such packets are bearing an encapsulated TCP packet, which by the user
space program is decapsulated and re-injected by ipq_set_verdict 
into the normal kernel processing.

The answer was YES.

But when I tested this situation, the TCP-packet were "lost"
and the TCP connection was not installed.

Michael Bussmann <bus@fgan.de> found out that the TCP packet
were not LOST, but they were DISCARDED within the kernel function
tcp_v4_rcv resp. tcp_v6_rcv, each doing an initial test:

	if (skb->pkt_type!=PACKET_HOST)
		goto discard_it;

Apparantly the skb->pkt_type is set very early within one of the
kernel IP routines passed by the broadcasted or multicasted packet
BEFORE iptables gave it to the user space program and the
modified (now TCP packet with a host address) packet is re-injected
into the kernel processing. Unfortunately an update of 
skb->pkt_type does not occur. This leads to the DISCARD of the
TCP packet.

We have the same behaviour within IPv4 and IPv6.

One - bad - solution for this problem could be to delete the above
test within the TCP functions, but this would produce difficulties,
if some people (hacker?) would send IP/TCP packets with multicast or
broadcast addresses.

As a better solution I would propose, that the processing initiated
by ipq_set_verdict should update the packet type (skb->pkt_type)
according to the re-injected packet.
This would lead to a consistent state of the re-injected packet and
the kernel status indicator.

I do not know, whether there exist other status indicators set before
and not updated after the re-injection, but if yes, they should be
updated as well.

Regards

Christian Riechmann
-- 
Christian Riechmann    E-Mail: riechmann@fgan.de
c/o FGAN/FKIE          Tel: (+49) 228/9435 345,378
Neuenahrer Strasse 20  Fax: (+49) 228/9435 685
D-53343 Wachtberg, Germany

Re: Change proposal for consistent "skb->pkt_type" after re-injection

[Henrik Nordstrom]

On Tue, 29 Jun 2004, Christian Riechmann wrote:

> Apparantly the skb->pkt_type is set very early within one of the
> kernel IP routines passed by the broadcasted or multicasted packet
> BEFORE iptables gave it to the user space program and the
> modified (now TCP packet with a host address) packet is re-injected
> into the kernel processing.

Correct, and ip_queue does not have an option to let the userspace return 
a new packet type. But there is other iptables modules allowing you to do 
this kind of thing either before or after the packet is sent to ip_queue.

> One - bad - solution for this problem could be to delete the above
> test within the TCP functions, but this would produce difficulties,
> if some people (hacker?) would send IP/TCP packets with multicast or
> broadcast addresses.

Deleting these tests from TCP would cause serious problems. These tests 
exists there for good reasons.

> As a better solution I would propose, that the processing initiated
> by ipq_set_verdict should update the packet type (skb->pkt_type)
> according to the re-injected packet.

How would it know? The packet type is dictated by how the packet arrived 
to the box, not the IP content.


But honestly I would recommend reinjecting the packets via a TUN device.  
This way a whole can of problems is avioded with very little complexity. I
would even get the encapsulated packets out of the kernel via the same TUN
device and just use iptables to have them routed there but that it me.

Regards
Henrik

Re: Change proposal for consistent "skb->pkt_type" after re-injection

[Christian Riechmann]

HenriK,

thanks for your reply. Some comments inline...

On 2004-06-30 12:43:50 +0200, Henrik Nordstrom wrote:
> On Tue, 29 Jun 2004, Christian Riechmann wrote:
> 
> > Apparantly the skb->pkt_type is set very early within one of the
> > kernel IP routines passed by the broadcasted or multicasted packet
> > BEFORE iptables gave it to the user space program and the
> > modified (now TCP packet with a host address) packet is re-injected
> > into the kernel processing.
> 
> Correct, and ip_queue does not have an option to let the userspace return 
> a new packet type. But there is other iptables modules allowing you to do 
> this kind of thing either before or after the packet is sent to ip_queue.

Maybe you can give me a pointer which are these modules.

> 
> > One - bad - solution for this problem could be to delete the above
> > test within the TCP functions, but this would produce difficulties,
> > if some people (hacker?) would send IP/TCP packets with multicast or
> > broadcast addresses.
> 
> Deleting these tests from TCP would cause serious problems. These tests 
> exists there for good reasons.

This is exactly what I meant with "bad" solution.

> 
> > As a better solution I would propose, that the processing initiated
> > by ipq_set_verdict should update the packet type (skb->pkt_type)
> > according to the re-injected packet.
> 
> How would it know? The packet type is dictated by how the packet arrived 
> to the box, not the IP content.

You are right, but if it is possible to re-inject another-type-packet, then
the skp->pkt_type should be updated FOR CONSISTENCY. The decision can
easily be done in the same way as it is done, when the packet enters the box:
By testing the address type of th re-injected packet, which by definition
is an IP packet.

> 
> 
> But honestly I would recommend reinjecting the packets via a TUN device.  
> This way a whole can of problems is avioded with very little complexity. I
> would even get the encapsulated packets out of the kernel via the same TUN
> device and just use iptables to have them routed there but that it me.

My understanding of TUN is that it offers only 1_to_1 and not 1_to_n
connections which I do need (IP/TCP packets have to be encapsulated within
UDP packets, which are broadcasted to the neighbor hosts). That is why I
did not yet overtake this proposal you made some weeks ago.

Regards
Christian
-- 
Christian Riechmann    E-Mail: riechmann@fgan.de
c/o FGAN/FKIE          Tel: (+49) 228/9435 345,378
Neuenahrer Strasse 20  Fax: (+49) 228/9435 685
D-53343 Wachtberg, Germany

Re: Change proposal for consistent "skb->pkt_type" after re-injection

[Henrik Nordstrom]

On Wed, 30 Jun 2004, Christian Riechmann wrote:

> > Correct, and ip_queue does not have an option to let the userspace return 
> > a new packet type. But there is other iptables modules allowing you to do 
> > this kind of thing either before or after the packet is sent to ip_queue.
> 
> Maybe you can give me a pointer which are these modules.

Looking... seems I remember wrongly. Can't find any.

> My understanding of TUN is that it offers only 1_to_1 and not 1_to_n
> connections which I do need (IP/TCP packets have to be encapsulated within
> UDP packets, which are broadcasted to the neighbor hosts). That is why I
> did not yet overtake this proposal you made some weeks ago.

This is incorrect. TUN offers a virtual network device at either the IP or 
Ethernet layers, giving userspace full control to inject packets at these 
layers as if they were coming from a real network device and also the 
ability to read packets as if they were sent to a real network device. 

Yes, intercepting broadcasts via a TUN device is a little tricky but if
you make a bridge with the real network device then this is also fully
doable. The TUN device obviously needs to be in TAP mode (Ethernet) for 
bridgeing to work.

The initial target application for TUN was simple userspace tunnelling of
networks, but it is by no means limited to this functionality. TUN is a
network device where the transmission layer is implemented by userspace
instead of wires. In all other aspects it is and behaves like any other
network device.

What you route/forward to a TUN device gets delivered to the userspace
application, and what the userspace application writes to the TUN device
gets processed/forwarded by the kernel. In TAP mode the packet type is 
controlled by the Ethernet address type in the exact same manner as on a 
real Ethernet device, in TUN mode only PACKET_HOST injection is possible 
(direct link to the IP layer).

Regards
Henrik

Re: Change proposal for consistent "skb->pkt_type" after re-injection

[Christian Riechmann]

Henrik,

thanks for your detailed information about TUN. As you pointed out,
the usage of TUN to solve my problem is not so quite easy as it seems
to me when using iptables and ip6tables. But we will look at your
proposal to find out, whether it would lead to a simpler and more suitable
implementation.

Nevertheless,
as iptables/ip6tables do not forbid and/or do not refuse to re-inject
an address-modified (multicast/broadcast to unicast address) packet,
IMHO, it is good programming method to guarantee the CONSISTENCY
between the preset indicator (e.g. skb->pkt_type) and the address
within the re-injected packet.

The other way to guarantee consistency would be, that a re-injection
of such packets are refused. This would need some additional tests as well.

Therefore,
why not a patch which resets skb->pkt_type according to the address of
the re-injected packet?

Best Regards

Christian


On 2004-06-30 21:53:11 +0200, Henrik Nordstrom wrote:
> On Wed, 30 Jun 2004, Christian Riechmann wrote:
> 
> > > Correct, and ip_queue does not have an option to let the userspace return 
> > > a new packet type. But there is other iptables modules allowing you to do 
> > > this kind of thing either before or after the packet is sent to ip_queue.
> > 
> > Maybe you can give me a pointer which are these modules.
> 
> Looking... seems I remember wrongly. Can't find any.
> 
> > My understanding of TUN is that it offers only 1_to_1 and not 1_to_n
> > connections which I do need (IP/TCP packets have to be encapsulated within
> > UDP packets, which are broadcasted to the neighbor hosts). That is why I
> > did not yet overtake this proposal you made some weeks ago.
> 
> This is incorrect. TUN offers a virtual network device at either the IP or 
> Ethernet layers, giving userspace full control to inject packets at these 
> layers as if they were coming from a real network device and also the 
> ability to read packets as if they were sent to a real network device. 
> 
> Yes, intercepting broadcasts via a TUN device is a little tricky but if
> you make a bridge with the real network device then this is also fully
> doable. The TUN device obviously needs to be in TAP mode (Ethernet) for 
> bridgeing to work.
> 
> The initial target application for TUN was simple userspace tunnelling of
> networks, but it is by no means limited to this functionality. TUN is a
> network device where the transmission layer is implemented by userspace
> instead of wires. In all other aspects it is and behaves like any other
> network device.
> 
> What you route/forward to a TUN device gets delivered to the userspace
> application, and what the userspace application writes to the TUN device
> gets processed/forwarded by the kernel. In TAP mode the packet type is 
> controlled by the Ethernet address type in the exact same manner as on a 
> real Ethernet device, in TUN mode only PACKET_HOST injection is possible 
> (direct link to the IP layer).
> 
> Regards
> Henrik
> 
> 

-- 
Christian Riechmann    E-Mail: riechmann@fgan.de
c/o FGAN/FKIE          Tel: (+49) 228/9435 345,378
Neuenahrer Strasse 20  Fax: (+49) 228/9435 685
D-53343 Wachtberg, Germany

Re: Change proposal for consistent "skb->pkt_type" after re-injection

[Henrik Nordstrom]

On Mon, 5 Jul 2004, Christian Riechmann wrote:

> Therefore,
> why not a patch which resets skb->pkt_type according to the address of
> the re-injected packet?

Because pkt_type is not about the address of the packet, it is about how
the packet arrived to the box. pkt_type is link level, not IP level. You
can not deduce pkt_type from the IP level as the needed information is not
there.

What you can maybe do if you really want to do this kind of packet
modifications via QUEUE is to extend ip_queue to also allow modification
of pkt_type, not only payload. But I strongly advice you to reinject the
packets via a TUN device rather than modifying them "inline", and would
also recommend intercepting the packets via a TUN device but you may use
QUEUE for this if somehow more suitable for your solution (just remember
to return NF_DROP verdict to stop the original packet). But be warned that
you will still need to consider the effects on conntrack from you stealing
the packet mid-flight if you ever consider using conntrack on the same
system, but with the packets being broadcasts conntrack should not be much 
of an issue I think..

Thinking about the interception.. why do you even need to intercept? Can't
you simply accept the packets? I don't remember exactly what kind of
encapsulation you are using other than that the transport packets is
broadcasted.. but if the transport protocol is something understandable 
then just having a socket accepting these packets should be sufficient to 
have them delivered to your userspace application with considerably less 
complexity than using ip_queue.

Regards
Henrik