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.
 We work on `some measurements` that should clarify the severity and
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.


}}}