[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Routing loop attacks using IPv6 tunnels
Hi Gabi,
> -----Original Message-----
> From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> Sent: Thursday, October 01, 2009 6:53 AM
> To: Templin, Fred L
> Cc: v6ops
> Subject: 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.
I'm actually OK with that. If two routers A and B advertise
the same prefix P, and if B doesn't know about host H either
through receiving RSs or through talking to A, then B should
not forward packets to H.
Thanks - Fred
fred.l.templin@boeing.com
> > > 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