netdev - Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection

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: <20070131205443.GA12237@hmsreliant.homelinux.net>
Date:	Wed, 31 Jan 2007 15:54:43 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	YOSHIFUJI Hideaki / 吉藤英明 
	<yoshfuji@...ux-ipv6.org>
Cc:	vladislav.yasevich@...com, sri@...ibm.com, davem@...emloft.net,
	kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
	kaber@...eworks.de, netdev@...r.kernel.org
Subject: Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection

On Wed, Jan 31, 2007 at 01:16:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20070130130208.GA3723@...reliant.homelinux.net> (at Tue, 30 Jan 2007 08:02:08 -0500), Neil Horman <nhorman@...driver.com> says:
> 
> > > I do not think we should copy neighbor information from (one of)
> > > default routers, but use temporary neigh entry (or neigh in new state)
> > > for such datagrams in stead.  We should aware that:
> > > 
> > Not sure how that is different from what I'm proposing.  a neighbor entry that
> > maps a given host on the current subnet to the MAC of the default router, that
> > then gets flushed when DAD completes is temporary, as far as I can see.
> > 
> > >  1) default router's link-layer address may change.
> > True, but if this changes, all our network connectivity is lost, until the
> > normal neighbor solicitation process completes anyway.
> 
> No, router may update its link-layer address by NA with Override flag set.
> In that case, we must use new link-layer for subsequent packets from
> our opportunistic address duing DAD.
> 
> > >  2) we may have more than one default routers.
> > True, but I would think we could select any of them and this would work.
> > Granted, we wouldn't use all the default routers in the table as we would with
> > routed frames, but I'm not sure how we avoid that.
> 
> I mean, if the status of the selected default router has changed or 
> has been deleted, we should try other router, at least.
> 
> > >  3) the default router's link-layer may be invalidated.
> > > 
> > yes, but this would be bad for the same reason as (1)
> 
> We MUST take this into account.
> 

Ok, understood.  In summary, we can't simply fill out the neighbor entry for a
given host with the address of a default router because

1) Any changes to the router link layer address wont be reflected in that when
it (the change) happens, redering the local address unable to communicate until
the neighbour entries age out.

2) There may be more than one default router as selected by the routing policy,
and we should be able to try those routes if the selected router becomes
unavailable

It sounds like what we need to do is shim into the route lookup code, and detect
there if we need to redirect every packet as they are sent.  I think I may have
an idea for this.  What if we implement the lookup in ip6_dst_lookup_tail.  In
there we can check if the associated neigh entry for the resolved dst_entry is
in a INCOMPLETE or FAILED state, and if the ifaddr associated withe the source
address passed in via the flowi struct is in an OPTIMISTIC state.  If both
conditions are true, we release the dst_entry that we origionally looked up, and
instead conduct a second lookup with a newly constructed flowi struct with the
dst addr replaced with an all zeros address (which I think should return a
gateway, selected as per routing policy).  Then we can return that dst entry
instead.  Since ip6_push_pending frames seems to bulid the ipv6 header using the
addresses in the flowi struct passed into ip6_*_dst_lookup from *_sendmsg
routines, and the link layer header is built based on the info gathered from the
resolved dst_entry (If I'm reading the code right), I think this give us what we
want, in that we redirect to a gatweway when we send from an optimistic address,
and we select the gateway based on the logic in the route lookup code
(ip6_route_output() specifically).  I'm trying to implement this right now, and
will post a new patch as soon as I have it done.  In the meantime, any thoughts
would be most appreciated.

Regards
Neil

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