[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
Gabi
----- Original Message ----
> From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> To: Gabi Nakibly <gnakibly@yahoo.com>
> Cc: v6ops <v6ops@ops.ietf.org>
> 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