draft-ietf-dmm-requirements-05.txt   draft-ietf-dmm-requirements-06.txt 
Network Working Group H. Chan (Ed.) Network Working Group H. Chan (Ed.)
Internet-Draft Huawei Technologies (more Internet-Draft Huawei Technologies (more
Intended status: Informational co-authors on P. 17) Intended status: Informational co-authors on P. 17)
Expires: December 7, 2013 D. Liu Expires: January 31, 2014 D. Liu
China Mobile China Mobile
P. Seite P. Seite
Orange Orange
H. Yokota H. Yokota
KDDI Lab KDDI Lab
J. Korhonen J. Korhonen
Nokia Siemens Networks Nokia Siemens Networks
June 5, 2013 July 30, 2013
Requirements for Distributed Mobility Management Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-05 draft-ietf-dmm-requirements-06
Abstract Abstract
This document defines the requirements for Distributed Mobility This document defines the requirements for Distributed Mobility
Management (DMM) in IPv6 deployments. The hierarchical structure in Management (DMM) in IPv6 deployments. The hierarchical structure in
traditional wireless networks has led to deployment models which are traditional wireless networks has led to deployment models which are
in practice centralized. Mobility management with logically in practice centralized. Mobility management with logically
centralized mobility anchoring in current mobile networks is prone to centralized mobility anchoring in current mobile networks is prone to
suboptimal routing and raises scalability issues. Such centralized suboptimal routing and raises scalability issues. Such centralized
functions can lead to single points of failure and inevitably functions can lead to single points of failure and inevitably
skipping to change at page 2, line 13 skipping to change at page 2, line 13
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 7, 2013. This Internet-Draft will expire on January 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 23 skipping to change at page 3, line 23
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11
5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 5.2. Transparency to Upper Layers when needed . . . . . . . . . 11
5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12
5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12
5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Security considerations . . . . . . . . . . . . . . . . . 13 5.6. Security considerations . . . . . . . . . . . . . . . . . 13
5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In the past decade a fair number of mobility protocols have been In the past decade a fair number of mobility protocols have been
standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
skipping to change at page 13, line 30 skipping to change at page 13, line 30
function as usual, and (b) enable inter-domain operation if function as usual, and (b) enable inter-domain operation if
desired. desired.
This requirement addresses the following related problem PS7 in This requirement addresses the following related problem PS7 in
Section 4. Section 4.
5.6. Security considerations 5.6. Security considerations
REQ6: Security considerations REQ6: Security considerations
DMM protocol solutions MUST consider security risks introduced A DMM solution MUST not introduce new security risks or
by DMM into the network. Such considerations may include amplify existing security risks against which the existing
authentication and authorization mechanisms that allow a security mechanisms/protocols cannot offer sufficient
mobile host/router to use the mobility support provided by the protection.
DMM solution; measures against redirecting traffic to the
wrong host when providing DMM support; signaling message
protection for authentication, integrity and confidentiality.
Motivation: Various attacks such as impersonation, denial of Motivation: Various attacks such as impersonation, denial of
service, man-in-the-middle attacks, and so on, may become service, man-in-the-middle attacks, and so on, may be launched
newly possible or easier to mount due to the introduction of in a DMM deployment. For instance, an illegitimate node may
DMM. Proof of possession of past and new IP addresses may be attempt to access a network providing DMM. Another example is
needed. that a malicious node can forge a number of signaling messages
thus redirecting traffic from its legitimate path.
Signaling messages can be subject to various attacks since Consequently, the specific node is under a denial of service
they carry critical context information about a mobile node/ attack, whereas other nodes do not receive their traffic.
router. For instance, a malicious node can forge a number of Accordingly, security mechanisms/protocols providing access
signaling messages thus redirecting traffic from its control, integrity, authentication, authorization,
legitimate path. Consequently, the specific node is under a confidentiality, etc. can be used to protect the DMM entities
denial of service attack, whereas other nodes do not receive as they are already used to protect against existing networks
their traffic. As signaling messages may travel over the and existing mobility protocols defined in IETF. In addition,
Internet, end-to-end security between communicating hosts must end-to-end security measures between communicating nodes may
be required. already be used when deploying existing mobility protocols
where the signaling messages travel over the Internet. For
instance, EAP-based authentication can be used for network
access security, while IPsec can be used for end-to-end
security. When the existing security mechanisms/protocols are
applied to protect the DMM entities, the security risks that
may be introduced by DMM MUST be considered to be eliminated.
Else the security protection would be degraded in the DMM
solution versus in existing mobility protocols.
This requirement addresses the problems of potentially insecure This requirement prevents a DMM solution from introducing
mobility management protocols which make deployment infeasible uncontrollable problems of potentially insecure mobility management
because platforms conforming to the protocols are at risk for data protocols which make deployment infeasible because platforms
loss and numerous other dangers, including financial harm to the conforming to the protocols are at risk for data loss and numerous
user. other dangers, including financial harm to the users.
5.7. Multicast 5.7. Multicast
REQ7: DMM SHOULD enable multicast solutions in flexible distribution REQ7: DMM SHOULD consider multicast early so that solutions can be
scenario. This flexibility pertains to the preservation of IP developed not only to provide IP mobility to keep IP multicast
multicast nature from the perspective of a mobility entity and sessions when it is needed, but also to avoid network
transmission of multicast packets to/from various multicast- inefficiency issues in multicast traffic delivery (such as
enabled entities. Therefore, this flexibility enables duplicate multicast subscriptions towards the downstream
different IP multicast flows with respect to a mobile host to tunnel entities). The multicast solutions should therefore
be managed (e.g., subscribed, received and/or transmitted)
using multiple multicast-enabled endpoints.
Motivation: to consider multicast early so that solutions can
be developed to avoid network inefficiency issues in multicast
traffic delivery. The multicast solution should therefore
avoid restricting the management of all IP multicast traffic avoid restricting the management of all IP multicast traffic
relative to a host through a dedicated interface on multicast- to a single host through a dedicated (tunnel) interface on
capable access routers. multicast-capable access routers.
Motivation: Existing multicast deployment have been introduced
after completing the design of the reference mobility
protocol, then optimization and extensions have been followed
by "patching-up" procedure, thus leading to network
inefficiency and non-optimal routing. The multicast solutions
should therefore be required to consider efficiency nature in
multicast traffic delivery.
This requirement addresses the problems PS1 and PS8 in Section 4. This requirement addresses the problems PS1 and PS8 in Section 4.
6. Security Considerations 6. Security Considerations
Distributed mobility management (DMM) requires two kinds of security Please refer to the discussion under Security requirement in Session
considerations. The first consideration is on access network 5.6.
security required between the mobile host/router and the access
network deploying DMM. It allows only a legitimate mobile host/
router to use DMM. The second consideration is on end-to-end
security required between nodes that participate in the DMM protocol.
It protects the DMM signaling messages.
It is necessary to provide sufficient defense against possible
security attacks, or to adopt existing security mechanisms and
protocols to provide sufficient security protections. For instance,
EAP-based authentication can be used for access network security,
while IPsec can be used for end-to-end security.
7. IANA Considerations 7. IANA Considerations
None None
8. Co-authors and Contributors 8. Co-authors and Contributors
This problem statement document is a joint effort among the numerous This problem statement document is a joint effort among the numerous
participants. Each individual has made significant contributions to participants. Each individual has made significant contributions to
this work and have been listed as co-authors. this work and have been listed as co-authors.
skipping to change at page 19, line 8 skipping to change at page 18, line 51
- -
Marco Liebsch Marco Liebsch
NEC Laboratories Europe NEC Laboratories Europe
Email: liebsch@neclab.eu Email: liebsch@neclab.eu
- -
Carl Williams Carl Williams
MCSR Labs MCSR Labs
Email: carlw@mcsr-labs.org Email: carlw@mcsr-labs.org
- -
Seil Jeon Seil Jeon
Instituto de Telecomunicacoes, Aveiro
Email: seiljeon@av.it.pt Email: seiljeon@av.it.pt
- -
Sergio Figueiredo Sergio Figueiredo
Universidade de Aveiro
Email: sfigueiredo@av.it.pt Email: sfigueiredo@av.it.pt
- -
Stig Venaas Stig Venaas
Email: stig@venaas.com Email: stig@venaas.com
- -
Luis Miguel Contreras Murillo Luis Miguel Contreras Murillo
Email: lmcm@tid.es Email: lmcm@tid.es
- -
Juan Carlos Zuniga Juan Carlos Zuniga
Email: JuanCarlos.Zuniga@InterDigital.com Email: JuanCarlos.Zuniga@InterDigital.com
skipping to change at line 828 skipping to change at page 19, line 37
- -
Wassim Michel Haddad Wassim Michel Haddad
Wassam.Haddad@ericsson.com Wassam.Haddad@ericsson.com
- -
Dirk von Hugo Dirk von Hugo
Dirk.von-Hugo@telekom.de Dirk.von-Hugo@telekom.de
- -
Ahmad Muhanna Ahmad Muhanna
amuhanna@awardsolutions.com amuhanna@awardsolutions.com
- -
Byoung-Jo Kim
ATT Labs
macsbug@research.att.com
-
Hassan Aliahmad
Orange
hassan.aliahmad@orange.com
-
 End of changes. 14 change blocks. 
58 lines changed or deleted 56 lines changed or added

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