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:	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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