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

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 26 Mar 2004 03:08:07 -0500

A comment on a couple of issues here.

 > OK, let's have a few.
 > 
 > 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).  ISATAP accepts proto-41 packets from
 > anyone.  ISATAP does direct tunneling between the nodes (even if they
 > aren't in the same admin domain, if deployed as you propose).  ISATAP
 > relies that the site has made appropriate protections at its
 > perimeter, or else its security properties fall apart.  ISATAP was
 > devised to be used inside a site, not across the sites.

=> One answer to all of the above: The whole point of recommending
a solution in specific scenarios is to assess the feasability
of the solution to that particular deployment. None of the above
is relevant for 3GPP:
  - On this point to point link ingress filtering in the GGSN 
    stops address spoofing.
  - It's always used in the same admin domain, logically, i.e.
    as far as the IP layer can see.
  - 6-to-4 is not recommended and should not be used by end
    hosts. We discussed this several times and even Brian C
    recommended against this a couple of years ago. 

Given the above conditions, there is no security problems
that we can see.

 > > So to start with IMO the above paragraph
 > > should mention the existence of these implementations and their
 > > interoperability since it is important for mobile 
 > operators/vendors to
 > > know that there is something they can use. Now it 
 > basically says the
 > > opposite i.e. no interoperability and wait for further work.
 > 
 > I do not think that is appropriate at all.  If the WG has not made up
 > its mind, WG document should not be pushing toward a solution which
 > has known problems.  Better not nudge towards any particular
 > direction.

=> In other words make the doc vague and practically useles.
This is the effect of not recommending anything. 
Regarding the WG opinion, I haven't seen anyone apart from 
you objecting to this. If I missed emails please point me
to one. I asked several times to get WG concensus on this
with no luck. What's the next step in the process ? How 
do I elevate this to see what the WG thinks ?

This process is taking way too long and is starting to
look fruitless. In other words, I share all the concerns
that Tony raised and I'd like the WG to address them. 

Hesham

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Mar 2004 11:17:22 +0100

Soliman,

>     recommended against this a couple of years ago.

I certainly can see no scenario in which a 6to4 interface and
an ISATAP interface should be simultaneously active on the
same IPv4 interface. These should definitely be mutually
exclusive. And that should perhaps be stated in the document.

> This is the effect of not recommending anything.

I think the issue here is that ISATAP is a complicated solution
and not everybody is confident that it is good engineering to
recommend it. And of course STEP is too new.

> do I elevate this to see what the WG thinks ?

Have you polled people privately to find out who is intending
to productize ISATAP? In terms of a solid recommendation
to the 3GPP industry, that is more important than anything. What is
the status of ISATAP interoperability testing?

  Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 13:07:49 +0200 (EET)

>   - On this point to point link ingress filtering in the GGSN 

If that's enabled, that is.  But as you see, this issue is not limited 
to being (or not being) able to spoof your IPv4 address.

>     as far as the IP layer can see.

You misunderstand the concept of administrative domains.  Is the home 
user and his (hers) ISP in the same administrative domain as well?  
No, they are not.  3GPP UE is managed by the user, not the 3GPP 
operator.  3GPP operator cannot trust whoever uses the UE.  UE users 
cannot trust other UE users.

>     recommended against this a couple of years ago. 

Such recommendation is not grounded on reality.  It is used by hosts
by the million, and there is nothing we can do to get it out from
there.  I'd suspect many UEs would include 6to4 capability themselves
(I seem to recall hearing some UE pilot stacks would have), e.g. for
trying to obtain IPv6 access in WLANs.

The problem is that if both of them are implemented, we end up in
problems, unless the implementations enforce that the two
pseudo-interfaces MUST NOT be allowed to be anchored to the same IPv4
address.
 
> Given the above conditions, there is no security problems

Perhaps you just don't look sufficiently hard enough :-)

> that Tony raised and I'd like the WG to address them. 

To be frank, the argument has sounded a bit like, "we want to have a
recommended solution soon, as long as it's the solution we have in
mind".  Where are the requirements?

It seems in many cases, a driver for ISATAP has been its
auto-discovery function.  Oh really -- that's implementable in about
every solution in a dozen of lines of code :).  Not really a good 
reason to be blindfolded to just look at one solution, IMHO.

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