Preventing Use of Recursive Nameservers in Reflector Attacks
draft-ietf-dnsop-reflectors-are-evil-06

[Ballot discuss]
[This is a yet another revised discuss; after discussion with Paul Hoffman, the
issues I inherited from Sam are now considered resolved.  We are now down to one
simple issue.]

The security considerations sections correctly states that  it "does not create any new
security issues", but the three techniques proposed by the document do have security
issues.  These should be mentioned.  For TSIG, RFC 2845 already provides a reasonable
description of the security considerations, so a pointer should suffice.  For SIG(0), the
Security Considerations of RFC 2931 and 2535 apply, and should be noted.  The security
considerations for 2931 and 2535 seem thin, I would encourage teh authors to consider
whether they should augment those considerations.  (I will clear based on a reference,
though.)

[Ballot discuss]
[This is a yet another revised discuss; Most of the issues raised in my discuss and some of
Sam's were resolved in the -05 draft]

The security considerations sections correctly states that  it "does not create any new
security issues", but the three techniques proposed by the document do have security
issues.  These should be mentioned.  For TSIG, RFC 2845 already provides a reasonable
description of the security considerations, so a pointer should suffice.  For SIG(0), the
Security Considerations of RFC 2931 and 2535 (which are included by reference) seem
really thin - perhaps the authors could do better here.  We should also acknowledge the
limitations and vulnerabilities of IP address filtering.

From Sam Hartman's discuss:

Paul Hoffman brought up a last call comment on the ietf list; I
believe this comment needs to be addressed.  I support discussing this
issue in the security considerations section.  I don't think we can
take a recommendation for or against using an open recursive name
server for roaming users; I don't see sufficient discussion to support
that either way.  However the recommendation in section 4 is worded in
such a way to allow organizations who have a need to do so to run open
recursive name servers.  I think that's fine and appropriate.  Please
add security considerations text to address Paul's issue without
making a recommendation about whether the practice is advisable.

Obviously factual discussion of the problems of that organizational
choice are appropriate.  Similarly, if you want to argue that my
reading of whether there is a consensus to recommend against this
practice exists I'll listen to your argument.

>The Security Considerations section for this document is much too
>narrow. It ignores one of the main reasons that many organizations
>purposely choose to provide recursive lookup to the public, namely for
>their own roaming users. Without an open, known-good nameserver at a
>fixed address, roaming users need to trust whatever is given to them
>by their ISP at the moment, and it is reasonable for organizations to
>consider this too large of a risk. Unless the organization has a way
>to tunnel DNS queries back to a non-recursive nameserver (such as
>through IPsec), having a recursive nameserver available increases the
>security of their roaming users.
>
>There are two major reasons for an organization to not want roaming
>users to trust locally-assigned DNS servers.
>
>- An attacker might have compromised the DHCP server to which the user
>conntect to point to a compromised DNS server. Although such an
>attacker can also cause the DHCP server to point to a compromised
>next-hop router, it is easier and less detectable for most attackers
>to compromise a DNS server than a router. There are plenty of examples
>where compromised DNS servers lead to spoofing and MITM attacks.
>
>- Some ISPs use DNS servers that purposely do not follow the same good
>practices that the organization uses. In particular, some ISPs have
>used bogus TLDs and name-lookup services to generate revenue.
>
>The Security Considerations section needs to deal with these issues,
>even if they do not change the advice given in section 4.

[Ballot discuss]
[This is a revised discuss; I am assuming Sam's issues in addition to my own as part of
the AD transition.]

I am uncomfortable with the characterization of IP address filtering by the nameserver
as "client authentication".  I do not dispute the applicability of the mechanism, but we
have enough experience with address spoofing to know that we haven't really authenticated
the sending host.

In addition, the document has some helpful words regarding the applicability of the
second and third techniques (incoming interface based selection, and signed queries
respectively) but does not describe when IP address filtering is appropriate.

The document implies that, if widely deployed, ingress filtering would be a complete solution.
I suspect that a variety of other avenues will always exist (exploiting misconfigured dual-homed
systems, for instance) so the techniques listed in Section 4 to limit service to intended
clients will always be needed.

The security considerations sections correctly states that  it "does not create any new
security issues", but the three techniques proposed by the document do have security
issues.  These should be mentioned.  For TSIG, RFC 2845 already provides a reasonable
description of the security considerations, so a pointer should suffice.  For SIG(0), the
Security Considerations of RFC 2931 and 2535 (which are included by reference) seem
really thin - prehaps the authors could do better here.  We should also acknowledge the
limitations and vulnerabilities of IP address filtering.

From Sam Hartman's discuss:

The description of the attack in section 3 is sufficiently hard to
follow that I would have been unable to do so had it not been
presented in detail at the IAB workshop on unwanted traffic.  Start by
using less abbreviations and acronyms and see if that makes it clear
enough that it is easy to follow.

Paul Hoffman brought up a last call comment on the ietf list; I
believe this comment needs to be addressed.  I support discussing this
issue in the security considerations section.  I don't think we can
take a recommendation for or against using an open recursive name
server for roaming users; I don't see sufficient discussion to support
that either way.  However the recommendation in section 4 is worded in
such a way to allow organizations who have a need to do so to run open
recursive name servers.  I think that's fine and appropriate.  Please
add security considerations text to address Paul's issue without
making a recommendation about whether the practice is advisable.

Obviously factual discussion of the problems of that organizational
choice are appropriate.  Similarly, if you want to argue that my
reading of whether there is a consensus to recommend against this
practice exists I'll listen to your argument.

>The Security Considerations section for this document is much too
>narrow. It ignores one of the main reasons that many organizations
>purposely choose to provide recursive lookup to the public, namely for
>their own roaming users. Without an open, known-good nameserver at a
>fixed address, roaming users need to trust whatever is given to them
>by their ISP at the moment, and it is reasonable for organizations to
>consider this too large of a risk. Unless the organization has a way
>to tunnel DNS queries back to a non-recursive nameserver (such as
>through IPsec), having a recursive nameserver available increases the
>security of their roaming users.
>
>There are two major reasons for an organization to not want roaming
>users to trust locally-assigned DNS servers.
>
>- An attacker might have compromised the DHCP server to which the user
>conntect to point to a compromised DNS server. Although such an
>attacker can also cause the DHCP server to point to a compromised
>next-hop router, it is easier and less detectable for most attackers
>to compromise a DNS server than a router. There are plenty of examples
>where compromised DNS servers lead to spoofing and MITM attacks.
>
>- Some ISPs use DNS servers that purposely do not follow the same good
>practices that the organization uses. In particular, some ISPs have
>used bogus TLDs and name-lookup services to generate revenue.
>
>The Security Considerations section needs to deal with these issues,
>even if they do not change the advice given in section 4.

[Ballot comment]
The advice in this draft seems to suggest that it not using ingress filtering is what is evil, not that reflectors are evil. But given the word evil does not seem like it will show up in the final RFC, I don't think this matters.

I'm having a hard time finding the discussion leading to the consensus that this is the best design.  Let me separate this into a bunch of points for that I would like to talk about, and once we have discussed them, I will remove them or turn them into an actionable discuss.

As has been pointed out in some emails, it seems like a reasonable assumption there will be plenty of large DNS records on authoritative servers without the attacker needing to create them. If this is not the case that there will be records larger than X, then the simple solution seems to be to not allow  records larger than X. Given this, I am very uncomfortable with the advice of turning off recursive name service for non authenticated clients. I am mostly uneasy with this because none of the schemes for authenticating a client look like they will meet a large percentage of the deployment use cases.

Moving to the topic of using reflectors in dos attacks, in general I think we have seen three approaches to solving this: 1) block spoofed requests 2) return route checks, and 3) don't allow amplification.

The advice of following BCP 38 is no doubt good advice but we have been recommending that for a very long time and have not made much progress. We could delve into why it is hard to do BCP 38 (even assuming all the equipment supports it) or why the people that need to deal with the pain of doing it do not have many incentives to actually do it but regardless of all that, I doubt that this document saying people should do BCP 38 will really up the rate of adoption of BCP 38 very much. That makes me wonder why this solution over other ones. This takes me on to return route checks.

The trivial return route check would be use TCP and clearly there is experience with this and it does not work thought some percentage of firewalls. Now we could argue about if the firewalls were misconfigured or not but what about a very pragmatic approach of for large  responses, trying a UDP based liveness check. I tried to find a record of discussion about this but could not. I'm curios to know if this ideas was considered and thrown out in favor of BCP 38.

The final approach sounds very lame at first glance but would simply be to not allow large repossess that were say more than twice the size of the request and allow the client to pad out requests that the client knew would result in large responses. Again, I'm curios if any ideas were considered and discarded for BCP 38.

Would some combination of any of these make sense?

[Ballot comment]
Other ADs have already entered Discuss positions that cover my concerns.
  I'm confident that resolution of those positions will resolve my
  concerns.

[Ballot comment]
I support Tim's concern with terminology, and the gist of Paul Hoffman's
last call comment.

