Subject: Routing loop attacks using IPv6 tunnels

From: Gabi Nakibly <[email-masked]>
Date: Mon, 17 Aug 2009 08:21:12 -0700 (PDT)

Hi all,
I would like to draw the attention of the list to some research results which my colleague and I at the National EW Research & Simulation Center have recently published. The research presents a class of routing loop attacks that abuses 6to4, ISATAP and Teredo. The paper can be found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf

Here is the abstract:
IPv6 is the future network layer protocol for the Internet. Since it is not compatible with its predecessor, some interoperability mechanisms were designed. An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 network without prior configuration. This category includes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exploit vulnerabilities in these tunnels. These attacks take advantage of inconsistencies between a tunnel's overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. We exhibit five attacks of this class. One of the presented attacks can DoS a Teredo server using a single packet. The exploited vulnerabilities are embedded in the design of the tunnels; hence any implementation of these tunnels may be vulnerable. In particular, the attacks were tested
 against the ISATAP, 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 R2. 

I think the results of the research warrant some corrective action. If this indeed shall be the general sentiment of the list, I will be happy write an appropriate I-D. The mitigation measures we suggested in the paper are the best we could think of to completely eliminate the problem. However they are far from perfect since they would require tunnel implementations to be updated in case new types of automatic tunnels are introduced.

Your comments are welcome.

Gabi

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 17 Aug 2009 19:54:06 +0300

Le lundi 17 août 2009 18:21:12 Gabi Nakibly, vous avez écrit :
> Hi all,
> I would like to draw the attention of the list to some research results
> which my colleague and I at the National EW Research & Simulation Center
> have recently published. The research presents a class of routing loop
> attacks that abuses 6to4, ISATAP and Teredo. The paper can be found at:
> http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf

Attack E has been known for at least 2 years, though I do not have a Microsoft 
implementation to verify: http://www.remlab.net/miredo/mtfl-sa-0603.shtml.en

Note that it *does* affect Linux-based in the sense that a non-privileged 
local user could screw up (an unlikely scenario on a Teredo server, anyway).

I'm now trying to verify attack D.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Aug 2009 10:35:08 -0700

Gabi,

Thanks for publishing this work. In the document, attacks A, B and C

correspond to a configuration that violates section 6.2 of RFC5214:

> 6.2.  ISATAP Interface Address Configuration

>   Each ISATAP interface configures a set of locators consisting of
IPv4

>   address-to-interface mappings from a single site; i.e., an ISATAP

>   interface's locator set MUST NOT span multiple sites.

In particular, in scenarios A, B and C the IPv4 locator used for ISATAP

is seen both within the enterprise as site #1 and within the global
Internet

itself as site #2. If the ISATAP interface is to be used as an
enterprise-

interior interface, it should therefore not accept IP-proto-41 packets

coming from an IPv4 source outside of the enterprise nor source

IP-proto-41 packets that are destined to an IPv4 node outside of the

enterprise. This condition should be satisfied by having the site border

routers implement IPv4 ingress filtering and ip-protocol-41 filtering as

required in Section 10 of RFC5214.

It is mentioned that attack C could also occur when the routers reside

in the same site, where their addresses may be private. This would

correspond to a case in which an attacker within the site attacks the

site itself, which can easily be traced - especially when source address

spoofing from a node within the site is prevented through proper ingress

filtering.

Fred

[email-masked]

________________________________

From: Gabi Nakibly [mailto:[email-masked]] 
Sent: Monday, August 17, 2009 8:21 AM
To: v6ops
Cc: [email-masked]; [email-masked]
Subject: Routing loop attacks using IPv6 tunnels

Hi all,

Here is the abstract:

IPv6 is the future network layer protocol for the Internet. Since it is
not compatible with its predecessor, some interoperability mechanisms
were designed. An important category of these mechanisms is automatic
tunnels, which enable IPv6 communication over an IPv4 network without
prior configuration. This category includes ISATAP, 6to4 and Teredo. We
present a novel class of attacks that exploit vulnerabilities in these
tunnels. These attacks take advantage of inconsistencies between a
tunnel's overlay IPv6 routing state and the native IPv6 routing state.
The attacks form routing loops which can be abused as a vehicle for
traffic amplification to facilitate DoS attacks. We exhibit five attacks
of this class. One of the presented attacks can DoS a Teredo server
using a single packet. The exploited vulnerabilities are embedded in the
design of the tunnels; hence any implementation of these tunnels may be
vulnerable. In particular, the attacks were tested against the ISATAP,
6to4 and Teredo implementations of Windows Vista and Windows Server 2008
R2. 

I think the results of the research warrant some corrective action. If
this indeed shall be the general sentiment of the list, I will be happy
write an appropriate I-D. The mitigation measures we suggested in the
paper are the best we could think of to completely eliminate the
problem. However they are far from perfect since they would require
tunnel implementations to be updated in case new types of automatic
tunnels are introduced.

Gabi

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 18 Aug 2009 02:29:58 -0700 (PDT)

Indeed, the vulnerability of attack 5 was noted and fixed in Miredo. However, I am not aware of any updates to the Teredo specification to mitigate it. This means that new implementations will always be vulnerable as in the case of Windows Server 2008 R2. This vulnerability was reported to Microsoft a few months ago. They have reproduced it on their end. A fix should be released in the next RC.
I did not realize that the attack can be successful also on Linux. Thanks for the correction.

Please let me know the results of your check on attack #4. If you wish, I can send you (off-list) the details of my setup for this attack. By the way, I encourage other people on the list to verify the attacks in different scenarios.

Gabi

________________________________
From: Rémi Denis-Courmont <[email-masked]>
To: Gabi Nakibly <[email-masked]>
Cc: v6ops <[email-masked]>; [email-masked]; [email-masked]
Sent: Monday, August 17, 2009 7:54:06 PM
Subject: Re: Routing loop attacks using IPv6 tunnels

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 18 Aug 2009 03:29:26 -0700 (PDT)

Indeed the ISATAP interface of the ISATAP router is meant to be an enterprise-interior (note that it is still assumed that the associated IPv4 address is non-private). As we explicitly note in the paper, the first three attacks will be mitigated if proper protocol-41 filtering is deployed on the site's border. However, note that RFC5214 does not mandate or require this filtering. It is only mentioned as a possible mitigation against incoming spurious protocol-41 packets. In addition, Section 10 of RFC5214 only mentions ingress not egress filtering. Hence it will not stop attack #2. 
In addition, as mentioned, protocol-41 filtering is not helpful when attack #3 is launched on two routers that reside in the same site. Note that it may be possible for the attack packet to be sourced from outside the site unless proper filtering of incoming IPv6 packets is deployed. If the attacker resides in the site, usually ingress filtering will not be helpful since it is deployed in general on the site's border.

In general, I would like to point out that indeed as in most other attacks these attacks may also be mitigated by proper firewall rules. However, I do not believe that this should be our only answer against these attacks. I believe that since these attacks are made possible due to the inherent characteristics of the tunnels they should be stopped intrinsically as much as possible by the tunnel participants and not relay on outside filtering rules.

Gabi

________________________________
From: "Templin, Fred L" <[email-masked]>
To: Gabi Nakibly <[email-masked]>; v6ops <v6ops@ops..ietf.org>
Cc: [email-masked]; [email-masked]
Sent: Monday, August 17, 2009 8:35:08 PM
Subject: RE: Routing loop attacks using IPv6 tunnels

Gabi,
 
Thanks for publishing this work. In the document, attacks A, B and C
correspond to a configuration that violates section 6.2 of RFC5214:
 
>   Each ISATAP interface configures a set of locators consisting of IPv4
 
In particular, in scenarios A, B and C the IPv4 locator used for ISATAP
is seen both within the enterprise as site #1 and within the global Internet
itself as site #2. If the ISATAP interface is to be used as an enterprise-
interior interface, it should therefore not accept IP-proto-41 packets
coming from an IPv4 source outside of the enterprise nor source
IP-proto-41 packets that are destined to an IPv4 node outside of the
enterprise. This condition should be satisfied by having the site border
routers implement IPv4 ingress filtering and ip-protocol-41 filtering as
required in Section 10 of RFC5214.
 
site itself, which can easily be traced – especially when source address
 
Fred

From:Gabi Nakibly [mailto:[email-masked]] 
Sent: Monday, August 17, 2009 8:21 AM
To: v6ops
Cc: [email-masked]; [email-masked]
Subject: Routing loop attacks using IPv6 tunnels
 
Hi all,
 
Here is the abstract:

 
Gabi

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 18 Aug 2009 13:51:30 +0200

On Tue, 18 Aug 2009 02:29:58 -0700 (PDT), Gabi Nakibly <[email-masked]>
wrote:
> Indeed, the vulnerability of attack 5 was noted and fixed in Miredo.
> However, I am not aware of any updates to the Teredo specification to
> mitigate it. This means that new implementations will always be
vulnerable
> as in the case of Windows Server 2008 R2. This vulnerability was reported
> to Microsoft a few months ago. They have reproduced it on their end. A
fix
> should be released in the next RC.

Well, it is as simple as not looping packet back to yourself, isn't it?
There could be a warning in the spec, but it's really an implementation
error, I think.

> Please let me know the results of your check on attack #4. If you wish, I
> can send you (off-list) the details of my setup for this attack. By the
> way, I encourage other people on the list to verify the attacks in
> different scenarios.

I managed to reproduce it. Single-homed NATs have absolutely no excuse in
forwarding a packet with their own IP address as the source. But yeah -
there is a problem.

-- 
Rémi Denis-Courmont

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Aug 2009 08:48:45 -0700

Gabi,

