< draft-ietf-dnsop-avoid-fragmentation-00.txt   draft-ietf-dnsop-avoid-fragmentation-01.txt >
Network Working Group K. Fujiwara Network Working Group K. Fujiwara
Internet-Draft JPRS Internet-Draft JPRS
Intended status: Best Current Practice P. Vixie Intended status: Best Current Practice P. Vixie
Expires: January 1, 2021 Farsight Expires: January 29, 2021 Farsight
June 30, 2020 July 28, 2020
Fragmentation Avoidance in DNS Fragmentation Avoidance in DNS
draft-ietf-dnsop-avoid-fragmentation-00 draft-ietf-dnsop-avoid-fragmentation-01
Abstract Abstract
Path MTU discovery remains widely undeployed due to security issues, EDNS0 enables a DNS server to send large responses using UDP and is
and IP fragmentation has exposed weaknesses in application protocols. widely deployed. Path MTU discovery remains widely undeployed due to
Currently, DNS is known to be the largest user of IP fragmentation. security issues, and IP fragmentation has exposed weaknesses in
It is possible to avoid IP fragmentation in DNS by limiting response application protocols. Currently, DNS is known to be the largest
size where possible, and signaling the need to upgrade from UDP to user of IP fragmentation. It is possible to avoid IP fragmentation
TCP transport where necessary. This document proposes to avoid IP in DNS by limiting response size where possible, and signaling the
fragmentation in DNS. need to upgrade from UDP to TCP transport where necessary. This
document proposes to avoid IP fragmentation in DNS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2021. This Internet-Draft will expire on January 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 3 3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 3
4. Maximum DNS/UDP payload size . . . . . . . . . . . . . . . . 5 4. Maximum DNS/UDP payload size . . . . . . . . . . . . . . . . 5
5. Incremental deployment . . . . . . . . . . . . . . . . . . . 5 5. Incremental deployment . . . . . . . . . . . . . . . . . . . 5
6. Request to zone operators and DNS server operators . . . . . 6 6. Request to zone operators and DNS server operators . . . . . 6
7. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 7. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 6 7.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. How to retrieve path MTU value to a destination from Appendix A. How to retrieve path MTU value to a destination from
applications . . . . . . . . . . . . . . . . . . . . 9 applications . . . . . . . . . . . . . . . . . . . . 9
Appendix B. Minimal-responses . . . . . . . . . . . . . . . . . 9 Appendix B. Minimal-responses . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
DNS has EDNS0 [RFC6891] mechanism. It enables a DNS server to send DNS has EDNS0 [RFC6891] mechanism. It enables a DNS server to send
large responses using UDP. EDNS0 is now widely deployed, and DNS large responses using UDP. EDNS0 is now widely deployed, and DNS
(over UDP) is said to be the biggest user of IP fragmentation. (over UDP) is said to be the biggest user of IP fragmentation.
However, "Fragmentation Considered Poisonous" [Herzberg2013] proposed However, "Fragmentation Considered Poisonous" [Herzberg2013] proposed
effective off-path DNS cache poisoning attack vectors using IP effective off-path DNS cache poisoning attack vectors using IP
fragmentation. "IP fragmentation attack on DNS" [Hlavacek2013] and fragmentation. "IP fragmentation attack on DNS" [Hlavacek2013] and
skipping to change at page 3, line 14 skipping to change at page 3, line 14
In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines
[RFC8085] we are told that an application SHOULD NOT send UDP [RFC8085] we are told that an application SHOULD NOT send UDP
datagrams that result in IP packets that exceed the Maximum datagrams that result in IP packets that exceed the Maximum
Transmission Unit (MTU) along the path to the destination. Transmission Unit (MTU) along the path to the destination.
A DNS message receiver cannot trust fragmented UDP datagrams A DNS message receiver cannot trust fragmented UDP datagrams
primarily due to the small amount of entropy provided by UDP port primarily due to the small amount of entropy provided by UDP port
numbers and DNS message identifiers, each of which being only 16 bits numbers and DNS message identifiers, each of which being only 16 bits
in size, and both likely being in the first fragment of a packet, if in size, and both likely being in the first fragment of a packet, if
fragmentation occurs. By comparison, TCP is considered resistant fragmentation occurs. By comparison, TCP protocol stack controls
against IP fragmentation attacks because TCP has a 32-bit sequence packet size and avoid IP fragmentation under ICMP NEEDFRAG attacks.
number and 32-bit acknowledgment number in each segment. In TCP, In TCP, fragmentation should be avoided for performance reasons,
fragmentation should be avoided for performance reasons, whereas for whereas for UDP, fragmentation should be avoided for resiliency and
UDP, fragmentation should be avoided for resiliency and authenticity authenticity reasons.
reasons.
[I-D.ietf-intarea-frag-fragile] summarized that IP fragmentation [I-D.ietf-intarea-frag-fragile] summarized that IP fragmentation
introduces fragility to Internet communication. The transport of DNS introduces fragility to Internet communication. The transport of DNS
messages over UDP should take account of the observations stated in messages over UDP should take account of the observations stated in
that document. that document.
This document proposes to avoid IP fragmentation in DNS/UDP. This document proposes to avoid IP fragmentation in DNS/UDP.
2. Terminology 2. Terminology
skipping to change at page 9, line 40 skipping to change at page 9, line 36
Appendix B. Minimal-responses Appendix B. Minimal-responses
Some implementations have 'minimal responses' configuration that Some implementations have 'minimal responses' configuration that
causes a DNS server to make response packets smaller, containing only causes a DNS server to make response packets smaller, containing only
mandatory and required data. mandatory and required data.
Under the minimal-responses configuration, DNS servers compose Under the minimal-responses configuration, DNS servers compose
response messages using only RRSets corresponding to queries. In response messages using only RRSets corresponding to queries. In
case of delegation, DNS servers compose response packets with case of delegation, DNS servers compose response packets with
delegation NS RRSet in authority section and in-zone and below-zone delegation NS RRSet in authority section and in-domain (in-zone and
glue in the additional data section. In case of non-existent domain below-zone) glue in the additional data section. In case of non-
name or non-existent type, the start of authority (SOA RR) will be existent domain name or non-existent type, the start of authority
placed in the Authority Section. (SOA RR) will be placed in the Authority Section.
In addition, if the zone is DNSSEC signed and a query has the DNSSEC In addition, if the zone is DNSSEC signed and a query has the DNSSEC
OK bit, signatures are added in answer section, or the corresponding OK bit, signatures are added in answer section, or the corresponding
DS RRSet and signatures are added in authority section. Details are DS RRSet and signatures are added in authority section. Details are
defined in [RFC4035] and [RFC5155]. defined in [RFC4035] and [RFC5155].
Authors' Addresses Authors' Addresses
Kazunori Fujiwara Kazunori Fujiwara
Japan Registry Services Co., Ltd. Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81 3 5215 8451 Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp Email: fujiwara@jprs.co.jp
Paul Vixie Paul Vixie
 End of changes. 9 change blocks. 
24 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/