Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues

From: Soliman Hesham <[email-masked]>
Date: Sun, 28 Sep 2003 04:35:34 -0400

> Do you have an alternate wording suggestion in mind which 
 > would keep the
 > essence of the original text (including "don't tunnel from 
 > UE")?  This
 > doesn't and is unacceptable to me..

=> I didn't ask to have "don't tunnel from the UE"
in the text. I was commenting on the new text.
I don't think the draft should include opinions on how 
easy it is to upgrade to V6 and whether that involves
SW or HW upgrades. It's not useful. 

My other comment is on the roaming case. Specific answer
below.

 > 
 > On Sun, 28 Sep 2003, Soliman Hesham wrote:
 > >  > *)
 > >  >     However, the UE may attach to a 3GPP network, in which 
 > >  > the Serving
 > >  >     GPRS Support Node (SGSN), the GGSN and the Home 
 > Location Register
 > >  >     (HLR) support IPv4 PDP contexts, but may not 
 > support IPv6 PDP
 > >  >     contexts. If the 3GPP network does not support IPv6 
 > PDP contexts,
 > >  >     and an application on the UE needs to communicate 
 > with an IPv6(-
 > >  >     only) node, the UE may activate an IPv4 PDP context and 
 > >  > encapsulate
 > >  >     IPv6 packets in IPv4 packets using a tunneling mechanism. 
 > > 
 > > This
 > >  >     might happen in very early phases of IPv6 deployment. 
 > > 
 > > => Please remove this sentence. This is an opinion and does not
 > > apply to the roaming case where the home operator has deployed
 > > IPv6 but the visited operator didn't.
 > >
 > >   To 
 > >  > generally
 > >  >     solve this problem (IPv6 not available in the 3GPP 
 > network), this
 > >  >     document strongly recommends the 3GPP operators to 
 > deploy basic
 > >  >     IPv6 support in their GPRS networks, 
 > > 
 > > => This does not apply to the roaming case, so it doesn't solve
 > > the problem stated above.
 > 
 > These are two quotes are intentional.  IPv6 support will 
 > work when the
 > visited networks also have upgraded to this minimal IPv6 
 > support.  

=> (drifting from the original comment but I'll answer 
this as a side issue). Supporting PDP type V6 is not a 
minimal support because it implies that the network behind
the SGSN supports v6, i.e. GGSN, DNS ...etc.

   That's 
 > also expected to happen during the early phases of 
 > transition.  If the 
 > operator doesn't care about IPv6 users at all, the users can 
 > just stay out 
 > of those networks.

=> The point is: Your operator cares about v6 and wants 
to offer you the services that IPv6 enables while you're
roaming. It is not relevant how the visited operator feels
about v6. So to work around this, you need to use something
to enable you to tunnel to a router in the home network. 
IMO ISATAP fits nicely in this model. But the point is, 
requiring an operator to support v6 will not necessarily
eliminate tunneling when the UE roams to another network
(whose managers don't want to support v6 and will implement
v6ops recommendations). 

 > 
 > We discussed previously several other options, such as 
 > trying to open the
 > IPv6 PDP context to an operator (if there are many) which in 
 > fact supports
 > IPv6.  This would be useful in the case that 3G + IPv6 gains market
 > momentum as there are typically multiple networks in a 
 > region one could
 > roam to.  I'm not sure how many of those ended up in the document.
 > 
 > The bottom line is that as we deploy dual stack UE's, when IPv6 isn't
 > supported in the visited network, one can just use IPv4 if 
 > all the tricks
 > fail.  

=> So , "other tricks" do not include tunneling? Why not?

  No tunneling needed at the UE.  Further, tunneling at 
 > the UE is 
 > counter-productive, as it doesn't give the *visited networks* _any_ 
 > incentive to deploy IPv6 in the first price, which is the number one 
 > priority.

=> But in this case the visited network doesn't care about 
v6. I'm not sure how eliminating the use of V6 through 
a tunnel will give the visited network an incentive to
deploy v6.

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Sep 2003 12:40:18 +0300 (EEST)

> SW or HW upgrades. It's not useful. 

It seems very useful to me, although the wording may not be optimal.  If 
upgrading to v6 is relatively easy, we can recommend upgrading to IPv6.

> the SGSN supports v6, i.e. GGSN, DNS ...etc.

When your network infrastructure includes hundreds of boxes, enabling v6 
support in about 3 of them could be seen as very minimal.

Note: I think it might be useful to try to describe in the document what 
constitutes a bare miminal IPv6 support.. just spell it out.  DNS 
certainly is *not* required.

> to offer you the services that IPv6 enables 

Right so far..

> while you're
> roaming. 

If your SP wants to enable services while you're roaming, your SP needs to 
convince those networks it has roaming agreements with to enable v6? 

> It is not relevant how the visited operator feels
> about v6. 

I fear this is very relevant.  Your home operator can't really offer what 
it can't provide.  So, it should not *guarantee* you IPv6 services while 
you roam, as simple as that..

> So to work around this, you need to use something
> IMO ISATAP fits nicely in this model. 

That's a detail at this point, but this is certainly at odds with the 
ISATAP security model.

> But the point is, 

So, don't use v6 in those networks then?

> => So , "other tricks" do not include tunneling? Why not?

That'd de-facto require implementation of a number of transition
mechanisms in UE's, with caveats those entail, making it much more
complex.
 
> a tunnel will give the visited network an incentive to

For example, if the customers select a different operator when they roam
because the one they tried first doesn't support v6 ("v4-only operator
loses customers and thus money"), I guess the operator which didn't
support v6 would start to see some benefit in deploying v6 if the number
of users warrants that.  There could also be some PR gains/losses involved
here.

-- 
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: Fred Templin <[email-masked]>
Date: Mon, 29 Sep 2003 16:06:32 -0700

Pekka,

>That's a detail at this point, but this is certainly at odds with the 

As the lead ISATAP author, I must ask what you see as
the problem with the ISATAP security model in this
context?

Thanks - Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 10:48:45 +0300 (EEST)

Let's try not to get sidetracked too much on ISATAP..

> the problem with the ISATAP security model in this

The ISATAP spec employs automatic tunneling within a site, trusting the
other nodes in the site (that alone is pretty serious, but it gets worse).  
When you have access to an ISATAP link, you can do pretty much everything
on that link (especially due to the current, flexibility tradeoffs -- see
Appendix D on the spec).

That may be more-or-less fine under a single administrative domain, where
such trust relations may (or may not) be assumed, but in this particular
case, the ISATAP link would consist of the 3GPP operator and all the
ISATAP-using UE's.  Every UE is basically untrusted by the others (and by
the 3GPP operator, but that's not so relevant here).

Thus, I fail to see how something like ISATAP could be even be considered
for use in this scenario.

---

From: Fred Templin <[email-masked]>
Date: Tue, 30 Sep 2003 09:59:03 -0700

Pekka,

>on that link (especially due to the current, flexibility tradeoffs -- see

The RPF checks for ingress filtering in draft -15 are a bit too loose
(hence appendix D) while those in earlier draft versions were a bit
too restrictive. This will be corrected in draft -16 (due out soon),
and appendix D will be removed.

>the 3GPP operator, but that's not so relevant here).

Not quite true; in the 3GPP environment we have link-layer
authentication mechanisms associated with the IPv4 PDP context
and ingress filtering to prevent IPv4 source address spoofing. Since
the ISATAP RPF checks for ingress filtering build on the link-layer
(IPv4) mechanisms, the IPv4 PDP context provides a trust basis.

Fred
[email-masked]