21 Čen
2016
21 Čen
'16
13:55
Hello guys,
there has been a request in our issue tracker [1], to enable
IPV6_USE_MIN_MTU socket option [2] for IPv6 UDP sockets in Knot DNS.
This option makes the operating system to send the responses with a
maximal fragment size of 1280 bytes (minimal MTU size required by IPv6
specification).
The reasoning is based on the draft by Mark Andrews from 2012 [3]. I
wonder if the reasoning is still valid in 2016. And I'm afraid that
enabling this option could enlarge the window for possible DNS cache
poisoning attacks.
We would appreciate any feedback on your operational experience with DNS
on IPv6 related to packet fragmentation.
[1] https://gitlab.labs.nic.cz/labs/knot/issues/467
[2] https://tools.ietf.org/html/rfc3542#section-11.1
[3] https://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01
Thanks and regards,
Jan
21 Čen
21 Čen
19:26
New subject: forcing minimal fragment size for IPv6 datagrams
Jan Včelák wrote:
there has been a request in our issue tracker [1], to
enable
IPV6_USE_MIN_MTU socket option [2] for IPv6 UDP sockets in Knot DNS.
This option makes the operating system to send the responses with a
maximal fragment size of 1280 bytes (minimal MTU size required by IPv6
specification).
I agree with Daisuke Higashi's comment on the issue tracker. There may
be other applications running on the same server as Knot (e.g., a web
server), so a global OS level configuration setting is probably not
granular enough.
The reasoning is based on the draft by Mark Andrews
from 2012 [3]. I
wonder if the reasoning is still valid in 2016. And I'm afraid that
enabling this option could enlarge the window for possible DNS cache
poisoning attacks.
Are you referring to a “Fragmentation Considered Poisonous” style
attack? One of the countermeasures described in that paper is:
Yet another possible defense for name servers, is to always add a
random RR to any packet over certain size (i.e., which may be
fragmented). A simple type A resource record, containing random IP
address for some fictitious domain name, would suffice. The TTL of
such an RR should be set to zero to prevent the resolver from
caching that record. This would prevent the attacker from being able
to predict and (correctly) adjust the checksum value. If there are
multiple vulnerable fragments, such a random RR should appear in
each fragment.
That is a little too fast and loose to be deployable in the real world,
but it seems like EDNS cookies would serve the same purpose, at least in
the two fragment case (and if the OPT RR is pushed to the end of the
additional section to guarantee that it appears in the second fragment)?
We would appreciate any feedback on your operational
experience with DNS
on IPv6 related to packet fragmentation.
There was a long thread a while back on the dns-operations mailing list
that may be of interest, starting here:
https://lists.dns-oarc.net/pipermail/dns-operations/2009-June/004021.html
--
Robert Edmonds
edmonds(a)debian.org
23 Čen
23 Čen
12:41
New subject: forcing minimal fragment size for IPv6 datagrams
Hello Robert,
A garbage in the packet sounds really hacky. I don't like that.
DNS cookies might serve the same purpose. But the option must be added
by the client initially. Which makes the approach opt-in.
EDNS padding sounds usable. Any content of the padding bytes should be
accepted [1]. And it can be always added by the server.
[1] https://tools.ietf.org/html/rfc7830#section-3
I agree with Daisuke Higashi's comment on the
issue tracker. There may
be other applications running on the same server as Knot (e.g., a web
server), so a global OS level configuration setting is probably not
granular enough.
I take the point.
The reasoning
is based on the draft by Mark Andrews from 2012 [3]. I
wonder if the reasoning is still valid in 2016. And I'm afraid that
enabling this option could enlarge the window for possible DNS cache
poisoning attacks.
Are you referring to a “Fragmentation Considered Poisonous” style
attack? One of the countermeasures described in that paper is:
Yet another possible defense for name servers, is to always add a
random RR to any packet over certain size (i.e., which may be
fragmented). A simple type A resource record, containing random IP
address for some fictitious domain name, would suffice. The TTL of
such an RR should be set to zero to prevent the resolver from
caching that record. This would prevent the attacker from being able
to predict and (correctly) adjust the checksum value. If there are
multiple vulnerable fragments, such a random RR should appear in
each fragment.
That is a little too fast and loose to be deployable in the real world,
but it seems like EDNS cookies would serve the same purpose, at least in
the two fragment case (and if the OPT RR is pushed to the end of the
additional section to guarantee that it appears in the second fragment)? There was a long thread a while back on the
dns-operations mailing list
that may be of interest, starting here:
https://lists.dns-oarc.net/pipermail/dns-operations/2009-June/004021.html
That's really long thread. Unfortunately without clear conclusion. The
only conclusion I made of it is that internet is a mess. :)
Thanks,
Jan
21 Čen
21 Čen
20:49
New subject: forcing minimal fragment size for IPv6 datagrams
On 2016-06-21 13:55, Jan Včelák wrote:
We would appreciate any feedback on your operational
experience with DNS
on IPv6 related to packet fragmentation.
Geoff Huston presented some statistics from his research on IPv6
fragmentation at RIPE 72 [1]. Perhaps it is useful in the context of DNS
on IPv6 or you could contact him to obtain additional data or conduct an
experiment specifically for DNS. I'll leave it to you to decide whether
Geoff's conclusions are valid and what to do about the issues with MTU,
PMTU and fragmentation.
- Matthias-Christian
[1] https://ripe72.ripe.net/archives/video/164/
23 Čen
23 Čen
12:47
New subject: forcing minimal fragment size for IPv6 datagrams
Hello,
On 21.6.2016 20:49, Matthias-Christian Ott wrote:
On 2016-06-21 13:55, Jan Včelák wrote:
Thanks. Geoff's presentation is great as always.
I'm quite surprised that the enforced fragmentation made things much
worse. My conclusion would be not to set IPV6_USE_MIN_MTU. At least not
by default.
Cheers,
Jan
We would appreciate any feedback on your
operational experience with DNS
on IPv6 related to packet fragmentation.
Geoff Huston presented some statistics from his research on IPv6
fragmentation at RIPE 72 [1]. Perhaps it is useful in the context of DNS
on IPv6 or you could contact him to obtain additional data or conduct an
experiment specifically for DNS. I'll leave it to you to decide whether
Geoff's conclusions are valid and what to do about the issues with MTU,
PMTU and fragmentation. 
22 Čen
22 Čen
11:38
New subject: forcing minimal fragment size for IPv6 datagrams
On 21/06/16 13:55, Jan Včelák wrote:
Hi Jan,
This setting is useful to operators who wish to emit large DNS UDP
responses over IPv6, and have them fragmented at 1280 bytes. Sure,
fragments have their own issues, and are blocked in many places, but an
operator should be allowed to make this decision.
If it were me, I would instead use the "max-udp-payload" option, set to
1280, so that Knot emits responses with TC set. This may cause some
clients to retry over TCP. But one missing feature in Knot is that it
doesn't allow tuning of the EDNS payload separately for IPv4 and IPv6.
It might be useful to have "max-udp-payload-ipv4" and
"max-udp-payload-ipv6" options for setting this separately, because IPv4
and IPv6 behaviours are different.
Regards,
Anand
there has been a request in our issue tracker [1], to
enable
IPV6_USE_MIN_MTU socket option [2] for IPv6 UDP sockets in Knot DNS.
This option makes the operating system to send the responses with a
maximal fragment size of 1280 bytes (minimal MTU size required by IPv6
specification).
The reasoning is based on the draft by Mark Andrews from 2012 [3]. I
wonder if the reasoning is still valid in 2016. And I'm afraid that
enabling this option could enlarge the window for possible DNS cache
poisoning attacks.
We would appreciate any feedback on your operational experience with DNS
on IPv6 related to packet fragmentation.
23 Čen
23 Čen
12:50
New subject: forcing minimal fragment size for IPv6 datagrams
Hi Anand,
If it were me, I would instead use the
"max-udp-payload" option, set to
1280, so that Knot emits responses with TC set. This may cause some
clients to retry over TCP. But one missing feature in Knot is that it
doesn't allow tuning of the EDNS payload separately for IPv4 and IPv6.
It might be useful to have "max-udp-payload-ipv4" and
"max-udp-payload-ipv6" options for setting this separately, because IPv4
and IPv6 behaviours are different.
Thank you for the input! This sounds to be a better solution than
forcing the fragmentation. Based on the conclusions from the Geoff's
experiment... We will consider adding a separate option for IPv6.
Regards,
Jan
2 Pro
2 Pro
16:34
New subject: forcing minimal fragment size for IPv6 datagrams
On 2016-06-23 12:50, Jan Včelák wrote:
Hi Anand,
Geoff Huston has continued his research [1] and his result look
disappointing. If I understand RFC 8085 section 3.2 correctly in the
context of DNS and IPv6, PMTUD and PLPMTUD do not work for DNS because
DNS uses only a single request and reply packet and any form of path MTU
discovery would make it loose its latency advantage over TCP. You could
think about path MTU discovery in a DNS resolver that caches the path
MTU for frequently queried servers though. Otherwise it seems best to
set max-ipv6-udp-payload to 1232 or an even lower value that accounts
for extension headers.
I think Jen Linkova's remark at the end of the talk about MPLS is right,
as the LER should already reject ICMPv6 PTB message before it lets an IP
packet enter the MPLS network. So the remaining problems with IPv6
fragmentation are anycast and other forms of load balancing and
misconfigured firewalls and other middle boxes. Anycast and load
balancing are debatable concepts but RFC 7690 outlines some solution to
the problem. And if you run an anycast network, you are used to such
problems. So the remaining problem are misconfigured firewalls and other
middle boxes. They should be dealt with like any misconfigured IPv6
equipment. I think we have made a lot of progress in this area as IPv6
deployment continues to expand. So I think there is a reasonable chance
that setting max-ipv6-udp-payload to a low value will not be necessary
in the future.
- Matthias-Christian
https://ripe75.ripe.net/archives/video/181/
If it were me, I would instead use the
"max-udp-payload" option, set to
1280, so that Knot emits responses with TC set. This may cause some
clients to retry over TCP. But one missing feature in Knot is that it
doesn't allow tuning of the EDNS payload separately for IPv4 and IPv6.
It might be useful to have "max-udp-payload-ipv4" and
"max-udp-payload-ipv6" options for setting this separately, because IPv4
and IPv6 behaviours are different.
Thank you for the input! This sounds to be a better solution than
forcing the fragmentation. Based on the conclusions from the Geoff's
experiment... We will consider adding a separate option for IPv6.
2546
days inactive
3075
days old
7 comments
4 participants
participants (4)
-
Anand Buddhdev -
Jan Včelák -
Matthias-Christian Ott -
Robert Edmonds