Subject: RE: Routing loop attacks using IPv6 tunnels

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 1 Sep 2009 09:49:56 -0700

Gabi,

> -----Original Message-----
> From: Gabi Nakibly [mailto:[email-masked]]
> Sent: Monday, August 31, 2009 12:41 PM
> To: Templin, Fred L; v6ops
> Cc: [email-masked]; [email-masked]
> Subject: Re: Routing loop attacks using IPv6 tunnels
> 
> Fred,
> 
> I agree that the source address check discussed below should be made. I would also add a forth
> check to mitigate attack #3 as a second layer of defense in case the opposite ISATAP router does not
> make the proper check on the destination address.
> 
> isatap_xmt() {
>      ...
>      if (src == "<foreign prefix>::0200:5efe:<my IP address>")
>        drop_pkt(); /* attack #3 mitigation */
>      ...
>  }

Having thought about it a bit, I agree but for ISATAP I see
the source address check as a MAY and the destination address
check as a SHOULD.

In new automatic tunneling protocol specifications that use a
different encapsulation format than ip-proto-41, as long as
we make the destination address check a MUST before anything
gets deployed then the source address check is unnecessary

Fred
[email-masked]
 
> 
> Gabi
> 
> ----- Original Message ----
> > From: "Templin, Fred L" <[email-masked]>
> > To: Gabi Nakibly <[email-masked]>; v6ops <[email-masked]>
> > Cc: [email-masked]; [email-masked]
> > Sent: Friday, August 28, 2009 11:23:40 PM
> > Subject: RE: Routing loop attacks using IPv6 tunnels
> >
> > Gabi,
> >
> > Thanks for your continued correspondence, and see below:
> >
> > > -----Original Message-----
> > > From: Gabi Nakibly [mailto:[email-masked]]
> > > Sent: Friday, August 28, 2009 12:02 PM
> > > To: Templin, Fred L; v6ops
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Routing loop attacks using IPv6 tunnels
> > >
> > > Fred,
> > > A quick summary of our discussion up until now: the best mitigation of most of
> > these attacks is
> > > indeed the proto-41 and ingress filtering on the border of the ISATAP site. If
> > it is indeed
> > > implemented. I assume that not all sites deploy such filtering for lack of
> > awareness or since the
> > > proto-41 filtering may break other tunnels the site may employ. However, I do
> > not have hard evidence
> > > on this. I would be happy if others on the list will refute or justify this
> > assumption.
> > >
> > > If this assumption is (even partially) correct than I think that the ISATAP
> > router should defend
> > > itself.
> >
> > If there is operational assurance of filtering, then I think there
> > is no problem. For the other cases, I am beginning to come around
> > to your opinion.
> >
> > > Moreover, as I mention below the proo-41 filtering is not effective in case of
> > attack
> > > #3 and the attacker is internal to the site.
> >
> > I'll speak more on this below.
> >
> > > So IMHO the best way is the mitigations I suggested and
> > > that you illustrated below in pseudo-code.
> >
> > OK.
> >
> > > See further comments inline.
> > >
> > > Gabi
> > >
> > > ----- Original Message ----
> > > > From: "Templin, Fred L"
> > > > To: Gabi Nakibly ; v6ops
> > > > Cc: [email-masked]; [email-masked]
> > > > Sent: Monday, August 24, 2009 10:04:34 PM
> > > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > > >
> > > > Gabi,
> > > >
> > > > > -----Original Message-----
> > > > > From: Gabi Nakibly [mailto:[email-masked]]
> > > > > Sent: Monday, August 24, 2009 4:44 AM
> > > > > To: Templin, Fred L; v6ops
> > > > > Cc: [email-masked]; [email-masked]
> > > > > Subject: Re: Routing loop attacks using IPv6 tunnels
> > > > >
> > > > > Fred,
> > > > > I initially very much liked your suggestion regarding the check of the
> > > > neighbor cache before
> > > > > forwarding a packet into the tunnel. It truly addresses the root cause of
> > the
> > > > problem ans is simple
> > > > > enough to implement. However, I realized that an attacker can send a
> > > > spoofed RS to the ISATAP router
> > > > > as if it came from the 6to4 relay. The router would then send a RA to
> > it and
> > > > consequently change its
> > > > > neighbor cache. So it seems that this defense does not add much. Wouldn't
> > you
> > > > agree?
> > > >
> > > > I agree that my proposed mitigation is only useful when there
> > > > is assurance of a coherent neighbor cache in the ISATAP router.
> > > > That would be true in the case in which the ISATAP router is
> > > > located within a site protected by border routers that perform
> > > > ip-proto-41 and ingress filtering, and in which there is no
> > > > untraceable IPv4 source address spoofing. So AFAICT, my proposed
> > > > mitigation is still necessary for preventing attack #3 when
> > > > ISATAP routers A and B are on separate ISATAP links within
> > > > the same site-internal IPv4 routing region.
> > > >
> > >
> > > This is only true when the attacker is outside the site and proto-41 filtering
> > is employed. If the
> > > attacker is internal to the site then the proto-41 filtering will not help and
> > the neighbor cache can
> > > be poisoned.
> >
> > Since the ISATAP checks require that the IPv6 source embed the
> > IPv4 source and/or the IPv4 source is a PRL router, you must be
> > speaking here about IPv4 source address spoofing from within the
> > site. For sites that allow intra-site source address spoofing,
> > I think much more serious problems could manifest themselves
> > that would be completely unrelated to ISATAP. I believe you
> > will also find other automatic tunneling protocols besides
> > ISATAP that operate under an assumption of no intra-site IPv4
> > source address spoofing.
> >
> > > > > I completely agree with your observation on the non-feasibility of
> > > > verifying that the
> > > > > destination ISATAP address does not include a local IPv4 address since the
> > > > ISATAP address may include
> > > > > a private IPv4 address. On the other hand, a check on public IPv4
> > addresses is
> > > > acceptable. If the
> > > > > check would be done only on ISATAP addresses that include public IPv4
> > > > addresses then this will
> > > > > eliminate the attacks in which the two victims reside at different sites.
> > Note
> > > > that if attack #3 is
> > > > > launched on two ISATAP routers having private addresses at two different
> > sites
> > > > then the attack will
> > > > > not work anyway since one router can not send a direct IPv4 packet to the
> > > > other. In addition,
> > > > > to mitigate attacks in which the other victim is a 6to4 relay (such as
> > attack
> > > > #1) then a check would
> > > > > have to be done on a 6to4 address, i.e. the destination address must not
> > be
> > > > "2002:> > the ISATAP router>::*". In this case the IPv4 address must be
> > public,
> > > > according to
> > > > >  the 6to4 spec.
> > > > >
> > > > > As you also noted there is another problem with this check since the
> > string
> > > > "200::5EFE" is not unique
> > > > > to ISATAP links. On the other hand, it seems that the probability to
> > encounter
> > > > a non-malicious packet
> > > > > with a destination address having an IID that equals "200:5EFE:> IPv4
> > address>" is
> > > > > pretty slim.
> > > > >
> > > > > This check is definitely not a perfect solution, and I sure hope that
> > someone
> > > > will come up with a
> > > > > better one for mitigating the routing loops. However, I would be happy if
> > > > there is some kind of other
> > > > > mitigation measures besides packet filtering (proto-41 and ingress)
> > by other
> > > > nodes (which does not
> > > > > necessarily exist).
> > > >
> > > > You seem to be envisioning a scenario of ISATAP router operation
> > > > with public IPv4 addresses and outside of any site border routers
> > > > that perform ingress filtering and ip-proto-41 filtering. That has
> > > > traditionally been seen as the domain of 6to4, but I am happy to
> > > > discuss the possibility of what I called the "inside-out ISATAP
> > > > model" in a list message long ago (which AFAICT is the scenario
> > > > you are alluding to).
> > > >
> > >
> > > Well, I am referring to any ISATAP deployment with public IPv4 addresses and
> > no proto-41 filtering. I
> > > imagine that in practice there are such deployments which are not the
> > "inside-out ISATAP model" .
> > > However, I must admit that I do not rely here on hard evidence.
> > >
> > > > So, if the public IPv4 Internet were considered as one gigantic
> > > > "site" and we wanted to do ISATAP on that site, it would be nice
> > > > to divide the site into multiple logical partitions, with each
> > > > partition identified by a PRL name and a unique set of IPv6
> > > > prefixes. But then, we have the scenario you are describing in
> > > > which we can't trust the integrity of the ISATAP router's
> > > > neighbor cache due to the possibility for untraceable IPv4
> > > > source address spoofing such that the neighbor cache check
> > > > mitigation can be subverted.
> > > >
> > > > This means that if we want to support the inside-out ISATAP
> > > > model then the routing loops could be mitigated either by
> > > > 1) implementing the destination address checks you are
> > > > suggesting, or 2) by not allowing ISATAP router interfaces
> > > > that are not behind filtering border routers to advertise
> > > > non-link-local on-link IPv6 prefixes and/or forward packets
> > > > from non-link-local prefixes in the first place.
> > > >
> > > > If we took the easy way out and did 2), then the entire
> > > > IPv4 Internet would look like one gigantic ISATAP link that
> > > > only did IPv6 link-local. So, nodes could ping6 each others'
> > > > ISATAP link-local addresses but that's about it.
> > > >
> > > > If we took the more ambitious route and allowed ISATAP to
> > > > flourish fully within the global IPv4 Internet, then we
> > > > would essentially be deprecating 6to4 - so it isn't
> > > > surprising that your address checks mostly involve 6to4
> > > > suppression. Assuming this, if I read your attack scenarios
> > > > 1 through 3 correctly then scenarios 1 and 3 are mitigated
> > > > by a receive-side check and scenario 2 is mitigated by a
> > > > send-side check. In particular, the pseudo-code would be:
> > > >
> > > >   isatap_rcv() {
> > > >     ...
> > > >     if (dst == "2002:::*")
> > > >       drop_pkt(); /* attack #1 mitigation */
> > > >
> > > >     if (dst == "*::0200:5efe:")
> > > >     drop_pkt(); /* attack #3 mitigation */
> > > >     ...
> > > >   }
> > > >
> > >
> > > Correct (with the correction you sent after this email).
> >
> > OK.
> >
> > > >   isatap_xmt() {
> > > >     ...
> > > >     if (dst == "*::0200:5efe:192.88.99.1")
> > > >       drop_pkt(); /* attack #2 mitigation */
> > > >     ...
> > > >   }
> > >
> > > This will not necessarily work, since the 6to4 relay may have a unicast
> > address the ISATAP router may
> > > not be aware of. The best way to mitigate attack #2 is by the 6to4 relay with
> > a check similar to that
> > > of attack #2 above. IMO, the second best way, as Remi suggested on another
> > thread, is for the ISATAP
> > > router to drop the packet if (src  == 2002:::*"). However, this
> > check is useful only
> > > when the 6to4 relay validates that the IPv6 source address corresponds to the
> > IPv4 one (this is
> > > in accordance with the 6to4 spec, however it does not always get implemented).
> > If this is not true
> > > then the attacker does not have to send the attack packet with such an
> > address.
> >
> > Keeping with the philosophy of the ISATAP router defending itself,
> > I believe it would be best to take Remi's suggestion and lay any
> > complications at the doorstep of the 6to4 relay if it fails to
> > adhere to the spec.
> >
> > Thanks - Fred
> > [email-masked]
> >
> > > > Does the above look right to you? And is this everything,
> > > > or are there other scenarios we need to consider?
> > > >
> > >
> > >
> > > > Thanks - Fred
> > > > [email-masked]
> > > >
> > > > >
> > > > > Gabi
> > > > >
> > > > > ----- Original Message ----
> > > > > From: "Templin, Fred L"
> > > > > To: Gabi Nakibly ; v6ops
> > > > > Cc: [email-masked]; [email-masked]
> > > > > Sent: Wednesday, August 19, 2009 6:16:18 PM
> > > > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > > > >
> > > > > Hi Gabi,
> > > > >
> > > > > I'm sorry to have to keep turning this into plaintext,
> > > > > but annotation is difficult otherwise. See below for
> > > > > my responses (==>):
> > > > >
> > > > > ________________________________________
> > > > > From: Gabi Nakibly [mailto:[email-masked]]
> > > > > Sent: Wednesday, August 19, 2009 1:49 AM
> > > > > To: Templin, Fred L; v6ops
> > > > > Cc: [email-masked]; [email-masked]
> > > > > Subject: Re: Routing loop attacks using IPv6 tunnels
> > > > >
> > > > > Fred,
> > > > > See my comments inline ().
> > > > >
> > > > > ________________________________________
> > > > > From: "Templin, Fred L"
> > > > > To: Gabi Nakibly ; v6ops
> > > > > Cc: [email-masked]; [email-masked]
> > > > > Sent: Tuesday, August 18, 2009 6:48:45 PM
> > > > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > > > >
> > > > > Gabi,
> > > > >
> > > > > ________________________________________
> > > > > From: Gabi Nakibly [mailto:[email-masked]]
> > > > > Sent: Tuesday, August 18, 2009 3:29 AM
> > > > > To: Templin, Fred L; v6ops
> > > > > > Cc: [email-masked]; [email-masked]
> > > > > > Subject: Re: Routing loop attacks using IPv6 tunnels
> > > > > >
> > > > > > Indeed the ISATAP interface of the ISATAP router is meant
> > > > > > to be an enterprise-interior (note that it is still assumed
> > > > > > that the associated IPv4 address is non-private). As we
> > > > > > explicitly note in the paper, the first three attacks will
> > > > > > be mitigated if proper protocol-41 filtering is deployed on
> > > > > > the site's border. However, note that RFC5214 does not mandate
> > > > > > or require this filtering.
> > > > >
> > > > > The RFC5214 Security Considerations makes clear the
> > > > > consequences of not implementing IPv4 ingress filtering
> > > > > and ip-protocol-41 filtering (i.e., a possible spooing
> > > > > attack in which spurious ip-protocol-41 packets are
> > > > > injected into an ISATAP link from outside). RFC5214
> > > > > Section 6.2 additionally requires that an ISATAP interface's
> > > > > locator set MUST NOT span multiple sites. This means that the
> > > > > ISATAP interface must not decapsulate nor source ip-proto-41
> > > > > packets within multiple sites, where the enterprise interior
> > > > > is site #1 and the global Internet is site #2. ip-protocol-41
> > > > > filtering is the way in which the ISATAP interface is
> > > > > restricted to a single site.
> > > > >
> > > > > Now let me see that I understand Section 6.2 correctly. In
> > > > > attack #2, for example, I assume the ISATAP router has two
> > > > > physical interfaces. A site-internal IPv4 interface with an
> > > > > address IPisatap and a site-external IPv6 interface. I also
> > > > > assume that there is another border router which connects the
> > > > > site to the IPv4 Internet. The ISATAP router has an ISATAP
> > > > > interface with a single locator: (IPisatap, site-internal
> > > > > interface). When the ISATAP router gets an IPv6 via its
> > > > > external interface it will encapsulate the packet accordingly
> > > > > and forward it through the internal IPv4 interface. If the
> > > > > encapsulated packet is destined to a node outside the site
> > > > > then the only thing that stops it is a proto-41 filtering
> > > > > at the other border router of the site. Did I get this right?
> > > > >
> > > > >
> > > > > ==> In this case, yes - the ip-proto-41 filtering is at a
> > > > > ==> border router. I know of at least one major enterprise
> > > > > ==> network that does this.
> > > > >
> > > > > > It is only mentioned as a possible mitigation against
> > > > > > incoming spurious protocol-41 packets. In addition,
> > > > > > Section 10 of RFC5214 only mentions ingress not egress
> > > > > > filtering. Hence it will not stop attack #2.
> > > > >
> > > > > We are now talking about ip-proto-41 filtering; not ingress
> > > > > filtering. ip-proto-41 filtering is in both directions. It
> > > > > prevents ip-proto-41 packets from entering the enterprise
> > > > > interior ISATAP site from the Internet and prevents
> > > > > ip-proto-41 packets from entering the Internet ISATAP
> > > > > site from the enterprise interior. Else the ISATAP
> > > > > interface would span multiple sites.
> > > > >
> > > > > Besides, "ingress" filtering is not about packets coming
> > > > > from the Internet into the end site, but rather it is
> > > > > about packets leaving the end site and going out into
> > > > > the Internet. RFC2827 (BCP38) documents ingress filtering.
> > > > >
> > > > > OK. I see what you are saying here.
> > > > >
> > > > >
> > > > > ==> OK.
> > > > >
> > > > > > In addition,
> > > > > > as mentioned, protocol-41 filtering is not helpful when
> > > > > > attack #3 is launched on two routers that reside in the
> > > > > > same site. Note that it may be possible for the attack
> > > > > > packet to be sourced from outside the site unless proper
> > > > > > filtering of incoming IPv6 packets is deployed. If the
> > > > > > attacker resides in the site, usually ingress filtering
> > > > > > will not be helpful since it is deployed in general on
> > > > > > the site's border.
> > > > >
> > > > > Here, we have the ISATAP router in both cases sourcing a
> > > > > packet from a foreign prefix.
> > > > >
> > > > > Well, I do not see how this is correct. In attacks #1 and #3 the ISATAP
> > router
> > > > sources (actually
> > > > > forwards) an IPv6 packet with a source address having the
> > corresponding prefix
> > > > of the ISATAP tunnel.
> > > > > In attacks #2 and #3 the ISATAP router sources and IPv4 packet with its
> > own
> > > > IPv4 address as the
> > > > > source address.
> > > > >
> > > > >
> > > > > ==> There were a number of errors in what I said in my last
> > > > > ==> message, so let me see if I can get it right here:
> > > > > ==>
> > > > > ==> In attacks #1 and #2 there are two cases to consider. Case
> > > > > ==> 1 in which a border router separates the 6to4 relay from the
> > > > > ==> ISATAP router, and case 2 in which no border router separates
> > > > > ==> the 6to4 relay from the ISATAP router.
> > > > > ==>
> > > > > ==> In attack #1, we have an IPv6 packet with a local source
> > > > > ==> address entering the site from the outside. IPv6 ingress
> > > > > ==> filtering at the site border router should prevent the
> > > > > ==> packet from entering the site in the first place. If the
> > > > > ==> 6to4 relay router is outside the site then ip-proto-41
> > > > > ==> filtering at the border router will block the attack in
> > > > > ==> the first place anyway. If the relay router is *inside*
> > > > > ==> the site, then the IPv6 ingress filtering is the lone
> > > > > ==> mitigation. The end result is that the 6to4 relay should
> > > > > ==> really be positioned outside of the site's border routers;
> > > > > ==> otherwise, it could be spoofed into thinking that the
> > > > > ==> ISATAP router is a 6to4 router and not an ISATAP router.
> > > > > ==>
> > > > > ==> In attack #2, we have an IPv6 packet with a foreign source
> > > > > ==> address being forwarded by the ISATAP router to a 6to4
> > > > > ==> relay, but I mis-spoke when I said that this would be a
> > > > > ==> case of the ISATAP router forwarding a packet with a foreign
> > > > > ==> source address out of the ISATAP link. For all the ISATAP
> > > > > ==> router knows, the 6to4 relay is just an ordinary host on
> > > > > ==> the ISATAP link, so the ISATAP router actually believes it
> > > > > ==> is forwarding the packet *into* the ISATAP link (not out of
> > > > > ==> it). But as in attack #1, the attack is blocked by ip-proto-41
> > > > > ==> filtering at the border router between the ISATAP router and
> > > > > ==> the 6to4 relay. If there is no border router between the ISATAP
> > > > > ==> router and the 6to4 relay, then we have an identical instance
> > > > > ==> to attack #3 which I will discuss below. But, the best
> > > > > ==> operational practice would again be to have the 6to4 relay
> > > > > ==> oriented outside of a border router that filters ip-proto-41.
> > > > > ==>
> > > > > ==> Short summary is that in attack #1, the 6to4 relay thinks it
> > > > > ==> is talking to a 6to4 router and not an ISATAP router. In
> > > > > ==> attack #2, the ISATAP router thinks it is talking to a
> > > > > ==> simple host on the link and not a 6to4 relay. In both cases,
> > > > > ==> the attacks are mitigated when there is an ip-proto-41
> > > > > ==> filtering border router between the ISATAP router and the
> > > > > ==> 6to4 relay. Oftentimes, the "border router" will be a two-
> > > > > ==> interface router that implements 6to4 on a site-external
> > > > > ==> IPv4 interface and implements ISATAP on a site-internal
> > > > > ==> IPv4 interface and performs ip-proto-41 filtering on packets
> > > > > ==> from outside the site with an IPv4 destination corresponding
> > > > > ==> to the ISATAP interface. I will discuss attack #3 below:
> > > > >
> > > > > This attack is mitigated by
> > > > > IPv6 ingress filtering which is an IPv6 security consideration
> > > > > and not an ISATAP nor IPv4 security consideration. BCP
> > > > > recommendations for network ingress filtering are documented
> > > > > in RFC2827 and it is expected that IPv6 routers that configure
> > > > > ISATAP interfaces will implement IPv6 ingress filtering
> > > > > according to the BCP.
> > > > >
> > > > > So If my last comment is correct than I do not see how ingress filtering
> > would
> > > > help here. The only
> > > > > case where ingress filtering can help is in case of attack #3 when the
> > routers
> > > > reside at the same
> > > > > site. In that case if the attack packet (packet 0) is sent from outside
> > the
> > > > site then ingress
> > > > > filtering on the border of the site will drop the packet.
> > > > >
> > > > >
> > > > > ==> Correct about the IPv6 ingress filtering at the border,
> > > > > ==> but as with attack #2 my error in the previous message
> > > > > ==> was in thinking the ISATAP router A was forwarding the
> > > > > ==> packet *out* of the ISATAP link when in fact from the
> > > > > ==> ISATAP router's perspective it is forwarding the packet
> > > > > ==> to a simple host *inside* of the link.
> > > > > ==>
> > > > > ==> The problem here is that the ISATAP router is blindly
> > > > > ==> forwarding a packet to a node that it assumes is a simple
> > > > > ==> host on the ISATAP link without first verifying that the
> > > > > ==> node has demonstrated a willingness to participate as a
> > > > > ==> host on the link. As you have pointed out, this can lead
> > > > > ==> to strange scenarios when the anonymous node is a tunnel
> > > > > ==> router of some sort that does not participate in the
> > > > > ==> ISATAP link.
> > > > > ==>
> > > > > ==> It would not generally be possible for the ISATAP router
> > > > > ==> to check whether the IPv6 destination address is an ISATAP
> > > > > ==> address that embeds one of its own IPv4 addresses, because
> > > > > ==> when IPv4 private addresses are used the same IPv4 address
> > > > > ==> can (and often does) occur in multiple sites. So for example,
> > > > > ==> if the ISATAP router configures an IPv4 address 10.0.0.1
> > > > > ==> and is asked to forward an IPv6 packet with ISATAP
> > > > > ==> destination address 2001:DB8::0:5EFE:10.0.0.1 where the
> > > > > ==> IPv6 prefix is foreign, the router can't very well drop the
> > > > > ==> packet as this would block legitimate communications. It
> > > > > ==> is also not generally possible to check whether a foreign
> > > > > ==> link is an ISATAP link by looking for the magic token
> > > > > ==> "0:5EFE" as that token only has significance for ISATAP
> > > > > ==> links and not other link types.
> > > > > ==>
> > > > > ==> Instead, the mitigation I think makes the most sense is
> > > > > ==> for the ISATAP router to first verify that the node which
> > > > > ==> it assumes to be a simple ISATAP host has demonstrated a
> > > > > ==> willingness to participate in the link. That can be done
> > > > > ==> by having the ISATAP router first check the neighbor cache
> > > > > ==> when it has a packet to send to verify that there is a
> > > > > ==> cached entry corresponding to the destination. For nodes
> > > > > ==> that are willing ISATAP hosts on the link, there would
> > > > > ==> have been a neighbor cache entry created when the node
> > > > > ==> sends a Router Solicitation to the ISATAP router for the
> > > > > ==> purpose of discovering default router lifetimes and on-
> > > > > ==> link prefixes. So, the simple mitigations is for the ISATAP
> > > > > ==> router to forward the packet only if there is a pre-existing
> > > > > ==> neighbor cache entry and drop the packet otherwise. This
> > > > > ==> implies that the router should keep neighbor cache entires
> > > > > ==> for the duration of the minimum lifetime of the prefixes
> > > > > ==> it advertises in its Router Advertisements.
> > > > >
> > > > > > In general, I would like to point out that indeed as in
> > > > > > most other attacks these attacks may also be mitigated by
> > > > > > proper firewall rules. However, I do not believe that this
> > > > > > should be our only answer against these attacks. I believe
> > > > > > that since these attacks are made possible due to the
> > > > > > inherent characteristics of the tunnels they should be
> > > > > > stopped intrinsically as much as possible by the tunnel
> > > > > > participants and not relay on outside filtering rules.
> > > > >
> > > > > In RFC5214, Section 10 we have: "restricting access to the
> > > > > link can be achieved by restricting access to the site". The
> > > > > mitigations do exactly that, and in such a way that ISATAP
> > > > > nodes can operate with only the necessary and sufficient
> > > > > checks. So on this point, I do not share your opinion.
> > > > >
> > > > > What about two ISATAP tunnels that reside on the same site like in attack
> > #3.
> > > > Do you also think that
> > > > > proto-41 filtering should barrier between the two tunnels within the site?
> > > > >
> > > > >
> > > > > ==> I think this may be overcome by the discussion above.
> > > > > ==> Short story is that operational practices must be
> > > > > ==> employed whereby an ISATAP router is not mistaken for
> > > > > ==> a 6to4 router. This is through proper arrangement of
> > > > > ==> 6to4 router/relay interfaces outside of the site border
> > > > > ==> rather than inside, and ISATAP router interfaces inside
> > > > > ==> of the site border rather than outside. Also proper
> > > > > ==> ip-proto-41 filtering and IPv6 ingress filtering at
> > > > > ==> site borders.
> > > > > ==>
> > > > > ==> Also, when there are multiple ISATAP links within the
> > > > > ==> same local IPv4 routing region, an ISATAP router should
> > > > > ==> first verify a node's willingness to act as a host on
> > > > > ==> the ISATAP link before blindly sending a packet to it.
> > > > > ==>
> > > > > ==> Fred
> > > > > ==> [email-masked]
> > > > >
> > > > > Fred
> > > > > [email-masked]
> > > > >
> > > > > ________________________________________
> > > > > From: "Templin, Fred L"
> > > > > To: Gabi Nakibly ; v6ops
> > > > > Cc: [email-masked]; [email-masked]
> > > > > Sent: Monday, August 17, 2009 8:35:08 PM
> > > > > Subject: RE: Routing loop attacks using IPv6 tunnels
> > > > >
> > > > >
> > > > > Gabi,
> > > > >
> > > > > Thanks for publishing this work. In the document, attacks A, B and C
> > > > > correspond to a configuration that violates section 6.2 of RFC5214:
> > > > >
> > > > > > 6.2.  ISATAP Interface Address Configuration
> > > > > >
> > > > > >   Each ISATAP interface configures a set of locators consisting of IPv4
> > > > > >   address-to-interface mappings from a single site; i.e., an ISATAP
> > > > > >   interface's locator set MUST NOT span multiple sites.
> > > > >
> > > > > In particular, in scenarios A, B and C the IPv4 locator used for ISATAP
> > > > > is seen both within the enterprise as site #1 and within the global
> > Internet
> > > > > itself as site #2. If the ISATAP interface is to be used as an enterprise-
> > > > > interior interface, it should therefore not accept IP-proto-41 packets
> > > > > coming from an IPv4 source outside of the enterprise nor source
> > > > > IP-proto-41 packets that are destined to an IPv4 node outside of the
> > > > > enterprise. This condition should be satisfied by having the site border
> > > > > routers implement IPv4 ingress filtering and ip-protocol-41 filtering as
> > > > > required in Section 10 of RFC5214.
> > > > >
> > > > > It is mentioned that attack C could also occur when the routers reside
> > > > > in the same site, where their addresses may be private. This would
> > > > > correspond to a case in which an attacker within the site attacks the
> > > > > site itself, which can easily be traced - especially when source address
> > > > > spoofing from a node within the site is prevented through proper ingress
> > > > > filtering.
> > > > >
> > > > > Fred
> > > > > [email-masked]
> > > > >
> > > > > ________________________________________
> > > > > From: Gabi Nakibly [mailto:[email-masked]]
> > > > > Sent: Monday, August 17, 2009 8:21 AM
> > > > > To: v6ops
> > > > > Cc: [email-masked]; [email-masked]
> > > > > Subject: Routing loop attacks using IPv6 tunnels
> > > > >
> > > > > Hi all,
> > > > > I would like to draw the attention of the list to some research results
> > which
> > > > my colleague and I at
> > > > > the National EW Research & Simulation Center have recently published. The
> > > > research presents a class
> > > > > of routing loop attacks that abuses 6to4, ISATAP and Teredo. The paper can
> > be
> > > > found at:
> > > > > http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf
> > > > >
> > > > > Here is the abstract:
> > > > > IPv6 is the future network layer protocol for the Internet. Since it is
> > not
> > > > compatible with its
> > > > > predecessor, some interoperability mechanisms were designed. An important
> > > > category of these
> > > > > mechanisms is automatic tunnels, which enable IPv6 communication over an
> > IPv4
> > > > network without prior
> > > > > configuration. This category includes ISATAP, 6to4 and Teredo. We present
> > a
> > > > novel class of attacks
> > > > > that exploit vulnerabilities in these tunnels. These attacks take
> > advantage of
> > > > inconsistencies
> > > > > between a tunnel's overlay IPv6 routing state and the native IPv6 routing
> > > > state. The attacks form
> > > > > routing loops which can be abused as a vehicle for traffic amplification
> > to
> > > > facilitate DoS attacks.
> > > > > We exhibit five attacks of this class. One of the presented attacks can
> > DoS a
> > > > Teredo server using a
> > > > > single packet. The exploited vulnerabilities are embedded in the design of
> > the
> > > > tunnels; hence any
> > > > > implementation of these tunnels may be vulnerable. In particular, the
> > attacks
> > > > were tested
> > > > > against the ISATAP, 6to4 and Teredo implementations of Windows Vista and
> > > > Windows Server 2008 R2.
> > > > >
> > > > > I think the results of the research warrant some corrective action. If
> > > > this indeed shall be the
> > > > > general sentiment of the list, I will be happy write an appropriate I-D.
> > The
> > > > mitigation measures we
> > > > > suggested in the paper are the best we could think of to completely
> > eliminate
> > > > the problem. However
> > > > > they are far from perfect since they would require tunnel implementations
> > to
> > > > be updated in case new
> > > > > types of automatic tunnels are introduced.
> > > > >
> > > > > Your comments are welcome.
> > > > >
> > > > > Gabi
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> 
> 
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Sep 2009 14:20:32 -0700

Below is my review of 'draft-jiang-v6ops-incremental-cgn-02.txt':

Fred

---

1) Section 1, second paragraph, the sentence beginning
"They are too complicated..." is meaningless unless it
were to name specific transition mechanisms within specific
deployment scenarios. For example, perceived complications
may only be relevant when necessary network-supporting
infrasturcture is missing. Suggestion is to rewrite the
paragraph as follows:

   "IPv4/IPv6 transition issues therefore become more critical
    and complicated for the soon-coming global IPv6 deployment.
    Host-based transition mechanisms alone may not be able to
    meet the requirements in all cases. Therefore, network
    supporting functions and/or new transition mechanisms
    with simple user-side operation are needed."

