Internet DRAFT - draft-bajko-mext-sod

draft-bajko-mext-sod






Individual Submission                                           G. Bajko
Internet-Draft                                                  B. Patil
Intended status: Standards Track                           T. Savolainen
Expires: May 4, 2012                                               Nokia
                                                        November 1, 2011


     Security on Demand for Mobile IPv6 and Dual-stack Mobile IPv6
                        draft-bajko-mext-sod-03

Abstract

   Mobile IPv6 and Dual-stack Mobile IPv6 protocols require the
   signaling messages between the mobile node and home agent to be
   secured.  However security for the user plane/traffic is optional and
   is a choice left to the mobile node.  This document proposes
   extensions to Mobile IPv6 signaling which enables the user plane
   traffic to be secured on a need or on-demand basis.  The mobile node
   or the home agent can request at any time security for the user plane
   traffic.  Security for user plane traffic can be triggered as a
   result of policy or, mobility or, at the user's choice.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 4, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Bajko, et al.              Expires May 4, 2012                  [Page 1]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  When to apply Security to user plane traffic  . . . . . . . . . 4
   3.  Triggering user plane traffic security  . . . . . . . . . . . . 4
   4.  Extensions to Mobile IPv6 . . . . . . . . . . . . . . . . . . . 5
     4.1.  Extensions to Binding Update and Binding
           Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  New binding Update Mobility Options . . . . . . . . . . . . 6
   5.  HA initiated security for user plane traffic  . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     10.1. Informative References  . . . . . . . . . . . . . . . . . . 7
     10.2. Normative References  . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8


























Bajko, et al.              Expires May 4, 2012                  [Page 2]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


1.  Introduction

   Mobile IPv6 [RFC6275] and Dual-stack Mobile IPv6 [RFC5555] provide
   the option to secure the user plane data between the Mobile Node (MN)
   and and the Home Agent (HA) when needed.  The user plane traffic
   between the MN and HA is secured via an IPsec security association
   (SA) which is established between them specifically for the purpose
   of user plane data.  IPsec is used for securing the user plane
   traffic when the security between the MN and HA is based on IPsec.
   However security between the MN and HA could also be enabled via
   other protocols.  The MEXT WG is evaluating on an experimental basis
   various alternatives to IPsec such as the one specified in
   [I-D.ietf-mext-mip6-tls].

   As per the current specifications for MIP6 and DSMIP6, security of
   the user plane traffic is optional.  When the MN is attached to 3G/4G
   network such as HSPA, LTE or EV-DO, the MN may not require security
   for the user plane traffic since these networks already provide
   ciphering over the air-interface and deploy hop-by-hop security,
   which makes these networks secure.  However the MN may attach to less
   secure or unsecured accesses such as wireless lan (WLAN) or it may
   roam in countries where the user may prefer the data between the MN
   and the HA to be encrypted (even when using cellular accesses).
   There is no solution in the protocol specification today which
   provides the capability to trigger the security for the user plane
   traffic on a need basis.

   The problem that is being addressed is the triggering of security for
   user plane traffic between the MN and HA on a need basis.  Policy
   information at the MN or information provided to the MN via other
   means at the time of attachment may assist the MN to determine if
   security needs to be enabled for user plane traffic.  The user may
   also consciously decide to enable security when attached to certain
   networks.  Furthermore, the operator of HA may have policies that
   define when user plane security is to be used.  This document
   describes a mechanism which can enable security for user plane
   traffic on-demand or need.

   An obvious implementation alternative would be to encrypt user plane
   traffic always (as is commonly done with VPN use-cases), but that
   would unnecessarily consume resources on the HA.  For the HA operator
   there is clear economic incentive to encrypt user-plane data only
   when necessary.  The MIP6/DSMIP6 protocols only provide a means to
   secure the user plane traffic but do not provide any mechanisms by
   which the security is triggered as a result of mobility or the MN
   attaching via different access networks.

   As per the current MIP6 [RFC6275] specification, only the MN has the



Bajko, et al.              Expires May 4, 2012                  [Page 3]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


   ability to enable security for user-plane traffic.  The HA has no
   ability to force the MN to secure user traffic.


2.  When to apply Security to user plane traffic

   An MN MUST have security for the control plane messages.  Hence all
   signaling between the MN and HA are secured.  The MN establishes an
   IPsec SA between itself and the assigned HA prior to sending a
   Binding Update.  However, the MN is not required to establish an SA
   for securing the user plane traffic.  It is up to the MN whether it
   establishes SAs for the control plane and user plane at the same time
   or if it only establishes the control plane SA.  The MN may choose to
   establish the SA for user plane traffic at any time [RFC4877].

   When the MN attaches to an access network, it is usually able to
   determine if the access network is viewed as trusted or untrusted.
   The MN can make this determination, for example, based on the PLMN ID
   of the cellular network; or wifi_SSID/MAC_address of a wifi network;
   or location information provided by the MN, or user input.  The MN
   has either a stored policy about trusted and untrusted access
   networks or it may be provided with such information from policy
   stores such as the ANDSF [23.402] or AAA server at the time of
   network attachment.  An interface exists generally between the policy
   store such as AAA or ANDSF and the Home Agent (HA).  If the MN is
   attached to an access network which is viewed as trusted or where
   encryption is not allowed, the MN chooses not to secure the user
   plane traffic.

   If the MN is attached to an access network which is not trusted, the
   MN may want to secure its user plane traffic.  The HA may also be
   able to determine from the source address of the binding update (BU)
   message the access network to which the MN is currently attached.
   Based on this information, the HA may require that the user plane
   traffic be encrypted on the MN-HA link.

   The MN or HA can determine when to use security for the user plane
   traffic using static policies or dynamic policies which can be
   obtained at the time of network attachment; or e.g. which are
   provisioned and maintained on a smartcard (eg, a UICC or SIM). 3GPP
   policy stores such as the ANDSF can also provide information about
   the access networks to which an MN is attached.  Location of the MN
   can also be used as input.


3.  Triggering user plane traffic security

   This document proposes extensions to MIPv6/DSMIPv6 protocol, allowing



Bajko, et al.              Expires May 4, 2012                  [Page 4]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


   the MN to signal to the HA its preference for user plane traffic
   security, and for the HA to override that preference based on the
   policy settings.

   A new mobility option called as the "Security-on-demand" (SoD) is
   specified which is used to switch on or off the security for the user
   plane traffic.

   The MN sends a binding update which includes the "Security-on-demand"
   mobility option set which is used to indicate whether security for
   the user plane traffic is to be switched On or Off. The HA processes
   the binding update message from the MN and sends a response
   acknowledging the request and including the "SoD" option for user
   plane traffic security.

   The HA MAY always overwrite the MN's security preference on the user
   plane traffic indicated in the Binding Update message, by setting the
   SoD option in the the Binding Acknowledgement to a different value.
   The MN SHALL always follow the indication in the Binding
   Acknowledgement to set the security of the MN to HA user plane
   traffic.


4.  Extensions to Mobile IPv6

4.1.  Extensions to Binding Update and Binding Acknowledgement

   This section defines the new Security-on-demand mobility option for
   the Binding Update and the corresponding Binding Acknowledgement
   message.

   The security-on-demand mobility option has an alignment requirement
   of 2n.  Its format is as follows:



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |   Type =      |  Length =     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | SoD option    |     Reserved                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



               Figure 1: Security on demand mobility option




Bajko, et al.              Expires May 4, 2012                  [Page 5]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


      Type = TBD (To be assigned by IANA)

      Length = 4

      SoD Option = This option field defines whether security is enabled
      or disabled as well as whether security is integrity protected or
      encrypted

4.2.  New binding Update Mobility Options

   A new mobility Options for carrying location of the MN is defined to
   be used in a Binding Update message with the following format:



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type        |   Length      |N|   Reserved  |   Data ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Data ...                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                           Figure 2: MN location

   Type: tbd

   N set to 1 indicates that the data contains a location in XML format
   as defined in RFC5139, N set to zero indicates that the data part
   contains an http URI pointing to a resource where the MN uploaded its
   location


5.  HA initiated security for user plane traffic

   Mobile IPv6 signaling is primarily mobile initiated.  The security
   for user plane traffic can be requested by the MN via the Binding
   Update request message and the HA has the ability to either approve
   or deny via the Binding Acknowledgment message.  However the HA does
   not have a way to send an insolicited message to the MN and trigger
   the establishment of security for the user plane traffic.

   Mobile IPv6 defines Binding Revocation [RFC5846] which enables an HA
   to send an unsolicited message to the MN to revoke a binding.  This
   is the only unsolicited signaling message that can be sent by HA to
   an MN.  This I-D proposes extending the binding revocation message to
   indicate to the MN that security for the user plane traffic is



Bajko, et al.              Expires May 4, 2012                  [Page 6]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


   required.  The effect of sending the binding revocation message to
   the MN with the appropriate option included in it will cause the MN
   to send a Binding update with the SoD mobility option requesting
   security for user plane traffic.


6.  IANA Considerations

   This document will require actions on the part of IANA to assign
   values for the new binding update mobility option.


7.  Security Considerations

   This I-D introduces extensions to Mobile IPv6 signaling messages.
   There is no impact to the security model and architecture that is
   currently specified for MIP6 [RFC6275].  The extensions specified in
   this document do not introduce any new vulnerabilities of threats to
   the security architecture of Mobile IPv6.


8.  Summary

   Security for the user plane traffic between the MN and Home agent can
   be switched on or off as a result of policy, location or, request by
   the user.  The ability to control and trigger the security for the
   user plane traffic rests with the MN as well as the HA with the HA
   having the final say.


9.  Acknowledgments

   The authors acknowledge the reviews by Julien Laganier, Jouni
   Korhonen, Stefano Faccin and Kent Leung.  Their comments and
   suggestions will be incorporated in the next revision.


10.  References

10.1.  Informative References

   [23.402]   3rd generation partnership project (3GPP), "3GPP TS
              23.402, Architecture enhancements for non-3GPP
              accesses,".







Bajko, et al.              Expires May 4, 2012                  [Page 7]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


10.2.  Normative References

   [I-D.ietf-mext-mip6-tls]
              Korhonen, J., Patil, B., Tschofenig, H., and D.
              Kroeselberg, "Transport Layer Security-based Mobile IPv6
              Security Framework for Mobile Node to Home Agent
              Communication", draft-ietf-mext-mip6-tls-02 (work in
              progress), October 2011.

   [RFC4877]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
              IKEv2 and the Revised IPsec Architecture", RFC 4877,
              April 2007.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5846]  Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
              and P. Yegani, "Binding Revocation for IPv6 Mobility",
              RFC 5846, June 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.


Authors' Addresses

   Gabor Bajko
   Nokia
   200 S Mathilda Avenue
   Sunnyvale, CA  94086
   USA

   Email: gabor.bajko@nokia.com


   Basavaraj Patil
   Nokia
   6021 Connection drive
   Irving, TX  75039
   USA

   Email: basavaraj.patil@nokia.com









Bajko, et al.              Expires May 4, 2012                  [Page 8]

Internet-Draft       Mobile IPv6: Security on demand       November 2011


   Teemu Savolainen
   Nokia
   Hermainkatu 12 D
   Tampere, FI  33720
   Finland

   Email: teemu.savolainen@nokia.com












































Bajko, et al.              Expires May 4, 2012                  [Page 9]