Subject: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP

From: Schruefer Wolfgang <[email-masked]>
Date: Tue, 15 Feb 2005 04:11:11 -0800 (PST)

> So there's no way to tell a peer about two different ports without an 
> extension, yes?

yes, without an SCTP extension it is not possible to use different ports and to 
overcome this problem.

Best regards,
Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] Im Auftrag 
> von Spencer Dawkins
> Gesendet: Dienstag, 15. Februar 2005 06:15
> An: Ietf-behave@xxxxxxxxxxxxxxxxxxx
> Betreff: Re: [Ietf-behave] Ietf-behave] Re: NATting SCTP
> 
> > why do you think an extension for multiple destination ports would 
> > make SCTP a different protocol?
> >
> > Please consider that the SCTP protocol would remain untouched for 
> > all existing scenarios.
> > Only if NAPT is involved such an SCTP extension may be used.
> 
> OK, I'll bite...
> 
> I was assuming (bad assumption?) that two different IP 
> addresses might 
> very well be on two different physical interfaces, on two separate 
> subnets, so a single NAPT won't be on both paths in the general case. 
> So a single NATP can't diddle with with the port numbers for both IP 
> addresses, right? So if you're going to use two separate interfaces 
> through multiple NAPTs, you're going to have to tell your peer about 
> two different ports, and that will require mods to the peer - a much 
> tougher deployment scenario than just me talking to my local NATP.
> 
> My copy of RFC 2960 shows these options for the INIT chunk:
> 
>          Variable Parameters                  Status     Type Value
>          -------------------------------------------------------------
>          IPv4 Address (Note 1)               Optional    5
>          IPv6 Address (Note 1)               Optional    6
>          Cookie Preservative                 Optional    9
>          Reserved for ECN Capable (Note 2)   Optional    32768 
> (0x8000)
>          Host Name Address (Note 3)          Optional    11
>          Supported Address Types (Note 4)    Optional    12
> 
> So there's no way to tell a peer about two different ports without an 
> extension, yes?
> 
> What am I not understanding?
> 
> Spencer 
> 
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Schruefer Wolfgang <[email-masked]>
Date: Tue, 15 Feb 2005 06:49:53 -0800 (PST)

> To the contrary - I think that in the past the IETF has made
> some big balls of wax by failing to consider the larger context
> when attacking problems as if they're unrelated.  

Yes, let's do it better ;-) 

> ...  Only changing the handling of port numbers is
> not sufficient.

It might be not sufficent, but for NAT it is ABSOLUTELY FUNDAMENTAL to know 
whether the port number can be changed or not.
In my opinion this question is definitly part of any larger context, do you 
agree?

Best regards,
Wolfgang 

> Von: Melinda Shore [mailto:mshore@xxxxxxxxx] 
> Gesendet: Dienstag, 15. Februar 2005 14:29
> An: Schruefer Wolfgang
> Cc: Ietf-behave@xxxxxxxxxxxxxxxxxxx
> Betreff: Re: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP
> 
> On Tuesday, February 15, 2005, at 06:38 AM, Schruefer Wolfgang wrote:
> > But I think it is not useful to close a discussion about 
> one problem 
> > by refering to the unsolved other problem.
> 
> To the contrary - I think that in the past the IETF has made
> some big balls of wax by failing to consider the larger context
> when attacking problems as if they're unrelated.  In this case
> SCTP is the most difficult protocol I've encountered to get across
> NATs, and I'm wondering just how far we're willing to go to get
> it to work.  Only changing the handling of port numbers is
> not sufficient.
> 
> Melinda
>

---

From: Schruefer Wolfgang <[email-masked]>
Date: Thu, 17 Feb 2005 15:14:13 -0800 (PST)

Please see inline ...

Randall Stewart wrote:

> Schruefer Wolfgang wrote:
> > Randy,
> > 
> > Randall Stewart wrote:
> > 
> >> Spencer:
> >> 
> >> That is why I wondered about Wolfgang's proposal.
> >> 
> >> You need seperate NAPT's on seperate boxes... to get diversity and
> >> no single point of failure..
> >> 
> >> You won't get that with Wolfgang's picture...
> > 
> > 
> > Sorry, the picture was misleading, I just wanted to make it 
> as easy a
> > possible ... Please see the NAPT as a cloud with random Address and
> > Port translations, not as a single box.
> > 
> 
> If you have two random NAPT's scattered amongst the cloud
> somewhere.. .then how would you ever coordinate the heartbeating?
> 
> If you have two seperate IP addresses on the NAT's then
> you have a problem with only one side will get the INIT
> (or INIT-ACK) to populate the state.. and, since SCTP only
> knows about its internal private addresses thats all it
> can list in its INIT... And right now we specifically tests
> at inter-ops that SCTP endpoints DON'T do this so they can
> get through NAT's singly homed.

Forget the address list within an INIT. I agree that this would not work
The SCTP extension would need a new procedure to establish the secondary path
 ... e.g if you send a second INIT via the alternate path

Then you avoid most problems addressed below ...

Wolfgang