2) Section 1, paragraph 4, the final two sentences seem to
imply that DSLite requires the ISP to upgrade its network
to IPv6, but that is incorrect. DSLite can operate as
IPv4-in-IPv6-in-IPv4 encapsulation, such that it can
operate over IPv4-only networks as long as the CPE and
CGN are dual-stacked. These two sentences need to be
corrected to reflect this.

3 Section 2.1, the sentence: "The integration of NAT-PT
is out of scope for this document." should be changed
to: "The integration of such mechanisms is out of scope
for this document."

4) Section 2.2, sentence beginning "Other tunneling
mechanisms..." should read:

  "Other tunneling mechanisms such as 6over4 [RFC2529], the
   Intra-Site Automatic Tunnel Addressing Protocol [RFC5214]
   and Virtual Enterprise Traversal (VET) [VET] are also
   considered."

5) Section 2.6, bring back text removed from the -01 in a
slightly modified form as follows:

  "However, for IPv6 traffic, a user behind the DS HG will
   see normal IPv6 service. It is therefore recommended that
   all IPv6 tunnels support an MTU of at least 1500 bytes,
   to ensure that the mechanism does not cause excessive
   fragmentation of IPv6 traffic nor excessive IPv6 path
   MTU discovery interactions."

6) Section 3, first part of first sentence, change to:
"If the core network transitions to IPv6,".

