Subject: Re: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0

From: Jim Reid <[email-masked]>
Date: Thu, 1 Oct 2009 12:02:36 +0100

On 1 Oct 2009, at 07:27, George Barwood wrote:

> The limit must not be higher than 4096 bytes.

Why not 4095 or 4097? Justify your choice of 4096.

It's nonsense anyway. Suppose some response is 6K. The client does a  
lookup saying it can accept up to 8K over EDNS. The server can handle  
an 8K EDNS response. Under your scheme, it wouldn't be allowed to do  
that. The 6K reply would not be sent, even though both parties can  
handle it. That would result in a truncated response and TCP retry,  
which is stupid.

The current Security Considerations of the draft are fine as they are.  
Your suggested changes are not helpful or relevant.

Language about DNS amplification attacks (yawn) does not belong in  
this draft/RFC. That should go in a draft to dnsop, if it goes in a  
draft at all.

---

From: Jim Reid <[email-masked]>
Date: Thu, 1 Oct 2009 14:08:45 +0100

On 1 Oct 2009, at 13:44, George Barwood wrote:

> That seems completely inconsistent with RFC 3552

Nope. See above.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 02 Oct 2009 10:21:16 +1000

In message <E4737AD107E84202BC61518DE3A9B2F1@localhost>, "George Barwood" write
s:
> 
> ----- Original Message ----- 
> From: "Jim Reid" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, October 01, 2009 2:08 PM
> Subject: Re: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0
> 
> 
> I don't get it at all. 
> Are you suggesting draft-ietf-dnsext-rfc2671bis-edns0 is somehow
> exempt from the provisions of RFC 3552?
> 
> Where does this exemption come from?
> I can find no provisions for known threats to be deferred to some other document.

George, please go lobby your local goverment officials to introduce
regulations that require ISP's operating in their juristictions to
block spoofed traffic.  i.e. put some bite into the BCPs.  That
will be far more effective than worrying about protocols that return
bigger responses.  The problem isn't with the protocols it is with
the spoofed traffic.

This will level the playing field by ensuring that no player is
unfairly disavantaged by doing the right thing.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Oct 2009 17:11:36 -0700

On 10/1/09 5:21 PM, Mark Andrews wrote:
> In message<E4737AD107E84202BC61518DE3A9B2F1@localhost>, "George
> Barwood" write
[]
>> Where does this exemption come from? I can find no provisions for
>> known threats to be deferred to some other document.
>
> block spoofed traffic.  i.e. put some bite into the BCPs.  That will
> be far more effective than worrying about protocols that return

Mark,

While it is fine to promote BCP 38, this rhetoric is misleading, since 
the problem is with the protocol.  Whether or not BCP 38 is applied 
locally does not preclude reflected DNS amplifications attacks. 
Reflections can occur off of millions of non-local servers.  As network 
sources increase their complexity with mobility, multi-homing, and 
asymmetrical routing, the rigorous use of BCP 38 grows less practical 
and more complex, which might diminish currently inadequate adoption.

Adhering to advice given in RFC 3552 provides complete protection from 
amplified reflected attack _without_ dependence upon BCP 38 or access 
control lists.  Large DNS responses over UDP can create a level of 
amplification able to disable 30Gb/s connections, as discussed by 
teamcymru in:

  http://www.youtube.com/watch?v=XhSTlqYIQnI

With DNSSEC, authoritative servers, in addition to open resolvers, 
become potential (unfair per RFC 3552)  high gain sources.  However, 
unlike open resolvers, authoritative servers can not be shielded with 
access control lists.

-Doug