[ipv6hackers] Local-link traffic injection through tunneling ?

[Mark ZZZ Smith]

----- Original Message -----
> From: ZAMANI Omar <Omar.ZAMANI at solucom.fr>
> To: ipv6hackers at lists.si6networks.com
> Cc: 
> Sent: Monday, 15 July 2013 6:30 PM
> Subject: [ipv6hackers] Local-link traffic injection through tunneling ?
> 
> Hello everyone !
> 
> 
> 
> I'm looking at the various attacks possible against an IPv6 enabled 
> enterprise network and in particular attacks that can be launched from outside 
> the network.
> 
> 
> 
> As far as I know, IPv6 well-known attacks rely on NDP which are mostly 
> Local-link attacks  (except NDP exhaustion if my memories are correct).
> 
> 
> 
> What I was wondering is : by establishing a tunnel from outside the network to 
> an internal IPv6 node, is it possible to target that node with NDP local-link 
> attacks from outside the network ? In other words and more generally, does the 
> tunnel act as a link-layer in that case ?

Yes. IPv6 tries to treat links as similar as possible, to minimise special handling. e.g., 

"RFC 4861               Neighbor Discovery in IPv6


...

 Unless specified otherwise (in a document that covers operating IP
   over a particular link type) this document applies to all link types.
   However, because ND uses link-layer multicast for some of its
   services, it is possible that on some link types (e.g., Non-Broadcast
   Multi-Access (NBMA) links), alternative protocols or mechanisms to
   implement those services will be specified (in the appropriate
   document covering the operation of IP over a particular link type).
   The services described in this document that are not directly
   dependent on multicast, such as Redirects, Next-hop determination,
   Neighbor Unreachability Detection, etc., are expected to be provided
   as specified in this document.
..."


"RFC 4291              IPv6 Addressing Architecture




2.1.  Addressing Model

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node.

   All interfaces are required to have at least one Link-Local unicast
   address (see Section 2.8 for additional required addresses).  A
   single interface may also have multiple IPv6 addresses of any type
   (unicast, anycast, and multicast) or scope.  Unicast addresses with a
   scope greater than link-scope are not needed for interfaces that are
   not used as the origin or destination of any IPv6 packets to or from
   non-neighbors.  This is sometimes convenient for point-to-point
   interfaces."

A tunnel is typically point-to-point, RFC4861 says the following about point-to-point links (in two separate sections):

   point-to-point - a link that connects exactly two interfaces.  A
                    point-to-point link is assumed to have multicast
                    capability and a link-local address.


     point-to-point - Neighbor Discovery handles such links just like
                      multicast links.  (Multicast can be trivially
                      provided on point-to-point links, and interfaces
                      can be assigned link-local addresses.)


> If so, do the attacker's machine, 
> the target node and the other nodes that share it local-link become all part of 
> the same link when a such tunnel is established ?
> 

Yes.


> 
> 
> Also, just to be clear about it, if a such tunnel is established with an 
> internal router, local-link encapsulated traffic won't be emitted on the 
> network because routers are not supposed to do so am I right ?
> 

Yes, routers are not to forward traffic with link-local sources and/or addresses.

One trick that has been used to try to ensure that a link-local sourced/destination packet has not been forwarded is to have the sender set the hop count value to 255, and the receiver ensure that the received hop count value is also 255. If it is any less than 255 it has been forwarded and should be dropped.

> 
> 
> Thanks for your answers and please excuse my bad English.
> 
> 
> 
> Have a nice day.
> 
> 

Regards,
Mark.

> 
> Omar ZAMANI
> Consultant
> Fixe : +33 (0)1 49 03 24 91
> omar.zamani at solucom.fr <mailto:omar.zamani at solucom.fr> 
> solucom
> Tour Franklin : 100 - 101 terrasse Boieldieu 
> 92042 Paris La Défense Cedex
> 
> 
> 
> 
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>