7) Section 3, paragraph 3 - same comment as 2) above. DSLite
does not require an IPv6-only ISP network, and can run as
IPv4-in-IPv6-in-IPv4 in an IPv4-only ISP network in which the
CPE and CGN are both dual-stacked. The advantages of using
DSLite over v4-v4 NATing are that the CPE can use traffic
engineering and ingress filtering by selecting specific CGNs
through which to direct their traffic. This requires only
that the CPE be able to discover the addresses of CGNs in
the operator network. That process can be coupled with the
ISATAP/VET Potential Router List (PRL) discovery mechanisms,
in which case the CGN would be co-resident with an ISATAP/VET
router that terminates IPv6-in-IPv4 intra-site tunnels.

8) Section 3.1, end of final sentence of first paragraph
says: "so we refer to it non-specifically" but then names
a specific service. To keep the sense of the sentence,
it would have to be changed to: "so we refer to it
non-specifically as "NAT64"." (i.e., and remove the
specific citation). I am open to other suggestions.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Sep 2009 11:37:39 +1200

Thanks for your two reviews, Fred.

Sheng is on travel, but we'll respond in due course.

Regards
   Brian Carpenter
   University of Auckland

---

From: Gabi Nakibly <[email-masked]>
Date: Thu, 3 Sep 2009 07:59:51 -0700 (PDT)

Hi Fred,
see inline.

Gabi

----- Original Message ----
> Sent: Tuesday, September 1, 2009 6:49:56 PM

Why do you think so? As I see it, the two checks mitigate two different attacks. The destination address check defends the ISATAP router against attacks of type 3 in which it acts as the decapsulator of the attack packet.  While, the source address check defends the ISATAP router against attacks of type 3 in which it acts as the ecapsulator of the attack packet.  Either of these checks are redundant if the other one is employed by the opposite router of the attack. So I do not see why one of them is a SHOULD and the other is a MAY. 

> gets deployed then the source address check is unnecessary

In principle, I agree with you. However, I am a believer of the "defense in depth" paradigm: two layers of security are (usually) better than one. Since no one can be absolutely sure that the destination address check shall always be implemented correctly at all other routers then it may seem prudent to also employ the source check as a second layer of defense.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 4 Sep 2009 11:54:39 -0700

Hi Remi,

I couldn't parse most of your message; there is no such
thing as a /96 prefix.

Fred

> From: Rémi Després [mailto:[email-masked]]
> Sent: Friday, September 04, 2009 10:05 AM
> To: Templin, Fred L
> Cc: Gabi Nakibly; v6ops; 6man 6man; [email-masked]
> Comment below
> Le 3 sept. 09 à 17:59, Templin, Fred L a écrit :
> 
> > Gabi,
> >
> >> Sent: Thursday, September 03, 2009 8:00 AM
> >>>> I agree that the source address check discussed below should be
> >>>> made. I would
> >>> also add a forth
> >>>> check to mitigate attack #3 as a second layer of defense in case
> >>>> the opposite
> >>> ISATAP router does not
> The two following scenarios show in my understanding that ISATAP
> routers SHOULD check Source addresses of packets they receive in IPv6:
> 
> SCENARIO 1: between two ISATAP routers A and B
> 
>    ISATAP router A receives in IPv6:
>    Dst6 = </96 prefix of ISATAP router A> . <IPv4 address of ISATAP
> router B>
>    Src6 = </96 prefix of ISATAP router B> . <IPv4 address of ISATAP
> router A>
> 
>    If ISATAP router A doesn't discard the packet because of its
> source address, it will encapsulate it with:
>    Dst4 = <IPv4 address of ISATAP router B>
>    Src4 = <IPv4 address of ISATAP router A>
> 
>    Then, ISATAP router B finds that Src6 and Src4 are consistent, and
> forwards the IPv6 packet to ISATAP router A.
>    The routing loop is in place.
> 
> SCENARIO 2: between an ISATAP router and a 6to4 relay router
> 
>    The ISATAP router receives in IPv6:
> 
>    Dst6 = </96 prefix of the ISATAP router> . <IPv4 address of the
> 6to4 relay>
>    Src6 = 2002::/16 . <IPv4 address of the ISATAP router>
> 
>    If it doesn't discard the packet because of its source address, it
> will encapsulate it with:
>    Dst4 = <IPv4 address of the 6to4 relay>
>    Src4 = <IPv4 address of the ISATAP router>
> 
>    Then, the 6to4 relay finds that Src6 and Src4 are consistent, and
> forwards the IPv6 packet to the ISATAP router.
>    The routing loop is in place.
> 
> Anything missing?
> 
> Regards,
> RD
>

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 07 Sep 2009 06:51:53 +0800

Hi, Templin,

Thanks so much for your comments. Can I ask you a question here: overall, do
you think this draft is suitable for v6ops charter and mature enough to be
adopted as wg file?

Most of your comments are accepted and will be reflected in the next version
except for point 5. Actually, I am with you and these texts were in the
earlier version. However, Fred thought any normative material were not
suitable for 6vops wg and should be removed. Apparently, a recommendation
for MTU is normative rather than operational. So, unless Fred confirms
that's fine I cannot put the MTU text back. Fred?

Many thanks and best regards,

Sheng

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Templin, Fred L
> Sent: Thursday, September 03, 2009 5:21 AM
> To: v6ops
> Cc: JiangSheng 66104; [email-masked]; Brian E Carpenter
> Subject: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'
>

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 8 Sep 2009 01:22:58 -0700 (PDT)

Fred,

Se below.

Gabi
----- Original Message ----
> Sent: Thursday, September 3, 2009 5:59:36 PM
> > > > I agree that the source address check discussed below should be made. I 
> would
> > > also add a forth
> > > > check to mitigate attack #3 as a second layer of defense in case the 
> opposite
> > > ISATAP router does not
> > > >      if (src == "::0200:5efe:")
> > Why do you think so?
> I think so, because ISATAP routers are strongly advised not
> to operate outside of an ip-proto-41 and ingress filtering
> site in the first place. Those that do are already operating
> at-risk, and the best we can do is tell them what they
> SHOULD/MAY do to avoid problems. 
> 

I agree. I was not suggesting otherwise.

> > As I see it, the two checks mitigate two different attacks. The destination
> > address check defends the ISATAP router against attacks of type 3 in which it 
> acts as
> > the decapsulator of the attack packet.
> 
> Right.
> 
> > While, the source address check defends the ISATAP
> > router against attacks of type 3 in which it acts as the ecapsulator of the 
> attack packet.
> 
> Right.
> 
> > Either of
> > these checks are redundant if the other one is employed by the opposite router 
> of the attack.
> 
> Right.
> 
> > So I do not see why one of them is a SHOULD and the other is a MAY.
> 
> In my view, the decapsulator is the true victim because
> it is the one that receives the tunneled packet. It has
> placed itself in a position to be attacked by operating
> outside of a filtering site in the first place, so it
> really SHOULD do something to protect itself.
> 
> The encapsulator on the other hand is neither the attacker
> nor the victim, but rather is an unwitting conduit for the
> attacker. So, it may want to do something extra on behalf
> of decapsulators that don't observe the SHOULD but it (like
> the decapsulator) is already operating at-risk outside of
> a filtering site anyway.  
>   

Here our views part. The encapsulator is as much a victim as the decapsulator. As a routing loop attack in launched, the same number of packets pass through both routers (or through any other hop on the loop of that matter). Both routers are DoSed equally. So the the encapsulator has also strong incentive to stop the attack.

> > In principle, I agree with you. However, I am a believer of the "defense in 
> depth" paradigm: two
> > layers of security are (usually) better than one. Since no one can be 
> absolutely sure that the
> > destination address check shall always be implemented correctly at all other 
> routers then it may seem
> > prudent to also employ the source check as a second layer of defense.
> 
> If the decapsulator is already required to implement the check,
> then IMHO any checks at the encapsulator would at most be a
> weak MAY. These checks are not cheap, and IMHO you would find
> encapsulator implementations that do not honor them regardless
> of the strength of the normative language.
> 

I definitely see what you are saying. The fundamental question here is whether a node (the encapsulator) should do what he can to protect itself or is it OK to be passive and rely on others (the decapsulator) for protection. I guess there is no definite answer here. I guess that the practical answer is that it depends on the cost of the self-protection. Do you believe that the cost of source check is unreasonable?

