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

From: "Luca Laurenzi" <[email-masked]>
Date: Wed, 2 Feb 2005 03:41:39 -0800 (PST)

ok... i make myself clear... it was just an exemple 
of a general NAPT situation...2 different hosts A and B, ... 
my problem was referred to <FONT 
face=Arial size=2>this situation:

<FONT 
face=Arial>    <FONT face="Times New Roman" 
size=3>SCTP   
(A+)-------------N                                             
SCTP    HOST X (  
)          
          
A--E+-------------cloud------------+--HOST 
Z              
    (B+)------------ 
P                                            
T
<FONT face="Times New Roman" 
size=3>Multihomed Host X.
I consider a 
single association.<FONT 
face=Arial>  
SCTP HOST X use IP A as a main address, and 
IP B as a secondary address.
When IP A sends his packets to Host Z, IP B sends 
an heartbeat packet: NAPT must traslate both 
addresses. 
 
if A sends a packet:
 <FONT face="Times New Roman" 
size=3>>From IP-A(port:9999)---------To:IPZ:port-80-----------> 

<FONT face=Arial 
size=2> 
and 
NAPTgets it and makes:
<FONT 
face=Arial size=2> >From 
IP-E(port:2222)---------To:IPZ:port-80-----------> 

<FONT face=Arial 
size=2> 
if B sends a packet:
 <FONT face="Times New Roman" 
size=3>>From IP-B(port:9999)---------To:IPZ:port-80-----------> 

NAPTgets it and makes:
 
 <FONT face="Times New Roman" 
size=3>>From IP-E(port:2222)---------To:IPZ:port-80-----------> 

 NAPT  traslate both IP A and IP B to IP 
E, and also traslate PORT 9999 to PORT 2222 :
<FONT face="Times New Roman" 
size=3>because:
"..if 
Network Address Port Translation is used with a  multihomed 
SCTPendpoint, then any port translation must be applied on a 
perassociation basis such that an SCTPendpoint continues to receive the 
same port number for all messages within a given 
association..."
<FONT face="Times New Roman" 
size=3>Problem:When HOST Z 
responds:
<FONT 
face=Arial size=2> >From IP-Z(port: 
80)---------To:IP-E:port-2222-----------> 

<FONT 
face=Arial size=2> 
<FONT 
face=Arial size=2>NAPT cannot who deliver to this packet: 
to IP-A or to IP-B 
?
<FONT 
face=Arial size=2>my question was this:
<FONT 
face=Arial size=2>if i can't change source 
port number whitin a gived  association,NAPT will have to 
multiplex/demultiplex using something other than the 

<FONT 
face=Arial size=2>SCTP port number?.. 

<FONT 
face=Arial size=2>Luca

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 2 Feb 2005 15:51:52 -0800 (PST)

Luca,

(cc'ing Randy, I think he may not see mails on this list).

My feeling is that the NAPT can translate the response from HOST Z to either IP-A/9999 or 
IP-B/9999. There may be some interesting side effects though (e.g., heartbeat from IP-B/9999 
--> IP-Z/80 gets a heartbeat ack from IP-Z/80 --> IP-A/9999). Or _maybe_ the NAPT should 
intercept and answer SCTP heartbeats (and handle ICMP messages).

regards,
-Qiaobing
Luca Laurenzi wrote:

ok... i make myself clear... it was just an exemple of a general NAPT 
situation...2 different hosts A and B, ...
my problem was referred to this situation:
 
    SCTP   (A+)-------------N                                     SCTP
    HOST X (  )             A--E+-------------cloud------------+--HOST Z
           (B+)------------ P
                            T

Multihomed Host X.
I consider a single association.  
SCTP HOST X use IP A as a main address, and IP B as a secondary address.
When IP A sends his packets to Host Z, IP B sends an heartbeat packet: 
NAPT must traslate both addresses. 
 
if A sends a packet:
 >From IP-A(port:9999)---------To:IPZ:port-80----------->
 
and NAPT gets it and makes:
 >From IP-E(port:2222)---------To:IPZ:port-80----------->
 
if B sends a packet:
 >From IP-B(port:9999)---------To:IPZ:port-80----------->
 
NAPT gets it and makes:
 
 >From IP-E(port:2222)---------To:IPZ:port-80----------->
 
 NAPT traslate both IP A and IP B to IP E, and also traslate PORT 9999 
to PORT 2222 :
because:
"..if Network Address Port Translation is used with a 
multihomed SCTP
endpoint, then any port translation must be applied on a
per association basis such that an SCTP
endpoint continues to receive the same port number for all messages
within a given association..."
Problem:
When HOST Z responds:
 >From IP-Z(port: 80)---------To:IP-E:port-2222----------->
 
NAPT cannot who deliver to this packet: to IP-A or to IP-B ?
my question was this:
if i can't change source port number whitin a gived association,
NAPT will have to multiplex/demultiplex using something other than the
SCTP port number?..
Luca

------------------------------------------------------------------------

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

---

From: Dan Wing <[email-masked]>
Date: Wed, 2 Feb 2005 16:40:02 -0800 (PST)

On Feb 2, 2005, at 3:49 PM, Qiaobing Xie wrote:

Luca,

My feeling is that the NAPT can translate the response from HOST Z to  
either IP-A/9999 or IP-B/9999. There may be some interesting side  
effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80 gets a  
heartbeat ack from IP-Z/80 --> IP-A/9999).
That doesn't sound desirable - the application won't be able to handle  
that well, if at all.

Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and  
handle ICMP messages).
By doing so you lose the value of the SCTP heartbeat -- check  
connectivity to, and the state of, the remote host.  I don't think you  
want to have NATs do that sort of thing.

-d

regards,
-Qiaobing
Luca Laurenzi wrote:

ok... i make myself clear... it was just an exemple of a general NAPT  
situation...2 different hosts A and B, ...
my problem was referred to this situation:
     SCTP   (A+)-------------N                                      
SCTP
    HOST X (  )              
A--E+-------------cloud------------+--HOST Z
           (B+)------------ P
                            T
Multihomed Host X.
I consider a single association.  SCTP HOST X use IP A as a main  
address, and IP B as a secondary address.
When IP A sends his packets to Host Z, IP B sends an heartbeat  
  >From IP-E(port:2222)---------To:IPZ:port-80----------->
  NAPT traslate both IP A and IP B to IP E, and also traslate PORT  
9999 to PORT 2222 :
because:
"..if Network Address Port Translation is used with a multihomed SCTP
endpoint, then any port translation must be applied on a
per association basis such that an SCTP
endpoint continues to receive the same port number for all messages
within a given association..."
Problem:
Luca
---------------------------------------------------------------------- 
--
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 3 Feb 2005 09:04:15 -0800 (PST)

Hi, Randy,

Randall Stewart wrote:

...
Now.. I would have a few questions on this arrangment..

1) To Host Z, I would imagine Host-A must look
   singly homed... is this what you are thinking?
Yes. HOST Z sees HOST A only with one IP addr: IP-E/2222.

2) How would NATP at E know that Host-A has both
   IP-A and IP-B... even if the NAT knows that
   Host-A has both of these how would it know that
   the IP-A and IP-B was bound by the same app
   to port 9999.
Yes, it does, because it has a 2-1 mapping entry kept in its table. This NAPT is SCTP-aware 
and at the association setup time, it intercepted the INIT (or INIT-ACK) from HOST A and 
decided (for some outside reasons) to map the two IP addresses (IP A and B) to a single 
external IP-E. Of cause, NAPT will need to remember that this belongs to the same SCTP 
association.

I guess what you are trying to do here is make NATP at E
use both IP-A and IP-B for M-Homing.. but that cannot
work unless either:
a) The INIT going out from Host-A has the listed address
   and NATP removes the address list as part of its
   processing (yuck).
Or replace the listed addr with IP E. Either way it will also recompose the INIT and re-do 
the checksum, etc. This is stated in the draft. It will be a bit work :-) But this is what 
is needed to make the NAPT SCTP-aware.

regards,
-Qiaobing
b) You pre-configure NATP with this knowledge (double yuck)

c) You develop a method to add this knowledge to the NAT..
   which I am not sure how .. stun like? or maybe a modified
   ADD-IP...
Anyway.. without this I don't see how the NAT could every use
IP-B.
.. just thoughts...

R

Qiaobing Xie wrote:

Luca,

heartbeat ack from IP-Z/80 --> IP-A/9999). Or _maybe_ the NAPT should 

regards,
-Qiaobing
Luca Laurenzi wrote:

Multihomed Host X.

 

Problem:

Luca

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 3 Feb 2005 09:11:08 -0800 (PST)

Dan Wing wrote:

Luca,

My feeling is that the NAPT can translate the response from HOST Z to  
either IP-A/9999 or IP-B/9999. There may be some interesting side  
effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80 gets a  
heartbeat ack from IP-Z/80 --> IP-A/9999).
That doesn't sound desirable - the application won't be able to handle  
that well, if at all.
Multi-homing (as well as heartbeating) in SCTP is mostly transparent to the app at both 
ends. I.e., it is handled internally by the SCTP stack itself.

Agreed. There are pros and cons for doing this.

regards,
-Qiaobing
-d

regards,
-Qiaobing
Luca Laurenzi wrote:

ok... i make myself clear... it was just an exemple of a general 
NAPT  situation...2 different hosts A and B, ...
my problem was referred to this situation:
     SCTP   (A+)-------------N                                      SCTP
    HOST X (  )              
A--E+-------------cloud------------+--HOST Z
           (B+)------------ P
                            T
Multihomed Host X.
I consider a single association.  SCTP HOST X use IP A as a main  
address, and IP B as a secondary address.
When IP A sends his packets to Host Z, IP B sends an heartbeat  

Problem:

Luca

---

From: Dan Wing <[email-masked]>
Date: Thu, 3 Feb 2005 09:24:03 -0800 (PST)

On Feb 3, 2005, at 9:13 AM, Qiaobing Xie wrote:

Dan Wing wrote:

My feeling is that the NAPT can translate the response from HOST Z  
to  either IP-A/9999 or IP-B/9999. There may be some interesting  
side  effects though (e.g., heartbeat from IP-B/9999 --> IP-Z/80  
gets a  heartbeat ack from IP-Z/80 --> IP-A/9999).
That doesn't sound desirable - the application won't be able to  
handle  that well, if at all.
Multi-homing (as well as heartbeating) in SCTP is mostly transparent  
to the app at both ends. I.e., it is handled internally by the SCTP  
stack itself.
So its akin to TCP keepalives which are also handled by the TCP stack  
but, when a timeout occurs, inform the application?

Or _maybe_ the NAPT should intercept and answer SCTP heartbeats (and  
 handle ICMP messages).
By doing so you lose the value of the SCTP heartbeat -- check   
connectivity to, and the state of, the remote host.  I don't think  
you  want to have NATs do that sort of thing.
Agreed. There are pros and cons for doing this.
If SCTP keepalives are akin to TCP keepalives, I couldn't imagine too  
many people being happy with a NAT responding to TCP keepalives on  
behalf of a host that's actually dead.

-d

regards,
-Qiaobing
-d
regards,
-Qiaobing
Luca Laurenzi wrote:

"..if Network Address Port Translation is used with a multihomed  

Problem:
 NAPT cannot who deliver to this packet: to IP-A or to IP-B ?
my question was this:
if i can't change source port number whitin a gived association,
NAPT will have to multiplex/demultiplex using something other than  
the
SCTP port number?..

Luca
-------------------------------------------------------------------- 
-- --
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 3 Feb 2005 11:12:34 -0800 (PST)

Dan Wing wrote:

...
Exactly.

Or _maybe_ the NAPT should intercept and answer SCTP heartbeats 
(and   handle ICMP messages).
By doing so you lose the value of the SCTP heartbeat -- check   
connectivity to, and the state of, the remote host.  I don't think  
you  want to have NATs do that sort of thing.
Agreed. There are pros and cons for doing this.
If SCTP keepalives are akin to TCP keepalives, I couldn't imagine too  
many people being happy with a NAT responding to TCP keepalives on  
behalf of a host that's actually dead.
There is another side to SCTP HB, that it is also meant to probe the path reachability in a 
multi-homed setting. Since the insertion of a NAPT may change the multi-path setting (like 
the example given in this thread), there _may_ be some pros for the NAPT to answer the path 
probings.

regards,
-Qiaobing
-d

regards,
-Qiaobing
-d

regards,
-Qiaobing
Luca Laurenzi wrote:

(A+)-------------N                                       SCTP
  >From IP-E(port:2222)---------To:IPZ:port-80----------->
  NAPT traslate both IP A and IP B to IP E, and also traslate 
PORT   9999 to PORT 2222 :
because:

Problem:

Luca

---

From: Dan Wing <[email-masked]>
Date: Thu, 3 Feb 2005 11:19:42 -0800 (PST)

On Feb 3, 2005, at 11:15 AM, Qiaobing Xie wrote:

Dan Wing wrote:

...
Ok, thanks.

Or _maybe_ the NAPT should intercept and answer SCTP heartbeats  
(and   handle ICMP messages).
By doing so you lose the value of the SCTP heartbeat -- check    
connectivity to, and the state of, the remote host.  I don't think   
you  want to have NATs do that sort of thing.
Agreed. There are pros and cons for doing this.
If SCTP keepalives are akin to TCP keepalives, I couldn't imagine too  
 many people being happy with a NAT responding to TCP keepalives on   
behalf of a host that's actually dead.
There is another side to SCTP HB, that it is also meant to probe the  
path reachability in a multi-homed setting. Since the insertion of a  
NAPT may change the multi-path setting (like the example given in this  
thread), there _may_ be some pros for the NAPT to answer the path  
probings.
If the SCTP device is a wireless device and goes out of range, wouldn't  
you want heartbeat to notice it's no longer available?  If the NAPT is  
responding to the heatbeats on the SCTP host's behalf (that is, the  
NAPT is "proxying" the heartbeats), the remote SCTP stack and remote  
SCTP application won't know the wireless SCTP device has gone out of  
range.

-d

regards,
-Qiaobing
-d
regards,
-Qiaobing
-d

regards,
-Qiaobing
Luca Laurenzi wrote:

endpoint continues to receive the same port number for all  
messages

Problem:
 NAPT cannot who deliver to this packet: to IP-A or to IP-B ?
my question was this:
if i can't change source port number whitin a gived association,
NAPT will have to multiplex/demultiplex using something other  
than  the
SCTP port number?..

Luca
------------------------------------------------------------------ 
-- -- --
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 3 Feb 2005 12:22:54 -0800 (PST)

Dan Wing wrote:

...
There is another side to SCTP HB, that it is also meant to probe the  
path reachability in a multi-homed setting. Since the insertion of a  
NAPT may change the multi-path setting (like the example given in 
this  thread), there _may_ be some pros for the NAPT to answer the 
path  probings.

If the SCTP device is a wireless device and goes out of range, wouldn't  
you want heartbeat to notice it's no longer available?  If the NAPT is  
responding to the heatbeats on the SCTP host's behalf (that is, the  
NAPT is "proxying" the heartbeats), the remote SCTP stack and remote  
SCTP application won't know the wireless SCTP device has gone out of  
range.
Yes, it is rather interesting issue. I didn't mean to say it is always a good thing to do... 
in some cases it may not be advisable but in others it may have its merits. Need more 
thoughts on this.

regards,
-Qiaobing
-d