Subject: Re: ip fragmented sctp packet through NAT

From: Randall Stewart <[email-masked]>
Date: Fri, 13 Jan 2006 18:38:46 -0500

Chiba, Hirotsugu wrote:
> Hello Randall-san,
> 
> We're considering NAPT which can handle sctp packets. If we'd like to do
> the static port translation for sctp, we'll have to re-calculate crc32
> checksum. But against ip fragmented sctp packets, we need to
> re-calculate crc without reassembling. Could you give me a good idea for
> it? Are there any good discussion about it somewhere?
> Any information or idea would be really appreciated...
> 
> Thank you,
> 
> Hiro Chiba
> 
Chiba-san

Please do NOT do that.. this is the WRONG way to do NAPT for
SCTP..

Please see my draft on this:

http://www.ietf.org/internet-drafts/draft-stewart-behave-sctpnat-01.txt

This is the way you want to do NAT :-D

R

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 14 Jan 2006 21:48:56 +0100

Hi Randy,

handling fragmented packets seems to be something we missed in the ID.
I think we should add some text...

We have two possibilities:

- reassemble the packets in the NAT device
- only store one ID and allow the lookup based on the src/dst address
   an the ID.

Since I think SCTP tries to avoid fragmentation (it should only affect
INIT/INIT-ACK/COOKIE chunks.), it should be OK to limit the handling
of fragmented packets to N per association. And I would even suggest to
use N=1.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Fri, 20 Jan 2006 19:44:31 -0500

Chiba, Hirotsugu wrote:
> Hello Randall-san,
> 
> Thank you for your prompt reply!
> 
> OK, for NAPT like TCP, we should handle not only Local-Port but also
> Local-VTag inside of the NAT box, shouldn't we?
> 
> But we'd like to do the static port translation for having some
> different static servers at local side... If we want it, do we have to
> control the server port numbers at local side not to have duplicate
> ones?
> 

Hmmm... let me see if I understand your query..

So I have a server inside  the nat

server(p:80)10.1.1.2 <------>10.1.1.1 NAT Gl.ob.al.ad <-------

Now you want to maintain a static mapping to direct
all your port 80 associations to your server..

So you point some rule in your nat to:

Inbound : portany ->>>> Port 80 address 10.1.1.2

I don't see why one would need port translation in this
case... The guy on the network thinks you are at

Port 80 + Gl.ob.al.ad  .. you always do a static
mapping to Port 80 + 10.1.1.2 .. on the way in..

And then if you receive something from 80+10.1.1.2 directed
to a global address.. all you do is substitute the
Gl.ob.al.ad for 10.1.1.2...

This saves you from ever having to worry about doing
CRC32c..

As Michael said earlier.. for IP fragmentation we will
need to add text to the draft :-D

Am I missing anything??

R

> Thank you again,
> 
> Hiro Chiba
> 
> 
> 
>>-----Original Message-----
>>From: Randall Stewart [mailto:[email-masked]] 
>>Sent: Saturday, January 14, 2006 8:39 AM
>>To: Chiba, Hirotsugu
>>Cc: [email-masked]
>>Subject: Re: ip fragmented sctp packet through NAT
>>
>>Chiba, Hirotsugu wrote:
>>
>>>Hello Randall-san,
>>>
>>>We're considering NAPT which can handle sctp packets. If 
>>
>>we'd like to 
>>
>>>do the static port translation for sctp, we'll have to re-calculate 
>>>crc32 checksum. But against ip fragmented sctp packets, we need to 
>>>re-calculate crc without reassembling. Could you give me a 
>>
>>good idea 
>>
>>>for it? Are there any good discussion about it somewhere?
>>Please do NOT do that.. this is the WRONG way to do NAPT for SCTP..
>>

---

From: Randall Stewart <[email-masked]>
Date: Mon, 23 Jan 2006 17:09:39 -0500

Sure .. I don't see why your
NAT could not do this..

You can still use the same procedures for setting things
up as in the draft.. the only think you need
to do is make sure on the inbound (from the global
side) you make your translation to the private side
properly.. after that the same vtag trick should
work.. its just setting up the tables in the reverse
of what you normally would when a private side host
sends an INIT outbound.. but it still should work.

R

