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

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

Hi Pekka, 

> There is, however, an argument to be made if a mechanism would be
> required in multiple scenarios, where one or more of the scenarios was
> not finished yet -- then the question would be what would be the basis
> on where to evolve the specification? (for example, let's consider
> ISATAP in 3GPP: one could remove direct tunneling support, but then it
> might become useless (at least to some) in Enterprise -- for
> mechanisms which dependencies it might be worth a bit more of
> wait-and-see, 

Although I may agree with the above argument in principle,
I do not agree with the exemplification.

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

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.

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 additional security check on Isatap interfaces:

* RA messages are only accepted from PRL routers.

We have implemented this with no problems and I would 
like to see it recommended for Isatap.

Indeed:

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.

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

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)

4.1.3: Non-applicable if DAD is omitted

4.2.1: Non-applicable given that a trust worthy PRL population
mechanism is deployed.

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.

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.

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

4.3.1:
Non-applicable by IPv4 source address spoofing prevention.

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

BR, Karen