Re: DNS hardening, was Re: Dan Kaminsky
This was responded to on the DNSEXT mailing list. Sorry, but your question was accidentally attributed to Paul who forwarded the message. DNSEXT Archive: http://ops.ietf.org/lists/namedroppers/ -Doug
Re: DNS hardening, was Re: Dan Kaminsky
On Thu, 06 Aug 2009 06:51:24 + Paul Vixie vi...@isc.org wrote: Christopher Morrow morrowc.li...@gmail.com writes: how does SCTP ensure against spoofed or reflected attacks? there is no server side protocol control block required in SCTP. someone sends you a create association request, you send back a ok, here's your cookie and you're done until/unless they come back and say ok, here's my cookie, and here's my DNS request. so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do. because of the extra round trips nec'y to create an SCTP association (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches. however, because the state is mostly on the client side, a server with associations open to millions of clients at the same time is actually no big deal. Am I missing something? The SCTP cookie guards against the equivalent of SYN-flooding attacks. The problem with SCTP is normal operations. A UDP DNS query today takes a message and a reply, with no (kernel) state created on the server end. For SCTP, it takes two round trips to set up the connection -- which includes kernel state -- followed by the query and reply, and tear-down. I confess that I don't remember the SCTP state diagram; in TCP, the side that closes first can end up in FIN-WAIT2 state, which is stable. That is, suppose the server -- the loaded party -- tries to shed kernel state by closing its DNS socket first. If the client goes away or is otherwise uncooperative, the server will then end up in FIN-WAIT2, in which case kernel memory is consumed forever by conforming server TCPs. Does SCTP have that problem? --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: DNS hardening, was Re: Dan Kaminsky
Christopher Morrow morrowc.li...@gmail.com writes: how does SCTP ensure against spoofed or reflected attacks? there is no server side protocol control block required in SCTP. someone sends you a create association request, you send back a ok, here's your cookie and you're done until/unless they come back and say ok, here's my cookie, and here's my DNS request. so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do. because of the extra round trips nec'y to create an SCTP association (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches. however, because the state is mostly on the client side, a server with associations open to millions of clients at the same time is actually no big deal. -- Paul Vixie KI6YSY
Re: DNS hardening, was Re: Dan Kaminsky
* Douglas Otis: Establishing SCTP as a preferred DNS transport offers a safe harbor for major ISPs. SCTP is not a suitable transport for DNS, for several reasons: Existing SCTP stacks are not particularly robust (far less than TCP). The number of bugs still found in them is rather large. Only very few stacks (if any) implement operation without kernel buffers. The remaining ones are subject to the same state exhaustion attacks as TCP stacks are. At least some parts of SCTP and the SCTP API were designed for a cooperative environment. The SCTP API specification is very ambiguous, which is quite strange for such a young protocol. For instance, it is not clear if a single socket is used to communicate with multiple peers, head-of-line blocking can occur. The protocol has insufficient signalling to ensure that implementations turn off features which are harmful on a global scale. For instance, persistant authoritative - resolver connections only work if you switch off heartbeat, but the protocol cannot do this, and it is likely that many peers won't do it. SCTP proposers generally counter these observations by referring to extensions and protocols which are not yet standardized, not implemented, or both, constantly moving the goalposts. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: DNS hardening, was Re: Dan Kaminsky
* Paul Vixie: there is no server side protocol control block required in SCTP. SCTP needs per-peer state for congestion control and retransmission. someone sends you a create association request, you send back a ok, here's your cookie and you're done until/unless they come back and say ok, here's my cookie, and here's my DNS request. so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do. This is a red herring. The TCP state issues are deeper and haven't got much to do with source address validation. The issues are mostly caused by how the BSD sockets API is designed. SCTP uses the same API model, and suffers from similar problems. because of the extra round trips nec'y to create an SCTP association (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches. This doesn't seem possible with current SCTP because the heartbeat rate quickly adds up and overloads servers further upstream. It also does not work on UNIX-like system where processes are short-lived and get a fresh stub resolver each time they are restarted. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: DNS hardening, was Re: Dan Kaminsky
* John Levine: 3) Random case in queries, e.g. GooGLe.CoM This does not work well without additional changes because google.com can be spoofed with responses to 123352123.com (or even 123352123.). Unbound strives to implement the necessary changes, some of which are also required if you want to use DNSSEC to compensate for lack of channel security. As far as I know (and Paul will certainly correct me), the necessary changes are not present in current BIND releases. 4) Ask twice (with different values for the first three hacks) and compare the answers There is a protocol proposal to cope with fluctuating data, but I'm not aware that anyone has expressed interest in implementing it. Basically, the idea is to reduce caching for such data, so that successful spoofing attacks have less amplification effect. I presume everyone is doing the first two. Any experience with the other two to report? 0x20 has alleged interoperability issues. It's also not such a simple upgrade as it was initially thought, so the trade-off is rather poor for existing resolver code bases. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: DNS hardening, was Re: Dan Kaminsky
On Thu, 6 Aug 2009, Florian Weimer wrote: This doesn't seem possible with current SCTP because the heartbeat rate quickly adds up and overloads servers further upstream. It also does not work on UNIX-like system where processes are short-lived and get a fresh stub resolver each time they are restarted. Stubs on Unix systems can have long-lived processes that handle the actual lookups, the stub component in the process that calls into the resolver then accesses it via IPC. I.e. the NSCD style approach. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: As Zeus said to Narcissus, Watch yourself.
Re: DNS hardening, was Re: Dan Kaminsky
On Thu, Aug 6, 2009 at 2:51 AM, Paul Vixievi...@isc.org wrote: Christopher Morrow morrowc.li...@gmail.com writes: how does SCTP ensure against spoofed or reflected attacks? there is no server side protocol control block required in SCTP. someone sends you a create association request, you send back a ok, here's your cookie and you're done until/unless they come back and say ok, here's my cookie, and here's my DNS request. so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do. awesome, how does that work with devices in the f-root-anycast design? (both local hosts in the rack and if I flip from rack to rack) If I send along a request to a host which I do not have an association created do I get a failure and then re-setup? (inducing further latency) because of the extra round trips nec'y to create an SCTP association (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches. however, because the state is mostly on the client side, a server with associations open to millions of clients at the same time is actually no big deal. See question above, as well as: Do loadbalancers, or loadbalanced deployments, deal with this properly? (loadbalancers like F5, citrix, radware, cisco, etc...) -Chris
Re: DNS hardening, was Re: Dan Kaminsky
note, i went off-topic in my previous note, and i'll be answering florian on namedroppers@ since it's not operational. chris's note was operational: Date: Thu, 6 Aug 2009 10:18:11 -0400 From: Christopher Morrow morrowc.li...@gmail.com awesome, how does that work with devices in the f-root-anycast design? (both local hosts in the rack and if I flip from rack to rack) If I send along a request to a host which I do not have an association created do I get a failure and then re-setup? (inducing further latency) yes. so, association setup cost will occur once per route-change event. note that the f-root-anycast design already hashes by flow within a rack to keep TCP from failing, so the only route-change events of interest to this point are in wide area BGP. ...: Do loadbalancers, or loadbalanced deployments, deal with this properly? (loadbalancers like F5, citrix, radware, cisco, etc...) as far as i know, no loadbalancer understands SCTP today. if they can be made to pass SCTP through unmodified and only do their enhanced L4 on UDP and TCP as they do now, all will be well. if not then a loadbalancer upgrade or removal will be nec'y for anyone who wants to deploy SCTP. it's interesting to me that existing deployments of L4-aware packet level devices can form a barrier to new kinds of L4. it's as if the internet is really just the web, and our networks are TCP/UDP networks not IP networks.
Re: DNS hardening, was Re: Dan Kaminsky
On Thu, Aug 06, 2009 at 03:16:25PM +, Paul Vixie wrote: ...: Do loadbalancers, or loadbalanced deployments, deal with this properly? (loadbalancers like F5, citrix, radware, cisco, etc...) as far as i know, no loadbalancer understands SCTP today. if they can be made to pass SCTP through unmodified and only do their enhanced L4 on UDP and TCP as they do now, all will be well. if not then a loadbalancer upgrade or removal will be nec'y for anyone who wants to deploy SCTP. F5 BIG-IP 10.0 has support for load balancing SCTP. I have not tested or implemented it. I do not know what feature parity exists with other protocols. But at least it's documented and supported. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie
Re: DNS hardening, was Re: Dan Kaminsky
On Thu, Aug 6, 2009 at 11:16 AM, Paul Vixievi...@isc.org wrote: note, i went off-topic in my previous note, and i'll be answering florian on namedroppers@ since it's not operational. chris's note was operational: Date: Thu, 6 Aug 2009 10:18:11 -0400 From: Christopher Morrow morrowc.li...@gmail.com awesome, how does that work with devices in the f-root-anycast design? (both local hosts in the rack and if I flip from rack to rack) If I send along a request to a host which I do not have an association created do I get a failure and then re-setup? (inducing further latency) yes. so, association setup cost will occur once per route-change event. note that the f-root-anycast design already hashes by flow within a rack pulling something I didn't previously understand from an ongoing discussion on the LISP/v6ops mailing lists... most routers today only hash on tcp/udp so.. sctp isn't going to hash in the same 'deterministic' manner, or someone should probably test that that is the case. to keep TCP from failing, so the only route-change events of interest to this point are in wide area BGP. right, and the (I think K-root) K-root folks had a study showing 1% of sessions seemed to be failing in this manner? (nanog in Toronto I think?) ...: Do loadbalancers, or loadbalanced deployments, deal with this properly? (loadbalancers like F5, citrix, radware, cisco, etc...) as far as i know, no loadbalancer understands SCTP today. if they can be made to pass SCTP through unmodified and only do their enhanced L4 on UDP and TCP as they do now, all will be well. if not then a loadbalancer upgrade or removal will be nec'y for anyone who wants to deploy SCTP. it's interesting to me that existing deployments of L4-aware packet level devices can form a barrier to new kinds of L4. it's as if the internet is really just the web, and our networks are TCP/UDP networks not IP networks. sadly, people have (and continue) to make simplifying assumptions while designing/deploying equipment. -Chris
Re: DNS hardening, was Re: Dan Kaminsky
On Wed, Aug 5, 2009 at 6:48 PM, John Levinejo...@iecc.com wrote: 3) Random case in queries, e.g. GooGLe.CoM 4) Ask twice (with different values for the first three hacks) and compare the answers I presume everyone is doing the first two. Any experience with the other two to report? 3 works, but offers zero protection against 'kaminsky spoofing the root' since you can't fold the case of 123456789.. And the root is the goal. 4 breaks on Akamai and many other CDNs. Even 'ask thrice, and take the majority answer' doesn't work there. 5 is 'edns ping', but it was effectively blocked because people thought DNSSEC would be easier to do, or demanded that EDNS PING (http://edns-ping.org) would offer everything that DNSSEC offered. Bert
Re: DNS hardening, was Re: Dan Kaminsky
bert hubert (bert.hubert) writes: 5 is 'edns ping', but it was effectively blocked because people thought DNSSEC would be easier to do, or demanded that EDNS PING (http://edns-ping.org) would offer everything that DNSSEC offered. I'm surprised you failed to mention http://dnscurve.org/crypto.html, which is always brought up, but never seems to solve the problems mentioned.
Re: DNS hardening, was Re: Dan Kaminsky
On 8/5/09 9:48 AM, John Levine wrote: Other than DNSSEC, I'm aware of these relatively simple hacks to add entropy to DNS queries. 1) Random query ID 2) Random source port 3) Random case in queries, e.g. GooGLe.CoM 4) Ask twice (with different values for the first three hacks) and compare the answers DNSSEC introduces vulnerabilities, such as reflected attacks and fragmentation related exploits that might poison glue, where perhaps asking twice might still be needed. Modern implementations use random 16 bit transaction IDs. Interposed NATs may impair effectiveness of random source ports. Use of random query cases may not offer an entropy increase in some instances. Asking twice, although doubling resource consumption and latency, offers an increase in entropy that works best when queried serially. Establishing SCTP as a preferred DNS transport offers a safe harbor for major ISPs. SCTP protects against both spoofed and reflected attack. Use of persistent SCTP associations can provide lower latency than that found using TCP fallback, TCP only, or repeated queries. SCTP also better deals with attack related congestion. Once UDP is impaired by EDNS0 response sizes that exceed reassembly resources, or are preemptively dropped as a result, TCP must then dramatically scale up to offer the resilience achieved by UDP anycast. In this scenario, SCTP offers several benefits. SCTP retains initialization state within cryptographically secured cookies, which provides significant protection against spoofed source resource exhaustion. By first exchanging cookies, the network extends server state storage. SCTP also better ensures against cache poisoning whether DNSSEC is used or not. Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. SCTP will also encourage use of IPv6, and improve proper SOHO router support. When SCTP becomes used by HTTP, this further enhances DDoS resistance for even critical web related services as well. -Doug
Re: DNS hardening, was Re: Dan Kaminsky
On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote: Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. Can you elaborate on this (or are you referring to removing the spoofing vector?)? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Unfortunately, inefficiency scales really well. -- Kevin Lawton
RE: DNS hardening, was Re: Dan Kaminsky
That is, of course, assuming that SCTP implementations someday clean up their act a bit. I'm not so sure I'd suggest that they're really ready for prime time at this point. - S -Original Message- From: Douglas Otis do...@mail-abuse.org Sent: Wednesday, August 05, 2009 11:13 To: John Levine jo...@iecc.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: DNS hardening, was Re: Dan Kaminsky On 8/5/09 9:48 AM, John Levine wrote: Other than DNSSEC, I'm aware of these relatively simple hacks to add entropy to DNS queries. 1) Random query ID 2) Random source port 3) Random case in queries, e.g. GooGLe.CoM 4) Ask twice (with different values for the first three hacks) and compare the answers DNSSEC introduces vulnerabilities, such as reflected attacks and fragmentation related exploits that might poison glue, where perhaps asking twice might still be needed. Modern implementations use random 16 bit transaction IDs. Interposed NATs may impair effectiveness of random source ports. Use of random query cases may not offer an entropy increase in some instances. Asking twice, although doubling resource consumption and latency, offers an increase in entropy that works best when queried serially. Establishing SCTP as a preferred DNS transport offers a safe harbor for major ISPs. SCTP protects against both spoofed and reflected attack. Use of persistent SCTP associations can provide lower latency than that found using TCP fallback, TCP only, or repeated queries. SCTP also better deals with attack related congestion. Once UDP is impaired by EDNS0 response sizes that exceed reassembly resources, or are preemptively dropped as a result, TCP must then dramatically scale up to offer the resilience achieved by UDP anycast. In this scenario, SCTP offers several benefits. SCTP retains initialization state within cryptographically secured cookies, which provides significant protection against spoofed source resource exhaustion. By first exchanging cookies, the network extends server state storage. SCTP also better ensures against cache poisoning whether DNSSEC is used or not. Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. SCTP will also encourage use of IPv6, and improve proper SOHO router support. When SCTP becomes used by HTTP, this further enhances DDoS resistance for even critical web related services as well. -Doug
Re: DNS hardening, was Re: Dan Kaminsky
5 is 'edns ping', but it was effectively blocked because people thought DNSSEC would be easier to do, or demanded that EDNS PING (http://edns-ping.org) would offer everything that DNSSEC offered. I'm surprised you failed to mention http://dnscurve.org/crypto.html, which is always brought up, but never seems to solve the problems mentioned. dnscurve looks like a swell idea, but I wouldn't put it in the category of a hack as straightforward as the ones I listed. Also, at this point there appears to be neither code nor an implementable spec available since Dan is still fiddling with it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly.
Re: DNS hardening, was Re: Dan Kaminsky
3 works, but offers zero protection against 'kaminsky spoofing the root' since you can't fold the case of 123456789.. And the root is the goal. Good point. 5) Download your own copy of the root zone every few days from http://www.internic.net/domain/, check the signature if you can find the signing key for 289FE7AD, and use that rather than the public roots. 6) EDNS0 PING, if you think anyone else will implement it R's, John
Re: DNS hardening, was Re: Dan Kaminsky
On 8/5/09 11:38 AM, Skywing wrote: That is, of course, assuming that SCTP implementations someday clean up their act a bit. I'm not so sure I'd suggest that they're really ready for prime time at this point. SCTP DNS would be intended for ISPs validating DNS where there would be fewer issues regarding SOHO routers. It seems likely DNS will require some kernel adjustments to support persistent SCTP. SCTP has been providing critical SS7 and H.248.1 services for many years now, where TCP would not be suitable. FreeBSD 7 represents a solid SCTP reference implementation. SCTP has far fewer issues going to homes connected via IPv6. -Doug
Re: DNS hardening, was Re: Dan Kaminsky
On 8/5/09 11:31 AM, Roland Dobbins wrote: On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote: Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. Can you elaborate on this (or are you referring to removing the spoofing vector?)? SCTP is able to simultaneously exchange chunks (DNS messages) over an association. Initialization of associations can offer alternative servers for immediate fail-over, which might be seen as means to arrange anycast style redundancy. Unlike TCP, resource commitments are only retained within the cookies exchanged. This avoids consumption of resources for tracking transaction commitments for what might be spoofed sources. Confirmation of the small cookie also offers protection against reflected attacks by spoofed sources. In addition to source validation, the 32 bit verification tag and TSN would add a significant amount of entropy to the DNS transaction ID. The SCTP stack is able to perform the housekeeping needed to allow associations to persist beyond single transaction, nor would there be a need to push partial packets, as is needed with TCP. -Doug
Re: DNS hardening, was Re: Dan Kaminsky
On Wed, Aug 5, 2009 at 5:24 PM, Douglas Otisdo...@mail-abuse.org wrote: On 8/5/09 11:31 AM, Roland Dobbins wrote: On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote: Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. Can you elaborate on this (or are you referring to removing the spoofing vector?)? SCTP is able to simultaneously exchange chunks (DNS messages) over an association. Initialization of associations can offer alternative servers for immediate fail-over, which might be seen as means to arrange anycast style redundancy. Unlike TCP, resource commitments are only retained within the cookies exchanged. This avoids consumption of resources for tracking transaction commitments for what might be spoofed sources. Confirmation of the small cookie also offers protection against reflected attacks by spoofed sources. In addition to source validation, the 32 bit verification tag and TSN would add a significant amount of entropy to the DNS transaction ID. The SCTP stack is able to perform the housekeeping needed to allow associations to persist beyond single transaction, nor would there be a need to push partial packets, as is needed with TCP. and state-management seems like it won't be too much of a problem on that dns server... wait, yes it will.
Re: DNS hardening, was Re: Dan Kaminsky
On Wed, 5 Aug 2009 15:07:30 -0400 (EDT) John R. Levine jo...@iecc.com wrote: 5 is 'edns ping', but it was effectively blocked because people thought DNSSEC would be easier to do, or demanded that EDNS PING (http://edns-ping.org) would offer everything that DNSSEC offered. I'm surprised you failed to mention http://dnscurve.org/crypto.html, which is always brought up, but never seems to solve the problems mentioned. dnscurve looks like a swell idea, but I wouldn't put it in the category of a hack as straightforward as the ones I listed. Also, at this point there appears to be neither code nor an implementable spec available since Dan is still fiddling with it. As I understand it, dnscurve protects transmissions, not objects. That's not the way DNS operates today, what with N levels of cache. It may or may not be better, but it's a much bigger delta to today's systems and practices than DNSSEC is. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: DNS hardening, was Re: Dan Kaminsky
On 8/5/09 2:49 PM, Christopher Morrow wrote: and state-management seems like it won't be too much of a problem on that dns server... wait, yes it will. DNSSEC UDP will likely become problematic. This might be due to reflected attacks, fragmentation related congestion, or packet loss. When it does, TCP fallback will tried. TCP must retain state for every attempt to connect, and will require significantly greater resources for comparable levels of resilience. SCTP instead uses cryptographic cookies and the client to retain this state information. SCTP can bundle several transactions into a common association, which reduces overhead and latency compared against TCP. SCTP ensures against source spoofed reflected attacks or related resource exhaustion. TCP or UDP does not. Under load, SCTP can redirect services without using anycast. TCP can not. -Doug
Re: DNS hardening, was Re: Dan Kaminsky
On Wed, Aug 5, 2009 at 6:53 PM, Douglas Otisdo...@mail-abuse.org wrote: On 8/5/09 2:49 PM, Christopher Morrow wrote: and state-management seems like it won't be too much of a problem on that dns server... wait, yes it will. DNSSEC UDP will likely become problematic. This might be due to reflected attacks, fragmentation related congestion, or packet loss. When it does, TCP because all of these problems aren't already problems today? how is dnssec adding to this? or is your premise that dnssec adds to it because it requires edns0 and larger responses? fallback will tried. TCP must retain state for every attempt to connect, ask worldnic how well that works... edns0 exists (for at least) the sidestep of truncate and use tcp. and will require significantly greater resources for comparable levels of resilience. Do you really think that dns in the future is going to move to mostly TCP based transport? do you know what added latency that will be for all clients which switch? What about handling more stateful requests on what today are stateless systems? (f-root-style anycasted pods of authoritative resolvers) SCTP instead uses cryptographic cookies and the client to retain this state information. SCTP can bundle several transactions into a common association, which reduces overhead and latency compared against TCP. SCTP great... which internet scale applications use SCTP today? Which loadbalancers are prepared to deal with this 'new' requirement? ensures against source spoofed reflected attacks or related resource exhaustion. TCP or UDP does not. Under load, SCTP can redirect services how does SCTP ensure against spoofed or reflected attacks? without using anycast. TCP can not. explain your assertions please... these seem like overly broad marketing slides which may be truthful in a corner-case but under wide deployment aren't going to work in this manner. -Chris