________________________________________
From: Gabi Nakibly [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2009 3:29 AM
To: Templin, Fred L; v6ops
> Indeed the ISATAP interface of the ISATAP router is meant
> to be an enterprise-interior (note that it is still assumed
> that the associated IPv4 address is non-private). As we
> explicitly note in the paper, the first three attacks will
> be mitigated if proper protocol-41 filtering is deployed on
> the site's border. However, note that RFC5214 does not mandate
> or require this filtering.

The RFC5214 Security Considerations makes clear the
consequences of not implementing IPv4 ingress filtering
and ip-protocol-41 filtering (i.e., a possible spooing
attack in which spurious ip-protocol-41 packets are
injected into an ISATAP link from outside). RFC5214
Section 6.2 additionally requires that an ISATAP interface's
locator set MUST NOT span multiple sites. This means that the
ISATAP interface must not decapsulate nor source ip-proto-41
packets within multiple sites, where the enterprise interior
is site #1 and the global Internet is site #2. ip-protocol-41
filtering is the way in which the ISATAP interface is
restricted to a single site. 

> It is only mentioned as a possible mitigation against
> incoming spurious protocol-41 packets. In addition,
> Section 10 of RFC5214 only mentions ingress not egress
> filtering. Hence it will not stop attack #2.

We are now talking about ip-proto-41 filtering; not ingress
filtering. ip-proto-41 filtering is in both directions. It
prevents ip-proto-41 packets from entering the enterprise
interior ISATAP site from the Internet and prevents
ip-proto-41 packets from entering the Internet ISATAP
site from the enterprise interior. Else the ISATAP
interface would span multiple sites.

Besides, "ingress" filtering is not about packets coming
from the Internet into the end site, but rather it is
about packets leaving the end site and going out into
the Internet. RFC2827 (BCP38) documents ingress filtering.

> In addition,
> as mentioned, protocol-41 filtering is not helpful when
> attack #3 is launched on two routers that reside in the
> same site. Note that it may be possible for the attack
> packet to be sourced from outside the site unless proper
> filtering of incoming IPv6 packets is deployed. If the
> attacker resides in the site, usually ingress filtering
> will not be helpful since it is deployed in general on
> the site's border.

Here, we have the ISATAP router in both cases sourcing a
packet from a foreign prefix. This attack is mitigated by 
IPv6 ingress filtering which is an IPv6 security consideration
and not an ISATAP nor IPv4 security consideration. BCP
recommendations for network ingress filtering are documented
in RFC2827 and it is expected that IPv6 routers that configure
ISATAP interfaces will implement IPv6 ingress filtering
according to the BCP.
 
> In general, I would like to point out that indeed as in
> most other attacks these attacks may also be mitigated by
> proper firewall rules. However, I do not believe that this
> should be our only answer against these attacks. I believe
> that since these attacks are made possible due to the
> inherent characteristics of the tunnels they should be
> stopped intrinsically as much as possible by the tunnel
> participants and not relay on outside filtering rules.

In RFC5214, Section 10 we have: "restricting access to the
link can be achieved by restricting access to the site". The
mitigations do exactly that, and in such a way that ISATAP
nodes can operate with only the necessary and sufficient
checks. So on this point, I do not share your opinion.

Fred
 
________________________________________
From: "Templin, Fred L" <[email-masked]>
To: Gabi Nakibly <[email-masked]>; v6ops <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Monday, August 17, 2009 8:35:08 PM
Subject: RE: Routing loop attacks using IPv6 tunnels

Gabi,

 

Fred
 
________________________________________
 
Hi all,
 
Here is the abstract:
IPv6 is the future network layer protocol for the Internet. Since it is not compatible with its predecessor, some interoperability mechanisms were designed. An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 network without prior configuration. This category includes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exploit vulnerabilities in these tunnels. These attacks take advantage of inconsistencies between a tunnel's overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. We exhibit five attacks of this class. One of the presented attacks can DoS a Teredo server using a single packet. The exploited vulnerabilities are embedded in the design of the tunnels; hence any implementation of these tunnels may be vulnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 R2. 

 
Gabi

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Aug 2009 19:00:42 +0200

Hi Gabi,

First, thanks to you and your colleagues for this research, and for  
the clear presentation of its results.
In my understanding, your contribution is important for transition  
solutions to be carefully selected, and where needed improved.

This mail is to complement the analysis with what applies to 6rd.

For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is an  
automatic tunnel mechanism in actual use for IPv6 across IPv4 clouds.
With it, service providers can offer native IPv6 to their customers  
while using for this their existing IPv4 infrastructures.
Publication of the RFC that describes it, RFC 5569, has been delayed  
since May for a reason related to intellectual property rights  
applicable to independent submissions.
But the draft on which 6rd is based is still available, and a new  
draft to extend its applicability is also available:
- tools.ietf.org/html/draft-despres-6rd-03
- tools.ietf.org/html/draft-townsley-ipv6-6rd-01

(1) Case of ISPs that operate 6rd relays and no 6to4 relays (and  
neither Teredo relays nor ISP-infrastructure NATs)

In its sec. 3, draft-despres-6rd-03 says:
<<<
    The IPv4 anycast address of 6rd relays may be chosen  
independently by
    each ISP.  The only constraint is that routes toward the ISP that  
are
    advertised must not include this address.
In view of your study and in my understanding, it should be completed  
with:
"Also, the ISP must not forward toward the global IPv4 global  
Internet packets having this address as source."

With this, an ISP that operates 6rd relays but operates neither 6to4  
relays nor Teredo relays nor NATs is immune to the routing loop  
attack because:
- An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay cannot  
come back to an IPv4 interface of a 6rd relay of the same ISP: there  
is no IPv4 route back to the ISP for its 6rd anycast address.
- An IPv6 packet received from the IPv6 Internet by a 6rd relay  
cannot be sent back to the IPv4 global Internet: the source address  
of its IPv4 encapsulating packet is the 6rd anycast address, which  
prevents it from reaching the IPv4 global Internet.

Note that, if interfaces of the ISP to the IPv4 global Internet are  
already subject to ingress filtering (packets received by the global  
Internet are discarded if there is no reverse path available for  
them), the added sentence is not necessary. It is just just a double  
precaution for cases where such ingress filtering doesn't apply.

(2) Case of ISPs that operate 6rd relays AND 6to4 relays (but neither  
Teredo relays nor ISP-infrastructure NATs)

In its sec. 5 on security, draft-despres-6rd-03 says:
<<<
    o  RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd
       address that matches the IPv4 source.  The IPv6 destination must
       not start with the ISP 6rd prefix.
...
    o  RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a  
6rd
       address of the ISP.  The IPv4 destination must not be multicast,
       i.e. must not start with 224/3...

In view of your study and in my understanding, it MUST be completed  
with:
- after the first quoted paragraph:
"Furthermore, if the ISP also operates 6to4 relays that advertise on  
the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source must  
be neither the 6to4 anycast address 192.88.99.0 nor any of its  
equivalent IPv4 unicast addresses."
- after the second quoted paragraph:
"Furthermore, if the ISP also operates 6to4 relays that advertise on  
the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination  
derived from the IPv6 destination must be neither the IPv4 anycast  
address 192.88.99.0 nor any of its equivalent IPv4 unicast addresses."

With this, an ISP that operates both 6rd and 6to4 relays is also  
immune to the routing-loop attack because:
- an IPv6 packet forwarded to the global Internet by 6rd relays can  
come back to the ISP IPv4 network via one of the 6to4 relays of the  
ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source  
address is then one of a 6to4 relay, which, with the first added  
sentence, prevents it from being accepted by the 6rd relay.
- an IPv6 packet received from the IPv6 Internet by a 6rd relay  
cannot be sent back to the IPv4 global Internet via one of the 6to4  
relays: the IPv4 address derived from its IPv6 destination would have  
for this to be one of a 6to4 relays, which, with the second added  
sentence, prevents it from being forwarded by the 6rd relay.

Note: RFC 3068, where the 6to4 anycast address is introduced, says  
that "each 6to4 relay router that advertise the 6to4 anycast prefix  
MUST also provide an equivalent IPv4 unicast address". Whether this  
is really important in practice is IMHO unclear. On the other hand,  
if this MUST is dispensed with, the above security precaution can be  
implemented in 6rd relays without a need to handle a variable number  
of addresses, and to administratively configure them (with the  
associated risks of human errors).

To conclude:
- Without needing to modify 6to4 relays, ISATAP relays, and Teredo  
relays, ISPs that support 6rd and don't support 6to4 appear to be  
already protected against routing loop attacks if ingress filtering  
is operational at their interfaces to the IPv4 global Internet. With  
an additional simple precaution in 6rd relays, they can also be  
immune in the absence of such filtering.
- A necessary additional security precaution against routing-loop  
attacks is now identified for ISPs that support 6rd and that, having  
started with 6to4, wish to keep it for backward compatibility. Thanks  
again for your analysis which made it possible.

Best regards,
RD

Le 17 août 09 à 17:21, Gabi Nakibly a écrit :

> Hi all,
> I would like to draw the attention of the list to some research  
> results which my colleague and I at the National EW Research &  
> Simulation Center have recently published. The research presents a  
> class of routing loop attacks that abuses 6to4, ISATAP and Teredo.  
> The paper can be found at: http://www.usenix.org/events/woot09/tech/ 
> full_papers/nakibly.pdf
>
> Here is the abstract:
> IPv6 is the future network layer protocol for the Internet. Since  
> it is not compatible with its predecessor, some interoperability  
> mechanisms were designed. An important category of these mechanisms  
> is automatic tunnels, which enable IPv6 communication over an IPv4  
> network without prior configuration. This category includes ISATAP,  
> 6to4 and Teredo. We present a novel class of attacks that exploit  
> vulnerabilities in these tunnels. These attacks take advantage of  
> inconsistencies between a tunnel's overlay IPv6 routing state and  
> the native IPv6 routing state. The attacks form routing loops which  
> can be abused as a vehicle for traffic amplification to facilitate  
> DoS attacks. We exhibit five attacks of this class. One of the  
> presented attacks can DoS a Teredo server using a single packet.  
> The exploited vulnerabilities are embedded in the design of the  
> tunnels; hence any implementation of these tunnels may be  
> vulnerable. In particular, the attacks were tested against the  
> ISATAP, 6to4 and Teredo implementations of Windows Vista and  
> Windows Server 2008 R2.
>
> I think the results of the research warrant some corrective action.  
> If this indeed shall be the general sentiment of the list, I will  
> be happy write an appropriate I-D. The mitigation measures we  
> suggested in the paper are the best we could think of to completely  
> eliminate the problem. However they are far from perfect since they  
> would require tunnel implementations to be updated in case new  
> types of automatic tunnels are introduced.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Gabi Nakibly <[email-masked]>
Date: Wed, 19 Aug 2009 00:39:06 -0700 (PDT)

Remi,
Well, I also think that there should also be a proper check in the spec.
Notice, that there are valid cases in which looping a packet back to yourself is OK. For example, if two processes on the same host communicate with each other. However, I do think that an alert implementer of a Teredo server could avoid this loop.

Gabi

Sent: Tuesday, August 18, 2009 2:51:30 PM

vulnerable
fix

> Please let me know the results of your check on attack #4.. If you wish, I

-- 
Rémi Denis-Courmont

---

From: Gabi Nakibly <[email-masked]>
Date: Wed, 19 Aug 2009 01:49:23 -0700 (PDT)

Fred,
See my comments inline (<gn>).

Sent: Tuesday, August 18, 2009 6:48:45 PM

Now let me see that I understand Section 6.2 correctly. In attack #2, for example, I assume the ISATAP router has two physical interfaces. A site-internal IPv4 interface with an address IPisatap and a site-external IPv6 interface. I also assume that there is another border router which connects the site to the IPv4 Internet. The ISATAP router has an ISATAP interface with a single locator: (IPisatap, site-internal interface). When the ISATAP router gets an IPv6 via its external interface it will encapsulate the packet accordingly and forward it through the internal IPv4 interface. If the encapsulated packet is destined to a node outside the site then the only thing that stops it is a proto-41 filtering at the other border router of the site. Did I get this right?
</gn>

<gn>
OK. I see what you are saying here.
</gn>

Here, we have the ISATAP router in both cases sourcing a
packet from a foreign prefix. 
<gn>
Well, I do not see how this is correct. In attacks #1 and #3 the ISATAP router sources (actually forwards) an IPv6 packet with a source address having the corresponding prefix of the ISATAP tunnel. In attacks #2 and #3 the ISATAP router sources and IPv4 packet with its own IPv4 address as the source address.
</gn> 
This attack is mitigated by 
IPv6 ingress filtering which is an IPv6 security consideration
and not an ISATAP nor IPv4 security consideration. BCP
recommendations for network ingress filtering are documented
in RFC2827 and it is expected that IPv6 routers that configure
ISATAP interfaces will implement IPv6 ingress filtering
according to the BCP.
<gn>
So If my last comment is correct than I do not see how ingress filtering would help here. The only case where ingress filtering can help is in case of attack #3 when the routers reside at the same site. In that case if the attack packet (packet 0) is sent from outside the site then ingress filtering on the border of the site will drop the packet.
</gn>

<gn>
What about two ISATAP tunnels that reside on the same site like in attack #3. Do you also think that proto-41 filtering should barrier between the two tunnels within the site? 
</gn>

Fred
 
From: "Templin, Fred L" <[email-masked]>

Gabi,

 

Fred
fred.l.templin@boeing..com

Hi all,
 
Here is the abstract:

 
Gabi

Gabi,

<gn>

---

From: Gabi Nakibly <[email-masked]>
Date: Wed, 19 Aug 2009 03:12:23 -0700 (PDT)

Remi,

Gabi

From: Rémi Després <[email-masked]>
To: Gabi Nakibly <[email-masked]>
Cc: v6ops <[email-masked]>; 6man 6man <[email-masked]>; [email-masked]; Mark Townsley <[email-masked]>
Sent: Tuesday, August 18, 2009 8:00:42 PM
Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case

I must admit that this is the first time I read the spec of 6rd so forgive me if I miss something.
</gn>

(1) Case of ISPs that operate 6rd relays and no 6to4 relays (and neither Teredo relays nor ISP-infrastructure NATs)

In its sec. 3, draft-despres-6rd-03 says:
<<<
  The IPv4 anycast address of 6rd relays may be chosen independently by
  each ISP.  The only constraint is that routes toward the ISP that are
  advertised must not include this address.
In view of your study and in my understanding, it should be completed with:
"Also, the ISP must not forward toward the global IPv4 global Internet packets having this address as source."

With this, an ISP that operates 6rd relays but operates neither 6to4 relays nor Teredo relays nor NATs is immune to the routing loop attack because:
- An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay cannot come back to an IPv4 interface of a 6rd relay of the same ISP: there is no IPv4 route back to the ISP for its 6rd anycast address.
- An IPv6 packet received from the IPv6 Internet by a 6rd relay cannot be sent back to the IPv4 global Internet: the source address of its IPv4 encapsulating packet is the 6rd anycast address, which prevents it from reaching the IPv4 global Internet.

Note that, if interfaces of the ISP to the IPv4 global Internet are already subject to ingress filtering (packets received by the global Internet are discarded if there is no reverse path available for them), the added sentence is not necessary. It is just just a double precaution for cases where such ingress filtering doesn't apply.

<gn>
I agree with you that above check will work. However, I might choose another way here: the relay must make the following two checks:
1) When an IPv6 packet is received from the IPv6 Internet the 6rd relay must ensure before encapsulation that the intended IPv4 destination address belongs to one of the ISP's clients (I assume it can make this check easily). This way no IPv6 packet received from the IPv6 Internet will be relayed to a 6to4 relay (and then back to the 6rd relay through the IPv6 Internet). 
2) When an encapsulated packet is received from the IPv4 network side the 6rd relay must check that the IPv6 destination does not include its own IPv4 address. For example the IPv6 destination address must not be: 2002:<IPv4 address of 6rd relay>::/48. This will prevent the packet from ever reaching back the 6rd relay through its IPv4 interface

