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, Karen E. Nielsen (AH/TED) wrote:
> > Yes.  This is very real if they use the same address.  But from the
> > implementation point of view, this is a huge problem.  How do they
> > ensure that this won't happen?  Seems like a very difficult thing to
> > do.
> 
> Well, I don't think that I understand why it is such a problem form
> the implementation point of view (I certainly wasn't for us, but
> then they may be some autoconfiguration issues that are escaping
> me).

If you enforce this in the implementation strongly enough, i.e., with 
a MUST, then this is doable.  Could be in the spec.

The same actually happens with ISATAP and configured tunneling as 
well.  Luckily enough, there should be relatively little overlap with 
them as well.

> > > Well a proto-41 packet will be discarded by an
> > > Isatap interface/daemon unless it meets a few very specific 
> > criteria's....
> > 
> > Depending on which specification you're looking at, this ranges from 
> > "check that v4 and the isatap address match for certain packets, but 
> > don't check for the rest" to "practically nothing".  Depends on which 
> > spec you're looking at...
> 
> May be, but let choose the most solid spec in this sense then.
> I assume we are allowed to improve the mechs and perhaps tune them according 
> to the applicable scenarios.

Yes, they could naturally be improved.  Such improvement does not 
help, however, if the core functionality of the mechanism is which 
would have to be changed. (And such changes might alter its 
applicability in other scenarios.)

> > But regardless of that, the fact stands that unless the site operator
> > blocks proto-41 at the edge, they can be injected to all the ISATAP
> > nodes.  Even if there are checks for such packets, they can cause a
> > lot of harm.  Checking that v4 and isatap address match does not help
> > that much in that regard, as the addresses are spoofable.
> > 
> 
> Well typically I think that the Isatap router will be located 
> within the site or at the site edge,
> therefore proto-41 will not be a problem on the site edge.

You probably mean that they're in the 3GPP network, yes?  It's not 
really in the same "site" with the ISATAP nodes, then, though.

Even if so, this would address the external proto-41 threats only when 
the 3GPP operator would perform proto-41 filtering at its 
Internet-facing borders.  And that would not yet even protect against 
attacks from the other users in the same 3GPP network.

> > No, I mean that if the 3GPP operator provides the ISATAP endpoint, 
> > it's in the different administrative domain as the UE.  UE is managed 
> > by the user, not the 3GPP operator.
> 
> I don't get this - typically the tunnel endpoint will be managed by
> some else than the user - right ?

Sorry if I was confusing here -- by "ISATAP endpoint" I was referring 
to ISATAP router from the ISATAP host's point of view.

The scenario is like this:

======================||===========+
                      ||3GPP user 1| admin domain 1
 3GPP operator's      ||ISATAP node|
   network            ||===========+
                      ||3GPP user N| admin domain N
 (ISATAP router)      ||ISATAP node|
                      ||===========+
======================||
administrative domain A

All the users and the 3GPP network are in different administrative 
domains.

Compare this to e.g. a possible enterprise where ISATAP was originally 
designed for:

=============================|
                      user 1 |
 Enterprise network          |
                             |
 (ISATAP router)      user N |
                             |
=============================|

The router and the hosts are in the same administrative domain.  
Actually nowadays, when the internal security is much more important,
the trend has been to start compartmentalizing the enterprise internal
networks as well, and then ISATAP domains would probably have to be
smaller, but again, this is an entirely different ballgame than using
ISATAP between 3GPP operator (or an ISP) and its users (and between
users as well).

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