> > > > > > proto-41 filtering may break other tunnels the site may employ. 
> However, I
> > > do
> > > > > not have hard evidence
> > > > > > > > forwarding a packet into the tunnel. It truly addresses the root 
> cause
> > > of
> > > > > the
> > > > > > > problem ans is simple
> > > > > > attacker is internal to the site then the proto-41 filtering will not 
> help
> > > and
> > > > > the neighbor cache can
> > > > > > be poisoned.
> > > > >
> > > > > > > > destination ISATAP address does not include a local IPv4 
> address since
> > > the
> > > > > > > > not work anyway since one router can not send a direct IPv4 packet 
> to
> > > the
> > > > > > > other. In addition,
> > > > > > > > have to be done on a 6to4 address, i.e. the destination address 
> must
> > > not
> > > > > be
> > > > > > > > better one for mitigating the routing loops. However, I would be 
> happy
> > > if
> > > > > > Well, I am referring to any ISATAP deployment with public IPv4 
> addresses
> > > and
> > > > > no proto-41 filtering. I
> > > > > > not be aware of. The best way to mitigate attack #2 is by the 6to4 
> relay
> > > with
> > > > > a check similar to that
> > > > > > when the 6to4 relay validates that the IPv6 source address corresponds 
> to
> > > the
> > > > > IPv4 one (this is
> > > > > > > > In attacks #2 and #3 the ISATAP router sources and IPv4 packet 
> with
> > > its
> > > > > own
> > > > > > > IPv4 address as the
> > > > > > > > source address.
> > > > > > > >
> > > > > > > >
> > > > > > > > proto-41 filtering should barrier between the two tunnels within 
> the
> > > site?
> > > > > > > >
> > > > > > > >
> > > > > > > > >   Each ISATAP interface configures a set of locators consisting 
> of
> > > IPv4
> > > > > > > > routers implement IPv4 ingress filtering and ip-protocol-41 
> filtering
> > > as
> > > > > > > > the National EW Research & Simulation Center have recently 
> published.
> > > The
> > > > > > > > of routing loop attacks that abuses 6to4, ISATAP and Teredo. 
> The paper
> > > can
> > > > > be
> > > > > > > found at:
> > > > > > > > IPv6 is the future network layer protocol for the Internet. Since 
> it
> > > is
> > > > > not
> > > > > > > compatible with its
> > > > > > > > mechanisms is automatic tunnels, which enable IPv6 communication 
> over
> > > an
> > > > > IPv4
> > > > > > > network without prior
> > > > > > > > We exhibit five attacks of this class. One of the presented 
> attacks
> > > can
> > > > > DoS a
> > > > > > > Teredo server using a
> > > > > > > > against the ISATAP, 6to4 and Teredo implementations of Windows 
> Vista
> > > and
> > > > > > > Windows Server 2008 R2.
> > > > > > > >
> > > > > > > > general sentiment of the list, I will be happy write an 
> appropriate
> > > I-D.
> > > > > The
> > > > > > > mitigation measures we

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 8 Sep 2009 01:58:45 -0700 (PDT)

Fred,

----- Original Message ----
> Sent: Friday, September 4, 2009 10:00:53 PM
> I'd like to make one other observation about these checks we
> have been discussing. There seems to be an implication that
> there needs to be a check on all of the IPv4 addresses assigned
> to the node's IPv4 interfaces, and with ISATAP there could be
> multiple underlying IPv4 interfaces over which the ISATAP
> interface is configured. So, that would seem like a potential
> performance issue if there were multiple IPv4 addresses to
> check for every packet.
> 

Duly noted. However, please note that the processing overhead of the checks is on par with that of other currently deployed checks, such as the PRL check before decapsulation.

> But, if the ISATAP router configures only a single IPv4 address
> and places it on the ISATAP interface (i.e., leaving all of the
> underlying IPv4 interfaces with only a link-local address) then
> there is only one IPv4 address to check. The technique is called:
> "link-layer multiplexing" and is described for ISATAP/VET in
> Appendix B of 'draft-templin-intarea-vet'. But, the idea really
> came from Section 3.3.4 of RFC1122.
> 

This is indeed a valid alternative.

> > Why do you think so? As I see it, the two checks mitigate two different 
> attacks. The destination
> > the decapsulator of the attack packet.  While, the source address 
> check defends the ISATAP
> attack packet.  Either of
> of the attack. So I do
> > not see why one of them is a SHOULD and the other is a MAY.
> > 
> > >

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 8 Sep 2009 05:27:43 -0700 (PDT)

Hi Christian,
Thanks for your comments.

The checks you suggested are powerful and will indeed mitigate the attacks. The only thing that worries me is the fact that usually AFAIK the ISATAP router is not configured with the IPv4 subnet addresses of the site. This means that the router must now be configured with this information and reconfigured as this information changes. If this is felt to be a reasonable administrative overhead, then I think the checks should be employed. 

One minor thing that should be noted is that these checks will not mitigate the attacks in case there are two ISATAP links (with two separate routers) in the same site. This means that their sets of registered subnets coincide. I assume that such deployment are not common, although I do not have the information to back this assumption.

Gabi

----- Original Message ----
> From: Christian Huitema <[email-masked]>
> To: "Templin, Fred L" <[email-masked]>; Gabi Nakibly <[email-masked]>; v6ops <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Friday, September 4, 2009 10:25:21 PM
> I think that there is another possible way to protect against these attacks, if 
> the ISATAP router limits the range of IPv4 addresses towards which it is willing 
> to relay packets. That would fit many current deployments, maybe most.
> 
> In many current deployments, ISATAP is used to provide IPv6 connectivity inside 
> a "site", typically protected by a firewall. The expected behavior is that hosts 
> in that site will use direct ISATAP connectivity to exchange packets with each 
> other, and will use the ISATAP router to exchange packets with other IPv6 
> subnets.
> 
> Assume that the site is defined by a set of IPv4 subnets, and the ISATAP router 
> knows that list. The basic check in the ISATAP router is thus:
> 
>         On incoming packet:
>                 If IPv6 source belongs to local ISATAP subnet (matches /64 prefix):
>                         If (IPv4 source does not match last 32 bits of IPv6 source): drop;
>                         Else If (IPv4 source does not belong to one of registered subnets): drop;
>                         Else relay; // we may or may not want to add a destination check
>                 Else
>                         If (IPv4 source belongs to one of registered subnets): drop;
>                         Else if (IPv6 destination does not match ISATAP subnet): drop;
>                         Else if (embedded IPv4 address does not belong to of registered subnets): drop;
>                         Else relay;
> 
> Written that way, the ISATAP router cannot create a loop, because packets always 
> go either from site to elsewhere, or from elsewhere to site.
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, 
> Fred L
> Sent: Friday, September 04, 2009 1:01 PM
> To: Gabi Nakibly; v6ops
> > the decapsulator of the attack packet.  While, the source address check 
> defends the ISATAP
> > > > > > > > destination ISATAP address does not include a local IPv4 address 
> since
> > > the
> > > > > > > > of routing loop attacks that abuses 6to4, ISATAP and Teredo. The 
> paper
> > > can
> > > > > be
> > > > > > > found at:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Sep 2009 10:12:28 -0700

Hi Sheng,

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Sunday, September 06, 2009 3:52 PM
> To: Templin, Fred L; 'v6ops'; 'Fred Baker'
> Cc: [email-masked]; 'Brian E Carpenter'
> Subject: RE: Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'
> 
> Hi, Templin,
> 

Thanks for considering the input. On point 5), however,
it should be OK to talk about MTU without using words that
could be construed as normative. For example, the original
text could be reworded slightly as follows:
 
   "However, for IPv6 traffic, a user behind the DS HG will
    see normal IPv6 service. We therefore observe that an
    IPv6 tunnel MTU of at least 1500 bytes would ensure that
    the mechanism does not cause excessive fragmentation of
    IPv6 traffic nor excessive IPv6 path MTU discovery
    interactions."

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Sep 2009 10:37:03 -0700

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?

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:<my_IPv4_address>". In pseudo-code:

  isatap_rcv() {
    ...
    if (v6dst == "foreign_prefix::0200:5efe:<my_IPv4_addr>")
      drop_pkt();
    ...
  }

  isatap_xmt() {
    ...
    if (v6src == "foreign_prefix::0200:5efe:<my_IPv4_addr>")
      drop_pkt();
    ...
  }

Does anyone see a problem with 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 would also like to point out that the attack vectors only
occur when the ISATAP/VET router mistakes the other tunnel
endpoint for a host when in fact the other end is another
router. Mitigations for router-to-router ingress filtering
are already specified in VET.

Comments?

Fred

> Sent: Tuesday, September 08, 2009 5:28 AM
> To: Christian Huitema; Templin, Fred L; v6ops
> The checks you suggested are powerful and will indeed mitigate the attacks. The only thing that
> worries me is the fact that usually AFAIK the ISATAP router is not configured with the IPv4 subnet
> addresses of the site. This means that the router must now be configured with this information and
> reconfigured as this information changes. If this is felt to be a reasonable administrative overhead,
> then I think the checks should be employed.
> 
> One minor thing that should be noted is that these checks will not mitigate the attacks in case there
> are two ISATAP links (with two separate routers) in the same site. This means that their sets of
> registered subnets coincide. I assume that such deployment are not common, although I do not have the
> information to back this assumption.
> 
> Gabi
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2009 13:56:16 +1200

...
>     IPv6 traffic nor excessive IPv6 path MTU discovery

I think that this should be said. Operational people will get the
message without the need for normative text.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Sep 2009 14:13:44 -0700

Hi Gabi,

> Sent: Friday, September 11, 2009 12:59 PM
> To: Templin, Fred L; Christian Huitema; v6ops
> See below.
> > To: Gabi Nakibly <[email-masked]>; Christian Huitema <[email-masked]>; v6ops
> <[email-masked]>
> > Sent: Tuesday, September 8, 2009 8:37:03 PM
> Looks fine.

OK.

> > "0200:5EFE:". In pseudo-code:
> >
> >   isatap_rcv() {
> >     ...
> 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? 

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

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

> > > > From: Christian Huitema
> > > > To: "Templin, Fred L" ; Gabi Nakibly
> > ; v6ops
> > >
> > > > Cc: "[email-masked]" ; "[email-masked]"
> > > >                         Else if (embedded IPv4 address does not belong to
> > of registered subnets):
> > > drop;
> > > >                         Else relay;
> > > >
> > > > > > > > > A quick summary of our discussion up until now: the best
> > mitigation
> > > > > > of most of
> > > > > > > > these attacks is
> > > > > > > > > indeed the proto-41 and ingress filtering on the border of the
> > ISATAP
> > > > > > site. If
> > > > > > > > it is indeed
> > > > > > > > > on this. I would be happy if others on the list will refute or
> > justify
> > > > > > this
> > > > > > > > assumption.
> > > > > > > > >
> > > > > > > > > If this assumption is (even partially) correct than I think that
> > the
> > > > > > ISATAP
> > > > > > > > router should defend
> > > > > > > > > itself.
> > > > > > > >
> > > > > > > > > Moreover, as I mention below the proo-41 filtering is not
> > effective in
> > > > > > case of
> > > > > > > > attack
> > > > > > > > > > > I initially very much liked your suggestion regarding the
> > check of
> > > > the
> > > > > > > > > > neighbor cache before
> > > > > > > > > > > enough to implement. However, I realized that an attacker can
> > send
> > > > a
> > > > > > > > > > > as if it came from the 6to4 relay. The router would then send
> > a RA
> > > > to
> > > > > > > > it and
> > > > > > > > > > consequently change its
> > > > > > > > > This is only true when the attacker is outside the site and
> > proto-41
> > > > > > filtering
> > > > > > > > is employed. If the
> > address
> > > > > > > > > > > check would be done only on ISATAP addresses that include
> > public
> > > > IPv4
> > > > > > > > > > addresses then this will
> > > > > > > > > > > eliminate the attacks in which the two victims reside at
> > different
> > > > > > sites.
> > > > > > > > Note
> > > > > > > > > > that if attack #3 is
> > > > > > > > > > "2002:> > the ISATAP router>::*". In this case the IPv4 address
> > must
> > > > be
> > > > > > > > public,
> > > > > > > > > > according to
> > > > > > > > > > >  the 6to4 spec.
> > > > > > > > > > >
> > > > > > > > > > > As you also noted there is another problem with this check
> > since
> > > > the
> > > > > > > > string
> > > > > > > > > > > to ISATAP links. On the other hand, it seems that the
> > probability
> > > > to
> > > > > > > > encounter
> > > > > > > > > > a non-malicious packet
> > > > > > > > > > > with a destination address having an IID that equals
> > "200:5EFE:>
> > > > IPv4
> > > > > > > > address>" is
> > > > > > > > > > > pretty slim.
> > > > > > > > > > >
> > > > > > > > > > > This check is definitely not a perfect solution, and I sure
> > hope
> > > > that
> > > > > > > > someone
> > > > > > > > > > will come up with a
> > > > > > > > > > > Well, I do not see how this is correct. In attacks #1 and #3
> > the
> > > > > > ISATAP
> > > > > > > > router
> > > > > > > > > > sources (actually
> > > > > > > > > > > case where ingress filtering can help is in case of attack #3
> > when
> > > > the
> > > > > > > > routers
> > > > > > > > > > reside at the same
> > > > > > > > > > > site. In that case if the attack packet (packet 0) is sent
> > from
> > > > > > outside
> > > > > > > > the
> > > > > > > > > > site then ingress
> > > > > > > > > > > What about two ISATAP tunnels that reside on the same site
> > like in
> > > > > > attack
> > > > > > > > #3.
> > > > > > > > > > Do you also think that
> > > > > > > > > > > Thanks for publishing this work. In the document, attacks A, B
> > and
> > > > C
> > > > > > > > > > > In particular, in scenarios A, B and C the IPv4 locator used
> > for
> > > > > > ISATAP
> > > > > > > > > > > IP-proto-41 packets that are destined to an IPv4 node outside
> > of
> > > > the
> > > > > > > > > > > enterprise. This condition should be satisfied by having the
> > site
> > > > > > border
> > > > > > > > > > > It is mentioned that attack C could also occur when the
> > routers
> > > > reside
> > > > > > > > > > > correspond to a case in which an attacker within the site
> > attacks
> > > > the
> > > > > > > > > > > site itself, which can easily be traced - especially when
> > source
> > > > > > address
> > > > > > > > > > > spoofing from a node within the site is prevented through
> > proper
> > > > > > ingress
> > > > > > > > > > > filtering.
> > > > > > > > > > >
> > > > > > > > > > > Fred
> > > > > > > > > > > predecessor, some interoperability mechanisms were designed.
> > An
> > > > > > important
> > > > > > > > > > category of these
> > > > > > > > > > > configuration. This category includes ISATAP, 6to4 and Teredo.
> > We
> > > > > > present
> > > > > > > > a
> > > > > > > > > > novel class of attacks
> > > > > > > > > > > between a tunnel's overlay IPv6 routing state and the native
> > IPv6
> > > > > > routing
> > > > > > > > > > state. The attacks form
> > > > > > > > > > > single packet. The exploited vulnerabilities are embedded in
> > the
> > > > > > design of
> > > > > > > > the
> > > > > > > > > > tunnels; hence any
> > > > > > > > > > > implementation of these tunnels may be vulnerable. In
> > particular,
> > > > the
> > > > > > > > attacks
> > > > > > > > > > were tested

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Sep 2009 11:05:37 +1200

On 2009-09-12 09:13, Templin, Fred L wrote:

(much text deleted)

> Otherwise, the best solution IMHO
> virtual links. 

This was of course the original intention for 6to4, so
that any misconfiguration issues could be limited to presumably
trusted staff and boxes. Unfortunately, reality has turned out
to be different, with host-based automatic tunnels becoming
popular.

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Sep 2009 16:12:23 -0700

Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, September 11, 2009 4:06 PM
> To: Templin, Fred L
> Cc: Christian Huitema; v6ops; [email-masked]; [email-masked]

Thanks. I was rethinking this a bit after sending, and
I may have been too premature in saying routers only
and not hosts.

What I would rather have said was that mechanisms such as
SEcure Neighbor Discovery (SEND) may be helpful in private
addressing domains where spoofing is possible. Let me know
if this makes sense.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Sep 2009 13:26:32 +1200

> addressing domains where spoofing is possible. Let me know

Except for the practical problems involved in deploying SEND.
We still have an issue in unmanaged networks.

    Brian

---

From: Dong Zhang <[email-masked]>
Date: Mon, 14 Sep 2009 09:26:44 +0800

Hi Temlin,

Please see inline.

>addressing domains where spoofing is possible. Let me know
IMHO, most of the threats of automatic tunnels, like ISATAP and 6to4,
are resulting from spoofing. If SEND or CGA is possible to be used, 
many attacks could be mitigated.

Thx.

>[email-masked] 

------------------				 
Dong Zhang
2009-09-14

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Sep 2009 09:25:50 -0700

Brian,

> Sent: Friday, September 11, 2009 6:27 PM
> To: Templin, Fred L
> Cc: v6ops; Christian Huitema; [email-masked]; [email-masked]

Can it be said that there is any appreciable operational
experience with SEND yet? Are there implementations?

> We still have an issue in unmanaged networks.

By "unmanaged", how unmanaged do you mean? ISATAP is
intended for networks where there is at least some modicum
of cooperative management. We want that it can also be used
in "loosly" managed networks where there is an overall mutual
spirit of cooperation but where site-internal link-layer
address spoofing may still be possible. Can SEND be used
for that, or do we need something else in addition (e.g.,
a nonce with every message)?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Sep 2009 16:02:53 +1200

> experience with SEND yet? Are there implementations?

I'd like to know that too.

> By "unmanaged", how unmanaged do you mean? 

I was thinking of home networks, the kind where Teredo or
6to4 starts up spontaneously. Probably not a concern for
ISATAP sites.

    Brian

> ISATAP is

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 15 Sep 2009 15:50:42 +1000

Fred, 

> experience with SEND yet? Are there implementations?

=> About 2 months ago there was a thread on the node requirements draft that
addressed the presence of SEND implementations and people who have
implementations voiced them on the list. If memory serves me right it's
basically on linux, BSD and IOS, but check the archives. I don't know
anything about deployment experience.

Hesham

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Sep 2009 08:37:34 -0700

Hesham,

> From: Hesham Soliman [mailto:[email-masked]]
> Sent: Monday, September 14, 2009 10:51 PM
> To: Templin, Fred L; Brian E Carpenter

Thanks for the pointer. A quick google search yesterday
also showed up JUNOS as having an implementation, so there
may be still others. I'll have a look at the archives.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Sep 2009 08:34:01 -0700

Brian,

> Sent: Monday, September 14, 2009 9:03 PM
> To: Templin, Fred L

OK, thanks for the clarification. I think you probably
mean home networks where the home gateway has not yet
been turned into an ISATAP router - else, it would be
a managed network. Does that sound right?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Sep 2009 08:48:53 -0700

Dong,

> From: Dong Zhang [mailto:[email-masked]]
> Sent: Sunday, September 13, 2009 6:27 PM
> Subject: Re: RE: Routing loop attacks using IPv6 tunnels
> 
> Hi Temlin,
> 
> Please see inline.
> 

Thanks for voicing your opinion on this, and I agree.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Sep 2009 09:34:32 +1200

(one word reply in line...)

> a managed network. Does that sound right?

Yes
   Brian

---

From: Dong Zhang <[email-masked]>
Date: Thu, 17 Sep 2009 10:40:21 +0800

Hi Templin,

>may be still others. I'll have a look at the archives.

There is another implementation.
http://www.ietf.org/mail-archive/web/cga-ext/current/msg00321.html

------------------				 
Dong Zhang
2009-09-17

---

From: Gabi Nakibly <[email-masked]>
Date: Tue, 29 Sep 2009 03:21:53 -0700 (PDT)

Hi Fred,
Back from vacation. See Comments inlines.

Gabi

----- Original Message ----
> To: Gabi Nakibly <[email-masked]>; Christian Huitema <[email-masked]>; v6ops <[email-masked]>
> Sent: Friday, September 11, 2009 11:13:44 PM
> > > To: Gabi Nakibly ; Christian Huitema 
> ; v6ops
> > 

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

> > >     if (v6dst == "foreign_prefix::0200:5efe:")
> > >       drop_pkt();
> > >     ...
> > >   }
> > >
> > >   isatap_xmt() {
> > >     ...
> > >     if (v6src == "foreign_prefix::0200:5efe:")
> > >       drop_pkt();
> > >     ...
> > >   }
> > >

I agree. However, remember that the spoofed packet may also originate from within the site, which is very hard to defend against.

> > > > The checks you suggested are powerful and will indeed mitigate the 
> attacks.
> > > The only thing that
> > > > worries me is the fact that usually AFAIK the ISATAP router is not 
> configured
> > > with the IPv4 subnet
> > > > addresses of the site. This means that the router must now be configured 
> with
> > > this information and
> > > > reconfigured as this information changes. If this is felt to be a 
> reasonable
> > > administrative overhead,
> > > > One minor thing that should be noted is that these checks will not 
> mitigate
> > > the attacks in case there
> > > > > I think that there is another possible way to protect against these 
> attacks,
> > > if
> > > > > a "site", typically protected by a firewall. The expected behavior is 
> that
> > > hosts
> > > > > in that site will use direct ISATAP connectivity to exchange packets 
> with
> > > each
> > > > > Written that way, the ISATAP router cannot create a loop, because 
> packets
> > > always
> made.
> > > I
> > > > > > address check defends the ISATAP router against attacks of type 3 in 
> which
> > > it
> > > > > acts as
> check
> > > > > > router against attacks of type 3 in which it acts as the ecapsulator 
> of
> > > the
> > > > > attack packet.  Either of
> > > > > > these checks are redundant if the other one is employed by the 
> opposite
> > > router
> > > > > of the attack. So I do
> > > > > > In principle, I agree with you. However, I am a believer of the 
> "defense
> > > in
> > > > > depth" paradigm: two
> > > > > > > > > > implemented. I assume that not all sites deploy such filtering 
> for
> > > > > lack of
> > > > > > > > > awareness or since the
> > > > > > > > > > > > forwarding a packet into the tunnel. It truly addresses 
> the
> > > root
> > > > > cause
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > > problem ans is simple
> > > > > > > > > > attacker is internal to the site then the proto-41 filtering 
> will
> > > not
> > > > > help
> > > > > > > and
> > > > > > > > > the neighbor cache can
> > > > > > > > > > be poisoned.
> > > > > > > > >
> > > > > > > > > > > > a private IPv4 address. On the other hand, a check on 
> public
> > > IPv4
> > > > > > > > > addresses is
> > > > > > > > > > > acceptable. If the
> > > > > > > > > > > > launched on two ISATAP routers having private addresses at 
> two
> > > > > > > different
> > > > > > > > > sites
> > > > > > > > > > > then the attack will
> > > > > > > > > > > > not work anyway since one router can not send a direct 
> IPv4
> > > packet
> > > > > to
> > > > > > > the
> > > > > > > > > > > other. In addition,
> > > > > > > > > > > > to mitigate attacks in which the other victim is a 6to4 
> relay
> > > > > (such as
> > > > > > > > > attack
> > > > > > > > > > > #1) then a check would
> > > > > > > > > > > > better one for mitigating the routing loops. However, I 
> would
> > > be
> > > > > happy
> > > > > > > if
> > > > > > > > > > > that perform ingress filtering and ip-proto-41 filtering. 
> That
> > > has
> > > > > > > > > > imagine that in practice there are such deployments which are 
> not
> > > the
> > > > > > > > > > This will not necessarily work, since the 6to4 relay may have 
> a
> > > > > unicast
> > > > > > > > > > of attack #2 above. IMO, the second best way, as Remi 
> suggested on
> > > > > another
> > > > > > > > > > in accordance with the 6to4 spec, however it does not always 
> get
> > > > > > > implemented).
> > > > > > > > > If this is not true
> > > > > > > > > > > > ==> 1 in which a border router separates the 6to4 relay 
> from
> > > the
> > > > > > > > > > > > ==> is forwarding the packet *into* the ISATAP link (not 
> out
> > > of
> > > > > > > > > > > > ==> filtering at the border router between the ISATAP 
> router
> > > and
> > > > > > > > > > > > ==> the 6to4 relay. If there is no border router between 
> the
> > > > > ISATAP
> > > > > > > > > > > > ==> Short summary is that in attack #1, the 6to4 relay 
> thinks
> > > it
> > > > > > > > > > > > So If my last comment is correct than I do not see how 
> ingress
> > > > > > > filtering
> > > > > > > > > would
> > > > > > > > > > > help here. The only
> > > > > > > > > > > > ==> IPv6 prefix is foreign, the router can't very well 
> drop
> > > the
> > > > > > > > > > > > >  address-to-interface mappings from a single site; i.e., 
> an
> > > > > ISATAP
> > > > > > > > > > > > is seen both within the enterprise as site #1 and within 
> the
> > > > > global
> > > > > > > > > Internet
> > > > > > > > > > > > itself as site #2. If the ISATAP interface is to be used 
> as an
> > > > > > > enterprise-
> > > > > > > > > > > > interior interface, it should therefore not accept 
> IP-proto-41
> > > > > packets
> > > > > > > > > > > > in the same site, where their addresses may be private. 
> This
> > > would
> > > > > > > > > > > > IPv6 is the future network layer protocol for the 
> Internet.
> > > Since
> > > > > it
> > > > > > > is
> > > > > > > > > not
> > > > > > > > > > > compatible with its
> > > > > > > > > > > > that exploit vulnerabilities in these tunnels. These 
> attacks
> > > take
> > > > > > > > > advantage of
> > > > > > > > > > > inconsistencies
> > > > > > > > > > > > I think the results of the research warrant some 
> corrective
> > > > > action. If
> > > > > > > > > > > this indeed shall be the

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Sep 2009 09:00:55 -0700

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:

> Sent: Tuesday, September 29, 2009 3:22 AM
> 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. 
 
> 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.

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

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