[dns-operations] The trouble with SCTP.
dotis at mail-abuse.org
Thu Feb 4 20:14:45 UTC 2010
On 2/3/10 5:41 AM, Paul Vixie wrote:
> so far so good. surprisingly few stateful firewalls blast away TCP options
> especially the ones that require an extension that puts some of them where
> the payload usually is.
> in testing thus far, this stuff gets through when UDP/53 does not and when
> a new protocol like SCTP (which i'd otherwise have preferred) would not.
With increased use of memory w/o ECC, and TCP's inability to detect ~2%
the packets affected by bus interface issues means having an option for
something other than TCP or UDP is needed to improve data integrity.
For some background, I was working within a storage forum, where a major
OS vendor developing network attached storage using TCP made their
presentation. When asked during the meeting how they recovered from
protocol incoherency states, their response was remarkable. "We have
found customers would rather have bad data than no data." When then
asked whether logs might indicate the frequency of such occurrences,
"No. Our customer support would be unable to handle the resulting
support calls." After some astonishment at the honesty of these
answers, someone then exclaimed. "I hope you're not doing this for a
bank." The engineer proudly exclaimed, "This is being used by Bank of
At the IETF meeting in Hiroshima, I asked Joe Touch about TCP's
inability to detect commonly occurring errors. His reply was that TCP
is not responsible for telco bit error rates, saying its a problem that
must be dealt with at the physical interface. I attempted to explain
that the concern was not related to telco bit error rates, but rather
was related to TCP's error detection algorithm having the modulo of
common error modes. He then said that TCP includes an option for
different error checks, but of course that would set the clock back more
than a decade, without resolving other fundamental issues related to TCP
DDoS and transactional security.
At the prior IETF meeting, the Internet Journal distributed in Stockholm
included misinformation related to SCTP as not being suitable for high
volume applications with statements based upon quotes more than 6 years
old. The impression made ignored availability of commodity NICs that
offload SCTP at 10Gb/s and 1Gb/s, and processors with math coprocessors
able to calculate CRC32c over a block of data by a single instruction.
CRC32c also extends error protection for Jumbo frames with its increased
Hamming distance over that of the Ethernet CRC.
If a standards body or government were to mandate use of SCTP for
critical infrastructure, such as electrical grid control or DNS, then
CPE equipment unable to support DNS over TCP would actually be in a
better position to support SCTP since it offers assured framing while
allowing unreliable unordered delivery. This mode would not require
caching to handle PMTU issues, while still ensuring transaction
integrity. ISPs could offer standard DNS resolvers to keep legacy
equipment functional during the transition.
Looking for partial TCP related solutions during disruptive changes
caused by IPv6 tunneling or DNSSEC misses an opportunity to usher in a
better foundation for creating a safer Internet. The transitional goals
should consider what is required to ensure stability and integrity at
the ISP first. There will be time to resolve last mile issues later.
Some have complained that SCTP frames are too complex compared to TCP's
nebulous byte stream. However, this framing allows immediate placement
of data in most cases, even within chained queries and responses.
More information about the dns-operations