Subject: Re: RFC proposal on DNS spoofing prevention

From: bert hubert <[email-masked]>
Date: Wed, 6 Sep 2006 21:49:53 +0200

On Fri, Sep 01, 2006 at 12:00:31AM -0400, Kevin Darcy wrote:

> Thinking as an implementor, the term "random source port" to me means 
> invoking a randomization function every time a source port is chosen, 
> regardless of whether the term is preceded by the adjective "new" or 

How about changing the current rather specific instruction, which mandates a
"new random source port" for each outgoing query, to one that describes the
intended effect:

  Given the above, a resolver MUST:

    o Send outgoing queries from source ports which can not be predicted
      by observing previous queries

How the nameserver achieves this is up to the implementor to decide.

Thanks for your analysis, Kevin!

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: bert hubert <[email-masked]>
Date: Wed, 6 Sep 2006 21:39:41 +0200

On Thu, Aug 31, 2006 at 04:39:31PM +0200, Stephane Bortzmeyer wrote:
> Good document, I've read it and I find it fine.

Thanks!

> But it should be submitted to the dnsop WG, no, since it does not
> change the protocol?

In some sense it does. You need source level changes to a nameserver to be
able to adhere to this draft. It is not an operational choice. RFC 1034
already contains language on verifying DNS question id's and addresses.

This draft actually changes DNS in that respect.

But I'm no expert on the finer points between dnsop/dnsext. Olafs?

	Bert

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Wed, 06 Sep 2006 16:29:41 -0400

<chair-hat on>
The chairs of DNSEXT and DNSOP's are discussing which WG is more appropriate
for this work, please give us few days to figure that out.

The bigger issue right now is what Andreas raised: what is the
scope of this document see:
http://psg.com/lists/namedroppers/namedroppers.2006/msg01220.html

<chair-hat off>
My gut feeling is that it will be hard to write this or similar draft
without saying "Updates RFC1035".

         Olafur

---

From: Scott Rose <[email-masked]>
Date: Thu, 07 Sep 2006 08:21:00 -0400

I agree - it doesn't do serious harm to the protocol if it is not 
followed, but it is a good practice to follow it.

Scott

Olaf M. Kolkman wrote:
> So I was doubting if that should be a MUST or a SHOULD.
> 
> RFC2119:
> 
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> 
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> 
> Further down in the same document:
>    In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)
> 
> I think it is clear that MUST is not needed for interoperability (DNS 
> has some interop trackrecord without this requirement). But it seems 
> that the "limit behaviour which has potential for causing harm" does apply.
> 
> Thoughts?
> 
> --Olaf (Without hats)
> 
> -----------------------------------------------------------
> Olaf M. Kolkman
> NLnet Labs
> http://www.nlnetlabs.nl/
> 
> 
> 
> 
> --

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 6 Sep 2006 22:31:46 +0200

RFC2119:

I think it is clear that MUST is not needed for interoperability (DNS  
has some interop trackrecord without this requirement). But it seems  
that the "limit behaviour which has potential for causing harm" does  
apply.

Thoughts?

--Olaf (Without hats)

---

From: bert hubert <[email-masked]>
Date: Wed, 6 Sep 2006 21:45:19 +0200

On Thu, Aug 31, 2006 at 03:18:10PM +0300, Andreas Gustafsson wrote:
> >  * http://ds9a.nl/rfc/dns-anti-spoofing.html
> I read the above draft.  A few comments:

Thanks!

> The draft covers threat 2.2, "ID Guessing and Query Prediction", in
> excellent detail, but makes no mention of the others.  It would be
> helpful to note in the draft that the term "DNS spoofing" can also
> refer to threats other than those discussed in the draft.

Will do.

> "Name Chaining".  All caching server implementations in common use
> today already implement such countermeasures, typically based on
> discarding records whose owner name is outside the domain whose
> authoritative servers are being queried.  In practice, these
> countermeasures are no longer optional, but there is still no IETF
> document discussing them.

Do you think this might fit in our current draft? I personally think it
would.

> >   o  Use a new random source port from its available range for each
> >      outgoing query
> 
> I don't think this MUST is realistic for high-volume servers.  In

Some of the highest-volume resolvers (7kpqs) of the internet currently run
with a new random source port per outgoing query. All recent operating
systems provide modern event multiplexing systems that take away the pain of
listening on thousands of ports.

> practice, most caching servers run on operating systems that require a
> separate open file descriptor for each port, and on a busy server the
> number of outstanding queries can easily exceed the number of
> available file descriptors.

Any large operator may be expected to have to raise limits if he wants to
achieve high volume. Linux by default restricts processes to 1024 file
descriptors, which should suffice most of the time, but Solaris has a
default limit of 256. This can be raised using the ulimit command. FreeBSD
has a default limit that is high enough for even very heavy duty use.

I don't think we should reduce security because older software has trouble
meeting the (new) demands, nor because the operator is unable/unwilling to
adjust his operating system for high loads.

	Bert

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 12 Sep 2006 16:43:28 +0300

> Do you think this might fit in our current draft? I personally think it

I would prefer two separate drafts, if only for the reason that any
controversy regarding one of them should not hold up the progress of
the other in the IETF process.

> listening on thousands of ports.

I would argue that listening on 64512 ports is still painful on most
systems, and that there exist systems (e.g., embedded ones) where the
pain threshold is much lower than that.

I have no problem with the draft encouraging the use of random ports
(as in SHOULD), and encouraging the use of the largest practical set
of ports to randomly choose from, but it should leave the determination
of what is practical in any particular implementation to the implementor.
-- 
Andreas Gustafsson, [email-masked]