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

[Fred Templin <ftemplin@iprg.nokia.com>]

Pekka,

This note seems more suitable for legitimate follow-up; see below:

Pekka Savola wrote:

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

I can take this up with the co-authors. Something along the lines of
"must not mix sites over the same IPv4 interface"? There might also
be some  text from older versions of the spec that could help.

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

Here, it would seem normal and natural to find both ISATAP
and configured tunnels configured over the same IPv4 interface.

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

But, wouldn't this depend on whether the ISATAP router sits on the
edge of the 3GPP operator network vs. somewhere inside the network?
See more on this below:

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

Yes, but if we limit the ISATAP router to occur at the edge of the
3GPP operator network (and not somewhere inside the network),
then we have a natural point of demarcation for site boundaries.

E.g., if 3GPP user 1 in your example opens up an IPv4 PDP context,
and the 3GPP operator's equipment acts as an ISATAP router on an
interface at the outward-facing edge of administrative domain A, then
the PDP context would extend admin domain 1 only to the edge of the
operator's network and not allow it to penetrate into admin domain A,
i.e., there would be no site-overlap.

This would make the interface(s) at the outward-facing edge of admin
domain A appear to be ISATAP router interfaces, and the 3GPP operator's
network would appear as a gigantic ISATAP router with multiple ISATAP
interfaces - one per 3GPP user, i.e., one per customer site. Would this go
toward addressing your concern? And, is there anything more needed in
the spec to support this?

Fred
ftemplin@iprg.nokia.com

P.S. I recall posting a note proposing an "inside-out isatap model"
   a long time ago, but it was quickly swept aside for some reason.