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

[Pekka Savola <pekkas@netcore.fi>]

A few responses in-line..

On Fri, 26 Mar 2004, Fred Templin wrote:
> >On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote:
> >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.

I haven't been able to follow the discussion on this, so I don't know 
about the current thinking, but when the thred has ceased, maybe 
someone will summarize the conclusion.

I'm not so much concerned about sites getting mixed up (I guess this 
would assume that different sites the host connects to have different 
ISATAP domains, and the node could act as a router), but how the 
implementations could robustly perform their ip-proto-41 decapsulation 
algorithm so that different tunnels would not get mixed up.

(Note: one thing some may be forgetting that the ISATAP interface also 
includes a link-local prefix, which overlaps with all the other 
mechanisms (well, except, 6to4 doesn't use them).  So, matching the 
global prefixes is not sufficient..)

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

I would not personally find it "normal and natural" -- because if you 
have the capability for configured tunnels, you should not be needing 
ISATAP to begin with (except possibly as an optimization methodbetween 
the ISATAP nodes inside the ISATAP site).

But I agree that there may be overlap.

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

...

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

I think you're describing the model where ISATAP is only used for 
host-to-router tunneling in some sense -- where the host-to-host part 
was disabled (using some unspecified methods)?

To say it differently, are you proposing the model where a different 
/64 prefix is advertised to *each* of users, i.e., that each would 
function as their own ISATAP site (with nobody else in the ISATAP 
site)? (And the other users would not be "on-link", ISATAP-wise.)

If I understand the scenario sufficiently, I think that would fix most
of the concerns.  But then again, as takes away the direct tunneling
benefit of ISATAP, I'm very uncertain why it would make sense to go
into that direction in any case -- as this seems fundamentally like
what a configured tunnel set-up does (like STEP or simplied TSP).

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