[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Routing loop attacks using IPv6 tunnels
Gabi,
> -----Original Message-----
> From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> Sent: Monday, October 05, 2009 2:24 PM
> To: Templin, Fred L
> Cc: v6ops
> Subject: 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.
I understand what you're saying, but here's the temptation.
Lets say that ISATAP routers A and B both advertise prefix
P::/64, then the ISATAP site partitions and the only way
A and B can still talk to each other is via the provider
network. The temptation part is that if A and B talk to
each other over the provider network then they can keep
track of the ISATAP hosts in each partition that configure
an address from P::/64 and seemingly can "heal" the
partition by forwarding misdirected packets to each other
across the provider network. But then, we are guilty of
"conspiracy to create a multilink subnet" (see RFC4903
for multi-link subnet issues).
This suggests that, if multiple ISATAP routers are to
advertise a shared prefix P::/64, then there either needs
to be strong assurance that the site won't partition. If
that condition cannot be met, then each ISATAP router must
advertise a distinct prefix. Do you see any other way?
Fred
fred.l.templin@boeing.com
> ----- 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
> > >
> > >
> > >
> > >
>
>
>
>