Re: [secdir] Routing loop attacks using IPv6 tunnels

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 29 September 2009 15:59 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 324CE3A67B2; Tue, 29 Sep 2009 08:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.774
X-Spam-Level:
X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.225, 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 qC+RP9dlYPs1; Tue, 29 Sep 2009 08:59:41 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id D3A3F3A6876; Tue, 29 Sep 2009 08:59:41 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8TG10Jr019029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 09:01:00 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n8TG106u000669; Tue, 29 Sep 2009 09:01:00 -0700 (PDT)
Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8TG0xx2000648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 29 Sep 2009 09:01:00 -0700 (PDT)
Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 29 Sep 2009 09:01:00 -0700
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>
Date: Tue, 29 Sep 2009 09:00:55 -0700
Thread-Topic: Routing loop attacks using IPv6 tunnels
Thread-Index: AcpA7y32SMKrSr8oQ9Se74wYt9GJGQAKrYtw
Message-ID: <12F4112206976147A34FEC0277597CCF27A40BB33C@XCH-NW-15V.nw.nos.boeing.com>
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> <39C363776A4E8C4A94691D2BD9D1C9A106624B24@XCH-NW-7V2.nw.nos.boeing.com> <165333.98948.qm@web45503.mail.sp1.yahoo.com>
In-Reply-To: <165333.98948.qm@web45503.mail.sp1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "secdir@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: Tue, 29 Sep 2009 15:59:43 -0000

Gabi,

Welcome back from your vacation. I trimmed quite a bit from
the bottom of this message to eliminate the clutter, but see
below for responses to your current comments:

> -----Original Message-----
> From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> Sent: Tuesday, September 29, 2009 3:22 AM
> To: Templin, Fred L; Christian Huitema; v6ops
> Cc: ipv6@ietf.org; secdir@ietf.org
> Subject: Re: Routing loop attacks using IPv6 tunnels
> 
> Hi Fred,
> Back from vacation. See Comments inlines.
> 
> 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: Friday, September 11, 2009 11:13:44 PM
> > Subject: RE: Routing loop attacks using IPv6 tunnels
> >
> > 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"
> > > > To: Gabi Nakibly ; Christian Huitema
> > ; v6ops
> > >
> > > > 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.
> >
> 
> On second thought, a couple of comments:
> 1) According to RFC 5214 Section 8.3.4:
>        " ISATAP nodes MAY schedule periodic Router Solicitation events
>        for certain PRL(i)s by setting the corresponding TIMER(i)."
> As I understand, this means that there is a possibility for a host not to send RSs to all routers in
> the PRL. However, any router in the PRL may forward packets into the ISATAP link. The isatap_xmt()
> check will prevent forwarding packets by routers which the destination has not previously sent RS to.
> If I am correct then this check may break ISATAP connectivity.

I don't think this is a problem. If a host has not sent an RS to
a PRL router, then it should not have configured a default route
nor any prefix information specific to that router. Therefore,
the only packets the host and router should expect to exchange
in this state are link-local. As such, the router can discard
non-link-local packets if there is no neighbor cache entry. 
 
> 2) I remind you a comment you made in the past: for the checks to work the time between two
> consequtive RSs from a host to a router should be no greater than the the lifetime of an entry for
> that host in the router's neighbors cache. This is needed to ensure that the entry in the neighbors
> cache will not be erased. This raises two questions:
>     a) AFAIK there is no minimum lifetime for an entry in a neighbors cache - it is an implementation
> detail. If this is true how can we enforce the above constraint?

Correct that there is no minimum lifetime for neighbor cache
entries specified by RFC4861. However, an ISATAP router that
uses the neighbor cache checking procedures I have described
can use its own discipline for managing its neighbor cache.
Exactly such a discipline is now specified in Section 5.4.1
of 'draft-templin-intarea-vet'. Please be aware that ISATAP
and VET are simply "IPv6-over-(foo)" specifications, and
RFC4861 permits that operations of the neighbor discovery
protocol that are specific to (foo) links may be specified
in such documents.

>     b) A router's neighbors cache must now include at any given moment all the active ISATAP nodes in
> the ISATAP link. Is this a reasonable demand?

Memory should be cheap enough, and ISATAP links within private
addressing realms should be small enough, that I do not see this
as an unreasonable demand.

> > > > 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:")
> > > >       drop_pkt();
> > > >     ...
> > > >   }
> > > >
> > > >   isatap_xmt() {
> > > >     ...
> > > >     if (v6src == "foreign_prefix::0200:5efe:")
> > > >       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.
> >
> 
> I agree. However, remember that the spoofed packet may also originate from within the site, which is
> very hard to defend against.

Spoofing is not so hard to defend against if Secure Neighbor
Discovery (SEND) is used to set up the neighbor relationships
and if every packet carries a nonce that can be used to detect
an off-path attack. That is only the case for VET and SEAL,
however, so if source address spoofing within the site is seen
as a problem then VET and SEAL should be used instead of ISATAP.

Note that for the sake of consistency it might be helpful to
consider VET as simply "ISATAP version 2 (ISATAPv2)".

Fred
fred.l.templin@boeing.com  
 
> > 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