[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Routing loop attacks using IPv6 tunnels
Removed the 6man and secdir mailing lists from the Cc.
Fred, see comments below.
----- 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" <ipv6@ietf.org>; "secdir@ietf.org" <secdir@ietf.org>
> Sent: Tuesday, September 29, 2009 6:00:55 PM
> Subject: RE: Routing loop attacks using IPv6 tunnels
>
> 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"
> > > To: Gabi Nakibly ; Christian Huitema
> ; v6ops
> >
> > > 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.
>
I was thinking of a case of two routers in the PRL advertising the same prefix for the ISATAP link. Either routers obviously may forward packets _into_ the ISATAP link to any host. If a host will not send a RS to one of those routers then it will drop packets destined to that host.
> > 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.
>
OK.
> > 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.
>
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:")
> > > > > 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.
I agree again. I was referring to the case where SEND is not deployed.
> 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
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com