Subject: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 )

From: Gopal Dommety <[email-masked]>
Date: Tue, 15 Feb 2005 12:11:50 -0800

Hello All,

This is a Working Group Last Call for the following I-D:
draft-ietf-mip6-bootstrap-ps-01.txt
Title:
Problem Statement for bootstrapping Mobile IPv6

Please note that the status intended for this I-D is Proposed Standard.

Please review and post your comments by March 3rd, 2005.

-Chairs,

URL-ID is:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 15 Feb 2005 13:48:04 -0800

isnt it supposed to be Informational? AFAIK, problem statement
drafts are Informational.

Vijay

---

From: Gopal Dommety <[email-masked]>
Date: Tue, 15 Feb 2005 18:21:53 -0800

Please note that the status intended for this I-D is Informational (and not 
Proposed Standard as specified in my email).

Thanks to Vijay and Alpesh for pointing it out.

-Gopal

---

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 16 Feb 2005 18:44:05 +0900

Hello, Gopal

I would like to re-comment about this WG I-D.
I think this I-D needs to be refined to clearly state about 
the relationship between the network access service and mobility service,
& local home agent assignment issue.
I raised 3 questions related with this as follows.

Q1. Should the network access service be always performed when a MN bootstraps ? 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 6.  Network Access and Mobility services
[Page 14]
Only having Mobile IPv6 service is not possible, since the Mobile IPv6 protocol requires
ability to send and receive IPv6 packets.  
=> It seems that network access service should be always performed.

Section 7.1  Mobility Service Subscription Scenario
=> There is no words about network access service.

Q2. Does we have to consider the case of  infrastructure-less scenario when we develop a bootstrapping solution or not ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 7.4 Infrastructure-less scenario
[Page 17]
This specific scenario is not supported in this document.  The reason
for this is described in Section 9.
Section 9. Security Considerations
Thus, the case of infrastructure-less network where there is absolutely 
no pre-mediated trust is kept outside of scope of this document.
=> It seems that we don't need to consider the infrastructure-less scenario 
     when we create a bootstrapping solution.

Q3. Does a bootstrapping solution should support local home agent assignment or not ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 5.1.2  Dynamic Home Agent Assignment
[Page 10]
Local home agents
      The mobile node's home ASP may want to allow a local roaming
      partner ASP to assign a local home agent for the mobile node.
      This is useful both from the point of view of communications
      efficiency, and has also been mentioned as one approach to support
      location privacy.
=> What is the exact meaning of the 'useful' and 'also been mentioned' ?
     Is the local home agent function optional[MAY] ?

draft-le-aaa-mipv6-requirements-03.txt
Section 5.5.  Home agent allocation
   Such functionality SHOULD also be considered when designing the AAA
   support for MIPv6 solution.
=> It seems that we SHOULD support the local HA assignment function.
I already know that draft-ietf-mip6-bootstrap-ps is not a I-D that describe the requirement &
draft-le-aaa-mipv6-requirements was expired. 
But i think that we have to decide about this because many different approaches can be come out depending on our decision.

--Junghoon

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Feb 2005 12:10:33 -0800

Here's my nonsecurity related comments on this draft.

Overall: I think the draft is sound in general, and I like the separation
between mobility and access service provider. I believe this distinction is
clearly made. Less clear is the distinction between the access network
service provider and home network service provider, in the traditional
wireless sense. I think this needs to be clarified in order for this
document to clearly lay out the problem of roaming, in the traditional
wireless sense, and I think that might be what is leading to some of the
confusion on the list. I'll provide some suggestions for improvement below.

1) Section 1.3

There are some terms that are used throughout the draft that are not well
defined. For example, trust relationship. I'd suggest adding the following
definitions to this section:

trust relationship - In the context of this draft, trust relationship means
that two parties in question, typically the user of the mobile host and the
mobility or access service provider, have some sort of prior contact in
which the mobile host was provisioned with credentials. These credentials
allow the mobile host to authenticate itself to the mobility or access
service provider and to prove its authorization to obtain service.

infrastructureless relationship - In the context of this draft, an
infrastructureless relationship is one in which the user of the mobile host
and the mobility or access service provider have no previous contact and the
mobile host is not required to supply credentials to authenticate and prove
authorization for service. Mobility and/or network access service is
provided without any authentication or authorization. Infrastructureless in
this context does not mean that there is no network infrastructure, such as
would be the case for an ad hoc network.

credentials - Data or mechanism used by a mobile host to authenticate itself
to a mobility or access network service provider and prove authorization to
receive service. User name/passwords, one time password cards,
public/private key pairs with certificates, biometric information, etc. are
some examples.

I also think some of the terms need modification.  Here are those I would
suggest modifying:

ASA
    Access Service Authorizer. A network operator that authenticates a
mobile host and establishes the mobile host's authorization to receive
Internet service.

ASP
    Access Service Provider. A network operator that provides direct IP
packet forwarding to and from the end host.

Serving Network Access Provider.
    A network operator that is the mobile host's ASP but not its ASA. The
roaming network accesss provider may or may not additionally provide
mobility service.

Home Network Access Provider.
    A network operator that is both the mobile host's ASP and ASA. The home
network access provider may or may not additionally provide mobility service
(note that this is a slighlty different definition from RFC 3775).

IASP
    Integrated Access Service Provider. A service provider that provides
both authorization for network access and also provides mobility service.

MSA
    Mobility Service Authorizer. A service provider that authorizes Mobile
IPv6 service.

MSP
    Mobility Service Provider. A service provider that provides Mobile IPv6
service. In order to obtain such service, the mobile host must be
authenticated and prove authorization to obtain the service.

Home Mobility Service Provider.
    A MSP that both provides mobility service and authorizes it.

Serving Mobility Service Provider.
    A MSP that provides mobility service but depends on another service
provider to authorize it.

Roaming
    When the mobile host is receiving network access service from a network
other than its home network, it is said to be roaming.

2)  Section 6 needs to be modified to more clearly define roaming, using the
terminology defined above. I would suggest rewriting paragraph 3 as follows:

If the mobile host is within the geographical area in which network access
service is not provided by its home network access service provider, the
mobile host is roaming. The home network access service provider in this
case acts as the access service authorizer, but the actual network access is
provided by the serving network access provider. During the authentication
and authorization prior to the mobile host having Internet access, the
serving network access provider may simply act as a routing agent for
authentication and authorization back to the access service authorizer, or
it may require an additional authentication and authorization step itself.
An example of a roaming situation is when a business person is using a
hotspot service in an airport, and the hotspot service provider has a
roaming agreement with the business person's cellular provider. In that
case, the hotspot network is acting as the serving network access provider,
while the cellular network is acting as the access service authorizer. When
the business person moves from the hotspot network to the cellular network,
the cellular network is both the home access service provider and the access
service authorizer.

Also, I think paragraph 5 would benefit from the following change:

Mobility service using Mobile IPv6 is conceptually and possibly also in
practice separate from network access service, though of course network
access is required prior to providing mobility. Mobile IPv6 service enables
an IPv6 host to maintain its reachability despite changing its network
attachment point (subnets). A network operator providing Mobile IPv6 service
is called a mobility service provider (MSP). Granting Mobile IPv6 service
requires a host to authenticate and prove authorization for the service. A
network operator that authenticates a mobile host and authorizes mobility
service is called a mobility service authorizer. If both types of operation
are performed by the same operator, that operator is called a home mobility
service provider. If authentication and authorization is provided by one
operator and the actual service is provider by another, the operator
providing the service is called the serving mobility service provider. The
serving MSP must contact the mobile host's mobility service authorizer to
check the mobile host's authorization prior to granting mobility service.

Finally, I think that paragraph 8 needs modification. Here's a suggested
change:

The service model defined here clearly separates the entity providing the
service from the entity that authentications and authorizes the service. In
the case of basic network access, this supports the traditional and
well-known roaming model, in which inter-operator roaming agreements allow a
host to obtain network access in areas where their home network access
provider does not have coverage. In the case of mobility service, this
allows a roaming mobile host to obtain mobility service in the local
operator's network while having that service authorized by the home
operator. The service model also allows mobility service and network access
service to be provided by different entities. This allows a network operator
with no wireless access, like, for example, an enterprise network operator,
to deploy a Mobile IPv6 home agent for mobility service while the actual
wireless network access is provided by the serving network access providers
with which the enterprise operator has a contract. Here are some other
possible combinations of ASPs and MSPs:

I would drop paragraphs 4, 6, and 7, since they talk about mechanisms rather
than the service model, and this section is really about the service model.

The bullet list after paragraph 8 and paragraph 9 both look OK.

I'll send comments on Section 9 in a separate message.

            jak

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 18 Feb 2005 13:39:42 +0900

Hello James and ALL.
It's very cool.
Please see my comments inline.

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; "Gopal Dommety" <[email-masked]>
Sent: Friday, February 18, 2005 5:10 AM
Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt(ProblemStatement for bootstrapping Mobile IPv6 )

> which the mobile host was provisioned with credentials. 

> These credentials allow the mobile host to authenticate itself to the mobility or access

I would like to change like below if my understanding of your terminology is correct.
"These credentials allow the mobile host to authenticate itself to the mobility or access
service --authorizer-- and to prove its authorization to obtain service"

> authorization for service. 

> Mobility and/or network access service is provided without any authentication or authorization. 
> Infrastructureless in this context does not mean that there is no network infrastructure, such as

The notable point of the above phrase is the use of "Mobility and/or network access service" not
"Mobility and/or network access authorizer".
I like this so much. It's very clear.
I hope to see this definition in the next version of this I-D.

> roaming network accesss provider may or may not additionally provide

What about changing the "Serving Network Access Provider" to "Roaming Network Access Provider" ?
This is not significant, it's just a choice.

> provider to authorize it.

What about changing the "Serving Mobility Service Provider" to "Roaming Mobility Service Provider" ?

> the cellular network is both the home access service provider and the access

Yes it's clear.

> check the mobile host's authorization prior to granting mobility service.

I like this way, if you agree with the change of the terminology.
"If authentication and authorization is provided by one operator and the actual service is provider by another, the operator providing the service is called the "roaming" mobility service provider."
This is also a choice.

> service from the entity that authentications and authorizes the service. 

This is the point what i like your expression.
I think, we're using of terminology, "service provider" to express the different entities.
This point should be applied to the next version of this I-D.

I think we can utilize this James' work to build-up our MIP6 bootstrapping framework.

--Junghoon 

> In the case of basic network access, this supports the traditional and

---

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Feb 2005 10:23:23 -0800

> service --authorizer-- and to prove its authorization to obtain service"

Yes, that's right, thanx for catching it. I forgot to change this before I
sent the email.

> This is not significant, it's just a choice.

Actually, that's how I orginally had it, but I changed it to "serving" to be
consistent with the terminology in Section 6.

One problem here is the terminology used by other SDOs. I think 3GPP and
3GPP2 use "serving" to describe the roaming operator. Worse, however, is the
terminology used by 802.11. They define "roaming" as what IETF or the 3Gs
would call "handover", that is when a terminal moves from one access point
to another. We don't have to be bound by the terminology used by other SDOs,
but they will certainly read this document so we need to make sure terms are
well defined. Personally, I don't mind which term is used, so long as it is
well defined an consistently applied.

> What about changing the "Serving Mobility Service Provider" to "Roaming
Mobility Service Provider" ?

Again, fine.

> "If authentication and authorization is provided by one operator and the
actual service is provider by another, the operator providing the service is
called the "roaming" mobility service provider."
> This is also a choice.

OK.

            jak