DNS/FCP/hayaについて、ここに記述してください。

/unbound-option

https://lists.dns-oarc.net/pipermail/dns-operations/2013-September/010681.html 

[dns-operations] DNS Attack over UDP fragmentation
Haya Shulman haya.shulman at gmail.com
Fri Sep 6 01:02:59 UTC 2013

    Previous message (by thread): [dns-operations] DNS Attack over UDP fragmentation
    Next message (by thread): [dns-operations] DNS Attack over UDP fragmentation
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I hope you do not mind me joining in.

FYI, (a short) updated version of the paper is enclosed.

I do not plan to release a PoC, but I will be happy to discuss questions and challenges pertaining to the implementation/evaluation. The results reported in the paper are based on evaluation of attacks against responses from real name servers, and (up-to-date) Bind and Unbound resolvers that I ran in a lab.

applicability of the attack. However, the main problem is lack of time, and all these travels in tandem with hotels' networks do not speed it up. So unfortunately, it is taking me longer than we were hoping for. 

Please notice that I am not urging anyone to patch :-) and I do not promote
any company, and do not have the required time to visit vendors around the
globe and demonstrate the attack.
We disclosed the work to raise awareness to the vulnerability, and the
paper is available. I think you _should_ patch and not wait till the
exploit is out there.

IMHO DNSSEC is a long term solution and I think that more research is
required to address different obstacles towards adoption thereof, such as
problems with large UDP packets, fragmentation, failures due to fall back
to TCP, lack of motivation due to interoperability problems and abuse for
DDoS, and more... Here is (a bit outdated) report on DNSSEC deployment
challenges study
http://eprint.iacr.org/2013/254
we plan to upload an updated version soon.

Merely deploying DNSSEC as the only solution may have an adverse impact on DNS functionaliy, and functionality and availability of other applications that depend on DNS. I would recommend short term patched (that we recommend in the paper) in the meanwhile, and addressing the deployment challenges of DNSSEC.

BTW, next week I am in London (presenting our new cache poisoning work at ESORICS), so, if anyone is in the neighbourhood and wants to chat - feel free to drop me a line. The work at ESORICS shows new techniques to deanonymise and cache poison resolvers behind patched upstream resolvers. Following [Kaminsky2008] one of the recommendations of the experts was either to patch or to configure a patched upstream resolver (most notably recommending OpenDNS). BTW, we checked and found many networks to be vulnerable to these new attacks against resolver-behind-upstream. So if you rely only on a patched upstream for your resolver's security, you may want to consider adopting additional mechanisms...

-- Best Regards, S.H.

}}}