< draft-ietf-mip6-bootstrap-ps-04.txt   draft-ietf-mip6-bootstrap-ps-05.txt >
MIP6 A. Patel, Ed. MIP6 A. Patel, Ed
Internet-Draft Cisco Internet-Draft Cisco
Expires: July 6, 2006 G. Giaretta, Ed. Expires: November 27, 2006 G. Giaretta, Ed
TILAB Telecom Italia
January 2, 2006 May 26, 2006
Problem Statement for bootstrapping Mobile IPv6 Problem Statement for bootstrapping Mobile IPv6
draft-ietf-mip6-bootstrap-ps-04 draft-ietf-mip6-bootstrap-ps-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 6, 2006. This Internet-Draft will expire on November 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
A mobile node needs at least the following information: a home A mobile node needs at least the following information: a home
address, home agent address and a security association with home address, home agent address and a security association with home
agent to register with the home agent. The process of obtaining this agent to register with the home agent. The process of obtaining this
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3
1.2. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 1.2. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10 5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10
5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Dynamic Home Address Assignment . . . . . . . . . . . 10 5.1.1. Dynamic Home Address Assignment . . . . . . . . . . . 10
5.1.2. Dynamic Home Agent Assignment . . . . . . . . . . . . 11 5.1.2. Dynamic Home Agent Assignment . . . . . . . . . . . . 11
5.1.3. Management requirements . . . . . . . . . . . . . . . 12 5.1.3. "Opportunistic" or "Local" Discovery . . . . . . . . . 12
5.1.4. Management Requirements . . . . . . . . . . . . . . . 12
5.2. Security Infrastructure . . . . . . . . . . . . . . . . . 12 5.2. Security Infrastructure . . . . . . . . . . . . . . . . . 12
5.2.1. Integration with AAA Infrastructure . . . . . . . . . 12 5.2.1. Integration with AAA Infrastructure . . . . . . . . . 12
5.2.2. "Opportunistic" or "Local" Discovery . . . . . . . . . 13
5.3. Topology Change . . . . . . . . . . . . . . . . . . . . . 13 5.3. Topology Change . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13 5.3.1. Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13
6. Network Access and Mobility services . . . . . . . . . . . . . 14 6. Network Access and Mobility services . . . . . . . . . . . . . 14
7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 16 7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 16
7.1. Mobility Service Subscription Scenario . . . . . . . . . . 16 7.1. Mobility Service Subscription Scenario . . . . . . . . . . 16
7.2. Integrated ASP network scenario . . . . . . . . . . . . . 16 7.2. Integrated ASP network scenario . . . . . . . . . . . . . 16
7.3. Third party MSP scenario . . . . . . . . . . . . . . . . . 17 7.3. Third party MSP scenario . . . . . . . . . . . . . . . . . 17
7.4. Infrastructure-less scenario . . . . . . . . . . . . . . . 18 7.4. Infrastructure-less scenario . . . . . . . . . . . . . . . 18
8. Parameters for authentication . . . . . . . . . . . . . . . . 19 8. Parameters for Authentication . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Security Requirements of Mobile IPv6 . . . . . . . . . . . 21 9.1. Security Requirements of Mobile IPv6 . . . . . . . . . . . 21
9.2. Threats to the Bootstrapping Process . . . . . . . . . . . 22 9.2. Threats to the Bootstrapping Process . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
13. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 27 13. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 27
14. Informative References . . . . . . . . . . . . . . . . . . . . 27 14. Informative References . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
Mobile IPv6 [RFC3775] specifies mobility support based on the Mobile IPv6 [RFC3775] specifies mobility support based on the
assumption that a mobile node has a trust relationship with an entity assumption that a mobile node (MN) has a trust relationship with an
called the home agent. Once the home agent address has been learned entity called the home agent. Once the home agent address has been
(for example via manual configuration, anycast discovery mechanisms, learned (for example via manual configuration, anycast discovery
or DNS lookup), Mobile IPv6 signaling messages between the mobile mechanisms, or DNS lookup), Mobile IPv6 signaling messages between
node and the home agent are secured with IPsec or with the the mobile node and the home agent are secured with IPsec or with the
authentication protocol as defined in [RFC4285]. The requirements authentication protocol as defined in [RFC4285]. The requirements
for this security architecture are created with [RFC3775] and the for this security architecture are created with [RFC3775] and the
details of this procedure are described in [RFC3776]. details of this procedure are described in [RFC3776].
In [RFC3775] there is an implicit requirement that the MN be In [RFC3775] there is an implicit requirement that the MN be
provisioned with enough information that will permit it to register provisioned with enough information that will permit it to register
successfully with its home agent. However, having this information successfully with its home agent. However, having this information
statically provisioned creates practical deployment issues. statically provisioned creates practical deployment issues.
This document serves to define the problem of bootstrapping. This document serves to define the problem of bootstrapping.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
Bootstrapping is defined as obtaining enough information at the Bootstrapping is defined as obtaining enough information at the
mobile node so that the mobile node can successfully register with an mobile node so that the mobile node can successfully register with an
appropriate home agent. Specifically, this means obtaining the home appropriate home agent. Specifically, this means obtaining the home
agent address and home address, and for the mobile node and home agent address and home address, and for the mobile node and home
agent to authenticate and mutually construct security credentials for agent to authenticate and mutually construct security credentials for
Mobile IPv6. Mobile IPv6.
Typically, bootstrapping happens when a mobile node does not have all Typically, bootstrapping happens when a mobile node does not have all
the information it needs to setup the Mobile IPv6 service. This the information it needs to setup the Mobile IPv6 service. This
includes, but is not limited to, the mobile node (MN) not having any includes, but is not limited to, the mobile node not having any
information when it boots up for the first time (out of the box), it information when it boots up for the first time (out of the box), it
does not retain any information during reboots, etc. does not retain any information during reboots, etc.
Also, in certain scenarios, after the MN bootstraps for the first Also, in certain scenarios, after the MN bootstraps for the first
time (out of the box), subsequent bootstrapping is implementation- time (out of the box), the need for subsequent bootstrapping is
dependent. For instance, the MN may bootstrap every time it boots, implementation-dependent. For instance, the MN may bootstrap every
bootstrap everytime on prefix change, bootstrap periodically to time it boots, bootstrap everytime on prefix change, bootstrap
anchor to an optimal (distance, load etc) HA, etc. periodically to anchor to an optimal (distance, load etc) HA, etc.
1.3. Terminology 1.3. Terminology
General mobility terminology can be found in [RFC3753]. The General mobility terminology can be found in [RFC3753]. The
following additional terms are used here: following additional terms are used here:
Trust relationship Trust relationship
In the context of this draft, trust relationship means that two In the context of this draft, trust relationship means that the
parties in question, typically the user of the mobile host and the two parties in question, typically the user of the mobile host and
mobility or access service authorizer , have some sort of prior the mobility or access service authorizer , have some sort of
contact in which the mobile node was provisioned with credentials. prior contact in which the mobile node was provisioned with
These credentials allow the mobile node to authenticate itself to credentials. These credentials allow the mobile node to
the mobility or access service provider and to prove its authenticate itself to the mobility or access service provider and
authorization to obtain service. to prove its authorization to obtain service.
Infrastructureless relationship Infrastructureless relationship
In the context of this draft, an infrastructureless relationship In the context of this draft, an infrastructureless relationship
is one in which the user of the mobile node and the mobility or is one in which the user of the mobile node and the mobility or
access service provider have no previous contact and the mobile access service provider have no previous contact and the mobile
node is not required to supply credentials to authenticate and node is not required to supply credentials to authenticate and
prove authorization for service. Mobility and/or network access prove authorization for service. Mobility and/or network access
service is provided without any authentication or authorization. service is provided without any authentication or authorization.
Infrastructureless in this context does not mean that there is no Infrastructureless in this context does not mean that there is no
network infrastructure, such as would be the case for an ad-hoc network infrastructure, such as would be the case for an ad-hoc
skipping to change at page 5, line 43 skipping to change at page 5, line 43
Serving Network Access Provider Serving Network Access Provider
A network operator that is the mobile node's ASP but not its ASA. A network operator that is the mobile node's ASP but not its ASA.
The serving network access provider may or may not additionally The serving network access provider may or may not additionally
provide mobility service. provide mobility service.
Home Network Access Provider Home Network Access Provider
A network operator that is both the mobile node's ASP and ASA. A network operator that is both the mobile node's ASP and ASA.
The home network access provider may or may not additionally The home network access provider may or may not additionally
provide mobility service (note that this is a slighlty different provide mobility service (note that this is a slightly different
definition from RFC 3775). definition from RFC 3775).
IASP IASP
Integrated Access Service Provider. A service provider that Integrated Access Service Provider. A service provider that
provides both authorization for network access, and mobility provides both authorization for network access, and mobility
service. service.
MSA MSA
skipping to change at page 7, line 7 skipping to change at page 7, line 7
A MSP that both provides mobility service and authorizes it. A MSP that both provides mobility service and authorizes it.
Serving Mobility Service Provider Serving Mobility Service Provider
A MSP that provides mobility service but depends on another A MSP that provides mobility service but depends on another
service provider to authorize it. service provider to authorize it.
2. Assumptions 2. Assumptions
o A basic assumption in the Mobile IPv6 [RFC3775] is that there is a o A basic assumption in Mobile IPv6 [RFC3775] is that there is a
trust relationship between the mobile node and its home agent(s). trust relationship between the mobile node and its home agent(s).
This trust relationship can be direct, or indirect through, for This trust relationship can be direct, or indirect through, for
instance, an ASP that has a contract with the MSP. This trust instance, an ASP that has a contract with the MSP. This trust
relationship can be used to bootstrap the MN. relationship can be used to bootstrap the MN.
One typical way of verifying the trust relationship is using One typical way of verifying the trust relationship is using
authentication, authorization, and accounting (AAA) authentication, authorization, and accounting (AAA)
infrastructure. In this document, two distinct uses of AAA are infrastructure. In this document, two distinct uses of AAA are
considered: considered:
skipping to change at page 7, line 32 skipping to change at page 7, line 32
AAA for Mobility Service AAA for Mobility Service
This functionality provides authentication and authorization This functionality provides authentication and authorization
for mobility services. for mobility services.
These functionalities may be implemented in a single entity or in These functionalities may be implemented in a single entity or in
different entities, depending on the service models described in different entities, depending on the service models described in
Section 6 or deployment scenarios as described in Section 7. Section 6 or deployment scenarios as described in Section 7.
o Yet another assumption is that some identifier, such as an NAI, as o Some identifier, such as an Network Access Identifier (NAI), as
defined in [RFC4283] or [RFC2794] is provisioned on the MN which defined in [RFC4283] or [RFC2794] is provisioned on the MN which
permits the MN to identify itself to the ASP and MSP. permits the MN to identify itself to the ASP and MSP.
3. Design Goals 3. Design Goals
A solution to the bootstrapping problem has the following design A solution to the bootstrapping problem has the following design
goals: goals:
o The following information must be available at the end of o The following information must be available at the end of
bootstrapping, to enable the MN to register with the HA. bootstrapping, to enable the MN to register with the HA.
* MN's home agent address * MN's home agent address
* MN's home address * MN's home address
* IPsec SA between MN and HA, IKE pre-shared secret between MN * IPsec SA between MN and HA, IKE pre-shared secret between MN
and HA, or shared secret/security association for and HA
authentication protocol [RFC4285]
o The bootstrapping procedure can be triggered at any time, either o The bootstrapping procedure can be triggered at any time, either
by the MN or by the network. Bootstrapping can occur, for by the MN or by the network. Bootstrapping can occur, for
instance due to administrative action, information going stale, HA instance due to administrative action, information going stale, HA
indicating the MN etc. Bootstrapping may be initiated even when indicating the MN etc. Bootstrapping may be initiated even when
the MN is registered with the HA and has all the required the MN is registered with the HA and has all the required
credentials. This may typically happen to refresh/renew the credentials. This may typically happen to refresh/renew the
credentials. credentials.
o Subsequent protocol interaction (for example updating the IPsec o Subsequent protocol interaction (for example updating the IPsec
skipping to change at page 8, line 41 skipping to change at page 8, line 40
involving the infrastructure that was used during bootstrapping. involving the infrastructure that was used during bootstrapping.
o Solutions to the bootstrapping problem should enable storage of o Solutions to the bootstrapping problem should enable storage of
user-specific information on entities other than the home agent. user-specific information on entities other than the home agent.
o Solutions to the bootstrapping problem should not exclude storage o Solutions to the bootstrapping problem should not exclude storage
of user-specific information on entities other than the home of user-specific information on entities other than the home
agent. agent.
o Configuration information which is exchanged between the mobile o Configuration information which is exchanged between the mobile
node and the home agent needs to be secured using integrity and node and the home agent must be secured using integrity and replay
replay protection. Confidentiality protection should be provided protection. Confidentiality protection should be provided if
if necessary. necessary.
o All feasible deployment scenarios, along with the relevant o The solution should be applicable to all feasible deployment
authentication/authorization models should be considered. scenarios that can be envisaged, along with the relevant
authentication/authorization models.
4. Non-Goals 4. Non-Goals
This following issues are clearly outside the scope of bootstrapping: This following issues are clearly outside the scope of bootstrapping:
o Home prefix renumbering is not explicity supported as part of o Home prefix renumbering is not explicitly supported as part of
bootstrapping. If the MN executes the bootstrap procedures bootstrapping. If the MN executes the bootstrap procedures
everytime it powers-on (as opposed to caching state information everytime it powers-on (as opposed to caching state information
from previous bootstrap process), then home network renumbering is from previous bootstrap process), then home network renumbering is
taken care of automatically. taken care of automatically.
o Bootstrapping in the absence of a trust relationship between MN o Bootstrapping in the absence of a trust relationship between MN
and any provider is not considered. and any provider is not considered.
5. Motivation for bootstrapping 5. Motivation for bootstrapping
skipping to change at page 11, line 46 skipping to change at page 11, line 46
Home agent discovery Home agent discovery
The Mobile IPv6 specification contains support for a mobile node The Mobile IPv6 specification contains support for a mobile node
to autoconfigure a home agent address based on a discovery to autoconfigure a home agent address based on a discovery
protocol [RFC3775]. protocol [RFC3775].
Independent network management Independent network management
An MSP may want to dynamically assign home agents in different An MSP may want to dynamically assign home agents in different
subnets; for istance, not require that a roaming mobile node have subnets; for instance, not require that a roaming mobile node have
a fixed home subnet. a fixed home subnet.
Local home agents Local home agents
The mobile node's MSP may want to allow the serving ASP to assign The mobile node's MSP may want to allow the serving ASP to assign
a local home agent for the mobile node. This is useful both from a local home agent for the mobile node. This is useful both from
the point of view of communications efficiency, and has also been the point of view of communications efficiency, and has also been
mentioned as one approach to support location privacy. mentioned as one approach to support location privacy.
Ease of deployment Ease of deployment
In order to simplify the deployment of Mobile IPv6, it is In order to simplify the deployment of Mobile IPv6, it is
desirable to free users and administrators from the task of desirable to free users and administrators from the task of
allocating home agent addresses in a static manner. Moreover, an allocating home agent addresses in a static manner. Moreover, an
MSP may want to have a dynamic home agent assignment mechanism to MSP may want to have a dynamic home agent assignment mechanism to
load balance users among home agents located on different links. load balance users among home agents located on different links.
5.1.3. Management requirements 5.1.3. "Opportunistic" or "Local" Discovery
The home agent discovery protocol does not support an "opportunistic"
or local discovery mechanisms in an ASP's local access network. It
is expected that the mobile node must know the prefix of the home
subnet in order to be able to discover a home agent. It must either
obtain that information through prefix update or have it statically
configured. A more typical pattern for inter-domain service
discovery in the Internet is that the client (mobile node in this
case) knows the domain name of the service, and uses DNS to find the
server in the visited domain. For local service discovery, DHCP is
typically used.
5.1.4. Management Requirements
As described earlier, new addresses invalidate configured security As described earlier, new addresses invalidate configured security
policy databases and authorization tables. Regardless of the policy databases and authorization tables. Regardless of the
specific protocols used, there is a need for either an automatic specific protocols used, there is a need for either an automatic
system for updating the security policy entries, or manual system for updating the security policy entries, or manual
configuration. These requirements apply to both home agents and configuration. These requirements apply to both home agents and
mobile nodes, but it can not be expected that mobile node users are mobile nodes, but it can not be expected that mobile node users are
capable of performing the required tasks. capable of performing the required tasks.
5.2. Security Infrastructure 5.2. Security Infrastructure
5.2.1. Integration with AAA Infrastructure 5.2.1. Integration with AAA Infrastructure
The current IKEv1-based dynamic key exchange protocol described in The current IKEv1-based dynamic key exchange protocol described in
[RFC3776] has no integration with backend authentication, [RFC3776] has no integration with backend authentication,
authorization and accounting techniques unless the authentication authorization and accounting techniques unless the authentication
credentials and trust relationships use certificates or pre-shared credentials and trust relationships use certificates or pre-shared
secrets. secrets.
Using certificates may require the MSP to deploy a PKI, which may not Certificates are not easily supported by traditional AAA
be possible or desirable in certain circumstances. Where a infrastructures. Where a traditional AAA infrastructure is used, the
traditional AAA infrastructure is used, the home agent is not able to home agent is not able to leverage authentication and authorization
leverage authentication and authorization information established information established between the mobile node, the foreign AAA
between the mobile node, the foreign AAA server, and the home AAA server, and the home AAA server. This would be desirable when the
server. This would be desirable when the mobile node gains access to mobile node gains access to the foreign network, in order to
the foreign network, in order to authenticate the mobile node's authenticate the mobile node's identity and determine if the mobile
identity and determine if the mobile node is authorized for mobility node is authorized for mobility service.
service.
The lack of connection to the AAA infrastructure also means the home The lack of connection to the AAA infrastructure also means the home
agent does not know where to issue accounting records at appropriate agent does not know where to send accounting records at appropriate
times during the mobile node's session, as determined by the business times during the mobile node's session, as determined by the business
relationship between the MSP and the mobile node's owner. relationship between the MSP and the mobile node's owner.
Presumably, some backend AAA protocol between the home agent and home Presumably, some backend AAA protocol between the home agent and home
AAA could be utilized, but IKEv1 does not contain support for AAA could be utilized, but IKEv1 does not contain support for
exchanging full AAA credentials with the mobile node. It is exchanging full AAA credentials with the mobile node. It is
worthwhile to note that IKEv2 provides this feature. worthwhile to note that IKEv2 provides this feature.
5.2.2. "Opportunistic" or "Local" Discovery
The home agent discovery protocol does not support an "opportunistic"
or local discovery mechanisms in an ASP's local access network. It
is expected that the mobile node must know the prefix of the home
subnet in order to be able to discover a home agent. It must either
obtain that information through prefix update or have it statically
configured. A more typical pattern for inter-domain service
discovery in the Internet is that the client (mobile node in this
case) knows the domain name of the service, and uses DNS to find the
server in the visited domain. For local service discovery, DHCP is
typically used.
5.3. Topology Change 5.3. Topology Change
5.3.1. Dormant Mode Mobile Nodes 5.3.1. Dormant Mode Mobile Nodes
The description of the protocol to push prefix information to mobile The description of the protocol to push prefix information to mobile
nodes in Section 10.6 in [RFC3775] has an implicit assumption that nodes in Section 10.6 in [RFC3775] has an implicit assumption that
the mobile node is active and taking IP traffic. In fact, many, if the mobile node is active and taking IP traffic. In fact, many, if
not most, mobile devices will be in a low power "dormant mode" to not most, mobile devices will be in a low power "dormant mode" to
save battery power, or even switched off, so they will miss any save battery power, or even switched off, so they will miss any
propagation of prefix information. As a practical matter, if this propagation of prefix information. As a practical matter, if this
skipping to change at page 14, line 7 skipping to change at page 14, line 7
reducing the utility of the protocol. reducing the utility of the protocol.
Bootstrapping does not explicitly try to solve this problem of home Bootstrapping does not explicitly try to solve this problem of home
network renumbering when MN is in dormant mode. If the MN can network renumbering when MN is in dormant mode. If the MN can
configure itself after it 'comes back on' by reinitiating the configure itself after it 'comes back on' by reinitiating the
bootstrapping process, then network renumbering problem is fixed as a bootstrapping process, then network renumbering problem is fixed as a
side-effect. side-effect.
6. Network Access and Mobility services 6. Network Access and Mobility services
This section defines some terms as it pertains to authentication and This section defines some terms as they pertain to authentication and
practical network deployment/roaming scenarios. This description practical network deployment/roaming scenarios. This description
lays the groundwork for Section 7. The focus is on the 'service' lays the groundwork for Section 7. The focus is on the 'service'
model since, ultimately, it is the provider providing the service model since, ultimately, it is the provider providing the service
that wants to authenticate the mobile (and vice-versa for mutual that wants to authenticate the mobile (and vice-versa for mutual
authentication between provider and the user of the service). authentication between provider and the user of the service).
Network access service enables a host to send and receive IP packets Network access service enables a host to send and receive IP packets
on the Internet or an intranet. IP address configuration and IP on the Internet or an intranet. IP address configuration and IP
packet forwarding capabilities are required to deliver this service. packet forwarding capabilities are required to deliver this service.
A network operator providing this service is called an access service A network operator providing this service is called an access service
provider (ASP). An ASP can, for example, be a commercial ASP, the IT provider (ASP). An ASP can, for example, be a commercial ASP, the IT
department of an enterprise network, or the maintainer of a home department of an enterprise network, or the maintainer of a home
(residential) network. (residential) network.
If the mobile node is not within the geographical area in which If the mobile node is not directly usable for communication at the
network access service is provided by its home ASP, the mobile node current location of the MN in which network access service is
is roaming. In this case, the home ASP acts as the access service provided by its home ASP, the mobile node is roaming. In this case,
authorizer, but the actual network access is provided by the serving the home ASP acts as the access service authorizer, but the actual
network access provider. During the authentication and authorization network access is provided by the serving network access provider.
prior to the mobile node having Internet access, the serving network During the authentication and authorization prior to the mobile node
access provider may simply act as a routing agent for authentication having Internet access, the serving network access provider may
and authorization back to the access service authorizer, or it may simply act as a routing agent for authentication and authorization
require an additional authentication and authorization step itself. back to the access service authorizer, or it may require an
An example of a roaming situation is when a business person is using additional authentication and authorization step itself. An example
a hotspot service in an airport, and the hotspot service provider has of a roaming situation is when a business person is using a hotspot
a roaming agreement with the business person's cellular provider. In service in an airport, and the hotspot service provider has a roaming
that case, the hotspot network is acting as the serving network agreement with the business person's cellular provider. In that
access provider, while the cellular network is acting as the access case, the hotspot network is acting as the serving network access
service authorizer. When the business person moves from the hotspot provider, while the cellular network is acting as the access service
network to the cellular network, the cellular network is both the authorizer. When the business person moves from the hotspot network
home access service provider and the access service authorizer. to the cellular network, the cellular network is both the home access
service provider and the access service authorizer.
Mobility service using Mobile IPv6 is conceptually and possibly also Mobility service using Mobile IPv6 is conceptually and possibly also
in practice separate from network access service, though of course in practice separate from network access service, though of course
network access is required prior to providing mobility. Mobile IPv6 network access is required prior to providing mobility. Mobile IPv6
service enables an IPv6 host to maintain its reachability despite service enables an IPv6 host to maintain its reachability despite
changing its network attachment point (subnets). A network operator changing its network attachment point (subnets). A network operator
providing Mobile IPv6 service is called a mobility service provider providing Mobile IPv6 service is called a mobility service provider
(MSP). Granting Mobile IPv6 service requires a host to authenticate (MSP). Granting Mobile IPv6 service requires a host to authenticate
and prove authorization for the service. A network operator that and prove authorization for the service. A network operator that
authenticates a mobile node and authorizes mobility service is called authenticates a mobile node and authorizes mobility service is called
skipping to change at page 15, line 44 skipping to change at page 15, line 45
not. not.
o It is possible that serving ASP and home MSP are the same o It is possible that serving ASP and home MSP are the same
operator. operator.
Similarly the home ASP and serving MSP may be the same. Also, the Similarly the home ASP and serving MSP may be the same. Also, the
ASA and MSA may be the same. ASA and MSA may be the same.
These entities and all combinations that are reasonable from a These entities and all combinations that are reasonable from a
deployment perspective must be taken into consideration when solving deployment perspective must be taken into consideration when solving
the Mobile IPv6 bootstraping problem. They impact home agent the Mobile IPv6 bootstrapping problem. They impact home agent
discovery, home address configuration, and mobile node to home agent discovery, home address configuration, and mobile node to home agent
authentication aspects. authentication aspects.
7. Deployment scenarios 7. Deployment scenarios
This section describes the various network deployment scenarios. The This section describes the various network deployment scenarios. The
various combinations of service providers as described in Section 6 various combinations of service providers as described in Section 6
are considered. are considered.
For each scenario, the underlying assumptions are described. The For each scenario, the underlying assumptions are described. The
basic assumption is that there is a trust relationship between mobile basic assumption is that there is a trust relationship between mobile
user and the MSA . Typically, this trust relationship is between the user and the MSA . Typically, this trust relationship is between the
mobile user and AAA in the MSA's network. Seed information needed to mobile user and AAA in the MSA's network. Seed information needed to
bootstrap the mobile node is considered in two cases: bootstrap the mobile node is considered in two cases:
o AAA authentication is mandatory for network access o AAA authentication is mandatory for network access
o AAA authentication is not part of network access. The seed o AAA authentication is not part of network access..
information is described further in Section 8.
The seed information is described further in Section 8
7.1. Mobility Service Subscription Scenario 7.1. Mobility Service Subscription Scenario
Many commercial deployments are based on the assumption that mobile Many commercial deployments are based on the assumption that mobile
nodes have a subscription with a service provider. In this scenario nodes have a subscription with a service provider. In this scenario
the MN has a subscription with an MSA , called also the home MSP, for the MN has a subscription with an MSA , also called the home MSP, for
Mobile IPv6 service. As stated in Section 6, the MSP is responsible Mobile IPv6 service. As stated in Section 6, the MSP is responsible
of setting up a home agent on a subnet that acts as a Mobile IPv6 of setting up a home agent on a subnet that acts as a Mobile IPv6
home link. As a consequence, the home MSP should explicitly home link. As a consequence, the home MSP should explicitly
authorize and control the whole bootstrapping procedure. authorize and control the whole bootstrapping procedure.
Since the MN is assumed to have a pre-established trust relationship Since the MN is assumed to have a pre-established trust relationship
with its home provider, it must be configured with an identity and with its home provider, it must be configured with an identity and
credentials, for instance an NAI and a shared secret by some out-of- credentials, for instance an NAI and a shared secret by some out-of-
band means (i.e. manual configuration) before bootstrapping. band means (i.e. manual configuration) before bootstrapping.
In order to guarantee ubiquitous service, the MN should be able to In order to guarantee ubiquitous service, the MN should be able to
bootstrap MIPv6 operations with its home MSP from any possible access bootstrap MIPv6 operations with its home MSP from any possible access
location, such as an open network or a network managed by an ASP, location, such as an open network or a network managed by an ASP,
that may be different from the MSP and may not have any pre- that may be different from the MSP and may not have any pre-
established trust relationship with it. established trust relationship with it.
7.2. Integrated ASP network scenario 7.2. Integrated ASP network scenario
In this scenario, the ASA and MSA are the same entity. The MN has In this scenario, the ASA and MSA are the same entity. The MN has
security credentials for access to the network and these credentials security credentials for access to the network and these credentials
can be used to bootstrap MIPv6. This bootstrapping can be done can also be used to bootstrap MIPv6.
during the same phase as access authentication/authorization or at a
later time (probably based on some state created during access
authentication/authorization).
Figure 1 describes an example AAA design for integrated ASP scenario. Figure 1 describes an example AAA design for integrated ASP scenario.
+----------------------------+ +----------------------------+
| IASP(ASA+MSA) | | IASP(ASA+MSA) |
+----+ +-----+ +----+ | +----+ +-----+ +----+ |
| MN |--- | NAS | | HA | | | MN |--- | NAS | | HA | |
+----+ +-----+ +----+ | +----+ +-----+ +----+ |
| \ \ | | \ \ |
| \ +------+ \ +-------+ | | \ +------+ \ +-------+ |
skipping to change at page 17, line 26 skipping to change at page 17, line 26
NAS: Network Access Server NAS: Network Access Server
AAA-NA: AAA for network access AAA-NA: AAA for network access
AAA-MIP: AAA for Mobile IP service AAA-MIP: AAA for Mobile IP service
Figure 1: Integrated ASP network Figure 1: Integrated ASP network
7.3. Third party MSP scenario 7.3. Third party MSP scenario
Mobility service has traditionally been provided by the same entity Mobility service has traditionally been provided by the same entity
that authenticates and authorizes the subscriber for network access. that authenticates and authorizes the subscriber for network access.
This is certainly the only model support by the base Mobile IPv6 This is certainly the only model supported by the base Mobile IPv6
specification. specification.
In the 3rd party mobility service provider scenario, the subscription In the 3rd party mobility service provider scenario, the subscription
for mobility service is made with one entity (MSA for instance a for mobility service is made with one entity (the MSA is for instance
corporate network), but the actual mobility service is provided by a corporate), but the actual mobility service is provided by yet
yet another entity (such as an operator specializing on this service, another entity (such as an operator specializing in this service, the
the serving MSP). These two entities have a trust relationship. serving MSP). These two entities have a trust relationship.
Transitive trust among the mobile node and these two entities may be Transitive trust among the mobile node and these two entities may be
used to assure the participants that they are dealing with, are used to assure the participants that they are dealing with, are
trustworthy peers. trustworthy peers.
This arrangement is similar to the visited - home operator roaming This arrangement is similar to the visited - home operator roaming
arrangement for network access. arrangement for network access.
Figure 2 describes an example network for third party MSP scenario. Figure 2 describes an example network for third party MSP scenario.
+--------------+ +--------+ +--------------+ +--------+
skipping to change at page 18, line 29 skipping to change at page 18, line 29
7.4. Infrastructure-less scenario 7.4. Infrastructure-less scenario
Infrastructure refers to network entities like AAA, PKI, HLR etc. Infrastructure refers to network entities like AAA, PKI, HLR etc.
Infrastructure-less implies that there is no dependency on any Infrastructure-less implies that there is no dependency on any
elements in the network with which the user has any form of trust elements in the network with which the user has any form of trust
relationship. relationship.
In such a scenario, there is absolutely no relationship between host In such a scenario, there is absolutely no relationship between host
and infrastructure. and infrastructure.
A good example of infrastructure-less environment for MIP6 A good example of infrastructure-less environment for MIPv6
bootstrapping is the IETF network at IETF meetings. It is possible bootstrapping is the IETF network at IETF meetings. It is possible
that there could be MIP6 service available on this network (i.e a that there could be MIP6 service available on this network (i.e a
MIPv6 HA). However there is not really any AAA infrastructure or for MIPv6 HA). However there is not really any AAA infrastructure or for
that matter any trust relationship that a user attending the meeting that matter any trust relationship that a user attending the meeting
has with any entity in the network. has with any entity in the network.
This specific scenario is not supported in this document. The reason This specific scenario is not supported in this document. The reason
for this is described in Section 9. for this is described in Section 9.
8. Parameters for authentication 8. Parameters for Authentication
The following is a list of parameters that are used as the seed for The following is a list of parameters that are used as the seed for
the bootstrapping procedure. The parameters vary depending on the bootstrapping procedure. The parameters vary depending on
whether authentication for network access is independent of whether authentication for network access is independent of
authentication for mobility services or not.If different client authentication for mobility services or not. If different client
identities are used for network access and mobility services, identities are used for network access and mobility services,
authentication for network access is independent of authentication authentication for network access is independent of authentication
for mobility services.. for mobility services.
o Parameter Set 1 o Parameter Set 1
In this case, authentication for network access is independent of In this case, authentication for network access is independent of
authentication for mobility services. authentication for mobility services.
If the home agent address is not known to the mobile node the If the home agent address is not known to the mobile node the
following parameter is needed for discovering the home agent following parameter is needed for discovering the home agent
address: address:
* The domain name or FQDN of the home agent * The domain name or Fully Qualified Domain Name (FQDN) of the
home agent
This parameter may be derived in various ways such as (but not This parameter may be derived in various ways such as (but not
limited to) static configuration, use of the domain name from the limited to) static configuration, use of the domain name from the
network access NAI (even if AAA for network access is not network access NAI (even if AAA for network access is not
otherwise used) or use of the domain name of the serving ASP where otherwise used) or use of the domain name of the serving ASP where
the domain name may be obtained via DHCP in the serving ASP. the domain name may be obtained via DHCP in the serving ASP.
If the home agent address is not known but the home subnet prefix If the home agent address is not known but the home subnet prefix
is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may
be used for discovering the home agent address and the above be used for discovering the home agent address and the above
parameter may not be used. parameter may not be used.
When the home agent address is known to the mobile node, the When the home agent address is known to the mobile node, the
following parameter is needed for performing mutual authentication following parameter is needed for performing mutual authentication
between the mobile node and the home agent by using IKE: between the mobile node and the home agent by using IKE:
* IKE credentials(*) * IKE credentials(*)
In the case where the home agent does not have the entire set of In the case where the home agent does not have the entire set of
IKE credentials, the home agent may communicate with other entity IKE credentials, the home agent may communicate with another
(for example a AAA server) to perform mutual authentication in entity (for example a AAA server) to perform mutual authentication
IKE. In such a case, the IKE credentials include the credentials in IKE. In such a case, the IKE credentials include the
used between the mobile node and the other entity. In the case credentials used between the mobile node and the other entity. In
where a AAA protocol is used for the communication between the the case where a AAA protocol is used for the communication
home agent and the other entity during the IKE procedure, AAA for between the home agent and the other entity during the IKE
Mobile IPv6 service may be involved in IKE. procedure, AAA for Mobile IPv6 service may be involved in IKE.
If authentication protocol [RFC4285] is used, the shared key based If the authentication protocol [RFC4285] is used, the shared key
security association with home agent is needed. based security association with the home agent is needed.
o Parameter Set 2 o Parameter Set 2
In this case, some dependency exists between authentication for In this case, some dependency exists between authentication for
network access and authentication for mobility services in that a network access and authentication for mobility services in that a
security association that is established as a result of security association that is established as a result of
authentication for network access is re-used for authentication authentication for network access is re-used for authentication
for mobility services. for mobility services.
All required information including IKE credentials are All required information including IKE credentials are
skipping to change at page 21, line 40 skipping to change at page 21, line 40
relevant IPsec RFCs must be quite strong. Provisioning of keys and relevant IPsec RFCs must be quite strong. Provisioning of keys and
other cryptographic material during the establishment of the SA other cryptographic material during the establishment of the SA
through bootstrapping must be done in a manner such that authenticity through bootstrapping must be done in a manner such that authenticity
is proved and confidentiality is ensured. In addition, the is proved and confidentiality is ensured. In addition, the
generation of any keying material or other cryptographic material for generation of any keying material or other cryptographic material for
the SA must be done in a way such that the probability of compromise the SA must be done in a way such that the probability of compromise
after the SA is in place is minimized. The best way to minimize the after the SA is in place is minimized. The best way to minimize the
probability of such a compromise is to have the cryptographic probability of such a compromise is to have the cryptographic
material only known or calculable by the two end nodes that share the material only known or calculable by the two end nodes that share the
SA -- in this case, the home agent and mobile node. If other parties SA -- in this case, the home agent and mobile node. If other parties
are involved in the establishing the SA, through key distribution for are involved in establishing the SA, through key distribution for
example, the process should follow the constraints [I-D.ietf-eap- example, the process should follow the constraints designed to
keying-08] designed to provide equivalent security. provide equivalent security.
RFC 3775 also requires a trust relationship as defined in Section 1.3 RFC 3775 also requires a trust relationship as defined in Section 1.3
between the mobile node and its home agent(s) . This is necessary, between the mobile node and its home agent(s). This is necessary,
for instance, to ensure that fradulent mobile nodes which attempt to for instance, to ensure that fradulent mobile nodes which attempt to
flood other mobile nodes with traffic can not only be shut off but flood other mobile nodes with traffic can not only be shut off but
tracked down [I-D.rosec]. An infrastructureless relationship as tracked down. An infrastructureless relationship as defined in
defined in Section 1.3 does not satisfy this requirement. Any Section 1.3 does not satisfy this requirement. Any bootstrapping
bootstrapping solution must include a trust relationship between solution must include a trust relationship between mobile node and
mobile node and mobility service provider. Solutions that depend on mobility service provider. Solutions that depend on an
an infrastructureless relationship are out of scope for infrastructureless relationship are out of scope for bootstrapping.
bootstrapping.
Another requirement is that a home address is authorized to one Another requirement is that a home address is authorized to one
specific host at a time. RFC 3775 requires this in order to that specific host at a time. RFC 3775 requires this in order that
misbehaving mobile nodes can be shut down. This implies that, in misbehaving mobile nodes can be shut down. This implies that, in
addition to the IPsec SA, the home agent must somehow authorize the addition to the IPsec SA, the home agent must somehow authorize the
mobile node for a home address. The authorization can be either mobile node for a home address. The authorization can be either
implicit (for example, as a side effect of the authentication for implicit (for example, as a side effect of the authentication for
mobility service) or explicit. The authorization can either be done mobility service) or explicit. The authorization can either be done
at the time the SA is created or dynamically managed through a first at the time the SA is created or dynamically managed through a first
come, first served allocation policy. come, first served allocation policy.
9.2. Threats to the Bootstrapping Process 9.2. Threats to the Bootstrapping Process
Various attacks are possible on the bootstrapping process itself. Various attacks are possible on the bootstrapping process itself.
These attacks can compromise the process such that the RFC 3775 These attacks can compromise the process such that the RFC 3775
requirements for Mobile IP security are not met, or they can serve to requirements for Mobile IP security are not met, or they can serve to
simply disrupt the process such that bootstrapping cannot complete. simply disrupt the process such that bootstrapping cannot complete.
Here are some possible attacks: Here are some possible attacks:
o An attacking network entity purporting to offer the mobile node a o An attacking network entity purporting to offer the mobile node a
legitimate home agent address or bootstrapping for the IPsec SAs legitimate home agent address or bootstrapping for the IPsec SAs
may, instead, offer a bogus home agent address or configure bogus may, instead, offer a bogus home agent address or configure bogus
SAs that allow the home agent to steal the mobile node's traffic SAs that allow the home agent to steal the mobile node's traffic
or otherwise disrupts the mobile node's mobility service. or otherwise disrupt the mobile node's mobility service.
o An attacking mobile node may attempt to steal mobility service by o An attacking mobile node may attempt to steal mobility service by
offering up fake credentials to a bootstrapping network entity or offering up fake credentials to a bootstrapping network entity or
otherwise disrupt the home agent's ability to offer mobility otherwise disrupt the home agent's ability to offer mobility
service. service.
o A man in the middle on the link between the mobile node and the o A man in the middle on the link between the mobile node and the
bootstrapping network entity could steal credentials or other bootstrapping network entity could steal credentials or other
sensitive information and use that to steal mobility service or sensitive information and use that to steal mobility service or
deny it to the legitimate owner of the credentials. Refer to deny it to the legitimate owner of the credentials. Refer to
skipping to change at page 22, line 50 skipping to change at page 22, line 49
further information. further information.
o An attacker could arrange for a distributed denial of service o An attacker could arrange for a distributed denial of service
attack on the bootstrapping entity, to disrupt legitimate users attack on the bootstrapping entity, to disrupt legitimate users
from bootstrapping. from bootstrapping.
In addition to these attacks, there are other considerations that are In addition to these attacks, there are other considerations that are
important in achieving a good security design. As mobility and important in achieving a good security design. As mobility and
network access authentication are separate services, keys generated network access authentication are separate services, keys generated
for these services need to be cryptographically separate, separately for these services need to be cryptographically separate, separately
named, and have separate lifetimes, including if the keys are named, and have separate lifetimes. This needs to be achieved
generated from the same authentication credentials This is necessary though the keys are generated from the same authentication
because a mobile node must be able to move from one serving (or credentials. This is necessary because a mobile node must be able to
roaming) network access provider to another without needing to change move from one serving (or roaming) network access provider to another
its mobility access provider. Finally, basic cryptographic processes without needing to change its mobility access provider. Finally,
must provide for multiple algorithms in order to accommodate the basic cryptographic processes must provide for multiple algorithms in
widely varying deployment needs. order to accommodate the widely varying deployment needs; the need
for replacement of algorithms when attacks become possible must also
be considered in the design.
10. IANA Considerations 10. IANA Considerations
No new protocol numbers are required. No new protocol numbers are required.
11. Contributors 11. Contributors
This contribution is a joint effort of the problem statement design This contribution is a joint effort of the problem statement design
team of the Mobile IPv6 WG. The contributors include Basavaraj team of the Mobile IPv6 WG. The contributors include Basavaraj
Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba, Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba,
skipping to change at page 27, line 19 skipping to change at page 27, line 19
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
14. Informative References 14. Informative References
[2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol [2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol
(EAP)", February 2004, <draft-ietf-eap-rfc2284bis-09.txt>. (EAP)", February 2004, <draft-ietf-eap-rfc2284bis-09.txt>.
[I-D.giaretta-mip6-authorization-eap] [I-D.giaretta-mip6-authorization-eap]
Giaretta, G., "MIPv6 Authorization and Configuration based Giaretta, G., "MIPv6 Authorization and Configuration based
on EAP", draft-giaretta-mip6-authorization-eap-02 (work in on EAP", draft-giaretta-mip6-authorization-eap-03 (work in
progress), February 2004, progress), March 2006,
<draft-giaretta-mip6-authorization-eap-02.txt>. <draft-giaretta-mip6-authorization-eap-02.txt>.
[I-D.ietf-eap-keying-08]
Aboba et. al., B., "Extensible Authentication Protocol
(EAP) Key Management Framework",
draft-ietf-eap-keying-08.txt (work in progress),
October 2005, <draft-ietf-eap-keying-08.txt>.
[I-D.kempf-mip6-bootstrap]
Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping
Problem", draft-kempf-mip6-bootstrap-00 (work in
progress), March 2004,
<draft-kempf-mip6-bootstrap-00.txt>.
[I-D.mariblanca-aaa-eap-lla-00] [I-D.mariblanca-aaa-eap-lla-00]
Mariblanca, D., "EAP lower layer attributes for AAA Mariblanca, D., "EAP lower layer attributes for AAA
protocols", May 2004, protocols", May 2004,
<draft-mariblanca-aaa-eap-lla-00.txt>. <draft-mariblanca-aaa-eap-lla-00.txt>.
[I-D.rosec]
Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-02 (work in
progress), October 2004, <draft-ietf-mip6-ro-sec-02.txt>.
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000. Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
skipping to change at page 29, line 17 skipping to change at page 28, line 17
Alpesh Patel Alpesh Patel
Cisco Cisco
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 853 9580 Phone: +1 408 853 9580
Email: alpesh@cisco.com Email: alpesh@cisco.com
Gerardo Giaretta Gerardo Giaretta
Telecom Italia LAB Telecom Italia
via Reiss Romoli 274 via Reiss Romoli 274
Torino 10148 Torino 10148
Italy Italy
Phone: +39 011 228 6904 Phone: +39 011 228 6904
Email: gerardo.giaretta@telecomitalia.it Email: gerardo.giaretta@telecomitalia.it
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
 End of changes. 49 change blocks. 
149 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/