Subject: IID-format constraint applicable to all IPv6 addresses for routing-loop attack protection

From: Rémi Després <[email-masked]>
Date: Thu, 10 Sep 2009 14:08:16 +0200

Hi all,

Should IID-format constraints be applicable to IPv6 addresses, even  
if they don't contain real IIDs?

I have proposed in various occasions that they would apply only to  
addresses that do contain real IIDs.

This mail is to WITHDRAW this proposal, to explain why it was  
proposed, and to explain why it is withdrawn.

GENERAL ANALYSIS

New IPv6-address formats are being considered for IPv6 addresses  
that, in IPv6/IPv4 NATs, identify IPv4 hosts. Some others are  
considered for new tunneling mechanisms, in particular the SAM I  
presented in Stockholm for IPv6 multihoming.

In these addresses, the lower 64 bits are not real IIDs:
- RFC 3513 says that "Interface identifiers in IPv6 unicast addresses  
are used to identify  interfaces on a link").
- The lower 64 bits of these addresses are never "used to identify  
interfaces on a link". It is only IPv4 or IPv6 addresses obtained  
after some mapping that are used for on-link interface  
identification. They in general don't contain the initial lower 64 bits.

We will call such addresses "mappable-only" addresses.

RFC 3513 also says, as we all know, that "For all unicast addresses,  
except those that start with binary value 000, Interface IDs are  
required to be 64 bits long and to be constructed in Modified EUI-64  
format".

We will call this constraint the "IID-format constraint"

Since mappable-only addresses have no real "Interface ID", they may  
be interpreted as out of the scope of the IID-format constraint.

If they are indeed out of scope, that's good news because new formats  
of mappable-only addresses can be simpler than if they are in scope  
(no constraint on the two lower bits of their 9th octet).

If mappable-only addresses should be considered in the constraint  
scope, some technical reason for it should at least be documented.

Since no such technical reason was identified, I proposed to make  
official that the IID-format constraint doesn't apply to mappable- 
only addresses.

Now, it happens that such a technical reason has just been  
identified. As explained below, it relates to a subtle attack  
possibility with some ISATAP and 6to4 nodes conforming to current  
RFCs. The only choice that remains is then to clearly include  
mappable-only addresses in the scope of the IID-format constraint.

ROUTING-LOOP ATTACK PROTECTION AND ITS IMPLICATION ON IPV6 ADDRESS  
FORMATS

In a mail of Aug 17 (www.ops.ietf.org/lists/v6ops/v6ops.2009/ 
msg00601), Gabi Nakibly documented a new type of attack: the "routing  
loop" attack. With it, some packets can be repeatedly retransmitted  
between two ISATAP routers, or between an ISATAP router and a 6to4  
relay router.

For a brief illustration of one instance of the the attack, here is  
an example:

+-------------------------------------------------------+
| IPv6                   IPv6 packet                    |
|Internet        dst6:  2002:198.16.9.9::1              |
|                src6:  2001:db8:1::200:5efe:192.88.99.1|
|                                           |           |
|                                           V           |
|          .--------------->--------------. |           |
|         /                                \|           |
+--------+----------------------------------+-----------+
          |                                  |
   2001:db8:1::/48                       2002::/16
     +---------+                        +---------+
     | ISATAP  |                        |  6to4   |
     +---------+                        +---------+
     198.16.9.9                         192.88.99.1
          |                                  |
+--------+---------+                        |
| IPv4   ^         |                        |
| site   ^         |                        |
|        ^         |                        V
|        ^         |                        |
+--------+---------+                        |
     198.16.9.0/24                           |
          |                                  |
          |                                  |
+--------+----------------------------------+-----------+
| IPv4    \                                /            |
|internet  '----------------<-------------'             |
|                 IPv6 in IPv4 packet                   |
|                  dst4: 198.16.9.9                     |
|                  src4: 192.88.99.1                    |
|                                                       |
+--------+----------------------------------+-----------+

Detailed protection mechanisms against these attacks are being  
discussed on the v6ops and 6man lists, in particular with Gabi  
Nakibly, Fred Templin, and Christian Huitema, and are out of scope  
here. Suffice it to say that a  6to4 relay router may need, to be  
safe, to look at IPv4 addresses that are embedded in ISATAP IPv6  
addresses. In the above example, if the 6to4 relay router sees that  
the IPv4 embedded address in the IPv6 destination is its own IPv4  
address 192.88.99.1, it can discard the packet and thus prevent the  
loop.

Now, IPv4 addresses embedded in ISATAP addresses can be reliably  
detected ONLY if non-ISATAP addresses NEVER have 200:5efe::/32 in  
their octets 8 to 15. If some mappable-only address would have this  
pattern, there could be a slight but real possibility that an  
intermediate 6to4 relay would discard packets sent to this address.

This is, in my understanding, a sufficient technical reason for the  
IID-format constraint to apply to all IPv6 addresses (with or without  
real IID).

Regards,
RD