Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)

[Mark Smith <[e-mail]>]

Hi Fernando,


On Fri, 24 Jun 2011 00:17:01 -0300
Fernando Gont <[e-mail]> wrote:

> On 06/22/2011 08:34 AM, Mark Smith wrote:
> 
> >> I think it is a bit ironic that if a L2 device has to parse all extension
> >> headers, that then L2 switching of IPv6 packets will be more expensive that
> >> L3 routing them.
> > 
> > It may be getting to the point where it'd probably be easier
> > to address these issues by taking away hosts' ability to multicast to
> > other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
> > mode of LAN operation, allowing the designated routers to also act as
> > traffic sanitisers for on-link inter-host traffic.
> 
> Two comments:
> 
> * Hosts would still need to multicast RSs

Yes, but the layer 2 device only delivers those multicast RSes to ports
that it has been told are attached to authorised routers.

> * This does nto prevent attackers from sending ND packets *unicast* to
> their victims.
> 

Actually it can.  Have a look at the following -

http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01

The layer 3 hub-and-spoke forwarding topology described can also be and
is likely to also be enforced at layer 2, by preventing layer 2
forwarding of traffic between designated host ports, limiting it to
host port to router port, or router port to host port.

It's interesting to look back on where we've come from. On simple
10BASE2 and earlier Ethernet, broadcast/multicast was cheap, because it
was the inherent nature of it's bus topology. After we moved to
bridges/switches with individual devices attached to each port, this
broadcast/multicast capability had to be actively emulated, because a
star topology does not have a natural broadcast/multicast capability.
Implementing hub-and-spoke forwarding paths in a bridge/switch is
not much more than reducing the requirement to emulate something that
fundamentally wasn't natural in the first place.

Regards,
Mark.