Subject: [MEXT] AD review of draft-korhonen-mip6-service-03.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Oct 2007 10:23:08 +0300

Jouni asked me to AD sponsor this document. Here's
my review.

I support the extension proposed in the document,
but there are a number of issues relating to how
these values are defaulted, tight coupling to MN-NAI,
whether these options appear in the first or all
messages, and a few other things.

I expect a revised ID. I proposed text for some of the
issues that below, in some cases you need to still work
on it.

Substantial:

>    o  In absence of the Service Selection option the home agent may
>       provide, based on operator policies, a default service.  For
>       example, a plain Internet access could be an operator's default
>       mobility service.
>   

The fact that there is no standard "default" and the proliferation
of various operator conventions and policies has caused significant
problems in GPRS and UMTS data access. I would not like to repeat
this mistake here.

One of way of avoiding this problem is to mandate that you do
have a default. Suggested edit:

OLD:
In absence of the Service Selection option the home agent may
provide, based on operator policies, a default service. For
example, a plain Internet access could be an operator's default
mobility service.
NEW:
In absence of the Service Selection option the home agent MUST
act as if the default service, plain Internet access had been
requested. There is no absolute requirement that this default service be
allowed to all customers, but it is highly RECOMMENDED in
order to avoid having normal users employ operator-specific
configuration values in order to get basic service.

> The Service Selection option should be used in
>    combination with the Mobile Node Identifier option during the initial
>    Binding Update at the beginning of the mobility session.
I do not see a reason to make this MNID specific. Also, the
concept of a mobility session isn't necessarily well-defined, if
home agents can reboot, etc. Reformulated:

OLD:
The Service Selection option should be used in
combination with the Mobile Node Identifier option during the initial
Binding Update at the beginning of the mobility session.
NEW:
The Service Selection option should be used in every Binding
Update that makes a registration to the home agent.

And then you should probably add text somewhere to
talk about the case where the service id suddenly changes
and this no longer fits with the home address allocation, etc.

>    The Service Selection mobility option can be included in any Mobile
>    IPv6 Mobility Header message. 
This is inconsistent with Section 2. I'm not sure I see a need
for this option to appear in other messages than the BU.
Please reformulate.

>    This option MAY be included in the initial Binding Update message
>    when registering to a home agent at the beginning of the mobility
>    session.  The MN-NAI option SHOULD be included in the Binding Update
>    message when the Service Selection option is used.  Sending the
>    Service Selection option in any Binding Update message is not
>    prohibited. 

See above for tight coupling to MN-NAI option or the initial
BUs.

> It should be noted that sending this option to
>    correspondent nodes makes little or no sense unless the home agent
>    and the correspondent nodes share the same knowledge of provided
>    mobility services.
Be more specific. SHOULD NOT be sent? Presumably, depending
on what kind of service you got, you will or will be able to reach the
CNs directly. In either case, it should be OK to attempt RO.

>    o  Identifier: A variable length service identifier string used to
>       identify the requested service.  The Identifier string is encoded
>       as a host name or a fully qualified domain name as defined in [4]
>       and [5].  The Identifier MAY be resolveable by DNS.
>
>       'internet', 'internet.example.com', 'voip.example.com' and
>       'voip.companyxyz.example.com' are valid examples of Service
>       Selection option Identifier strings.  At minimum the Identifier
>       must be unique among the home agents the mobile node is authorized
>       to register to.
>   

Something like "internet" would not be unique among the home
agents, if I the mobile node is allowed to use two different
operators, for instance.

Are there existing APN conventions in GPRS networks that are
based on domain names? Or are you inventing a convention here?

Another alternative might be to just say "UTF-8" and that the
value is up to a local policy. And unique within a particular
home agent.

> The Service
>    Selection option is intended to be used with the MN-NAI option, but
>    it is also possible to use Home Address to identify the mobile node
>    as defined in [1].
See above about the coupling to MN-NAI.

Editorial:

>    Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that
>    provides a flexible way to identify mobile nodes using other
>    identifiers than IPv6 addresses.  Example of such identifier is a
>    Network Access Identifier (NAI) [2].
There are multiple ways of identifying the mobile node, and the NAI is
just one of them. Suggested rewrite:

OLD:
Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that
provides a flexible way to identify mobile nodes using other
identifiers than IPv6 addresses. Example of such identifier is a
Network Access Identifier (NAI) [2].
NEW:
Mobile IPv6 [1] can identify mobile nodes in various ways, including
home addresses [1], Network Access Identifiers (NAIs) [2, 3], and
credentials suitable for IKEv2 [RFC 4877].

> The service selection may affect home
>    agent routing decisions and Home Address or Home Network Prefix
>    assignment policies. 
Or firewall and security policies. Suggested edit:

OLD:
The service selection may affect home
agent routing decisions and Home Address or Home Network Prefix
assignment policies.
NEW:
The service selection may affect home
agent routing decisions, Home Address or Home Network Prefix
assignment policies, firewall settings, and security policies.

Jari

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Oct 2007 10:09:40 -0700

Hi Jari,

A couple of comments.

> configuration values in order to get basic service.

This is a good idea. Completely agree.

> for this option to appear in other messages than the BU.

We should probably not say anything here. There is no need to restrict 
it to the Binding Update and at the same time no need to claim that it 
can be used in any mobility header message.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Oct 2007 23:49:25 +0300

Vijay,

> can be used in any mobility header message.

I think you need to define what the behaviour should be
when you receive this. I'm not sure its obvious. What should
you do if you receive this in a BA or BE, for instance?

Jari

---

From: <[email-masked]>
Date: Tue, 2 Oct 2007 10:15:40 +0200

Hi Jari,

Thanks for the extensive review. Some comments inline.

> Sent: Monday, October 01, 2007 10:23 AM
> 
> Jouni asked me to AD sponsor this document. Here's my review.
> 
> I support the extension proposed in the document, but there 
> are a number of issues relating to how these values are 
> defaulted, tight coupling to MN-NAI, whether these options 
> appear in the first or all messages, and a few other things.
> 
> I expect a revised ID. I proposed text for some of the issues 
> that below, in some cases you need to still work on it.
> 
> Substantial:
> 
> The fact that there is no standard "default" and the 
> proliferation of various operator conventions and policies 
> has caused significant problems in GPRS and UMTS data access. 
> I would not like to repeat this mistake here.

Agree on this. This actually has given headache in several
occasions e.g. in our services deployments. Dunno how we
managed to repeat it in this I-D in the first place...

> example, a plain Internet access could be an operator's 
> default mobility service.
> NEW:
> In absence of the Service Selection option the home agent 
> MUST act as if the default service, plain Internet access had 
> been requested. There is no absolute requirement that this 
> default service be allowed to all customers, but it is highly 
> RECOMMENDED in order to avoid having normal users employ 
> operator-specific configuration values in order to get basic service.

OK by me.

> concept of a mobility session isn't necessarily well-defined, 
> if home agents can reboot, etc. Reformulated:

Hmmm.. right. "should" is not exactly mandating the use of MNID.
Agree on the mobility session ambiguity.

> OLD:
> The Service Selection option should be used in combination 
> with the Mobile Node Identifier option during the initial 

OK.

> And then you should probably add text somewhere to talk about 
> the case where the service id suddenly changes and this no 
> longer fits with the home address allocation, etc.

Good point. I actually had some thoughts to write a bit about this
scenario. My initial thinking was that if the service id changes mid
session and the HA cannot agree with the new service, the HA
would reject the binding and send back a BA with an error code
indicating the administrative decision.

> This is inconsistent with Section 2. I'm not sure I see a 
> need for this option to appear in other messages than the BU.
> Please reformulate.

Right. Agree.

> See above for tight coupling to MN-NAI option or the initial BUs.

Ack.

> on what kind of service you got, you will or will be able to 
> reach the CNs directly. In either case, it should be OK to attempt RO.

Yes, attempting RO should be ok in all cases. I should probably
only say here:

   The service selection option SHOULD NOT be send to a correspondent
   node. The mobile node cannot assume that the correspondent node
   has any knowledge about a specific service selection done between
   the mobile node and the home agent.

> agents, if I the mobile node is allowed to use two different 

IMHO that falls to roaming contract arrangement part and in that
case something like "internet" can definitely be agreed on to
be unique among operators the mobile node is allowed to roam
with. Bad choice of example, I can change that.

> based on domain names? Or are you inventing a convention here?

APNs are have two parts: the Netword Identified (NI) and the Operator
Identifier (OI). The NI is mandatory e.g. plain "voip" in the above
example and the optional OI is the domain name e.g. "example.com".
Of cource GPRS APN domain name convention are more akward than in
the above example. So no inventing a convention here.
 
> value is up to a local policy. And unique within a particular 

Hmmm.. could be ok. Need to think about this.

> See above about the coupling to MN-NAI.

Ack.

> There are multiple ways of identifying the mobile node, and 
> the NAI is just one of them. Suggested rewrite:
> 
> OLD:
> Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) 
> [6] that provides a flexible way to identify mobile nodes 
> using other identifiers than IPv6 addresses. Example of such 
> identifier is a Network Access Identifier (NAI) [2].
> NEW:
> Mobile IPv6 [1] can identify mobile nodes in various ways, 
> including home addresses [1], Network Access Identifiers 
> (NAIs) [2, 3], and credentials suitable for IKEv2 [RFC 4877].

Good. Thanks.

> agent routing decisions and Home Address or Home Network 
> Prefix assignment policies.
> NEW:

OK. Thanks,

Cheers,
	Jouni

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Oct 2007 12:32:54 +0300

> indicating the administrative decision.

This is fine.

>    the mobile node and the home agent.

Ok.

> Hmmm.. could be ok. Need to think about this.

It is still unclear to me what the best choice is.

Jari

---

From: <[email-masked]>
Date: Wed, 3 Oct 2007 10:55:49 +0200

> >> Are there existing APN conventions in GPRS networks that 
> are based on 
> >> domain names? Or are you inventing a convention here?
> >
> > Of cource GPRS APN domain name convention are more akward 
> than in the 
> > above example. So no inventing a convention here.
> >   
> >> Another alternative might be to just say "UTF-8" and that 
> the value 
> >> is up to a local policy. And unique within a particular home agent.
> >

For a wider applicability, not just for one specific scenario, I
think UTF-8 could be the way to go. Just like you proposed earlier.
If some SDO or alikes need more specific definition they can do it
within their own architecture specifications.

Cheers,	
	jouni

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Oct 2007 12:17:00 +0300

Jouni,

> within their own architecture specifications.
That would work for me.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Oct 2007 08:54:48 +0300

The new version addresses the concerns I had. Thanks. The document will
now be moved forward.

Jari

---

From: <[email-masked]>
Date: Tue, 30 Oct 2007 10:59:35 +0100

There was comment I received offline pointing out that description
of the service selection option identifier in -04 does not mention
DNS anymore. In -03 it read
  "The Identifier MAY be resolveable by DNS."
I think it could be put back. The new text could be:

"  o  Type: 8-bit identifier set to TBD (to be defined by IANA) of the
      type of the skipable mobility option. Depending on the system
      deployment the Identifier MAY be resolveable by DNS."

Any thoughts? 

Cheers,
	Jouni

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, October 22, 2007 8:55 AM
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt
> 
> 
> The new version addresses the concerns I had. Thanks. The 
> document will now be moved forward.
> 
> Jari
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 30 Oct 2007 16:28:21 +0200

I'm wary of specifying something might be found in DNS or
might not.

Also, do we have any evidence that we actually need the identifiers to
be resolved by DNS? In any case, no one would turn on service
for a particular domain without an agreement in place with that
domain. So the box initiating a VPN tunnel simply has to have
configuration for that domain, its not enough for the DNS query
to succeed.

Jari