Menu
▾
▴
Re: [Lksctp-developers] HEARTBEAT causes ABORT
|
From: Florian N. <flo...@st...> - 2008-08-22 12:42:33
|
Vlad Yasevich schrieb: > Florian Niederbacher wrote: > >> Neil Horman schrieb: >> >>> On Wed, Aug 20, 2008 at 10:57:23AM +0200, Florian Niederbacher wrote: >>> >>> >>>> Vlad Yasevich schrieb: >>>> >>>> >>>>> Florian Niederbacher wrote: >>>>> >>>>> >>>>>> I have a question about the behavior of HEARTBEAT. >>>>>> If a receiver gets a SCTP HEARTBEAT to an established connection >>>>>> during a data transfer and the IP does not belong to this >>>>>> connection, then a SCTP ABORT is send back to this destination. I >>>>>> am right? But if this packet goes over a NAT then also the >>>>>> established connection gets lost. >>>>>> >>>>>> Example: >>>>>> >>>>>> (Sender IP) - (Receiver IPs 192.168.4.2, 192.168.1.5) >>>>>> >>>>>> 192.168.2.2 --> 192.168.4.2 >>>>>> DATA-> >>>>>> <-ACK >>>>>> DATA -> >>>>>> <-ACK >>>>>> >>>>>> HEARTBEAT(192.168.2.2) -> NAT(192.168.1.2)->HEARTBEAT(192.168.1.2) >>>>>> and 192.168.1.5 receives >>>>>> <-NAT(192.168.2.2,192.168.1.2)<-ABORT(192.168.1.5) >>>>>> >>>>>> >>>>> Wait a second, why would the NAT change the source address of the >>>>> heartbeat >>>>> from the upstream side? >>>>> >>>>> >>>> NAT on a router exchanges by definition the IP address from the >>>> outgoing packet in the IP header(192.168.2.2 NAT to 192.168.1.2 -> >>>> 192.168.1.5). >>>> >>> Yes, but it does this in the IP header for all SCTP packets. I.e. the >>> INIT >>> chunks when the association are established will also have this >>> exchange. So >>> the reciever has a known association on the NAT-ted address >>> (192.168.1.2). When >>> the HEARTBEAT chunk is sent the receiver should recognize it for the >>> natted >>> address. >>> >>> Do you have tcpdumps of this behavior? As Vlad mentioned multihoming >>> through >>> NAT doesn't currently work since NAT doesn't modify payload data >>> (where the >>> multihomed addresses are stored). But a single association through a >>> NAT router >>> should work just fine. >>> >>> >> Yes i know that NAT is not supported by SCTP and an other solution would >> be tunneling with UDP encapsulation. >> I have also read the other drafts about NAT considerations. >> >> But there is one scenario missing (exactly my case): >> >> +------+ >> /====|NAT A |====\ >> +------+ / +------+ \ +------+ >> |SCTP |/ Router 1 \|SCTP | >> |end A |\ /|end B | >> +------+ \ +------+ / +------+ >> \=== no NAT ===/ >> +------+ >> Router 2 >> >> >> SCTP A has following IP: >> 192.168.2.2 >> 192.168.4.2 >> >> SCTP B has following IP: >> 192.168.1.5 >> 192.168.4.3 >> >> Router1 natting 192.168.2.2 -> 192.168.1.2 >> >> Case 1: If the INIT starts from 192.168.2.2 over Router 2 SCTP_B gets >> (192.168.2.2 and 192.168.4.2) as connection. >> Case 2: If the INIT starts from 192.168.2.2 over Router 1 SCTP_B gets >> (192.168.1.2 and 192.168.4.2) as connection. >> >> In case2 everything gets ok, because natting is transparent, but in >> case1 SCTP_B interprets the connection wrong. The problem is now that >> packets from 192.168.2.2 send over Router 1 have not the address >> belonging to the connection association. Therefore the connection get >> closed, when a HEARTBEAT is send in case2 from 192.168.2.2 over Router >> > > You mean case 1 here, right? > Yes the failure description is for case 1. > >> 1. SCTP_B sends back an ABORT to 192.168.1.2. Natting makes then the >> rest 192.168.1.2 is natted back to 192.168.2.2 and the connection get an >> ABORT. >> >> > > The same would also happen with other packets, not just HB. In case 1, > if you have to retransmit over router 1 (NAT), the retransmitted DATA > would cause the same ABORT. So, as your suggestion earlier of > modifying the HB wouldn't keep the association up. > > The problem is really that the address should have 2 different scopes, but > IPv4 doesn't provide for that really well. > If we had 2 different scopes, we would be able to either prefer certain routes, > or list only certain addresses in the INIT so that the problem of case 2 doesn't > happen. Yes, I figured out more cases and I have them proven in practice. They show also failures. Therefore the solution is to exclude such IPs until the NAT behavior is implemented or to tunnel the SCTP connection with UDP. But the best solution in my eyes would be the SCTP NAT solution proposed in this draft (draft-stewart-behave-sctpnat-04.txt). Thanks, for your suggestions and help. - Florian > > I am actually rather surprised that you NAT doest reject the HB since it would > have not control block for that association. > > -vlad > > >> If you need a tcpdump let me know the parameters which you like or i can >> send you also a whireshark capture file. >> >> - Florian >> >>> Neil >>> >>> >>> >>> > > > |