Chiba, Hirotsugu wrote:
> Hello Randall-san,
> 
> Actually, we're considering transition of services from TCP/UDP to SCTP.
> At TCP, there was a requirement to want to access telnet from global to
> local for remote control of local system. So we made a map for TCP like
> below;
> 
> Port 10000 + Gl.ob.al.ad ->>>> Port 23 + 10.1.1.2
> Port 10001 + Gl.ob.al.ad ->>>> Port 23 + 10.1.1.3
> Port 10002 + Gl.ob.al.ad ->>>> Port 23 + 10.1.1.4
> 
> Now, we'd like to do the same thing on SCTP. In fact, we can do this
> without ip fragmentation.
> 
> Does this make sense?
> 
> Thank you,
> 
> chiba
> 
> 
> 
> 
>>Sent: Saturday, January 21, 2006 9:45 AM
>>To: Chiba, Hirotsugu
>>>OK, for NAPT like TCP, we should handle not only Local-Port 
>>
>>but also 
>>
>>>different static servers at local side... If we want it, do 
>>
>>we have to 
>>
>>Now you want to maintain a static mapping to direct all your 
>>port 80 associations to your server..
>>
>>Port 80 + Gl.ob.al.ad  .. you always do a static mapping to 
>>Port 80 + 10.1.1.2 .. on the way in..
>>
>>This saves you from ever having to worry about doing CRC32c..
>>
>>
>>As Michael said earlier.. for IP fragmentation we will need 
>>to add text to the draft :-D
>>
>>Am I missing anything??
>>
>>R
>>
>>
>>>Thank you again,
>>>
>>>Hiro Chiba
>>>
>>>
>>>
>>>

---

From: Randall Stewart <[email-masked]>
Date: Tue, 24 Jan 2006 08:58:43 -0500

Chiba, Hirotsugu wrote:
> Hello Randall-san,
> 
> Thank you very much for your time...
> 
> As you say, when a private side host sends an INIT outbound, we don't
> have to make any port translations. Because the server who should accept
> that INIT must be just one. And then, the NAT box can have an ip address
> translation table by both the src port and the initiation tag in the
> INIT.
> 
> On the other hand, we'd like to have a couple of servers(hosts) at local
> side who have completely the same service port number for each. At that
> time, if a client at global side sends an INIT to this NAT box with both
> a certain dst port number and the initiation tag randomly assigned, how
> can we decide which server host should accept it?
> 
> 
> local host A(10.1.1.2) <-----+
> service port = 23            |
>                              |
>                              |     local side
> local host B(10.1.1.3) <--- ??? <-- (10.1.1.1)
> service port = 23            |          NAT box
>                              |              (Gl.ob.al.ad) <--- SCTP-INIT
>                              |                                   src
> ip=xx.xx.xx.xx
> local host C(10.1.1.4) <-----+                                   dst
> ip=Gl.ob.al.ad
> service port = 23                                                src
> port=yyyy
>                                                                  dst
> port=23
>                                                                  v-tag=0
>  
> init-tag=zzzzz(random)
> 
> Then we can have a map at the NAT box like the following;
> 
> 

Ahh.. I see what you are after here... you want the
server's to all be on the same port.. but you want
the initiator to be able to select the server
based on the port number. I missed this before.. sorry about
that...

> 
> and let remote users of local hosts use their specific port numbers like
> 10000,10001... But in this case, we have to do the port translation
> which needs checksum recalculation.
> 
> 
> local host A(10.1.1.2) <-----+
> service port = 23            |
>                              x
>                                    local side
> local host B(10.1.1.3) <---<----<-- (10.1.1.1)
> service port = 23                       NAT box
>                              x              (Gl.ob.al.ad) <--- SCTP-INIT
>                              |                                   src
> ip=xx.xx.xx.xx
> local host C(10.1.1.4) <-----+                                   dst
> ip=Gl.ob.al.ad
> service port = 23                                                src
> port=yyyy
>                                                                  dst
> port= ### 10001 ###
>                                                                  v-tag=0
>  
> init-tag=zzzzz(random)
> 

> Does this make sense again...?

Now it does... and this will be a problem for you
since you cannot:

a) Ever do multi-homing... once you start
    translating ports. (Michael and I have some
    ideas on how to make full m-homing work which
    will show up in future drafts).

b) You can build the table you wish.. and do the
    port translation but you cannot escape a full
    CRC-32c on every packet. One of the reasons the
    CRC-32c is so strong is that any bytes mis-ordered
    will cause a different crc to be generated. Unlike
    TCP or UDP where you have an additive sum and can just
    add/subtract the things you are changing. So unless
    you have hardware assist this will be a real problem
    for you. Some NIC vendors may have this (mainly due
    to iSCSI).. but last time I checked there was only
    one very expensive intel board (designed for iSCSI
    offload) that supported hardware assisted CRC32c

It seems to me that you are using this NAT like a
terminal server.. or something along that line..

And I am afraid all you can do is either do the
port translation and thus all the overhead of
CRC32c on every packet <OR>

1) Have the telnet servers listen on different
    ports.. then we have just a straight mapping
    g+10001----> .1+10001
    g+10002----> .2+10002
   etc

or

2) If you really did not care what machine you hit
    you could have g+23----> go to a randomly
    assigned (or load balanced) server. This could
    work and you setup your state with the tag
    in/out with the IP addresses etc... of course
    it won't help you if you want to have control of
    which ones you attach to :-0

R

> Regards,