Subject: Re: Routing loop attacks using IPv6 tunnels

From: Gabi Nakibly <[email-masked]>
Date: Thu, 1 Oct 2009 06:53:10 -0700 (PDT)

Removed the 6man and secdir mailing lists from the Cc.

Fred, see comments below.

----- Original Message ----
> From: "Templin, Fred L" <[email-masked]>
> To: Gabi Nakibly <[email-masked]>; Christian Huitema <[email-masked]>; v6ops <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> 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:[email-masked]]
> > Sent: Tuesday, September 29, 2009 3:22 AM
> > To: Templin, Fred L; Christian Huitema; v6ops
> > Cc: [email-masked]; [email-masked]
> > 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: [email-masked]; [email-masked]
> > > 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:[email-masked]]
> > > > Sent: Friday, September 11, 2009 12:59 PM
> > > > To: Templin, Fred L; Christian Huitema; v6ops
> > > > Cc: [email-masked]; [email-masked]
> > > > 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: [email-masked]; [email-masked]
> > > > > 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.

> > 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
> [email-masked]  
> 
> > > 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
> > > [email-masked]

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Oct 2009 09:49:31 -0700

Hi Gabi,

> Sent: Thursday, October 01, 2009 6:53 AM
> To: Templin, Fred L
> Cc: v6ops
> 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

---

From: Gabi Nakibly <[email-masked]>
Date: Mon, 5 Oct 2009 13:32:21 -0700 (PDT)

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 ----
> To: Gabi Nakibly <[email-masked]>
> Cc: v6ops <[email-masked]>
> Sent: Thu, October 1, 2009 6:49:31 PM
> > > Cc: "[email-masked]" ; "[email-masked]"

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Oct 2009 13:41:16 -0700

Gabi,

> Sent: Monday, October 05, 2009 1:32 PM
> To: Templin, Fred L
> Cc: v6ops
> 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

---

From: Gabi Nakibly <[email-masked]>
Date: Mon, 5 Oct 2009 14:24:11 -0700 (PDT)

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 ----
> Sent: Mon, October 5, 2009 10:41:16 PM
> > > To: Gabi Nakibly 
> > > > > > check will prevent forwarding packets by routers which the 
> destination has
> > > not
> > > > > previously sent RS to.
> > > > 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.
> > >
> > > > > >     b) A router's neighbors cache must now include at any given moment 
> all
> > > the
> > > > > active ISATAP nodes in

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Oct 2009 16:50:31 -0700

Gabi,

> Sent: Monday, October 05, 2009 2:24 PM
> To: Templin, Fred L
> Cc: v6ops
> 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

---

From: Rémi Després <[email-masked]>
Date: Tue, 6 Oct 2009 11:13:29 +0200

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 :

>>>> 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
>>>>>>>> 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()
>>>>>>>> 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
>>>>>>>>     a) AFAIK there is no minimum lifetime for an entry in a  
>>>>>>>> neighbors
>>>>> cache
>>>>>>>>>> I can not tell for sure. Why this case seems to you less  
>>>>>>>>>> plausible
>>>>> than
>>>>>>> case
>>>>>>>>> 2?
>>>>>>>>>
>>>>>>>> I agree. However, remember that the spoofed packet may also  
>>>>>>>> originate
>>> from

---

From: Gabi Nakibly <[email-masked]>
Date: Wed, 7 Oct 2009 10:15:30 -0700 (PDT)

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). 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. 

I think the best way to move forward is to go ahead with the three types of checks you described a few weeks ago.

Gabi

----- Original Message ----
> Sent: Mon, October 5, 2009 4:50:31 PM
> > > > 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
> > > > > > > > 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()
> > > > > > > > consequtive RSs from a host to a router should be no greater than 
> the
> > > the
> > > > > > > lifetime of an entry for

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Oct 2009 10:42:07 -0700

Gabi,

> Sent: Wednesday, October 07, 2009 10:16 AM
> To: Templin, Fred L
> Cc: v6ops
> 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

How shall we document this?

Thanks - Fred

---

From: Gabi Nakibly <[email-masked]>
Date: Sat, 10 Oct 2009 10:08:53 -0700 (PDT)

Fred,
I guess the best way to document those checks is by an I-D that may eventually update RFC 5214. 

Gabi

----- Original Message ----
> Sent: Wed, October 7, 2009 7:42:07 PM
> > I think the best way to move forward is to go ahead with the three types of 
> checks you described a
> > few weeks ago.
> 
> > > > 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
> > > > > > > > > >        " ISATAP nodes MAY schedule periodic Router 
> Solicitation
> > > events
> into
> > > > > > > > link. Either routers obviously may forward packets _into_ the 
> ISATAP
> > > link
> > > > > to
> > > > > > > any host. If a host will
> > > > > > > > > > 2) I remind you a comment you made in the past: for the checks 
> to
> > > > > work the
> > > > > > > > > time between two