Subject: [dnsext] Some feedback on draft-andrews-dnsext-udp-fragmentation-00.txt

From: Fernando Gont <[email-masked]>
Date: Fri, 16 Dec 2011 13:25:16 -0300

Mark,

Here's some feedback about the aforementioned I-D.

** Technical **

Section 3:
>    It should be noted that even with IPV6_USE_MIN_MTU set to one that a
>    PTB message may still be received [RFC 2460] which requires a IPv6 to
>    add a Fragmentation header to subsequent packets.  There is currently
>    no way to avoid this, without using raw sockets, as there is no way
>    for a application to request that a Fragmentation header be added to
>    a packet.

I understand that this could (at leasst in theory) happen but, out of
curiosity: are there any devices that leverage the aforementioned
featuer specified in RFC 2460? NAT 64? Othes?

Section 5 (Security Considerations):
All these IPv4 issues are discussed in detail in RFC 6274.

Also, as noted in my feedback about your other I-D:
Relying on fragmentation doesn't come for free, either. In aprticular,
if implementation use predictable Fragment IDs (see
draft-gont-6man-predictable-fragment-id) fragmentation-related attacks
become pretty much feasible.

** Editorial **

Abstract: Expand the Abstract briefly outlining the problem.

Section 3:
> These include, but are
>    not limited to, setting the interface the packets are being sent over
>    should be set to the network MTU (1280 bytes), or restricing DNS/UDP
>    packets to no more than 1280 bytes including IPv6 headers.

This does not parse. You should probably rephrase to "setting the MTU of
the interface the packets are being sent over to the minimum IPv6 MTU
(1280 bytes)"

(Note that I've also s/network MTU/minimum IPv6 MTU/)

Section 3:
>    It should be noted that even with IPV6_USE_MIN_MTU set to one that a
>    PTB message may still be received [RFC 2460] which requires a IPv6 to
>    add a Fragmentation header to subsequent packets.  There is currently
>    no way to avoid this, without using raw sockets, as there is no way
>    for a application to request that a Fragmentation header be added to
>    a packet.

Add a pointer to your other I-D specifying a mechanism to achieve this.

** Nits **

Section 1:
>    network and no PMTUD was performed.  With IPv6 fragmentation occurs
>    in the sending node and PMTUD is alway performed unless the IPv6
>    packet is fragmented by the sending node using the network MTU.

s/alway/always/

Section 1:
> PMTUD discover

Replace with "Path-MTU Discovery".

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Dec 2011 11:08:15 +1100

> Here's some feedback about the aforementioned I-D.

Thanks.
 
> featuer specified in RFC 2460? NAT 64? Othes?

Its been told to me that there are small (<1280) MTU networks that
don't fragment and reassembly IPv6 at the link layer.  I have no
reason to disbelieve this.  Instead they depend on this.  I have no
direct knowledge.

I do have direct knowledge of DNS/UDP responses being fragmented
at ethernet MTU (by looking at final fragment offsets) rather than
1280 and only the last fragment making it through as a result of a
6in4 link in the path even with repeated queries to the authoritative
server.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]