draft-ietf-dnsop-cookies-04.txt   draft-ietf-dnsop-cookies-05.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: December 31, 2015 July 1, 2015 Expires: January 31, 2016 August 1, 2015
Domain Name System (DNS) Cookies Domain Name System (DNS) Cookies
<draft-ietf-dnsop-cookies-04.txt> <draft-ietf-dnsop-cookies-05.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. deployed.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
"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
below. These attacks include denial-of-service, cache poisoning and below. These attacks include denial-of-service, cache poisoning and
answer forgery. answer forgery.
2.1 Denial-of-Service Attacks 2.1 Denial-of-Service Attacks
The typical form of the denial-of-service attacks considered herein The typical form of the denial-of-service attacks considered herein
is to send DNS requests with forged source IP addresses to a server. is to send DNS requests with forged source IP addresses to a server.
The intent can be to attack that server or some other selected host The intent can be to attack that server or some other selected host
as described below. as described below.
2.1.1 DNS Amplification Attacks 2.1.1 DNS Amplification Attacks
skipping to change at page 7, line 31 skipping to change at page 7, line 31
2.2 Cache Poisoning and Answer Forgery Attacks 2.2 Cache Poisoning and Answer Forgery Attacks
The form of the cache poisoning attacks considered is to send forged The form of the cache poisoning attacks considered is to send forged
replies to a resolver. Modern network speeds for well-connected hosts replies to a resolver. Modern network speeds for well-connected hosts
are such that, by forging replies from the IP addresses of a DNS are such that, by forging replies from the IP addresses of a DNS
server to a resolver for names that resolver has been induced to server to a resolver for names that resolver has been induced to
resolve or for common names whose resource records have short time- resolve or for common names whose resource records have short time-
to-live values, there can be an unacceptably high probability of to-live values, there can be an unacceptably high probability of
randomly coming up with a reply that will be accepted and cause false randomly coming up with a reply that will be accepted and cause false
DNS information to be cached by that resolver (the Dan Kaminsky DNS information to be cached by that resolver (the Dan Kaminsky
attack). This can be used to facilitate phishing attacks and other attack [Kaminsky]). This can be used to facilitate phishing attacks
diversion of legitimate traffic to a compromised or malicious host and other diversion of legitimate traffic to a compromised or
such as a web server. malicious host such as a web server.
With the use of DNS cookies, a resolver can generally reject such With the use of DNS cookies, a resolver can generally reject such
forged replies. forged replies.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
3. Comments on Existing DNS Security 3. Comments on Existing DNS Security
Two forms of security have been added to DNS, data security and Two forms of security have been added to DNS, data security and
message/transaction security. message/transaction security.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
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 5.5). 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.
A client MUST NOT use the same Client Cookie value for requests to In order to maintain the security properties of this protocol, a
all servers. client MUST NOT use the same Client Cookie value for requests to all
servers.
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 5.5).
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.
A server MUST NOT use the same Server Cookie value for responses to In order to maintain the security properties of this protocol, a
all clients. server MUST NOT use the same Server Cookie value for responses to all
clients.
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 coookie or secret is covered in and transient retention of the old cookie or secret is covered in
Section 5.5. Section 5.5.
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 44 skipping to change at page 12, line 44
The Server Cookie, when it occurs in a COOKIE OPT option in a The Server Cookie, when it occurs in a COOKIE OPT option in a
request, is intended to weakly assure the server that the request request, is intended to weakly assure the server that the request
came from a client that is both at the source IP address of the came from a client that is both at the source IP address of the
request and using the Client Cookie included in the option. This weak request and using the Client Cookie included in the option. This weak
assurance is provided by the Server Cookie that server would send to assurance is provided by the Server Cookie that server would send to
that client in an earlier response appearing as the Server Cookie that client in an earlier response appearing as the Server Cookie
field in the request. field in 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
before. if no COOKIE OPT option had been included in the request.
When DNS Cookies are implemented and enabled, there are four When DNS Cookies are implemented and enabled, there are four
possibilities: (1) there is no OPT RR at all in the request; (2) possibilities: (1) there is no OPT RR at all in the request; (2)
there is no valid Client Cookie in the request because the COOKIE OPT there is no valid Client Cookie in the request because the COOKIE OPT
option is absent from the request, or one is present but is not a option is absent from the request, or one is present but is not a
legal length; (3) there is a valid length cookie option in the legal length; (3) there is a valid length cookie option in the
request with no Server Cookie or an incorrect Server Cookie; or (4) request with no Server Cookie or an incorrect Server Cookie; or (4)
there is a cookie option in the request with a correct Server Cookie. there is a cookie option in the request with a correct Server Cookie.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
skipping to change at page 17, line 10 skipping to change at page 17, line 10
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. and it should consider a more frequent rollover of its secret.
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 sever secret or the server IP function of the client IP address and a server secret or the server
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 indefinitely 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 weak signature the client checks in replies and you could extend this weak signature
to cover the request ID, for example, or any other information that to cover the request ID, for example, or any other information that
is returned unchanged in the reply. is 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,
skipping to change at page 20, line 15 skipping to change at page 20, line 15
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]
IANA is requested to assign a new DNS error code in the range above IANA has assigned the following DNS error code as an early
16 and below 3,840 as follows: allocation:
RCODE Name Description Reference RCODE Name Description Reference
-------- --------- ------------------------- --------------- -------- --------- ------------------------- ---------------
TBD[23] BADCOOKIE Bad/missing server cookie [this document] 23 BADCOOKIE Bad/missing server cookie [this document]
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
9. Security Considerations 9. Security Considerations
DNS Cookies provide a weak form of authentication of DNS requests and DNS Cookies provide a weak form of authentication of DNS requests and
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
skipping to change at page 24, line 32 skipping to change at page 24, line 32
[RFC6891] - Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] - Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891,
April 2013, <http://www.rfc-editor.org/info/rfc6891>. April 2013, <http://www.rfc-editor.org/info/rfc6891>.
Informative References Informative References
[FNV] - G. Fowler, L. C. Noll, K.-P. Vo, D. Eastlake, "The FNV Non- [FNV] - G. Fowler, L. C. Noll, K.-P. Vo, D. Eastlake, "The FNV Non-
Cryptographic Hash Algorithm", draft-eastlake-fnv, work in Cryptographic Hash Algorithm", draft-eastlake-fnv, work in
progress. progress.
[Kaminsky] - Olney, M., P. Mullen, K. Miklavicic, "Dan Kaminsky's
2008 DNS Vulnerability", 25 July 2008,
<https://www.ietf.org/mail-
archive/web/dnsop/current/pdf2jgx6rzxN4.pdf>.
[RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<http://www.rfc-editor.org/info/rfc2845>. <http://www.rfc-editor.org/info/rfc2845>.
[RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY [RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000,
<http://www.rfc-editor.org/info/rfc2930>. <http://www.rfc-editor.org/info/rfc2930>.
[RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000, ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000,
<http://www.rfc-editor.org/info/rfc2931>. <http://www.rfc-editor.org/info/rfc2931>.
[RFC3022] - Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] - Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, DOI Address Translator (Traditional NAT)", RFC 3022, DOI
10.17487/RFC3022, January 2001, <http://www.rfc- 10.17487/RFC3022, January 2001, <http://www.rfc-
editor.org/info/rfc3022>. editor.org/info/rfc3022>.
INTERNET-DRAFT DNS Cookies
[RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, Rose, "DNS Security Introduction and Requirements", RFC 4033,
DOI 10.17487/RFC4033, March 2005, <http://www.rfc- DOI 10.17487/RFC4033, March 2005, <http://www.rfc-
editor.org/info/rfc4033>. editor.org/info/rfc4033>.
INTERNET-DRAFT DNS Cookies
[RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC Rose, "Resource Records for the DNS Security Extensions", RFC
4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc- 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-
editor.org/info/rfc4034>. editor.org/info/rfc4034>.
[RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", Rose, "Protocol Modifications for the DNS Security Extensions",
RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc- RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-
editor.org/info/rfc4035>. editor.org/info/rfc4035>.
skipping to change at page 26, line 9 skipping to change at page 26, line 9
[RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
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 contributions of the following are gratefully acknowledged: The suggestions and contributions of the following are gratefully
acknowledged:
Gayle Noble, Tim Wicinski Bob Harold, Paul Hoffman, Gayle Noble, Tim Wicinski
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
 End of changes. 16 change blocks. 
21 lines changed or deleted 29 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/