SCTP Discussions

Text archives Help


[SCTP-Discussion] Validity of INIT ACK


Chronological Thread 
  • From: 송제영 <sjy14 AT samsung.com>
  • To: discussion AT sctp.de
  • Cc:
  • Subject: [SCTP-Discussion] Validity of INIT ACK
  • Date: Tue Jul 2 15:02:01 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Msgkey: 20020702090312@sjy14

Hi,

I've been testing Multihoming functionality of SCTP with sctplib-pre17 and
found something strange with establishing associations.

My testbed topology is simple as follows:

INIT
---------->
---------------------
| 1.1 1.2 |
--------- ---------
| Host A | | Host B |
--------- ---------
| 2.1 2.2 |
---------------------

Routing tables
A: 1.1-->1.2 B: 1.2-->1.1
2.1-->2.2 2.2-->2.1


Both ends are multihomed and directly connected to each other through a pair
of links.
Under the normal circumstaces, everything works fine. Link failover worked
great when I cut off 1.1-1.2 link.
What I mean by the normal circumstances is that the IP setup of SCTP is like
this:

Host A(Client) : Primary=1.1 Secondary=2.1 Destination=1.2
Host B(Server): Primary=1.2 Secondary=2.2


But, if I try to make a connection using only one IP of one end, the
connection ends up with INIT ACK discarded at the one that sent INIT in some
cases.
In one of those cases, the setup is like this:

Host A(Client) : Primary=1.1 Secondary=none Destination=2.2
Host B(Server) : Primary=1.2 Secondary=2.2

The way the connection failed is:
1) Host A: INIT is sent from 1.1 through 2.1 to 2.2
2) Host B: INIT ACK is sent from 1.2 to 1.1 due to the routing table of Host B
3) Host A: INIT ACK is discarded because INIT ACK is regarded to be coming
from 1.2 by looking at the src IP of INIT ACK
4) Association fail

I don't know whether you've designed sctplib this way on purpose or already
noticed this problem.
However, this problem should be fixed because I see some other Association
failure from the same reason when the routing tables of Host A and Host B are
"cross-
matched".

I won't describe the detail of it now. If you need more detail, let me know
then I'll post it here later.

The possible fix for this seems like this:
When the INIT sender checks the IP address of INIT ACK from the other end to
validate the INIT ACK, every multihoming IP address contained in the payload
of INI
T ACK should be checked.

In the expample above, INIT ACK is supposed to have the multihoming IP
addresses of 1.2 and 2.2, and the Host A will check the validity by looking
at those add
ress contained in the payload, not the IP address(1.2) of IP header.


I would like you to clear this up and possibly fix it.

Thank you.

Jye
SCTP research from Samsung




Archive powered by MHonArc 2.6.19+.

Top of page