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

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]

Message-ID: <20110303013649.GA13101@via.ecp.fr>
Date:	Thu, 3 Mar 2011 02:36:49 +0100
From:	Pierre Ynard <linkfanel@...oo.fr>
To:	netdev@...r.kernel.org
Cc:	pierre-list@...man.eu
Subject: Re: [RFC][PATCH] Export DNSSL RA option to userspace

> 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."
--
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