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

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote:
> OK. There are 3gpp specific mechanisms for this like ggsn
> spoofing protection. But these are generic issues which are
> not specific to ISATAP.

Certainly, but the existance (or not) and use (or not) of these 
mechanisms certainly affect the requirements for the solutions we 
have.

>  > 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.
> 
> You have talked above about generic security issues which exist
> independently of ISATAP. Even if you don't use ISATAP you still
> have those issues and I think many are addressed in 3gpp. So how
> can you come to the conclusion to push-back on ISATAP?

The point is that we know the security issues (or lack thereof) in the 
simple mechanisms such as configured tunnels.

We have not done the rounds of a full analysis of more complex
techniques such as ISATAP.

Until that is done, I do not believe it is appropriate to consider 
anything more complicated seriously.

> We've already discussed the ISATAP security issues and I don't
> see the problem when using it in the 3gpp network. Plus it
> is only an optional mechanism!

It has been "discussed" (to some definition of "discussed"), but not 
properly analyzed, AFAICS.

> We must create appropriate solutions to solve problems and not
> ignore them or generate new ones (like the configured tunnel
> proposal), otherwise quite naturally people will go off and solve it
> their own way. I think people want to solve problems they don't just
> like to do things. 

This is exactly the reason why I'd like to see more discussion what to 
do (or not to do), so that people don't need to make their own 
solutions if they don't need to.

> Careful reviewing is important but specs being
> discussed for years when they are implemented and out in commercial
> products just demonstrates that there is something wrong with the
> way we are handling things.

So as long as a spec has not been properly analyzed, but is already 
implemented or to a degree deployed, we should forget about the warts 
in the specs?

Sorry, I don't subscribe to that belief.  Maybe the analysis should 
have happened sooner, or we should have finished the framework to that 
analysis (scenarios work?) sooner?

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