draft-ietf-dnsop-cookies-05.txt   draft-ietf-dnsop-cookies-06.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: January 31, 2016 August 1, 2015 Expires: April 18, 2016 October 19, 2015
Domain Name System (DNS) Cookies Domain Name System (DNS) Cookies
<draft-ietf-dnsop-cookies-05.txt> <draft-ietf-dnsop-cookies-06.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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction............................................4 1. Introduction............................................4
1.1 Contents of This Document..............................4 1.1 Contents of This Document..............................4
1.2 Definitions............................................5 1.2 Definitions............................................5
2. Threats Considered......................................6 2. Threats Considered......................................6
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.........................7
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. DNS Cookie Option......................................10 4. DNS Cookie Option......................................10
4.1 Client Cookie.........................................11 4.1 Client Cookie.........................................11
4.2 Server Cookie.........................................11 4.2 Server Cookie.........................................11
5. DNS Cookies Protocol Specification.....................12 5. DNS Cookies Protocol Specification.....................12
5.1 Originating Requests..................................12 5.1 Originating Requests..................................12
5.2 Responding to Request.................................12 5.2 Responding to Request.................................12
5.2.1 No Opt RR or No COOKIE OPT option...................13 5.2.1 No Opt RR or No COOKIE OPT option...................13
5.2.2 Malformed COOKIE OPT option.........................13 5.2.2 Malformed COOKIE OPT option.........................13
5.2.3 Only a Client Cookie................................13 5.2.3 Only a Client Cookie................................13
5.2.4 A Client Cookie and Server Cookie...................14 5.2.4 A Client Cookie and an Invalid Server Cookie........14
5.2.4.1 A Client Cookie and Invalid Server Cookie.........14 5.2.5 A Client Cookie and a Valid Server Cookie...........14
5.2.4.2 A Client Cookie and Valid Server Cookie...........14
5.3 Processing Responses..................................14 5.3 Processing Responses..................................14
5.4 QUERYing for a Server Cookie..........................15 5.4 QUERYing for a Server Cookie..........................15
5.5 Client and Server Secret Rollover.....................16 5.5 Client and Server Secret Rollover.....................16
6. NAT Considerations and AnyCast Server Considerations...17 6. NAT Considerations and AnyCast Server Considerations...17
7. Deployment.............................................19 7. Deployment.............................................19
8. IANA Considerations....................................20 8. IANA Considerations....................................20
9. Security Considerations................................21 9. Security Considerations................................21
9.1 Cookie Algorithm Considerations.......................21 9.1 Cookie Algorithm Considerations.......................21
10. Implementation Considerations.........................23 10. Implementation Considerations.........................23
Normative References......................................24 Normative References......................................24
Informative References....................................24 Informative References....................................24
Acknowledgements..........................................26 Acknowledgements..........................................26
Appendix A: Example Client Cookie Algorithms..............27 Appendix A: Example Client Cookie Algorithms..............27
A.1 A Simple Algorithm....................................27 A.1 A Simple Algorithm....................................27
A.2 A More Complex Algorithm..............................27 A.2 A More Complex Algorithm..............................27
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Table of Contents (continued) Table of Contents (continued)
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.
There are also on-path denial of service attacks that attempt to
saturate a server with DNS requests having correct souce addresses.
Cookies do not protect against such attacks but successful cookie
validation improves the probablity that the correct source IP address
for the requests is known. This facilitates contacting the managers
of or taking other actions for the networks from which the requests
originate.
2.1.1 DNS Amplification Attacks 2.1.1 DNS Amplification Attacks
A request with a forged IP address generally causes a response to be A request with a forged IP source address generally causes a response
sent to that forged IP address. Thus the forging of many such to be sent to that forged IP address. Thus the forging of many such
requests with a particular source IP address can result in enough requests with a particular source IP address can result in enough
traffic being sent to the forged IP address to interfere with service traffic being sent to the forged IP address to interfere with service
to the host at the IP address. Furthermore, it is generally easy in to the host at the IP address. Furthermore, it is generally easy in
the DNS to create short requests that produce much longer responses, the DNS to create short requests that produce much longer responses,
thus amplifying the attack. thus amplifying the attack.
The DNS Cookies mechanism can severely limit the traffic The DNS Cookies mechanism can severely limit the traffic
amplification obtained by attackers off path for the server and the amplification obtained by attacker requests that are off the path
attacked host. Enforced DNS cookies would make it hard for an off between the server and the request's source address. Enforced DNS
path attacker to cause any more than rate-limited short error cookies would make it hard for an off path attacker to cause any more
responses to be sent to a forged IP address so the attack would be than rate-limited short error responses to be sent to a forged IP
attenuated rather than amplified. DNS cookies make it more effective address so the attack would be attenuated rather than amplified. DNS
to implement a rate limiting scheme for error responses from the cookies make it more effective to implement a rate limiting scheme
server. Such a scheme would further restrict selected host denial- for error responses from the server. Such a scheme would further
of-service traffic from that server. restrict selected host denial-of-service traffic from that server.
INTERNET-DRAFT DNS Cookies
2.1.2 DNS Server Denial-of-Service 2.1.2 DNS Server Denial-of-Service
DNS requests that are accepted cause work on the part of DNS servers. DNS requests that are accepted cause work on the part of DNS servers.
This is particularly true for recursive servers that may issue one or This is particularly true for recursive servers that may issue one or
more requests and process the responses thereto, in order to more requests and process the responses thereto, in order to
determine their response to the initial request. And the situation determine their response to the initial request. And the situation
can be even worse for recursive servers implementing DNSSEC can be even worse for recursive servers implementing DNSSEC
([RFC4033] [RFC4034] [RFC4035]) because they may be induced to ([RFC4033] [RFC4034] [RFC4035]) because they may be induced to
perform burdensome cryptographic computations in attempts to verify perform burdensome cryptographic computations in attempts to verify
the authenticity of data they retrieve in trying to answer the the authenticity of data they retrieve in trying to answer the
INTERNET-DRAFT DNS Cookies
request. request.
The computational or communications burden caused by such requests The computational or communications burden caused by such requests
may not depend on a forged IP source address, but the use of such may not depend on a forged IP source address, but the use of such
addresses makes addresses makes
+ the source of the requests causing the denial-of-service attack + the source of the requests causing the denial-of-service attack
harder to find and harder to find and
+ restriction of the IP addresses from which such requests should + restriction of the IP addresses from which such requests should
be honored hard or impossible to specify or verify. be honored hard or impossible to specify or verify.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
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.
3.1 Existing DNS Data Security 3.1 Existing DNS Data Security
DNS data security is one part of DNSSEC and is described in DNS data security is one part of DNSSEC and is described in
[RFC4033], [RFC4034], [RFC4035], and updates thereto. It provides [RFC4033], [RFC4034], [RFC4035], and updates thereto. It provides
data origin authentication and authenticated denial of existence. data origin authentication and authenticated denial of existence.
DNSSEC is being deployed and can provide strong protection against DNSSEC is being deployed and can provide strong protection against
forged data; however, it has the unintended effect of making some forged data and cache poisoning; however, it has the unintended
denial-of-service attacks worse because of the cryptographic effect of making some denial-of-service attacks worse because of the
computational load it can require and the increased size in DNS cryptographic computational load it can require and the increased
response packets that it tends to produce. size in DNS response packets that it tends to produce.
3.2 DNS Message/Transaction Security 3.2 DNS Message/Transaction Security
The second form of security that has been added to DNS provides The second form of security that has been added to DNS provides
"transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931]. "transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931].
TSIG could provide strong protection against the attacks for which TSIG could provide strong protection against the attacks for which
the DNS Cookies mechanism provides weak protection; however, TSIG is the DNS Cookies mechanism provides weak protection; however, TSIG is
non-trivial to deploy in the general Internet because of the burdens non-trivial to deploy in the general Internet because of the burdens
it imposes. Among these burdens are pre-agreement and key it imposes. Among these burdens are pre-agreement and key
distribution between client and server, keeping track of server side distribution between client and server, keeping track of server side
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.
In order to maintain the security properties of this protocol, a In order to provide minimal authentication, a client MUST send client
client MUST NOT use the same Client Cookie value for requests to all COOKIEs that will usually be different for any two servers at
servers. different IP addresses.
4.2 Server Cookie 4.2 Server Cookie
The Server Cookie SHOULD consist of or include a 64-bit or larger The Server Cookie SHOULD consist of or include a 64-bit or larger
pseudo-random function of the request source IP address, the request pseudo-random function of the request source IP address, the request
Client Cookie, and a secret quantity known only to the server. (See Client Cookie, and a secret quantity known only to the server. (See
Section 6 for a discussion of why the Client Cookie is used as input Section 6 for a discussion of why the Client Cookie is used as input
to the Server Cookie but the Server Cookie is not used as an input to to the Server Cookie but the Server Cookie is not used as an input to
the Client Cookie.) This server secret SHOULD have at least 64 bits the Client Cookie.) This server secret SHOULD have at least 64 bits
of entropy [RFC4086] and be changed periodically (see Section 5.5). of entropy [RFC4086] and be changed periodically (see Section 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.
In order to maintain the security properties of this protocol, a In order to provide minimal authentication, a server MUST send server
server MUST NOT use the same Server Cookie value for responses to all COOKIEs that will usually be different for clients at any two
clients. different IP addresses or with different client COOKIEs.
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
skipping to change at page 12, line 38 skipping to change at page 12, line 38
Cookie in the option along with the Client Cookie (Figure 2). Cookie in the option along with the Client Cookie (Figure 2).
Otherwise it just sends the shorter form option with a Client Cookie Otherwise it just sends the shorter form option with a Client Cookie
(Figure 1). (Figure 1).
5.2 Responding to Request 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 sent to that
that client in an earlier response appearing as the Server Cookie client in an earlier response appearing as the Server Cookie field in
field in the request. the request.
At a server where DNS Cookies are not implemented and enabled, At a server where DNS Cookies are not implemented and enabled,
presence of a COOKIE OPT option is ignored and the server responds as presence of a COOKIE OPT option is ignored and the server responds as
if no COOKIE OPT option had been included in the request. if no COOKIE OPT option had been included in the request.
When DNS Cookies are implemented and enabled, there are four When DNS Cookies are implemented and enabled, there are five
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 or there
there is no valid Client Cookie in the request because the COOKIE OPT is a OPT RR but the the COOKIE OPT option is absent from the OPT RR;
option is absent from the request, or one is present but is not a (2) a COOKIE OPT is present but is not a legal length or otherwise
legal length; (3) there is a valid length cookie option in the malformed; (3) there is a valid length cookie option in the request
request with no Server Cookie or an incorrect Server Cookie; or (4) with no Server Cookie; (4) there is a valid length COOKIE OPT in the
there is a cookie option in the request with a correct Server Cookie. request with a Server Cookie but that Server Cookie is invalid; or
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
The four possibilities are discussed in the subsections below. (5) there is a valid length COOKIE OPT in the request with a correct
Server Cookie.
The five possibilities are discussed in the subsections below.
In all cases 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.
5.2.1 No Opt RR or No COOKIE OPT option 5.2.1 No Opt RR or No COOKIE OPT option
If there is no OPT record or no COOKIE OPT option present in the If there is no OPT record or no COOKIE OPT option present in the
request then the server responds to the request as if the server request then the server responds to the request as if the server
doesn't implement the COOKIE OPT. doesn't implement the COOKIE OPT.
skipping to change at page 13, line 48 skipping to change at page 14, line 4
(3) Process the request and provide a normal response. The RCODE is (3) Process the request and provide a normal response. The RCODE is
NOERROR unless some non-cookie error occurs in processing the NOERROR unless some non-cookie error occurs in processing the
request. request.
If the server responds, choosing 2 or 3 above, it SHALL generate its If the server responds, choosing 2 or 3 above, it SHALL generate its
own COOKIE OPT containing both the Client Cookie copied from the own COOKIE OPT containing both the Client Cookie copied from the
request and a Server Cookie it has generated and adds this COOKIE OPT request and a Server Cookie it has generated and adds this COOKIE OPT
to the response's OPT record. Servers MUST, at least occasionally, to the response's OPT record. Servers MUST, at least occasionally,
respond to such requests to inform the client of the correct Server respond to such requests to inform the client of the correct Server
Cookie. This is necessary so that such a client can bootstrap to the
weakly secure state where requests and responses have recognized
Server Cookies and Client Cookies.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
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. A server is not expected to
maintain per client state to achieve this. For example, it could
respond to every Nth request across all clients.
If the request was received over TCP, the server SHOULD take the weak If the request was received over TCP, the server SHOULD take the weak
authentication provided by the use of TCP into account and SHOULD authentication provided by the use of TCP into account and SHOULD
choose 3. In this case, if the server is not willing to accept the choose 3. In this case, if the server is not willing to accept the
weak security provided by TCP as a substitute for the weak security weak security provided by TCP as a substitute for the weak security
provided by DNS Cookies but instead chooses 2, there is some danger provided by DNS Cookies but instead chooses 2, there is some danger
of an indefinite loop of retries (see Section 5.3). of an indefinite loop of retries (see Section 5.3).
5.2.4 A Client Cookie and Server Cookie 5.2.4 A Client Cookie and an Invalid Server Cookie
The server examines the Server Cookie to determine if it is a valid The server examines the Server Cookie to determine if it is a valid
Server Cookie it has generated. This examination will result in a Server Cookie it has generated. This examination will result in a
determination of whether the Server Cookie is valid or not. These determination of whether the Server Cookie is valid or not. If the
cases are discussed below. cookie is invalid, it can be because of a stale Server Cookie, or a
5.2.4.1 A Client Cookie and Invalid Server Cookie
This can occur due to a stale Server Cookie being returned, a
client's IP address or Client Cookie changing without the DNS server client's IP address or Client Cookie changing without the DNS server
being aware, an anycast server cluster that is not consistently being aware, or an anycast server cluster that is not consistently
configured, or an attempt to spoof the client. configured, or an attempt to spoof the client.
The server SHALL process the request as if the invalid Server Cookie The server SHALL process the request as if the invalid Server Cookie
was not present as described in Section 5.2.3. was not present as described in Section 5.2.3.
5.2.4.2 A Client Cookie and Valid Server Cookie 5.2.5 A Client Cookie and a Valid Server Cookie
When this occurs the server can assume that the request is from a When a valid Server Cookie is present in the request the server can
client that it has talked to before and defensive measures for assume that the request is from a client that it has talked to before
spoofed UDP requests, if any, are no longer required. and defensive measures for spoofed UDP requests, if any, are no
longer required.
The server SHALL process the request and include a COOKIE OPT in the The server SHALL process the request and include a COOKIE OPT in the
response by (a) copying the complete COOKIE OPT from the request or response by (a) copying the complete COOKIE OPT from the request or
(b) generating a new COOKIE OPT containing both the Client Cookie (b) generating a new COOKIE OPT containing both the Client Cookie
copied from the request and a valid Server Cookie it has generated. copied from the request and a valid Server Cookie it has generated.
5.3 Processing Responses 5.3 Processing Responses
The Client Cookie, when it occurs in a COOKIE OPT option in a DNS The Client Cookie, when it occurs in a COOKIE OPT option in a DNS
reply, is intended to weakly assure the client that the reply came reply, is intended to weakly assure the client that the reply came
from a server at the source IP address used in the response packet from a server at the source IP address used in the response packet
because the Client Cookie value is the value that client would send because the Client Cookie value is the value that client would send
to that server in a request. In a DNS reply with multiple COOKIE OPT
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
to that server in a request. In a DNS reply with multiple COOKIE OPT
options, all but the first (the one closest to the DNS Header) are options, all but the first (the one closest to the DNS Header) are
ignored. ignored.
A DNS client where DNS cookies are implemented and enabled examines A DNS client where DNS cookies are implemented and enabled examines
the response for DNS cookies and MUST discard the response if it the response for DNS cookies and MUST discard the response if it
contains an illegal COOKIE OPT option length or an incorrect Client contains an illegal COOKIE OPT option length or an incorrect Client
Cookie value. If the COOKIE OPT option Client Cookie is correct, the Cookie value. If the COOKIE OPT option Client Cookie is correct, the
client caches the Server Cookie provided even if the response is an client caches the Server Cookie provided even if the response is an
error response (RCODE non-zero). error response (RCODE non-zero).
skipping to change at page 15, line 54 skipping to change at page 16, line 4
zero) provided that an OPT record is present with a COOKIE option. zero) provided that an OPT record is present with a COOKIE option.
Such servers will reply with an empty answer section and a COOKIE Such servers will reply with an empty answer section and a COOKIE
option giving the Client Cookie provided in the query and a valid option giving the Client Cookie provided in the query and a valid
Server Cookie. Server Cookie.
If such a query provided just a Client Cookie and no Server Cookie, If such a query provided just a Client Cookie and no Server Cookie,
the response SHALL have the RCODE NOERROR. the response SHALL have the RCODE NOERROR.
This mechanism can also be used to confirm/re-establish a existing This mechanism can also be used to confirm/re-establish a 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
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
Cookie. In this case the response SHALL have the RCODE BADCOOKIE if
the Server Cookie sent with the query was invalid and the RCODE the Server Cookie sent with the query was invalid and the RCODE
NOERROR if it was valid. NOERROR if it was valid.
Servers which don't support the COOKIE option will normally send Servers which don't support the COOKIE option will normally send
FORMERR in response to such a query, though REFUSED, NOTIMP, and FORMERR in response to such a query, though REFUSED, NOTIMP, and
NOERROR without a COOKIE option are also possible in such responses. NOERROR without a COOKIE option are also possible in such responses.
5.5 Client and Server Secret Rollover 5.5 Client and Server Secret Rollover
Clients and servers MUST NOT continue to use the same secret in new The longer a secret is used, the higher the probability it has been
requests and responses for more than 36 days and SHOULD NOT continue compromised. Thus clients and servers MUST NOT continue to use the
to do so for more than 26 hours. Many clients rolling over their same secret in new requests and responses for more than 36 days and
secret at the same time could briefly increase server traffic and SHOULD NOT continue to do so for more than 26 hours. These values are
exactly predictable rollover times for clients or servers might chosen to assure that a secret will not be used for longer than about
facilitate guessing attacks. For example, an attacker might increase a month and normally no longer than one day. The odd values are to
the priority of attacking secrets they believe will be in effect for allow for long holiday weekends and daylight savings time shifts and
an extended period of time. To avoid rollover synchronization and the like while still staying within the limits.
predictability, it is RECOMMENDED that pseudorandom jitter in the
range of plus zero to minus at least 40% be applied to the time until Many clients rolling over their secret at the same time could briefly
a scheduled rollover of a DNS cookie secret. increase server traffic and exactly predictable rollover times for
clients or servers might facilitate guessing attacks. For example, an
attacker might increase the priority of attacking secrets they
believe will be in effect for an extended period of time. To avoid
rollover synchronization and predictability, it is RECOMMENDED that
pseudorandom jitter in the range of plus zero to minus at least 40%
be applied to the time until a scheduled rollover of a DNS cookie
secret.
It is RECOMMENDED that a client keep the Client Cookie it is 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 associated with the outstanding request 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 5 minutes, after a change in its secret, and consider requests than 5 minutes, after a change in its secret, and consider requests
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.
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. More
rapid rollover decreases the benefit to a cookie guessing attacker if
they succeed in guessing a cookie.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
6. NAT Considerations and AnyCast Server Considerations 6. NAT Considerations and AnyCast Server Considerations
In the Classic Internet, DNS Cookies could simply be a pseudo-random In the Classic Internet, DNS Cookies could simply be a pseudo-random
function of the client IP address and a server secret or the server function of the client IP address and a server secret or the server
IP address and a client secret. You would want to compute the Server IP address and a client secret. You would want to compute the Server
Cookie that way, so a client could cache its Server Cookie for a Cookie that way, so a client could cache its Server Cookie for a
particular server for an indefinitely amount of time and the server particular server for an indefinitely amount of time and the server
skipping to change at page 21, line 25 skipping to change at page 21, line 25
For example, if a host is connected via an unsecured IEEE Std 802.11 For example, if a host is connected via an unsecured IEEE Std 802.11
link (Wi-Fi), any device in the vicinity that could receive and link (Wi-Fi), any device in the vicinity that could receive and
decode the 802.11 transmissions must be considered "on-path". On the decode the 802.11 transmissions must be considered "on-path". On the
other hand, in a similar situation but one where 802.11 Robust other hand, in a similar situation but one where 802.11 Robust
Security (WPAv2) is appropriately deployed on the Wi-Fi network Security (WPAv2) is appropriately deployed on the Wi-Fi network
nodes, only the Access Point via which the host is connecting is "on- nodes, only the Access Point via which the host is connecting is "on-
path" as far as the 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 significant reduction in the
available launch points for the traffic amplification and denial of available launch points for the traffic amplification and denial of
service forgery attacks described in Section 2 above. service forgery attacks described in Section 2 above.
Should stronger message/transaction security be desired, it is Should stronger message/transaction security be desired, it is
suggested that TSIG or SIG(0) security be used (see Section 3.2); suggested that TSIG or SIG(0) security be used (see Section 3.2);
however, it may be useful to use DNS Cookies in conjunction with however, it may be useful to use DNS Cookies in conjunction with
these features. In particular, DNS Cookies could screen out many DNS these features. In particular, DNS Cookies could screen out many DNS
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.
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 FNV (Fowler- based on a pseudo-random function at least as strong as 64-bit FNV
Noll-Vo [FNV]) because an excessively weak or trivial algorithm could (Fowler-Noll-Vo [FNV]) because an excessively weak or trivial
enable adversaries to guess cookies. However, in light of the weak algorithm could enable adversaries to guess cookies. However, in
plain-text token security provided by DNS Cookies, a strong light of the weak plain-text token security provided by DNS Cookies,
cryptography hash algorithm may not be warranted in many cases, and a strong cryptography hash algorithm may not be warranted in many
would cause an increased computational burden. Nevertheless there is cases, and would cause an increased computational burden.
nothing wrong with using something stronger, for example, HMAC- Nevertheless there is nothing wrong with using something stronger,
SHA256-64 [RFC6234], assuming a DNS processor has adequate for example, HMAC-SHA256-64 [RFC6234], assuming a DNS processor has
computational resources available. DNS processors that feel the need adequate computational resources available. DNS processors that feel
for somewhat stronger security without a significant increase in the need for somewhat stronger security without a significant
computational load should consider more frequent changes in their increase in computational load should consider more frequent changes
client and/or server secret; however, this does require more frequent in their client and/or server secret; however, this does require more
generation of a cryptographically strong random number [RFC4086]. See frequent generation of a cryptographically strong random number
Appendices A and B for specific examples of cookie computation [RFC4086]. See Appendices A and B for specific examples of cookie
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
algorithms. computation algorithms.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
10. Implementation Considerations 10. Implementation Considerations
The DNS Cookie Option specified herein is implemented in BIND 9.10 The DNS Cookie Option specified herein is implemented in BIND 9.10
using a experimental option code. using a experimental option code.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
 End of changes. 33 change blocks. 
87 lines changed or deleted 105 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/