draft-ietf-dnsop-cookies-09.txt   draft-ietf-dnsop-cookies-10.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: July 11, 2016 January 12, 2016 Expires: October 4, 2016 April 5, 2016
Domain Name System (DNS) Cookies Domain Name System (DNS) Cookies
<draft-ietf-dnsop-cookies-09.txt> <draft-ietf-dnsop-cookies-10.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 48 skipping to change at page 2, line 48
6. NAT Considerations and AnyCast Server Considerations...17 6. NAT Considerations and AnyCast Server Considerations...17
7. Operational and Deployment Considerations..............19 7. Operational and Deployment Considerations..............19
7.1 Client and Server Secret Rollover.....................19 7.1 Client and Server Secret Rollover.....................19
7.2 Counters..............................................20 7.2 Counters..............................................20
8. IANA Considerations....................................21 8. IANA Considerations....................................21
9. Security Considerations................................22 9. Security Considerations................................22
9.1 Cookie Algorithm Considerations.......................22 9.1 Cookie Algorithm Considerations.......................23
10. Implementation Considerations.........................24 10. Implementation Considerations.........................24
Normative References......................................25 Normative References......................................25
Informative References....................................25 Informative References....................................25
Acknowledgements..........................................27 Acknowledgements..........................................27
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
skipping to change at page 11, line 9 skipping to change at page 11, line 9
/ Server Cookie (variable size, 8 to 32 bytes) / / Server Cookie (variable size, 8 to 32 bytes) /
/ / / /
+-+-+-+-... +-+-+-+-...
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 client IP
address and a secret quantity known only to the client. This client address, the server IP address, and a secret quantity known only to
secret SHOULD have at least 64 bits of entropy [RFC4086] and be the client. This client secret SHOULD have at least 64 bits of
changed periodically (see Section 7.1). The selection of the pseudo- entropy [RFC4086] and be changed periodically (see Section 7.1). The
random function is a matter private to the client as only the client selection of the pseudo-random function is a matter private to the
needs to recognize its own DNS cookies. client as only the client needs to recognize its own DNS cookies.
The client IP address is included so that the Client Cookie cannot be
used (1) to track a client if the client IP address changes due to
privacy mechanisms or (2) to impersonate the client by some network
device that was formerly on path but is no longer on path when the
client IP address changes due to mobility. However, if the client IP
address is being changed very often, it may be necessary to fix the
Client Cookie for a particular server for several requests to avoid
undue inefficiency due to retries caused by that server not
recognizing the Client Cookie.
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 (client) IP address, a
Client Cookie, and a secret quantity known only to the server. (See secret quantity known only to the server, and the request Client
Section 6 for a discussion of why the Client Cookie is used as input Cookie. (See Section 6 for a discussion of why the Client Cookie is
to the Server Cookie but the Server Cookie is not used as an input to used as input to the Server Cookie but the Server Cookie is not used
the Client Cookie.) This server secret SHOULD have at least 64 bits as an input to the Client Cookie.) This server secret SHOULD have at
of entropy [RFC4086] and be changed periodically (see Section 7.1). least 64 bits of entropy [RFC4086] and be changed periodically (see
The selection of the pseudo-random function is a matter private to Section 7.1). The selection of the pseudo-random function is a
the server as only the server needs to recognize its own DNS cookies. matter private to 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
different IP addresses or with different Client Cookies. different IP addresses or with different Client Cookies.
skipping to change at page 15, line 20 skipping to change at page 15, line 20
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
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 client is expecting the response to contain a
client caches the Server Cookie provided even if the response is an COOKIE OPT and it is missing the response MUST be discarded. If the
error response (RCODE non-zero). COOKIE OPT option Client Cookie is correct, the client caches the
Server Cookie provided even if the response is an error response
(RCODE non-zero).
If the reply extended RCODE is BADCOOKIE and the Client Cookie If the reply extended RCODE is BADCOOKIE and the Client Cookie
matches what was sent, it means that the server was unwilling to matches what was sent, it means that the server was unwilling to
process the request because it did not have the correct Server Cookie process the request because it did not have the correct Server Cookie
in it. The client SHOULD retry the request using the new Server in it. The client SHOULD retry the request using the new Server
Cookie from the response. Repeated BADCOOKIE responses to requests Cookie from the response. Repeated BADCOOKIE responses to requests
that use the Server Cookie provided in the previous response may be that use the Server Cookie provided in the previous response may be
an indication that the shared secrets / secret generation method in an indication that the shared secrets / secret generation method in
an anycast cluster of servers are inconsistent. If the reply to a an anycast cluster of servers are inconsistent. If the reply to a
retried request with a fresh Server Cookie is BADCOOKIE, the client retried request with a fresh Server Cookie is BADCOOKIE, the client
skipping to change at page 15, line 53 skipping to change at page 16, line 4
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 an 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
Server Cookie.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
option giving the Client Cookie provided in the query and a valid
Server Cookie.
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 an 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
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
skipping to change at page 19, line 48 skipping to change at page 19, line 48
increase server traffic and exactly predictable rollover times for increase server traffic and exactly predictable rollover times for
clients or servers might facilitate guessing attacks. For example, an clients or servers might facilitate guessing attacks. For example, an
attacker might increase the priority of attacking secrets they attacker might increase the priority of attacking secrets they
believe will be in effect for an extended period of time. To avoid believe will be in effect for an extended period of time. To avoid
rollover synchronization and predictability, it is RECOMMENDED that rollover synchronization and predictability, it is RECOMMENDED that
pseudorandom jitter in the range of plus zero to minus at least 40% 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 be applied to the time until a scheduled rollover of a DNS cookie
secret. secret.
It is RECOMMENDED that a client keep the Client Cookie it is It is RECOMMENDED that a client keep the Client Cookie it is
expecting in a reply associated with the outstanding request to avoid expecting in a reply until there is no longer an outstanding request
rejection of replies due to a bad Client Cookie right after a change associated with that Client Cookie that the client is tracking. This
in the client secret. It is RECOMMENDED that a server retain its avoids rejection of replies due to a bad Client Cookie right after a
previous secret after a rollover to a new secret for a configurable change in the client secret.
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 It is RECOMMENDED that a server retain its previous secret after a
based on its previous secret are treated as a correct Server Cookie rollover to a new secret for a configurable period of time not less
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
during that time. When a server responds to a request containing a than 1 second or more than 5 minutes with default configuration of 2
old Server Cookie that the server is treating as correct, the server 1/2 minutes. Requests with Server Cookies based on its previous
MUST include a new Server Cookie in its response. secret are treated as 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.
7.2 Counters 7.2 Counters
It is RECOMMENDED that implementations include counters of the It is RECOMMENDED that implementations include counters of the
occurrences of the various types of requests and responses described occurrences of the various types of requests and responses described
in Section 5. in Section 5.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
8. IANA Considerations 8. IANA Considerations
skipping to change at page 22, line 29 skipping to change at page 22, line 29
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 (WPA2) is appropriately deployed on the Wi-Fi network nodes, Security (WPA2) is appropriately deployed on the Wi-Fi network nodes,
only the Access Point via which the host is connecting is "on-path" only the Access Point via which the host is connecting is "on-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.
Work is underway in the IETF DPRIVE working group to provide
confidentiality for DNS requests and responses which would be
compatible with DNS cookies.
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
messages before the cryptographic computations of TSIG or SIG(0) are messages before the cryptographic computations of TSIG or SIG(0) are
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
skipping to change at page 22, line 51 skipping to change at page 23, line 5
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 When a server or client starts receiving an increased level of
requests with bad server cookies or replies with bad client cookies, requests with bad server cookies or replies with bad client cookies,
it would be reasonable for it to believe it is likely under attack 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 and it should consider a more frequent rollover of its secret. More
rapid rollover decreases the benefit to a cookie guessing attacker if rapid rollover decreases the benefit to a cookie guessing attacker if
they succeed in guessing a cookie. they succeed in guessing a cookie.
INTERNET-DRAFT DNS Cookies
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
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
skipping to change at page 27, 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, Dan Romascanu, Alissa Cooper, Bob Harold, Paul Hoffman, David Malone, Yoav Nir,
Gayle Noble, Dan Romascanu,
Tim Wicinski, Peter Yee 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
A simple example method to compute Client Cookies is the FNV-64 [FNV] A simple example method to compute Client Cookies is the FNV-64 [FNV]
of the server IP address and the client secret. That is of the client IP address, the server IP address, and the client
secret. That is
Client Cookie = FNV-64 ( Server IP Address | Client Secret ) Client Cookie =
FNV-64( Client IP Address | Server IP Address | Client Secret )
where "|" indicates concatenation. (If the order of the items where "|" indicates concatenation. Some computational resources may
concatenated above were reversed, it might be possible to reduce the be saved by precomputing FNV-64 through the Client IP Address. (If
computational effort by pre-computing FNV-64 through the bytes of the the order of the items concatenated above is changed to put the
Client Secret but this would reduce the strength of the Client Cookie Server IP Address last, it might be possible to further reduce the
and is NOT RECOMMENDED.) computational effort by pre-computing FNV-64 through the bytes of
both the Client IP Address and the Client Secret but this would
reduce the strength of the Client Cookie and is NOT RECOMMENDED.)
A.2 A More Complex Algorithm A.2 A More Complex Algorithm
A more complex algorithm to calculate Client Cookies is given below. A more complex algorithm to calculate Client Cookies is given below.
It uses more computational resources than the simpler algorithm shown It uses more computational resources than the simpler algorithm shown
in A.1. in A.1.
Client Cookie = HMAC-SHA256-64 ( Client Secret, Client Cookie = HMAC-SHA256-64(
Server IP Address ) Client IP Address | Server IP Address,
Client Secret )
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Appendix B: Example Server Cookie Algorithms Appendix B: Example Server Cookie Algorithms
B.1 A Simple Algorithm B.1 A Simple Algorithm
An example of a simple method producing a 64-bit Server Cookie is the An example of a simple method producing a 64-bit Server Cookie is the
FNV-64 [FNV] of the request IP address, the Client Cookie, and the FNV-64 [FNV] of the request IP address, the Client Cookie, and the
server secret. server secret.
Server Cookie = Server Cookie =
FNV-64 ( Request IP Address | Client Cookie | Server Secret ) FNV-64( Client IP Address | Client Cookie | Server Secret )
where "|" represents concatenation. (If the order of the items where "|" represents concatenation. (If the order of the items
concatenated above were reversed, it might be possible to reduce the concatenated was changed, 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
Sever Secret and Client Cookie but this would reduce the strength of Sever Secret and Client Cookie but this would reduce the strength of
the Server Cookie and is NOT RECOMMENDED.) the Server Cookie and is NOT RECOMMENDED.)
B.2 A More Complex Algorithm B.2 A More Complex Algorithm
Since the Server Cookie has a variable size, the server can store Since the Server Cookie has a variable size, the server can store
various information in that field as long as it is hard for an various information in that field as long as it is hard for an
adversary to guess the entire quantity used for authentication. There adversary to guess the entire quantity used for authentication. There
should be 64 bits of entropy in the Server Cookie; for example it should be 64 bits of entropy in the Server Cookie; for example it
skipping to change at page 30, line 11 skipping to change at page 30, line 11
cookies. cookies.
The Hash part of the Server Cookie is the hard-to-guess part. In BIND The Hash part of the Server Cookie is the hard-to-guess part. In BIND
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
9.10.3 (and later), 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
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Huawei Technologies Huawei Technologies
155 Beaver Street 155 Beaver Street
 End of changes. 21 change blocks. 
49 lines changed or deleted 75 lines changed or added

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