This way all the checks are done only at the 6rd relay and not in other IPv4 border routers of the ISP which should not be aware of the 6rd deployment.
</gn>

(2) Case of ISPs that operate 6rd relays AND 6to4 relays (but neither Teredo relays nor ISP-infrastructure NATs)

  o  RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd

In view of your study and in my understanding, it MUST be completed with:
- after the first quoted paragraph:
"Furthermore, if the ISP also operates 6to4 relays that advertise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source must be neither the 6to4 anycast address 192.88.99.0 nor any of its equivalent IPv4 unicast addresses."
- after the second quoted paragraph:
"Furthermore, if the ISP also operates 6to4 relays that advertise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination derived from the IPv6 destination must be neither the IPv4 anycast address 192.88.99.0 nor any of its equivalent IPv4 unicast addresses."

<gn>
Actually, I believe that the precautions I suggested above will work here also instead of those checks. Won't they?
In general, I think that checks performed on the destination address (IPv4 or IPv6) should be more robust than checks on a source address.
</gn>

With this, an ISP that operates both 6rd and 6to4 relays is also immune to the routing-loop attack because:
- an IPv6 packet forwarded to the global Internet by 6rd relays can come back to the ISP IPv4 network via one of the 6to4 relays of the ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source address is then one of a 6to4 relay, which, with the first added sentence, prevents it from being accepted by the 6rd relay.
- an IPv6 packet received from the IPv6 Internet by a 6rd relay cannot be sent back to the IPv4 global Internet via one of the 6to4 relays: the IPv4 address derived from its IPv6 destination would have for this to be one of a 6to4 relays, which, with the second added sentence, prevents it from being forwarded by the 6rd relay.

Note: RFC 3068, where the 6to4 anycast address is introduced, says that "each 6to4 relay router that advertise the 6to4 anycast prefix MUST also provide an equivalent IPv4 unicast address". Whether this is really important in practice is IMHO unclear. On the other hand, if this MUST is dispensed with, the above security precaution can be implemented in 6rd relays without a need to handle a variable number of addresses, and to administratively configure them (with the associated risks of human errors).

<gn>
If you do the check on the destination address you can avoid this administrative configuration altogether.
</gn>

To conclude:
- Without needing to modify 6to4 relays, ISATAP relays, and Teredo relays, ISPs that support 6rd and don't support 6to4 appear to be already protected against routing loop attacks if ingress filtering is operational at their interfaces to the IPv4 global Internet. With an additional simple precaution in 6rd relays, they can also be immune in the absence of such filtering.
<gn>
I fully agree.
</gn>
- A necessary additional security precaution against routing-loop attacks is now identified for ISPs that support 6rd and that, having started with 6to4, wish to keep it for backward compatibility. Thanks again for your analysis which made it possible.

Best regards,
RD

Le 17 août 09 à 17:21, Gabi Nakibly a écrit :

> IPv6 is the future network layer protocol for the Internet. Since it is not compatible with its predecessor, some interoperability mechanisms were designed. An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 network without prior configuration. This category includes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exploit vulnerabilities in these tunnels. These attacks take advantage of inconsistencies between a tunnel's overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. We exhibit five attacks of this class. One of the presented attacks can DoS a Teredo server using a single packet. The exploited vulnerabilities are embedded in the design of the tunnels; hence any implementation of these tunnels may be vulnerable. In particular, the attacks were
 tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 R2.

Hi Gabi,

First, thanks to you and your colleagues for this research, and for the clear presentation of its results.
In my understanding, your contribution is important for transition solutions to be carefully selected, and where needed improved.

For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is an automatic tunnel mechanism in actual use for IPv6 across IPv4 clouds.
With it, service providers can offer native IPv6 to their customers while using for this their existing IPv4 infrastructures.
Publication of the RFC that describes it, RFC 5569, has been delayed since May for a reason related to intellectual property rights applicable to independent submissions.
But the draft on which 6rd is based is still available, and a new draft to extend its applicability is also available:
- tools.ietf.org/html/draft-despres-6rd-03
- tools.ietf.org/html/draft-townsley-ipv6-6rd-01
<gn>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Aug 2009 08:16:18 -0700

Hi Gabi,

I'm sorry to have to keep turning this into plaintext,
but annotation is difficult otherwise. See below for
my responses (==>):

Sent: Wednesday, August 19, 2009 1:49 AM

Fred,

Gabi,

The RFC5214 Security Considerations makes clear the
consequences of not implementing IPv4 ingress filtering
and ip-protocol-41 filtering (i.e., a possible spooing
attack in which spurious ip-protocol-41 packets are
injected into an ISATAP link from outside). RFC5214
Section 6.2 additionally requires that an ISATAP interface's
locator set MUST NOT span multiple sites. This means that the
ISATAP interface must not decapsulate nor source ip-proto-41
packets within multiple sites, where the enterprise interior
is site #1 and the global Internet is site #2. ip-protocol-41
filtering is the way in which the ISATAP interface is
restricted to a single site. 
<gn>
Now let me see that I understand Section 6.2 correctly. In
attack #2, for example, I assume the ISATAP router has two
physical interfaces. A site-internal IPv4 interface with an
address IPisatap and a site-external IPv6 interface. I also
assume that there is another border router which connects the
site to the IPv4 Internet. The ISATAP router has an ISATAP
interface with a single locator: (IPisatap, site-internal
interface). When the ISATAP router gets an IPv6 via its
external interface it will encapsulate the packet accordingly
and forward it through the internal IPv4 interface. If the
encapsulated packet is destined to a node outside the site
then the only thing that stops it is a proto-41 filtering
at the other border router of the site. Did I get this right?
</gn>

