Re: [secdir] Routing loop attacks using IPv6 tunnels

Gabi Nakibly <gnakibly@yahoo.com> Fri, 11 September 2009 19:58 UTC

Return-Path: <gnakibly@yahoo.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 6A9B428C12B for <secdir@core3.amsl.com>; Fri, 11 Sep 2009 12:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.584
X-Spam-Level:
X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, J_CHICKENPOX_13=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 MWa3PYGGDXg6 for <secdir@core3.amsl.com>; Fri, 11 Sep 2009 12:57:58 -0700 (PDT)
Received: from web45513.mail.sp1.yahoo.com (web45513.mail.sp1.yahoo.com [68.180.197.161]) by core3.amsl.com (Postfix) with SMTP id C0A4528C127 for <secdir@ietf.org>; Fri, 11 Sep 2009 12:57:58 -0700 (PDT)
Received: (qmail 21799 invoked by uid 60001); 11 Sep 2009 19:58:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252699115; bh=Rp50sF8vWhlTxFfz42TXbar5Fx+5ho5W2U7wTqISTUA=; 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=yO0kv152b25d/XNN1EQA/4WZXkfgNj9Ol9AtrX+xChpNp2Y0TgwwsMSQROqyYWrrTznDlWpBsDerNUULtqqD9gpgL4/Nq40hwHjGZKUI5dCfyzStpdd0W0n/rxe9Kulj8eQ1CGHmaup7B+xi0l3cyqM6sA0Fa2dqL5k0LTm0oW0=
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=181jso2+ayHEZd0pMyJt6p2ynu8r2iPcjtdaxoiFNGgEu7VT/XtJc9rzzfj71TdnsoLhCZdRqrYam7Ncnbo7rVEeV3ZwLRKY7hSB3N2nMJXD9dhOzZfDjnXY+bTvtQL7hscOp8IikAuw5kSlWMkqvDk9Ezo5ryb8ez62T0oTZK0=;
Message-ID: <309242.20809.qm@web45513.mail.sp1.yahoo.com>
X-YMail-OSG: .LdW.OcVM1lQkCwce97nr.zdXJjI6nTB7_StXZs9x6JSEJjeR8nXoOf0O1QlWaoDvN_tPwta12vyCnPC291u1K8fSiaayki7VldlCLu1tEfiMm3H5iKIO_.jIhbx7AVVJFIwaQX0r12AvmIw7qwnPwDv60O0BsNga8y.N7pyT.8AOq6OPWFCVwDSyDr3qfk_FjdjupjshYZaM7Xm.iFGrLsY7cRTMjtDJVHowMe3VWyXJFkbpapczckNe5DyiurtQdf1sXKS
Received: from [89.138.115.145] by web45513.mail.sp1.yahoo.com via HTTP; Fri, 11 Sep 2009 12:58:35 PDT
X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.338.2
References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> <373420.97768.qm@web45509.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106599177@XCH-NW-7V2.nw.nos.boeing.com> <342868.34354.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D7CB7@XCH-NW-7V2.nw.nos.boeing.com> <6B55F0F93C3E9D45AF283313B8D342BA0440F47F@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <702481.50824.qm@web45515.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com>
Date: Fri, 11 Sep 2009 12:58:35 -0700 (PDT)
From: Gabi Nakibly <gnakibly@yahoo.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Christian Huitema <huitema@microsoft.com>, v6ops <v6ops@ops.ietf.org>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065D80A0@XCH-NW-7V2.nw.nos.boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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, 11 Sep 2009 19:58:02 -0000

Hi Fred,
See below.

Gabi



----- Original Message ----
> From: "Templin, Fred L" <Fred.L.Templin@boeing.com>;
> To: Gabi Nakibly <gnakibly@yahoo.com>;; Christian Huitema <huitema@microsoft.com>;; v6ops <v6ops@ops.ietf.org>;
> Cc: ipv6@ietf.org; secdir@ietf.org
> Sent: Tuesday, September 8, 2009 8:37:03 PM
> Subject: RE: Routing loop attacks using IPv6 tunnels
> 
> Gabi and Christian,
> 
> Focusing only on attack #3 (i.e., leaving out attack #1
> and #2 6to4 interactions for the moment), please check
> the following summary of proposed mitigations:
> 
> 1) For ISATAP/VET routers that have assurance that their
> neighbor cache is coherent, the router can make a simple
> check in the neighbor cache to determine whether to
> forward or drop the packet. In pseudo-code:
> 
>   isatap_rcv() {
>     ...
>     if ((v6src is not a neighbor) && (v6dst != "fe80::*"))
>       drop_pkt();
>     ...
>   }
> 
>   isatap_xmt() {
>     ...
>     if ((v6dst is not a neighbor) && (v6src != "fe80::*"))
>       drop_pkt();
>     ...
>   }
> 
> (Here, the link-local exception is necessary to bootstrap
> neighbor discovery on the ISATAP link.)
> 
> Does anyone see a problem with this?
> 
Looks fine. 

