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

From: Schruefer Wolfgang <[email-masked]>
Date: Wed, 16 Feb 2005 08:51:36 -0800 (PST)

Randy,

> ... your NAPT's could also assign the same outgoing
> translation port to both interfaces 
> ... this gets ugly fast...

I agree! And all discussion about this approach failed because it led to huge 
problems ...

> If the base protocol had seperate ports allowed.. you might
> be able to do it... but that is a major change to the
> protocol..

But this seems to me is the only way to proceed! We need a discussion about it.
What is a blocking point for this approach?
I expect: when it is possible to establish two sigle-homed association between 
two host through NAPT, it should also be possible to establisch two paths 
between them.

Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: Randall Stewart [mailto:rrs@xxxxxxxxx] 
> Gesendet: Mittwoch, 16. Februar 2005 13:05
> An: Schruefer Wolfgang
> Cc: Qiaobing Xie; Luca Laurenzi; Ietf-behave@xxxxxxxxxxxxxxxxxxx
> Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP
> 
> Wolfgang:
> 
> Comments below...
> 
> 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.
> > 
> > And you see: The application has a multihoming 
> functionality, it uses SCTP and it is behind a NAPT!
> 
> Well.. I see your point.. but you would have
> to have a NAPT that understood SCTP and that
> would open more than one interface as the
> "private address" side. FreeBSD at least
> is not capable of doing this..
> 
> Yes, I can setup two NAPT's .. I have done
> that.. but each had to have an independant
> network to route out... aka two DSL's, which
> I used to have :-D
> 
> 
> 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
> 
> 
> > 
> > **********************************************
> > 
> > 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???  
> > 
> > 
> > Best regards,
> > Wolfgang
> > 
> > 
> > 
> > 
> > 
> >>-----Ursprüngliche Nachricht-----
> >>Von: Randall Stewart [mailto:rrs@xxxxxxxxx] 
> >>Gesendet: Dienstag, 15. Februar 2005 21:24
> >>An: Qiaobing Xie
> >>Cc: Schruefer Wolfgang; Luca Laurenzi; 
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> >>Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP
> >>
> >>Q:
> >>
> >>Ok, I give up... I will subscribe to behave kicking and screaming
> >>to try to avoid one more mailing list :-D
> >>
> >>Comments below..
> >>
> >>Qiaobing Xie wrote:
> >>
> >>>(added Randy to the cc list since he's not seeing email on 
> >>
> >>behave list)
> >>
> >>>Hi, Wolfgang,
> >>>
> >>>Please see my comments in-line.
> >>>
> >>>Schruefer Wolfgang wrote:
> >>>
> >>>
> >>>>Qiaobing,
> >>>>
> >>>>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.
> >>>>
> >>>>Please consider that only the DESTINATION transport 
> >>
> >>addresses should 
> >>
> >>>>be allowed to contain multiple port numbers. For the 
> LOCAL address 
> >>>>handling the design with a unique port remains untouched.
> >>>>
> >>>>Multiple destination ports would affect only the addressing of 
> >>>>outgoing packets to an multihomed peer behind a NAPT. Before the 
> >>>>packets arrive at the peer NAPT would retranslate the 
> >>
> >>addresses back 
> >>
> >>>>to an unique port number. This is the reason why SCTP 
> >>
> >>would not need 
> >>
> >>>>to handle multiple local port numbers. 
> >>>
> >>I too, like Q, am a bit confused.. and I have probably missed
> >>some of the discussion.. yes.. I know I should go back and
> >>read the archive.. but alas .. I have not the cycles..
> >>
> >>What Wolfgang could be advocating is something more like:
> >>
> >>host-a          NATP                              host-z
> >>
> >>----IP-a --INIT--->
> >>----IP-b
> >>     (src-port:1)
> >>
> >>                 IP-A:src-P2
> >>                 IP-B:src-P3 ------->
> >>
> >>But unless you had yet another NATP at the other side then host-z's
> >>SCTP stack would need to be aware of the multiple ports... which
> >>would be confusing and more complex..
> >>
> >>
> >>
> >>
> >>
> >>>I guess I still do not fully understand what you are 
> >>
> >>proposing. Let's 
> >>
> >>>see the following example - an INIT/INIT-ACK exchange 
> >>
> >>through a NAPT. 
> >>
> >>>Which one would be the DESTINATION transport address that 
> >>
> >>you would like 
> >>
> >>>to see with multiple port numbers?
> >>>
> >>>  End A                       NAPT                        End B
> >>>{IP-A, IP-B/p1}                ##                      
> >>
> >>{IP-X, IP-Y/p3}
> >>
> >>>INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3)
> >>>    (dst: IP-X/p3)                  (dst:IP-X/p3)
> >>>
> >>>(p1)<---INIT_ACK(src:IP-X,IP-Y/p3) 
> >>
> >>##<------INIT_ACK(src:IP-X,IP-Y/p3)
> >>
> >>>                (dst: IP-A/p1)                      (dst:IP-M/p2)
> >>>
> >>
> >>The above looks to me like what a regular NAPT does.. i.e. 
> End-A gets
> >>p1 and yet End B sees p2... this is no problem without changing
> >>the protocol... only if multiple addresses are involved is
> >>there an issue I think... and this may be what Wolfgang is trying
> >>to solve..
> >>
> >>Wolfgangs.. clearfications for Q and I would be most welcome .
> >>
> >>R
> >>
> >>
> >>
> >>>regards,
> >>>-Qiaobing
> >>>
> >>>
> >>
> >>
> >>-- 
> >>Randall Stewart
> >>ITD
> >>803-345-0369 <or> 815-342-5222
> > 
> > 
> > 
> 
> 
> -- 
> Randall Stewart
> ITD
> 803-345-0369 <or> 815-342-5222
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 16 Feb 2005 09:07:05 -0800 (PST)

On Wednesday, February 16, 2005, at 11:51 AM, Schruefer Wolfgang wrote:
I expect: when it is possible to establish two sigle-homed association 
between two host through NAPT, it should also be possible to 
establisch two paths between them
The conditions are profoundly different.  In the multi-homed SCTP
case there's a need for one single endpoint to explicitly signal
a list of addresses, which means it must either know those addresses
or those addresses must be fixed-up in transit by the NATs.  That
problem will not be fixed simply by adding support for multiple
ports to SCTP.
I think it's important to take Spencer's earlier comment to heart -
if the intent behind multi-homing SCTP connections is to provide
robustness and failure resistance, introducing inherently brittle
mechanisms into the network in order to get SCTP to work across NATs
is almost certainly working against your own interests.
Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 16 Feb 2005 13:18:24 -0800 (PST)

Hi, Melinda

....
I think it's important to take Spencer's earlier comment to heart -
if the intent behind multi-homing SCTP connections is to provide
robustness and failure resistance, introducing inherently brittle
mechanisms into the network in order to get SCTP to work across NATs
is almost certainly working against your own interests.
Yes, having the NAPT be able to retain the e2e path diversity is certainly ideal and would 
be the complete and perfect solution. But I disagree with your above view, since I believe a 
partial solution is till way better than no solution.

regards,
-Qiaobing
Melinda
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Randall Stewart <[email-masked]>
Date: Thu, 17 Feb 2005 07:00:05 -0800 (PST)

Melinda Shore wrote:

agreed.

R
Melinda