One document matched: draft-ietf-mif-mpvd-ndp-support-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc4861 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY rfc4862 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY rfc2460 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY rfc4122 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml">
<!ENTITY rfc4282 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY rfc3971 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY rfc6495 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6495.xml">
<!ENTITY rfc6494 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6494.xml">
<!ENTITY rfc6487 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml">
<!ENTITY I-D.ietf-mif-mpvd-arch PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-mpvd-arch-03.xml">
<!ENTITY I-D.kkbg-mpvd-id PUBLIC ""
"http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kkbg-mpvd-id.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-mif-mpvd-ndp-support-00"
ipr="trust200902">
<front>
<title abbrev="NDP PVD support">Support for multiple provisioning domains in IPv6
Neighbor Discovery Protocol</title>
<author fullname="Jouni Korhonen" initials="J." surname="Korhonen" >
<organization abbrev="Broadcom">Broadcom</organization>
<address>
<postal>
<street>Porkkalankatu 24</street>
<code>FIN-00180 Helsinki</code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 Decarie Blvd.</street>
<city>Town of Mount Royal</city>
<region>QC</region>
<country>Canada</country>
</postal>
<phone>+1 514 345 7900 x42871</phone>
<email>suresh.krishnan@ericsson.com</email>
</address>
</author>
<author fullname="Sri Gundavelli" initials="S.G." surname="Gundavelli">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>sgundave@cisco.com</email>
</address>
</author>
<date />
<area>Internet</area>
<workgroup>IPv6 Maintenance</workgroup>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref target="I-D.ietf-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)
<xref target="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) <xref target="RFC3971"/>.
</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="PVD Container option" anchor="opt_pvd_co">
<t>The PVD container option (PVD_CO) is used to mark the start of the
configuration options that belong to the explicitly identified provisioning
domain. The PVD container option MUST encapsulate exactly one PVD identifier
option (PVD_ID, see <xref target="suboptions"/>).
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. The PVD
container options MUST NOT be nested.
</t>
<t>
A PVD container is intended to be used in IPv6 Router Advertisement
(RA) NDP messages. However, including a PVD container or identity
options inside a Router Solicitation (RS) NDP messages is also
possible (actually, in this way a host can solicit for information
from a specific provisioning domain). The PVD container option MUST
NOT be included in a NDP message without accompanying PVD identity
option (see <xref target="suboptions"/>). If, for some reason, the
NDP message does not include the accompanying PVD identity option,
then the implementation MUST ignore the PVD container option and
SHOULD log the event. The PVD container MUST NOT be fragmented i.e.,
should the IPv6 packet be fragmented, the PVD container and the
accompanying PVD identity MUST both be inside the same fragment.
</t>
<t>Since implementations are required to ignore any unrecognized
options <xref target="RFC4861"/>, the backward compatibility and the
reuse of existing NDP options is implicitly enabled. Implementations
that do not recognize the PVD container option plain ignore it and
also skip PVD container option "encapsulated" NDP options normally
without associating them into any provisioning domain (since the
implementation has no notion of provisioning domains). For example,
the PVD container could "encapsulate" a Prefix Information Option
(PIO), which would mark that this certain advertised IPv6 prefix
belongs and originates from a specific provisioning domain. However,
if the implementation does not understand provisioning domains, then
this specific PIO is also skipped and not configured to the
interface.
</t>
<t>
The optional security for the PVD container is based on X.509
certificates <xref target="RFC6487"/> and reuses mechanisms already
defined for SeND <xref target="RFC3971"/> <xref target="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. See <xref target="RFC6494"/>
for discussion how to enable deployments where the certificates
needed to sign PVD containers) belong to different
administrative domains i.e. to different provisioning
domains.
</t>
<figure anchor="fig_pvdco" title="PVD Container Option">
<artwork><![CDATA[
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 |S| Reserved | Name Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Key Hash (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Digital Signature (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible zero padding to ensure 8 octets alignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style="hanging" hangIndent="4">
<t hangText="Type"><vspace blankLines="1"/>
PVD Container; Set to TBD1.
<vspace blankLines="1"/></t>
<t hangText="Length"><vspace blankLines="1"/>
Length of the PVD_CO. The actual length depends on the number of "encapsulated"
NDP options, the length of the PVD identifier option
and the optional Key Hash/Digital Signature/Padding.
<vspace blankLines="1"/></t>
<t hangText="S"><vspace blankLines="1"/>
Security enabled/disabled flag. If S=0 then security (signing) of the
PVD_CO is disabled. If S=1 then security (signing) is enabled.
<vspace blankLines="1"/></t>
<t hangText="Name Type"><vspace blankLines="1"/>
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 <xref target="RFC6495"/>. Name Type values
starting from 3 are supported and an implementation MUST at least support
SHA-1 (value 3). Note that if S=0 the Name field serves no use.
<vspace blankLines="1"/></t>
<t hangText="Key Hash"><vspace blankLines="1"/>
This field is only present when S=1.
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
<xref target="RFC3971"/> and <xref target="RFC6495"/>.
<vspace blankLines="1"/></t>
<t hangText="Digital Signature"><vspace blankLines="1"/>
This field is only present when S=1.
A signature calculated over the PVD_CO option including all option data
from the beginning of the option until to the end of the container.
The procedure
of calculating the signature is identical to the one defined for SeND
<xref target="RFC3971"/>. During the signature calculation the contents of
the Digital Signature option MUST be treated as all zero.
</t>
</list>
</t>
<t>Implementations MUST ensure that the PVD container option meets the 8
octets NDP option alignment requirement. This MAY imply adding padding zero
octets to the tail of the PVD container option until the alignment
requirement has been met. The padding is independent of the 'S' flag setting.
</t>
<t>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.
</t>
<t>If the PVD_CO contains a signature and the verification fails, then
the whole PVD_CO, PVD_ID and other NDP options MUST be silently ignored
and the event SHOULD be logged.
</t>
</section>
<section title="PVD Identity option" anchor="suboptions">
<t>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 option MUST have exactly
one PVD identity option. However, the PVD identity option MAY also be
included in a NDP message without the PVD container option. In this
case it merely serves as a hint of provisioning domain and could, for example,
be used in an RS message to solicit information from specific provisioning
domains.
</t>
<figure anchor="fig_pvdid" title="PVD_ID Option">
<artwork>
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 | Identity ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging" hangIndent="4">
<t hangText="Type"><vspace blankLines="1"/>
PVD identifier; Set to TBD2.
<vspace blankLines="1"/></t>
<t hangText="Length"><vspace blankLines="1"/>
Length of the PVD_ID.
<vspace blankLines="1"/></t>
<t hangText="Identity"><vspace blankLines="1"/>
The provisioning domain identity. The contents of this field is
defined in a separate document <xref target="I-D.kkbg-mpvd-id"/>.
Note that the Identity field may need to be zero padded at the
tail to meets the natural NDP options' alignment.
</t>
</list>
</t>
<t>If the receiver of the PVD identity option does not understand any of the
ID-Types, then anything belonging to this provisioning domain MUST
be silently discarded. This would mean the PVD identity option, the PVD
container option and all other options.
</t>
</section>
<section title="Set of allowable options">
<t>The PVD container option MAY be used to encapsulate any allocated IPv6
NDP options, which may appear more than once in a NDP message. The PVD
container option MUST NOT be used to encapsulate other PVD_CO option(s).
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>An attacker may attempt to modify the information provided inside the PVD container
option. These attacks can easily be prevented by using SeND <xref
target="RFC3971"></xref> or per PVD container signature that would detect any form
of tampering with the IPv6 NDP message contents.
</t>
<t>
A compromised router may advertise configuration information related
to provisioning domains 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 provisioning domain container contains
embedded authentication and authorization information from the owner
of the provisioning domain. 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
provisioning domain owner (e.g. a certificate with a well-known/common
trust anchor).
</t>
<t>
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
information. This specification does not define a replay protection
solution. Rather it is assumed that if replay protection is required, the
access network and hosts also deploy existing security solutions such as
SeND <xref target="RFC3971"/>.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document defines two new IPv6 NDP options into the
"IPv6 Neighbor Discovery Option Formats" registry. The options
TBD1 and TBD2 are described in <xref target="opt_pvd_co"/> and
<xref target="suboptions"/>.
</t>
</section>
<section anchor="acks" title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4861;
&rfc6494;
&rfc6495;
&I-D.kkbg-mpvd-id;
</references>
<references title="Informative References">
&rfc6487;
&rfc3971;
&I-D.ietf-mif-mpvd-arch;
</references>
<section title="Examples">
<section title="One implicit PVD and one explicit PVD">
<t><xref target="fig_ex1"/> shows how the NDP options are laid out
in an RA for
one implicit provisioning domain and one explicit provisioning domain.
The example does not include security (and signing of the PVD container).
The assumption is the PVD identity consumes 14 octets.
</t>
<t>The explicit provisioning domain ("starducks.example.com" in a
NAI Realm format) contains a specific
PIO for 2001:db8:abad:cafe::/64 and the MTU of 1337 octets. The implicit
provisioning domain
configures a prefix 2001:db8:cafe:babe::/64 and the link MTU of 1500
octets. There are two cases: 1) the host receiving the RA implements
provisioning domains and 2) the host does not understand provisioning
domains.<vspace blankLines="1"/>
<list style="numbers">
<t>The host recognizes the PVD_CO and "starts" a provisioning domain
specific configuration. Security is disabled, thus there are no
Key Hash or Digital Signature fields to process. The prefix
2001:db8:abad:cafe::/64 is found and configured on the interface.
Once the PVD_ID option is located the interface prefix configuration
for 2001:db8:abad:cafe::/64 and the MTU of 1337 octets can be associated
to the provisioning domain found in the PVD_ID option.
<vspace blankLines="1"/>
The rest of the options are
parsed and configured into the implicit provisioning domain since there is no
encapsulating provisioning domain. The interface is configured
with prefix 2001:db8:cafe:babe::/64. The
implicit provisioning domain uses the link MTU of 1500 octets, whereas
the "starducks.example.com" provisioning domain uses the MTU of 1337
octets (this means when packets are sourced using 2001:db8:abad:cafe::/64
prefix the link MTU is different than when sourcing packets using
2001:db8:cafe:babe::/64 prefix).
<vspace blankLines="1"/></t>
<t>The host ignores the PVD_CO (including the PVD_ID and other options)
and ends up configuring
one prefix on its interface ( 2001:db8:cafe:babe::/64) with a link
MTU of 1500 octets.
</t>
</list>
</t>
<figure anchor="fig_ex1" title="An RA with one implicit PVD and one explicit PVD">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 134 | 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |0|1| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
| Type=PVD_CO | 10 |0| Reserved | 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 3 | 4 | 64 |1|1| Reserved1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
| Preferred Lifetime | D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 2001:db8:abad:cafe:: ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type=PVD_ID | 4 | id-type=4 | 21 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ "starducks.example.com",'\0','\0','\0','\0','\0','\0','\0' | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 5 | 1 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1337 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+
| 3 | 4 | Prefix Length |1|1| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2001:db8:cafe:babe:: ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:25 |