[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Routing loop attacks using IPv6 tunnels

Fred, Gabi,
I didn't follow all details of this discussion, but it seems to me that the much simpler checks below are sufficient to prevent routing- loop attacks in ISATAP routers. 

ISATAP router checks:
- In an IPv6 packet received natively, the SOURCE address MUST NOT have the IPv4 address of the router itself embedded in it (neither in ISATAP nor in 6to4). - In an IPv6 packets received encapsulated in an IPv4 packet, the DESTINATION address MUST NOT have the IPv4 address of the router itself embedded in it (neither in ISATAP nor in 6to4). 

Did I miss anything?

Regards,
RD



Le 6 oct. 09 à 01:50, Templin, Fred L a écrit :


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