Subject: Re: Routing loop attacks using IPv6 tunnels

From: Gabi Nakibly <[email-masked]>
Date: Mon, 24 Aug 2009 04:43:57 -0700 (PDT)

Fred,
I initially very much liked your suggestion regarding the check of the neighbor cache before forwarding a packet into the tunnel. It truly addresses the root cause of the problem ans is simple enough to implement. However, I realized that an attacker can send a spoofed RS to the ISATAP router as if it came from the 6to4 relay. The router would then send a RA to it and consequently change its neighbor cache. So it seems that this defense does not add much. Wouldn't you agree? 
 
I completely agree with your observation on the non-feasibility of verifying that the destination ISATAP address does not include a local IPv4 address since the ISATAP address may include a private IPv4 address. On the other hand, a check on public IPv4 addresses is acceptable. If the check would be done only on ISATAP addresses that include public IPv4 addresses then this will eliminate the attacks in which the two victims reside at different sites. Note that if attack #3 is launched on two ISATAP routers having private addresses at two different sites then the attack will not work anyway since one router can not send a direct IPv4 packet to the other. In addition, to mitigate attacks in which the other victim is a 6to4 relay (such as attack #1) then a check would have to be done on a 6to4 address, i.e. the destination address must not be "2002:<IPv4 address of the ISATAP router>::*". In this case the IPv4 address must be public, according to
 the 6to4 spec.
 
As you also noted there is another problem with this check since the string "200::5EFE" is not unique to ISATAP links. On the other hand, it seems that the probability to encounter a non-malicious packet with a destination address having an IID that equals "200:5EFE:<my own public IPv4 address>" is pretty slim.
 
This check is definitely not a perfect solution, and I sure hope that someone will come up with a better one for mitigating the routing loops. However, I would be happy if there is some kind of other mitigation measures besides packet filtering (proto-41 and ingress) by other nodes (which does not necessarily exist). 
 
Gabi
 
----- Original Message ----
From: "Templin, Fred L" <[email-masked]>
To: Gabi Nakibly <[email-masked]>; v6ops <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Wednesday, August 19, 2009 6:16:18 PM
Subject: RE: Routing loop attacks using IPv6 tunnels

Hi Gabi,

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

________________________________________
From: Gabi Nakibly [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2009 1:49 AM
To: Templin, Fred L; v6ops
Cc: [email-masked]; [email-masked]
Subject: Re: Routing loop attacks using IPv6 tunnels

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

________________________________________
From: "Templin, Fred L" <[email-masked]>
To: Gabi Nakibly <[email-masked]>; v6ops <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Tuesday, August 18, 2009 6:48:45 PM
Subject: RE: Routing loop attacks using IPv6 tunnels

Gabi,

________________________________________
From: Gabi Nakibly [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2009 3:29 AM
To: Templin, Fred L; v6ops
> Cc: [email-masked]; [email-masked]
> Subject: Re: Routing loop attacks using IPv6 tunnels
> 
> 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. 
<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.

> 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.
<gn>
OK. I see what you are saying here.
</gn>

==> OK.

> 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. 
<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>

==> 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:
   
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>

==> 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.  

> 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.
<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>

==> 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
[email-masked]
 
________________________________________
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,
 
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,
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: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Aug 2009 13:04:34 -0700

Gabi,

> -----Original Message-----
> Sent: Monday, August 24, 2009 4:44 AM
> I initially very much liked your suggestion regarding the check of the neighbor cache before
> forwarding a packet into the tunnel. It truly addresses the root cause of the problem ans is simple
> enough to implement. However, I realized that an attacker can send a spoofed RS to the ISATAP router
> as if it came from the 6to4 relay. The router would then send a RA to it and consequently change its
> neighbor cache. So it seems that this defense does not add much. Wouldn't you agree?

I agree that my proposed mitigation is only useful when there
is assurance of a coherent neighbor cache in the ISATAP router.
That would be true in the case in which the ISATAP router is
located within a site protected by border routers that perform
ip-proto-41 and ingress filtering, and in which there is no
untraceable IPv4 source address spoofing. So AFAICT, my proposed
mitigation is still necessary for preventing attack #3 when
ISATAP routers A and B are on separate ISATAP links within
the same site-internal IPv4 routing region.

> I completely agree with your observation on the non-feasibility of verifying that the
> destination ISATAP address does not include a local IPv4 address since the ISATAP address may include
> a private IPv4 address. On the other hand, a check on public IPv4 addresses is acceptable. If the
> check would be done only on ISATAP addresses that include public IPv4 addresses then this will
> eliminate the attacks in which the two victims reside at different sites. Note that if attack #3 is
> launched on two ISATAP routers having private addresses at two different sites then the attack will
> not work anyway since one router can not send a direct IPv4 packet to the other. In addition,
> to mitigate attacks in which the other victim is a 6to4 relay (such as attack #1) then a check would
> have to be done on a 6to4 address, i.e. the destination address must not be "2002:<IPv4 address of
> the ISATAP router>::*". In this case the IPv4 address must be public, according to
>  the 6to4 spec.
> 
> As you also noted there is another problem with this check since the string "200::5EFE" is not unique
> to ISATAP links. On the other hand, it seems that the probability to encounter a non-malicious packet
> with a destination address having an IID that equals "200:5EFE:<my own public IPv4 address>" is
> pretty slim.
> 
> This check is definitely not a perfect solution, and I sure hope that someone will come up with a
> better one for mitigating the routing loops. However, I would be happy if there is some kind of other
> mitigation measures besides packet filtering (proto-41 and ingress) by other nodes (which does not
> necessarily exist).

You seem to be envisioning a scenario of ISATAP router operation
with public IPv4 addresses and outside of any site border routers
that perform ingress filtering and ip-proto-41 filtering. That has
traditionally been seen as the domain of 6to4, but I am happy to
discuss the possibility of what I called the "inside-out ISATAP
model" in a list message long ago (which AFAICT is the scenario
you are alluding to).

So, if the public IPv4 Internet were considered as one gigantic
"site" and we wanted to do ISATAP on that site, it would be nice
to divide the site into multiple logical partitions, with each
partition identified by a PRL name and a unique set of IPv6
prefixes. But then, we have the scenario you are describing in
which we can't trust the integrity of the ISATAP router's
neighbor cache due to the possibility for untraceable IPv4
source address spoofing such that the neighbor cache check
mitigation can be subverted.

This means that if we want to support the inside-out ISATAP
model then the routing loops could be mitigated either by
1) implementing the destination address checks you are
suggesting, or 2) by not allowing ISATAP router interfaces
that are not behind filtering border routers to advertise
non-link-local on-link IPv6 prefixes and/or forward packets
from non-link-local prefixes in the first place.

