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

["Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>]

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