==> In this case, yes - the ip-proto-41 filtering is at a
==> border router. I know of at least one major enterprise
==> network that does this.

==> OK.

==> There were a number of errors in what I said in my last
==> message, so let me see if I can get it right here:
==>
==> In attacks #1 and #2 there are two cases to consider. Case
==> 1 in which a border router separates the 6to4 relay from the
==> ISATAP router, and case 2 in which no border router separates
==> the 6to4 relay from the ISATAP router.
==>
==> In attack #1, we have an IPv6 packet with a local source
==> address entering the site from the outside. IPv6 ingress
==> filtering at the site border router should prevent the
==> packet from entering the site in the first place. If the
==> 6to4 relay router is outside the site then ip-proto-41
==> filtering at the border router will block the attack in
==> the first place anyway. If the relay router is *inside*
==> the site, then the IPv6 ingress filtering is the lone
==> mitigation. The end result is that the 6to4 relay should
==> really be positioned outside of the site's border routers;
==> otherwise, it could be spoofed into thinking that the
==> ISATAP router is a 6to4 router and not an ISATAP router. 
==>
==> In attack #2, we have an IPv6 packet with a foreign source
==> address being forwarded by the ISATAP router to a 6to4
==> relay, but I mis-spoke when I said that this would be a
==> case of the ISATAP router forwarding a packet with a foreign
==> source address out of the ISATAP link. For all the ISATAP
==> router knows, the 6to4 relay is just an ordinary host on
==> the ISATAP link, so the ISATAP router actually believes it
==> is forwarding the packet *into* the ISATAP link (not out of
==> it). But as in attack #1, the attack is blocked by ip-proto-41
==> filtering at the border router between the ISATAP router and
==> the 6to4 relay. If there is no border router between the ISATAP
==> router and the 6to4 relay, then we have an identical instance
==> to attack #3 which I will discuss below. But, the best
==> operational practice would again be to have the 6to4 relay
==> oriented outside of a border router that filters ip-proto-41.
==>
==> Short summary is that in attack #1, the 6to4 relay thinks it
==> is talking to a 6to4 router and not an ISATAP router. In
==> attack #2, the ISATAP router thinks it is talking to a
==> simple host on the link and not a 6to4 relay. In both cases,
==> the attacks are mitigated when there is an ip-proto-41
==> filtering border router between the ISATAP router and the
==> 6to4 relay. Oftentimes, the "border router" will be a two-
==> interface router that implements 6to4 on a site-external
==> IPv4 interface and implements ISATAP on a site-internal
==> IPv4 interface and performs ip-proto-41 filtering on packets
==> from outside the site with an IPv4 destination corresponding
==> to the ISATAP interface. I will discuss attack #3 below:

==> Correct about the IPv6 ingress filtering at the border,
==> but as with attack #2 my error in the previous message
==> was in thinking the ISATAP router A was forwarding the
==> packet *out* of the ISATAP link when in fact from the
==> ISATAP router's perspective it is forwarding the packet
==> to a simple host *inside* of the link.
==>
==> The problem here is that the ISATAP router is blindly
==> forwarding a packet to a node that it assumes is a simple
==> host on the ISATAP link without first verifying that the
==> node has demonstrated a willingness to participate as a
==> host on the link. As you have pointed out, this can lead
==> to strange scenarios when the anonymous node is a tunnel
==> router of some sort that does not participate in the
==> ISATAP link.
==>
==> It would not generally be possible for the ISATAP router
==> to check whether the IPv6 destination address is an ISATAP
==> address that embeds one of its own IPv4 addresses, because
==> when IPv4 private addresses are used the same IPv4 address
==> can (and often does) occur in multiple sites. So for example,
==> if the ISATAP router configures an IPv4 address 10.0.0.1
==> and is asked to forward an IPv6 packet with ISATAP
==> destination address 2001:DB8::0:5EFE:10.0.0.1 where the
==> IPv6 prefix is foreign, the router can't very well drop the
==> packet as this would block legitimate communications. It
==> is also not generally possible to check whether a foreign
==> link is an ISATAP link by looking for the magic token
==> "0:5EFE" as that token only has significance for ISATAP
==> links and not other link types.
==>
==> Instead, the mitigation I think makes the most sense is
==> for the ISATAP router to first verify that the node which
==> it assumes to be a simple ISATAP host has demonstrated a
==> willingness to participate in the link. That can be done
==> by having the ISATAP router first check the neighbor cache
==> when it has a packet to send to verify that there is a
==> cached entry corresponding to the destination. For nodes
==> that are willing ISATAP hosts on the link, there would
==> have been a neighbor cache entry created when the node
==> sends a Router Solicitation to the ISATAP router for the
==> purpose of discovering default router lifetimes and on-
==> link prefixes. So, the simple mitigations is for the ISATAP
==> router to forward the packet only if there is a pre-existing
==> neighbor cache entry and drop the packet otherwise. This
==> implies that the router should keep neighbor cache entires
==> for the duration of the minimum lifetime of the prefixes
==> it advertises in its Router Advertisements.  

==> I think this may be overcome by the discussion above.
==> Short story is that operational practices must be
==> employed whereby an ISATAP router is not mistaken for
==> a 6to4 router. This is through proper arrangement of
==> 6to4 router/relay interfaces outside of the site border
==> rather than inside, and ISATAP router interfaces inside
==> of the site border rather than outside. Also proper
==> ip-proto-41 filtering and IPv6 ingress filtering at
==> site borders.
==>
==> Also, when there are multiple ISATAP links within the
==> same local IPv4 routing region, an ISATAP router should
==> first verify a node's willingness to act as a host on
==> the ISATAP link before blindly sending a packet to it.
==>
==> Fred
==> [email-masked]

Fred

