HOMENET D. Migault (Ed)
Internet-Draft Orange
Intended status: Standards Track October 20, 2013
Expires: April 23, 2014
IPv6 Home Network Naming Delegation
draft-mglt-homenet-dnssec-validator-dhc-options-01.txt
Abstract
DNSSEC provides data integrity and authentication for DNSSEC
validators. However, without valid trust anchor(s) and an acceptable
value for the current time, DNSSEC validation cannot be performed.
As a result, there are multiple cases where DNSSEC validation MUST
NOT be performed. In addition, this list of exceptions is expected
to become larger over time.
Considering an increasing number of cases where DNSSEC is disabled
adds complexity to the DNSSEC validator implementations and increases
the vectors that disable security.
This document assumes that DNSSEC adoption by end devices requires
that end devices MUST be able to support a DNSSEC validation always
set. This MUST be valid today as well as in the future.
This document describes DHCP Options to provision the DHCP Client
with valid trust anchors and time so DNSSEC validation can be
performed.
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 23, 2014.
Copyright Notice
Migault (Ed) Expires April 23, 2014 [Page 1]
Internet-Draft Home Network Naming Delegation October 2013
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
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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Motivations for providing DNSSEC Trust Anchor . . . . . . 3
3.2. Motivations for providing Time . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. DHCP DNSSEC Trust Anchor Options . . . . . . . . . . . . . . 6
5.1. DHCP DNSSEC KSK RR Trust Anchor Options . . . . . . . . . 6
5.2. DHCP DNSSEC KSK CERT Trust Anchor Options . . . . . . . . 6
6. DHCP Time Option . . . . . . . . . . . . . . . . . . . . . . 7
7. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . 8
8. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 9
9. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informational References . . . . . . . . . . . . . . . . 11
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Requirements notation
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].
2. Introduction
DNSSEC [RFC4033], [RFC4034], [RFC4035] adds data authentication and
integrity checks to DNS [RFC1034], [RFC1035]. For signature
validation, DNSSEC requires a trust anchor such as the Key Signing
Migault (Ed) Expires April 23, 2014 [Page 2]
Internet-Draft Home Network Naming Delegation October 2013
Key (KSK) of the Root Zone or any other zone. Without a trust
anchor, DNSSEC validation cannot be performed. In addition KSKs and
signatures are valid for a given period of time. As a result, DNSSEC
validation cannot be performed if time shifting is to large.
This document considers DHCP DNSSEC Trust Anchor Option and DHCP Time
Option to provision a device with trusted KSKs and current time.
Although our priority is to provide the Root Zone KSK, we also
consider the case other trusted KSK MAY be provided, for example, if
a Zone does not provide secure delegation, or to mitigate badly
configured DNSSEC zones (like TLDs zones).
The main motivation for these DHCP Options is that DHCP enabled
devices have DNSSEC validation always set and do not need to perform
DNS resolution without DNSSEC validation. In fact, enabling DNS with
no validation represents a potential way to remove security and MAY
be used by attackers. Similarly, DNSSEC configuration implemented in
the end users device, MAY not consider future cases and MAY introduce
vulnerabilities. DHCP Options prevent this as long as the
relationship between DHCP Client and DHCP Server is trusted.
This document assumes that the channel between the DHCP Client and
the DHCP Server is trusted and secured with DHCP mechanisms described
in [RFC3315], or IPsec [RFC4301].
3. Threat Model
This document addresses the case of a device configured with DNSSEC
validation set that is plugged in, gets connectivity (using DHCP for
example), but fails DNSSEC resolutions because its trust anchor KSK
is not valid anymore or its local time is not valid.
This threat mainly addresses devices that can be switched off for a
long period of time or devices that MAY be off-shelves for a long
time before being plugged in. CPEs as well as any homenet devices
are concerned by this use case.
This threat also addresses DNSSEC emergency key roll over operations.
Devices that have cached the out-of-date KSK will not be able to
check the signatures until the TTL has expired on all caches.
This document proposes DHCP Options that provide the necessary
parameters to perform DNSSEC validation. These Options MUST be used
on a trusted network over a trusted channel between the DHCP Client
and the DHCP Server. These options MAY be used in conjunction of
additional mechanisms.
3.1. Motivations for providing DNSSEC Trust Anchor
Migault (Ed) Expires April 23, 2014 [Page 3]
Internet-Draft Home Network Naming Delegation October 2013
The first motivation for providing trusted KSKs is to provide
automatic configuration of devices to enable DNSSEC validation. This
avoids validator initial KSK provisioning issue as well as KSK roll
over issues.
A validator MAY not be able to perform signature check with an
authenticated KSK because:
- 1) It does not have a trust anchor (like the Root Zone KSK)
- 2) The KSK MAY have been authenticated, stored or cached with an
expiration date valid but is not valid anymore. This MAY
happen in the case of an emergency key roll over, if the device
has been offline during the key roll over, or if the key roll
over is not performed as described in [DPS-KSK], [RFC5011].
- 3) The chain of trust MAY have been broken. This can happen to
non Root Zone KSK only and MAY not involve the responsibility
of the owner of the zone. The deeper the Zone is in the
hierarchy, the more likely this happens.
- 4) A DNSSEC zone MAY have been badly signed or a KSK MAY have been
badly generated. The DNSSEC MAY be correct, but DNSSEC
validator MAY keep for a long time the badly generated KSK,
ZSK...
The goal of the DHCP DNSSEC Trust Anchor Option is to provide these
validators trusted anchors like the Root Zone KSK, as well as other
KSKs (TLDs...) so the validator has the proper KSKs to perform DNSSEC
validation.
Most documents are currently focused on the Root Zone KSK for which
recommendations and alternative mechanisms have been described. [I-D
.jabley-dnsop-validator-bootstrap] provides guide lines on how to
retrieve and select DNSSEC Trust Anchors. Section 5.3 and [I-D
.jabley-dnssec-trust-anchor] describes mechanisms to retrieve
securely the Root Zone KSK relying on TLS security. It suggests to
use insecure DNS resolution to set HTTPS connections. Using HTTPS
requires downloading the keyDigest id (key-label) from https://
data.iana.org/root-anchors/root-anchors.xml, followed by an HTTPS
request at https://data.iana.org/root-anchors/key-label.crt to get
the whole certificate.
The key advantages of the DHCP DNSSEC Trust Anchor Option described
in this document are that we extend the mechanism to any KSK, and
validators can set DNSSEC validation for all DNS queries. However,
we do not see any contradiction between recommendations provided by
[I-D.jabley-dnsop-validator-bootstrap] and [I-D.jabley-dnssec-trust-
Migault (Ed) Expires April 23, 2014 [Page 4]
Internet-Draft Home Network Naming Delegation October 2013
anchor] and believe the principle described in these documents SHOULD
be applied by the validators. Note also that DHCP DNSSEC Trust
Anchor Option only benefits to validators that are configured via
DHCP.
To recover from a DNSSEC failure and remove a particular data from
cache, [I-D.jabley-dnsop-dns-flush] suggests to use a NOTIFY message
between Authoritative Servers and Resolvers. This mechanism is set
between Recursive Server and Authoritative Servers with a specific
trusted relationship. This is probably a selection of TLDs. This
document, does not address the DNSSEC failure over Recursive Servers,
but addresses more specifically DHCP configured devices. These are
typically CPEs or End Users. We believe that configuring and
restarting DNSSEC validators with DHCP Option, is an easier way to
cope with this issue. First the trust relation between DHCP Server
already exists, we do not need additional trusted channel between
Authoritative Servers or eventually the Recursive Servers. Then
basic implementations of stub resolvers, in CPE or desktops may not
address NOTIFY message.
3.2. Motivations for providing Time
KSKs and signatures are always associated to an expiration time. As
a result, DNSSEC validation requires that the validator knows the
current time.
A number of mechanisms exists like [TLSDATE] or [RFC5905] for setting
the time of the device. In addition, [RFC5908] provides a Network
Time Protocol (NTP) Server Option for DHCP. The DHCP Time Option
described in this document differs from [RFC5908] as it provides an
estimation of the current time, instead of providing the NTP servers
location information. The time value provided by the DHCP Time
Option should be used only if previously mentioned mechanisms are
either not implemented on the device or are unavailable. One of the
reason MAY be that you MAY need valid DNS(SEC) resolution to use
these protocols. The time provided by the DHCP Time Option does not
have the accuracy of NTP and SHOULD be considered as a best effort
value. [I-D.jabley-dnsop-validator-bootstrap] also recommends that
when time has not been verified by the validator, the signature
validation SHOULD be done with time off.
The key advantage of the DHCP Time Option is that it makes possible
to have DNSSEC validation always set. It limits the possible DNSSEC
validation variants which potentially expose the device to disable
DNSSEC validations. Note also that DHCP Time Option only benefits to
validators that are configured via DHCP.
4. Terminology
Migault (Ed) Expires April 23, 2014 [Page 5]
Internet-Draft Home Network Naming Delegation October 2013
5. DHCP DNSSEC Trust Anchor Options
This section describes two options:
- DHCP DNSSEC KSK Trust Anchor Options: carries the KSK RRset as
described in [RFC1035] with a DNSKEY RDATA as described in
[RFC4033]. This data is not integrity protected, nor it can be
authenticated. Such data SHOULD be trusted over a trusted DHCP
channel.
- DHCP DNSSEC CERT Trust Anchor Options: Carries a certificate
encoded as described in [RFC4398]. The advantage of the
Certificate is that is enables authentication of the received
information by a trusted party. For example, CPE providers MAY
provide a trusted certification authority. Unlike DNSSEC key
roll over, the CPE provider controls the key roll over of the
certification authority it provides.
5.1. DHCP DNSSEC KSK RR Trust Anchor Options
The DHCP DNSSEC KSK Trust Anchor Option provides the RRset as
mentioned in the DNS(SEC) Zone. In other words, it carries the RR as
defined in Section 3.2. of [RFC1035] and a RDATA DNSKEY as defined
in Section 2.1 of [RFC4033]. As the RR has a variable length, the
DHCP DNSSEC KSK Trust Anchor Options follows the recommendation
format of Section 5.9 of [I-D.ietf-dhc-option-guidelines].
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-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. KSK RR .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DHCP DNSSEC KSK Trust Anchor Options
Payload Description
- option-code: OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR
- option-len: An unsigned integer giving the length of the KSK RR
field in this option in octets
5.2. DHCP DNSSEC KSK CERT Trust Anchor Options
Migault (Ed) Expires April 23, 2014 [Page 6]
Internet-Draft Home Network Naming Delegation October 2013
The DHCP DNSSEC CERT Trust Anchor Option provides a certificate. The
CERT RR is described in [RFC4398]. Note that only the RDATA
associated to the CERT is present in the DHCP Option. As the RR has
a variable length, the DHCP DNSSEC KSK CERT Trust Anchor Options
follows the recommendation format of Section 5.9 of [I-D.ietf-dhc-
option-guidelines].
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-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. KSK CERT RDATA .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DHCP DNSSEC CERT Trust Anchor Options
Payload Description
- option-code: OPTION_DNSSEC_CERT_TRUST_ANCHOR
- option-len: An unsigned integer giving the length of the KSK RR
field in this option in octets
The X.509 [RFC5280] certificate MUST have a keyUsage set to
digitalSignature (0) and nonRepudiation (1). Subject Alternative
Name DNS name indicates the name of the zone.
In order to be compliant with the certificate of the Root Zone
described [I-D.jabley-dnssec-trust-anchor]. The CERT for a KSK
SHOULD have a Common Name (CN) with the string "'Zone-FQDN' Zone KSK"
followed by the time and date of key generation in the format
specified in [RFC3339]. 'Zone-FQDN' is the name of the zone and
SHOULD be the same as the one mentioned in Subject Alternative Name.
The resourceRecord Attribute SHOULD be set with the DS RRset.
6. DHCP Time Option
The DHCP DNSSEC Time Option is used by the DHCP Server to indicate
the Time to the DHCP Client. The Time is provided in a string format
as specified in [RFC3339] and in [I-D.ietf-dhc-option-guidelines]
Section 5.8.
Migault (Ed) Expires April 23, 2014 [Page 7]
Internet-Draft Home Network Naming Delegation October 2013
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-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TXT Time Format .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DHCP Time Options
Payload Description
- option-code: OPTION_TIME
- option-len: A string representing the Time
7. DHCP Client Behavior
DHCP DNSSEC KSK Trust Anchor Option, DHCP DNSSEC CERT Trust Anchor
Option or DHCP Time Option described in this document are intended
for DNSSEC validation. If a connected device is not performing
DNSSEC validation, it MUST NOT send a DHCP an Option Request DHCP
Option (ORO) [RFC3315] for any of these options, and MUST ignore all
these options if provided by the DHCP Server.
The DHCP sends a DHCP ORO for one or multiple options described in
the document. Motivations for sending this Option Request DHCP
Option is out of scope of the document. It could be a device
switched off for a long time, a device that cannot validate the
DNSSEC responses.
A channel is considered trusted if 1) the DHCP Server is trusted and
authenticated and 2) exchanged data between the DHCP Client and the
DHCP Server is integrity protected. IPsec [RFC4301], for example,
MAY be used to establish a secure channel.
Over a trusted channel, the DHCP Client that performs DNSSEC
validation MAY send an ORO for any of the DHCP DNSSEC KSK Trust
Anchor Option, the DHCP DNSSEC CERT Trust Anchor Option or the DHCP
Time Option to a DHCP Server.
Over a trusted channel, the DHCP Client that performs DNSSEC
validation SHOULD consider the DHCP DNSSEC KSK Trust Anchor Option,
the DHCP DNSSEC CERT Trust Anchor Option or the DHCP Time Option sent
by the DHCP Server.
Migault (Ed) Expires April 23, 2014 [Page 8]
Internet-Draft Home Network Naming Delegation October 2013
Over a non trusted channel, the DHCP Client MAY only send ORO for a
DHCP DNSSEC CERT Trust Anchor Option. This option is the only one
that MAY be considered by the DHCP Client if sent by the DHCP Server.
If the DHCP Client does not trust the signer of the certificate, the
option MUST be ignored.
When a DHCP DNSSEC KSK Trust Anchor Option or a DHCP DNSSEC CERT
Trust Anchor Option is accepted by the DHCP Client, it MUST remove
overwrite old values for the KSK with the new one.
When a DHCP Time Option is accepted by the DHCP Client, it MUST check
the difference between its clock and the time provided by the Option.
It SHOULD overwrite its clock value only if the difference is too
large.
In any other case, ORO requests MUST NOT be sent by the DHCP Client,
and options received by the DHCP Server MUST NOT be considered by the
DHCP Client. The remaining of the section details when the options
MUST NOT be requested by the DHCP Client and MUST be ignored by the
DHCP Client when received by the DHCP Server.
The DHCP Client MUST NOT send an ORO for a DHCP DNSSEC KSK Trust
Anchor Option, a DHCP DNSSEC CERT Trust Anchor Option or a DHCP Time
Option to a DHCP Server that is either not trusted or not
authenticated.
All DHCP DNSSEC KSK Trust Anchor Option, a DHCP DNSSEC CERT Trust
Anchor Option or a DHCP Time Option received from DHCP Server that is
not authenticated or that is not trusted MUST be ignored by the DHCP
Client.
The DHCP Client MUST NOT send an ORO for a DHCP DNSSEC KSK Trust
Anchor Option or a DHCP Time Option to a trusted DHCP Server over an
untrusted channel. A DHCP DNSSEC CERT Trust Anchor Option MAY be
requested over an untrusted channel since the certificate is signed
and thus can be authenticated. A DHCP DNSSEC CERT Trust Anchor
Option signed by an untrusted authority MUST be ignored by the DHCP
Client.
All DHCP DNSSEC KSK Trust Anchor Option or a DHCP Time Option
received from DHCP Server over a channel that is not trusted MUST be
ignored by the DHCP Client.
8. DHCP Server Behavior
The DHCP Server SHOULD properly answer with the requested options in
the ORO, even if the DHCP Server does not consider the channel with
DHCP Client as trusted.
Migault (Ed) Expires April 23, 2014 [Page 9]
Internet-Draft Home Network Naming Delegation October 2013
The DHCP Server MAY also provide DHCP DNSSEC KSK Trust Anchor Option,
DHCP DNSSEC CERT Trust Anchor Option or DHCP Time Option without
being requested by the DHCP Client. This could for example prevent
failures not detected by the DHCP Client.
9. DHCP Relay Agent Behavior
The DHCP Options described in the document do not impact the Relay
Agent.
10. IANA Considerations
The DHCP options detailed in this document is:
- OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR: TBD
- OPTION_DNSSEC_KSK_CERT_TRUST_ANCHOR: TBD
- OPTION_TIME: TBD
11. Security Considerations
Security has been discussed in the "DHCP Client Behavior Section".
As information contained in the payloads are use to enable signature
validation, these pieces of information MUST be considered only when
issued by a trusted party, and when integrity protection is provided.
12. Acknowledgment
Bringing DNSSEC in Home Networks discussion has started during the
IETF87 in Berlin with Ted Lemon, Ralph Weber, Normen Kowalewski, and
Mikael Abrahamsson. An email discussion has also been initiated by
Jim Gettys with among others, helpful remarks from Paul Wouters, Joe
Abley, Michael Ridchardson.
13. References
13.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Migault (Ed) Expires April 23, 2014 [Page 10]
Internet-Draft Home Network Naming Delegation October 2013
[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.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP)
Server Option for DHCPv6", RFC 5908, June 2010.
13.2. Informational References
[DPS-KSK] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter,
"DNSSEC Practice Statement for the Root Zone KSK
Operation", Root DNSSEC Design Team, URL: http://www
.root-dnssec.org/wp-content/uploads/2010/06/icann-
dps-00.txt, 2010.
Migault (Ed) Expires April 23, 2014 [Page 11]
Internet-Draft Home Network Naming Delegation October 2013
[I-D.ietf-dhc-option-guidelines]
Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
draft-ietf-dhc-option-guidelines-14 (work in progress),
September 2013.
[I-D.jabley-dnsop-dns-flush]
Abley, J., "A Mechanism for Remote-Triggered DNS Cache
Flushes (DNS FLUSH)", draft-jabley-dnsop-dns-flush-00
(work in progress), June 2013.
[I-D.jabley-dnsop-validator-bootstrap]
Abley, J. and D. Knight, "Establishing an Appropriate Root
Zone DNSSEC Trust Anchor at Startup", draft-jabley-dnsop-
validator-bootstrap-00 (work in progress), January 2011.
[I-D.jabley-dnssec-trust-anchor]
Abley, J., Schlyter, J., and G. Bailey, "DNSSEC Trust
Anchor Publication for the Root Zone", draft-jabley-
dnssec-trust-anchor-07 (work in progress), June 2013.
[TLSDATE] error, IO., "tlsdate: secure parasitic rdate replacement",
URL: https://github.com/ioerror/tlsdate, 2013.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-00: First version published.
Author's Address
Daniel Migault
Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Phone: +33 1 45 29 60 52
Email: mglt.ietf@gmail.com
Migault (Ed) Expires April 23, 2014 [Page 12]