Subject: comments on draft-ietf-v6ops-3gpp-analysis-09.txt

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Thu, 25 Mar 2004 23:56:49 +0100

Hi

Some comments on the 3gpp analysis draft:

    Closer details for an applicable tunneling mechanism are not 
    analyzed in this document. However, a simple host-to-router 
    (automatic) tunneling mechanism may be a good fit. There is not yet 
    consensus on the right approach. Primarily, ISATAP [ISATAP] has 
    been proposed, but some issues have been raised about it, such as 
    its unnecessary features and relative complexity for a simple task 
    like this, and its inadequacy in providing security when crossing 
    administrative domains. Proposed solution alternatives have been 
    (at least) a simplified, but probably non-interoperable, version of 
    ISATAP, and STEP [STEP]. In any case, further work is needed to 
    find out the requirements for the scenario and to specify the 
    mechanism.

This paragraph seems to conclude that STEP is the superior solution.
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. 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.

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

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 09:11:00 +0200 (EET)

> This paragraph seems to conclude that STEP is the superior solution.

It can be read both ways, but the intent is not to push any particular 
solution, but to try to present arguments for the both sides.

(co-chair hat on)
This document is on the IESG agenda next week.  Unless they raise 
issues about this, it's likely that it will be changed.

There was a poll on the text on the list on 23 Jan, and no objections 
were seen on the list.  So the current text appears to reflect 
WG rough consensus.
(co-chair hat off)

I'll respond to your arguments in a separate message.

-- 
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: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 09:34:00 +0200 (EET)

Commenting as just another bozo on the bus..

On Thu, 25 Mar 2004, Karim El-Malki (HF/EAB) wrote:
> 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.  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.

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.

> So to start with IMO the above paragraph

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.

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.

> something complex. 

It has much more to it than just RA/RS over a tunnel interface.

> Also there is no need for the sort of security across

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

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

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.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 09:35:03 +0200 (EET)

> issues about this, it's likely that it will be changed.

Oops.. I meant the other way around -- "unlikely that is will be 
changed".

Sorry for too fast typing.