draft-ietf-dnsop-cookies-01.txt   draft-ietf-dnsop-cookies-02.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: August 21, 2015 February 22, 2015 Expires: December 15, 2015 June 16, 2015
Domain Name System (DNS) Cookies Domain Name System (DNS) Cookies
<draft-ietf-dnsop-cookies-01.txt> <draft-ietf-dnsop-cookies-02.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 2, line 24 skipping to change at page 2, line 24
2.1 Denial-of-Service Attacks..............................6 2.1 Denial-of-Service Attacks..............................6
2.1.1 DNS Amplification Attacks............................6 2.1.1 DNS Amplification Attacks............................6
2.1.2 DNS Server Denial-of-Service.........................6 2.1.2 DNS Server Denial-of-Service.........................6
2.2 Cache Poisoning and Answer Forgery Attacks.............7 2.2 Cache Poisoning and Answer Forgery Attacks.............7
3. Comments on Existing DNS Security.......................8 3. Comments on Existing DNS Security.......................8
3.1 Existing DNS Data Security.............................8 3.1 Existing DNS Data Security.............................8
3.2 DNS Message/Transaction Security.......................8 3.2 DNS Message/Transaction Security.......................8
3.3 Conclusions on Existing DNS Security...................8 3.3 Conclusions on Existing DNS Security...................8
4. The COOKIE OPT Option...................................9 4. DNS Cookie Option.......................................9
4.1 Client Cookie.........................................10 4.1 Client Cookie.........................................10
4.2 Server Cookie.........................................10 4.2 Server Cookie.........................................10
4.3 Error Code............................................11
5. DNS Cookies Protocol Description.......................12
5.1 Originating Requests..................................12
5.2 Responding to Requests................................12
5.2.1 No OPT RR...........................................13
5.2.2 No Valid Client Cookie..............................13
5.2.3 Bad or Absent Server Cookie.........................14
5.2.4 A Correct Server Cookie.............................14
5.3 Processing Responses..................................15
5.4 Client and Server Secret Rollover.....................15
5.5 Implementation Requirement............................16
6. Simple DNS Cookie Option...............................17
6.1 Simple Client Cookie..................................18
6.2 Simple Server Cookie..................................18
7. Simple DNS Cookies Protocol Description................20 5. DNS Cookies Protocol Description.......................11
7.1 Originating Requests (Simple).........................20 5.1 Originating Requests..................................11
7.2 Responding to Request (Simple)........................20 5.2 Responding to Request.................................11
7.2.1 No Opt RR or No COOKIE OPT option...................20 5.2.1 No Opt RR or No COOKIE OPT option...................12
7.2.2 Malformed COOKIE OPT option.........................21 5.2.2 Malformed COOKIE OPT option.........................12
7.2.3 Only a CLIENT Cookie................................21 5.2.3 Only a Client Cookie................................12
7.2.4 A Client Cookie and Server Cookie...................21 5.2.4 A Client Cookie and Server Cookie...................13
7.2.4.1 A Client Cookie and Invalid Server Cookie.........21 5.2.4.1 A Client Cookie and Invalid Server Cookie.........13
7.2.4.2 A Client Cookie and Valid Server Cookie...........21 5.2.4.2 A Client Cookie and Valid Server Cookie...........13
5.3 Processing Responses..................................13
5.4 Client and Server Secret Rollover.....................14
5.5 Implementation Requirement............................15
8. NAT Considerations and AnyCast Server Considerations...23 6. NAT Considerations and AnyCast Server Considerations...16
9. Deployment.............................................25 7. Deployment.............................................18
8. IANA Considerations....................................19
INTERNET-DRAFT DNS Cookies 9. Security Considerations................................20
9.1 Cookie Algorithm Considerations.......................20
Table of Contents (continued) 10. Implementation Considerations.........................21
10. IANA Considerations...................................26 Normative References......................................22
Informative References....................................22
11. Security Considerations...............................27 Acknowledgements..........................................24
11.1 Cookie Algorithm Considerations......................27
Normative References......................................28 Appendix A: Example Client Cookie Algorithms..............25
Informative References....................................28 A.1 A Simple Algorithm....................................25
A.2 A More Complex Algorithm..............................25
Acknowledgements..........................................30 INTERNET-DRAFT DNS Cookies
Appendix A: Example Client Cookie Algorithms..............31 Table of Contents (continued)
A.1 A Simple Algorithm....................................31
A.2 A More Complex Algorithm..............................31
Appendix B: Example Server Cookie Algorithms..............32 Appendix B: Example Server Cookie Algorithms..............26
B.1 A Simple Algorithm....................................32 B.1 A Simple Algorithm....................................26
B.2 A More Complex Algorithm..............................32 B.2 A More Complex Algorithm..............................26
Author's Address..........................................34 Author's Address..........................................28
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.
This document describes DNS cookies, a lightweight DNS transaction This document describes DNS cookies, a lightweight DNS transaction
security mechanism specified as an OPT [RFC6891] option. Two security mechanism specified as an OPT [RFC6891] option. The DNS
different cookie formats are presented for evaluation. cookies mechanism provides limited protection to DNS servers and
clients against a variety of increasingly common abuses by off-path
The DNS cookies mechanism provides limited protection to DNS servers attackers. It is compatible with and can be used in conjunction with
and clients against a variety of increasingly common abuses by off- other DNS transaction forgery resistance measures such as those in
path attackers. It is compatible with and can be used in conjunction [RFC5452].
with other DNS transaction forgery resistance measures such as those
in [RFC5452].
The protection provided by DNS cookies bears some resemblance to that The protection provided by DNS cookies bears some resemblance to that
provided by using TCP for DNS transactions. To bypass the weak provided by using TCP for DNS transactions. To bypass the weak
protection provided by using TCP requires an off-path attacker protection provided by using TCP requires an off-path attacker
guessing the 32-bit TCP sequence number in use. To bypass the weak guessing the 32-bit TCP sequence number in use. To bypass the weak
protection provided by DNS Cookies requires such an attacker to guess protection provided by DNS Cookies requires such an attacker to guess
a 64-bit pseudo-random quantity. Where DNS Cookies are not available a 64-bit pseudo-random quantity. Where DNS Cookies are not available
but TCP is, a fall back to using TCP is a reasonable strategy. but TCP is, a fall back to using TCP is a reasonable strategy.
If only one party to a DNS transaction supports DNS cookies, the If only one party to a DNS transaction supports DNS cookies, the
skipping to change at page 4, line 50 skipping to change at page 4, line 48
DNS cookies mechanism in anycast servers. DNS cookies mechanism in anycast servers.
1.1 Contents of This Document 1.1 Contents of This Document
In Section 2, we discuss the threats against which the DNS cookie In Section 2, we discuss the threats against which the DNS cookie
mechanism provides some protection. mechanism provides some protection.
Section 3 describes existing DNS security mechanisms and why they are Section 3 describes existing DNS security mechanisms and why they are
not adequate substitutes for DNS cookies. not adequate substitutes for DNS cookies.
Section 4 describes the COOKIE OPT option including an error code Section 4 describes the COOKIE OPT option.
field.
Section 5 provides a protocol description including an error code
field.
INTERNET-DRAFT DNS Cookies
Section 6 describes an alternative COOKIE OPT option not including an
error field.
Section 7 provides a description of a simplified protocol without an Section 5 provides a protocol description.
error code.
Section 8 discusses some NAT and anycast related DNS Cookies design Section 6 discusses some NAT and anycast related DNS Cookies design
considerations. considerations.
Section 9 discusses incremental deployment considerations. INTERNET-DRAFT DNS Cookies
Sections 10 and 11 describe IANA and Security Considerations. Section 7 discusses incremental deployment considerations.
Sections 8 and 9 describe IANA and Security Considerations.
1.2 Definitions 1.2 Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An "off-path attacker", for a particular DNS client and server, is An "off-path attacker", for a particular DNS client and server, is
defined as an attacker who cannot observe the DNS request and defined as an attacker who cannot observe the DNS request and
response messages between that client and server. response messages between that client and server.
skipping to change at page 9, line 7 skipping to change at page 9, line 7
3.3 Conclusions on Existing DNS Security 3.3 Conclusions on Existing DNS Security
The existing DNS security mechanisms do not provide the services The existing DNS security mechanisms do not provide the services
provided by the DNS Cookies mechanism: lightweight message provided by the DNS Cookies mechanism: lightweight message
authentication of DNS requests and responses with no requirement for authentication of DNS requests and responses with no requirement for
pre-configuration or per client server side state. pre-configuration or per client server side state.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
4. The COOKIE OPT Option 4. DNS Cookie Option
COOKIE is an OPT RR [RFC6891] option that can be included in the
RDATA portion of an OPT RR in DNS requests and responses. The option
length varies depending on the circumstance in which it is being
used. There are two cases as described below. Both use the same
OPTION-CODE; they are distinguished by their length.
The COOKIE OPT describced in this Section is used in the protocol The DNS Cookie Option is an OPT RR [RFC6891] option that can be
described in Section 5. An alternative COOKIE OPT is described in included in the RDATA portion of an OPT RR in DNS requests and
Section 6 that is used in an alternative protocol described in responses. The option length varies depending on the circumstances
Section 7. in which it is being used. There are two cases as described below.
Both use the same OPTION-CODE; they are distinguished by their
length.
In a request sent by a client to a server when the client does not In a request sent by a client to a server when the client does not
know the server cookie, its length is 10, consisting of a 2 bytes DNS know the server cookie, its length is 8, consisting an 8 byte Client
error code field followed by the 8 byte Client Cookie as shown in Cookie as shown in Figure 1.
Figure 1.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = {TBD} | OPTION-LENGTH = 10 | | OPTION-CODE = TBD1 | OPTION-LENGTH = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+- Client Cookie (fixed size, 8 bytes) -+-+-+-+ +-+- Client Cookie (fixed size, 8 bytes) -+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. COOKIE Option, Unknown Server Cookie Figure 1. COOKIE Option, Unknown Server Cookie
In a request sent by a client when a server cookie is known and in In a request sent by a client when a server cookie is known and in
all responses, the length is variable from 18 to 42 bytes, consisting all responses, the length is variable from 16 to 40 bytes, consisting
of a 2 byte DNS error field followed by the 8 bytes Client Cookie and of an 8 bytes Client Cookie followed by the variable 8 to 32 bytes
then the variable 8 to 32 bytes Server Cookie as shown in Figure 2. Server Cookie as shown in Figure 2. The variability of the option
The variability of the option length stems from the variable length length stems from the variable length Server Cookie. The Server
Server Cookie. The Server Cookie is an integer number of bytes with a Cookie is an integer number of bytes with a minimum size of 8 bytes
minimum size of 64 bits for security and a maximum size of 256 bits for security and a maximum size of 32 bytes for implementation
for implementation convenience. convenience.
INTERNET-DRAFT DNS Cookies
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = {TBD} | OPTION-LENGTH >= 18, <= 42 | | OPTION-CODE = TBD1 | OPTION-LENGTH >= 16, <= 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+- Client Cookie (fixed size, 8 bytes) -+-+-+-+ +-+- Client Cookie (fixed size, 8 bytes) -+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ 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
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.4). The selection of the pseudo- changed periodically (see Section 5.4). 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 queries to all A client MUST NOT use the same Client Cookie value for queries to all
servers. 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 8 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.4). of entropy [RFC4086] and be changed periodically (see Section 5.4).
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.
INTERNET-DRAFT 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 A server MUST NOT use the same Server Cookie value for responses to
all clients. all clients.
4.3 Error Code
In requests, the Error Code field MUST be zero and is ignored on
receipt. Replies have a COOKIE OPT with an Error Code equal to one of
the following four values: Zero (if the request they respond to had a
COOKIE OPT with a correct Server Cookie), NOCOOKIE, MFCOOKIE, or
BADCOOKIE.
NOCOOKIE and MFCOOKIE indicate that the server did not receive a
Client Cookie, either because there was no COOKIE OPT option in the
request (NOCOOKIE) or one was present but the COOKIE OPT option was
malformed as not being a valid length (MFCOOKIE). BADCOOKIE indicates
that the server did receive a Client Cookie but did not receive the
correct Server Cookie either because there was no Server Cookie
present or because it was not a valid value.
A server may choose to normally process a request, for example
returning the normal answer information for a QUERY, notwithstanding
a cookie error condition. For more information on error processing,
see Section 5.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
5. DNS Cookies Protocol Description 5. DNS Cookies Protocol Description
This section discusses using DNS Cookies in the DNS Protocol. An This section discusses using DNS Cookies in the DNS Protocol.
alternative protocol description appears in Section 7.
5.1 Originating Requests 5.1 Originating Requests
A DNS client that implements DNS cookies includes one DNS Cookie A DNS client that implements DNS includes one DNS COOKIE OPT option
option in every DNS request it sends unless DNS cookies are disabled. containing a Client Cookie in every DNS request it sends unless DNS
The COOKIE OPT option in a request always includes a zero Error Code cookies are disabled.
field and a Client Cookie as discussed in Section 4.1.
If the client has no Server Cookie obtained from a previous DNS If the client has a cached server cookie for the server against its
response and cached under the server's IP address, it uses the IP address it uses the longer cookie form and includes that server
shorter form of COOKIE OPT shown in Figure 1. If the client does have cookie in the option along with the client cookie (Figure 2)
such a cached Server Cookie, it uses the form of COOKIE OPT shown in otherwise it just sends the shorter form option with a client cookie
Figure 2 and also includes that cached Server Cookie in the DNS (Figure 1).
option it sends.
5.2 Responding to Requests 5.2 Responding to Request
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, the 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. before.
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 in absent from the request or one is present but not a legal option in absent from the request or one is present but not a legal
length; (3) there is a valid length cookie option in the request with length; (3) there is a valid length cookie option in the request with
no Server Cookie or an incorrect Server Cookie; or (4) there is a no Server Cookie or an incorrect Server Cookie; or (4) there is a
cookie option in the request with a correct Server Cookie. The four cookie option in the request with a correct Server Cookie. The four
possibilities are discussed in the subsections below. possibilities are discussed in the subsections below.
In the case of multiple COOKIE OPT options in a request, only the In all cases of multiple COOKIE OPT options in a request, only the
first (the one closest to the DNS header) is considered. All others first (the one closest to the DNS header) is considered. All others
are ignored. are ignored.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
5.2.1 No OPT RR 5.2.1 No Opt RR or No COOKIE OPT option
If there is no OPT RR in the request, the client does not support
EDNS since [RFC6891] requires that an OPT RR be included in a request
if the requester supports that feature. Under these circumstances,
the server cannot expect to ever receive a correct COOKIE OPT option
from the client as in Section 5.2.4.
The situation and server options available are the same as those in If there is no OPT record or on COOKIE OPT option present in the
Section 5.2.2 except that no OPT RR can be included in any response. request then the server responds to the request as if the server
doesn't understand the COOKIE OPT.
5.2.2 No Valid Client Cookie 5.2.2 Malformed COOKIE OPT option
A request with an OPT RR but no COOKIE OPT option or with a COOKIE If the COOKIE OPT is too short to contain a Client Cookie then
that is not a valid length (10 or 18 through 42) could be from a FORMERR is generated. If the COOKIE OPT is longer than that required
client that does not implement DNS cookies or on which they are to hold a COOKIE OPT with just a Client Cookie (8) but is shorter
disabled or it could be some form of abuse or broken client that the minimum COOKIE OPT with both a Client and Server Cookie (16)
implementation. A server on which DNS cookies are enabled has the then FORMERR is generated. If the COOKIE OPT is longer than the
following three choices in responding to such a request: maximum valid COOKIE OPT (40) then a FORMERR is generated.
(1) Silently discard the request. In summary, valid cookie lengths are 8 and 16 to 40 inclusive.
(2) Not process the request other than returning a minimal length 5.2.3 Only a Client Cookie
error response. Because of the absence of a validly formatted
COOKIE OPT option in the request, it cannot be assumed that the
client would understand any new RCODE values. An RCODE of Refused
is returned and the Error Field of the returned COOKIE OPT option
is set to NOCOOKIE if there was no COOKIE OPT option in the
request and set to MFCOOKIE if such an option was present but not
a valid length.
(3) Process the request normally and provide a normal response except Based on server policy, including rate limiting, the server chooses
that a COOKIE OPT option with a non-zero Error Field is included one of the following:
as in point 2 above. The RCODE in the DNS Header is zero unless
some non-cookie error occurs in processing the request.
Server policy determines how often the server selects each of the (1) Silently discard the request.
above response choices; however, if the request was received over
TCP, the server may wish to take the weak authentication provided by
the use of TCP into account, increasing the probability of choice 3
and decreasing the probability of choice 1 perhaps to the extent of
never choosing 1. For both response choices 2 and 3, the server
should consider setting TC=1 in the response so that future requests
from the client are more likely to be received with the weak
authentication that can be provided by TCP.
INTERNET-DRAFT DNS Cookies (2) Send a BADCOOKIE error response.
5.2.3 Bad or Absent Server Cookie (3) Process the request and provide a normal response. The RCODE is
zero unless some non-cookie error occurs in processing the
request.
If a request is received with the COOKIE OPT option having no Server If the server responds, choosing 2 or 3 above, it SHALL generate its
Cookie value (length 10) or a bad Server Cookie value (length 18 to own COOKIE OPT containing both the client cookie copied from the
42), it could be some attempted abuse or it could just be that the request and a server cookie it has generated and adds this COOKIE OPT
client does not know a currently valid Server Cookie for the server to the response's OPT record. Servers MUST, at least occasionally,
to which the request was sent. For example, the client might have an respond to such requests to inform the client of the correct server
old, no longer recognized Server Cookie cookie. This is necessary so that such a client can bootstrap to the
weakly secure state where requests and responses have recognized
server cookies and client cookies. If the request was received over
TCP, the server SHOULD take the weak authentication provided by the
use of TCP into account, increasing the probability of choice 3
Servers MUST, at least occasionally, respond to such requests to INTERNET-DRAFT DNS Cookies
inform the client of the correct Server Cookie. This is necessary so
that such a client can bootstrap to the weakly secure state where
requests and responses have recognized Server Cookies and Client
Cookies.
In responding to such a request, the server has the following three 5.2.4 A Client Cookie and Server Cookie
choices:
(1) Silently discard the request. The server examines the server cookie to determine if it is a valid
server cookie it has generated. This examination will result in a
determination of whether the server cookie is valid or not. These
cases are discussed below.
(2) Not process the request other than returning a minimal length 5.2.4.1 A Client Cookie and Invalid Server Cookie
error response. Because of the correct length COOKIE OPT option
in the request, the client can be assume to understand the new
error codes assigned in this document. Both the Error Field in
the returned COOKIE OPT option and the extended RCODE are set to
BADCOOKIE.
(3) Processes the request normally and sends its usual response This can occur due to a stale server Cookie being returned, a
including a COOKIE OPT option with an Error field of BADCOOKIE client's IP address or client cookie changing without the DNS server
and a zero RCODE (unless there was also a non-cookie error in being aware, or an attempt to spoof the client.
processing the request).
Server policy determines how often the server selects each of the The server SHALL process the query as if the invalid server cookie
above response choices; however, if the request was received over was not present as described in Section 5.2.3.
TCP, the server may wish to take the weak authentication provided by
the use of TCP into account, increasing the probability of choice 3
and decreasing the probability of choice 1 perhaps to the extent of
never choosing 1.
5.2.4 A Correct Server Cookie 5.2.4.2 A Client Cookie and Valid Server Cookie
If a server with enabled DNS cookies receives a request where the When this occurs the server can assume that it is talking to a client
COOKIE OPT option has a valid length and correct Server Cookie, it that it has talked to before and defensive measures for spoofed UDP
processes the request normally and includes a COOKIE OPT option with queries, if any, are no longer required.
a zero Error Field in the response. Such a response might have a
non-zero RCODE if a non-cookie error occurs in processing the
request.
INTERNET-DRAFT DNS Cookies The server SHALL process the query and include a COOKIE OPT in the
response by (a) copying the complete COOKIE OPT from the request or
(b) generating a new COOKIE OPT containing both the client cookie
copied from the request and a valid server cookie it has generated.
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 use in the response packet from a server at the source IP address use 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. If there are multiple COOKIE OPT options to that server in a request. In a DNS reply with multiple COOKIE OPT
in a DNS reply, all but the first (the one closest to the DNS Header) options, all but the first (the one closest to the DNS Header) are
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
response for DNS cookies and MUST discard the response if it contains response for DNS cookies and MUST discard the response if it contains
an illegal COOKIE OPT option length or an incorrect Client Cookie an illegal COOKIE OPT option length or an incorrect client cookie
value. If the COOKIE OPT option Client Cookie is correct, the client value. If the COOKIE OPT option client cookie is correct, the client
caches the Server Cookie provided even if the response is an error caches the server cookie provided even if the response is an error
response (RCODE non-zero). response (RCODE non-zero).
INTERNET-DRAFT DNS Cookies
If the reply extended RCDOE is BADCOOKIE, it means that the server If the reply extended RCDOE is BADCOOKIE, it means that the server
was unwilling to process the request because it did not have the was unwilling to process the request because it did not have the
correct Server Cookie in it. The client should retry the request correct server cookie in it. The client should retry the request
using the new Server Cookie from the response. using the new server cookie from the response.
If the reply extended RCODE is BADCOOKIE and the client cookie
matches what was sent, it means that the server was unwilling to
process the request because it did not have the correct server cookie
in it. The client SHOULD retry the request using the new server
cookie from the response. Multiple BADCOOKIE responses may be an
indication that the shared secrets / secret generation method in an
anycast cluster of servers are not consistent. If the reply to a
retried query with a fresh server cookie is BADCOOKIE, the client
SHOULD retry using TCP as the transport since the server will be more
likely to process the query normally based on the weak security
provided by TCP.
If the RCODE is some value other than BADCOOKIE, including zero, the If the RCODE is some value other than BADCOOKIE, including zero, the
response is then processed normally. further processing of the response proceedes normally.
5.4 Client and Server Secret Rollover 5.4 Client and Server Secret Rollover
Clients and servers MUST NOT continue to use the same secret in new Clients and servers MUST NOT continue to use the same secret in new
queries and responses, respectively, for more than 14 days and SHOULD queries and responses, respectively, for more than 35 days and SHOULD
NOT continue to do so for more than 1 day. Many clients rolling over NOT continue to do so for more than 25 hours. Many clients rolling
their secret at the same time could briefly increase server traffic over their secret at the same time could briefly increase server
and exactly predictable rollover times for clients or servers might traffic and exactly predictable rollover times for clients or servers
facilitate guessing attacks. For example, an attacker might increase might facilitate guessing attacks. For example, an attacker might
the priority of attacking secrets they believe will be in effect for increase the priority of attacking secrets they believe will be in
an extended period of time. To avoid rollover synchronization and effect for an extended period of time. To avoid rollover
predictability, it is RECOMMENDED that pseudorandom jitter of at synchronization and predictability, it is RECOMMENDED that
least 30% be applied to the time of a scheduled rollover of a DNS pseudorandom jitter in the range of plus zero to minus at least 40%
cookie secret. 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 It is RECOMMENDED that a client keep the client cookie it is
expecting in a reply associated with the outstanding query to avoid expecting in a reply associated with the outstanding query to avoid
rejection of replies due to a bad Client Cookie right after a change 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 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 previous secret for a period of time not less than 1 second or more
than 3 minutes, after a change in its secret, and consider queries than 3 minutes, after a change in its secret, and consider queries
with Server Cookies based on its previous secret to have a correct with server cookies based on its previous secret to have a correct
Server Cookie during that time. server cookie during that time.
INTERNET-DRAFT DNS Cookies Receiving a sudden increased level of requests with bad server
cookies or replies with bad client cookies would be reason to believe
a server or client is likely to be under attack and should consider
more frequent rollover of its secret.
Receiving a sudden increased level of requests with bad Server INTERNET-DRAFT DNS Cookies
Cookies or replies with bad Client Cookies would be a good reason to
believe a server or client is likely to be under attack and should
consider more frequent rollover of its secret.
5.5 Implementation Requirement 5.5 Implementation Requirement
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.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
6. Simple DNS Cookie Option 6. NAT Considerations and AnyCast Server Considerations
The Simple DNS Cookie Option is a alternative DNS COOKIE option
format that is implemented in BIND 9.10 using a experimental option
code. It differs from the the COOKIE OPT Option (Section 4) in that
it does not contain a error code and as a consequence there is
mimimal error handling required. Only one of COOKIE OPT or Simple
DNS Cookie Option will be in the final document. Both are present in
this document for comparision.
The Simple DNS Cookie Option is a OPT RR [RFC6891] option that can be
included in the RDATA portion of an OPT RR in DNS requests and
responses. The option length varies depending on the circumstances
in which it is being used. There are two case as described below.
Both use the same OPTION-CODE; they are distinguished by there
length.
In a request sent by a client to a server when the client does not
know the server cookie, its length is 8, consisting a 8 byte Client
Cookie as shown in Figure 3.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = {TBD} | OPTION-LENGTH = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+- Client Cookie (fixed size, 8 bytes) -+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Simple COOKIE Option, Unknown Server Cookie
In a request sent by a client when a server cookie is known and in
all responses, the length is variable from 16 to 40 bytes, consisting
of a 8 bytes Client Cookie followed by the variable 8 to 32 bytes
Server Cookie as shown in Figure 4. The variability of the option
length stems from the variable length Server Cookie. The Server
Cookie is an integer number of bytes with a minimum size of 64 bits
for security and a maximum size of 256 bits for implementation
convenience.
INTERNET-DRAFT DNS Cookies
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = {TBD} | OPTION-LENGTH >= 16, <= 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+- Client Cookie (fixed size, 8 bytes) -+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Server Cookie (variable size, 8 to 32 bytes) /
/ /
+-+-+-+-...
Figure 4. Simple COOKIE Option, Known Server Cookie
6.1 Simple Client Cookie
[This section is identical to section 4.1]
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
secret SHOULD have at least 64 bits of entropy [RFC4086] and be
changed periodically (see Section 5.4). The selection of the pseudo-
random function is a matter private to the client as only the client
needs to recognize its own DNS cookies.
For further discussion of the Client Cookie field, see Section 5.1.
For example methods of determining a Client Cookie, see Appendix A.
A client MUST NOT use the same Client Cookie value for queries to all
servers.
6.2 Simple Server Cookie
[This section is identical to section 4.2]
The Simple Server Cookie SHOULD consist of or include a 64-bit or
larger pseudo-random function of the request source IP address, the
request Simple Client Cookie, and a secret quantity known only to the
server. (See Section 8 for a discussion of why the Simple Client
Cookie is used as input to the Simple Server Cookie but the Simple
Server Cookie is not used as an input to the Simple Client Cookie.)
This server secret SHOULD have at least 64 bits of entropy [RFC4086]
and be changed periodically (see Section 5.4). The selection of the
pseudo-random function is a matter private to the server as only the
INTERNET-DRAFT DNS Cookies
server needs to recognize its own DNS cookies.
For further discussion of the Simple Server Cookie field see Section
5.2. For example methods of determining a Server Cookie, see
Appendix B.
A server MUST NOT use the same Server Cookie value for responses to
all clients.
INTERNET-DRAFT DNS Cookies
7. Simple DNS Cookies Protocol Description
This section discusses using Simple DNS Cookies in the DNS Protocol.
7.1 Originating Requests (Simple)
A DNS client that implements DNS includes one DNS Cookie option in
every DNS requests it sends unless DNS cookies are disabled.
If the client has a cached server cookie for the server against its
IP address it includes that in the option along with the client
cookie (Figure 4) otherwise it just sends a option with a client
cookie (Figure 3).
7.2 Responding to Request (Simple)
The Server Cookie, when included in a COOKIE option in a request, is
intended to weakly assure that server that the request has come from
a client that it has responsed to in the past and is both at the same
source address and is using the same Client Cookie in the option.
At a server where Simple DNS Cookies are not implemented and enabled,
presence of a COOKIE OPT option is ignored and the server responds as
before.
When DNS Cookies are implemented and enabled, there are four
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
option in absent from the request or one is present but not a legal
length; (3) there is a valid length cookie option in the 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. The four
possibilities are discussed in the subsections below.
In the case of multiple COOKIE OPT options in a request, only the
first (the one closest to the DNS header) is considered. All others
are ignored.
7.2.1 No Opt RR or No COOKIE OPT option
If there is no OPT record or on COOKIE OPT option present in the
request then the server responds to the request as if it doesn't
understand the COOKIE OPT.
INTERNET-DRAFT DNS Cookies
7.2.2 Malformed COOKIE OPT option
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
to hold a COOKIE OPT with just a Client Cookie (8) but is shorter
that the mimimum COOKIE OPT with both both a Client and Server Cookie
(16) then FORMERR is generated. If the COOKIE OPT is longer than the
maximum valid COOKIE OPT (40) then a FORMERR is generated.
In summary valid cookie lengths are 8 and 16 to 40 inclusive.
7.2.3 Only a CLIENT Cookie
The server SHALL process the query as if the Client Cookie was not
present. In addition it SHALL generate its own COOKIE OPT containing
both the client cookie copied from the request and a server cookie it
has generated and adds this COOKIE OPT to the response's OPT record.
7.2.4 A Client Cookie and Server Cookie
The server shall examine the Server Cookie to determine if it is a
valid server cookie it has generated. This examination will result
in a deterimination of whether the server cookie is valid or not.
7.2.4.1 A Client Cookie and Invalid Server Cookie
This can occur due to a stale server cookie being returned, a clients
IP address changing without the DNS client being aware, or a attempt
to spoof the client.
The server SHALL process the query as if the Client Cookie was not
present. In addition it SHALL generate its own COOKIE OPT containing
both the client cookie copied from the request and a valid server
cookie it has generated and adds this COOKIE OPT to the response's
OPT record.
7.2.4.2 A Client Cookie and Valid Server Cookie
When this occurs the server can assume that it is talking to a client
that it has talked to before and defensive measures for spoofed UDP
queries, if any, are no longer required.
INTERNET-DRAFT DNS Cookies
The server SHALL process the query and include a COOKIE OPT in the
response by (a) copying the complete COOKIE OPT from the request or
(b) generating a new COOKIE OPT containing both the client cookie
copied from the request and a valid server cookie it has generated.
INTERNET-DRAFT DNS Cookies
8. 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 sever secret or the server IP
address and a client secret. You would want to compute the Server 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
skipping to change at page 23, line 45 skipping to change at page 16, line 45
multiple DNS requests and responses from multiple internal hosts to multiple DNS requests and responses from multiple internal hosts to
be mapped to a smaller number of external IP addresses, such as one be mapped to a smaller number of external IP addresses, such as one
address. Thus there could be many clients behind a NAT box that address. Thus there could be many clients behind a NAT box that
appear to come from the same source IP address to a server outside appear to come from the same source IP address to a server outside
that NAT box. If one of these were an attacker (think Zombie or that NAT box. If one of these were an attacker (think Zombie or
Botnet), that behind-NAT attacker could get the Server Cookie for Botnet), that behind-NAT attacker could get the Server Cookie for
some server for the outgoing IP address by just making some random some server for the outgoing IP address by just making some random
request to that server. It could then include that Server Cookie in request to that server. It could then include that Server Cookie in
the COOKIE OPT of requests to the server with the forged local IP the COOKIE OPT of requests to the server with the forged local IP
address of some other host and/or client behind the NAT box. address of some other host and/or client behind the NAT box.
(Attacker possession of this Server Cookie will not help in forging (Attacker possession of this server cookie will not help in forging
responses to cause cache poisoning as such responses are protected by responses to cause cache poisoning as such responses are protected by
the required Client Cookie.) the required Client Cookie.)
To fix this potential defect, it is necessary to distinguish To fix this potential defect, it is necessary to distinguish
different clients behind a NAT box from the point of view of the different clients behind a NAT box from the point of view of the
server. It is for this reason that the Server Cookie is specified as server. It is for this reason that the Server Cookie is specified as
a pseudo-random function of both the request source IP address and a pseudo-random function of both the request source IP address and
the Client Cookie. From this inclusion of the Client Cookie in the the Client Cookie. From this inclusion of the Client Cookie in the
calculation of the Server Cookie, it follows that a stable Client calculation of the Server Cookie, it follows that a stable Client
Cookie, for any particular server, is needed. If, for example, the Cookie, for any particular server, is needed. If, for example, the
skipping to change at page 25, line 7 skipping to change at page 18, line 7
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.4). time period of such time skew (see also Section 5.4).
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
9. Deployment 7. Deployment
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.
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 weak security implements the DNS cookies mechanism, they get the weak security
benefits of the DNS Cookies mechanism. benefits of the DNS Cookies mechanism.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
10. IANA Considerations 8. IANA Considerations
IANA is requested to assign the following four code points: IANA is requested to assign the following two code points:
The OPT option value for COOKIE is <TBD> [10 suggested]. A new OPT option value as shown below:
[The following error codes are not required for the Simple COOKIE Value Name Status Reference
OPT.] -------- ------ -------- ---------------
TBD1[10] COOKIE Standard [this document]
Three new DNS error codes in the range above 16 and below 3,840 as A new DNS error code in the range above 16 and below 3,840 as
shown below: shown below:
RCODE Name Description Reference RCODE Name Description Reference
-------- --------- ----------------- --------------- -------- --------- ------------------------- ---------------
TBD1[23] NOCOOKIE No client cookie. [this document] TBD2[23] BADCOOKIE Bad/missing server cookie [this document]
TBD2[24] MFCOOKIE Malformed cookie. [this document]
TBD3[25] BADCOOKIE Bad/missing server cookie. [this document]
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
11. 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
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 802.11 link For example, if a host is connected via an unsecured IEEE Std 802.11
(Wi-Fi), any device in the vicinity that could receive and decode the link (Wi-Fi), any device in the vicinity that could receive and
802.11 transmissions must be considered "on-path". On the other hand, decode the 802.11 transmissions must be considered "on-path". On the
in a similar situation but one where 802.11 Robust Security (WPAv2) other hand, in a similar situation but one where 802.11 Robust
is appropriately deployed on the Wi-Fi network nodes, only the Access Security (WPAv2) is appropriately deployed on the Wi-Fi network
Point via which the host is connecting is "on-path" as far as the nodes, only the Access Point via which the host is connecting is "on-
802.11 link is concerned. path" 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 substantial reduction in the Internet is expected to provide a substantial 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
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.
11.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 [FNV] because based on a pseudo-random function at least as strong as [FNV] because
an excessively weak or trivial algorithm could enable adversaries to an excessively weak or trivial algorithm could enable adversaries to
guess cookies. However, in light of the weak plain-text token guess cookies. However, in light of the weak plain-text token
security provided by DNS Cookies, a strong cryptography hash security provided by DNS Cookies, a strong cryptography hash
algorithm may not be warranted in many cases, and would cause an algorithm may not be warranted in many cases, and would cause an
increased computational burden. Nevertheless there is nothing wrong increased computational burden. Nevertheless there is nothing wrong
with using something stronger, for example, HMAC-SHA256-64 [RFC6234], with using something stronger, for example, HMAC-SHA256-64 [RFC6234],
assuming a DNS processor has adequate computational resources assuming a DNS processor has adequate computational resources
available. DNS processors that feel the need for somewhat stronger available. DNS processors that feel the need for somewhat stronger
security without a significant increase in computational load should security without a significant increase in computational load should
consider more frequent changes in their client and/or server secret; consider more frequent changes in their client and/or server secret;
however, this does require more frequent generation of a however, this does require more frequent generation of a
cryptographically strong random number [RFC4086]. See Appendices A cryptographically strong random number [RFC4086]. See Appendices A
and B for specific examples of cookie computation algorithms. and B for specific examples of cookie computation algorithms.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
10. Implementation Considerations
The DNS Cookie Option specified herein is implemented in BIND 9.10
using a experimental option code.
INTERNET-DRAFT DNS Cookies
Normative References Normative References
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June "Randomness Requirements for Security", BCP 106, RFC 4086, June
2005. 2005.
[RFC6891] - Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] - Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
skipping to change at page 31, line 5 skipping to change at page 24, line 13
2011. 2011.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Acknowledgements Acknowledgements
The contributions of the following are gratefully acknowledged: The contributions of the following are gratefully acknowledged:
Tim Wicinski Tim Wicinski
The document was prepared in raw nroff. All macros used were defined
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 An simple example method to compute Client Cookies is the FNV-64
[FNV] of the server IP address and the client secret. That is [FNV] of the server IP address and the client secret. That is
Client Cookie = FNV-64 ( Client Secret | Server IP Address ) Client Cookie = FNV-64 ( Client Secret | Server IP Address )
where "|" indicates concatenation. where "|" indicates concatenation.
A.2 A More Complex Algorithm A.2 A More Complex Algorithm
A more complex algorithm to calculate Client Cookies is give below. A more complex algorithm to calculate Client Cookies is give 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, Server IP Address Client Cookie = HMAC-SHA256-64 ( Client Secret,
) Server IP Address )
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 simple method producing a 64-bit Server Cookie is the An example 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. That is server secret. That is
 End of changes. 85 change blocks. 
472 lines changed or deleted 210 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/