Fred, See my comments inline (<gn>).
________________________________ From: "Templin, Fred L" <fred.l.temp...@boeing.com> To: Gabi Nakibly <gnaki...@yahoo.com>; v6ops <v6...@ops.ietf.org> Cc: ipv6@ietf.org; sec...@ietf.org Sent: Tuesday, August 18, 2009 6:48:45 PM Subject: RE: Routing loop attacks using IPv6 tunnels 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> > 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> > 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> 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> > 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> Fred fred.l.temp...@boeing.com ________________________________________ From: "Templin, Fred L" <fred..l.temp...@boeing.com> To: Gabi Nakibly <gnaki...@yahoo.com>; v6ops <v6...@ops.ietf.org> Cc: ipv6@ietf.org; sec...@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.temp...@boeing..com ________________________________________ From: Gabi Nakibly [mailto:gnaki...@yahoo.com] Sent: Monday, August 17, 2009 8:21 AM To: v6ops Cc: ipv6@ietf.org; sec...@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 Gabi, ________________________________________ From: Gabi Nakibly [mailto:gnaki...@yahoo.com] Sent: Tuesday, August 18, 2009 3:29 AM To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; sec...@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. <gn>
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
