On Mon, 26 Sep 2005, Hallam-Baker, Phillip wrote:
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Tim Bray
On Sep 24, 2005, at 8:28 PM, Dean Anderson wrote:
None of my emails have been abusive.
Speaking as a 99.99999999% passive observer around here, I consider
Dean Anderson's emails, in aggregate, abusive. They consume precious
mental bandwidth, in many cases with no material technical content,
and thus make it more difficult for me (and I assume many others) to
follow the flow of IETF discussion.
I am completely unable to follow the line of argument.
Dean appears to be claiming that DNSSEC is somehow incompatible with the
widespread use of anycast. If for the sake of argument we accept this as
true the only conclusion I could draw from such a situation is that
DNSSEC would have to be sent back to be reworked again. If DNSSEC does
not support existing use cases then it has to be fixed.
It is not DNSSEC that is broken.
But I do not see how DNSSEC is incompatible with anycast. It is merely
an assertion that is repeated without evidence. Anycast might possibly
There has been plenty of evidence on the DNSOP list and most recently on the
GROW list. Without getting into to much detail, Anycast doesn't work with TCP,
but it also doesn't work with large UDP packets and fragments. DNSSEC requires
large UDP packets and fragments. The details of why fine grained load balancing
permitted by RFC1812 break the Anycast Extension are hinted at in RFC1546 and
the footnotes to my instant criticism on DNSOP. I can send you a more detailed
explanation if you like offlist.
Your assumption below is common: You assume that everyone does course grained
load balancing or no load balancing. Besides RFC1812 permitting fine grained
load-splitting in "theory", Cisco implements it. There are active programs
underway such as BGP multipath, which also results in fine grained
load-splitting. One cannot assume that two successive packets are delivered to
the same path or that two successive packets will reach the same Anycast
destination. This is acceptable for small, stateless UDP packets. It is not
acceptable TCP or large UDP packets and fragments.
break TCP/IP fallback but it is unlikely that the anycast routes would
change rapidly enough for that effect to be any more significant than
existing TCP issues created by firewalls.
Cryptography is remarkably indifferent to transport, this is the biggest
challenge in the DKIM spec. Depending on particular transport
configurations has in the past turned out to be a mistake. The
authentication of the end point IP addresses in IPSEC achieves no useful
security purpose, it only causes the protocol to become more brittle in
use.
If the issue is real then it should be raised in DNSEXT where the DNSSEC
specs are being developed. It does not appear to be genuine to me.
Its not a problem with DNSSEC per se. It a problem with operation of Anycast
Root Nameservers. There should not be any Anycast root nameservers.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf