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

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

Comments below ... 

Randall Stewart wrote:
> Comments inline..
> 
> Schruefer Wolfgang wrote:
> > Qiaobing,
> > 
> > Qiaobing Xie wrote:
> > 
> >> Schruefer Wolfgang wrote:
> >> 
> >> 
> >>> Hello,
> >>> 
> >>> yesterday Melinda gave us the advice to consider the larger
> >>> context... Therefore I will try first to explain my motivation by
> >>> an example instead of technical details:
> >>> 
> >>> ********************************************* Example (I will use
> >>> Luca's scenario):
> >>> 
> >>> - A client application on host X needs Interface redundancy, but
> >>> unfortunately SCTP can not establish a multihomed Association due
> >>> to NAPT...
> >>> 
> >>> 
> >>> 
> >>>> SCTP   (A+)-------------N
> >>>> SCTP HOST X (  )
> >>>> A--E+-------------cloud------------+--HOST Z (B+)------------ P
> >>>>  T
> >>> 
> >>> 
> >>> - But 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.
> >> 
> >> I assume you meant that they were 2 singled homed associations with
> >> HOST Z, i.e., A<->Z and B<->Z.
> > 
> > 
> > Yes, exactly. I wanted just to make it simple. Please see 
> the NAPT as
> > a cloud with random Address and Port translations, not as a single
> > box.
> > 
> > 
> > 
> > 
> >>> And you see: The application has a multihoming
> >> 
> >> functionality, it uses SCTP and it is behind a NAPT!
> >> 
> >>> **********************************************
> >>> 
> >>> What I expect:
> >>> 
> >>> If the application can realize multihoming, SCTP should be
> >> 
> >> able to do it also. Probably better.
> >> 
> >>> Do I really expect too much???
> >> 
> >> But why this is a question unique to SCTP? Your smart application
> >> should be able to do the same with two TCP connections, right? If
> >> so, maybe your challenge should be: should any transport be able to
> >> do it also.
> > 
> > 
> > 
> > This question is unique to SCTP, because it is the unique protocol
> > that claims the multihoming feature. Let me cite the introduction of
> > the SCTP RFC: "SCTP ... offers the following services to its users: 
> > --... -- network-level fault tolerance through supporting of multi- 
> > homing at either or both ends of an association."
> > 
> > 
> > Sure, as you agree that an application might implement its own
> > multihoming if SCTP fails, it would not need SCTP. Then a smart
> > application might use TCP or even UDP...
> > 
> > But the transport protocols should provide best service to
> > applications to make things easier and with as less restrictions as
> > possible. That is why I think the multihoming and port numbering
> > restrictions should be a topic for future SCTP improvement.
> > 
> 
> So you want to change a fundamental design concept to accomadate
> a hack called NAT.

... not fundamental ... just an extension

> 
> 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 

> 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 ...

> 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??? 

Best regards,
Wolfgang

> 
> R
> 
> 
> 
> > Best regards, Wolfgang
> > 
> > 
> > 
> >> regards, -Qiaobing
> >> 
> > 
> > 
> 
> 
> -- 
> Randall Stewart
> ITD
> 803-345-0369 <or> 815-342-5222
>

---

From: Randall Stewart <[email-masked]>
Date: Thu, 17 Feb 2005 14:39:04 -0800 (PST)

... 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..

... 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

... 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.

*********************************************
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....)

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.
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.
It would have to have all of the tracking information 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.
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..
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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 17 Feb 2005 14:46:13 -0800 (PST)

Wolfgang,

...
Example:

You are talking about failover from one SCTP association to another. This is covered in 
RSERPOOL, not SCTP.

regards,
-Qiaobing

My vision:

My question:

Best regards,
Wolfgang