draft-ietf-dnsop-cookies-08.txt   draft-ietf-dnsop-cookies-09.txt 
INTERNET-DRAFT Donald Eastlake INTERNET-DRAFT Donald Eastlake
Intended Status: Proposed Standard Huawei Intended Status: Proposed Standard Huawei
Mark Andrews Mark Andrews
ISC ISC
Expires: June 23, 2016 December 24, 2015 Expires: July 11, 2016 January 12, 2016
Domain Name System (DNS) Cookies Domain Name System (DNS) Cookies
<draft-ietf-dnsop-cookies-08.txt> <draft-ietf-dnsop-cookies-09.txt>
Abstract Abstract
DNS cookies are a lightweight DNS transaction security mechanism that DNS cookies are a lightweight DNS transaction security mechanism that
provides limited protection to DNS servers and clients against a provides limited protection to DNS servers and clients against a
variety of increasingly common denial-of-service and amplification / variety of increasingly common denial-of-service and amplification /
forgery or cache poisoning attacks by off-path attackers. DNS Cookies forgery or cache poisoning attacks by off-path attackers. DNS Cookies
are tolerant of NAT, NAT-PT, and anycast and can be incrementally are tolerant of NAT, NAT-PT, and anycast and can be incrementally
deployed. (Since DNS Cookies are only returned to the IP address from deployed. (Since DNS Cookies are only returned to the IP address from
which they were originally received, they cannot be used to generally which they were originally received, they cannot be used to generally
skipping to change at page 2, line 36 skipping to change at page 2, line 36
4.2 Server Cookie.........................................11 4.2 Server Cookie.........................................11
5. DNS Cookies Protocol Specification.....................12 5. DNS Cookies Protocol Specification.....................12
5.1 Originating Requests..................................12 5.1 Originating Requests..................................12
5.2 Responding to Request.................................12 5.2 Responding to Request.................................12
5.2.1 No Opt RR or No COOKIE OPT option...................13 5.2.1 No Opt RR or No COOKIE OPT option...................13
5.2.2 Malformed COOKIE OPT option.........................13 5.2.2 Malformed COOKIE OPT option.........................13
5.2.3 Only a Client Cookie................................13 5.2.3 Only a Client Cookie................................13
5.2.4 A Client Cookie and an Invalid Server Cookie........14 5.2.4 A Client Cookie and an Invalid Server Cookie........14
5.2.5 A Client Cookie and a Valid Server Cookie...........14 5.2.5 A Client Cookie and a Valid Server Cookie...........14
5.3 Processing Responses..................................14 5.3 Processing Responses..................................15
5.4 QUERYing for a Server Cookie..........................15 5.4 QUERYing for a Server Cookie..........................15
5.5 Client and Server Secret Rollover.....................16
6. NAT Considerations and AnyCast Server Considerations...17 6. NAT Considerations and AnyCast Server Considerations...17
7. Deployment.............................................19
8. IANA Considerations....................................20
9. Security Considerations................................21 7. Operational and Deployment Considerations..............19
9.1 Cookie Algorithm Considerations.......................21 7.1 Client and Server Secret Rollover.....................19
7.2 Counters..............................................20
10. Implementation Considerations.........................23 8. IANA Considerations....................................21
Normative References......................................24 9. Security Considerations................................22
Informative References....................................24 9.1 Cookie Algorithm Considerations.......................22
Acknowledgements..........................................26 10. Implementation Considerations.........................24
Appendix A: Example Client Cookie Algorithms..............27 Normative References......................................25
A.1 A Simple Algorithm....................................27 Informative References....................................25
A.2 A More Complex Algorithm..............................27
Acknowledgements..........................................27
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Table of Contents (continued) Table of Contents (continued)
Appendix B: Example Server Cookie Algorithms..............28 Appendix A: Example Client Cookie Algorithms..............28
B.1 A Simple Algorithm....................................28 A.1 A Simple Algorithm....................................28
B.2 A More Complex Algorithm..............................28 A.2 A More Complex Algorithm..............................28
Author's Address..........................................30 Appendix B: Example Server Cookie Algorithms..............29
B.1 A Simple Algorithm....................................29
B.2 A More Complex Algorithm..............................29
Author's Address..........................................31
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
1. Introduction 1. Introduction
As with many core Internet protocols, the Domain Name System (DNS) As with many core Internet protocols, the Domain Name System (DNS)
was originally designed at a time when the Internet had only a small was originally designed at a time when the Internet had only a small
pool of trusted users. As the Internet has grown exponentially to a pool of trusted users. As the Internet has grown exponentially to a
global information utility, the DNS has increasingly been subject to global information utility, the DNS has increasingly been subject to
abuse. abuse.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
"Soft state" indicates information learned or derived by a host which "Soft state" indicates information learned or derived by a host which
may be discarded when indicated by the policies of that host may be discarded when indicated by the policies of that host
but can be later re-instantiated if needed. For example, it but can be later re-instantiated if needed. For example, it
could be discarded after a period of time or when storage for could be discarded after a period of time or when storage for
caching such data becomes full. If operations requiring that caching such data becomes full. If operations requiring that
soft state continue after it has been discarded, it will be soft state continue after it has been discarded, it will be
automatically re-generated, albeit at some cost. automatically re-generated, albeit at some cost.
"Silently discarded" indicates that there are no DNS protocol message "Silently discarded" indicates that there are no DNS protocol message
consequences; however, it is RECOMMENDED that appropriate consequences.
network management facilities be included in implementations,
such as a counter of the occurrences of each such event type.
"IP address" is used herein as a length independent term and includes "IP address" is used herein as a length independent term and includes
both IPv4 and IPv6 addresses. both IPv4 and IPv6 addresses.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
2. Threats Considered 2. Threats Considered
DNS cookies are intended to provide significant but limited DNS cookies are intended to provide significant but limited
protection against certain attacks by off-path attackers as described protection against certain attacks by off-path attackers as described
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Figure 2. COOKIE Option, Known Server Cookie Figure 2. COOKIE Option, Known Server Cookie
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
4.1 Client Cookie 4.1 Client Cookie
The Client Cookie SHOULD be a pseudo-random function of the server IP The Client Cookie SHOULD be a pseudo-random function of the server IP
address and a secret quantity known only to the client. This client address and a secret quantity known only to the client. This client
secret SHOULD have at least 64 bits of entropy [RFC4086] and be secret SHOULD have at least 64 bits of entropy [RFC4086] and be
changed periodically (see Section 5.5). The selection of the pseudo- changed periodically (see Section 7.1). The selection of the pseudo-
random function is a matter private to the client as only the client random function is a matter private to the client as only the client
needs to recognize its own DNS cookies. needs to recognize its own DNS cookies.
For further discussion of the Client Cookie field, see Section 5.1. For further discussion of the Client Cookie field, see Section 5.1.
For example methods of determining a Client Cookie, see Appendix A. For example methods of determining a Client Cookie, see Appendix A.
In order to provide minimal authentication, a client MUST send Client In order to provide minimal authentication, a client MUST send Client
Cookies that will usually be different for any two servers at Cookies that will usually be different for any two servers at
different IP addresses. different IP addresses.
4.2 Server Cookie 4.2 Server Cookie
The Server Cookie SHOULD consist of or include a 64-bit or larger The Server Cookie SHOULD consist of or include a 64-bit or larger
pseudo-random function of the request source IP address, the request pseudo-random function of the request source IP address, the request
Client Cookie, and a secret quantity known only to the server. (See Client Cookie, and a secret quantity known only to the server. (See
Section 6 for a discussion of why the Client Cookie is used as input Section 6 for a discussion of why the Client Cookie is used as input
to the Server Cookie but the Server Cookie is not used as an input to to the Server Cookie but the Server Cookie is not used as an input to
the Client Cookie.) This server secret SHOULD have at least 64 bits the Client Cookie.) This server secret SHOULD have at least 64 bits
of entropy [RFC4086] and be changed periodically (see Section 5.5). of entropy [RFC4086] and be changed periodically (see Section 7.1).
The selection of the pseudo-random function is a matter private to The selection of the pseudo-random function is a matter private to
the server as only the server needs to recognize its own DNS cookies. the server as only the server needs to recognize its own DNS cookies.
For further discussion of the Server Cookie field see Section 5.2. For further discussion of the Server Cookie field see Section 5.2.
For example methods of determining a Server Cookie, see Appendix B. For example methods of determining a Server Cookie, see Appendix B.
When implemented as recommended, the server need not maintain any When implemented as recommended, the server need not maintain any
cookie related per client state. cookie related per client state.
In order to provide minimal authentication, a server MUST send Server In order to provide minimal authentication, a server MUST send Server
Cookies that will usually be different for clients at any two Cookies that will usually be different for clients at any two
skipping to change at page 12, line 15 skipping to change at page 12, line 15
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
5. DNS Cookies Protocol Specification 5. DNS Cookies Protocol Specification
This section discusses using DNS Cookies in the DNS Protocol. The This section discusses using DNS Cookies in the DNS Protocol. The
cycle of originating a request, responding to that request, and cycle of originating a request, responding to that request, and
processing the response are covered in Sections 5.1, 5.2, and 5.3. A processing the response are covered in Sections 5.1, 5.2, and 5.3. A
de facto extension to QUERY to allow pre-fetching a Server Cookie is de facto extension to QUERY to allow pre-fetching a Server Cookie is
specified in Section 5.4. Rollover of the client and server secrets specified in Section 5.4. Rollover of the client and server secrets
and transient retention of the old cookie or secret is covered in and transient retention of the old cookie or secret is covered in
Section 5.5. Section 7.1.
DNS clients and servers SHOULD implement DNS cookies to decrease DNS clients and servers SHOULD implement DNS cookies to decrease
their vulnerability to the threats discussed in Section 2. their vulnerability to the threats discussed in Section 2.
5.1 Originating Requests 5.1 Originating Requests
A DNS client that implements DNS Cookies includes one DNS COOKIE OPT A DNS client that implements DNS Cookies includes one DNS COOKIE OPT
option containing a Client Cookie in every DNS request it sends option containing a Client Cookie in every DNS request it sends
unless DNS cookies are disabled. unless DNS cookies are disabled.
skipping to change at page 12, line 48 skipping to change at page 12, line 48
assurance is provided by the Server Cookie that server sent to that assurance is provided by the Server Cookie that server sent to that
client in an earlier response appearing as the Server Cookie field in client in an earlier response appearing as the Server Cookie field in
the request. the request.
At a server where DNS Cookies are not implemented and enabled, At a server where DNS Cookies are not implemented and enabled,
presence of a COOKIE OPT option is ignored and the server responds as presence of a COOKIE OPT option is ignored and the server responds as
if no COOKIE OPT option had been included in the request. if no COOKIE OPT option had been included in the request.
When DNS Cookies are implemented and enabled, there are five When DNS Cookies are implemented and enabled, there are five
possibilities: (1) there is no OPT RR at all in the request or there possibilities: (1) there is no OPT RR at all in the request or there
is a OPT RR but the the COOKIE OPT option is absent from the OPT RR; is a OPT RR but the COOKIE OPT option is absent from the OPT RR; (2)
(2) a COOKIE OPT is present but is not a legal length or otherwise a COOKIE OPT is present but is not a legal length or otherwise
malformed; (3) there is a valid length cookie option in the request malformed; (3) there is a valid length cookie option in the request
with no Server Cookie; (4) there is a valid length COOKIE OPT in the with no Server Cookie; (4) there is a valid length COOKIE OPT in the
request with a Server Cookie but that Server Cookie is invalid; or request with a Server Cookie but that Server Cookie is invalid; or
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
(5) there is a valid length COOKIE OPT in the request with a correct (5) there is a valid length COOKIE OPT in the request with a correct
Server Cookie. Server Cookie.
The five possibilities are discussed in the subsections below. The five possibilities are discussed in the subsections below.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
5.2.1 No Opt RR or No COOKIE OPT option 5.2.1 No Opt RR or No COOKIE OPT option
If there is no OPT record or no COOKIE OPT option present in the If there is no OPT record or no COOKIE OPT option present in the
request then the server responds to the request as if the server request then the server responds to the request as if the server
doesn't implement the COOKIE OPT. doesn't implement the COOKIE OPT.
5.2.2 Malformed COOKIE OPT option 5.2.2 Malformed COOKIE OPT option
If the COOKIE OPT is too short to contain a Client Cookie then If the COOKIE OPT is too short to contain a Client Cookie then
FORMERR is generated. If the COOKIE OPT is longer than that required FORMERR is generated. If the COOKIE OPT is longer than that required
to hold a COOKIE OPT with just a Client Cookie (8) but is shorter to hold a COOKIE OPT with just a Client Cookie (8 bytes) but is
that the minimum COOKIE OPT with both a Client and Server Cookie (16) shorter that the minimum COOKIE OPT with both a Client and Server
then FORMERR is generated. If the COOKIE OPT is longer than the Cookie (16 bytes) then FORMERR is generated. If the COOKIE OPT is
maximum valid COOKIE OPT (40) then a FORMERR is generated. longer than the maximum valid COOKIE OPT (40 bytes) then a FORMERR is
generated.
In summary, valid cookie lengths are 8 and 16 to 40 inclusive. In summary, valid cookie lengths are 8 and 16 to 40 inclusive.
5.2.3 Only a Client Cookie 5.2.3 Only a Client Cookie
Based on server policy, including rate limiting, the server chooses Based on server policy, including rate limiting, the server chooses
one of the following: one of the following:
(1) Silently discard the request. (1) Silently discard the request.
(2) Send a BADCOOKIE error response. (2) Send a BADCOOKIE error response.
(3) Process the request and provide a normal response. The RCODE is (3) Process the request and provide a normal response. The RCODE is
NOERROR unless some non-cookie error occurs in processing the NOERROR unless some non-cookie error occurs in processing the
request. request.
If the server responds, choosing 2 or 3 above, it SHALL generate its If the server responds, choosing 2 or 3 above, it SHALL generate its
own COOKIE OPT containing both the Client Cookie copied from the own COOKIE OPT containing both the Client Cookie copied from the
request and a Server Cookie it has generated and adds this COOKIE OPT request and a Server Cookie it has generated and adds this COOKIE OPT
to the response's OPT record. Servers MUST, at least occasionally, to the response's OPT record. Servers MUST, at least occasionally,
respond to such requests to inform the client of the correct Server
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
respond to such requests to inform the client of the correct Server
Cookie. This is necessary so that such a client can bootstrap to the Cookie. This is necessary so that such a client can bootstrap to the
more secure state where requests and responses have recognized Server more secure state where requests and responses have recognized Server
Cookies and Client Cookies. A server is not expected to maintain per Cookies and Client Cookies. A server is not expected to maintain per
client state to achieve this. For example, it could respond to every client state to achieve this. For example, it could respond to every
Nth request across all clients. Nth request across all clients.
If the request was received over TCP, the server SHOULD take the If the request was received over TCP, the server SHOULD take the
authentication provided by the use of TCP into account and SHOULD authentication provided by the use of TCP into account and SHOULD
choose 3. In this case, if the server is not willing to accept the choose 3. In this case, if the server is not willing to accept the
security provided by TCP as a substitute for the security provided by security provided by TCP as a substitute for the security provided by
DNS Cookies but instead chooses 2, there is some danger of an DNS Cookies but instead chooses 2, there is some danger of an
indefinite loop of retries (see Section 5.3). indefinite loop of retries (see Section 5.3).
5.2.4 A Client Cookie and an Invalid Server Cookie 5.2.4 A Client Cookie and an Invalid Server Cookie
The server examines the Server Cookie to determine if it is a valid The server examines the Server Cookie to determine if it is a valid
Server Cookie it has generated. This examination will result in a Server Cookie it has generated. This determination normally involves
determination of whether the Server Cookie is valid or not. If the re-calculating the Server Cookie (or the hash part thereof) based on
the server secret (or the previous server secret if it has just
changed), the received Client Cookie, the client IP address, and
possibly other fields -- see Appendix B.2 for an example. If the
cookie is invalid, it can be because of a stale Server Cookie, or a cookie is invalid, it can be because of a stale Server Cookie, or a
client's IP address or Client Cookie changing without the DNS server client's IP address or Client Cookie changing without the DNS server
being aware, or an anycast server cluster that is not consistently being aware, or an anycast server cluster that is not consistently
configured, or an attempt to spoof the client. configured, or an attempt to spoof the client.
The server SHALL process the request as if the invalid Server Cookie The server SHALL process the request as if the invalid Server Cookie
was not present as described in Section 5.2.3. was not present as described in Section 5.2.3.
5.2.5 A Client Cookie and a Valid Server Cookie 5.2.5 A Client Cookie and a Valid Server Cookie
When a valid Server Cookie is present in the request the server can When a valid Server Cookie is present in the request the server can
assume that the request is from a client that it has talked to before assume that the request is from a client that it has talked to before
and defensive measures for spoofed UDP requests, if any, are no and defensive measures for spoofed UDP requests, if any, are no
longer required. longer required.
The server SHALL process the request and include a COOKIE OPT in the The server SHALL process the request and include a COOKIE OPT in the
response by (a) copying the complete COOKIE OPT from the request or response by (a) copying the complete COOKIE OPT from the request or
(b) generating a new COOKIE OPT containing both the Client Cookie (b) generating a new COOKIE OPT containing both the Client Cookie
copied from the request and a valid Server Cookie it has generated. copied from the request and a valid Server Cookie it has generated.
INTERNET-DRAFT DNS Cookies
5.3 Processing Responses 5.3 Processing Responses
The Client Cookie, when it occurs in a COOKIE OPT option in a DNS The Client Cookie, when it occurs in a COOKIE OPT option in a DNS
reply, is intended to weakly assure the client that the reply came reply, is intended to weakly assure the client that the reply came
from a server at the source IP address used in the response packet from a server at the source IP address used in the response packet
because the Client Cookie value is the value that client would send because the Client Cookie value is the value that client would send
INTERNET-DRAFT DNS Cookies
to that server in a request. In a DNS reply with multiple COOKIE OPT to that server in a request. In a DNS reply with multiple COOKIE OPT
options, all but the first (the one closest to the DNS Header) are options, all but the first (the one closest to the DNS Header) are
ignored. ignored.
A DNS client where DNS cookies are implemented and enabled examines A DNS client where DNS cookies are implemented and enabled examines
the response for DNS cookies and MUST discard the response if it the response for DNS cookies and MUST discard the response if it
contains an illegal COOKIE OPT option length or an incorrect Client contains an illegal COOKIE OPT option length or an incorrect Client
Cookie value. If the COOKIE OPT option Client Cookie is correct, the Cookie value. If the COOKIE OPT option Client Cookie is correct, the
client caches the Server Cookie provided even if the response is an client caches the Server Cookie provided even if the response is an
error response (RCODE non-zero). error response (RCODE non-zero).
skipping to change at page 15, line 44 skipping to change at page 15, line 50
5.4 QUERYing for a Server Cookie 5.4 QUERYing for a Server Cookie
In many cases a client will learn the Server Cookie for a server as In many cases a client will learn the Server Cookie for a server as
the side effect of another transaction; however, there may be times the side effect of another transaction; however, there may be times
when this is not desirable. Therefore a means is provided for when this is not desirable. Therefore a means is provided for
obtaining a Server Cookie through an extension to the QUERY opcode obtaining a Server Cookie through an extension to the QUERY opcode
for which opcode most existing implementations require that QDCOUNT for which opcode most existing implementations require that QDCOUNT
be one (see Section 4.1.2 of [RFC1035]). be one (see Section 4.1.2 of [RFC1035]).
For servers with DNS Cookies enabled, the QUERY opcode behavior is For servers with DNS Cookies enabled, the QUERY opcode behavior is
extended to support queries with a empty question section (QDCOUNT extended to support queries with an empty question section (QDCOUNT
zero) provided that an OPT record is present with a COOKIE option. zero) provided that an OPT record is present with a COOKIE option.
Such servers will reply with an empty answer section and a COOKIE Such servers will reply with an empty answer section and a COOKIE
option giving the Client Cookie provided in the query and a valid option giving the Client Cookie provided in the query and a valid
Server Cookie. Server Cookie.
INTERNET-DRAFT DNS Cookies
If such a query provided just a Client Cookie and no Server Cookie, If such a query provided just a Client Cookie and no Server Cookie,
the response SHALL have the RCODE NOERROR. the response SHALL have the RCODE NOERROR.
This mechanism can also be used to confirm/re-establish a existing This mechanism can also be used to confirm/re-establish an existing
Server Cookie by sending a cached Server Cookie with the Client Server Cookie by sending a cached Server Cookie with the Client
INTERNET-DRAFT DNS Cookies
Cookie. In this case the response SHALL have the RCODE BADCOOKIE if Cookie. In this case the response SHALL have the RCODE BADCOOKIE if
the Server Cookie sent with the query was invalid and the RCODE the Server Cookie sent with the query was invalid and the RCODE
NOERROR if it was valid. NOERROR if it was valid.
Servers which don't support the COOKIE option will normally send Servers which don't support the COOKIE option will normally send
FORMERR in response to such a query, though REFUSED, NOTIMP, and FORMERR in response to such a query, though REFUSED, NOTIMP, and
NOERROR without a COOKIE option are also possible in such responses. NOERROR without a COOKIE option are also possible in such responses.
5.5 Client and Server Secret Rollover
The longer a secret is used, the higher the probability it has been
compromised. Thus clients and servers MUST NOT continue to use the
same secret in new requests and responses for more than 36 days and
SHOULD NOT continue to do so for more than 26 hours. These values are
chosen to assure that a secret will not be used for longer than about
a month and normally no longer than one day. The odd values are to
allow for long holiday weekends and daylight savings time shifts and
the like while still staying within the limits.
Many clients rolling over their secret at the same time could briefly
increase server traffic and exactly predictable rollover times for
clients or servers might facilitate guessing attacks. For example, an
attacker might increase the priority of attacking secrets they
believe will be in effect for an extended period of time. To avoid
rollover synchronization and predictability, it is RECOMMENDED that
pseudorandom jitter in the range of plus zero to minus at least 40%
be applied to the time until a scheduled rollover of a DNS cookie
secret.
It is RECOMMENDED that a client keep the Client Cookie it is
expecting in a reply associated with the outstanding request to avoid
rejection of replies due to a bad Client Cookie right after a change
in the client secret. It is RECOMMENDED that a server retain its
previous secret for a period of time not less than 1 second or more
than 5 minutes, after a change in its secret, and consider requests
with Server Cookies based on its previous secret to have a correct
Server Cookie during that time. When a server responds to a request
containing a old Server Cookie that the server is treating as
correct, the server MUST include a new Server Cookie in its response.
When a server or client starts receiving an increased level of
requests with bad server cookies or replies with bad client cookies,
it would be reasonable for it to believe it is likely under attack
and it should consider a more frequent rollover of its secret. More
rapid rollover decreases the benefit to a cookie guessing attacker if
they succeed in guessing a cookie.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
6. NAT Considerations and AnyCast Server Considerations 6. NAT Considerations and AnyCast Server Considerations
In the Classic Internet, DNS Cookies could simply be a pseudo-random In the Classic Internet, DNS Cookies could simply be a pseudo-random
function of the client IP address and a server secret or the server function of the client IP address and a server secret or the server
IP address and a client secret. You would want to compute the Server IP address and a client secret. You would want to compute the Server
Cookie that way, so a client could cache its Server Cookie for a Cookie that way, so a client could cache its Server Cookie for a
particular server for an indefinitely amount of time and the server particular server for an indefinite amount of time and the server
could easily regenerate and check it. You could consider the Client could easily regenerate and check it. You could consider the Client
Cookie to be a weak client signature over the server IP address that Cookie to be a weak client signature over the server IP address that
the client checks in replies and you could extend this signature to the client checks in replies and you could extend this signature to
cover the request ID, for example, or any other information that is cover the request ID, for example, or any other information that is
returned unchanged in the reply. returned unchanged in the reply.
But we have this reality called NAT [RFC3022], Network Address But we have this reality called NAT [RFC3022], Network Address
Translation (including, for the purposes of this document, NAT-PT, Translation (including, for the purposes of this document, NAT-PT,
Network Address and Protocol Translation, which has been declared Network Address and Protocol Translation, which has been declared
Historic [RFC4966]). There is no problem with DNS transactions Historic [RFC4966]). There is no problem with DNS transactions
skipping to change at page 18, line 42 skipping to change at page 18, line 42
are not unduly burdensome. (When such anycast-accessed servers act are not unduly burdensome. (When such anycast-accessed servers act
as recursive servers or otherwise act as clients they normally use a as recursive servers or otherwise act as clients they normally use a
different unique address to source their requests to avoid confusion different unique address to source their requests to avoid confusion
in the delivery of responses.) in the delivery of responses.)
For simplicity, it is RECOMMENDED that the same server secret be used For simplicity, it is RECOMMENDED that the same server secret be used
by each DNS server in a set of anycast servers. If there is limited by each DNS server in a set of anycast servers. If there is limited
time skew in updating this secret in different anycast servers, this time skew in updating this secret in different anycast servers, this
can be handled by a server accepting requests containing a Server can be handled by a server accepting requests containing a Server
Cookie based on either its old or new secret for the maximum likely Cookie based on either its old or new secret for the maximum likely
time period of such time skew (see also Section 5.5). time period of such time skew (see also Section 7.1).
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
7. Deployment 7. Operational and Deployment Considerations
The DNS cookies mechanism is designed for incremental deployment and The DNS cookies mechanism is designed for incremental deployment and
to complement the orthogonal techniques in [RFC5452]. Either or both to complement the orthogonal techniques in [RFC5452]. Either or both
techniques can be deployed independently at each DNS server and techniques can be deployed independently at each DNS server and
client. client. Thus installation at the client and server end need not be
synchronized.
In particular, a DNS server or client that implements the DNS COOKIE In particular, a DNS server or client that implements the DNS COOKIE
mechanism can interoperate successfully with a DNS client or server mechanism can interoperate successfully with a DNS client or server
that does not implement this mechanism although, of course, in this that does not implement this mechanism although, of course, in this
case it will not get the benefit of the mechanism and the server case it will not get the benefit of the mechanism and the server
involved might choose to severely rate limit responses. When such a involved might choose to severely rate limit responses. When such a
server or client interoperates with a client or server which also server or client interoperates with a client or server which also
implements the DNS cookies mechanism, they get the security benefits implements the DNS cookies mechanism, they get the security benefits
of the DNS Cookies mechanism. of the DNS Cookies mechanism.
7.1 Client and Server Secret Rollover
The longer a secret is used, the higher the probability it has been
compromised. Thus clients and servers are configured with a lifetime
for their secret and rollover to a new secret when that lifetime
expires or earlier due to deliberate jitter as described below. The
default lifetime is one day and the maximum permitted is one month.
To be precise and to make it practical to stay within limits despite
long holiday weekends and daylight savings time shifts and the like,
clients and servers MUST NOT continue to use the same secret in new
requests and responses for more than 36 days and SHOULD NOT continue
to do so for more than 26 hours.
Many clients rolling over their secret at the same time could briefly
increase server traffic and exactly predictable rollover times for
clients or servers might facilitate guessing attacks. For example, an
attacker might increase the priority of attacking secrets they
believe will be in effect for an extended period of time. To avoid
rollover synchronization and predictability, it is RECOMMENDED that
pseudorandom jitter in the range of plus zero to minus at least 40%
be applied to the time until a scheduled rollover of a DNS cookie
secret.
It is RECOMMENDED that a client keep the Client Cookie it is
expecting in a reply associated with the outstanding request to avoid
rejection of replies due to a bad Client Cookie right after a change
in the client secret. It is RECOMMENDED that a server retain its
previous secret after a rollover to a new secret for a configurable
period of time not less than 1 second or more than 5 minutes with
default configuration of 2 1/2 minutes. Requests with Server Cookies
based on its previous secret are treated as a correct Server Cookie
INTERNET-DRAFT DNS Cookies
during that time. When a server responds to a request containing a
old Server Cookie that the server is treating as correct, the server
MUST include a new Server Cookie in its response.
7.2 Counters
It is RECOMMENDED that implementations include counters of the
occurrences of the various types of requests and responses described
in Section 5.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
8. IANA Considerations 8. IANA Considerations
IANA has assigned the following OPT option value: IANA has assigned the following OPT option value:
Value Name Status Reference Value Name Status Reference
-------- ------ -------- --------------- -------- ------ -------- ---------------
10 COOKIE Standard [this document] 10 COOKIE Standard [this document]
skipping to change at page 21, line 20 skipping to change at page 22, line 20
responses. In particular, they provide no protection against "on- responses. In particular, they provide no protection against "on-
path" adversaries; that is, they provide no protection against any path" adversaries; that is, they provide no protection against any
adversary that can observe the plain text DNS traffic, such as an on- adversary that can observe the plain text DNS traffic, such as an on-
path router, bridge, or any device on an on-path shared link (unless path router, bridge, or any device on an on-path shared link (unless
the DNS traffic in question on that path is encrypted). the DNS traffic in question on that path is encrypted).
For example, if a host is connected via an unsecured IEEE Std 802.11 For example, if a host is connected via an unsecured IEEE Std 802.11
link (Wi-Fi), any device in the vicinity that could receive and link (Wi-Fi), any device in the vicinity that could receive and
decode the 802.11 transmissions must be considered "on-path". On the decode the 802.11 transmissions must be considered "on-path". On the
other hand, in a similar situation but one where 802.11 Robust other hand, in a similar situation but one where 802.11 Robust
Security (WPAv2) is appropriately deployed on the Wi-Fi network Security (WPA2) is appropriately deployed on the Wi-Fi network nodes,
nodes, only the Access Point via which the host is connecting is "on- only the Access Point via which the host is connecting is "on-path"
path" as far as the 802.11 link is concerned. as far as the 802.11 link is concerned.
Despite these limitations, deployment of DNS Cookies on the global Despite these limitations, deployment of DNS Cookies on the global
Internet is expected to provide a significant reduction in the Internet is expected to provide a significant reduction in the
available launch points for the traffic amplification and denial of available launch points for the traffic amplification and denial of
service forgery attacks described in Section 2 above. service forgery attacks described in Section 2 above.
Should stronger message/transaction security be desired, it is Should stronger message/transaction security be desired, it is
suggested that TSIG or SIG(0) security be used (see Section 3.2); suggested that TSIG or SIG(0) security be used (see Section 3.2);
however, it may be useful to use DNS Cookies in conjunction with however, it may be useful to use DNS Cookies in conjunction with
these features. In particular, DNS Cookies could screen out many DNS these features. In particular, DNS Cookies could screen out many DNS
skipping to change at page 21, line 44 skipping to change at page 22, line 44
required and, if SIG(0) is in use, DNS Cookies could usefully screen required and, if SIG(0) is in use, DNS Cookies could usefully screen
out many requests given that SIG(0) does not screen requests but only out many requests given that SIG(0) does not screen requests but only
authenticates the response of complete transactions. authenticates the response of complete transactions.
An attacker that does not know the Server Cookie could do a variety An attacker that does not know the Server Cookie could do a variety
of things, such as omitting the COOKIE OPT option or sending a random of things, such as omitting the COOKIE OPT option or sending a random
Server Cookie. In general, DNS servers need to take other measures, Server Cookie. In general, DNS servers need to take other measures,
including rate limiting responses, to protect from abuse in such including rate limiting responses, to protect from abuse in such
cases. See further information in Section 5.2. cases. See further information in Section 5.2.
When a server or client starts receiving an increased level of
requests with bad server cookies or replies with bad client cookies,
it would be reasonable for it to believe it is likely under attack
and it should consider a more frequent rollover of its secret. More
rapid rollover decreases the benefit to a cookie guessing attacker if
they succeed in guessing a cookie.
9.1 Cookie Algorithm Considerations 9.1 Cookie Algorithm Considerations
The cookie computation algorithm for use in DNS Cookies SHOULD be The cookie computation algorithm for use in DNS Cookies SHOULD be
based on a pseudo-random function at least as strong as 64-bit FNV based on a pseudo-random function at least as strong as 64-bit FNV
INTERNET-DRAFT DNS Cookies
(Fowler-Noll-Vo [FNV]) because an excessively weak or trivial (Fowler-Noll-Vo [FNV]) because an excessively weak or trivial
algorithm could enable adversaries to guess cookies. However, in algorithm could enable adversaries to guess cookies. However, in
light of the lightweight plain-text token security provided by DNS light of the lightweight plain-text token security provided by DNS
Cookies, a strong cryptography hash algorithm may not be warranted in Cookies, a strong cryptography hash algorithm may not be warranted in
many cases, and would cause an increased computational burden. many cases, and would cause an increased computational burden.
Nevertheless there is nothing wrong with using something stronger, Nevertheless there is nothing wrong with using something stronger,
for example, HMAC-SHA256 [RFC6234] truncated to 64 bits, assuming a for example, HMAC-SHA256 [RFC6234] truncated to 64 bits, assuming a
INTERNET-DRAFT DNS Cookies
DNS processor has adequate computational resources available. DNS DNS processor has adequate computational resources available. DNS
processors that feel the need for somewhat stronger security without processors that feel the need for somewhat stronger security without
a significant increase in computational load should consider more a significant increase in computational load should consider more
frequent changes in their client and/or server secret; however, this frequent changes in their client and/or server secret; however, this
does require more frequent generation of a cryptographically strong does require more frequent generation of a cryptographically strong
random number [RFC4086]. See Appendices A and B for specific examples random number [RFC4086]. See Appendices A and B for specific examples
of cookie computation algorithms. of cookie computation algorithms.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
10. Implementation Considerations 10. Implementation Considerations
The DNS Cookie Option specified herein is implemented in BIND 9.10 The DNS Cookie Option specified herein is implemented in BIND 9.10
using a experimental option code. using an experimental option code.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Normative References Normative References
[RFC1035] - Mockapetris, P., "Domain names - implementation and [RFC1035] - Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 26, line 12 skipping to change at page 27, line 12
10.17487/RFC6234, May 2011, <http://www.rfc- 10.17487/RFC6234, May 2011, <http://www.rfc-
editor.org/info/rfc6234>. editor.org/info/rfc6234>.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Acknowledgements Acknowledgements
The suggestions and contributions of the following are gratefully The suggestions and contributions of the following are gratefully
acknowledged: acknowledged:
Bob Harold, Paul Hoffman, Yoav Nir, Gayle Noble, Tim Wicinski Bob Harold, Paul Hoffman, Yoav Nir, Gayle Noble, Dan Romascanu,
Tim Wicinski, Peter Yee
The document was prepared in raw nroff. All macros used were defined The document was prepared in raw nroff. All macros used were defined
within the source file. within the source file.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Appendix A: Example Client Cookie Algorithms Appendix A: Example Client Cookie Algorithms
A.1 A Simple Algorithm A.1 A Simple Algorithm
An simple example method to compute Client Cookies is the FNV-64 A simple example method to compute Client Cookies is the FNV-64 [FNV]
[FNV] of the server IP address and the client secret. That is of the server IP address and the client secret. That is
Client Cookie = FNV-64 ( Server IP Address | Client Secret ) Client Cookie = FNV-64 ( Server IP Address | Client Secret )
where "|" indicates concatenation. (If the order of the items where "|" indicates concatenation. (If the order of the items
concatenated above were reversed, it might be possible to reduce the concatenated above were reversed, it might be possible to reduce the
computational effort by pre-computing FNV-64 through the bytes of the computational effort by pre-computing FNV-64 through the bytes of the
Client Secret but this would reduce the strength of the Client Cookie Client Secret but this would reduce the strength of the Client Cookie
and is NOT RECOMMENDED.) and is NOT RECOMMENDED.)
A.2 A More Complex Algorithm A.2 A More Complex Algorithm
skipping to change at page 28, line 52 skipping to change at page 29, line 52
Time 32 bits Time 32 bits
Hash 64 bits Hash 64 bits
With this algorithm, the server sends a new 128-bit cookie back with With this algorithm, the server sends a new 128-bit cookie back with
every request. The Nonce field assures a low probability that there every request. The Nonce field assures a low probability that there
would be a duplicate. would be a duplicate.
The Time field gives the server time and makes it easy to reject old The Time field gives the server time and makes it easy to reject old
cookies. cookies.
The Hash part of the Server Cookie is the hard-to-guess part. In the The Hash part of the Server Cookie is the hard-to-guess part. In BIND
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
beta release of BIND, its computation can be configured to use AES, 9.10.3 (and later), its computation can be configured to use AES,
HMAC-SHA1, or, as shown below, HMAC-SHA256: HMAC-SHA1, or, as shown below, HMAC-SHA256:
hash = hash =
HMAC-SHA256-64 ( Server Secret, HMAC-SHA256-64 ( Server Secret,
(Client Cookie | nonce | time | client IP Address) ) (Client Cookie | nonce | time | client IP Address) )
where "|" represents concatenation. where "|" represents concatenation.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
skipping to change at page 30, line 26 skipping to change at page 31, line 26
Mark Andrews Mark Andrews
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 USA Redwood City, CA 94063 USA
Email: marka@isc.org Email: marka@isc.org
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
 End of changes. 43 change blocks. 
98 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/