[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Routing loop attacks using IPv6 tunnels
Fred,
I guess the best way to document those checks is by an I-D that may eventually update RFC 5214.
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: Wed, October 7, 2009 7:42:07 PM
> Subject: RE: Routing loop attacks using IPv6 tunnels
>
> Gabi,
>
> > -----Original Message-----
> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]
> > Sent: Wednesday, October 07, 2009 10:16 AM
> > To: Templin, Fred L
> > Cc: v6ops
> > Subject: Re: Routing loop attacks using IPv6 tunnels
> >
> > Fred,
> > I believe the problem you are trying to address (link partitioning with two or
> more same-prefix
> > routers) is not specific to ISATAP links. Any link may suffer from this
> problem (with smaller
> > probability, perhaps).
>
> Right. At any time, an operator might unplug a cable, a backhoe
> might dig up a wiring conduit, a piece of networking gear might
> fail, etc., etc.
>
> > As I see it, if this issue was not addressed up until now for IPv6 in general,
> > then we should not try to cope with it specifically in ISATAP using special
> mechanisms or
> > restrictions.
>
> In general I agree, but as ISATAP may be applied to a wide
> variety of use cases perhaps there would be a separate
> study to be investigated in a specific use case analysis.
> But I can agree that that would be out of scope wrt what
> we are discussing here.
>
> > I think the best way to move forward is to go ahead with the three types of
> checks you described a
> > few weeks ago.
>
> How shall we document this?
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
> > Gabi
> >
> > ----- Original Message ----
> > > From: "Templin, Fred L"
> > > To: Gabi Nakibly
> > > Cc: v6ops
> > > Sent: Mon, October 5, 2009 4:50:31 PM
> > > Subject: 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"
> > > > > To: Gabi Nakibly
> > > > > Cc: v6ops
> > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >