Re: [secdir] Routing loop attacks using IPv6 tunnels
"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 28 August 2009 20:23 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CEB3A6A75; Fri, 28 Aug 2009 13:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.634
X-Spam-Level:
X-Spam-Status: No, score=-5.634 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29tGvlBFRJwx; Fri, 28 Aug 2009 13:23:40 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 207E13A6A5E; Fri, 28 Aug 2009 13:23:39 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7SKNicT027530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 13:23:44 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7SKNiE0006208; Fri, 28 Aug 2009 13:23:44 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7SKNhkh006170; Fri, 28 Aug 2009 13:23:43 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:23:43 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Aug 2009 13:23:40 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <31484.26522.qm@web45503.mail.sp1.yahoo.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Routing loop attacks using IPv6 tunnels
Thread-Index: AcooEhDsb5iTYmmfSmCH2zbFJmnM8QACX3Vw
References: <31484.26522.qm@web45503.mail.sp1.yahoo.com>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Gabi Nakibly <gnakibly@yahoo.com>, v6ops <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 28 Aug 2009 20:23:43.0525 (UTC) FILETIME=[70364D50:01CA281D]
Cc: ipv6@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2009 20:23:42 -0000
Gabi, Thanks for your continued correspondence, and see below: > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, August 28, 2009 12:02 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels > > Fred, > A quick summary of our discussion up until now: the best mitigation of most of these attacks is > indeed the proto-41 and ingress filtering on the border of the ISATAP site. If it is indeed > implemented. I assume that not all sites deploy such filtering for lack of awareness or since the > proto-41 filtering may break other tunnels the site may employ. However, I do not have hard evidence > on this. I would be happy if others on the list will refute or justify this assumption. > > If this assumption is (even partially) correct than I think that the ISATAP router should defend > itself. If there is operational assurance of filtering, then I think there is no problem. For the other cases, I am beginning to come around to your opinion. > Moreover, as I mention below the proo-41 filtering is not effective in case of attack > #3 and the attacker is internal to the site. I'll speak more on this below. > So IMHO the best way is the mitigations I suggested and > that you illustrated below in pseudo-code. OK. > See further comments inline. > > Gabi > > ----- Original Message ---- > > From: "Templin, Fred L" <Fred.L.Templin@boeing.com> > > To: Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org> > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Monday, August 24, 2009 10:04:34 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, August 24, 2009 4:44 AM > > > To: Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > 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 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. > > > > This is only true when the attacker is outside the site and proto-41 filtering is employed. If the > attacker is internal to the site then the proto-41 filtering will not help and the neighbor cache can > be poisoned. Since the ISATAP checks require that the IPv6 source embed the IPv4 source and/or the IPv4 source is a PRL router, you must be speaking here about IPv4 source address spoofing from within the site. For sites that allow intra-site source address spoofing, I think much more serious problems could manifest themselves that would be completely unrelated to ISATAP. I believe you will also find other automatic tunneling protocols besides ISATAP that operate under an assumption of no intra-site IPv4 source address spoofing. > > > 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:> > 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:> 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). > > > > Well, I am referring to any ISATAP deployment with public IPv4 addresses and no proto-41 filtering. I > imagine that in practice there are such deployments which are not the "inside-out ISATAP model" . > However, I must admit that I do not rely here on hard evidence. > > > 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 */ > > ... > > } > > > > Correct (with the correction you sent after this email). OK. > > isatap_xmt() { > > ... > > if (dst == "*::0200:5efe:192.88.99.1") > > drop_pkt(); /* attack #2 mitigation */ > > ... > > } > > This will not necessarily work, since the 6to4 relay may have a unicast address the ISATAP router may > not be aware of. The best way to mitigate attack #2 is by the 6to4 relay with a check similar to that > of attack #2 above. IMO, the second best way, as Remi suggested on another thread, is for the ISATAP > router to drop the packet if (src == 2002:<my_ipv4_addr>::*"). However, this check is useful only > when the 6to4 relay validates that the IPv6 source address corresponds to the IPv4 one (this is > in accordance with the 6to4 spec, however it does not always get implemented). If this is not true > then the attacker does not have to send the attack packet with such an address. Keeping with the philosophy of the ISATAP router defending itself, I believe it would be best to take Remi's suggestion and lay any complications at the doorstep of the 6to4 relay if it fails to adhere to the spec. Thanks - Fred fred.l.templin@boeing.com > > Does the above look right to you? And is this everything, > > or are there other scenarios we need to consider? > > > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > > Gabi > > > > > > ----- Original Message ---- > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > 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:gnakibly@yahoo.com] > > > Sent: Wednesday, August 19, 2009 1:49 AM > > > To: Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Fred, > > > See my comments inline (). > > > > > > ________________________________________ > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Tuesday, August 18, 2009 6:48:45 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Gabi, > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Tuesday, August 18, 2009 3:29 AM > > > To: Templin, Fred L; v6ops > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > 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. > > > > > > 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? > > > > > > > > > ==> 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. > > > > > > OK. I see what you are saying here. > > > > > > > > > ==> 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. > > > > > > 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. > > > > > > > > > ==> 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. > > > > > > 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. > > > > > > > > > ==> 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. > > > > > > 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? > > > > > > > > > ==> 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 > > > ==> fred.l.templin@boeing.com > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > ________________________________________ > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > 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 > > > fred.l.templin@boeing.com > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, August 17, 2009 8:21 AM > > > To: v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > 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 > > > > > > > > > > > >
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- [secdir] Routing loop attacks using IPv6 tunnels Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Rémi Denis-Courmont
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Rémi Denis-Courmont
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Rémi Després
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Rémi Després
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Rémi Després
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Christian Huitema
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Brian E Carpenter
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Brian E Carpenter
- Re: [secdir] Routing loop attacks using IPv6 tunn… Dong Zhang
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Brian E Carpenter
- Re: [secdir] Routing loop attacks using IPv6 tunn… Hesham Soliman
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Brian E Carpenter
- Re: [secdir] Routing loop attacks using IPv6 tunn… Dong Zhang
- Re: [secdir] Routing loop attacks using IPv6 tunn… Gabi Nakibly
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Dmitry Anipko
- Re: [secdir] Routing loop attacks using IPv6 tunn… Templin, Fred L
- Re: [secdir] Routing loop attacks using IPv6 tunn… Dmitry Anipko