Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol
draft-kk-mpvd-ndp-support-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jouni Korhonen , Suresh Krishnan | ||
| Last updated | 2013-10-21 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kk-mpvd-ndp-support-00
IPv6 Maintenance J. Korhonen
Internet-Draft Broadcom
Intended status: Standards Track S. Krishnan
Expires: April 24, 2014 Ericsson
October 21, 2013
Support for multiple provisioning domains in IPv6 Neighbor Discovery
Protocol
draft-kk-mpvd-ndp-support-00
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 IPv6 Neighbor
Discovery Protocol 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 April 24, 2014.
Copyright Notice
Copyright (c) 2013 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
to this document. Code Components extracted from this document must
Korhonen & Krishnan Expires April 24, 2014 [Page 1]
Internet-Draft NDP PVD support October 2013
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 . . . . . . . . . . . . . . . . . . . . . . 6
5. Set of allowable options . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Korhonen & Krishnan Expires April 24, 2014 [Page 2]
Internet-Draft NDP PVD support October 2013
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 (PVD). This document describes an IPv6 Neighbor
Discovery Protocol (NDP) [RFC4861] mechanism for explicitly
indicating provisioning domain information along with any
configuration that will be provided. The proposed mechanism uses an
NDP 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.
The solution defined in this document aligns as much as possible with
the existing IPv6 Neighbor Discovery security, namely with Secure
Neighbor Discovery (SeND) [RFC3971].
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 (PVD_CO) 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 PVD identifier option (PVD_ID). The PVD
container option MAY occur multiple times in the same NDP message but
each of these PVD container options MUST have a different PVD
identity specified under its PVD identity option. A PVD container is
intended to be used in IPv6 Router Advertisement (RA) NDP messages.
However, including a PVD container inside a Router Solicitation (RS)
NDP messages is also possible (actually, a host can in this way
solicit for information from a specific PVD).
For the backward compatibility and the reuse of existing NDP options,
the PVD container can encapsulate any (meaningful) existing IPv6 NDP
options. For example, the PVD container could encapsulate a Prefix
Information Option (PIO), which would mark that a certain advertised
IPv6 prefix belongs and originates from a specific PVD. Furthermore,
for the backward compatibility reasons, it is RECOMMENDED that
options critical for establishing IP communication (such as the
prefix and DNS information) are encapsulated inside the PVD container
Korhonen & Krishnan Expires April 24, 2014 [Page 3]
Internet-Draft NDP PVD support October 2013
as well as in the RA (although this will cause duplication of
information is most cases). This ensures hosts that do not
understand provisioning domain concept, will at least receive the
implicit provisioning domain configuration. Hosts that understand
provisioning domain SHOULD always give configuration information
encapsulated inside the PVD container a higher priority than the ones
outside the PVD container(s). It should be noted that a router can
do smart advertisement of "legacy" configuration information and the
PVD container encapsulated. The router MAY leave some of the
provisioning domain specific information outside the "legacy
[RFC4861] way" of advertising them in RAs.
The optional security for the PVD container is based on X.509
certificates [RFC6487] and reuses mechanisms already defined for SeND
[RFC3971] [RFC6495]. However, the use of PVD containers does not
assume or depend on SeND being deployed or even implemented. The PVD
containers SHOULD be signed per PVD certificates, which provides both
integrity protection and proves that the configuration information
source is authorized for advertising the given information.
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=PVD_CO | Length | Options Count | Name Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Suboptions (padded to 8 octet boundary) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
: : |
: Key Hash : o
: : p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t
: : i
: Digital Signature : o
: : n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a
: Padding (zeroes) : l
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
Figure 1: PVD Container Option
Type
PVD Container; Set to TBA1.
Korhonen & Krishnan Expires April 24, 2014 [Page 4]
Internet-Draft NDP PVD support October 2013
Length
Length of the PVD_CO. The actual length depends on the number of
suboptions and the optional Key Hash/Digital Signature/Padding.
Options Count
The number of suboptions in this PVD container. MUST be 1 or
greater.
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).
Suboptions
One or more suboptions that describe properties and other meta
data attached to the provisioning domain. See Section 4 for
description of the PVD_ID suboption. All suboptions MUST be
multiple of 8 octets and provide required padding with '\0'
octets, when needed. Unknown suboptions MUST be silently
discarded.
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].
Digital Signature
A signature calculated over the PVD_CO option including all
option data from the beginning of the option until the Key Hash
field. The procedure of calculating the signature is identical
to the one defined for SeND [RFC3971].
Padding
Zero or more '\0' octets to make the PVD_CO to multiple of 8
octets.
The presence of the optional Key Hash and Digital Signature field is
Korhonen & Krishnan Expires April 24, 2014 [Page 5]
Internet-Draft NDP PVD support October 2013
determined from the Length field, i.e. the option length is greater
than 0 after subtracting 'Options Count' times suboptions from it,
then the signature part of the option is present. If the PVD_CO does
not contain a digital signature, then other means to secure the
integrity of the NDP message SHOULD be provided, such as utilizing
SeND. However, the security provided by SeND is for the entire NDP
message and does not allow verifying whether the sender of the NDP
message is actually authorized for the information for the
provisioning domain.
If the PVD_CO contains a signature and the verification fails, then
the whole PVD_CO MUST be silently discarded and the event SHOULD be
logged.
4. PVD Identity option
The PVD identity option (PVD_ID) is used to explicitly indicate the
identity of the provisioning domain that is associated with the
configuration information encapsulated by the PVD container option.
A PVD container MUST have exactly one PVD identity 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PVD_ID | Length | ID-Type | ID-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Provisioning Domain Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PVD_ID Option
Type
PVD identifier; Set to TBA2.
Length
Length of the PVD_ID.
ID-Type
Describes the type of identification information. This document
defines four types of PVD identity information:
Korhonen & Krishnan Expires April 24, 2014 [Page 6]
Internet-Draft NDP PVD support October 2013
0x01: UUID [RFC4122]
0x02: UTF-8 string
0x03: OID [OID]
0x03: NAI Realm [RFC4282]
ID-Length
Length of the Provisioning Domain Identifier in octets.
Provisioning Domain Identifier
The PVD identification that is based on the id-type. The
identifier MUST be '\0' octet padded until the PVD_ID option
length is multiple of 8 octet.
If the receiver of the PVD_ID option does not understand any of the
ID-Types, then the whole encapsulating PVD_CO MUST be silently
discarded.
5. Set of allowable options
The PVD container option MAY be used to encapsulate any allocated
IPv6 NDP options but MUST NOT be used to encapsulate another PVD_CO
option. [TODO: Should we add any other exclusions?].
6. Security Considerations
An attacker may attempt to modify the information provided inside the
PVD container option. These attacks can easily be prevented by using
SeND [RFC3971] or per PVD container signature that would detect any
form of tampering with the IPv6 NDP message contents.
A compromised router may advertise configuration information related
to PvDs it is not authorized to advertise. e.g. A coffee shop router
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
Korhonen & Krishnan Expires April 24, 2014 [Page 7]
Internet-Draft NDP PVD support October 2013
including some replay protection mechanism such as a timestamp or a
nonce inside the PvD container to ensure freshness of the provided
information.
7. IANA Considerations
This document defines new IPv6 Neighbor discovery options from the
registry at http://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-5
PVD_CO: TBA1
PVD_ID: TBA2
This document reuses information from a new registry for PVD Identity
types
http://www.iana.org/assignments/dhcpv6-parameters/
8. 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.
9. References
9.1. Normative References
[OID] IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management
Private Enterprise Codes, http://www.iana.org/
assignments/enterprise-numbers/enterprise-numbers.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Korhonen & Krishnan Expires April 24, 2014 [Page 8]
Internet-Draft NDP PVD support October 2013
[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.
9.2. Informative References
[I-D.anipko-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture",
draft-anipko-mif-mpvd-arch-04 (work in progress),
October 2013.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
February 2012.
Authors' Addresses
Jouni Korhonen
Broadcom
Porkkalankatu 24
FIN-00180 Helsinki
Finland
Email: jouni.nospam@gmail.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Korhonen & Krishnan Expires April 24, 2014 [Page 9]