Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 17, 2014, at 6:44 AM, Tony Finch d...@dotat.at wrote: Jared Mauch ja...@puck.nether.net wrote: I can point anyone interested to the place in the bind source to force it to reply to all UDP queries with TC=1 to force TCP. should be safe on any authority servers, as a recursive server should be able to do outbound TCP. However see http://www.potaroo.net/ispcol/2013-09/dnstcp.html Yes, I’m aware of the excellent work by Geoff on this topic. There are many things that could be done, including the nonce (or similar) approach NTP took with MONLIST vs MRULIST. Perhaps it’s something like this: http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 - Jared
Re: trivial changes to DNS (was: OpenNTPProject.org)
Jared Mauch ja...@puck.nether.net wrote: I can point anyone interested to the place in the bind source to force it to reply to all UDP queries with TC=1 to force TCP. should be safe on any authority servers, as a recursive server should be able to do outbound TCP. However see http://www.potaroo.net/ispcol/2013-09/dnstcp.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
trivial changes to DNS (was: OpenNTPProject.org)
On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting EDNS0 universally deployed in under 10 years. Right? A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 2:27 PM, Andrew Sullivan asulli...@dyn.com wrote: On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting EDNS0 universally deployed in under 10 years. Right? Perhaps the problem with EDNS0 is exactly its backward compatibility. A parallel protocol adopted by the usual suspects of authoritative and recursive names servers that at some point becomes required for query volumes larger than x qps could account for most of name resolution on the planet in much less than 10 years. Rubens
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:27 AM, Andrew Sullivan asulli...@dyn.com wrote: On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting EDNS0 universally deployed in under 10 years. Right? pretty easy to believe that quic would be helpful right? especially if you were interested in: 1) keeping resource utilization down/same on dns servers 2) rtt and latency impacts of extra rtt on upper layer protocols 3) the Xmillions of embedded devices that end users rely upon for dns in their homes seems totally feasible. -chris
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. seems totally feasible. Certainly, it would be possible to standardize it. Whether it would be trivial to get it deployed is quite a different matter. The evidence to date is that there is a very, very long tail in any change having to do with the DNS. We are still, to this day, fighting with sysadmins who are convinced that firewall rules on TCP/53 are perfectly reasonable, even though DNS _always_ used TCP. People who believe there are going to be easy fixes to the issues coming from DNS are deluding themselves. A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. seems totally feasible. Certainly, it would be possible to standardize it. Whether it would be trivial to get it deployed is quite a different matter. The evidence to date is that there is a very, very long tail in any change having to do with the DNS. We are still, to this day, fighting with sysadmins who are convinced that firewall rules on TCP/53 are perfectly reasonable, even though DNS _always_ used TCP. People who believe there are going to be easy fixes to the issues coming from DNS are deluding themselves. I totally agree... I was actually joking in my last note :( sorry for not adding the :) as requisite in email. So... what other options are there to solve the larger problem of: Some service is running on a public host, and it can be used to attack a third party where in all of these cases the third party is someone who's address has been spoofed in the src-address of a packet. -chris
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: I totally agree... I was actually joking in my last note :( sorry for not adding the :) as requisite in email. I'm sorry my humour is now so impaired from reading 1net and other such things that I didn't figure it out! So... what other options are there to solve the larger problem […] If I knew, I'd run out an implement it rather than talk about it! A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 9:08 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: I totally agree... I was actually joking in my last note :( sorry for not adding the :) as requisite in email. I'm sorry my humour is now so impaired from reading 1net and other such things that I didn't figure it out! So... what other options are there to solve the larger problem […] If I knew, I'd run out an implement it rather than talk about it! A Well. These reflection attacks have something in common. The big ones (chargen, dns, ntp) are all IPv4 UDP. And these are all *very* big. I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I hope QUIC does not stay on UDP, as it may find itself cut off at the legs. CB -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I won't speak about the other protocols, but I encourage you to turn off DNS using UDP over IPv4 in your network and report back to us all on how that works out. You may not be able to do it by email, however. Best regards, A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 9:31 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I won't speak about the other protocols, but I encourage you to turn off DNS using UDP over IPv4 in your network and report back to us all on how that works out. You may not be able to do it by email, however. I white listed google and facebooks auth servers, so its cool. CB Best regards, A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 11:39:46AM -0500, Andrew Sullivan wrote: On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. seems totally feasible. Certainly, it would be possible to standardize it. Whether it would be trivial to get it deployed is quite a different matter. The evidence to date is that there is a very, very long tail in any change having to do with the DNS. We are still, to this day, fighting with sysadmins who are convinced that firewall rules on TCP/53 are perfectly reasonable, even though DNS _always_ used TCP. I can point anyone interested to the place in the bind source to force it to reply to all UDP queries with TC=1 to force TCP. should be safe on any authority servers, as a recursive server should be able to do outbound TCP. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: trivial changes to DNS (was: OpenNTPProject.org)
On 16 Jan 2014, at 17:30 , Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I won't speak about the other protocols, but I encourage you to turn off DNS using UDP over IPv4 in your network and report back to us all on how that works out. You may not be able to do it by email, however. Why not? .org and nanog.org have IPv6-enabled DNS, mailman.nanog.org has an IPv6 address. What else do you need to reply to this list? — Bjoern A. Zeeb ? ??? ??? ??: '??? ??? ?? ??? ?? ?? ??? ??? ??? ? ? ?? ?? ? ', ? ?, ??? ? ?? ?, ?.???
Re: trivial changes to DNS (was: OpenNTPProject.org)
On (2014-01-16 09:19 -0800), Cb B wrote: I hope QUIC does not stay on UDP, as it may find itself cut off at the legs. Any new L4 would need to support both flavours, over UDP and native. Over UDP is needed to be deployable right now and be working to vast majority of the end users. Native-only would present chicken and egg problem, goog/fb/amzn/msft etc won't add support to it, because failure rate is too high, and stateful box vendors won't add support, because no customer demand. And what becomes to deployment pace, good technologies which give benefits to end users can and have been deployed very fast. IPv6 does not give benefit to end users, EDNS does not give benefit to end users. QUIC/MinimaLT/IETF-transport-standardized-version would give benefit to end users, all persistent connections like ssh would keep running when you jump between networks. You could in your homeserver specifically allow /you/ to connect to any service, regardless of your IP address, because key is your identity, not your IP address. (So sort of LISPy thing going on here, we'd make IP more low-level information which it should be, it wouldn't be identity anymore) Parity packets have potential to give much better performance in packet loss conditions. Packet pacing seems much better on fast to slow file transfers. -- ++ytti
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 10:16 AM, Saku Ytti s...@ytti.fi wrote: On (2014-01-16 09:19 -0800), Cb B wrote: I hope QUIC does not stay on UDP, as it may find itself cut off at the legs. Any new L4 would need to support both flavours, over UDP and native. Over UDP is needed to be deployable right now and be working to vast majority of the end users. Native-only would present chicken and egg problem, goog/fb/amzn/msft etc won't add support to it, because failure rate is too high, and stateful box vendors won't add support, because no customer demand. And what becomes to deployment pace, good technologies which give benefits to end users can and have been deployed very fast. IPv6 does not give benefit to end users, EDNS does not give benefit to end users. QUIC/MinimaLT/IETF-transport-standardized-version would give benefit to end users, all persistent connections like ssh would keep running when you jump between networks. You could in your homeserver specifically allow /you/ to connect to any service, regardless of your IP address, because key is your identity, not your IP address. (So sort of LISPy thing going on here, we'd make IP more low-level information which it should be, it wouldn't be identity anymore) Parity packets have potential to give much better performance in packet loss conditions. Packet pacing seems much better on fast to slow file transfers. -- ++ytti Then let's go all the way with ILNP. I like that. CB
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 12:55:18PM -0500, Jared Mauch wrote: I can point anyone interested to the place in the bind source to force it to reply to all UDP queries with TC=1 to force TCP. should be safe on any authority servers, as a recursive server should be able to do outbound TCP. You could also (and for most cases, I recommend you do) enable the Response Rate Limiting patches available on most of the open-source authoritative servers. Sorry I didn't think to mention it earlier. I thought everyone already knew that. But it does appear to help. A -- Andrew Sullivan Dyn, Inc. asulli...@dyn.com v: +1 603 663 0448
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 10:48 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan asulli...@dyn.com wrote: On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: So... what other options are there to solve the larger problem of: Some service is running on a public host, and it can be used to attack a third party where in all of these cases the third party is someone who's address has been spoofed in the src-address of a packet. Standardizing some UDP service-neutral PRE-Authentication system comes to mind; operating at the host level, independent of the various services, requiring the client to perform at least as much work as the response packet. E.g. Fwknop Single-Packet Authentication/Port-Knocking Style The application doesn't see any UDP packets from a source:port number pair, until a source address authenticity event occurs, for that source ip:port number pair. Say instead of port knocking though, the client is required to estimate the size of the response to its first round trip of UDP request messages. Then the client's UDP stack must construct and send a Hashcash proof of work, of sufficient difficulty based on the estimated query plus response size, up to the first full round trip; containing a message digest of the first UDP packet the client will send, before sending the packet, or it will be silently discarded. An out-of-band reply will come back to the claimed source, that the client souce IP:Port has to acknowledge within 5 packets. Once the out-of-band reply is acknowledged, the source is confirmed not to be spoofed. UDP response packets and new queries above the estimated initial reply size or after the 5th packet are delayed until definitive confirmation or silently dropped, instead of returned to the claimed source. -chris -- -JH
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, 16 Jan 2014 13:35:00 -0600, Jimmy Hess said: Then the client's UDP stack must construct and send a Hashcash proof of work, of sufficient difficulty based on the estimated query plus response size, up to the first full round trip; containing a message digest of the first UDP packet the client will send, before sending the packet, or it will be silently discarded. An out-of-band reply will come back to the claimed source, that the client souce IP:Port has to acknowledge within 5 packets. Once the out-of-band reply is acknowledged, the source is confirmed not to be spoofed. How is this any better than a TCP 3-packet handshake with syncookies? pgpBLWmPZkfD_.pgp Description: PGP signature
Re: trivial changes to DNS (was: OpenNTPProject.org)
We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What would your fix be for the Chargen and SNMP protocols? -- Mark Andrews, ISC -- -JH
Re: trivial changes to DNS (was: OpenNTPProject.org)
In message caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com , Jimmy Hess writes: On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What thousand protocols? There really are very few protocols widely deployed on top of UDP. What would your fix be for the Chargen and SNMP protocols? Chargen is turned off on many platforms by default. Turn it off on more. Chargen loops are detectable. SNMP doesn't need to be open to the entire world. It's not like authoritative DNS servers which are offering a service to everyone. New UDP based protocols need to think about how to handle spoof traffic. You look at providing extending routing protocols to provide information about the legitimate source addresses that may be emitted over a link. SIDR should help here with authentication of the data. This will enable better automatic filtering to be deployed. You continue to deploy BCP38. Every site that deploys BCD is one less site where owened machines can be used to launch attacks from. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: trivial changes to DNS (was: OpenNTPProject.org)
On Jan 16, 2014 5:10 PM, Mark Andrews ma...@isc.org wrote: In message caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com , Jimmy Hess writes: On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What thousand protocols? There really are very few protocols widely deployed on top of UDP. What would your fix be for the Chargen and SNMP protocols? Chargen is turned off on many platforms by default. Turn it off on more. Chargen loops are detectable. Somebody has it on. I can confirm multi gb/s size chargen attacks going on regularly. I agree. More chargen off, more bcp 38, but ...yeh.. chargen is a big problem here and now CB SNMP doesn't need to be open to the entire world. It's not like authoritative DNS servers which are offering a service to everyone. New UDP based protocols need to think about how to handle spoof traffic. You look at providing extending routing protocols to provide information about the legitimate source addresses that may be emitted over a link. SIDR should help here with authentication of the data. This will enable better automatic filtering to be deployed. You continue to deploy BCP38. Every site that deploys BCD is one less site where owened machines can be used to launch attacks from. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: trivial changes to DNS (was: OpenNTPProject.org)
In message CAD6AjGTE-raK1AnFha+tz+WQGAuUrB7Pr0vfc3J=qnhfu63...@mail.gmail.com , Cb B writes: On Jan 16, 2014 5:10 PM, Mark Andrews ma...@isc.org wrote: In message caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com , Jimmy Hess writes: On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote: We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What thousand protocols? There really are very few protocols widely deployed on top of UDP. What would your fix be for the Chargen and SNMP protocols? Chargen is turned off on many platforms by default. Turn it off on more. Chargen loops are detectable. Somebody has it on. I can confirm multi gb/s size chargen attacks going on regularly. I agree. More chargen off, more bcp 38, but ...yeh.. chargen is a big problem here and now So go and *report* the traffic streams so that chargen service can be turned off or if the box doesn't support that, the box is replaced / filter. I don't know anyone that *needs* chargen turned on all the time. Most *never* need it to be turned on. India was just declared polio free. Fixing chargen is easier than that. Step 1. make sure you do not have chargen sources. Step 2. report traffic. Step 3. stop accepting all traffic to/from the if step 2 does not help. Mark CB SNMP doesn't need to be open to the entire world. It's not like authoritative DNS servers which are offering a service to everyone. New UDP based protocols need to think about how to handle spoof traffic. You look at providing extending routing protocols to provide information about the legitimate source addresses that may be emitted over a link. SIDR should help here with authentication of the data. This will enable better automatic filtering to be deployed. You continue to deploy BCP38. Every site that deploys BCD is one less site where owened machines can be used to launch attacks from. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org --047d7bfd030c59198804f02057ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable p dir=3Dltrbr On Jan 16, 2014 5:10 PM, quot;Mark Andrewsquot; lt;a href=3Dmailto:mar= k...@isc.orgma...@isc.org/agt; wrote:br gt;br gt;br gt; In message lt;a href=3Dmailto:CAAAwwbVJKEok-ydwEQd4cowJ9qAAtbC8mKqw= nxrsud55%2bh9...@mail.gmail.comCAAAwwbVJKEok-ydwEQd4cowJ9qAAtbC8mKqwNXrsu= d55+h9...@mail.gmail.com/agt;br gt; , Jimmy Hess writes:br gt; gt; On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews lt;a href=3Dmail= to:ma...@isc.orgma...@isc.org/agt; wrote:br gt; gt;br gt; gt; gt; We don#39;t need to change transport, we don#39;t need to = port knock. =A0Webr gt; gt; gt; just need to implementent a slightly modified dns cookies wh= ichbr gt; gt; gt; reminds me that I need to review Donald Eastlake#39;s new d= raft to be.br gt; gt; gt;br gt; gt;br gt; gt; But a change to DNS doesn#39;t solve the problem for the other t= housand or sobr gt; gt; UDP-based protocols.br gt;br gt; What thousand protocols? =A0There really are very few protocols widely= br gt; deployed on top of UDP.br gt;br gt; gt; What would your fix be for the Chargen and SNMP protocols?br gt;br gt; Chargen is turned off on many platforms by default. =A0Turn it offbr gt; on more. =A0Chargen loops are detectable.br gt;/p p dir=3DltrSomebody has it on. /p p dir=3DltrI can confirm multi gb/s size chargen attacks going on regul= arly. /p p dir=3DltrI agree. More chargen off, more bcp 38, but ...yeh.. chargen= is a big problem here and now/p p dir=3DltrCB/p p dir=3Dltrgt; SNMP doesn#39;t need to be open to the entire world. = =A0It#39;s not likebr gt; authoritative DNS servers which are offering a service to everyone.br= gt;br gt; New UDP based protocols need to think about how to handle spoofbr gt; traffic.br gt;br gt; You look at providing extending routing protocols to providebr gt; information about the legitimate source addresses that may be emitted= br gt; over a link. =A0SIDR should help here with authentication of the data.= br gt; This will enable better automatic filtering to be deployed.br gt;br gt; You continue to deploy BCP38. =A0Every site that deploys BCD is onebr= gt; less site where owened machines can be used to launch attacks from.br= gt;br gt; Markbr gt; --br gt; Mark Andrews, ISCbr gt; 1 Seymour St., Dundas Valley, NSW 2117, Australiabr gt; PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: a hr= ef=3Dmailto:ma...@isc.org;ma...@isc.org/abr gt;br /p