> 
> So... you would then need NAT'a KNOWING that NAT'b was
> at a different address... and knowing its address and then
> somehow talking to it to get state set in.. once you have
> the two NATs talking I think it should be no problem to
> coordinate what ports are handed out.. and then.. tada
> SCTP works as is through a NAT.. we just need to get the above
> fixed in SCTP implementations.. i.e. go ahead and list
> your private addresses...
> > 
> > 
> >> And then the only way I can think of is to either a) have a
> >> nat-2-nat protocol... talk about way ugly
> >> 
> >> or
> >> 
> >> b) have a way to have SCTP use different ports.. which is not
> >> allowed by the spec (and rightly so in my mind). Changing it,
> >> especially since 99.9 % of all napt's know nothing about SCTP yet,
> >> is like having the tail wag the dog... IMO. You don't design a
> >> transport protocol FOR NAT's...
> > 
> > 
> > By this argumentation You'll have a dog biting its tail ... NATs
> > would not implement SCTP because SCTP does not support NAT ... SCTP
> > would not support NAT because NATs do not support SCTP ...
> > 
> > 
> 
> A Nat can support SCTP the same way it supports TCP.. aka
> singly homed. There is no problem with this at all.
> 
> 
> > 
> >> So.. not sure of a multi-homing solution for SCTP and NAT. Singly 
> >> homed will work just fine (as long as napt's will implement it).
> >> 
> > 
> > 
> > Please let me summarize your words:
> > 
> > We have 3 Options:
> > 
> > a) nat-2-nat protocol: (... ugly ...) b) bring SCTP to use different
> > ports  (... not needed...) c) forget NAT usage for SCTP ...
> > 
> No..
> 
> Lets first GET NAT's working with singly homed SCTP. Thats the
> FIRST step.. there are problems to address in that (I know
> from experience) world...
> 
> Then, the next step is to try to get M-Homed working in some way.. and
> that MAY take an ugly NAT-2-NAT protocol.
> 
> We don't go re-design the base spec to fit NAT's.. What we
> do is get NAT's working for the general case (singly homed) then
> we can discuss the more complex area .. which by the way .. will
> have less demand.
> 
> R
> 
> > If everybody shares your opinion I think we can close the 
> discussion.
> >  I personally do not agree, I would continue with option b) ...
> > 
> > Best regards, Wolfgang
> > 
> > 
> > 
> > 
> >> R
> >> 
> >> Spencer Dawkins wrote:
> >> 
> >>> Randall,
> >>> 
> >>> Thanks for popping in here.
> >>> 
> >>> My concern is about "multihoming solutions" that would require
> >>> two different IP interfaces (chosen for diversity) to point
> >> 
> >> traffic to the
> >> 
> >>> same NATP box (so it can assign the same outgoing
> >> 
> >> translation port to
> >> 
> >>> both interfaces).
> >>> 
> >>> It seems to me that inserting a single point of failure,
> >> 
> >> regardless of
> >> 
> >>> its reliability, into a multihoming solution isn't quite
> >> 
> >> solving the
> >> 
> >>> right problem.
> >>> 
> >>> If I chose two interfaces that home through two different
> >> 
> >> ISPs, traffic
> >> 
> >>> to two ISPs would have to traverse the same NATP in order
> >> 
> >> to pull this
> >> 
> >>> off (or we could insert a NATP-to-NATP protocol that would keep 
> >>> translation ports synchronized, but...).
> >>> 
> >>> Thank you for pointing out the "don't heartbeat to both IP
> >> 
> >> addresses"
> >> 
> >>> problem. I hadn't thought of that.
> >>> 
> >>> I agree that things are getting ugly fast. I'm not sure
> >> 
> >> everyone has the
> >> 
> >>> same definition of "ugly" in this thread.
> >>> 
> >>> Spencer
> >>> 
> >>> 
> >>>> Now, the problem here is that of ports... which is why you are
> >>>> asking for SCTP to have multiple ports.
> >>>> 
> >>>> And I would argue that if your NAPT's is written to handle two
> >>>> interfaces, it could also assign the same outgoing translation
> >>>> port to both interfaces (if it knew that the SCTP endpoint was
> >>>> multi-homed by looking inside the INIT/INIT-ACK). Of course it
> >>>> would then have to do some method to use both networks. I.e. 
> >>>> how would it decide to fail over.. it can't know what the end's
> >>>> are doing.. and of course the multi-homed nature would be
> >>>> hidden from the peer Host-Z which would mean it would not know
> >>>> to HB a seperate address.
> >>>> 
> >>>> This gets ugly fast...
> >>>> 
> >>>> If the base protocol had seperate ports allowed.. you might be
> >>>> able to do it... but that is a major change to the protocol..
> >>>> 
> >>>> R
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________ Ietf-behave
> >>> mailing list Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> >> -- Randall Stewart ITD 803-345-0369 <or> 815-342-5222 
> >> _______________________________________________ Ietf-behave mailing
> >> list Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> -- 
> Randall Stewart
> ITD
> 803-345-0369 <or> 815-342-5222
>

---

