Re: [secdir] Routing loop attacks using IPv6 tunnels

"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 11 September 2009 21:13 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 029AC3A6991; Fri, 11 Sep 2009 14:13:20 -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 JeSqlkL9aIrh; Fri, 11 Sep 2009 14:13:16 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C7F223A6A46; Fri, 11 Sep 2009 14:13:15 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8BLDqhc014094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2009 16:13:52 -0500 (CDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n8BLDql9026330; Fri, 11 Sep 2009 16:13:52 -0500 (CDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8BLDjLm026053; Fri, 11 Sep 2009 16:13:52 -0500 (CDT)
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, 11 Sep 2009 14:13:45 -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, 11 Sep 2009 14:13:44 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <309242.20809.qm@web45513.mail.sp1.yahoo.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Routing loop attacks using IPv6 tunnels
Thread-Index: AcozGkJPdACh96PHSv23xhQKVoGb8QACFT+A
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> <309242.20809.qm@web45513.mail.sp1.yahoo.com>
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>
X-OriginalArrivalTime: 11 Sep 2009 21:13:45.0593 (UTC) FILETIME=[BF5E0690:01CA3324]
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 21:13:20 -0000

Hi Gabi,

> -----Original Message-----
> From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> Sent: Friday, September 11, 2009 12:59 PM
> To: Templin, Fred L; Christian Huitema; v6ops
> Cc: ipv6@ietf.org; secdir@ietf.org
> Subject: Re: Routing loop attacks using IPv6 tunnels
> 
> Hi Fred,
> See below.
> 
> Gabi
> 
> 
> 
> ----- Original Message ----
> > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > To: Gabi Nakibly <gnakibly@yahoo.com>om>; Christian Huitema <huitema@microsoft.com>om>; 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.

OK.

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

OK, but since I sent this I began to wonder whether cases
1) and 2) should be reversed (i.e., do the 0x00:5EFE check
first). I came to believe that it almost doesn't matter
from a performance standpoint, and perhaps should be left
up to the implementer. Do you have an opinion on this? 

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

Case 3) is the case in which source address spoofing within
a private IPv4 addressing range is possible. It seems to me
that it may correspond to either a poorly managed deployment,
or one in which there are multiple administrative authorities
with diverse policies and operational practices.

The checks that Christian proposed could be used for this
scenario if possible. Otherwise, the best solution IMHO
would be to allow only routers (and not hosts) on the
virtual links. This final model would be best addressed
by VET and SEAL rather than ISATAP.

Thanks - Fred
fred.l.templin@boeing.com

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