Re: Comments on draft-nakibly-v6ops-tunnel-loops
Gabi Nakibly <gnakibly@yahoo.com> Tue, 31 August 2010 19:49 UTC
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E70F3A6A49 for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 31 Aug 2010 12:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.963
X-Spam-Level:
X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_46=0.6]
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 Ul2pqhvcCxPX for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 31 Aug 2010 12:49:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE8723A6A08 for <v6ops-archive@lists.ietf.org>; Tue, 31 Aug 2010 12:49:10 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1OqWny-0005px-QB for v6ops-data0@psg.com; Tue, 31 Aug 2010 19:47:38 +0000
Received: from n78.bullet.mail.sp1.yahoo.com ([98.136.44.42]) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from <gnakibly@yahoo.com>) id 1OqWnr-0005pc-4n for v6ops@ops.ietf.org; Tue, 31 Aug 2010 19:47:31 +0000
Received: from [69.147.84.145] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 31 Aug 2010 19:47:30 -0000
Received: from [98.136.44.163] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 31 Aug 2010 19:47:30 -0000
Received: from [127.0.0.1] by omp604.mail.sp1.yahoo.com with NNFMP; 31 Aug 2010 19:47:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 301941.70574.bm@omp604.mail.sp1.yahoo.com
Received: (qmail 93697 invoked by uid 60001); 31 Aug 2010 19:47:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1283284050; bh=PjiOS75gtm1nypob4PPde8maNgHCatZHnZ96FBy00Ks=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W/cp31j8XRr5VPOACoZ0a0aaR0hTATlCuAVcnXhHC8Z5twR1j3CaLkDtpXV1evDIEEma/prQSrxL5n3vONroXVZMYHKo9GweSibbzUknz/RgmKW8oAyCt+x1OEY45oNJtvjZtrGFHrFRdywzCzvXxHIZzRqSKIisjM2cU9H+uI0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sWd+4xHDyP6STXs6IcJ/Ztuiik/3MVcFEuiUwBx35DQ93127SUD3xHpa1/8/Af3bHoEmOnWEtLNXDYGJHiSQlvpZxuaKTMWxLkx+OdPkpqRcp8hd6RoiMEKhzExS7vJCPFXQeJxmvzVCl/m21C5gZmgTUtXXXMlEREpff6SU8cw=;
Message-ID: <141984.91800.qm@web45509.mail.sp1.yahoo.com>
X-YMail-OSG: QfylO20VM1kaoW2kWqws9MGzhchPqJJO6JE31PrqbxTfwl5 LIk62wgc6UUTYPJg_wBCdug1ea9Fh9nQjri8qwJlFYMWH5JSAtJkT.7TuJTO 4O7zxUiFZAjLBD5yV9qYd1qb06potEDKJ4YTKvau.RqDEBJhJ78PpmEIZKZC vrBNBlS4gmc6.gFia2lzu7ZKxWSlPon8Cqz5XQJ7kNYaSQKR79rGl2IXt6tA FsScIxfnUrXzhIS9VzPX4odDVYkFWbsDVZeFVSBVLa.Ecosb0MlB39WI29YI np.KhCGqyN.2W4OWoT3a4EIk-
Received: from [85.64.216.89] by web45509.mail.sp1.yahoo.com via HTTP; Tue, 31 Aug 2010 12:47:29 PDT
X-Mailer: YahooMailRC/470 YahooMailWebService/0.8.105.279950
References: <4C71E8DC.7020005@gont.com.ar> <586778.68736.qm@web45501.mail.sp1.yahoo.com> <4C77700B.5050807@gont.com.ar>
Date: Tue, 31 Aug 2010 12:47:29 -0700
From: Gabi Nakibly <gnakibly@yahoo.com>
Subject: Re: Comments on draft-nakibly-v6ops-tunnel-loops
To: Fernando Gont <fernando@gont.com.ar>
Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>, fltemplin@acm.org
In-Reply-To: <4C77700B.5050807@gont.com.ar>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
Hi Fernando, We shall include your proposed mitigation in the draft. See our response inline. Fred & Gabi ----- Original Message ---- > From: Fernando Gont <fernando@gont.com.ar> > To: Gabi Nakibly <gnakibly@yahoo.com> > Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>; fltemplin@acm.org > Sent: Fri, August 27, 2010 10:58:03 AM > Subject: Re: Comments on draft-nakibly-v6ops-tunnel-loops > > Hi, Gabi, > > Thanks so much for your response. Please find my comments inline.... > > >> a) "Attack #1: 6to4 Relay to ISATAP Router" discussed in [USENIX09] > >> implies that an ISATAP router will receive an encapsulated IPv6 packet > >> on its *external* interface, destined to an IPv6 address that does not > >> belong to that site, but nevertheless forward it on the native IPv6 network. > >> > >> The rule here should be simple: tunneled packets should only be received > >> on the internal interface. Furthermore, ingress filtering should prevent > >> processing a packet with an *internal* src addr that was received on an > >> *external* interface. > >> > > > > We agree with your observation. However, please note that the ISATAP router >will > > not always receive the attack packet (packet #0) on its external interface. > > The packet may enter the inside network through a border router which is not >the > > ISATAP router. Let's take for example a network with two border routers. The > > first border router is an ISATAP router that borders with a native IPv6 >network > > and a second border router that borders with an IPv4 network. The attack >packet > > may enter the network through the second router and the ISATAP router may > > receive it on its *internal* interface. The rule you propose can not mitigate > > the attack in this case. > > In this scenario, the second router should be doing ingress filtering. > I'd argue that having such a scenario and not doing ingress filtering is > opening the door to lots of trouble -- not just this only issue. > > Nevertheless, it should be clarified in the I-D this possible scenario. > Because for other scenarios, the check I've mentioned would solve this > issue. > > (Note, nevertheless, that ingress filtering on the second router, plus > the check I've mentioned fix this potential problem, with no magic) > We shall note this in the draft. > > > > > >> b) "Attack #2: ISATAP Router to 6to4 Relay" > >> > >> This one implies that the ISATAP router will send a tunneled packet on > >> its *external* interface. Being ISATAP an *Intra-site* tunneling > >> protocol, this clearly shouldn't happen (but Fred Templin is certainly > >> in a much better position than me to correct me if I'm wrong). > >> > >> Both in this case and in Attack #1 above, there should never be a case > >> in which a packet is received on the external physical interface, and > >> forwarded back on that external physical interface. > > > > Similarly to the case we described above, the packet will indeed be forwarded >by > > the ISATAP router over its internal interface, but the packet will find its >way > > out through the second border router and loop will continue. > > This scenario should be clearly explained, then. -- Even then, being a > border router the ISATAP router probably knows the IP address block > that's used within the site. Therefore, it should probably filter those > packets that would need to be tunneled off-site. An ISATAP router doesn't do that by default. We suggest similar measure to this in the Neighbor Cache Check. > > But, again: it should be made clear that you're thinking about a > two-border-router scenario. > > > > >> c) Attack #3: ISATAP Router to ISATAP Router > >> > >> Same as above. > >> > > > > Same as above. > > Same as above. :-) > > > > >> d) "Attack #4: Teredo Client to NAT" > >> > >> This not only implies that a Teredo client will accept packets on its > >> Teredo interface, but also that it will forward them. Both behaviors > >> seem to be ill-advised (despite the fact that Windows allegedly > >> implements them). > >> > >> The countermeasure here is straightforward: drop packets received on the > >> Teredo interface that are not received to your nodes. Never forward > >> packets on the Teredo interface that have not originated in your own node. > >> > >> e) "E. Attack #5: Teredo Server" > >> > >> This one is probably trickier. Although one should probably argue that > >> packets received on a physical interface for a unicast address, with a > >> src addr that belongs to the host should be dropped. (such packets would > >> typically be forwarded internally). > > > > > > Regarding the last two Teredo attacks, please note that the draft does NOT > > address them. The nature of these two attacks are different from the previous > > ones, hence to make the draft more coherent and simple it only addresses > > protocol-41 tunnel-based loops. > > As to the countermeasure you proposed for attack #4, I think that it may not >be > > suitable for Teredo clients that do need to forward packets. > > Are there any of these available? For instance, does RFC 4380 support > this? - I don't think that's the case (of the top of my head, though) > RFC 4380's definition of a Teredo Client: "A node that has some access to the IPv4 Internet and wants to gain access to the IPv6 Internet." A node is a host or a router. From this we deduce that the RFC does not exclude forwarding on a Teredo client. > > > For example, a > > router that serves as a gateway to an internal IPv6 network while the >router's > > external IPv6 connectivity is achieved via Teredo. > > This setup would be really broken. If there's an IPv6 island, then the > border router of that island should be doing 6to4, or a configured > tunnel or the like. > Unless the IPv6 island is behind a NAT. > > > > However, we do agree that a > > simple countermeasure similar to the one you proposed can be devised. > > But, again, this is not related to the draft. If the list feels that these > > attacks should be addressed, suitable updates to Teredo can be proposed. If >yes, > > > I welcome any comments. > > IMHO, if you mention the attack, you should probably point a possible > way to fix this. -- although I understand that in this particular case > this would be more in the scope of 6man than v6ops. > Please note that although the draft references [USENIX09] it does not mention the Teredo attacks. > > > >> **** 5) Section 2, first para: > >> " In this section we shall denote an IPv6 address of a node reached via > >> a given tunnel by the prefix of the tunnel and the IPv4 address of > >> the node, i.e., Addr(Prefix, IPv4)." > >> > >> This seems misleading. the IPv4 address (IPv4) corresponds to the tunnel > >> end-point, and not to the node that is reachable by the given tunnel. > > > > Good point, but to be more precise the IPv4 address corresponds to an > > (IPv4) interface associated with the tunnel endpoint. The tunnel endpoint > > may associate multiple such interfaces with the tunnel endpoint, however, > > so the proposed resolution is to change "the IPv4 address" to "an IPv4 >address". > > We will change this to make it clearer. > > Looking at the text again, I realize that I looked confusion to me in > this aspect: "node reached via a given tunnel" sounded to me more like > e.g. a node in a network that was accessed through a tunnel (this > "node" was different from the node/router that was the tunnel endpoint) > -- hence the confusion. > > Again, a network diagram would be helpful here. > > > > > >> **** 7) Section 2 (nit): > >> " The source address of the packet is a T1 > >> address with Prf1 as the prefix and IP2 as the embedded IPv4 address, > >> i.e., Addr(Prf1, IP2)." > >> > >> While I do understand what you're talking about, this is the first time > >> you mention that of "embedded address". Therefore, that of "embedded > >> addresses" should be clarified/explained. > >> > > > > OK. By way of clarification, the third sentence of Section 1 will be changed >to > > > the following: > > > > "Automatic tunnels form a category of tunnels in which a > > packet's egress node's IPv4 address is embedded within the > > destination IPv6 address of the packet." > > Great. > > > > >> **** 9) Section 3.1 (meta-comment): > >> > >> See the "counter-measures" I suggested when discussing each of the > >> attack vectors above. They seem to be simpler than the ones you're > >> proposing here.... > > > > Yes, but only if it can be operationally assured that the case we described > > above is avoided. > > > > We will add these countermeasures in the draft with this reservation. > > Ok. > > > > >> **** 11) Section 3.2.1 > >> > >> This section talks about the "Neighbor Cache Check". Does such a thing > >> necessarily exist for, e.g., ISATAP? > >> > >> I guess that in the case of Teredo, you're really talking about the > >> "List of recent Teredo peers"? > > > > As mentioned above, Teredo is not addressed by the draft. > > What about ISATAP? Sorry, due to an oversight the response for the ISATAP case was not included in our last email. Here it is: RFC4861 discusses the neighbor cache wrt all IPv6 interfaces, but by implication a router may omit the neighbor cache in order to reduce state. Section 8.4 of RFC5214 says: "After address resolution, ISATAP hosts SHOULD perform an initial reachability confirmation by sending Neighbor Solicitation messages and receiving a Neighbor Advertisement message. ISATAP routers MAY perform this initial reachability confirmation, but this might not scale in all environments." This calls for the ISATAP router to maintain at least a minimal neighbor cache if it elects to perform initial reachability confirmations, so there is at least one published case in which an ISATAP router is implicitly required to maintain a neighbor cache. Section 3.2.1 simply describes a second case in which an ISATAP router is implicitly required to maintain a neighbor cache; hence, there does not seem to be a need to mention this explicitly in this document. > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > >
- Comments on draft-nakibly-v6ops-tunnel-loops Fernando Gont
- Re: Comments on draft-nakibly-v6ops-tunnel-loops Gabi Nakibly
- Re: Comments on draft-nakibly-v6ops-tunnel-loops Fernando Gont
- Re: Comments on draft-nakibly-v6ops-tunnel-loops Gabi Nakibly
- Re: Comments on draft-nakibly-v6ops-tunnel-loops Fernando Gont
- RE: Comments on draft-nakibly-v6ops-tunnel-loops Templin, Fred L
- Re: Comments on draft-nakibly-v6ops-tunnel-loops Fernando Gont