If we took the easy way out and did 2), then the entire
IPv4 Internet would look like one gigantic ISATAP link that
only did IPv6 link-local. So, nodes could ping6 each others'
ISATAP link-local addresses but that's about it. 

If we took the more ambitious route and allowed ISATAP to
flourish fully within the global IPv4 Internet, then we
would essentially be deprecating 6to4 - so it isn't
surprising that your address checks mostly involve 6to4
suppression. Assuming this, if I read your attack scenarios
1 through 3 correctly then scenarios 1 and 3 are mitigated
by a receive-side check and scenario 2 is mitigated by a
send-side check. In particular, the pseudo-code would be:

  isatap_rcv() {
    ...
    if (dst == "2002:<my_ipv4_addr>::*")
      drop_pkt(); /* attack #1 mitigation */

    if (dst == "*::0200:5efe:<my_ipv4_addr>")
	drop_pkt(); /* attack #3 mitigation */
    ...
  }

  isatap_xmt() {
    ...
    if (dst == "*::0200:5efe:192.88.99.1")
      drop_pkt(); /* attack #2 mitigation */
    ...
  }

Does the above look right to you? And is this everything,
or are there other scenarios we need to consider?

Thanks - Fred

> 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>
> 
> 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>
> 
> 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>
> 
> 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
> 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: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Aug 2009 13:53:00 -0700

> 	  drop_pkt(); /* attack #3 mitigation */

should be:

  if (dst == "<foreign_prefix>::0200:5efe:<my_ipv4_addr>")
    drop_pkt(); /* attack #3 mitigation */

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Aug 2009 09:23:03 -0700

Gabi,

Correct me if I am wrong, but if there were a new version
of ISATAP that did not use ip-proto-41 encapsulation but
instead used a different kind of encapsulation, then it
need not concern itself with routing loop interactions
with 6to4 relays since 6to4 relays only know about
ip-proto-41. Does that match your understanding? 

Thanks - Fred

---

From: Gabi Nakibly <[email-masked]>
Date: Fri, 28 Aug 2009 12:07:03 -0700 (PDT)

Correct. All the attacks rely on the fact that the ISATAP router encapsulates/decapsulates a packet the 6to4 relay decapsulates/encapsulates, respectively. So the two tunnels must have the same encapsulation type.

----- Original Message ----
> Sent: Friday, August 28, 2009 7:23:03 PM

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Aug 2009 13:25:23 -0700

Gabi,

> Sent: Friday, August 28, 2009 12:07 PM
> Correct. All the attacks rely on the fact that the ISATAP router
encapsulates/decapsulates a packet
> the 6to4 relay decapsulates/encapsulates, respectively. So the two
tunnels must have the same
> encapsulation type.

OK. That will greatly simplify the checks needed for new
automatic tunneling protocols that have a format other
than ip-proto-41.

Fred