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

["Carl Williams" <carlw@kddilabs.com>]

This is a bit of operator input that I can provide.

We are currently investigating the use of ISATAP 
with respect to 3GPP2 deployments (cdma2000 networks).
The ISATAP router can be placed behind the PDSNs and minimal
changes are required.  We can gradually transition the
3G network to IPv6 for simple IPv6 service.  We will not
use 6to4 for this specific deployment.     

We have tested ISATAP implementations from Cisco, MSFT
and public domain versions (usagi Linux).


 
Carl

Original Message:
-----------------
From: Fred Templin osprey67@yahoo.com
Date: Fri, 26 Mar 2004 07:51:20 -0800 (PST)
To: karim.el-malki@ericsson.com, pekkas@netcore.fi, v6ops@ops.ietf.org
Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on
draft-ietf-v6 ops-3gpp-analysis-09.txt]


I won't respond to this thread in detail other than to say that a clear
sense 
seems to be emerging from the community in terms of desired scope for
the
ISATAP spec, and have received similar feedback from other sources as
well.
 
About the 6to4 issue, others have already correctly answered that ISATAP
and 6to4 would not occur on the same IPv4 interface such that there
would
be no ambiguity. The only way this could happen is if we had an
unrestricted
"multihomed IPv4 interface", e.g., a wireless interface that could
connect to
multiple sites at the same time w/o encapsulation. But, in practice, we
either use overlay pseudo interfaces (e.g., PDP contexts, PPP,
configured
tunnels, ISATAP interfaces, etc.) to keep the sites separate, or
link-layer
abstractions like the IEEE 802.11 (I)BSS to restrict access to a single
site at a time.
 
About interoperability testing, this is certainly high on the agenda
but,
as others have commented, ISATAP is already seen in wide deployment.
I believe there were ISATAP implementations shown in the IPv6 demo
exhibits at IETF59 as well; I'll send a request to the 'isatap.com' site
administrator asking to have the links there updated.
 
Fred Templin
osprey67@yahoo.com
 

"Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com> wrote:
> On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote:
> > This stems from the STEP vs. ISATAP competition which I don't quite
> > understand. There is not such a big difference between simplified
> > host-to-router ISATAP implementations that are deployed 
> today and the
> > functions specified in STEP. 
> 
> 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.

Just like an IPv6 host accepts IPv6 packets from anyone right?
By using appropriate security (incl. ingress filtering) you limit
the risks. But this is not a problem of ISATAP.

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

And that's exactly what is proposed, it is always inside a site
from the IP viewpoint.

> 
> I do not know which specific simplified subset of ISATAP you have in
> mind, but these are fundamental issues with ISATAP as it is 
> (and as it
> always has been). Some of these have been made worse (or new ones
> introduced) along the lifetime of ISATAP, so depending on what's
> implemented, it could be worse as well.

It has been implemented and used widely. You may claim that only a
subset was used and I would be happy to agree. Still that is a reason
for the ISATAP document to be modified to reflect what is deployed and
any limitations but not a reason to discard it. I am certainly in favour
of this and had already sent come comments to Fred Templin about this
to share with the authors.

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

By ignoring the reality of what is out there this will make it harder
for IPv6 to be deployed. Also you are just turning the tables since the
text you wanted in that spec is specifically pushing for STEP. So if
there
is someone pushing for their solution which the WG has not adopted yet
it's
not me unlike what you seem to be hinting. I would like ISATAP to be
given fair consideration, since it is anyway used today and a likely
candidate
for more deployment in the short run. Creating an ISATAP vs. STEP
competiton
as you are doing will just leave us with nothing to deploy since STEP is
too new.

> 
> Read closer about non-interoperability: it says basically that if we
> wanted to "simplify" or secure ISATAP considerably, that would likely
> require non-interoperable changes to the spec. It is not trying to
> say that current ISATAP implementations are non-interoperable.

Since current interoperable ISATAP implementations are already a
"simplified" version your logic doesn't make sense.

> 
> > The paragraph above also talks about ISATAP complexity and 
> this does
> > not match the experience with the deployed base. We're 
> talking about
> > supporting RA/RS over a tunnel interface and that doesn't seem like
> > something complex. 
> 
> It has much more to it than just RA/RS over a tunnel interface.

Again, it says deployed base.

> 
> > Also there is no need for the sort of security across
> > administrative domains mentioned above in 3gpp networks, 
> since it is
> > handled at layer 2.
> 
> I don't think you understand the issues that come into play when you 
> deploy something to be used across administrative domains. The 
> interface between domains must be carefully analyzed. It 
> helps a lot 
> if the interface is simple and easy to understand (IMHO which ISATAP 
> isn't).

Actually I think your logic does not reflect at all how a 3gpp mobile
network works. Once again, there is no crossing of administrative
domains
in the way you mean it.

> 
> It is one thing to say that the 3GPP operator has identified the user
> (whether using regular or pre-paid SIM or whatever) -- and
> consequently everything any user does to the operator, the 
> Internet or
> the user would be magically trusted -- and another to consider what
> the user is able to believe.
> That is, 1) can the user trust 
> the other
> 3GPP users who are doing direct tunneling to it, possibly injecting
> malicious packets (which they wouldn't be able to do, unless 
> there was
> ISATAP),

This has nothing to do with ISATAP. With native IPv6 or IPv4 users can
just send each other packets and these packets are in no way less likely
to be malicious than tunnelled packets.

or 2) can the user trust that the 3GPP operator has secured
> *all* of its borders properly, so that either other users, or anyone
> in the internet could not inject maliscious packets to the user. L2
> identification helps with none of this.

It just has to do ingress filtering in the GGSN which from what I know
is default. So you should assume it is default and if anything
explicitly
state this as an assumption/requirement.

> All of these issues are much simpler with something resembling
> configured tunneling, which is why it's preferable. STEP 
> and the like
> are just extensions of that model to make the tunnel easier to
> configure, but the security properties are still the same.

I am not saying work should stop on STEP. What I am saying is that
ISATAP is already being used and has good reasons for that. So the
draft should be quickly adapted to reflect what is deployed and
moved on. That will give us a solution which we can use. Otherwise
we will continue with this standstill situation.

/Karim

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.