Gabi,

 

Fred

Hi all,
 
Here is the abstract:

 
Gabi

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Aug 2009 11:34:49 +0200

gabi,

Thanks for your quick answer.
Further remarks in line.

Le 19 août 09 à 12:12, Gabi Nakibly a écrit :

> Cc: v6ops <[email-masked]>; 6man 6man <[email-masked]>;  
> [email-masked]; Mark Townsley <[email-masked]>
> For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is  
> an automatic tunnel mechanism in actual use for IPv6 across IPv4  
> clouds.
> Publication of the RFC that describes it, RFC 5569, has been  
> delayed since May for a reason related to intellectual property  
> rights applicable to independent submissions.
> With this, an ISP that operates 6rd relays but operates neither  
> 6to4 relays nor Teredo relays nor NATs is immune to the routing  
> loop attack because:
> - An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay  
> cannot come back to an IPv4 interface of a 6rd relay of the same  
> ISP: there is no IPv4 route back to the ISP for its 6rd anycast  
> address.
> already subject to ingress filtering (packets received by the  
> global Internet are discarded if there is no reverse path available  
> for them), the added sentence is not necessary. It is just just a  
> double precaution for cases where such ingress filtering doesn't  
> apply.
> <gn>
> I agree with you that above check will work. However, I might  
> choose another way here: the relay must make the following two checks:
> 1) When an IPv6 packet is received from the IPv6 Internet the 6rd  
> relay must ensure before encapsulation that the intended IPv4  
> destination address belongs to one of the ISP's clients (I assume  
> it can make this check easily). This way no IPv6 packet received  
> from the IPv6 Internet will be relayed to a 6to4 relay (and then  
> back to the 6rd relay through the IPv6 Internet).

The problem is that this check is not easy "in general" because ISPs  
typically have their IPv4 prefixes allocated one by one as they  
increase the number of their clients.

> 2) When an encapsulated packet is received from the IPv4 network  
> side the 6rd relay must check that the IPv6 destination does not  
> include its own IPv4 address. For example the IPv6 destination  
> address must not be: 2002:<IPv4 address of 6rd relay>::/48. This  
> will prevent the packet from ever reaching back the 6rd relay  
> through its IPv4 interface

The problem is that to be general, and as you noted, this test  
depends on a knowledge of all formats used to embed IPv4 addresses in  
IPv6 addresses. When a new format is introduced, a security weakness  
therefore holds until all relays are upgraded to support it.
Besides, and more important, some formats may use _ISP dependent  
prefixes_ (and 6rd is already in this case!). These formats cannot be  
recognized by a constant code.

This being noted, I agree that, to extend applicability of 6rd relays  
to cases where ingress filtering doesn't apply, and to deal more  
simply with the case of 6rd ISPs that also operate 6to4 relays, 6rd  
relays SHOULD do as you propose:
*In 6rd relays, packets received on the IPv4 side should be discarded  
if their IPv6 destinations are 6to4 addresses containing the ISP 6rd  
anycast address.*

>
> This way all the checks are done only at the 6rd relay and not in  
> other IPv4 border routers of the ISP which should not be aware of  
> the 6rd deployment.

Note that IPv4 border routers of the ISP need not to be aware of the  
6rd in particular.
They only have to make sure that ingress filtering "in general"  
applies to packets sent toward the global Internet.
(If their downstream neighbors do ingress filtering as they should,  
these border routers have nothing specific to do. In cases where this  
isn't sure though, they should better prevent source address spoofing  
by filtering themselves source addresses for which they have no  
reverse path.)

> </gn>
>
>
> (2) Case of ISPs that operate 6rd relays AND 6to4 relays (but  
> "Furthermore, if the ISP also operates 6to4 relays that advertise  
> on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source  
> must be neither the 6to4 anycast address 192.88.99.0 nor any of its  
> "Furthermore, if the ISP also operates 6to4 relays that advertise  
> on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4  
> destination derived from the IPv6 destination must be neither the  
> IPv4 anycast address 192.88.99.0 nor any of its equivalent IPv4  
> unicast addresses."
> <gn>
> Actually, I believe that the precautions I suggested above will  
> work here also instead of those checks. Won't they?

As explained above, it would be 100% safe only if all embedded IPv4  
addresses were guaranteed to be recognized, which is not the case.

> In general, I think that checks performed on the destination  
> address (IPv4 or IPv6) should be more robust than checks on a  
> source address.

In my understanding, not always.
Each scenario has to be studied for what it is.

> relays: the IPv4 address derived from its IPv6 destination would  
> have for this to be one of a 6to4 relays, which, with the second  
> added sentence, prevents it from being forwarded by the 6rd relay.
>
> if this MUST is dispensed with, the above security precaution can  
> be implemented in 6rd relays without a need to handle a variable  
> number of addresses, and to administratively configure them (with  
> the associated risks of human errors).
>
> <gn>

Agreed for packets forwarded to the IPv6 side (see above).

Now, for packets from the IPv6 Internet, rather than checking that  
the embedded IPv4 destination has one of the ISP allocated prefixes,  
there is a better check I hadn't seen before sending the previous e- 
mail:
*In 6rd relays, packets received on the IPv6 side should be discarded  
if their source addresses are 6to4 addresses containing the ISP 6rd  
anycast address.*

The above administrative configuration is thus unnecessary, and the  
6rd relay cannot participate in a routing loop attack even if its ISP  
also operates 6to4 relays.

NOTE: As a matter of fact, a source address check can also be used to  
improve the Mitigation Measures you proposed for 6to4, ISATAP and  
Teredo relays:
*In your three forwarding conditions, it would be sufficient to add  
"or source" after each occurrence of "destination".*
Thus, each of these relays becomes protected against rooting loop  
attacks via any other 6to4, ISATAP, and Teredo relay, even if this  
relay doesn't make the new check on destination addresses.

> is operational at their interfaces to the IPv4 global Internet.  
> With an additional simple precaution in 6rd relays, they can also  
> be immune in the absence of such filtering.
> <gn>
> I fully agree.

Thanks.
Thoughts on the proposal to improve your mitigation measures?

Regards,
RD

> attacks is now identified for ISPs that support 6rd and that,  
> having started with 6to4, wish to keep it for backward  
> compatibility. Thanks again for your analysis which made it possible.
>
>
> Best regards,
> RD
>
>
>
> > I think the results of the research warrant some corrective  
> action. If this indeed shall be the general sentiment of the list,  
> I will be happy write an appropriate I-D. The mitigation measures  
> we suggested in the paper are the best we could think of to  
> completely eliminate the problem. However they are far from perfect  
> since they would require tunnel implementations to be updated in  
> case new types of automatic tunnels are introduced.
> >

---

From: Gabi Nakibly <[email-masked]>
Date: Mon, 24 Aug 2009 09:11:58 -0700 (PDT)

Remi,

Gabi

----- Original Message ----
From: Rémi Després <[email-masked]>
To: Gabi Nakibly <[email-masked]>
Cc: v6ops <[email-masked]>; 6man 6man <[email-masked]>; [email-masked]; Mark Townsley <[email-masked]>
Sent: Thursday, August 20, 2009 11:34:49 AM
Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case

gabi,

> 1) When an IPv6 packet is received from the IPv6 Internet the 6rd relay must ensure before encapsulation that the intended IPv4 destination address belongs to one of the ISP's clients (I assume it…

