* Paul Vixie:
there is no server side protocol control block required in SCTP.
SCTP needs per-peer state for congestion control and retransmission.
someone sends you a "create association" request, you send back a "ok, here's your cookie" and you're done until/unless they come back and say "ok, here's my cookie, and here's my DNS request." so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do.
This is a red herring. The TCP state issues are deeper and haven't got much to do with source address validation. The issues are mostly caused by how the BSD sockets API is designed. SCTP uses the same API model, and suffers from similar problems.
because of the extra round trips nec'y to create an SCTP "association" (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches.
This doesn't seem possible with current SCTP because the heartbeat rate quickly adds up and overloads servers further upstream. It also does not work on UNIX-like system where processes are short-lived and get a fresh stub resolver each time they are restarted. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99