IPv6: optionaly validate RAs on raw sockets
Subsystems (2)
PATCH 1/1 IPv6: optionaly validate RAs on raw sockets
ICMPv6 Router Advertisements may now contain informations that is mostly of interest to userland. This currently mostly consists of recursive DNS server addresses (though one should expect other stuff to come).
This patch adds a setsockopt to ICMPv6 sockets to only deliver Router Advertisements if they pass the same set of checks as the kernel IPv6 autoconfiguration does, so that userland can parse attributes it is interested safely (otherwise, it would get and parse advertisements that the kernel rejected).
N.B.: not too sure about the option name though...
include/linux/icmpv6.h +1 -0
@@ -139,6 +139,7 @@ static inline struct icmp6hdr *icmp6_hdr(const struct sk_buff *skb)*/ #define ICMPV6_FILTER 1 +#define ICMPV6_VALID_ADVERT 2/* * ICMPV6 filter
include/linux/ipv6.h +3 -1
@@ -343,7 +343,9 @@ struct ipv6_pinfo {struct raw6_sock {/* inet_sock has to be the first member of raw6_sock */ struct inet_sock inet; -__u32 checksum;/* perform checksum */ +__u16 unused; +__u8 valid_advert;/* deliver valid RAs only */ +__u8 checksum;/* perform checksum */ __u32 offset;/* checksum offset */ struct icmp6_filter filter;/* ipv6_pinfo has to be the last member of raw6_sock, see inet6_sk_generic */
net/ipv6/raw.c +60 -11
110 lines not on this page · raw message
Signature · 2 lines
Rémi Denis-Courmont http://www.remlab.net/
In article <[email protected]> (at Tue, 10 Jul 2007 21:11:17 +0300), Remi Denis-Courmont <[email protected]> says:
Quoted 4 lines
ICMPv6 Router Advertisements may now contain informations that is mostly of interest to userland. This currently mostly consists of recursive DNS server addresses (though one should expect other stuff to come).
I really do not want to have such non-standard API in kernel.
--yoshfuji
Quoted 1 line · On Wednesday 11 July 2007 15:29:16 YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article <[email protected]> (at Tue, 10 Jul 2007
21:11:17 +0300), Remi Denis-Courmont <[email protected]> says:
Quoted 6 lines
Quoted 4 lines
ICMPv6 Router Advertisements may now contain informations that is mostly of interest to userland. This currently mostly consists of recursive DNS server addresses (though one should expect other stuff to come).
I really do not want to have such non-standard API in kernel.
I can only think of a very limited set of ways to extract options from RAs that the kernel currently ignores:
1) parse everything in kernel addrconf.c
2) validate RA in kernel, parse userland options in userland
3) parse everything in userland
4) do not support any option of interest to userland ever
5) userland and kernel do their own cooking separately
netdev folks already rejected (1) earlier. You just rejected (2) this instant.
(3) implies removing addrconf from the kernel completely, which does not sound good, besides being a big waste. (4) means Linux is unusable on IPv6 networks. And it's already been pointed out (5) was not safe/secure (userland may end up accepting something when it should not).
I might be missing something because I am a notoriously arrogant moron but it looks like Linux IPv6 is in a dead-end for the time being :-(
What do you propose then?
Signature · 1 line
Rémi Denis-Courmont
I think #2 in your list is the right choice, and that has nothing to do with adding a
non-standard option (which I completely agree is a bad idea).
It looked like you're just checking if the machine is acting as a router or not and
if it comes from a link-local address; is that right? Of course, lots of apps already
check for "am I a router" and they don't require a new socket option. (!) See everything
in the quagga package, for example. And checking the address type in a app is
trivial.
The previous discussion about "validation" was talking about RA's that are forged,
so don't pass IPsec authentication checks. I don't see any reason at all to deliver those
to an application (ever), so no non-standard socket option required there. I don't know
if those are currently delivered on raw sockets or not, but if they are, I think it's
reasonable to have a patch that clones them only after authentication rather than before.
Prior discussion used FUD about some monitoring apps needing to see forged RA's.
I don't think there really are apps that need to see forged RA's, but if they really
want everything, they should use bpf or the like, just as they would need to do to
receive, for example, packets with invalid checksums.
+-DLS
Quoted 7 lines · Rémi Denis-Courmont
Quoted 1 line · On Wednesday 11 July 2007 15:29:16 YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article <[email protected]> (at Tue, 10 Jul 2007
21:11:17 +0300), Remi Denis-Courmont <[email protected]> says:
Quoted 4 lines
Quoted 4 lines
ICMPv6 Router Advertisements may now contain informations that is mostly of interest to userland. This currently mostly consists of recursive DNS server addresses (though one should expect other stuff to come).
Quoted 7 lines
Quoted 1 line
I really do not want to have such non-standard API in kernel.
I can only think of a very limited set of ways to extract options from RAs that the kernel currently ignores:
1) parse everything in kernel
addrconf.c
2) validate RA in kernel, parse userland options in userland
Yes, #2 is the right option. However, I agree that passing such info with non-standard socket option is not ideal.
Since you asked for another idea, how about using netlink to send _validated_ RA information to interested parties?
-vlad
Quoted 1 line
Since you asked for another idea, how about using netlink to send
_validated_ RA
Quoted 3 lines
information to interested parties?
-vlad
That sounds like a good idea to me (FWIW),
though I also still think a simple raw-socket application would do it just fine, possibly with no kernel modification at all.
But since the kernel wouldn't be maintaining
the DNS info, which was my real objection to the original version, netlink would work well too.
+-DLS
Quoted 7 lines · David Stevens
That sounds like a good idea to me (FWIW),
though I also still think a simple raw-socket application would do it just fine, possibly with no kernel modification at all.
But since the kernel wouldn't be maintaining
the DNS info, which was my real objection to the original version, netlink would work well too.
One remaining corner case is NFS/IPv6 root, whereby userland won't have a chance to start before the network, and hence may miss the solicited RA. Or would it? By default, the next unsolicited RA can be anytime from now to after 10 minutes, so that's not sufficient. I wouldn't personnaly care, but...
Signature · 2 lines
Rémi Denis-Courmont http://www.remlab.net/
Quoted 9 lines · Rémi Denis-Courmont
Quoted 7 lines · David Stevens
That sounds like a good idea to me (FWIW),
though I also still think a simple raw-socket application would do it just fine, possibly with no kernel modification at all.
But since the kernel wouldn't be maintaining
the DNS info, which was my real objection to the original version, netlink would work well too.
Quoted 6 lines
One remaining corner case is NFS/IPv6 root, whereby userland won't have a chance to start before the network, and hence may miss the solicited RA. Or would it? By default, the next unsolicited RA can be anytime from now to after 10 minutes, so that's not sufficient. I wouldn't personnaly care, but...
You've got the same issue with the socket option approach.
-vlad
David Miller
maintainerFrom: Rémi_Denis-Courmont <[email protected]>
Date: Wed, 11 Jul 2007 19:19:11 +0300
Quoted 9 lines · David Stevens
Quoted 7 lines
That sounds like a good idea to me (FWIW),
though I also still think a simple raw-socket application would do it just fine, possibly with no kernel modification at all.
But since the kernel wouldn't be maintaining
the DNS info, which was my real objection to the original version, netlink would work well too.
Quoted 5 lines
One remaining corner case is NFS/IPv6 root, whereby userland won't have a chance to start before the network, and hence may miss the solicited RA. Or would it? By default, the next unsolicited RA can be anytime from now to after 10 minutes, so that's not sufficient. I wouldn't personnaly care, but...
We already have cases like that with network device firmware that has to be loaded in from the filesystem in userspace, and the answer is to use a properly populated initrd.
Same goes for things like this.
That's the fact of life these days, like it or not.
Quoted 6 lines · David Miller
Quoted 5 lines
One remaining corner case is NFS/IPv6 root, whereby userland won't have a chance to start before the network, and hence may miss the solicited RA. Or would it? By default, the next unsolicited RA can be anytime from now to after 10 minutes, so that's not sufficient. I wouldn't personnaly care, but...
Quoted 7 lines
We already have cases like that with network device firmware that has to be loaded in from the filesystem in userspace, and the answer is to use a properly populated initrd.
Same goes for things like this.
That's the fact of life these days, like it or not.
Same story for NFS root when using strong authentication -- something has to be running in userland to manage that.
- James
Signature · 2 lines
James Morris <[email protected]>