However, the key recommendation of this draft seems important and
appropriate.

The acronym "SOHO" is used without being expanded on first use.

[Ballot discuss]
I'm having a hard time finding the discussion leading to the consensus that this is the best design.  Let me separate this into a bunch of points for that I would like to talk about, and once we have discussed them, I will remove them or turn them into an actionable discuss.

As has been pointed out in some emails, it seems like a reasonable assumption there will be plenty of large DNS records on authoritative servers without the attacker needing to create them. If this is not the case that there will be records larger than X, then the simple solution seems to be to not allow  records larger than X. Given this, I am very uncomfortable with the advice of turning off recursive name service for non authenticated clients. I am mostly uneasy with this because none of the schemes for authenticating a client look like they will meet a large percentage of the deployment use cases.

Moving to the topic of using reflectors in dos attacks, in general I think we have seen three approaches to solving this: 1) block spoofed requests 2) return route checks, and 3) don't allow amplification.

The advice of following BCP 38 is no doubt good advice but we have been recommending that for a very long time and have not made much progress. We could delve into why it is hard to do BCP 38 (even assuming all the equipment supports it) or why the people that need to deal with the pain of doing it do not have many incentives to actually do it but regardless of all that, I doubt that this document saying people should do BCP 38 will really up the rate of adoption of BCP 38 very much. That makes me wonder why this solution over other ones. This takes me on to return route checks.

The trivial return route check would be use TCP and clearly there is experience with this and it does not work thought some percentage of firewalls. Now we could argue about if the firewalls were misconfigured or not but what about a very pragmatic approach of for large  responses, trying a UDP based liveness check. I tried to find a record of discussion about this but could not. I'm curios to know if this ideas was considered and thrown out in favor of BCP 38.

The final approach sounds very lame at first glance but would simply be to not allow large repossess that were say more than twice the size of the request and allow the client to pad out requests that the client knew would result in large responses. Again, I'm curios if any ideas were considered and discarded for BCP 38.

Would some combination of any of these make sense?

[Ballot discuss]
I'm having a hard time finding the discussion leading to the consensus that this is the best design.  Let me separate this into a bunch of points for that I would like to talk about, and once we have discussed them, I will remove them or turn them into an actionably discuss.

As has been pointed out in some emails, it seems like a reasonable assumption there will be plenty of large DNS records on authoritative servers without the attacker needing to create them. If this is not the case that there will be records larger than X, then the simple solution seems to be to not allow  records larger than X. Given this, I am very uncomfortable with the advice of turning off recursive name service for non authenticated clients. I am mostly uneasy with this because none of the schemes for authenticating a client look like they will meet a large percentage of the deployment use cases.

Moving to the topic of using reflectors in dos attacks, in general I think we have seen three approaches to solving this: 1) block spoofed requests 2) return route checks, and 3) don't allow amplification.

The advice of following BCP 38 is no doubt good advice but we have been recommending that for a very long time and have not made much progress. We could delve into why it is hard to do BCP 38 (even assuming all the equipment supports it) or why the people that need to deal with the pain of doing it do not have many incentives to actually do it but regardless of all that, I doubt that this document saying people should do BCP 38 will really up the rate of adoption of BCP 38 very much. That makes me wonder why this solution over other ones. This takes me on to return route checks.

The trivial return route check would be use TCP and clearly there is experience with this and it does not work thought some percentage of firewalls. Now we could argue about if the firewalls were misconfigured or not but what about a very pragmatic approach of for large  responses, trying a UDP based liveness check. I tried to find a record of discussion about this but could not. I'm curios to know if this ideas was considered and thrown out in favor of BCP 38.

The final approach sounds very lame at first glance but would simply be to not allow large repossess that were say more than twice the size of the request and allow the client to pad out requests that the client knew would result in large responses. Again, I'm curios if any ideas were considered and discarded for BCP 38.

Would some combination of any of these make sense?

[Ballot comment]
The advice in this draft seems to suggest that it not using ingress filtering is what is evil, not that reflectors are evil. But given the word evil does not seem like it will show up in the final RFC, I don't think this matters.

[Ballot discuss]
I am uncomfortable with the characterization of IP address filtering by the nameserver
as "client authentication".  I do not dispute the applicability of the mechanism, but we
have enough experience with address spoofing to know that we haven't really authenticated
the sending host.

In addition, the document has some helpful words regarding the applicability of the
second and third techniques (incoming interface based selection, and signed queries
respectively) but does not describe when IP address filtering is appropriate.

The document implies that, if widely deployed, ingress filtering would be a complete solution.
I suspect that a variety of other avenues will always exist (exploiting misconfigured dual-homed
systems, for instance) so the techniques listed in Section 4 to limit service to intended
clients will always be needed.

The security considerations sections correctly states that  it "does not create any new
security issues", but the three techniques proposed by the document do have security
issues.  These should be mentioned.  For TSIG, RFC 2845 already provides a reasonable
description of the security considerations, so a pointer should suffice.  For SIG(0), the
Security Considerations of RFC 2931 and 2535 (which are included by reference) seem
really thin - prehaps the authors could do better here.  We should also acknowledge the
limitations and vulnerabilities of IP address filtering.

[Ballot discuss]
I am uncomfortable with the characterization of IP address filtering by the nameserver
as "client authentication".  I do not dispute the applicability of the mechanism, but we
haver enough experience with address spoofing to know that we haven't really authenticated
the sending host.

In addition, the document has some helpful words regarding the applicability of the
second and third techniques (incoming interface based selection, and signed queries
respectively) but does not describe when IP address filtering is appropriate.

The document implies that, if widely deployed, ingress filtering would be a complete solution.
I suspect that a variety of other avenues will always exist (exploiting misconfigured dual-homed
systems, for instance) so the techniques listed in Section 4 to limit service to intended
clients will always be needed.

The security considerations sections correctly states that  it "does not create any new
security issues", but the three techniques proposed by the document do have security
issues.  These should be mentioned.  For TSIG, RFC 2845 already provides a reasonable
description of the security considerations, so a pointer should suffice.  For SIG(0), the
Security Considerations of RFC 2931 and 2535 (which are included by reference) seem
really thin - prehaps the authors could do better here.  We should also acknowledge the
limitations and vulnerabilities of IP address filtering.

[Ballot discuss]
[This is a preliminary discuss; I reserve the right to add to it until the telechat on Thursday.
I wanted to get this issue filed as a discuss so people could think about it.]

The description of the attack in section 3 is sufficiently hard to
follow that I would have been unable to do so had it not been
presented in detail at the IAB workshop on unwanted traffic.  Start by
using less abbreviations and acronyms and see if that makes it clear
enough that it is easy to follow.

Paul Hoffman brought up a last call comment on the ietf list; I
believe this comment needs to be addressed.  I support discussing this
issue in the security considerations section.  I don't think we can
take a recommendation for or against using an open recursive name
server for roaming users; I don't see sufficient discussion to support
that either way.  However the recommendation in section 4 is worded in
such a way to allow organizations who have a need to do so to run open
recursive name servers.  I think that's fine and appropriate.  Please
add security considerations text to address Paul's issue without
making a recommendation about whether the practice is advisable.

Obviously factual discussion of the problems of that organizational
choice are appropriate.  Similarly, if you want to argue that my
reading of whether there is a consensus to recommend against this
practice exists I'll listen to your argument.

>The Security Considerations section for this document is much too
>narrow. It ignores one of the main reasons that many organizations
>purposely choose to provide recursive lookup to the public, namely for
>their own roaming users. Without an open, known-good nameserver at a
>fixed address, roaming users need to trust whatever is given to them
>by their ISP at the moment, and it is reasonable for organizations to
>consider this too large of a risk. Unless the organization has a way
>to tunnel DNS queries back to a non-recursive nameserver (such as
>through IPsec), having a recursive nameserver available increases the
>security of their roaming users.
>
>There are two major reasons for an organization to not want roaming
>users to trust locally-assigned DNS servers.
>
>- An attacker might have compromised the DHCP server to which the user
>conntect to point to a compromised DNS server. Although such an
>attacker can also cause the DHCP server to point to a compromised
>next-hop router, it is easier and less detectable for most attackers
>to compromise a DNS server than a router. There are plenty of examples
>where compromised DNS servers lead to spoofing and MITM attacks.
>
>- Some ISPs use DNS servers that purposely do not follow the same good
>practices that the organization uses. In particular, some ISPs have
>used bogus TLDs and name-lookup services to generate revenue.
>
>The Security Considerations section needs to deal with these issues,
>even if they do not change the advice given in section 4.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Peter Koch (==me) is the Document Shepherd for this document.
I have read the latest version (-04) of the draft and believe it
is ready for consideration by the IESG.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The draft has undergone in-depth review in the DNSOP WG and has
been brought to the attention of various other DNS operational fora.

Reviews are available from the DNSOP archive in response to the WGLC


There are no concerns about the depth or breadth of reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

There are no such concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no IPR or similar issues with this document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The WG had good consensus in favour of the document, its intended
status and the recommendations it makes. Some WG members were
uncomfortable with the focus being constrained to "recursive servers",
leaving open the (ab)use of authoritative servers in similar or other
attack scenarios. Given the state of the art separation of
recursive and authoritative name servers and the particular problem
that triggered writing of this document, the WG supports this
going forward knowing that it does not address all potential
amplification issues caused by large DNS responses.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

The judgement made by the WG to address the specific attack
scenario observed in early 2006 was not supported by all WG members
(see separate note).

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The draft has passed the ID nits test 2.04.12 at
.
This document is aimed at BCP status.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are split into normative/informative and there
are no downrefs.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The document does not require IANA action, which is what the IANA
considerations section says.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document describes ways to prevent the use of recursive
nameservers as reflectors in Denial of Service (DoS) attacks.
It makes recommendations to both operators and vendors (for
default configurations).

Working Group Summary
The document was started in reaction to the "DNS reflection attacks"
widely published in early 2006. While the basic direction was
clear from the beginning, it needed some discussion to agree upon
a recommendation of the more sophisticated and less widely deployed
querier authentication mechanisms (TSIG and SIG(0)).

Document Quality
After the February 2006 DNS amplification attacks, several surveys
have discovered varying, but huge numbers of DNS resolvers on the
Internet willing to respond to DNS queries of arbitrary origin.

At least two vendors of DNS recursive servers (full resolvers)
have announced to (or do already) follow the recommendations made
in this document by adjusting their default ACLs.

Personnel
Peter Koch acted as the document shepherd.
Ron Bonica reviewed this document for the IESG.