[RFC][PATCH] Export DNSSL RA option to userspace

[RFC][PATCH] Export DNSSL RA option to userspace

[Pierre Ossman]

[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]

RFC 6106 specifies a new RA option for DNS resolver configuration that
therefore needs to end up in userspace.

This first patch just exports the new option, but I started thinking
that this seems overly complex that the kernel needs to be updated
every time there is something new of interest to userspace in the RA.
So I also have a second patch that exports everything that the kernel
doesn't want.

Patches only compile tested so far as I'm still hacking away at
userspace. Comments very much welcome though.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-ipv6-export-DNS-search-list-option-to-userspace.patch --]
[-- Type: text/x-patch, Size: 1544 bytes --]

From a5b60e80eeed87763c811ecfb0d7aa5695d0a2bf Mon Sep 17 00:00:00 2001
From: Pierre Ossman <pierre@ossman.eu>
Date: Sun, 12 Dec 2010 00:06:48 +0100
Subject: [PATCH 1/2] ipv6: export DNS search list option to userspace

Like DNS resolver addresses, the suffixes to be used in DNS lookups need
to be configured by userspace. Make sure userspace has access to the
option containing that information.

Signed-off-by: Pierre Ossman <pierre@ossman.eu>
---
 include/net/ndisc.h |    3 ++-
 net/ipv6/ndisc.c    |    8 +++++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index 895997b..9c8698a 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -33,7 +33,8 @@ enum {
 	ND_OPT_MTU = 5,			/* RFC2461 */
 	__ND_OPT_ARRAY_MAX,
 	ND_OPT_ROUTE_INFO = 24,		/* RFC4191 */
-	ND_OPT_RDNSS = 25,		/* RFC5006 */
+	ND_OPT_RDNSS = 25,		/* RFC5006 / RFC6106 */
+	ND_OPT_DNSSL = 31,		/* RFC6106 */
 	__ND_OPT_MAX
 };
 
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 58841c4..c5b01e3 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -233,7 +233,13 @@ static struct nd_opt_hdr *ndisc_next_option(struct nd_opt_hdr *cur,
 
 static inline int ndisc_is_useropt(struct nd_opt_hdr *opt)
 {
-	return (opt->nd_opt_type == ND_OPT_RDNSS);
+	switch (opt->nd_opt_type) {
+	case ND_OPT_RDNSS:
+	case ND_OPT_DNSSL:
+		return 1;
+	default:
+		return 0;
+	}
 }
 
 static struct nd_opt_hdr *ndisc_next_useropt(struct nd_opt_hdr *cur,
-- 
1.7.2.3


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

[RFC][PATCH] Export all RA options that we don't handle to userspace

[Pierre Ossman]

[-- Attachment #1.1: Type: text/plain, Size: 897 bytes --]

Second patch that exports everything. If noone objects to this model,
then merge the two patches and just use the commit message from the
second one.

Pros:
- Kernel doesn't need to be updated for every new RA option that might
  show up.

Cons:
- Possible security issue if it requires less privilege to read these
  netlink messages than to open a raw ICMPv6 socket.
- List of types the kernel is interested in is now in two places in the
  code, creating a risk for getting out of sync. I tried to come up
  with a structure that would prevent this, but couldn't think of
  anything that wouldn't require large changes. Ideas welcome...

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0002-ipv6-give-userspace-all-RA-options-that-we-do-not-ca.patch --]
[-- Type: text/x-patch, Size: 2561 bytes --]

From 00cdbb6f65ad4c8d71aec12a615a83aeedcf541c Mon Sep 17 00:00:00 2001
From: Pierre Ossman <pierre@ossman.eu>
Date: Sun, 12 Dec 2010 12:49:29 +0100
Subject: [PATCH 2/2] ipv6: give userspace all RA options that we do not care about

Instead of having to update the kernel for every new RA option that needs
to be dealt with in userspace, just send over everything that we don't
handle ourselves in the kernel.

Signed-off-by: Pierre Ossman <pierre@ossman.eu>
---
 net/ipv6/ndisc.c |   38 +++++++++++++++++++-------------------
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index c5b01e3..192e90b 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -233,12 +233,17 @@ static struct nd_opt_hdr *ndisc_next_option(struct nd_opt_hdr *cur,
 
 static inline int ndisc_is_useropt(struct nd_opt_hdr *opt)
 {
+	/* Keep in sync with ndisc_parse_options() ! */
 	switch (opt->nd_opt_type) {
-	case ND_OPT_RDNSS:
-	case ND_OPT_DNSSL:
-		return 1;
-	default:
+	case ND_OPT_SOURCE_LL_ADDR:
+	case ND_OPT_TARGET_LL_ADDR:
+	case ND_OPT_MTU:
+	case ND_OPT_REDIRECT_HDR:
+	case ND_OPT_PREFIX_INFO:
+	case ND_OPT_ROUTE_INFO:
 		return 0;
+	default:
+		return 1;
 	}
 }
 
@@ -268,6 +273,7 @@ static struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
 		l = nd_opt->nd_opt_len << 3;
 		if (opt_len < l || l == 0)
 			return NULL;
+		/* Keep in sync with ndisc_is_useropt() ! */
 		switch (nd_opt->nd_opt_type) {
 		case ND_OPT_SOURCE_LL_ADDR:
 		case ND_OPT_TARGET_LL_ADDR:
@@ -295,21 +301,15 @@ static struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
 			break;
 #endif
 		default:
-			if (ndisc_is_useropt(nd_opt)) {
-				ndopts->nd_useropts_end = nd_opt;
-				if (!ndopts->nd_useropts)
-					ndopts->nd_useropts = nd_opt;
-			} else {
-				/*
-				 * Unknown options must be silently ignored,
-				 * to accommodate future extension to the
-				 * protocol.
-				 */
-				ND_PRINTK2(KERN_NOTICE
-					   "%s(): ignored unsupported option; type=%d, len=%d\n",
-					   __func__,
-					   nd_opt->nd_opt_type, nd_opt->nd_opt_len);
-			}
+			/*
+			 * Unknown options must be silently ignored,
+			 * to accommodate future extension to the
+			 * protocol. We also provide them to userspace
+			 * for things like DNS configuration.
+			 */
+			ndopts->nd_useropts_end = nd_opt;
+			if (!ndopts->nd_useropts)
+				ndopts->nd_useropts = nd_opt;
 		}
 		opt_len -= l;
 		nd_opt = ((void *)nd_opt) + l;
-- 
1.7.2.3


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [RFC][PATCH] Export DNSSL RA option to userspace

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

I've also noticed a problem in the nduseropt code that I'm not sure how
to solve (given that this is now a stable userspace interface). Both
RFC5006 and RFC6106 state the following:

   Note:  An RDNSS address or a DNSSL domain name MUST be used only as
      long as both the RA router Lifetime (advertised by a Router
      Advertisement message [RFC4861]) and the corresponding option
      Lifetime have not expired.

But the RA router lifetime is not included in the information sent.
Normally this is probably not an issue as the RDNSS and DNSSL lifetime
will be shorter than the router lifetime. One exception is when the
router is disabled at which point it will send a RA with router
lifetime to 0 (RFC4861 section 6.2.5). That means userspace will not be
informed that the DNS information should be removed immediately*.

Is there any way we can safely extend the interface with this
information? I'm not familiar enough with it myself yet to determine if
it's possible...

* Unless the router has a workaround for this client bug and also sets
  RDNSS and DNSSL lifetimes to 0 as part of the final message.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [RFC][PATCH] Export DNSSL RA option to userspace

[David Woodhouse]

On Sun, 2010-12-12 at 14:43 +0100, Pierre Ossman wrote:
> RFC 6106 specifies a new RA option for DNS resolver configuration that
> therefore needs to end up in userspace.
> 
> This first patch just exports the new option, but I started thinking
> that this seems overly complex that the kernel needs to be updated
> every time there is something new of interest to userspace in the RA.
> So I also have a second patch that exports everything that the kernel
> doesn't want.
> 
> Patches only compile tested so far as I'm still hacking away at
> userspace. Comments very much welcome though.

Totally untested userspace support:
http://git.infradead.org/users/dwmw2/connman.git

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: [RFC][PATCH] Export DNSSL RA option to userspace

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On Tue, 14 Dec 2010 13:10:15 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> On Sun, 2010-12-12 at 14:43 +0100, Pierre Ossman wrote:
> > RFC 6106 specifies a new RA option for DNS resolver configuration that
> > therefore needs to end up in userspace.
> > 
> > This first patch just exports the new option, but I started thinking
> > that this seems overly complex that the kernel needs to be updated
> > every time there is something new of interest to userspace in the RA.
> > So I also have a second patch that exports everything that the kernel
> > doesn't want.
> > 
> > Patches only compile tested so far as I'm still hacking away at
> > userspace. Comments very much welcome though.
> 
> Totally untested userspace support:
> http://git.infradead.org/users/dwmw2/connman.git
> 

Tested userspace support in the form of NetworkManager: ;)

https://bugzilla.gnome.org/show_bug.cgi?id=637077

And a radvd to send things out:

http://lists.litech.org/pipermail/radvd-devel-l/2010-December/000507.html

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [RFC][PATCH] Export DNSSL RA option to userspace

[Dan Williams]

On Tue, 2010-12-14 at 14:43 +0100, Pierre Ossman wrote:
> On Tue, 14 Dec 2010 13:10:15 +0000
> David Woodhouse <dwmw2@infradead.org> wrote:
> 
> > On Sun, 2010-12-12 at 14:43 +0100, Pierre Ossman wrote:
> > > RFC 6106 specifies a new RA option for DNS resolver configuration that
> > > therefore needs to end up in userspace.
> > > 
> > > This first patch just exports the new option, but I started thinking
> > > that this seems overly complex that the kernel needs to be updated
> > > every time there is something new of interest to userspace in the RA.
> > > So I also have a second patch that exports everything that the kernel
> > > doesn't want.
> > > 
> > > Patches only compile tested so far as I'm still hacking away at
> > > userspace. Comments very much welcome though.
> > 
> > Totally untested userspace support:
> > http://git.infradead.org/users/dwmw2/connman.git
> > 
> 
> Tested userspace support in the form of NetworkManager: ;)
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=637077

And pushed to master and stable branches too.  Thanks for the work on
this!

Dan


> And a radvd to send things out:
> 
> http://lists.litech.org/pipermail/radvd-devel-l/2010-December/000507.html
> 
> Rgds

Re: [RFC][PATCH] Export all RA options that we don't handle to userspace

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

Ping!

The userspace support is rather useless without these kernel bits...

On Sun, 12 Dec 2010 14:47:06 +0100
Pierre Ossman <pierre-list@ossman.eu> wrote:

> Second patch that exports everything. If noone objects to this model,
> then merge the two patches and just use the commit message from the
> second one.
> 
> Pros:
> - Kernel doesn't need to be updated for every new RA option that might
>   show up.
> 
> Cons:
> - Possible security issue if it requires less privilege to read these
>   netlink messages than to open a raw ICMPv6 socket.
> - List of types the kernel is interested in is now in two places in the
>   code, creating a risk for getting out of sync. I tried to come up
>   with a structure that would prevent this, but couldn't think of
>   anything that wouldn't require large changes. Ideas welcome...
> 
> Rgds


-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [RFC][PATCH] Export DNSSL RA option to userspace

[Pierre Ynard]

Hello,

Thanks for the patch!

> From a5b60e80eeed87763c811ecfb0d7aa5695d0a2bf Mon Sep 17 00:00:00 2001
> From: Pierre Ossman <pierre@xxxxxxxxx>
> Date: Sun, 12 Dec 2010 00:06:48 +0100
> Subject: [PATCH 1/2] ipv6: export DNS search list option to userspace
> 
> Like DNS resolver addresses, the suffixes to be used in DNS lookups need
> to be configured by userspace. Make sure userspace has access to the
> option containing that information.
> 
> Signed-off-by: Pierre Ossman <pierre@xxxxxxxxx>
> ---
>  include/net/ndisc.h |    3 ++-
>  net/ipv6/ndisc.c    |    8 +++++++-
>  2 files changed, 9 insertions(+), 2 deletions(-)

Acked-by: Pierre Ynard <linkfanel@yahoo.fr>

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Re: [RFC][PATCH] Export all RA options that we don't handle to userspace

[Pierre Ynard]

> Second patch that exports everything. If noone objects to this model,
> then merge the two patches and just use the commit message from the
> second one.

I'm a bit wary about that, we don't know what new option might come out
in the future, that we really don't want to forward to userspace. I
suggest we remain conservative here.

Regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Re: [RFC][PATCH] Export DNSSL RA option to userspace

[Pierre Ynard]

> I've also noticed a problem in the nduseropt code that I'm not sure how
> to solve (given that this is now a stable userspace interface). Both
> RFC5006 and RFC6106 state the following:
> 
>    Note:  An RDNSS address or a DNSSL domain name MUST be used only as
>       long as both the RA router Lifetime (advertised by a Router
>       Advertisement message [RFC4861]) and the corresponding option
>       Lifetime have not expired.
> 
> But the RA router lifetime is not included in the information sent.
> Normally this is probably not an issue as the RDNSS and DNSSL lifetime
> will be shorter than the router lifetime. One exception is when the
> router is disabled at which point it will send a RA with router
> lifetime to 0 (RFC4861 section 6.2.5). That means userspace will not be
> informed that the DNS information should be removed immediately*.
> 
> Is there any way we can safely extend the interface with this
> information? I'm not familiar enough with it myself yet to determine if
> it's possible...

You could define a new netlink attribute to carry the lifetime of
the router in that RA. But that seems pointless to me, since in my
understanding, you have to track the lifetime of that router in future
RAs too, independently of whether or not they contain an RDNSS/DNSSL
option or not. So the nduseropt code path is not the right place to
track this.

I suppose it's possible to use a netlink socket to track events related
to the corresponding router and/or directly query its lifetime, in
the same way as any networking tool does, and remove the option when
it expires. That's what I planned to do in rdnssd, although I haven't
looked into details.

Regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Re: [RFC][PATCH] Export all RA options that we don't handle to userspace

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Reping!

On Thu, 20 Jan 2011 09:15:05 +0100
Pierre Ossman <pierre-list@ossman.eu> wrote:

> Ping!
> 
> The userspace support is rather useless without these kernel bits...
> 
> On Sun, 12 Dec 2010 14:47:06 +0100
> Pierre Ossman <pierre-list@ossman.eu> wrote:
> 
> > Second patch that exports everything. If noone objects to this model,
> > then merge the two patches and just use the commit message from the
> > second one.
> > 
> > Pros:
> > - Kernel doesn't need to be updated for every new RA option that might
> >   show up.
> > 
> > Cons:
> > - Possible security issue if it requires less privilege to read these
> >   netlink messages than to open a raw ICMPv6 socket.
> > - List of types the kernel is interested in is now in two places in the
> >   code, creating a risk for getting out of sync. I tried to come up
> >   with a structure that would prevent this, but couldn't think of
> >   anything that wouldn't require large changes. Ideas welcome...
> > 
> > Rgds
> 
> 


-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [RFC][PATCH] Export all RA options that we don't handle to userspace

[David Miller]

From: Pierre Ossman <pierre-list@ossman.eu>
Date: Sun, 20 Nov 2011 15:00:46 +0100

> Reping!

You ping like this 1,000 times, it won't make anything happen.

Instead, you need to formally make fresh resubmission of the patch
you wish us to consider.