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

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Fri, 26 Mar 2004 12:24:36 +0100

Hi Pekka,

I am replying to the list (I missed that in the first message).

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: 26. marts 2004 11:51
> To: Karen E. Nielsen (AH/TED)
> Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on
> draft-ietf-v6 ops-3gpp-analysis-09.txt]
> 
> 
> On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) 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) 
> > 
> > I agree that this may be a problem if both pseudo-interfaces and
> > anchored on the same IPv4 address - but otherwise I do not see a any
> > problem here.
> 
> 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).

>  
> > You consider this to be a big issue - does this mean that 
> you consider a scenario
> > where a node would want to establish both 6to4 and Isatap 
> communication 
> > by use the same IPv4 PDP context as likely ?
> 
> I don't think this is practical in 3GPP scenario, but I can see that 
> the mobile nodes would implement 6to4 (for roaming outside of 3GPP).  
> And if they would implement ISATAP as well, a recipe for disaster 
> could be ready.
> 

I am not really worried about the implementation details.

> I don't think the interfaces would be enabled simultaneously in a 3GPP
> network -- because there private addresses are used, and 6to4 is not
> applicable in any case..
>  

I agree, I don't consider the scenario to be even remotely likely.

> >   ISATAP accepts proto-41 packets from
> > > anyone.  
> > 
> > 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.

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

> > > ISATAP does direct tunneling between the nodes (even if they
> > > aren't in the same admin domain, if deployed as you propose).  
> > 
> > You mean when nodes attached on different administrative domains 
> > uses the same Isatap prefix/the same administrative domain
> > for Isatap tunnel endpoint, I assume.
> > 
> > That will not be the case in 3GPP if the Isatap service/tunnel
> > endpoint service is provided by the serving 3G ISP 
> 
> 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 ?

Thanks, Karen

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 19:57:44 +0200 (EET)

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

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

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

> 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

---

From: Fred Templin <[email-masked]>
Date: Fri, 26 Mar 2004 12:59:01 -0800

Pekka,

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

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

>well.  Luckily enough, there should be relatively little overlap with 

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

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

>The scenario is like this:

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
[email-masked]

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.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Mar 2004 17:17:51 +0300 (EEST)

A few responses in-line..

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

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

> edge of the 3GPP operator network vs. somewhere inside the network?

...

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

---

From: Fred Templin <[email-masked]>
Date: Tue, 30 Mar 2004 18:00:12 -0800

Pekka,

>someone will summarize the conclusion.

I agree that this thread should be wrapped up with a concise summary;
see below.

>algorithm so that different tunnels would not get mixed up.

As far as I can tell, configured tunnels will have a specific match on
both the source and destination IPv4 addresses in the outer headers
of ip-proto-41 packets, while automatic tunnels will have a specific
match on the destination but wildcard match on the source - that
much seems unambiguous.

>global prefixes is not sufficient..)

I havn't forgotten.

>But I agree that there may be overlap.

ISATAP specifies mechanisms for auto-discovery (and has for a
long time now) that add value for the host-router case. It can even
be combined with a tunnel broker capability to dynamically
create configured tunnels if you'd like, but that is getting
beyond the scope of simple mechanisms.

>what a configured tunnel set-up does (like STEP or simplied TSP).

I am not claiming that the above is the only way to go in the 3GPP space;
it's just one possibility. I agree that it might appear to be converging 
toward
what a configured tunnel set-up does in this scenario, but the mechanism
is lightweight and simple.

Fred
[email-masked]