Hi all As a part of DNS fragments drafting (which requires protection against UDP amplification attacks), I reviewed draft-ietf-dnsop-cookies-00. Its use in fragments would be narrow and I mainly read the draft from that point-of-view.
The draft describes different types of attacks and the COOKIE mechanisms. While it seems sound, while reading it I felt it didn't explain well HOW the mechanisms help in preventing the listed attacks, or HOW the mechanisms should be deployed. This is partly a network availablity and partly a network integrity related draft, so I think it needs further descriptions and clarifications. It would be nice for things that are left to policy have guidelines. As far as network availability is concerned, compared to what is there now, the effect of this draft is to deny service to some requests where service is provided now. (Another way to look at this would be that in a network without possibility of such attacks, this draft's real effect is to improve service where service would be disrupted now. Nevertheless, the draft is written to assist the server in dropping or refusing requests that don't satisfy some conditions, and so the earlier point is considered.) The conditions for such denial must be described clearly, and perhaps, not completely left to operators to decide. TCP --- It would be useful for "Weak authentication" to be defined in the "Definitions" section. The draft seems to state that what TCP provides after the three-way connection handshake is weak authentication, but that COOKIE option also provides "weak authentication", so its complete meaning should be stated somewhere. > The protection provided by DNS cookies bears some resemblance to that > provided by using TCP for DNS transactions. To bypass the weak > protection provided by using TCP requires an off-path attacker > guessing the 32-bit TCP sequence number in use. To bypass the weak > protection provided by DNS Cookies requires such an attacker to guess > 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. Many of the off-path attacks for UDP don't occur in TCP. There are some attacks on TCP to inject segments by on-path eavesdroppers (and perhaps a 1 in 1<<32 attack by a very lucky off-path attacker), but they won't be discovered by this COOKIE feature even if the option exists. Towards this, the description in the introduction seems somewhat badly phrased. A DNS message over TCP is not limited to a single IP datagram, and COOKIE does not sign data. Perhaps it is trying to compare TCP (either with or without COOKIE) vs. UDP+COOKIE, but it should be clarified. The word UDP doesn't occur even once in the draft, so it is unclear what is intended. TCP already performs "weak authentication" via the 3-way connection establishment handshake, so apart from keeping the COOKIE option alive and going, why should this option have any effect at all (i.e., deny service) in DNS over TCP, when it cannot further help TCP? [As a side note: to avoid SYN flood attacks, most TCPs used on the public internet nowadays use cookies as a weak authentication in the sequence number field (and recently using the timestamp TCP option too, to preserve some more TCP options) during the initial handshake. This is done to avoid maintaining state on the server side until the three-way handshake is complete. This is not an on-going cookie that lasts during the connection, and though it is similarly used to verify the client without maintaining per-request state on the server, the similarity to DNS cookies ends there.] UDP --- UDP is the fast case. A single datagram is sent as a query and a single datagram is received as the reply. Ignoring processing time, if the round-trip time between client and server is represented by the unit RTT, the lookup takes 1 RTT. Typically, UDP is tried first by clients, and if the answer does not fit, TCP is tried. In the best case scenario, assuming the TC=1 reply is delivered correctly, after 1 RTT spent on UDP, the client tries a 3-way handshake ~ another 1 RTT, plus actually sending the data, and receiving a reply, both flows in slow-start, which can take another 1-2 RTT at best for the first 1-3 segments. So this takes at least 3 roundtrips for the simplest DNS query that falls to TCP. From my part of the world to the USA, a roundtrip averages about 280ms. This makes it nearly a second to resolve a single name from a nameserver that truncates, in the best case and without recursion. (A user visiting a new website in her browser would have to wait for resolution to complete, and then the actual HTTP TCP connection to establish, and the process is repeated as as more webservers are contacted.) Fallback to DNS over TCP is slower than UDP, and one of the contributors is the initial attempt over UDP. If DNS UDP peformance degrades, there isn't much in the way to directly try TCP for all its advantages, especially as recent DNS RFCs seem to make TCP support mandatory. In section 5.2.3, Bad or Absent Server Cookie: > In responding to such a request, the server has the following three > choices: > > (1) Silently discard the request. The server can refuse to process a request for myriad other reasons including resource exhaustion, but this draft should not introduce dropping requests as a possibility for "Bad or Absent Cookie". In this case, the client cannot recover as it will not receive the server cookie. It would be good if the draft recommends that the server SHOULD make an effort to send a minimal response with the server cookie to clients that support the COOKIE option. Similarly in section 5.2.2, over TCP requests should never be dropped or refused due to lack of COOKIE as a reason due to the reasons in the TCP section above. [BTW, the last paragraph of that section also contradicts this by saying that servers should use TC=1 in the case of (2) so that future requests are served by TCP.] Coming back to 5.2.3, > (2) Not process the request other than returning a minimal length > 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 > including a COOKIE OPT option with an Error field of BADCOOKIE > and a zero RCODE (unless there was also a non-cookie error in > processing the request). In a DNS implementation that supports the COOKIE option, in the case of (2), at least 2 roundtrips are necessary to actually get an answer for the query when the cookie is unknown when contacting a nameserver for the first time, or when the cookies change. In the case of (3), the risk of amplification attacks comes back. The choice between (2) and (3) is moved to a policy decision, but there are no guidelines for it. Given the risk of EDNS payload size related drops from an uknown server and extra roundtrips, what are the reasons why this option should be used in preference to TCP (that is just 1 RTT longer to get an answer from) and has several other advantages? Some other comments ------------------- 1. In section 2, off-path attacks are considered. Apart from off-path attackers (who have no access to traffic), and on-path attackers (who can modify traffic), there is another class of attackers between these two classes, which are eavesdroppers. Such attackers can listen in and sometimes can inject traffic, but cannot filter or alter traffic. I guess for the purposes of this draft, they can be considered as on-path. 2. In section 5.2, > 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. This seems to go against RFC 6891. RFC 6891 states this: > The order of appearance of option tuples is not defined. If one > option modifies the behaviour of another or multiple options are > related to one another in some way, they have the same effect > regardless of ordering in the RDATA wire encoding. A lower layer that processes OPT options may not end up preserving the ordering of options. So I suggest changing the text to restrict the number of COOKIES options to 1 and behave as if it's not found otherwise. 3. In Section 5.2.3: > (2) Not process the request other than returning a minimal length > 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. Considering that the COOKIE option has an error code field, and it is only sent to the peer that knows about the COOKIE option, is there a reason why the extended RCODE is introduced? Wouldn't it suffice to return RCODE=Refused with the error code field assigned? 4. Does the draft explain how DNS amplification is prevented? It specifies COOKIEs, but there is a bit of connect-the-dots that can be stated, i.e., what facilities fix what issues, and how. It would be useful to present reasons next to all these behavioral descriptions, i.e., say "The client must drop the response to address XYZ threat described in the introduction." 5. The server cookie is unknown in Figure 1, but I recommend having a matching amount of effort (32 bytes of 0s) sent in this request in the server cookie field as in figure 2. This is a draft about countering amplification, so let the client do as much work as it expects the server to do. This will also reduce the number of figures to 1 in the draft, simplifying it. If you do this, I promise not to write a draft that adds a DNS option that bloats the query message to be as large as the EDNS client buffer size. ;) 6. I have a comment on the design of the client cookie, but first, can you explain the following: > However, NAT devices sometimes also map ports. This can cause > multiple DNS requests and responses from multiple internal hosts to > 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 > 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 > Botnet), that behind-NAT attacker could get the Server Cookie for > some server for the outgoing IP address by just making some random > 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 > address of some other host and/or client behind the NAT box. > (Attacker possession of this Server Cookie will not help in forging > responses to cause cache poisoning as such responses are protected by > the required Client Cookie.) > > To fix this potential defect, it is necessary to distinguish > different clients behind a NAT box from the point of view of the > server. Cache poisoning cannot happen, so what is the potential defect? That the other client behind NAT is attacked by traffic? 7. I wonder what would be ways to allow the first request from an IP address to a server to pass without a valid server cookie in the request (with one eventually added in the response), but disallow it from the second request onwards? The simple stupid method, a bitfield of all the 1<<32 IPv4 addresses would occupy 512 MiB of memory... Mukund
pgpYlDLUK4JSW.pgp
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop