Subject: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

From: Danny McPherson <[email-masked]>
Date: Sun, 30 Sep 2007 22:32:39 -0600

I do support this document being published as BCP.

A couple of minor comments:

Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator, IMO (in addition, there's a
typo; s/were/where/).

    In situations were more complex network setups are in place,  
"Ingress
    Filtering for Multihomed Network" [BCP84] maybe a useful additional
    reference.

Perhaps clarifying that Strict and Feasible methods do provide some
protection, but Loose provides zero protection from reflective attacks,
as they really only require that the target "exist" - they usually do.

You might stress that the "IP based authentication" recommendation
is pretty much useless -- unless you implement policy at all ingress
points (including from peers/providers).  In particular, if you don't  
filter
you're permitted-query-address-sources coming from "the Internet" or
peers, then spoofing can still be used to launch reflective attacks:

    o  IP based authentication.  Use the IP address of the sending host
       and filter them through and Access Control List (ACL) to service
       only the intended clients.

Also, I'm not sure I'd call this "authentication", perhaps IP-based
access policy" is more appropriate?

Some more details and recommendations on SOHOish ORNS
might be useful for implementers.

As for the TSIG or SIG(0) recommendation, I'm not sure what
the numbers are for client support today, but I suspect it's at
best an negligible sample.

I also agree with Paul Hoffman's comments on some reasons
for ORNSs.  There are many reasons why I may want to use a
specific resolver consistently, to include those outlined by
Paul/John.

-danny

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Danny McPherson <[email-masked]>
Date: Sun, 30 Sep 2007 22:32:39 -0600

-danny

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 1 Oct 2007 09:52:27 +0200

On Sun, Sep 30, 2007 at 10:32:39PM -0600,
 Danny McPherson <[email-masked]> wrote 
 a message of 51 lines which said:

> useful action on part of the operator,

This could be said of all the parts of the I-D which mentions non-DNS
issues such as BCP 38. In that respect, I full agree with Stephen
Hanna's review
(http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html).

> Some more details and recommendations on SOHOish ORNS might be
> useful for implementers.

Any idea? The current draft mentions "Incoming Interface based
selection" and I do not see what to add?

> I also agree with Paul Hoffman's comments on some reasons for ORNSs.
> There are many reasons why I may want to use a specific resolver
> consistently, to include those outlined by Paul/John.

Sorry, but their messages are quite off the track. The problem is not
wether there is an use case for using a resolver different from the
one provided by the current access point. There are, indeed, many
reasons for *not* using the default resolver (ISP which violates RFC
4925, section 2.5.2 are a very good example). But ORNS are *not* the
proper solution for that use case. TSIG signatures, VPNs, local
caching resolvers are the good solutions.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 1 Oct 2007 09:52:27 +0200

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 10:47:44 -0600

> (http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html).

I read Stephen's comments before posting, and I agree
as well.

However, the BCP 84 bit is slightly different because it's
only useful for mitigating reflective attacks IF it's employed
in a particular way.  If this document is going to reference it
then it should make a distinction here.

> selection" and I do not see what to add?

Perhaps expanding in the "Problem Description" section
would be beneficial.  Something mentioning that Many
SOHO and broadband access devices provide some flavor
of name resolution services (e.g., there are 4 flavors
outlined by JKT and others; Recursive, Forwarder, Caching-
only and Restricted).

Some other empirical bits might be useful as well, though
and although I'm not sure they need to be in the I-D, they
would be useful:

E.g., 16M recursive "type" servers, , with 800k or so being
the larger problem.   Also, some references that provide usual
information on actual numbers, such as John's work here:

http://condor.depaul.edu/~jkristof/orns/
http://maps.measurement-factory.com/gallery/Openresolvers/

And this is particularly illustrative:

http://maps.measurement-factory.com/gallery/Openresolvers/20070429.png

As for the current text, you don't provide much in the way
of explaining that queries should probably not be accepted
from the Internet/untrusted interfaces, you just essentially
state that interface-based discrimination might be employed.
That was my initial concern.  If your attempt is to progress as
BCP, then some actual specific guidelines on this front
for implementers and administrators alike might provide more
actionable information.
> caching resolvers are the good solutions.

I think you made my point.  Where is this currently explained in the
document as such?  Acknowledging existence and practical realities
is important, methinks.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 10:47:44 -0600

-danny

---

From: John Kristoff <[email-masked]>
Date: Mon, 1 Oct 2007 14:08:57 -0500

On Mon, 1 Oct 2007 10:47:44 -0600

> outlined by JKT and others; Recursive, Forwarder, Caching-

Since this group can be a bit pedantic about terminology, what Danny
is referencing is what I was specifically referring to as "resolvers".
I totally made up those four categories for my purposes of describing
some of the work we were doing as a simple way to describe what we've
seen in responses to probes.

> information on actual numbers, such as John's work here:

Can you explain what you mean by the 800k being the larger problem?
I presume you're referring to the observation that the majority of
resolvers on the net are forwarding to that smaller pool.  I might
argue that the bigger problem is not with the 800k pool.

John

---

From: John Kristoff <[email-masked]>
Date: Mon, 1 Oct 2007 14:08:57 -0500

John

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 15:34:57 -0600

> seen in responses to probes.

Yeah, I'd hope you'd chime in here :-)  Sorry to put you
on the spot, but I believe data and work are relevant and
quite useful in this context.  Furthermore,  I think it's a useful
exercise to classify resolver types, as implications and any
recommendation BCPs would perhaps vary widely across
each type.

> resolvers on the net are forwarding to that smaller pool.

Yep, precisely.

> I might argue that the bigger problem is not with the 800k pool.

Yeah, actually, I could agree with that.  One might presuppose
that the larger pool is perhaps the result of more default
configuration and implementation issues.  Do you have any
additional thoughts along these lines, perhaps further analysis
based on the dns-fp/id data sets?

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 15:34:57 -0600

Yep, precisely.

-danny

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2007 11:42:01 +1000

> best an negligible sample.

	Well all Windows XP/2003/Vista boxes can be configured to
	support TSIG, with free software, if not natively.

	All Linux, *BSD and Apple boxes can do this with what ships
	with the OS.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2007 11:42:01 +1000

Mark

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 19:52:33 -0600

> 	All Linux, *BSD and Apple boxes can do this with what ships

Sorry, I said "support", I meant "use".  Any numbers there?

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 19:52:33 -0600

-danny

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2007 13:45:30 +1000

> Sorry, I said "support", I meant "use".  Any numbers there?

	I use TSIG on my laptop.

	As for others I have no idea.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2007 13:45:30 +1000

I use TSIG on my laptop.

	Mark