Subject: RE: [Tsvwg] SCTP and NAT

From: Tuexen Michael <[email-masked]>
Date: Tue, 16 Apr 2002 13:35:33 +0200

Hello,

please see my comments in-line.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Poetzl, Joachim [SMTP:[email-masked]]
> Sent:	Thursday, April 11, 2002 4:44 PM
> To:	[email-masked]
> Subject:	[Tsvwg] SCTP and NAT
> 
> Hi SCTP experts,
> 
> who can help?
> 
> Does SCTP work with NAT? 
> What are the related drafts and RFCs?
> Any experience on that topic?
	[Tuexen Michael]  You may want to look into the very new RFC
	http://www.ietf.org/rfc/rfc3257.txt

> What are advantages / disadvantages using SCTP in conjunction with TLS or IPSec?
> 
> What about the discussion on the TLS over SCTP Draft (draft-ietf-tsvwg-tls-over-sctp-00.txt)? The draft is still in version 0.
	[Tuexen Michael]  It is still in version 00, but has completed the WG last call and the IESG last call just started today.

> Thanks for your help in advance.
> 
> Regards
> 
> > Joachim P> ötzl
> > 
> ........................................................................................
> Deutsche Telekom AG
> Zentralbereich Netzinfrastruktur (ZB NI)
> NI196a13; Signalling, Gateways and Switching Systems
> 64307 DARMSTADT, GERMANY 
> Phone:  +49 6151 83-2134
> Fax:      +49 6151 83-4577
> email:	[email-masked]
> ........................................................................................
> 
> 
> 
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Coene Lode <[email-masked]>
Date: Tue, 16 Apr 2002 15:46:05 +0200

A few comments below:

> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 2:58 PM
> To: Poetzl, Joachim
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP and NAT
> 
> 
> A small comment or two..
> 
> "Poetzl, Joachim" wrote:
> 
> > Does SCTP work with NAT?
> 
> I think Michael as pointed out a "new" RFC that discusses this in
> some detail. But I will add a few rambling thoughts on the matter....

Another draft, originally part of the "new" RFC 3257 describes this a bit in
more detail.
see http://search.ietf.org/internet-drafts/draft-coene-sctp-multihome-03.txt
It got a bit lost but I am trying to put it back on the track for
informational

> 
> NAT's WILL work with SCTP if you are talking singly homed and the
> SCTP implementation as enough address selection sense to NOT include
> any addresses in the address list. I believe our implementation on
> BSD will do this (available at http://www.sctp.org and soon it
> will be released as part of kame). The basic idea is that the 
> SCTP implementation behind the NAT must realize it has a private
> address and then only send either the INIT or INIT-ACK back to
> the "global" address without listing any of its addresses.
> 
> If the SCTP implementation is multi-homed and would like to 
> be able to take advantage of that ... say something like:
> 
>            (Private Address)-----NAT-1-----IP-X(Global address)
>     IP-P1-----+
> SCTP
>     IP-P2-----+
>            (Private Address)-----NAT-2-----IP-Y(Global address)
> 
> The SCTP implementation would require assistance from the two
> NAT's in order to make this work..
> 
> You would need the NAT's to:
> 
> 1) Do stateful inspection of the address lists and substitute
>     IP-P1/IP-P2 for IP-X and IP-X (in the INIT/INIT-ACK messages). 
> 2) Communicate with the peer NAT through some mechanism to
>    allocate a COMMON port number and setup the mapping.
> 3) Coordinate the tear down of this state when the association
>    ends.. note that EITHER side could get the tear down indication.
> 
> I don't believe there is ANY way this can be done today without
> further work on NAT's which I DO NOT advocate. A far better way
> to get multi-homing is to move to IPv6 and then both sides can
> have nice global addresses :>
> 
> R
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

Agree with problem description. 
Solutions:
INIT, INIT-ACK and data traffic goes through a single NAT box and then you
get a single point-of-failure. Not what you are looking for...
or
you do some NAT-NAT communication coupled together with some SCTP-NAT
communication(and that should only be the simple case where only one of the
endpoint is behind a NAT, I wouldn't even dream of multiple NAT box crossing
in-between) 
Thus the solution would be invariably complex.

Therefore the simplest solution is to have NO NAT between your endpoints.
- own private IPv4 network(but doesn't solve the requirement below)
- need interconnecting with a different operator, well then IPv6 springs to
mind.

yours sincerly,
Lode 

Siemens atea
atealaan 34          2200 Herentals, Belgium
E-mail: [email-masked]
Tel: +32-14-252081
Fax: +32-14-253212