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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 26 Mar 2004, Karim El-Malki (HF/EAB) wrote:
>  > 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.
> 
> Just like an IPv6 host accepts IPv6 packets from anyone right?
> By using appropriate security (incl. ingress filtering) you limit
> the risks. But this is not a problem of ISATAP.

No, ISATAP opens a (semi-)trusted conduit, a virtual link, to everyone
in the Internet (or everyone in the ISATAP site, if the border
security is done properly).  Specifically, the ISATAP
pseudo-interface, with its link local addresses and functionality
using link-local addresses is placed at risk. This is not possible
with just any IPv6 host.

This is completely different from any IPv6 host accepting IPv6
packets.  To say it differently, a regular IPv6 host cannot receive
packets with a link-local source address and TTL=255 from practically
anyone out there, from completely untrusted source.  ISATAP allows --
no, even stronger, requires! -- this.

(There are other problems with the ISATAP router spoofing as well, but 
they are probably not as relevant compared to this.)

>  > 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.
> 
> And that's exactly what is proposed, it is always inside a site
> from the IP viewpoint.

You do not understand the the concept of "administrative domain".  UEs 
do not belong to the same AD as the 3GPP operator.
 
>  > 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.
> 
> It has been implemented and used widely. You may claim that only a
> subset was used and I would be happy to agree. Still that is a reason
> for the ISATAP document to be modified to reflect what is deployed and
> any limitations but not a reason to discard it. I am certainly in favour
> of this and had already sent come comments to Fred Templin about this
> to share with the authors.

It would help in this discussion if the specific features (and
security protections) implemented and used was explicitly spelled out.
 
> By ignoring the reality of what is out there this will make it harder
> for IPv6 to be deployed. Also you are just turning the tables since the
> text you wanted in that spec is specifically pushing for STEP. So if there
> is someone pushing for their solution which the WG has not adopted yet it's
> not me unlike what you seem to be hinting. I would like ISATAP to be
> given fair consideration, since it is anyway used today and a likely candidate
> for more deployment in the short run. 

I fail to see what's unfair about the current text.  Moreover, no 
objections were raised.

It just lists ISATAP as a proposal, mentions a few problems which have
been raised about it, and describes a few alternatives in case these
problems are considered to be a problem -- and says more work is
needed.

> Creating an ISATAP vs. STEP competiton
> as you are doing will just leave us with nothing to deploy since STEP is
> too new.

So, are you saying, "we must get ISATAP, otherwise there is nothing we
can deploy"?

FWIW, I certainly don't want to push for STEP.  There's work in
progress to create a more unified tunnel server solution.  But IMHO
ISATAP seems to have way too many drawbacks to go for it blindfolded.
And don't say this comes as a late surprise.  I think I've been
complaining about this at least a year or two now, but folks don't
seem to care or don't seem to have sufficient security expertise to
even understand the problems.

>  > 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.
> 
> Since current interoperable ISATAP implementations are already a
> "simplified" version your logic doesn't make sense.

Then they quite likely aren't yet what was referred to with the
"simplified" reference in draft-ietf-v6ops-3gpp-analysis-09.

I.e., such simplified version could be e.g. a variant which would not
include direct tunneling between ISATAP nodes at all.  This would not 
be suitable in some other contexts, though.

>  > > 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.
> 
> Again, it says deployed base.

Direct tunneling between ISATAP nodes in the same ISATAP site is in
the deployed base, right?  Thought so.

>  > 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).
> 
> Actually I think your logic does not reflect at all how a 3gpp mobile
> network works. Once again, there is no crossing of administrative domains
> in the way you mean it.

Administrative domain as a concept has very little to do with the
technique used in the network.  I.e., it still holds.

>  > 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),
> 
> This has nothing to do with ISATAP. With native IPv6 or IPv4 users can
> just send each other packets and these packets are in no way less likely
> to be malicious than tunnelled packets.

Wrong.  See the link-local threat.
 
>  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.
> 
> It just has to do ingress filtering in the GGSN which from what I know
> is default. So you should assume it is default and if anything explicitly
> state this as an assumption/requirement.

Again, this doesn't help against the link-local threat.
 
>  > 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.
> 
> I am not saying work should stop on STEP. What I am saying is that
> ISATAP is already being used and has good reasons for that. 

And a large number of reasons why this is an incredibly bad idea.

Tell me why again the IETF should be advocating bad practice, just
because someone didn't understand the consequences and needed
something to deploy -- and the first solution that came across seemed
to fit?

> So the
> draft should be quickly adapted to reflect what is deployed and
> moved on. That will give us a solution which we can use. Otherwise
> we will continue with this standstill situation.

Standstill may be better than bad solution.  It might help us to get
to a good solution.

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