The chairs felt that fujiwara-san's draft was one that needed in person discussion in Montreal.
Also, if folks did not see his presentation at OARC, here are the slides: https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf Tim On Wed, Jul 10, 2019 at 11:17 PM Mark Andrews <ma...@isc.org> wrote: > > > > On 11 Jul 2019, at 4:00 am, Paul Vixie <p...@redbarn.org> wrote: > > > > i like marka's proposed solution below, a lot. and muks' is also clever, > > though requiring wire protocol changes. however, fujiwara-san's proposal > > describes a broader array of fragmentation problems than just integrity, > and > > we should be looking at that broader array when making our plans. > > > > i think there's a broader question about fragmentation itself. at the > outset, > > i knew, when creating EDNS0, that fragmentation was considered harmful: > > > > https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf > > > > noting, jeff mogul and chris kanterjiev (kent), authors of the above > tech > > report, were two of my mentors and bosses at d|i|g|i|t|a|l from 1988 to > 1993, > > so, i read all of their work, and i discussed my questions and > objections with > > them. fragmentation was, in ipv4, harmful. there can be no argument at > this > > late date. i sinned egregiously in EDNS0 by opening the door to > fragmentation, > > and the results have been predictably painful and expensive for > everybody. > > > > however, IPv6 intended to, promised to, and claimed to, fix V4 > fragmentation's > > many defects. i must have been thinking optimistic thoughts about the > IPv6 > > time line, and IPv6's promises and intentions, when i opened the > fragmentation > > door in EDNS0. what actually then happened was that ICMPv6 as required > for > > PMTUD6 was not secure and could not be implemented, which means any > > fragmentation done in IPv6 (which unlike IPv4, is an endpoint-only > activity) > > will be uninformed about path MTU. thus we make pessimistic assumptions > like > > 1500 and 1220. and if that's the kind of fragmentation we can actually > get, > > then it's a negative value, and fragmentation in IPv6 is as bad, for > different > > reasons, than in IPv4. > > IPv6 moved fragmentation to the originating node from the router to allow > for > faster routers. > > As for PMTUD and DNS/UDP it was clear in 1998 that DNS servers would need a > mechanism to avoid PMTUD issues so I proposed draft-ietf-ipngwg-bsd-frag > (1998) > which got incorporated into RFC 3542 (2003) as IPV6_USE_MIN_MTU. Named > uses > that mechanism when the OS supports it. > > Limiting transmitted EDNS/UDP responses just moves PMTUD issues to TCP > unless > care is taken to limit MSS sizes. This can be done by a number of > mechanisms > but is not universally achievable. DNS/TCP is not a panacea for DNS/UDP > fragmentation issues. > > PMTUD is a issue for a number of reasons. Routers still have PTB > generation on > the slow path which means that it ends up getting rate limited. PTB > generation > should have been moved into ASICs a decade ago. Firewalls that block PTB > packets. > Packet load balancers that fail to look into the ICMP payload when > forwarding PTB > messages. > > > therefore, for the reasons set out by fujiwara-san in his recent draft > posted > > here, and especially for the reasons spelled out by his extensive > references, > > DNS should not use fragmentation. while some of kazunori's examples have > to do > > with message integrity and attacks such as the shulman method, the case > > against fragmentation in DNS's use of UDP is immensely strong. solving > for the > > integrity problems doesn't change our conclusion, and adds more > complexity. > > > > i have two final notes, which may help inform those who witnessed the > sham > > consensus railroaded (soviet-style) through the recent DNS-OARC meeting > in > > bangkok, and heard me speak against outlawing fragmentation as a 2020 > Flag Day > > goal, and are now hearing me contradict myself. > > > > --- > > > > first, we need fragmentation to work, which means we need path MTU > discovery > > to work, which means we need ICMP to be secure, at least in IPv6. while > use of > > fragmentation for DNS UDP has a high cost, the intentional investment of > that > > cost would be a beneficial forcing function on fixing fragmentation > itself. > > notably, TCP avoids fragmentation through its MSS signaling, which > defaults to > > MIN(myMTU, herMTU) minus some fudge factor for protocol headers. which > means > > lack of fragmentation does not hurt the web, and so nobody cares about > it. but > > we should, all, care about it. i'll explain further in an upcoming > article > > which i'll link here, but briefly, 1500 is the wrong LAN MTU for FastE, > and is > > insanely small for 1GE, unthinkably wrong for 10GE, laughable for 40GE, > and > > engineering malpractice for 100GE. for a test, do a bunch of NFS and SMB > > tests, over both UDP and TCP for each protocol, using jumbo grams (9K > MTU) and > > then again using standard (1500 MTU) sized data grams. watch for > transfer > > speed, CPU utilization, and network utilization (as bits, not as > packets). > > > > i will at some point teach FreeBSD TCP how to fragment its first TCP > segment > > after synchronization, but only for IPv6. my goal is to force IPv4 > fallback if > > IPv6 with all of its promised PMTUD and endpoint-only fragmentation does > not > > work. let every network operator whose key performance indicators > include IPv6 > > deployment levels, begin to fear that without its PMTUD promises, IPv6 > is not > > good enough to replace IPv4, and they will have to plan on investments > in > > dual-stack, _forever_. > > > > --- > > > > second, all mass is energy, and state in the network should be thought > of as > > having mass. PMTUD has some scale problems regarding endpoint state > > requirements, and so, has to work well enough for fast LRU purges of > state > > required for endpoint MTU information, which will lead to rapid > rediscovery. > > but, TCP protocol control blocks are also state, and state has mass. a > world > > in which every recursive iterating server has long-running TCP/853 (DoT) > > connections open to hundreds or thousands of authority servers is not > going to > > be inexpensive, either for the initators or the responders. the web > works this > > way, but can require tens of gigabytes of kernel memory for the TCP > state > > alone. that's not a good ratio or mass to value. importantly, > fragmentation > > has another state mass cost, which is transmitting the fragments with > enough > > inter-packet gap to avoid microbursts which overflow the switch port > buffers, > > and receiving fragments which must be reassembled before they can be > > delivered. all of this is wrong. > > > > william simpson, perry metzger, and paul vixie (me) worked together > about ten > > years ago to create TCP enhancements which would have permitted an > unlimited > > number of quiescent but open TCP connections, at a per-connection state > cost > > precisely equal to the cost of resisting a SYN flood attack. so, highly > > compressed state, because state mass is a high cost at the network-wide > level. > > we also supported payloads large enough for DNS or WWW queries in the > > synchronization phase, fixed the security problems around RST, expanded > the > > option header space, and saved the window size during periods of > connection > > quiescence, allowing back-to-back-to-back transmissions once cookies had > been > > exchanged. the result was RFC 6013, which was entirely ignored by the > people > > who brought us TCPFO, which has the same incompressible state as TCP, > adds no > > security, and reduces only the problem of round trip costs. the other > document > > besides RFC 6013 that may be of interest is here: > > > > https://www.usenix.org/system/files/login/articles/126-metzger.pdf > > > > metzger, simpson, and vixie (me) are all notoriously difficult to work > with, > > and this stems from correctable personality defects and unforced human > > protocols errors for which we should each be periodically upbraided. > however, > > ignoring our work because we're somewhat irritating runs the risk of > taking > > the internet itself down a blind alley from which a later return won't > earn us > > thanks from the grandchildren. > > > > --- > > > > in summary, the network needs working fragmentation so that it can have > a > > future that isn't constrained by the physics of thickwire ten megabit > > ethernets, and if the DNS community were willing to join the fight, it > would > > be a shorter fight. however, DNS, and UDP itself, is better off without > > fragmentation, because of state mass and complexity costs, regardless of > > whether we can solve fragmentation's integrity and substitution > weaknesses. > > -- > > Paul > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
