Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE]

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 16:51:18 +0100

> > Using the SIM a user can roam to another network and send
 > > packets back to its home network. 
 > 
 > That doesn't mean the operator trusts the user at all; in this case, 
 > it seems like a way to identify what is the home network to send the 
 > packets to.

I don't understand what you mean?
The user gets charged and is able to access services (e.g. internet access).
That's the 3gpp model and ISATAP can be just one of those services.

 > 
 > > So from the 3gpp point of view the user can access basic "home"
 > > services (e.g. ISATAP) in the same way while roaming as if the user
 > > was actually at home. That fits the ISATAP scenario.
 > 
 > You made an assumption that using ISATAP at home network 
 > would be OK, 
 > and therefore using it on the remote network would be equally OK.
 > 
 > I don't make either.
 > 
 > I don't think ISATAP should be used at the home network either, due 
 > to the reasons described: it doesn't fit well to a model of crossing 
 > administrative borders.

I lost you here. What are the admin domains when the user is at home?

Anyway we seem to have come full circle again.
But please take note that there are people on this list who would like
to stop discussing and start finishing off those specs now pending for
years.

/Karim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 19:51:56 +0200 (EET)

On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote:
> I don't understand what you mean? The user gets charged and is able
> to access services (e.g. internet access). That's the 3gpp model and
> ISATAP can be just one of those services.

Let me try to clarify, as the differences in security properties of 
different scenarios are clearly not clear.

My home xDSL system gets charged as well, and the ISP provides me 
services as well.

That doesn't mean the ISP trusts me to "behave well" in their network.  
E.g., I can spoof my address, I can send specially crafted packets, I
can try to confuse their router with OSPF packets if they haven't
disabled the interface, I can harass my neighbor, etc.etc. -- to the
ISP (and other users), I'm a "hostile user".

Much the same with 3GPP, actually more, because you don't have to have 
a contract or details where you can be traced, because you can use 
anonymous SIMs and similar.

In a similar fashion, you cannot trust other users, because you cannot 
trust that the ISP is ensuring that the users cannot harm you (even 
if that was somehow possible).

On the other hand, within an enterprise network, or at least a branch 
of the enterprise network, typically the assumptions are entirely 
different: you have to trust the users at least to some degree.  You 
have contracts etc. with them.  While some host may be acting weird 
for some reason, the users are not typically intentionally malicious.  

So...

As it should be obvious, security mechanisms used and assumptions
implied when devising a solution to the enterprise network are very
probably not adequate for ISP/3GPP scenarios with a different set of
requirements.

Hence, I have always given significant pushback for re-using the 
ISATAP model outside of its (original?) scope, the enterprise 
networks.

> I lost you here. What are the admin domains when the user is at home?

Between the user and the ISP/3GPP operator, see above for better 
explanation.
 
> to stop discussing and start finishing off those specs now pending for

I'm sure that there are people who would like to do that.  On the
other hand, that's exactly what we should not do, as even the
differences in security properties are not clear enough.

We must do what we must do, not necessarily what people would like to
do.

-- 
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: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 18 Nov 2003 19:03:17 +0100

Pekka,

I'm not sure if I got what do you mean ... but if you mean that ISATAP should be used only in enterprise scenarios, I think is wrong.

In general, my opinion is that if we can find the best set of transition tools, that can be deployed everywhere in the network, to be able to sort-out automatically several possible transition scenarios/situations, then we got the best chance to help in the transition. And that means to me that if a transition tool, in your example ISATAP, can be used in more scenarios that the original scope, then is very good.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Karim El-Malki (HF/EAB)" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 18, 2003 6:51 PM
Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE]

> We must do what we must do, not necessarily what people would like to

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 20:19:22 +0200 (EET)

On Tue, 18 Nov 2003, JORDI PALET MARTINEZ wrote:
> I'm not sure if I got what do you mean ... but if you mean that
> ISATAP should be used only in enterprise scenarios, I think is
> wrong.

Pretty close.

Remember, our goal is not just to deploy IPv6 as fast as possible,
it's also to do it securely, with operationally sound principles, etc.

You may be assuming that if we have generic tool which works (to some
definition of "works"), that's good -- nobody cares about the security
considerations anyway as long as the transition is easy... :-)

I'm not saying that we might not want to consider something like
ISATAP in some scenarios; it's just that when doing so, we have to be
careful to consider the features it provides (whether
useful/desirable), the security assumptions it has, etc.etc.  -- quite
a number of non-trivial issues! 

 The direction we'd develop e.g.  ISATAP would probably depend a LOT
on which scenarios we want to make it applicable in, which is why we
need to figure out the scenarios first before going down the path of 
specifying mechanisms.

> In general, my opinion is that if we can find the best set of
> transition tools, that can be deployed everywhere in the network, to
> be able to sort-out automatically several possible transition
> scenarios/situations, then we got the best chance to help in the
> transition. And that means to me that if a transition tool, in your
> example ISATAP, can be used in more scenarios that the original
> scope, then is very good.

A mechanism being usable in more than one scenario would be nice, of
course.

But such a mechanism must also be suited for those scenarios, e.g. 
considering its design assumptions, security properties, operational 
considerations etc.

I'm not sure if other than the most basic transition mechanisms such 
as dual-stack and configured tunneling pass this test.

For example, I would not recommend 6to4 to be used by enterprises,
ISPs (except for relays) or 3GPP networks. For a number of reasons,
mainly based on its unreliability, and such networks requiring better
control of the mechanisms ("configured tunnel") than 6to4 can provide.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 18 Nov 2003 19:31:21 +0100

I see your point.

Of course, when I say "works", I mean with the required security considerations.

I know for sure that we like it or not, the transition mechanisms will be used in the "wrong" scenarios, same as NAT-PT is used some times for what it was not designed, and we have a very little chance to change it. So may be the goal is to make several mechanism to work together in a single "tool box".

Regards,
Jordi

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 21:12:38 +0200 (EET)

On Tue, 18 Nov 2003, JORDI PALET MARTINEZ wrote:
> I know for sure that we like it or not, the transition mechanisms
> will be used in the "wrong" scenarios, same as NAT-PT is used some
> times for what it was not designed, and we have a very little chance
> to change it. So may be the goal is to make several mechanism to
> work together in a single "tool box".

.. which is all the more reason for doing the analysis before getting 
down to the mechanisms.  NAT-PT was published before this was clear, 
and it resulted in some "misuse".

We cannot prevent misuse, of course, but we can ensure that by proper
documentation, description of the scenarios and analysis of the
situation, this becomes clearer to the IPv6 deployers.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 18 Nov 2003 20:38:56 +0100

Not sure but then, for this "misuse", I think the scenarios work is not so useful ... because we will not be able to figure out all the possible combinations. We are just trying on the other way, isolating a few, when there are too many, with too many combinations, too much complicated, too many dependencies, too length process that will not be possible until all the 4 scenarios are done.

Instead we need to put all the possibilities together of were each transition tool can be used. It seems to me much simpler. If we take longer and longer, the market will deploy more and more bad transition tools, and will be worst, less controlled.

Just a good description of each transition tool "own scenarios" will be a better start. Simultaneously, in parallel, we need also to look into a set of priorities/conflicts document: What order to choose, when several transition tools are available. Any conflicts among several of them ?

Regards,
Jordi