Le 2 nov. 2010 à 16:39, james woodyatt a écrit : > Not disagreeing with you, but I would like to point out that the perceived > security benefits of NAT, which seem to folks like Mr. Engel and Mr. Marquis > to apply to TCP, apply to a much lesser degree to SCTP. Due to the inherent > multihoming nature of SCTP, the "default fail closed" behavior of NAT both > protects less and interferes more than with TCP.
Sorry for my hesitation. We do agree. Best regards, RD > > --jhw (sent from my phone) > > On Nov 2, 2010, at 8:22, Rémi Després <[email protected]> wrote: > >> Hi, James, >> >> For clarification, is your comment just a positive remark about SCTP, or is >> it suggesting that SCTP could work without hosts knowing their global >> addresses. >> (If it is the former, it doesn't go against what I wrote; if it is the >> latter, I don't see how it can work.) >> >> Regards, >> RD >> >> Le 2 nov. 2010 à 16:05, james woodyatt a écrit : >>>> On Nov 2, 2010, at 01:25 , Rémi Després wrote: >>>> ... >>>> SCTP depends on hosts knowing their global addresses, and the same holds >>>> for SHIM6. >>>> Both are therefore incompatible with all variants of NAT66 as specified >>>> today. >>> >>> Actually, SCTP uses IP addresses in pretty much the same way as TCP and >>> other connection-oriented transport protocols. From the perspective of a >>> NAT, however, the requirements to maintain state for SCTP are quite a bit >>> simpler than for TCP and other protocols. You only need to hold onto the >>> interior and exterior IP addresses of the association endpoints, unified by >>> the verification tag for each association. No port translation is >>> necessary-- it's not even helpful for the purposes of address >>> amplification. The addresses are amplified in the 32-bit verification tag, >>> not the port numbers. >> >> _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
