Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[Mark Andrews]

The real issue with fragmentation is that firewalls don't add
appropriate slit rules to let through the response fragments when
they open the pinhole for the reply packet.

It isn't that hard to add "permit from dest, to src, type udp, frag
offset != 0" when you add "permit from dest port 53, to src port
xxx, type udp" except the firewall vendors haven't written code to
do it.  You don't have to let through all fragments.  You can filter
to potentially matching fragment.  The effort to be a perfect filter
breaks legitimate traffic.

NATs need to reassemble packets / hold fragments until the initial
fragment arrives but even they can use slit rules to reduce the
attack surface.  You don't have to drop fragments that you haven't
seen the initial fragment of the packet yet (ipfw does/did this).

The fragment with offset 0 also needs to be sent first.  This greatly
improves to possibility of fragments getting through.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[Robert Edmonds]

John Kristoff wrote:
> After a DNS over TCP discussion a student of mine indicated that they
> recently fixed a problem in their network where DNS messages over 512
> bytes were not being relayed.  It appears the root cause has to do with
> some defaults being set common gear that simply drops messages over 512
> bytes.  For example:
> 
>   
> 
>   !-- Enable a maximum message length to help defeat DNS
>   !-- amplification attacks. Note: This is the default
>   !-- configuration and value based on RFC 1035.
>   !
>   message-length maximum 512

Ironically, elsewhere in that same document series:

http://www.cisco.com/web/about/security/intelligence/dnssec.html

Potential Networking Challenges with DNSSEC Deployment

The networking-specific challenges from DNSSEC are largely the
result of the differences mentioned previously: increased packet
sizes, EDNS requirements and the more frequent use of TCP. Many
firewall devices incorrectly limit DNS responses to 512 and prohibit
DNS over TCP. [...]

This is still wrong, though; "and" should be "or", as in "Many firewall
devices incorrectly limit DNS responses to 512 *or* prohibit DNS over
TCP."  That document further states:

Connectivity Over UDP and TCP port 53

Because most DNS traffic is sent over UDP port 53, any filtering of
traffic that exists on the network is unlikely to impact future
native DNS traffic that is traversing UDP port 53. However, if DNS
traffic is not currently permitted to traverse TCP port 53, which is
typically used for large DNS packets (that is, those greater than
512 bytes), any issues with DNS traffic over TCP port 53 will be
exacerbated when DNSSEC packets begin arriving on the network,
because many DNSSEC packets will be greater than 512 bytes due to
the additional packet overhead of DNSSEC. If traffic using TCP port
53 is currently not permitted, or is being filtered to or from
specific hosts or networks, then it may be necessary to account for
new hosts and networks that could be sending DNSSEC traffic over TCP
port 53.

This seems to be implying that it's OK to block >512B UDP as long as you
don't *also* block TCP/53 :-(

-- 
Robert Edmonds

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[Nicholas Weaver]

> On Nov 12, 2015, at 8:43 AM, John Kristoff  wrote:
> 
> On Thu, 12 Nov 2015 08:00:50 -0800
> Nicholas Weaver  wrote:
> 
> After a DNS over TCP discussion a student of mine indicated that they
> recently fixed a problem in their network where DNS messages over 512
> bytes were not being relayed.  It appears the root cause has to do with
> some defaults being set common gear that simply drops messages over 512
> bytes.  For example:

This is an issue but its relatively rare.  Often the bigger problem is 
fragmentation support.

--
Nicholas Weaver  it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[John Kristoff]

On Thu, 12 Nov 2015 08:00:50 -0800
Nicholas Weaver  wrote:

> We've done some of this in Netalyzr.  Captive portals in particular
> are a problem, with about 1% of systems measured in Netalyzr unable
> to use EDNS0 to get DNSSEC information either from the recursive
> resolver OR directly from the roots.

After a DNS over TCP discussion a student of mine indicated that they
recently fixed a problem in their network where DNS messages over 512
bytes were not being relayed.  It appears the root cause has to do with
some defaults being set common gear that simply drops messages over 512
bytes.  For example:

  

  !-- Enable a maximum message length to help defeat DNS
  !-- amplification attacks. Note: This is the default
  !-- configuration and value based on RFC 1035.
  !
  message-length maximum 512

This contradicts what IETF RFC 6891 (EDNS0, April 2013) now says:

   6.2.6.  Support in Middleboxes
   [...]
   Conformant middleboxes MUST NOT limit DNS messages over UDP to 512
   bytes.

John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[Nicholas Weaver]

> On Nov 12, 2015, at 7:59 AM, Wiley, Glen  wrote:
> 
> I have seen the ISC EDNS compliance report (beautiful thing really), but it 
> loks as though the focus is really on the name servers and name server 
> operators.  Has a recent study been done to examine whether client side/ISP 
> firewalls are interfering with EDNS?

We've done some of this in Netalyzr.  Captive portals in particular are a 
problem, with about 1% of systems measured in Netalyzr unable to use EDNS0 to 
get DNSSEC information either from the recursive resolver OR directly from the 
roots.

--
Nicholas Weaver  it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[Wiley, Glen]

I have seen the ISC EDNS compliance report (beautiful thing really), but it 
loks as though the focus is really on the name servers and name server 
operators.  Has a recent study been done to examine whether client side/ISP 
firewalls are interfering with EDNS?
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop