[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Routing loop attacks using IPv6 tunnels
On first thought, setting up a synchronization mechanism of the neighbor caches at the routers does not sound, IMHO, like the best solution. It will probably add complexity and interdependence to the routers' functionality.
Maybe a good trade-off would be to first require a host to send an initial RS to every router in the PRL. Then after the host learns the advertised prefix of each router the host should continue sending RSs (or stop sending) to all routers advertising the same prefix.
----- Original Message ----
> From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> To: Gabi Nakibly <gnakibly@yahoo.com>
> Cc: v6ops <v6ops@ops.ietf.org>
> Sent: Mon, October 5, 2009 10:41:16 PM
> Subject: RE: Routing loop attacks using IPv6 tunnels
>
> Gabi,
>
> > -----Original Message-----
> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> > Sent: Monday, October 05, 2009 1:32 PM
> > To: Templin, Fred L
> > Cc: v6ops
> > Subject: Re: Routing loop attacks using IPv6 tunnels
> >
> > Fred,
> > With regrad to your comment below: if indeed an ISATAP router will not
> forward packets to an
> > ISATAP host it has not recently received RS from, then I think that the ISATAP
> specification
> > should at least require an ISATAP host (using a SHOULD) to regularly send RSs
> to _all_ routers in the
> > PRL, or else ISATAP connectivity may be broken.
>
> Yes, "ping them all" is certainly one way to ensure a nbr
> cache entry at each PRL router. I was also starting to
> think that another solution would be for PRL routers that
> advertise a shared IP prefx (e.g., 2001:DB8::/64) to
> somehow synchronize their neighbor caches. For that
> matter, it might be best to do both because you can
> never tell which subset of the PRLs is the correct
> subset to ping.
>
> Fred
> fred.l.templin@boeing.com
>
> > Gabi
> >
> > ----- Original Message ----
> > > From: "Templin, Fred L"
> > > To: Gabi Nakibly
> > > Cc: v6ops
> > > Sent: Thu, October 1, 2009 6:49:31 PM
> > > Subject: 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"
> > > > > To: Gabi Nakibly ; Christian Huitema
> > > ; v6ops
> > > >
> > > > > Cc: "ipv6@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
> >
> >
> >
> >