> 2) For ISATAP/VET routers that use public IPv4 addresses
> and that do not have assurance that their neighbor cache
> is coherent, the router can check for the interface ID
> "0200:5EFE:". In pseudo-code:
> 
>   isatap_rcv() {
>     ...
>     if (v6dst == "foreign_prefix::0200:5efe:<my_IPv4_addr>")
>       drop_pkt();
>     ...
>   }
> 
>   isatap_xmt() {
>     ...
>     if (v6src == "foreign_prefix::0200:5efe:<my_IPv4_addr>")
>       drop_pkt();
>     ...
>   }
> 
> Does anyone see a problem with this?
 
Looks fine.
 
> 
> 3) For ISATAP/VET routers that use private IPv4 addresses
> and that do not have assurance that their neighbor cache
> is coherent, the router can make the checks that Christian
> has proposed. But, will we see any of these case 3)
> situations in operational practice?
> 
 
I can not tell for sure. Why this case seems to you less plausible than case 2?

> I would also like to point out that the attack vectors only
> occur when the ISATAP/VET router mistakes the other tunnel
> endpoint for a host when in fact the other end is another
> router. Mitigations for router-to-router ingress filtering
> are already specified in VET.
> 
> Comments?
> 
> Fred
> fred.l.templin@boeing.com
> 
> 
> > -----Original Message-----
> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> > Sent: Tuesday, September 08, 2009 5:28 AM
> > To: Christian Huitema; Templin, Fred L; v6ops
> > Cc: ipv6@ietf.org; secdir@ietf.org
> > Subject: Re: Routing loop attacks using IPv6 tunnels
> > 
> > Hi Christian,
> > Thanks for your comments.
> > 
> > 
> > The checks you suggested are powerful and will indeed mitigate the attacks. 
> The only thing that
> > worries me is the fact that usually AFAIK the ISATAP router is not configured 
> with the IPv4 subnet
> > addresses of the site. This means that the router must now be configured with 
> this information and
> > reconfigured as this information changes. If this is felt to be a reasonable 
> administrative overhead,
> > then I think the checks should be employed.
> > 
> > One minor thing that should be noted is that these checks will not mitigate 
> the attacks in case there
> > are two ISATAP links (with two separate routers) in the same site. This 
> means that their sets of
> > registered subnets coincide. I assume that such deployment are not common, 
> although I do not have the
> > information to back this assumption.
> > 
> > Gabi
> > 
> > 
> > ----- Original Message ----
> > > From: Christian Huitema 
> > > To: "Templin, Fred L" ; Gabi Nakibly 
> ; v6ops
> > 
> > > Cc: "ipv6@ietf.org"; ; "secdir@ietf.org"; 
> > > Sent: Friday, September 4, 2009 10:25:21 PM
> > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > >
> > > I think that there is another possible way to protect against these attacks, 
> if
> > > the ISATAP router limits the range of IPv4 addresses towards which it is 
> willing
> > > to relay packets. That would fit many current deployments, maybe most.
> > >
> > > In many current deployments, ISATAP is used to provide IPv6 connectivity 
> inside
> > > a "site", typically protected by a firewall. The expected behavior is that 
> hosts
> > > in that site will use direct ISATAP connectivity to exchange packets with 
> each
> > > other, and will use the ISATAP router to exchange packets with other IPv6
> > > subnets.
> > >
> > > Assume that the site is defined by a set of IPv4 subnets, and the ISATAP 
> router
> > > knows that list. The basic check in the ISATAP router is thus:
> > >
> > >         On incoming packet:
> > >                 If IPv6 source belongs to local ISATAP subnet (matches 
> /64 prefix):
> > >                         If (IPv4 source does not match last 32 bits of 
> IPv6 source): drop;
> > >                         Else If (IPv4 source does not belong to one 
> of registered subnets): drop;
> > >                         Else relay; // we may or may not want to add 
> a destination check
> > >                 Else
> > >                         If (IPv4 source belongs to one of registered 
> subnets): drop;
> > >                         Else if (IPv6 destination does not match ISATAP 
> subnet): drop;
> > >                         Else if (embedded IPv4 address does not belong to 
> of registered subnets):
> > drop;
> > >                         Else relay;
> > >
> > > Written that way, the ISATAP router cannot create a loop, because packets 
> always
> > > go either from site to elsewhere, or from elsewhere to site.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of 
> Templin,
> > > Fred L
> > > Sent: Friday, September 04, 2009 1:01 PM
> > > To: Gabi Nakibly; v6ops
> > > Cc: ipv6@ietf.org; secdir@ietf.org
> > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > >
> > > Gabi,
> > >
> > > I'd like to make one other observation about these checks we
> > > have been discussing. There seems to be an implication that
> > > there needs to be a check on all of the IPv4 addresses assigned
> > > to the node's IPv4 interfaces, and with ISATAP there could be
> > > multiple underlying IPv4 interfaces over which the ISATAP
> > > interface is configured. So, that would seem like a potential
> > > performance issue if there were multiple IPv4 addresses to
> > > check for every packet.
> > >
> > > But, if the ISATAP router configures only a single IPv4 address
> > > and places it on the ISATAP interface (i.e., leaving all of the
> > > underlying IPv4 interfaces with only a link-local address) then
> > > there is only one IPv4 address to check. The technique is called:
> > > "link-layer multiplexing" and is described for ISATAP/VET in
> > > Appendix B of 'draft-templin-intarea-vet'. But, the idea really
> > > came from Section 3.3.4 of RFC1122.
> > >
> > > Thanks - Fred
> > > fred.l.templin@boeing.com
> > >
> > > > -----Original Message-----
> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> > > > Sent: Thursday, September 03, 2009 8:00 AM
> > > > To: Templin, Fred L; v6ops
> > > > Cc: ipv6@ietf.org; secdir@ietf.org
> > > > Subject: Re: Routing loop attacks using IPv6 tunnels
> > > >
> > > > Hi Fred,
> > > > see inline.
> > > >
> > > > Gabi
> > > >
> > > > ----- Original Message ----
> > > > > From: "Templin, Fred L"
> > > > > To: Gabi Nakibly ; v6ops
> > > > > Cc: ipv6@ietf.org; secdir@ietf.org
> > > > > Sent: Tuesday, September 1, 2009 6:49:56 PM
> > > > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > > > >
> > > > > Gabi,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> > > > > > Sent: Monday, August 31, 2009 12:41 PM
> > > > > > To: Templin, Fred L; v6ops
> > > > > > Cc: ipv6@ietf.org; secdir@ietf.org
> > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels
> > > > > >
> > > > > > Fred,
> > > > > >
> > > > > > I agree that the source address check discussed below should be made. 
> I
> > > would
> > > > > also add a forth
> > > > > > check to mitigate attack #3 as a second layer of defense in case the
> > > opposite
> > > > > ISATAP router does not
> > > > > > make the proper check on the destination address.
> > > > > >
> > > > > > isatap_xmt() {
> > > > > >      ...
> > > > > >      if (src == "::0200:5efe:")
> > > > > >        drop_pkt(); /* attack #3 mitigation */
> > > > > >      ...
> > > > > >  }
> > > > >
> > > > > Having thought about it a bit, I agree but for ISATAP I see
> > > > > the source address check as a MAY and the destination address
> > > > > check as a SHOULD.
> > > >
> > > > Why do you think so? As I see it, the two checks mitigate two different
> > > attacks. The destination
> > > > address check defends the ISATAP router against attacks of type 3 in which 
> it
> > > acts as
> > > > the decapsulator of the attack packet.  While, the source address check
> > > defends the ISATAP
> > > > router against attacks of type 3 in which it acts as the ecapsulator of 
> the
> > > attack packet.  Either of
> > > > these checks are redundant if the other one is employed by the opposite 
> router
> > > of the attack. So I do
> > > > not see why one of them is a SHOULD and the other is a MAY.
> > > >
> > > > >
> > > > > In new automatic tunneling protocol specifications that use a
> > > > > different encapsulation format than ip-proto-41, as long as
> > > > > we make the destination address check a MUST before anything
> > > > > gets deployed then the source address check is unnecessary
> > > > >
> > > >
> > > > In principle, I agree with you. However, I am a believer of the "defense 
> in
> > > depth" paradigm: two
> > > > layers of security are (usually) better than one. Since no one can be
> > > absolutely sure that the
> > > > destination address check shall always be implemented correctly at all 
> other
> > > routers then it may seem
> > > > prudent to also employ the source check as a second layer of defense.
> > > >
> > > > > 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: Friday, August 28, 2009 11:23:40 PM
> > > > > > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > > > > > >
> > > > > > > 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"
> > > > > > > > > To: Gabi Nakibly ; v6ops
> > > > > > > > > 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:::*")
> > > > > > > > >      drop_pkt(); /* attack #1 mitigation */
> > > > > > > > >
> > > > > > > > >    if (dst == "*::0200:5efe:")
> > > > > > > > >    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:::*"). 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > 
> > 
> > 
> >