Internet DRAFT - draft-kkb-mpvd-dhcp-support
draft-kkb-mpvd-dhcp-support
DHC Working Group S. Krishnan
Internet-Draft Ericsson
Intended status: Standards Track J. Korhonen
Expires: August 17, 2014 Broadcom
S. Bhandari
Cisco Systems
February 13, 2014
Support for multiple provisioning domains in DHCPv6
draft-kkb-mpvd-dhcp-support-01
Abstract
The MIF working group is producing a solution to solve the issues
that are associated with nodes that can be attached to multiple
networks. One part of the solution requires associating
configuration information with provisioning domains. This document
details how configuration information provided through DHCPv6 can be
associated with provisioning domains.
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 August 17, 2014.
Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect
Krishnan, et al. Expires August 17, 2014 [Page 1]
Internet-Draft DHCPv6 mPVD support February 2014
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PVD Container option . . . . . . . . . . . . . . . . . . . . . 3
4. PVD Identity option . . . . . . . . . . . . . . . . . . . . . . 4
5. PVD Authentication and Authorization option . . . . . . . . . . 4
6. Set of allowable options . . . . . . . . . . . . . . . . . . . 6
7. Behaviour of DHCPv6 entities . . . . . . . . . . . . . . . . . 6
7.1. Client and Requesting Router Behavior . . . . . . . . . . . 6
7.2. Server and Delegating Router Behavior . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
11. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Krishnan, et al. Expires August 17, 2014 [Page 2]
Internet-Draft DHCPv6 mPVD support February 2014
1. Introduction
The MIF working group is producing a solution to solve the issues
that are associated with nodes that can be attached to multiple
networks based on the Multiple Provisioning Domains (MPVD)
architecture work [I-D.anipko-mif-mpvd-arch]. One part of the
solution requires associating configuration information with
provisioning domains. This document describes a DHCPv6 mechanism for
explicitly indicating provisioning domain information along with any
configuration that will be provided. The proposed mechanism uses a
DHCPv6 option that indicates the identity of the provisioning domain
and encapsulates the options that contain the configuration
information as well as any accompanying authentication/authorization
information.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. PVD Container option
The PVD container option is used to encapsulate and group together
all the configuration options that belong to the explicitly
identified provisioning domain. The PVD container option MUST
encapsulate exactly one OPTION_PVD_ID. The PVD container option MAY
occur multiple times in the same message, but each of these PVD
container options MUST have a different PVD identity specified under
its PVD identity option. The PVD container option SHOULD contain
exactly one OPTION_PVD_AUTH.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PVD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ encapsulated-options (variable length) .
. .
+---------------------------------------------------------------+
Figure 1: PVD Container Option
Krishnan, et al. Expires August 17, 2014 [Page 3]
Internet-Draft DHCPv6 mPVD support February 2014
o option-code: OPTION_PVD (TBA1)
o option-length: Length of encapsulated options
o encapsulated-options: options associated with this provisioning
domain.
4. PVD Identity option
The PVD identity option is used to explicitly indicate the identity
of the provisioning domain that is associated with the configuration
information encapsulated by the PVD container option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PVD_ID | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PVD identity information |
+ (variable length) +
+ +
. .
+---------------------------------------------------------------+
Figure 2: PVD ID Option
o option-code: OPTION_PVD_ID (TBA2)
o option-length: Length of PVD identity information
o PVD identity information: The provisioning domain identity.
The contents of this field is defined in
a separate document [PVDIDS].
5. PVD Authentication and Authorization option
The PVD authentication and authorization option contains information
that could be used by the DHCPv6 client to verify whether the
configuration information provided was not tampered with by the
DHCPv6 server as well as establishing that the DHCPv6 server was
authorized to advertise the information on behalf of the PVD per
OPTION_PVD basis. The contents of the authentication/authorization
information is provided by the owner of the provisioning domain and
is completely opaque to the DHCPv6 server that passes along the
information unmodified. Every OPTION_PVD option SHOULD contain at
Krishnan, et al. Expires August 17, 2014 [Page 4]
Internet-Draft DHCPv6 mPVD support February 2014
most one OPTION_PVD_AUTH option. The OPTION_PVD_AUTH option MUST be
the last option inside the OPTION_PVD option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PVD_AUTH | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
| name-type | key-hash : |
+-+-+-+-+-+-+-+-+ : |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth
: : info
: digital-signature : |
: : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
Figure 3: PVD Auth Option
o option-code: OPTION_PVD_AUTH (TBA3)
o option-length: Length of the Auth info
o name-type: Names the algorithm used to identify a specific
X.509 certificate using the method defined for the Subject Key
Identifier (SKI) extension for the X.509 certificates. The
usage and the Name Type registry aligns with the mechanism
defined for SeND [RFC6494][RFC6495]. Name Type values starting
from 3 are supported and an implementation MUST at least support
SHA-1 (value 3).
o key-hash: A hash of the public key using the algorithm
identified by the Name Type. The procedure how the Key Hash is
calculated is defined in [RFC3971] and [RFC6495]
o digital-signature: A signature calculated over the encapsulating
OPTION_PVD including all option data from the beginning of the
option while setting the digital-signature field to zero. The
procedure of calculating the signature is identical to the one
defined for SeND [RFC3971].
[TODO: There may be some alignment considerations here for some
implementations as DHCPv6 options are not aligned.]
Krishnan, et al. Expires August 17, 2014 [Page 5]
Internet-Draft DHCPv6 mPVD support February 2014
6. Set of allowable options
The PVD container option MAY be used to encapsulate any allocated
DHCPv6 options but MUST NOT be used to encapsulate another OPTION_PVD
option. [TODO: Should we add any other exclusions?]
7. Behaviour of DHCPv6 entities
This section describes role of DHCPv6 entities involved in requesting
and receiving DHCPv6 configuration or prefix and address allocation.
7.1. Client and Requesting Router Behavior
DHCPv6 client or requesting router can request for configuration from
provisioning domain in the following ways:
o In the SOLICIT message it MAY include OPTION_PVD_ID requesting
configuration for the specific PVD ID indicated in the
OPTION_PVD_ID option. It can include multiple OPTION_PVD_ID
options to indicate its preference for more than one provisioning
domain. The PVD ID it requests is learnt via configuration or any
other out of band mechanism not defined in this document.
o In the SOLICIT message include an OPTION_ORO option with the
OPTION_PVD option code to request configuration from all the PVDs
that the DHCPv6 server can provide.
The client or requesting router parses OPTION_PVD options in the
response message. The Client or Requesting router MUST then include
all or subset of the received OPTION_PVD options in the REQUEST
message so that it will be responsible for the configuration
information selected.
If DHCPv6 client or requesting router receives OPTION_PVD options but
does not support PVD, it SHOULD ignore the received option(s).
7.2. Server and Delegating Router Behavior
If the Server or Delegating router supports PVD and it is configured
to provide configuration data in one or more provisioning domains, it
selects configuration for the PVD based allocation in the following
way:
o If OPTION_PVD option code within OPTION_ORO is not present in the
request, it MUST NOT include provisioning domain based
configuration. It MAY select configuration and prefix allocation
from a default PVD defined.
Krishnan, et al. Expires August 17, 2014 [Page 6]
Internet-Draft DHCPv6 mPVD support February 2014
o If OPTION_PVD_ID is included, it selects information to be offered
from that specific PVD if available.
o If OPTION_PVD option code within OPTION_ORO is included, then
based on its configuration and policy it MAY offer configuration
from the available PVD(s).
When PVD information and configuration are selected for address and
prefix allocation the server or delegating router responds with an
ADVERTISE message after populating OPTION_PVD.
If OPTION_PVD is not included, then the server or delegating router
MAY allocate the prefix and provide configuration as specified in
[RFC3315] and[RFC3633] and MUST NOT include OPTION_PVD option in the
response.
If OPTION_ORO option includes the OPTION_PVD option code but the
server or delegating router does not support PVD, then it SHOULD
ignore the OPTION_PVD and OPTION_PVD_ID options received.
If both client/requesting router and server/delegating router support
PVD but cannot offer configuration with PVD for any other reason, it
MUST respond to client/requesting router with appropriate status code
as specified in [RFC3315] and [RFC3633].
8. Security Considerations
An attacker may attempt to modify the information provided inside the
PVD container option. These attacks can easily be prevented by using
the DHCPv6 AUTH option [RFC3315] that would detect any form of
tampering with the DHCPv6 message contents.
A compromised DHCPv6 server or relay agent may insert configuration
information related to PvDs it is not authorized to advertise. e.g.
A coffee shop DHCPv6 server may provide configuration information
purporting to be from an enterprise and may try to attract enterprise
related traffic. The only real way to avoid this is that the PvD
container contains embedded authentication and authorization
information from the owner of the PvD. Then, this attack can be
detected by the client by verifying the authentication and
authorization information provided inside the PVD container option
after verifying its trust towards the PvD owner (e.g. a certificate
with a well-known/common trust anchor).
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 some replay protection mechanism such as a timestamp or a
nonce inside the PvD container to ensure freshness of the provided
Krishnan, et al. Expires August 17, 2014 [Page 7]
Internet-Draft DHCPv6 mPVD support February 2014
information.
9. IANA Considerations
This document defines three new DHCPv6 options to be allocated out of
the registry at http://www.iana.org/assignments/dhcpv6-parameters/
OPTION_PVD (TBA1)
OPTION_PVD_ID (TBA2)
OPTION_PVD_AUTH (TBA3)
10. Acknowledgements
The authors would like to thank the members of the MIF architecture
design team for their comments that led to the creation of this
draft.
11. Normative References
[I-D.anipko-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture",
draft-anipko-mif-mpvd-arch-05 (work in progress),
November 2013.
[PVDIDS] Krishnan, S., Korhonen, J., Bhandari, S., and S.
Gundavelli, "Identification of provisioning domains",
draft-kkbg-mpvd-id-00 (work in progress), February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
Krishnan, et al. Expires August 17, 2014 [Page 8]
Internet-Draft DHCPv6 mPVD support February 2014
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
Profile and Certificate Management for SEcure Neighbor
Discovery (SEND)", RFC 6494, February 2012.
[RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key
Identifier (SKI) SEcure Neighbor Discovery (SEND) Name
Type Fields", RFC 6495, February 2012.
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Jouni Korhonen
Broadcom Communications
Porkkalankatu 24
FIN-00180 Helsinki
Finland
Email: jouni.nospam@gmail.com
Shwetha Bhandari
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone: +91 80 4426 0474
Email: shwethab@cisco.com
Krishnan, et al. Expires August 17, 2014 [Page 9]