The problem is that this check is not easy "in general" because ISPs typically have their IPv4 prefixes allocated one by one as they increase the number of their clients.

> 2) When an encapsulated packet is received from the IPv4 network side the 6rd relay must check that the IPv6 destination does not include its own IPv4 address. For example the IPv6 destination addr…

The problem is that to be general, and as you noted, this test depends on a knowledge of all formats used to embed IPv4 addresses in IPv6 addresses. When a new format is introduced, a security weakness therefore holds until all relays are upgraded to support it.
Besides, and more important, some formats may use _ISP dependent prefixes_ (and 6rd is already in this case!). These formats cannot be recognized by a constant code.

This being noted, I agree that, to extend applicability of 6rd relays to cases where ingress filtering doesn't apply, and to deal more simply with the case of 6rd ISPs that also operate 6to4 relays, 6rd relays SHOULD do as you propose:
*In 6rd relays, packets received on the IPv4 side should be discarded if their IPv6 destinations are 6to4 addresses containing the ISP 6rd anycast address.*

> This way all the checks are done only at the 6rd relay and not in other IPv4 border routers of the ISP which should not be aware of the 6rd deployment.

Note that IPv4 border routers of the ISP need not to be aware of the 6rd in particular.
They only have to make sure that ingress filtering "in general" applies to packets sent toward the global Internet.
(If their downstream neighbors do ingress filtering as they should, these border routers have nothing specific to do. In cases where this isn't sure though, they should better prevent source address spoofing by filtering themselves source addresses for which they have no reverse path.)

<gn>
- For packets coming from the IPv6 side: if the first check I suggested of the ISP's clients is not easy, then you can instead check, as you suggested below, the IPv6 source address of the incoming packet to verify that it is not a 6to4 address containing the 6rd relay IPv4 address. This can make the check of the source address in other IPv4 border routers redundant.
- For packets coming from the IPv4 side: on second thought, if the 6rd spec already ensures that there is no IPv4 route from an external 6to4 relay to a 6rd relay, then indeed the second check I proposed is redundant. Moreover, I completely agree that this check can only eliminate routing loops with a 6to4 relay and not with relays of other types of tunnels. 
 </gn>

> Actually, I believe that the precautions I suggested above will work here also instead of those checks. Won't they?

As explained above, it would be 100% safe only if all embedded IPv4 addresses were guaranteed to be recognized, which is not the case.

Now, for packets from the IPv6 Internet, rather than checking that the embedded IPv4 destination has one of the ISP allocated prefixes, there is a better check I hadn't seen before sending the previous e-mail:
*In 6rd relays, packets received on the IPv6 side should be discarded if their source addresses are 6to4 addresses containing the ISP 6rd anycast address.*

<gn>
I fully agree.
<\gn>

The above administrative configuration is thus unnecessary, and the 6rd relay cannot participate in a routing loop attack even if its ISP also operates 6to4 relays.

NOTE: As a matter of fact, a source address check can also be used to improve the Mitigation Measures you proposed for 6to4, ISATAP and Teredo relays:
*In your three forwarding conditions, it would be sufficient to add "or source" after each occurrence of "destination".*
Thus, each of these relays becomes protected against rooting loop attacks via any other 6to4, ISATAP, and Teredo relay, even if this relay doesn't make the new check on destination addresses.

<gn>
You are right. This can add another layer of security. However, one must note that for this check to work the other relay that participates in the routing loop must indeed validate before it decapsulates a packet that its IPv4 source address corresponds to its IPv6 source address. If this is not true, then the check of the source address you noted above is useless. I am making this note, since I have encountered some implementations of 6to4 and ISATAP that does not follow their corresponding spec and do not make this validation, as they should. 
But, again, I agree that this check can be used as another layer of security.
</gn>

> </gn>
> 
> To conclude:
> - Without needing to modify 6to4 relays, ISATAP relays, and Teredo relays, ISPs that support 6rd and don't support 6to4 appear to be already protected against routing loop attacks if ingress filtering is operational at their interfaces to the IPv4 global Internet. With an additional simple precaution in 6rd relays, they can also be immune in the absence of such filtering..
> <gn>
> I fully agree.

Thanks.

Regards,
RD

> > I would like to draw the attention of the list to some research results which my colleague and I at the National EW Research & Simulation Center have recently published. The research presents a class of routing loop attacks that abuses 6to4, ISATAP and Teredo. The paper can be found at: http://www..usenix.org/events/woot09/tech/full_papers/nakibly.pdf
> >
> > Here is the abstract:

---

From: Gabi Nakibly <[email-masked]>
Date: Mon, 24 Aug 2009 09:11:58 -0700 (PDT)

Remi,

Gabi

----- Original Message ----
From: Rémi Després <[email-masked]>
To: Gabi Nakibly <[email-masked]>
Cc: v6ops <[email-masked]>; 6man 6man <[email-masked]>; [email-masked]; Mark Townsley <[email-masked]>
Sent: Thursday, August 20, 2009 11:34:49 AM
Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case

gabi,

<gn>

<gn>
I fully agree.
<\gn>

<gn>

Thanks.

Regards,
RD