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

[Pekka Savola <pekkas@netcore.fi>]

Commenting as just another bozo on the bus..

On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote:
> This stems from the STEP vs. ISATAP competition which I don't quite
> understand. There is not such a big difference between simplified
> host-to-router ISATAP implementations that are deployed today and the
> functions specified in STEP. 

OK, let's have a few.

ISATAP uses a pseudo-interface (this is especially problematic if the
implementation also has a 6to4 pseudo-interface, and one big reason
why ISATAP should be avoided).  ISATAP accepts proto-41 packets from
anyone.  ISATAP does direct tunneling between the nodes (even if they
aren't in the same admin domain, if deployed as you propose).  ISATAP
relies that the site has made appropriate protections at its
perimeter, or else its security properties fall apart.  ISATAP was
devised to be used inside a site, not across the sites.

I do not know which specific simplified subset of ISATAP you have in
mind, but these are fundamental issues with ISATAP as it is (and as it
always has been).  Some of these have been made worse (or new ones
introduced) along the lifetime of ISATAP, so depending on what's
implemented, it could be worse as well.

> So to start with IMO the above paragraph
> should mention the existence of these implementations and their
> interoperability since it is important for mobile operators/vendors to
> know that there is something they can use. Now it basically says the
> opposite i.e. no interoperability and wait for further work.

I do not think that is appropriate at all.  If the WG has not made up
its mind, WG document should not be pushing toward a solution which
has known problems.  Better not nudge towards any particular
direction.

Read closer about non-interoperability: it says basically that if we
wanted to "simplify" or secure ISATAP considerably, that would likely
require non-interoperable changes to the spec.  It is not trying to
say that current ISATAP implementations are non-interoperable.

> The paragraph above also talks about ISATAP complexity and this does
> not match the experience with the deployed base. We're talking about
> supporting RA/RS over a tunnel interface and that doesn't seem like
> something complex. 

It has much more to it than just RA/RS over a tunnel interface.

> Also there is no need for the sort of security across
> administrative domains mentioned above in 3gpp networks, since it is
> handled at layer 2.

I don't think you understand the issues that come into play when you 
deploy something to be used across administrative domains.  The 
interface between domains must be carefully analyzed.  It helps a lot 
if the interface is simple and easy to understand (IMHO which ISATAP 
isn't).

It is one thing to say that the 3GPP operator has identified the user
(whether using regular or pre-paid SIM or whatever) -- and
consequently everything any user does to the operator, the Internet or
the user would be magically trusted -- and another to consider what
the user is able to believe.  That is, 1) can the user trust the other
3GPP users who are doing direct tunneling to it, possibly injecting
malicious packets (which they wouldn't be able to do, unless there was
ISATAP), or 2) can the user trust that the 3GPP operator has secured
*all* of its borders properly, so that either other users, or anyone
in the internet could not inject maliscious packets to the user.  L2
identification helps with none of this.

All of these issues are much simpler with something resembling
configured tunneling, which is why it's preferable.  STEP and the like
are just extensions of that model to make the tunnel easier to
configure, but the security properties are still the same.

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