Subject: [DNSOP] draft-fujiwara-dnsop-avoid-fragmentation-00

From: [email-masked]
Date: Fri, 05 Jul 2019 18:01:33 +0900 (JST)

Dear DNSOP,

I submitted draft-fujiwara-dnsop-avoid-fragmentation-00.

  https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00

It proposes avoid IP fragmentation operation in DNS.

I removed details of attack to path MTU discovery and cache poisoning
attacks using IP fragmentation from
draft-fujiwara-dnsop-fragmentation-attack01, and changed as
recommendations.

Details of attacks are written in slides at OARC 30.
https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf  

If the draft is interested, I will request timeslot at IETF 105.

I think it is time to consider to avoid IP Fragmentation in DNS.
It is possible to avoid IP fragmentation as much as possible.

It is not good that DNS is the biggest user of IP fragmentation.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

A new version of I-D, draft-fujiwara-dnsop-avoid-fragmentation-00.txt
has been successfully submitted by Kazunori Fujiwara and posted to the
IETF repository.

Name:		draft-fujiwara-dnsop-avoid-fragmentation
Revision:	00
Title:		Avoid IP fragmentation in DNS
Document date:	2019-07-04
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-avoid-fragmentation-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/
Htmlized:       https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-avoid-fragmentation

Abstract:
   Path MTU discovery is vulnerable and IP fragmentation may cause
   protocol weakness.  Currently, DNS is said to be the biggest user of
   IP fragmentation.  However, it is possible to avoid IP fragmentation
   in DNS because TCP transport and truncation work well.  This document
   proposes to avoid IP fragmentation in DNS.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Brian Dickson <[email-masked]>
Date: Wed, 10 Jul 2019 12:13:10 -0700

Sorry for the late message, but I support both the intent and the draft.

One question:
Would it be feasible for recommending that full service resolvers check for
EDNS0 bufsize compliance, and treat violations as if they were TC=1?
E.g. Suppose I am a resolver, and send my query to an authority server with
bufsize=1220 (per the draft). If I get a response that exceeds that size, I
unilaterally modify the response to set the TC bit, which triggers retry
over UDP, without looking at any of the response data.

If it makes sense, it probably should be added to the above draft rather
than being standalone.

I think this suggestion is a very minor hack, and I can't see any real
downside to it.

The bufsize adherence is mandatory. If bufsize was <= MTU, for sure
fragmentation occurring would require bufsize violation.
(The reverse is not automatic; if MTU <= actual < bufsize, fragmentation
might not have occurred, even though the requested bufsize was not honored.)
This adds protection against the one corner case that the original ID isn't
able to fix.

The upside of this suggestion is, the party at risk (resolver and
resolver's clients) is the same party that needs to apply the fix, i.e. it
is symmetric in nature.

Obviously, authority servers that do not honor bufsize still need to fix
their implementations, but at least this allows impacted resolvers to
unilaterally protect themselves (exactly analogous to setting bufsize <=
MTU in the first place).

Brian

On Fri, Jul 5, 2019 at 2:02 AM <[email-masked]> wrote:

> URL:
> https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-avoid-fragmentation-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/
> Htmlized:
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-avoid-fragmentation
>
>
> Abstract:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Daisuke HIGASHI <[email-masked]>
Date: Tue, 16 Jul 2019 01:14:58 +0900

Fujiwara-san,

IHMO, as long as we use UDP, fragmentation is inevitable in heterogeneous IP network (“the internet”). We could avoid IP fragmentation as possible with some techniques, but should prepared for case which fragmentation is really needed.

> o Full-service resolvers MAY drop fragmented UDP 
>   responses derived from DNS before IP assembly. 
>   (It is a countermeasure against DNS cache poisoning attacks
>   using IP fragmentation.)

Just dropping fragmented responses breaks DNS resolution when fragmentation was really needed to deliver responses. Full-service resolvers need to take further action, i.e. retrying in TCP mode.

However implementing “retry in TCP mode when fragmentation received” have some difficulties, because there is no socket API (in general) to know if a UDP packet is derived from IP reassembly. I just wrote simple nfqueue filter to replace fragmented DNS responses with tc=1 responses [1] but I don’t think all operator can deploy such filter.

[1] https://github.com/hdais/dnsfrag2tc

> o And more, authoritative servers MAY send DNS responses with
>  IP_DONTFRAG / IPV6_DONTFRAG options.

Authoritative server also need to be prepared for case that DNS response could not be delivered due to IP_DONTFRAG but fragmentation was really needed.

In this case authoritative servers should know it by some error code (EMSGSIZE?) from recvfrom() syscalls, and servers can resend tc=1 to enforce resolvers to retry in TCP mode.