[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-sctp
Subject: Re: Few Questions About SCTP NAT
From: Michael Tuexen <tuexen () fh-muenster ! de>
Date: 2019-05-05 13:54:39
Message-ID: A0A2576C-99C4-4F2E-98CB-D70C7CE3297A () fh-muenster ! de
[Download RAW message or body]
> On 26. Apr 2019, at 18:39, Xin Long <lucien.xin@gmail.com> wrote:
>
> On Fri, Apr 26, 2019 at 8:33 PM Michael Tuexen <tuexen@fh-muenster.de> wrote:
>>
>>> On 25. Apr 2019, at 13:46, Xin Long <lucien.xin@gmail.com> wrote:
>>>
>>> Sorry, seems I sent to the wrong email address.
>>> use tuexen@fh-muenster.de instead.
>> ... I'm typically more responsive on this address than on the one
>> I use for mailing lists...
>>>
>>> On Sat, Apr 20, 2019 at 6:45 PM Xin Long <lucien.xin@gmail.com> wrote:
>>>>
>>>> cc'ing linux-sctp.
>>>>
>>>> On Sat, Apr 20, 2019 at 4:24 PM Xin Long <lucien.xin@gmail.com> wrote:
>>>>>
>>>>> Hi, Michael,
>>>>>
>>>>> I'm trying to implement SCTP NAT
>>>>> (https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-12) on linux,
>>>>> but got some questions:
>>>>>
>>>>> 1.
>>>>> +-------+
>>>>> /--------| NAT 1 |--------\ /--\/--\
>>>>> +------+ / +-------+ \ / \ +--------+
>>>>> | Host |=== ====| Internet |===| Host B |
>>>>> | A | \ +-------+ / \ / +--------+
>>>>> +------+ \--------| NAT 2 |--------/ \--/\--/
>>>>> +-------+
>>>>>
>>>>> In this topo, after 4 shake-hands and asconf:
>>>>>
>>>>> +---------+--------+----------+--------+-----------+
>>>>> NAT 1 | Int | Int | Ext | Ext | Priv |
>>>>> | VTag | Port | VTag | Port | Addr |
>>>>> +---------+--------+----------+--------+-----------+
>>>>> | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
>>>>> +---------+--------+----------+--------+-----------+
>>>>>
>>>>> +---------+--------+----------+--------+-----------+
>>>>> NAT 2 | Int | Int | Ext | Ext | Priv |
>>>>> | VTag | Port | VTag | Port | Addr |
>>>>> +---------+--------+----------+--------+-----------+
>>>>> | 1234 | 1 | 5678 | 2 | 10.1.0.1 |
>>>>> +---------+--------+----------+--------+-----------+
>>>>>
>>>>> Now there are 1 entry on nat1 and 1 entry on nat2. If the connection is
>>>>> shutdown via nat1, the entry on nat1 will be deleted, right? What about
>>>>> the entry on nat2, when can it be deleted?
>> Deletion of state is purely timer based. This applies to NAT1 and NAT2.
>>>>>
>>>>> 2.
>>>>> /--\/--\
>>>>> +--------+ +-----+ / \ +--------+
>>>>> | Host A | <----------> | NAT | <----> | Internet | <----> | Host B |
>>>>> +--------+ +-----+ \ / +--------+
>>>>> \--/\--/
>>>>>
>>>>> In this topo, if both paths with saddr 10.0.0.1 and 10.1.0.1 go through
>>>>> NAT, will there be 2 entries created on this NAT after 4 shake-hands and
>>>>> asconf like:
>>>>>
>>>>> +---------+--------+----------+--------+-----------+
>>>>> NAT | Int | Int | Ext | Ext | Priv |
>>>>> | VTag | Port | VTag | Port | Addr |
>>>>> +---------+--------+----------+--------+-----------+
>>>>> | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
>>>>> +---------+--------+----------+--------+-----------+
>>>>> | 1234 | 1 | 5678 | 2 | 10.1.0.1 |
>>>>> +---------+--------+----------+--------+-----------+
>>>>>
>>>>> or it will be handled as "Internal Port Number and Verification Tag
>>>>> Collisions"?
>> Which section are you referring to?
> I was looking at:
>
> 6.3. Handling of Internal Port Number and Verification Tag Collisions:
>
> "two hosts in the Private-Address space want to set up an SCTP association
> with the same service provided by some hosts in the Internet"
>
> "in this unlikely event the NAT box MUST send an ABORT chunk with the M-bit
> set if the collision is triggered by an INIT or INIT-ACK chunk or send an
> ERROR chunk with the M-bit set if the collision is triggered by an ASCONF
> chunk"
>
> Does it mean:
> Users will fail to add the 2nd path by ASCONF chunk on the same NAT as
> the 1st path? (if these 2 paths for one asoc go through the same one NAT,
> NOT two different NATs).
>
> like:
> +--------+
> /--\/--\ /-|Router 1| \
> +------+ +-----+ / \ / +--------+ \ +------+
> | Host | <-----> | NAT | <-> | Internet | == =| Host |
> | A | +-----+ \ / \ +--------+ / | B |
> +------+ \--/\--/ \-|Router 2|-/ +------+
>
> (10.0.0.1, 10.1.0.1) (203.0.113.1, 203.0.113.129)
>
>
> After 4 shake-hands by 10.0.0.1:1 ---> 203.0.113.1:2:
>
> +---------+--------+----------+--------+-----------+
> NAT | Int | Int | Ext | Ext | Priv |
> | VTag | Port | VTag | Port | Addr |
> +---------+--------+----------+--------+-----------+
> | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
> +---------+--------+----------+--------+-----------+
>
> then the user wants to add the 2nd path, which will also go this NAT:
>
> ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678]
> 10.1.0.1:1 --------> 203.0.113.129:2
> Ext-VTag = 5678
>
> What will happen on this NAT?
>
> please let me know if it's still unclear. Thanks.
Now it is clear to me what you are referring to.
Based on the remote vtag we could detect that this belongs to the existing
association.
But what would you gain? We assume that the NAT box has a single public
address. How should the NAT box map an incoming packet to one of the private
addresses. This selection is normally done by Host B.
Best regards
Michael
>
>>>>>
>>>>> 3.
>>>>> For multipath, each entry for one path should maintain a 'state', like
>>>>> closed, established, cookie-echo etc, right? If they belong to a same
>>>>> association, especially when they're on different nats, how do we keep
>>>>> each entry's state consistent? or they don't have to be consistent?
>> You don't need such a state as long as you delete state purely timer based.
>>>>>
>>>>> Thanks.
>>
["smime.p7s" (smime.p7s)]
0 *H
010
`He 0 *H
00 PN=d0
*H
0q1 0 UDE1 0U
Deutsche Telekom AG1 0 U T-TeleSec Trust Center1#0!UDeutsche Telekom \
Root CA 20 140722120826Z
190709235900Z0Z1 0 UDE10U
DFN-Verein10U DFN-PKI1$0"UDFN-Verein PCA Global - G010"0
*H
0
g
TÖP5=bnL ["t 41 R (#t^[xx(59{-E \
z|J Æ\+1{ $C 8jh Oxv&t kν0Ob'0 \
e`M #*5X'vq 5}o3 \
]AkLQٽVVC= '0IT4qul !'>99Hjə 00U 0 U I= D{)
p>d0 U #01ySz-l
+30U 00bU \
[0Y0+!,0+!, 0+!,0 +!,0
+!, 0>U 70503 1 \
/-http://pki0336.telesec.de/rl/DT_ROOT_CA_2.crl0x+l0j0,+0 \
http://ocsp0336.telesec.de/ocspr0:+0.http://pki0336.telesec.de/crt/DT_ROOT_CA_2.cer0
*H
c (!r9FY92%
}Am
n,Yu3a'ò5*Iff/ \
]n?nZ[Cc\1 _MeN2|zKM\t!uR>jӐ#nIg5MV/Ϸr>ɼ@Z=ּ÷2 \
,jm59DXc$ Nn/8WI?nPo, FeϮٟS>/ Ƅ }{$$c4Z \
*y:%Be;|#),9[T00 $ H30 *H
0Z1 0 UDE10U
DFN-Verein10U DFN-PKI1$0"UDFN-Verein PCA Global - G010
140527145409Z
190709235900Z01 0 UDE1 0UNordrhein-Westfalen10UMuenster1 \
0 U Fachhochschule Muenster1#0!U Datenverarbeitungszentrale1 0UFH \
Muenster CA - G011 0 *H ca@fh-muenster.de0"0
*H
0
yll""AODSW{gp5ȕ[۵K{{ N '%M|( 45
~.; . e.xH&=k| fWv293qP_vd:;IyCl|쒷 4/sCYձPG_Ecj \
Xh WZ
xy_STbZOἥ ^_Ml3d stЎEPKp7 \
aa%w مgo 00U 00U 0U 00U \
0 U [15B70 U #0I= D{)
p>d0 U 0ca@fh-muenster.de0U 0~0= ; \
97http://cdp1.pca.dfn.de/global-root-ca/pub/crl/cacrl.crl0= ; \
97http://cdp2.pca.dfn.de/global-root-ca/pub/crl/cacrl.crl0+003+ \
0'http://ocsp.pca.dfn.de/OCSP-Server/OCSP0G+0;http://cdp1.pca.dfn.de/globa \
l-root-ca/pub/cacert/cacert.crt0G+0;http://cdp2.pca.dfn.de/global-root-ca/pub/cacert/cacert.crt0
*H
G5Jo5-km˅qtM h(gsQb@2^C l}h^tB \
f!*$(Y1Kdlh`V_+ \
tpz-ӎ~0kY!@Fw7+`vezZ%H&@ E \
Ɏ, lfQ@k}u#>wڹf5Zl$K@eukYqFI;6]7.܋@Zy aƄ} \
~~0 0 t70
*H
01 0 UDE1 0UNordrhein-Westfalen10UMuenster1 0 U
Fachhochschule Muenster1#0!U Datenverarbeitungszentrale1 0UFH Muenster \
CA - G011 0 *H ca@fh-muenster.de0
160704070613Z
190704070613Z0|1 0 UDE1 0 U
Fachhochschule Muenster1200U )Fachbereich Elektrotechnik und \
Informatik10U Michael Tuexen0"0 *H
0
̚Pmٛn6
lW <ƣ ~Kyw'L797V8 yWY3H?.M:u.ۈdU=w>@.vWb_uK?XXxS6.N
SY|n1kX_+\2L-=p
,&e;:ה⒬ b
G-_W ԵDg bS" w`CD k [}m\! G0C0@U \
9070+!,0+!,0 \
+!,0 U 0 0U 0 U %0++0 U jf fEu0 U #0
[15B70 U 0tuexen@fh-muenster.de0U 0~0= ; \
97http://cdp1.pca.dfn.de/fh-muenster-ca/pub/crl/cacrl.crl0= ; \
97http://cdp2.pca.dfn.de/fh-muenster-ca/pub/crl/cacrl.crl0+003+ \
0'http://ocsp.pca.dfn.de/OCSP-Server/OCSP0G+0;http://cdp1.pca.dfn.de/fh-mu \
enster-ca/pub/cacert/cacert.crt0G+0;http://cdp2.pca.dfn.de/fh-muenster-ca/pub/cacert/cacert.crt0
*H
Hx:Ti ʆ,$c`)nqF?ŖNqeu7B> -,!ŃRK~SyFrIʲ}iI81|W' \
~'m >bZ5he ߲Q \
N*t 4vKsnsQqϨIG ^VTU/<[U9J .B1i67(ɐvH
)1905001 0 UDE1 0UNordrhein-Westfalen10UMuenster1 \
0 U Fachhochschule Muenster1#0!U Datenverarbeitungszentrale1 0UFH \
Muenster CA - G011 0 *H ca@fh-muenster.det70
`He 70 *H
1 *H
0 *H
1
190505135439Z0/ *H
1" 1>\)')+*pD0 +71001 0 UDE1 0UNordrhein-Westfalen10UMuenster1 \
0 U Fachhochschule Muenster1#0!U Datenverarbeitungszentrale1 0UFH \
Muenster CA - G011 0 *H ca@fh-muenster.det70 *H
1 01 0 UDE1 0UNordrhein-Westfalen10UMuenster1 0 U
Fachhochschule Muenster1#0!U Datenverarbeitungszentrale1 0UFH Muenster \
CA - G011 0 *H ca@fh-muenster.det70
*H
l:=
`#$]PAN7즅g '"0 <FxL$HW4xn P'Í=
= n{]1T#< >h&c˽i qBz \
bhNN C&$ yN2Oij0CeNM'<S0ҦۄS[Yn`<Y4Teˉ]1Rvn慍]FV+B*y,:
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic