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

From: Schruefer Wolfgang <[email-masked]>
Date: Wed, 16 Feb 2005 00:43:19 -0800 (PST)

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!

**********************************************

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
>

---

From: Randall Stewart <[email-masked]>
Date: Wed, 16 Feb 2005 04:08:00 -0800 (PST)

Wolfgang:

Comments below...

- A client application on host X needs Interface redundancy, but unfortunately SCTP can not establish a multihomed Association due to NAPT... 

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

Qiaobing Xie wrote:

Hi, Wolfgang,

Qiaobing,

may be used.

host-a          NATP                              host-z

----IP-a --INIT--->
----IP-b
    (src-port:1)
                IP-A:src-P2
                IP-B:src-P3 ------->

 End A                       NAPT                        End B
{IP-A, IP-B/p1}                ##                      
{IP-X, IP-Y/p3}

R

regards,
-Qiaobing

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 16 Feb 2005 05:54:54 -0800 (PST)

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

---

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

On Wednesday, February 16, 2005, at 08:55 AM, Spencer Dawkins wrote:
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.
This should probably be engraved somewhere for posterity.

Melinda

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 16 Feb 2005 12:50:20 -0800 (PST)

Wolfgang,

Hello,

I assume you meant that they were 2 singled homed associations with HOST Z, i.e., A<->Z and 
B<->Z.

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.

regards,
-Qiaobing

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:

Qiaobing Xie wrote:

Hi, Wolfgang,

Qiaobing,

may be used.

host-a          NATP                              host-z

----IP-a --INIT--->
----IP-b
    (src-port:1)
                IP-A:src-P2
                IP-B:src-P3 ------->

 End A                       NAPT                        End B
{IP-A, IP-B/p1}                ##                      
{IP-X, IP-Y/p3}

R

regards,
-Qiaobing

---

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

Hi, Spencer,

Spencer Dawkins wrote:

Randall,

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.
You are absolutely right and this is noted in the draft. However, having 90% of the path 
diversity (due to the presence of one or two single point of failures, i.e., NAPTs) is still 
far better than an end-to-end single path (i.e., no path diversity), in terms of overall 
reliability.

Of cause, it would be great that NAPT can some day evolve to a point that it will be able 
retain e2e diversity of a multi-homed SCTP association.

regards,
-Qiaobing
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...).

I agree that things are getting ugly fast. I'm not sure everyone has the 
same definition of "ugly" in this thread.

Spencer

_______________________________________________
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 06:59:20 -0800 (PST)

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

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

Spencer Dawkins wrote:
Randall,

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Feb 2005 15:09:42 -0800 (PST)

Qiaobing, if you ever rev your draft-xie-tsvwg-sctp-nat-00 document can you
please try to include this comment in.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Feb 2005 15:11:07 -0800 (PST)

On 2/16/05 1:03 PM, "Qiaobing Xie" <Qiaobing.Xie@xxxxxxxxxxxx> wrote:

> You are absolutely right and this is noted in the draft.

Sorry for my previous message - I missed this when I read the draft.