RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt]

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 26 Mar 2004, Soliman Hesham wrote:
> => One answer to all of the above: The whole point of recommending
> a solution in specific scenarios is to assess the feasability
> of the solution to that particular deployment. None of the above
> is relevant for 3GPP:
>   - On this point to point link ingress filtering in the GGSN 
>     stops address spoofing.

If that's enabled, that is.  But as you see, this issue is not limited 
to being (or not being) able to spoof your IPv4 address.

>   - It's always used in the same admin domain, logically, i.e.
>     as far as the IP layer can see.

You misunderstand the concept of administrative domains.  Is the home 
user and his (hers) ISP in the same administrative domain as well?  
No, they are not.  3GPP UE is managed by the user, not the 3GPP 
operator.  3GPP operator cannot trust whoever uses the UE.  UE users 
cannot trust other UE users.

>   - 6-to-4 is not recommended and should not be used by end
>     hosts. We discussed this several times and even Brian C
>     recommended against this a couple of years ago. 

Such recommendation is not grounded on reality.  It is used by hosts
by the million, and there is nothing we can do to get it out from
there.  I'd suspect many UEs would include 6to4 capability themselves
(I seem to recall hearing some UE pilot stacks would have), e.g. for
trying to obtain IPv6 access in WLANs.

The problem is that if both of them are implemented, we end up in
problems, unless the implementations enforce that the two
pseudo-interfaces MUST NOT be allowed to be anchored to the same IPv4
address.
 
> Given the above conditions, there is no security problems
> that we can see.

Perhaps you just don't look sufficiently hard enough :-)

> This process is taking way too long and is starting to
> look fruitless. In other words, I share all the concerns
> that Tony raised and I'd like the WG to address them. 

To be frank, the argument has sounded a bit like, "we want to have a
recommended solution soon, as long as it's the solution we have in
mind".  Where are the requirements?

It seems in many cases, a driver for ISATAP has been its
auto-discovery function.  Oh really -- that's implementable in about
every solution in a dozen of lines of code :).  Not really a good 
reason to be blindfolded to just look at one solution, IMHO.

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