Re: Security issues of Isatap usage in 3GPP networks WAS : RE: moving when all the scenarios are not yet complete [RE: DSTM]

[Pekka Savola <pekkas@netcore.fi>]

Going through oooooold backlog...

I think we are pretty close to agreeing that with additional
simplifications to ISATAP spec, and significant assumptions about
deployment (border is secured; ingress filtering is deployed; etc. --
I don't think they hold in general!) ISATAP's security threats from ND
can be mitigated reasonably well.

On Fri, 25 Jun 2004, Karen E. Nielsen (AH/TED) wrote:
> Let me try (once more) to address the expressed concerns with
> the direct tunnelling functionality of Isatap. 
> 
> The problem hinted at, I assume, is the SEND security threats
> as detailed in 3756 (....or are there others ?)

RFC3756 on ND security threats should provide a relatively complete
picture here.  Of course, there are still security issues that might
be independent of the use of ND that come with ISATAP (for example,
see my last comment in this mail).

Note that ISATAP's securit model wrt. RFC3756 would be:

   3.  A model where the nodes do not directly trust each other at the
       IP layer.  This model is considered suitable for e.g., ad hoc
       networks.

.. even if IP spoofing had been prevented, the perimeter secured, etc.

In addition, direct tunneling brings up the same link-local threats in 
other protocols, such as MLD.  Those are likely subject to other forms 
of threats.
 
> In 3GPP networks it should be possible to assume the following:
> 
> * Intrasite IPv4 source spoofing isn't possible.
> * Site is Protocol-41 perimeter guarded.
> 
> - or it should be acceptable to recommended the above to be 
> enforced by the 3GPP operator as a mechanism to prevent 
> potential SEND security threats of Isatap.

(This is not all of the threats, but still..) How realistic is it that 
these are being performed?

Still, the ISATAP spec does not (IMHO) include sufficient guidance 
(just two paragraphs in Security Considerations) what exactly the site 
should do, and what happens if that isn't done.  This seems too vague 
to qualify as a sufficient recommendation.  (yes, this has been 
brought up in the past, but the revisions of spec seem to remove all 
of this kind of analyses.)

Also, I seem to recall (I'd be happy to be proven wrong..) that some
or even many implementations do not perform the required security
checks (or didn't perform them).  That's not good; a tunneling
mechanism where you have less to check and rely on is better because
you don't need to worry about whether a particular implementation has
done a check or not.
 
> Given the above, the SEND security threats either do not apply to
> Isatap or can be prevented by careful implementation. In particular
> by implementing the following [...] security check on Isatap interfaces:
> 
> * RA messages are only accepted from PRL routers.

See responses below.

> 4.1.1. Link-layer addresses in potential 
> Neighbour Cache Entries maintained on Isatap Interfaces
> are not relevant. The Link-layer address (IPv4 address) is deduced
> from IPv6 destination address. An implementation that uses a different link-layer address
> than the IPv4 address embedded within the IPv6 destination address isn't compliant.

Yes, should be OK in the current spec.

Note however that you still can populate the neighbor cache with crap
even if you don't use it with ISATAP.
 
> DAD sub-clause:
> Why you would ever want to implement DAD on an Isatap Interface I really don't know.
> The uniqueness of the address is inherited from the uniqueness of the IPv4 address.
> The latter which is ensured by the network (at least in enterprise and 3GPP networks).

The spec takes no stance on disabling DAD or not for ISATAP, hence it 
could be used.  However, if v4 spoofing is prevented and perimeter is 
secure, this shouldn't be a problem.
 
> 4.1.2: This could be a valid DoS threat.
> This is however only applicable if NUD is performed on the interface.
> NUD over Isatap only really work if carefully implemented anyway -
> Hence it should be reasonable to assume careful behaviour of an implementation which performs
> NUD on an Isatap interface. For example by implementing the following additional validity
> check:
> * Unless sourced from the link-local address of a PRL router (e.g. for proxy ND) the target address
> of the NS message should be identical to the source address of the packet.
> 
> (We haven't implemented the mentioned check as we 
> do not support NUD on isatap interfaces)

I think the critical question here is whether the node processes NS's
and NA's (and which ones if so) that are sent on the ISATAP link.  
That's where I'm concerned -- I'd rather restrict ND messages to just
those we know we need, rather than allow everything and provide checks
which might or might not help.

Also, looking at the spec, I can't quickly think of why running NUD on 
top of ISATAP links would make sense, as NUD only deletes the neighbor 
cache entry -- but as with ISATAP neighor cache wouldn't be used in 
any case, always just the static computation, this doesn't seem too 
useful.

The only cases I could marginally think of would be the use of some 
onlink prefixes by PRL routers, but that's marginal as well.

I guess this could be removed.
 
> 4.1.3: Non-applicable if DAD is omitted

Yes, but more on DAD above.
 
> 4.2.1: Non-applicable given that a trust worthy PRL population
> mechanism is deployed.

Agreed (and if spoofing is not possible).
 
> 4.2.2+4.2.3
> Isn't related to the direct tunnelling functionality of Isatap.
> Is limited by the usage of/and management of 
> a trust worthy PRL population mechanism.

Wrt, 4.2.2, ISATAP should be better off than standard ND because if 
the decapsulation checks are implemented, even if the default router 
is killed, only communication using the ISATAP addresses is possible, 
others will be discarded.

4.2.3 is not an ISATAP-specific issue.

> 4.2.4
> Non-applicable as Isatap's source address checks combined with IPv4 source address
> proof implies IPv6 source address proof. I.e. the IPv6 link-local address of
> a PRL router cannot be spoofed.

Agreed.
 
> 4.2.5+4.2.6+4.2.7:
> Non-applicable given IPv4 source address spoofing prevention,
> if trustworthy PRL population mechanism is deployed.

Agreed -- significant if's.
 
> 4.3.1:
> Non-applicable by IPv4 source address spoofing prevention.

Yes.
 
> 4.3.2 
> Not related to the direct tunnelling functionality of Isatap.
> Not applicable if address resolution is based on static resolution only.

This is slightly different with ISATAP.  Instead of the router having 
to do lots of ND lookups (which time out), the router has to send the 
packets to arbitrary IPv4 nodes by static computation.

You could even perform 6to4-like reflection from the ISATAP router.  
Assume that the ISATAP addresses would be of the form: 
2001:db8::<ISATAP-ID>, and the site used 10.0.0.0/8 for addressing.

Now you could force the router to send proto-41 packet to 1) every 
host inside 10/8, or even 2) every host the user wants e.g., a host 
that's outside the ISATAP domain (e.g., 4.5.6.7) -- unless there are 
specific blocks at the ISATAP router or at the perimeter to change 
this.

It might be possible to avoid 2) for global addresses if the ISATAP
prefix length is chosen to be sufficiently short and the v4 address
space is contiguous.  But that would mean having a prefix length like
/106 which would be disallowed by the IPv6 specs and would probably
have other problems..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings