Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[神明達哉 <[e-mail]>]

At Mon, 04 Mar 2019 20:43:14 +0900 (JST),
[e-mail] wrote:

> > - Section 3
> >
> >    Linux 2.6.32, Linux 4.18.20
> >    and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and
> >    path MTU decreased to 1280.
> >
> >   I suspect this often doesn't matter much in practice.  Since IPv6
> >   doesn't allow fragmentation and PMTU discovery isn't very effective
for
>                   ^^^^^^^^^^^^^
>           on-path fragmentation ?

Oops, sorry for the confusing text.  I meant "IPv6 doesn't allow
fragmentation at intermediate nodes" (or, yes, I meant "on-path
fragmentation").

> >   DNS responders, the server implementation should set
> >   IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations
> >   actually set this option; some others don't, but they are just lucky
> >   to not encounter the problem or receive complaints about it).
>
> If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU
value ?

Yes.  Or more accurately, if IPV6_USE_MIN_MTU is set the path MTU
value (if known) is just ignored.

> Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ?

Yes (if IPV6_USE_MIN_MTU is specified).

> I observed many fragmented IPv6 DNS responses whose packet size are
> 1496 or 1500.

Those should be sent from a server that doesn't set IPV6_USE_MIN_MTU
or from a system that doesn't support the option (sadly a very widely
deployed OS doesn't support it: Linux).

> # What I was interested in was that many implementations accept
> # crafted "ICMPv6 Packet Too Big".

Sure, but unless it matters in the larger context of the draft, it's
just a distraction.

--
JINMEI, Tatuya