CODEWITHSUNDEEP
sctp
user3553856
user3553856

Reputation: 21

SCTP Multihoming issue

We have developed multihomed application now while testing my setup is:

Eth4 as primary interface connected back to back to another machine. Eth5 as secondary interface connected back to back to another machine.

I make my porimary interface down now when the INIT is been sent it reaches to peer machine seems using secondary interface but the source ip address kept is of primary interface only due to which when peer machine tries to respond INIT_ACK it tries to send on primary interface ip which is down and due to ICMP it drops the packet.

I am not too good in Routing but it seems that some routing has not been configuered properly, why is it always using primary ip ?

I have tested the same part when I have connected my primary & secondary interface through router but facrd the same issue.

Upvotes: 2

Views: 2171

Answers (1)

Karthik Balaguru
Karthik Balaguru

Reputation: 7852

For the benefit of everyone, i have just touched upon few points before coming to the main point .

SCTP endpoint can have more than one IP addresses. That is, an application can open an SCTP socket and bind selective set of addresses or all IP addresses to that socket. An association in SCTP is between a pair of end points. The SCTP endpoints shall be exchanging the list of IP addresses, so that each endpoint can receive messages from any of the addresses in other endpoint. The exchange of IP address list is done at the time of initiation of the association. However, the SCTP shall use one IP address as primary address for communication and other IP addresses shall be used for re-transmission incase of continuous failure to send data or control chunks.

From RFC4960(SCTP), you will notice that "during the initiation of association, if there is a Host Name parameter present in the received INIT , the endpoint shall resolve that host name to a list of IP address(es) and derive the transport address(es) of this peer by combining the resolved IP address(es) with the SCTP source port."

However a key point from RFC4960(SCTP) is importance of time to resolve the host name into IP addresses. It states that "in cases where the name translation involves potential long delay, the receiver of the INIT MUST postpone the name resolution till the reception of the COOKIE ECHO chunk from the peer. In such a case, the receiver of the INIT SHOULD build the State Cookie using the received Host Name (instead of destination transport addresses) and send the INIT ACK to the source IP address from which the INIT was received."

If we look into your scenario from the above information alone : Considering that the primary interface is brought down after sending INIT chunk and assuming that the time to resolve the host name into IP addresses is taking too much time in the server, it can be assumed that the INIT-ACK has been sent to the Source IP address(Primary interface) from which INIT was received.

However, if you carefully read the RFC of SCTP, there is an explicit note regarding INIT-ACK in the RFC4960(SCTP) that claims "The INIT ACK MUST be sent to the source address of the INIT. " Refer RFC3286(SCTP) that seems to convey it as a protection mechanism as it claims that "since the INIT ACK always goes back to the source address of the INIT, the blind attacker will not get the Cookie."

Now, if we look into your scenario by taking into consideration of the above information also : It is clear that the server will always sends the response INIT ACK chunk to the source address that was in the IP header of the INIT.

Upvotes: 2

Related Questions