Subject: [dns-dir] Urgent question: how long to keep DNS state on NAT and firewall?

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 09 Dec 2008 09:48:29 -0500

Background:
https://datatracker.ietf.org/idtracker/draft-ietf-dnsext-forgery-resilience/comment/88789/

Same issue applies to statefull firewalls.

RFC4787 says keep state for 2-5 minutes
RFC4787 req #5 says no less than 2 minutes
RFC4787 req #5-a says ports <1024 MAY have shorter
RFC4787 Req #5-c recommends 5 minutes.

On area of particular concern is NAT boxes with limited port range or limited
memory.

To address this issue we are proposing to add the following text to the
Forgery resilience draft:

"DNS recursive servers sitting behind at NAT or a statefull firewall
may consume all available NAT translation entries/ports when operating
under high query load. Port randomization will cause translation entries to
be consumed faster than with fixed query port.
To avoid this NAT boxes and statefull firewalls can/should purge outgoing
DNS query translation entries 10 seconds after the last outgoing query on
that mapping was sent. [RFC4787] compliant devices need to treat
UDP messages with port 53 differently than most other UDP protocols.

To minimize the potential that port/state exhaustion attacks can be staged from
the outside, it is recommended that services which generate number of 
DNS queries
for each connection, should be rate limited. This applies in 
particular to e-mail
servers."

The question is: is the 10 second recommendation OK or should it be 
longer/shorter?

Feel free to suggest better text.

         thanks
         Olafur
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Peter Koch <[email-masked]>
Date: Tue, 9 Dec 2008 20:24:49 +0100

> RFC4787 Req #5-c recommends 5 minutes.

with destination port 53 < 1024, DNS qualifies for less than 2 minutes under
these rules - and that makes sense.

> On area of particular concern is NAT boxes with limited port range or 

Is the "attack scenario" an exhaustion of the table or an attack against
a second (third, ...) resolver behind the same NAT by having one resolver
grab all the available slots?

> The question is: is the 10 second recommendation OK or should it be 

The trade off needs to be discussed. With 10 seconds you need 6500 q/s to
consume all available ports (provided the randomization is good enough(?)
not to reuse any port at the resolver side).
However, shrinking the window may lead to an effect where the mapping is
removed before the (increasing) resolver timeout expires.  A later response would
then be rejected.  Strange enough, we don't have clear recommendations how
long these resolver timeouts should be (at most), except RFC 1035 saying
"expected round trip time of 5-10 seconds should be the worst case".
Intuitively I'd have suggested 17 seconds to even cover a 16 second timeout,
but 10 (or 9, for that matter) seconds might be OK.  I'd feel more
comfortable, though, if the number didn't come out of the blue.

-Peter

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 09 Dec 2008 15:44:15 -0500

>grab all the available slots?

We can not do anything against internal attack i.e. java script spewing
out DNS questions.
This is about using external services like e-mail that generate
number of DNS questions for each e-mail message that arrives.

>not to reuse any port at the resolver side).

You are thinking that the NAT has 64K ports available (or can keep
track of 64K connections) that may not
be true in all cases and some of the IPv4-IPv6 transition steps
may restrict the number of ports available to each site.

>comfortable, though, if the number didn't come out of the blue.

That is why I asked rather than write down a recommendation on my own.

         Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 9 Dec 2008 16:07:47 -0500

> The question is: is the 10 second recommendation OK or should it be  

I'd prefer a little longer, but it all seems like a SWAG to me.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.