From: Schruefer Wolfgang <[email-masked]>
Date: Thu, 17 Feb 2005 15:44:24 -0800 (PST)

Please see inline...

Randall Stewart wrote: 
> >>So you want to change a fundamental design concept to accomadate
> >>a hack called NAT.
> > 
> > 
> > ... not fundamental ... just an extension
> The way implementations find associations with ports and addresses
> is a fundamental design issue that every SCTP implementation
> that i have seen must deal with... Changes in ports and addresses
> mean fundamental changes to this..
> 
> 
> > 
> >>And on top of that, I know of NO NAT's that yet implement SCTP.. 
> > 
> > 
> > ... actually NATs only need to learn how to calculate SCTP checksum
> > ... this is not so complicated ... IMO 
> 
> And ports and state .. there are issues here.. you just
> have to dig a bit deeper into the problem.. like try
> to make it work correctly :0-
> > 
> > 
> >>yes
> >>I have worked on a BSD version of one but its not released or even
> >>fully tested yet.... So we have roughly 25-30 different 
> >>implementations
> >>of SCTP many being used in production environments.. and 
> you want all
> >>of them to go through major changes so you can make 
> implementing SCTP
> >>over NAT's more easy.. 
> > 
> > 
> > ... same procedure as implementing ADDIP, some may do, some not ...
> 
> No you can't have optionial extra ports.. one side
> must always be aware of it.. which means all sides must
> be aware of it since neither will know when a NAT does
> something.
> 
> 
> > 
> > 
> >>And yes it is major changes since you are
> >>talking about the fundamental method that associations are
> >>found via..
> >>
> >>And it does not help solve the single point of failure 
> >>issue... either..
> >>nor does it help with HB'ing and all the other things.
> >>
> >>In fact it solves very little of the true M-Homing NAT 
> problem.. which
> >>IMO is a need for a Nat-2-Nat communication protocol to 
> allow two NATs
> >>to assign the same port numbers and communicate state to each other.
> >>
> >>Especially since very few nats are configured per your 
> drawing... IMO
> > 
> > 
> > 
> > Here I will bring again my example about application multihoming.
> > Now with a better drawing, hopefully. 
> > None of your problems appeare ...
> > 
> > 
> > *********************************************
> > Example:
> > 
> > - A client application on host X needs Interface redundancy, 
> >   but unfortunately SCTP can not establish a multihomed 
> Association due to NAPT... 
> > - I assume this NAPT box is able to handle SCTP like TCP ...
> > 
> >   
> >    SCTP   (A1, Port P)----- NAPT(A2,P1)----cloud            
>    SCTP  (here single
> >    HOST                                    
> cloud------------+--HOST   homed for 
> >     X     (B1, Port P)----- NAPT(B2,P2)----cloud            
>     Z     easier drawing....)
> >    
> > 
> > - The application is smart: it creates 2 singled homed associations:
> >   a primary association containing Addr A as Source Address 
> and a secondary containing Addr B as Source Address.
> > - If Association A fails, the application continues data 
> transfer using association B.
> > 
> > And you see: The application has a multihoming 
> functionality, it uses SCTP and it is behind a NAPT!
> > 
> > **********************************************
> > 
> > My vision:
> > If the application can realize multihoming, SCTP should be 
> able to do it also. Probably better. 
> > 
> > My question:
> > Why is impossible and a fundamental change to implement 
> this application logic within SCTP??? 
> 
> Because, in your drawing, you get to send two different INIT's
> one to B-side and one to A-side. this allows propagation
> of independant state in two seperate NAT's. This also
> allows the SCTP stack at Z to deal with them
> as just that two assocaiations.. indexed by port etc.

Yes, but what is wrong about that? It is no fundamental change ...

> 
> If you somehow magically were allowed two different ports
> on the same association then the ONLY way it would work
> is if Host-Z was capable of handling this strange behaviour.

Yes Host-z needs to store the remote port number per path.

> It would have to have all of the tracking information

no, nothing more than it has by two single-homed associations ...

> AND
> Host-A also needs to do soemthing as well to propagate state
> into the NAT it did NOT use to setup the association... and thus
> communicate with Z the new port number.

no, Host-A uses both NATs for setup, any NAT should handle a path similar to an 
independend single homed association ...

> 
> All of which is a fundamental change to SCTP's design.
> 
> Lets first go fix the real problem.. getting NAT's and SCTP
> singly homed to work..

Sure, that is the base, and additionally a vision of multihoming may push it ...

regards,
Wolfgang

> 
> Once that gets fixed we can play in the "weeds" as Melinda puts it :-D
> 
> I do like to fish for Stripe Bass.. lets save that for another day
> though ;-D
> 
> R
> 
> > 
> > 
> > Best regards,
> > Wolfgang
> > 
> > 
> >>R
> >>
> >>
> >>
> >>
> >>>Best regards, Wolfgang
> >>>
> >>>
> >>>
> >>>
> >>>>regards, -Qiaobing
> >>>>
> >>>
> >>>
> >>
> >>-- 
> >>Randall Stewart
> >>ITD