OK, so we need to have some appropriate language here in the threats document.
In particular we need to be aware that this sort of attack might be performed as a DDoS attack. The only solution to this sort of thing is going to be to find a way of suppressing DDoS type traffic, in particular spoofed source address packets. This is not very hard for ISPs to do, if a machine is generating reams of spoofed source address data then it has been botted and should be either refused service or moved to an isolation network. > -----Original Message----- > From: william(at)elan.net [mailto:[EMAIL PROTECTED] > Sent: Monday, February 27, 2006 11:19 AM > To: Hallam-Baker, Phillip > Cc: [email protected] > Subject: RE: [ietf-dkim] Threats Issue - Large DNS records > make servers targets for spoofed source amplification attacks abuse > > > I think you misunderstood what I said. DKIM does not cause > any greater issues for "misconfigured systems" (i.e. public > dns servers that allow recursive queries) that already exist. > But it does make any dns server that deploys large DKIM > records just as good for use in amplification attacks as > those "misconfigured systems" that do allow recursion. > > On Mon, 27 Feb 2006, Hallam-Baker, Phillip wrote: > > > As a matter of policy it is a bad idea to attempt to > architect around > > misconfigured systems. > > > > This should probably be mentioned in threats but the only long term > > fix here is for recursive DNS servers that accept unrestricted, > > unauthenticated requests to have code in them to make sure they are > > not doing this sort of thing. > > > >> From a tactical perspective amplified DNS attacks are > vastly easier > >> to > > control than a random spoofed source attack, simply drop > the traffic > > from the offending sites which will in any case be seeing a > heavy load. > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> william(at)elan.net > >> Sent: Monday, February 27, 2006 10:46 AM > >> To: [email protected] > >> Subject: [ietf-dkim] Threats Issue - Large DNS records > make servers > >> targets for spoofed source amplification attacks abuse > >> > >> > >> There have been a lot of discussions going on in the last > few days at > >> NANOG and other dns operations lists that are related to issue of > >> public recursive dns servers being used to amplify an attacks: > >> http://www.gossamer-threads.com/lists/nanog/users/89657 > >> > >> http://lists.oarci.net/pipermail/dns-operations/2006-February/ > >> thread.html > >> > >> The general description of the problem is that bad guys > are sending > >> spoofed udp packets to servers in a way so that the servers would > >> send data (to spoofed source) that is considerably larger then the > >> original request - thus the amplification. For more > information, you > >> may want to read > >> http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf > >> > >> In current case with DNS abuse documented above, most (almost > >> all) dns servers only have records that a small and so the servers > >> are not good targets for any significant amplification. So > attackers > >> are basically poisoning recursive nameservers with their own large > >> data as a way to get them to become good targets and good > amplifiers > >> - this has been quite successful and is currently major > issue for dns > >> operations and security folks. > >> > >> Getting back to this group work - you are expecting to introduce > >> large DNS records as a mainstream for many dns servers. This would > >> make such servers a great target for use in amplification attacks > >> even if those servers are not configured to do recursion. > This is bad > >> and potential for such an attack and abuse for anyone > using DKIM must > >> be documented and it must be made clear that servers with DKIM > >> records may become targets for use in DNS amplification > attacks. In > >> fact the larger the record you put in dns, the better > target for such > >> an attack it becomes! > >> > >> Note that there is currently no good solution to this > issue for UDP > >> protocols (most either do TCP-like session establishment before > >> sending large data or they are engineered so that responses can be > >> limited with ACLs to only specified group of systems, i.e. > local LAN > >> in case of DHCP). > >> My personal view is that if there is a way to avoid > introducing large > >> records into UDP one query-response situation, that it absolutely > >> must be done. So I would see as best solution a > replacement of public > >> keys in dns with an approach that uses a lot smaller > fingerprints in > >> DNS. > >> > >> -- > >> William Leibzon > >> Elan Networks > >> [EMAIL PROTECTED] > >> _______________________________________________ > >> NOTE WELL: This list operates according to > >> http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
