HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > IPv6: Les dangers du Routing Header Type 0
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|IPv6: Les dangers du Routing Header Type 0  

by Nicolas Collignon (27/02/2007)



------------[ IPv6: pitfall of "Routing Headers Type 0" ]---------------



Cet article est disponible en francais à ipv6-rt0.html.fr .



--[ 1. Introduction ]---------------------------------------------------

This article presents routing headers type 0 of the IPv6 protocol
and the threats involved with.

The Routing Header (RH) is used by an IPv6 host to list one or more
intermediate nodes to be "visited" on the way to a packet's destination.
This function is very similar to IPv4 Source Routing. Three RH types
are currently (27/02/2006) defined.

RH type 0 is the most generic type. It has been designed to hold one or
more intermediate routers.

RH type 1 has been reserved for an experimental network architecture
called Nimrod. Nimrod is kind of distributed routing architecture where
network's intelligence is centralized in subsystems which are not necessary
organized according to the network topology. RH type 1 specifications
are obsolete since January 1996.

RH type 2 is a limited version of the type 0. It has been designed to
hold an unique intermediate router. It may be used for IPv6 Mobility
(MIPv6) to specify the "Home Address" (HoA) of the "Mobile Node" (MN).

This article is about 4 threats involved with routing headers:
 - ACL bypassing: IPv6 to IPv6 and IPv6 to IPv4
 - scope evasion
 - traffic overbilling
 - network scan optimization


--[ 2. Routing Headers Type 0 ]-----------------------------------------
Routing Headers type 0 is a concept very similar to IPv4 source routing
which is not used anymore mainly for security reasons.

IPv4 source routing permits to alter the path of a packet but the
destination address held in IPv4 packet's header stays the same from the
emitter to the final destination.

While the destination address field of the packet's header changes after
each intermediate hops with IPv6 routing header.

Below is a diagram representing the evolution of the source address (src),
the destination address (dest) and the list of the RH intermediate
routers (RH) on a packet path.


        src: A                src: A               src: A
       dest: B               dest: C              dest: D
         RH: C, D              RH: D

  A  ----------------> B ----------------> C ---------------->  D

  ^                                                             |
  |                                                             |
  +-------------------------------------------------------------+
                            src: D
			   dest: A


RH are a standard extension of the IPv6 protocol. Thus their structure
is very simple and generic:



        0     8    16    24    32
      0 +-----+-----+-----+-----+  --> bits
        |  N  |  L  |  T  |  C  |
      4 +-----+-----+-----+-----|   N: next extension (ex: UDP)
        |                       |   L: size of the extension
        | RH Type specific data |   T: type of RH
        |                       |   C: remaining hops count
        |          ...          |
  bytes v                       v



The structure of the RH type 0 is the most generic one and has the
following format:

        0      8       16      24      32
      0 +-------+-------+-------+-------+
        |   N   |   L   |   0   |   C   |
      4 +-------+-------+-------+-------|
        |   0       0       0       0   |
      8 +-------------------------------+
        |                               |

        |     Address of router n°1     |
        |                               |
     24 +-------------------------------+
        |                               |

        |     Address of router n°2     |
        |                               |
     40 +-------------------------------+
        |              ...              |
        v                               v


Some IPv6 implementations limit the intermediary hop list's size, whereas
others permits to use as much hops as long as the packet is not fragmented.

Support of RH type 0 is mandatory for an IPv6 implementation which support
all RFC 2460 requirements. It's not the case for RH types 1 and 2.

Almost all IPv6 implementations permit the use of RH only with protocols
UDP and ICMPv6.



--[ 3. Bypassing ACL ]--------------------------------------------------

All ACL bypassing methods explained below are based on the fact that the
destination address held in the IPv6 header is not necessary the real
final destination of a packet.
A firewall musts analyze the content of the routing header to identify
the final destination. All following study cases concern only ACL based
on the destination address.




----[ 3.1 IPv6 to IPv6 ]------------------------------------------------

First study case concerns the bypassing of a firewall blocking outgoing
connections to a server plugged in an IPv6 network.
By using RH extension, it's possible for the client to bypass filtering
rules based on the destination address field in the IPv6 header. When
the packet is handled by the firewall, the destination address field is
the address of the relay, not the one of the server:

                              +--- Relay IPv6 ---+
                              |                  |
                              |                  v
   Client IPv6 --------> Firewall -----XX----> Server IPv6

The flow of the packets sent by the client to the server bypass the firewall
but the answer packets will be blocked if the filtering rule is checking
the source and the destination address. It may be possible to establish
a bidirectional tunnel by using a specially configured IPv6 stack on the
server side in order to bypass ACLs.

In the latter case, at no time the packets:
 - sent by the client will use the server's address in the IPv4 header
   destination address field.
 - sent by the server will use the client's address in the IPv4 header
   destination address field.

          +--- Relay IPv6 ---+    +--- Relay IPv6 ---+
          |                  |    |                  |
          v                  v    v                  v
   Client IPv6 <----XX----> Firewall <----XX----> Server IPv6


----[ 3.2 IPv6 to IPv4 ]------------------------------------------------

Both IP version will share network links for long time. Filtering one
version of the IP protocol involve checking all available IP transition
mechanisms in order to avoid non-authorized access.

There are a lot of IPv6 and IPv4 public and free relays on the IPv6
internet. Thus ACLs based on IPv4 addresses blacklisting is almost
useless on a network where full IPv6 connectivity is provided.

An IPv4 ACL bypass using a public IPv6 to IPv4 relay:

                           6 +--- Relay IPv6/IPv4 ---+ 4
                             |                       |
                             v                       v
   Client IPv6 <--------> Firewall <-----XX-----> Server IPv4




--[ 4. Scope Evasion ]--------------------------------------------------

IPv6 Addresses are grouped in 4 scopes:
 - Node-Local  Limited to 1 host (localhost)
 - Link-Local  Limited to the network link
 - Site-Local  Large and supervised scope (ex: Intranet)
 - Global      Internet IPv6
 
The theory says it should not be possible to communicate between two IP
addresses of different scopes. This is not specific to IPv6. It's not
possible to contact a public IPv4 address from an address of 192.168.0.0/16.

Most of IPv6 stack implementations only check if there is any Multicast
address in the intermediary hops list of the RH before routing the
packets. The implementations rarely check whether all the intermediary
hops addresses belong to the same scope.

      [global]             [site]       [link]      [node]

   A ---------> Firewall ---------> B ---------> C ::1

       2000::              fec0::       fe80::

It's obviously not possible to get an answer from a packet which source
and destination address scopes differ because the final host:
 - would cross addresses scopes to send the answer
 - won't use any routing header (default behaviour).
 
Scope evasion may be considered harmless but it clearly shows some side
effects of routing headers. If the final host is forced to use RH when
answering packets, scope evasion can be used to escape ACLs.




--[ 5. Traffic Overbilling ]--------------------------------------------

On some specific network infrastructures, billing may be based on the
volume of traffic sent or based on the duration of communications.

Let's consider a network:
  - with N hosts and 1 malicious user
  - on which a sum S is charged for each bytes of UDP data sent.
  - with a MTU big enough so that K relays may be included in the IPv6
    packet header without fragmentation.
    
A malicious user could use RH to charge N clients instead of only one
(himself).

Standard billing case:
   Cost for the intruder:   S
   Cost for the N hosts:    0
   
Overbilling case:
   Cost for the intruder:   S
   Cost for the N hosts:    S x MAX(K, N)
   

      +--> Client B ----> Client C ----> Client D ---+
      |                                              |
      |                                              v
   Client A <------------------------------------- Server
   

Most IPv6 implementations don't inspect the content of the RH. Thus it's
possible to generate routings loops.

Client A charges clients B and C few times before contacting the server:

              +----------+  ---->  +----------+
      +-----> | Client B |  <----  | Client C | ------+
      |       +----------+  ---->  +----------+       |
      |                                               v
   Client A <------------------------------------- Server
   
If we consider an IPv6 network with:
  - with 4 clients (N=3)
  - where the communication is charged 1 cent per packet (S=1)
  - with a MTU big enough so that 23 routers can be held in the RH

Cost for the intruder          =>  1 cent
Effective cost for the network => 23 cents (S x K)




--[ 6. ICMPv6 Scan Optimization ]---------------------------------------

IPv6 protocol has been designed to increase network's transparency. It's
quite unusual to meet IPv6 firewalls filtering ICMPv6 protocol.
It may be possible to shorten a IPv6 "ping" scan on a network where IPv6
hosts answer to ICMPv6 "Echo Request" when RH are used.

Instead of checking the presence of only one host per sent packet, we can
check up to K addresses per sent packet as long as the network's MTU is
big enough to hold K intermediary hops in the RH without fragmentation.

Let's consider a scanner trying to detect the presence of hosts A, B and C
and on network. Instead of sending one ping to each host, the scan can be
optimized by using hosts B and C as intermediary routers before trying to
reach final host A.

So:
  - if A answers, addresses A, B and C are valid
  - if an ICMPv6 "Unreachable" error packet is returned, the sender should
    be considered as the last valid hop.

Below is a ping to host A trying to scan B and C at the same time:

                                 +------+  Host B
                                 ^      |
                                 |      v
     Scanner <--------> Router R +      +  Host C
                                 ^      |
                                 |      v
                                 +------+  Host A

Thus:
  - if A answers "Echo Reply"  => A, B, C are valid
  - if B answers "Unreachable" => B is valid
  - if C answers "Unreachable" => B, C are valid
  - if R answers "Unreachable" => B is invalid




--[ 7. Filtering ]------------------------------------------------------

Here are some filtering rules for various firewalls which may be used
to block IPv6 Routing Headers.

  * Cisco IOS < 12.2(15)T
    deny ipv6 any any routing

  * Cisco IOS>= 12.2(15)T
    no ipv6 source-route

  * Linux netfilter
    ip6tables -A INPUT -m rt --rt-type 0 -j DROP

  * ipf
    block in proto udp from any to any with v6hdrs routing


--[ 8. Conclusion ]-----------------------------------------------------


IPv6 stack implementations handle differently RH. Some stacks are very
restrictive about the list of intermediary router addresses and their
scopes. Others are very kind and even route packets through localhost.

I recommend to block RH on a network where they are not needed or at
least to inspect RH content.

Before setting up ACLs on an IPv6 network, it's mandatory to check which
equipments support RH and which equipments are enable to interpret their
meaning.

                  -- Nicolas Collignon <Nicolas(dot)Collignon(at)hsc.fr>



--[ 9. References ]-----------------------------------------------------

 - RFC2460 - Internet Protocol Version 6

   http://www.ietf.org/rfc/rfc2460.txt

 - draft-ietf-nimrod-rh1-00 - Nimrod Routing Header

   http://www.ir.bbn.com/projects/nimrod/draft-ietf-nimrod-rh1-00.txt

 - RFC3775 - Mobility Support in IPv6

   http://www.ietf.org/rfc/rfc3775.txt

 - Deploying IPv6 Networks - Cisco Press
   ISBN 1-58705-210-5

 - IPv6 : Théorie de pratique - O'Reilly
   ISBN 284177337X
   http://livre.point6.net


Last modified on 27 Mars 2007 at 13:49:00 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants