Skip to main content

Multiple Provisioning Domain Architecture
draft-ietf-mif-mpvd-arch-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7556.
Author Dmitry Anipko
Last updated 2014-09-17 (Latest revision 2014-09-15)
Replaces draft-anipko-mif-mpvd-arch
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd DENG Hui
IESG IESG state Became RFC 7556 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-mif-mpvd-arch-05
5.2.3.1.1.  Connection-oriented APIs

   For connection-oriented APIs, when the initial incoming packet is
   received, the packet PvD is remembered for the established connection
   and used for handling of outgoing traffic for that connection.  While
   typically, connection-oriented APIs use a connection-oriented
   transport protocol, such as TCP, it is possible to have a connection-
   oriented API that uses a generally connectionless transport protocol,
   such as UDP.

   For APIs/protocols that support multiple IP traffic flows associated
   with a single transport API connection object (for example, multi
   path TCP), the processing rules may be adjusted accordingly.

5.2.3.1.2.  Connectionless APIs

   For connectionless APIs, the host should provide an API that PvD-
   aware applications can use to query the PvD associated with the
   packet.  For outgoing traffic on this transport API object, the OS
   should use the selected outgoing PvDs, determined as described above.

5.2.4.  Enforcement of Security Policies

   By themselves, PvDs do not define, and cannot be used for
   communication of, security policies.  When implemented in a network,
   this architecture provides the host with information about connected
   networks.  The actual behavior of the host then depends on the host's
   policies (provisioned through mechanisms out of scope of this
   document), applied taking received PvD information into account.  In
   some scenarios, e.g.  a VPN, such policies could require the host to
   use only a particular VPN PvD for some / all of the application's
   traffic (VPN 'disable split tunneling' also known as 'force
   tunneling' behavior), or apply such restrictions only to selected
   applications and allow the simultaneous use of the VPN PvD together
   with the other connected PvDs by the other or all applications (VPN
   'split tunneling' behavior).

5.3.  Connectivity Tests

   Although some PvDs may appear as valid candidates for PvD selection
   (e.g.  good link quality, consistent connection parameters, etc.),
   they may provide limited or no connectivity to the desired network or
   the Internet.  For example, some PvDs provide limited IP connectivity
   (e.g., scoped to the link or to the access network), but require the
   node to authenticate through a web portal to get full access to the
   Internet.  This may be more likely to happen for PvDs which are not
   trusted by a given PvD-aware node.

   An attempt to use such a PvD may lead to limited network connectivity
   or application connection failures.  To prevent the latter, a PvD-
   aware node may perform a connectivity test for the PvD before using
   it to serve application network connection requests.  In current
   implementations, some nodes already implement this e.g., by trying to

Anipko                   Expires March 17, 2015                [Page 16]
Internet-Draft             MPVD architecture              September 2014

   reach a dedicated web server (see [RFC6419]).

   Section 5.2 describes how a PvD-aware node shall maintain and use
   multiple PvDs separately.  The PvD-aware node shall perform a
   connectivity test and, only after validation of the PvD, consider
   using it to serve application connections requests.  Ongoing
   connectivity tests are also required, since during the IP session,
   the end-to-end connectivity could be disrupted for various reasons
   (e.g.  L2 problems, IP QoS issues); hence, a connectivity monitoring
   function is needed to check the connectivity status and remove the
   PvD from the set of usable PvDs if necessary.

   There may be cases where a connectivity test for PvD selection may
   not be appropriate and should be complemented, or replaced, by PvD
   selection based on other factors.  For example, this could be
   realized by leveraging some 3GPP and IEEE mechanisms, which would
   allow the exposure of some PvD characteristics to the node (e.g.
   3GPP Access Network Discovery and Selection Function (ANDSF)
   [TS23.402], IEEE 802.11u [IEEE802.11u]/ANQP).

5.4.  Relationship to Interface Management and Connection Managers

   Current devices, such as mobile handsets make use of proprietary
   mechanisms and custom applications to manage connectivity in
   environments with multiple interfaces and multiple sets of network
   configuration.  These mechanisms or applications are commonly known
   as connection managers [RFC6419].

   Connection managers sometimes rely on policy servers to allow a node
   that is connected to multiple networks to perform network selection.
   They can also make use of routing guidance from the network (e.g.
   3GPP ANDSF [TS23.402]).  Although connection managers solve some
   connectivity problems, they rarely address network selection problems
   in a comprehensive manner.  With proprietary solutions, it is
   challenging to present coherent behavior to the end user of the
   device, as different platforms present different behaviors even when
   connected to the same network, with the same type of interface, and
   for the same purpose.  The architecture described in this document
   should improve the hosts behavior by providing the hosts with tools
   and guidance to make informed network selection decisions.

6.  PvD support in APIs

   For all levels of PvD support in APIs described in this chapter, it
   is expected that the notifications about changes in the set of
   available PvDs are exposed as part of the API surface.

6.1.  Basic

Anipko                   Expires March 17, 2015                [Page 17]
Internet-Draft             MPVD architecture              September 2014

   Applications are not PvD-aware in any manner and only submit
   connection requests.  The node performs PvD selection implicitly,
   without any application participation, based purely on node-specific
   administrative policies and / or choices made by the user from a user
   interface provided by the operating environment, not by the
   application.

   As an example, PvD selection can be done at the name service lookup
   step by using the relevant configuration elements, such as those
   described in [RFC6731].  As another example, PvD selection could be
   made based on application identity or type (i.e., a node could always
   use a particular PvD for a VOIP application).

6.2.  Intermediate

   Applications indirectly participate in PvD selection by specifying
   hard requirements and soft preferences.  As an example, a real time
   communication application intending to use the connection for the
   exchange of real time audio / video data may indicate a preference or
   a requirement for connection quality, which could affect PvD
   selection (different PvDs could correspond to Internet connections
   with different loss rates and latencies).

   Another example is the connection of an infrequently executed
   background activity, which checks for application updates and
   performs large downloads when updates are available.  For such
   connections, a cheaper or zero cost PvD may be preferable, even if
   such a connection has a higher relative loss rate or lower bandwidth.
   The node performs PvD selection based on applications' inputs and
   policies and / or user preferences.  Some / all properties of the
   resultant PvD may be exposed to applications.

6.3.  Advanced

   PvDs are directly exposed to applications for enumeration and
   selection.  Node polices and / or user choices may still override the
   applications' preferences and limit which PvD(s) can be enumerated
   and / or used by the application, irrespective of any preferences
   which the application may have specified.  Depending on the
   implementation, such restrictions (imposed by node policy and / or
   user choice) may or may not be visible to the application.

7.  PvD Trust for PvD-Aware Node

7.1.  Untrusted PvDs

   Implicit and explicit PvDs for which no trust relationship exists are
   considered untrusted.  Only PvDs which meet the requirements in
   Section 7.2 are trusted; any other PvD is untrusted.

Anipko                   Expires March 17, 2015                [Page 18]
Internet-Draft             MPVD architecture              September 2014

   In order to avoid the various forms of misinformation that could
   occur when PvDs are untrusted, nodes that implement PvD separation
   cannot assume that two explicit PvDs with the same identifier are
   actually the same PvD. A node that makes this assumption will be
   vulnerable to attacks where, for example, an open Wifi hotspot might
   assert that it was part of another PvD and thereby attempt to draw
   traffic intended for that PvD onto its own network.

   Since implicit PvD identifiers are synthesized by the node, this
   issue cannot arise with implicit PvDs.

   Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide
   configuration information that asserts special knowledge about the
   reachability of resources through that PvD. Such assertions cannot be
   validated unless the node has a trust relationship with the PvD;
   therefore, assertions of this type must be ignored by nodes that
   receive them from untrusted PvDs.  Failure to ignore such assertions
   could result in traffic being diverted from legitimate destinations
   to spoofed destinations.

7.2.  Trusted PvDs

   Trusted PvDs are PvDs for which two conditions apply: First, a trust
   relationship must exist between the node that is using the PvD
   configuration and the source that provided that configuration; this
   is the authorization portion of the trust relationship.  Second,
   there must be some way to validate the trust relationship.  This is
   the authentication portion of the trust relationship.  Two mechanisms
   for validating the trust relationship are defined.

   It shall be possible to validate the trust relationship for all
   advertised elements of a trusted PvD, irrespective of whether the PvD
   elements are communicated as a whole, e.g., in a single DHCP option,
   or separately, e.g., in supplementary RA options.  The feasibility of
   mechanisms to implement a trust relationship for all PvD elements
   will be determined in the respective companion design documents.

7.2.1.  Authenticated PvDs

   One way to validate the trust relationship between a node and the
   source of a PvD is through the combination of cryptographic
   authentication and an identifier configured on the node.  In some
   cases, the two could be the same; for example, if authentication is
   by a shared secret, the secret would have to be associated with the
   PvD identifier.  Without a PvD Identifier / shared key tuple,
   authentication would be impossible, and hence authentication and
   authorization are combined.

Anipko                   Expires March 17, 2015                [Page 19]
Internet-Draft             MPVD architecture              September 2014

   However, if authentication is done using a public key mechanism such
   as a TLS certificate or DANE, authentication by itself is not enough
   since theoretically any PvD could be authenticated in this way.  In
   addition to authentication, the node would need configuration to
   trust the identifier being authenticated.  Validating the
   authenticated PvD name against a list of PvD names configured as
   trusted on the node would constitute the authorization step in this
   case.

7.2.2.  PvDs Trusted by Attachment

   In some cases, a trust relationship may be validated by some means
   other than those described in Section 7.2.1 simply by virtue of the
   connection through which the PvD was obtained.  For instance, a
   handset connected to a mobile network may know through the mobile
   network infrastructure that it is connected to a trusted PvD.
   Whatever mechanism was used to validate that connection constitutes
   the authentication portion of the PvD trust relationship.
   Presumably, such a handset would be configured from the factory (or
   else through mobile operator or user preference settings) to trust
   the PvD, and this would constitute the authorization portion of this
   type of trust relationship.

8.  Contributors

   The following individuals contributed to this document (listed in no
   specific order): Alper Yegin (alper.yegin@yegin.org), Aaron Yi Ding
   (yding@cs.helsinki.fi), Zhen Cao (caozhenpku@gmail.com), Dapeng Liu
   (liudapeng@chinamobile.com), Dave Thaler (dthaler@microsoft.com),
   Dmitry Anipko (dmitry.anipko@microsoft.com), Hui Deng
   (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com),
   Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos
   Pentikousis (k.pentikousis@huawei.com), Marc Blanchet
   (marc.blanchet@viagenie.ca), Margaret Wasserman
   (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com),
   Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen
   (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com) and
   Tim Chown (tjc@ecs.soton.ac.uk).

9.  Acknowledgments

   The authors would like to thank (in no specific order) Ian Farrer,
   Marcus Stenberg and Mikael Abrahamsson for their review and comments.

10.  IANA Considerations

   This memo does not include any IANA requests.

11.  Security Considerations

   There are at least three different forms of attacks that can be
   performed using configuration sources that support multiple
   provisioning domains.

Anipko                   Expires March 17, 2015                [Page 20]
Internet-Draft             MPVD architecture              September 2014

   Tampering with provided configuration information: An attacker may
      attempt to modify information provided inside the PvD container
      option.  These attacks can easily be prevented by using message
      integrity features provided by the underlying protocol used to
      carry the configuration information.  E.g.  SEND [RFC3971] would
      detect any form of tampering with the RA contents and the DHCPv6
      [RFC3315] AUTH option that would detect any form of tampering with
      the DHCPv6 message contents.  This attack can also be performed by
      a compromised configuration source by modifying information inside
      a specific PvD, in which case the mitigations proposed in the next
      subsection may be helpful.

   Rogue configuration source: A compromised configuration source, such
      as a router or a DHCPv6 server, may advertise information about
      PvDs that it is not authorized to advertise.  e.g.  A coffee shop
      WLAN may advertise configuration information purporting to be from
      an enterprise and may try to attract enterprise related traffic.
      The only real way to prevent this is is for the PvD related
      configuration container to contain embedded authentication and
      authorization information from the owner of the PvD. This provides
      the client with a way of detecting the attack by verifying the
      authentication and authorization information provided inside the
      PvD container option, after verifying its trust of the PvD owner
      (e.g.  a certificate with a well-known / common trust anchor).

   Replay attacks: A compromised configuration source or an on-link
      attacker may try to capture advertised configuration information
      and replay it on a different link, or at a future point in time.
      This can be avoided by including a replay protection mechanism
      such as a timestamp or a nonce inside the PvD container to ensure
      the validity of the provided information.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [I-D.bhandari-dhc-class-based-prefix]
              Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
              Thiebaut, L., Korhonen, J. and I. Farrer, "DHCPv6 class
              based prefix", Internet-Draft draft-bhandari-dhc-class-
              based-prefix-05, July 2013.

   [I-D.korhonen-dmm-prefix-properties]
              Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D.
              Liu, "IPv6 Prefix Mobility Management Properties",
              Internet-Draft draft-korhonen-dmm-prefix-properties-03,
              October 2012.

Anipko                   Expires March 17, 2015                [Page 21]
Internet-Draft             MPVD architecture              September 2014

   [IEEE802.11u]
              IEEE, "IEEE Standard 802.11u-2011 (Amendment 9:
              Interworking with External Networks)", 2011.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
              M. Carney, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", RFC 3315, July 2003.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5739]  Eronen, P., Laganier, J. and C. Madson, "IPv6
              Configuration in Internet Key Exchange Protocol Version 2
              (IKEv2)", RFC 5739, February 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet
              Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
              September 2010.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S. and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, March 2011.

   [RFC6418]  Blanchet, M. and P. Seite, "Multiple Interfaces and
              Provisioning Domains Problem Statement", RFC 6418,
              November 2011.

   [RFC6419]  Wasserman, M. and P. Seite, "Current Practices for
              Multiple-Interface Hosts", RFC 6419, November 2011.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A. and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

   [RFC6731]  Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive
              DNS Server Selection for Multi-Interfaced Nodes", RFC
              6731, December 2012.

   [RFC7078]  Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing
              Address Selection Policy Using DHCPv6", RFC 7078, January
              2014.

   [TS23.402]
              3GPP, "3GPP TS 23.402; Architecture enhancements for non-
              3GPP accesses; release 12", .

Anipko                   Expires March 17, 2015                [Page 22]
Internet-Draft             MPVD architecture              September 2014

Author's Address

   Dmitry Anipko, editor
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052
   USA
   
   Phone: +1 425 703 7070
   Email: dmitry.anipko@microsoft.com

Anipko                   Expires March 17, 2015                [Page 23]