RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Wes,

> -----Original Message-----
> From: Wes Beebee (wbeebee) [mailto:wbeebee@cisco.com]
> Sent: Wednesday, January 06, 2010 1:36 PM
> To: Hemant Singh (shemant); Templin, Fred L; Fred Baker (fred); v6ops@ops.ietf.org
> Cc: kurtis@kurtis.pp.se; rbonica@juniper.net
> Subject: RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-
> 03.txt WGLC)
> 
> > Again, this is not a memory limitation consideration; it is a policy
> consideration.
> 
> OK - I finally understand where you're coming from.  Consider the
> following scenario:
> 
> 1) A CE Router is connected via a link to a SP Router, and sends a
> DHCPv6 SOLICIT with IA_PD.
> 2) An evil host running Dibbler sends a DHCPv6 SOLICIT with an IA_PD
> option that SP router gleans.
> 3) SP router populates routing table with IA_PD from both boxes.
> 4) Traffic is sent to both the CE Router and the evil host destined for
> PC's behind the CE Router and the evil host.
> 5) The evil host should NOT be receiving this traffic since it is not a
> router.
> 
> Therefore, a policy was enacted to use the IsRouter flag to determine
> whether the box is the CE Router or the evil host.  The evil host is
> rejected by garbage collection (the policy).  Unfortunately, the CE
> Router is also rejected by the policy, since the Neighbor Cache entry in
> the SP Router says that the CE Router IsRouter flag is FALSE.
> 
> The policy is understandable from a security perspective.  However, the
> primitive used to implement the policy (IsRouter) is too weak to do the
> job.

I don't know if it would be productive to try to guess
at what policy decisions the endless array of router
implementations would observe, but I know of at least
one implementation that takes heed of the IsRouter
flag when considering whether a route should be deleted.

> There are two solutions to this problem.
> 
> 1) Make IsRouter a stronger primitive that would be up to the job.
> 2) Use a different primitive which is stronger to implement the policy.
> 
> #1 is very difficult and may have serious repercussions to the ND
> specification and other implementations and may not be feasible.
> 
> I suggest you start with #2.  Some primitives that may help (which have
> other problems) include routing protocols, secure ND, DHCPv6 gleaning by
> the SP Router, or a combination of the three.
> 
> If these primitives are insufficient for your needs, you can consider
> doing additional protocol work outside of the tools available in RFC
> 4861.

Maybe so, but lacking a spec I don't think it would
be productive to try to guess whether all router
implementations observe the same policies wrt the
IsRouter flag.

Fred
fred.l.templin@boeing.com

> - Wes and Hemant