netdev - Re: [patch] ipv6.7: IPV6_ROUTER

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

Date:	Tue, 16 Oct 2007 21:15:50 +0100
From:	Andrew McDonald <andrew@...onald.org.uk>
To:	Pekka Savola <pekkas@...core.fi>
Cc:	netdev@...r.kernel.org
Subject: Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

On Mon, Oct 15, 2007 at 08:51:16AM +0300, Pekka Savola wrote:
> Took off linux-man from cc:,
> 
> On Sun, 14 Oct 2007, Andrew McDonald wrote:
> >+The tapped packets are not forwarded by the kernel, it is the
> >+user's responsibility to send them out again.
> 
> This is probably incompliant (and from users' perspective, 
> unacceptible) behaviour that IMHO should be fixed.

I disagree. This is basically the behaviour you want.

It might be an improvement to that sentence to simply say: "The tapped
packets are not forwarded by the kernel." The second half of the
sentence possibly suggests that you always want to forward the packet
after router alert processing.

For why you don't want to packets to be forwarded, consider a simple
example that applies to something like RSVP:
- packet hits router, identified as potentially interesting from router
alert option
- packet passed to user space, confirmed as really interesting and
processed
- create new packet (based on the one that came in and the RSVP
processing you've done) and send it out

You don't want the original packet you received to be forwarded, only
your new packet.

There is the possible case that you decide that you aren't interested
in the packet once it has reached userspace, in which case the user
will need to forward it themself. I can imagine ways of improving this
(e.g. LSF/BPF filters that run before deciding not to forward the
packet to reduce the likelihood of intercepting 'uninteresting'
packets), but they would not completely remove this situation.

-- 
Andrew McDonald
E-mail: andrew@...onald.org.uk
http://www.mcdonald.org.uk/andrew/
-
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