Fair enough. You will see that text in the next version of the draft.
Ron
From: C. M. Heard <he...@pobox.com>
Sent: Friday, June 1, 2018 12:01 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: draft-intarea-frag authors <draft-bonica-intarea-frag-frag...@ietf.org>;
int-area <int-area@ietf.org>
Subject: Re: draft-bonica-intarea-frag-fragile-01
On Thu, May 31, 2018 at 12:39 PM, Ron Bonica
<rbon...@juniper.net<mailto:rbon...@juniper.net>> wrote:
In Section 6.1, DNS, please note that
draft-ietf-tsvwg-udp-options<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dudp-2Doptions&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=J_pOJLHC_gbCzzfyeW8omX8B8j4T6I07igUCmsA7vPg&s=l9Z0Kh7PKrF4seGUMRn2kViHzJspMRaoNPTKtZ62uIs&e=>
may offer an incrementally deployable solution to the problem of oversize DNS
responses. As far as I know, this specific use case is not yet documented in
any I-D, but the basic idea is that a client would indicate its willingness to
accept a UDP-fragmented response by including in its (unfragmented) request a
UDP options trailer with the FRAG option as specified on
page-15<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dudp-2Doptions-2D02-23page-2D15&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=J_pOJLHC_gbCzzfyeW8omX8B8j4T6I07igUCmsA7vPg&s=VyqM-WCNZiwxsDRAU9buCv7rxPTo9FyDxsWRLlwh_T8&e=>
of draft-ietf-tsvwg-udp-options. A server that does not implemented UDP
options would ignore the options trailer and use IP-layer fragmentation for
large responses; a server that implements UDP options would use UDP-layer
fragmentation for large responses.
RB> While I agree, such a recommendation might be overstepping my charter.
Isn’t that a decision for another WG?
Fair enough. But it might be worth noting possible solutions, Let me offer the
following proposal for your consideration.
OLD:
DNS Servers that execute DNSSEC
[RFC4035<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4035&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=3hdRdqDKogUrFAnsk2PVA1XtzMKf_uOyyPaQJlIYrm4&s=iVOGnO8g0kR-YbEW_OTY3jl0QbFKxAgT9ClrD0JOs4c&e=>]
procedures are more likely
to generate large responses. Therefore, when running over UDP, they
are more likely to cause the generation of IPv6 fragments. DNS's
reliance upon IPv6 fragmentation is fundamental and cannot be broken
without changing the DNS specification.
NEW:
DNS Servers that execute DNSSEC
[RFC4035<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4035&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=3hdRdqDKogUrFAnsk2PVA1XtzMKf_uOyyPaQJlIYrm4&s=iVOGnO8g0kR-YbEW_OTY3jl0QbFKxAgT9ClrD0JOs4c&e=>]
procedures are more likely
to generate large responses. Therefore, when running over UDP, they
are more likely to cause the generation of IPv6 fragments. DNS's
reliance upon IPv6 fragmentation is fundamental and cannot be fully
eliminated without changing the DNS specification, e.g., by adding
UDP or application layer fragmentation, or by measures such as those
described in
https://tools.ietf.org/html/draft-song-atr-large-resp<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsong-2Datr-2Dlarge-2Dresp&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=3hdRdqDKogUrFAnsk2PVA1XtzMKf_uOyyPaQJlIYrm4&s=F3W3ZMZQZDYsg1U-raZas8QM5l0vc5udsEs0xl5KmAg&e=>.
Section 4.4, Security Vulnerabilities: please cite RFC 3828 in addition to RFC
1858 in both places where the latter is cited.
RB> Are you sure that you want me to reference 3828 (UDP lite)? I don’t see the
connection.
That was a typo. I meant RFC
3128<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3128&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=3hdRdqDKogUrFAnsk2PVA1XtzMKf_uOyyPaQJlIYrm4&s=-9XQRL7WMoI5EfSks-E5b7h92F__gRQhbMBCL284Tj8&e=>.
Sorry about that.
Mike Heard
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
