Subject: [Tsvwg] Tie-Tags in Restart scenario -SCTP

From: "Somsak Vanit-anunchai" <[email-masked]>
Date: Mon, 29 Sep 2008 14:49:34 +0700

Dear Sirs,
 
I have a problem with using Tie-Tags for restarting connection in SCTP.
Are the Local Tag and Peer’s defined in page 67 of RFC 4960 the same as in 
the Table 2??   Table 2 Action –A (restart) requires Local and Peer’s Tag 
mismatch VTAGs in the existing TCB which is not the case here.  Do I 
misunderstand something? I hereby attach the message sequeunce chart of the 
restart scenario. 
 
Please help
Somsak

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 29 Sep 2008 10:36:50 +0200

Hi Somsak,

please use plain ASCII text in future mails...

The old association uses verification tags A and Z.

The one being restarted will use Ax and Zx. Assuming
A != Ax and Z != Zx, you are in the case where the
Tie tags match and the verification tags do not match,
so it is case A and you are restarting.

Best regards
Michael

On Sep 29, 2008, at 9:49 AM, Somsak Vanit-anunchai wrote:

> Are the Local Tag and Peer’s defined in page 67 of RFC 4960 the same  
> as in the Table 2??   Table 2 Action –A (restart) requires Local and  
> Peer’s Tag mismatch VTAGs in the existing TCB which is not the case  
> here.  Do I misunderstand something? I hereby attach the message  
> sequeunce chart of the restart scenario.
>
> Please help
> Somsak
>
>
> <SCTP-Restart-Problem.doc>

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 29 Sep 2008 11:42:29 +0200

On Sep 29, 2008, at 11:09 AM, Somsak Vanit-anunchai wrote:

> Many thanks
> It is clear that the Table 2 (heading - the first and second  
> columns) in RFC
> 4960 is wrong then.
Please keep the mailing list included...

Why is the table wrong?

Take for example the first column of the first row:

It means that the Local Tag (which is defined to be the Tag
in the TCB, which is the tag used for the "old" association)
does not match the tags in the COOKIE (which are the
tags used for the "new" association).

So where is the error?
>
>
> Somsak
>
> -----Original Message-----
> From: Michael Tüxen <[email-masked]>
> To: [email-masked]
> Date: Mon, 29 Sep 2008 11:04:58 +0200
> Subject: Re: [Tsvwg] Tie-Tags in Restart scenario -SCTP
>
>> On Sep 29, 2008, at 10:54 AM, Somsak Vanit-anunchai wrote:
>>
>>> Hi Michael
>>>
>>>> you are in the case where the
>>> Are the verification tags in Cookie or temporary TCB?
>> There is no temporary TCB when you process the COOKIE.
>>> If so, is this means "the Local Tag and Peer’s defined in page 67 of
>>> RFC 4960 are not the same as the Local Tag and Peer’s Tag in the
>>> Table 2"???
>> Case A means that the tags in the COOKIE do not match the tags in the
>> TCB.
>>>
>>> I am still confused.
>>> Best regards,
>>> Somsak
>>>
>>> -----Original Message-----
>>> From: Michael Tüxen <[email-masked]>
>>> To: [email-masked]
>>> Cc: [email-masked] <[email-masked]>
>>> Date: Mon, 29 Sep 2008 10:36:50 +0200
>>> Subject: Re: [Tsvwg] Tie-Tags in Restart scenario -SCTP
>>>
>>>> Hi Somsak,
>>>>

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 29 Sep 2008 11:56:38 +0200

Hi Somsak,

more thinking on my side...

I now see what you mean:

The X in the first column should mean the the local tag in
the COOKIE and in the TCB do not match. I think we agree on
this. Right?

Now the legend says:
  "X - Tag does not match the existing TCB"

Therefore the 'Local Tag' in the column header must be
the local tag in the COOKIE (to make any non-trivial sense).

Now you see a contradiction with the sentence
"We will refer to the copy within an association's TCB as the
  Local Tag and Peer's Tag."
within the section 5.2.2.

Is this the error you are referring to?

Best regards
Michael

PS: There is also an error in the flow chart showing the tie-tags
     as "old tag" instead of random nonces.

---

From: "Ramaiah, Chaitra M (STSD)" <[email-masked]>
Date: Tue, 30 Sep 2008 04:02:14 +0000

Hi All,

  I need a small clarification. RFC 2960 quotes the following:

3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5):

   An endpoint should send this chunk to its peer endpoint as a response
   to a HEARTBEAT chunk (see Section 8.3).  A HEARTBEAT ACK is always
   sent to the source IP address of the IP datagram containing the
   HEARTBEAT chunk to which this ack is responding.

Assume I have two hosts connected through two interfaces and a router in between so that there are 4 routes between them.

One host has A and B as it's IP addresses and host two has C and D.

Now the routable paths are:

A <----> C
A <----> D
B <----> C
B <----> D

A and C are in the same network and so are B and D. Since we have a router in between, I also have the paths A <----> D and B <----> C set up.

The question is, if a HEARTBEAT is sent from A <----> D, RFC says that the HEARTBEAT ACK has to be sent back to the source IP address i.e. A in this case. Now, what should be the reply path of the HEARTBEAT ACK? Should it be D <----> A or is an implementation allowed to send it from C <----> A?

My understanding is that D <----> A makes more sense for HEARTBEAT ACKs since these messages are to monitor the health of the path (source/destination IP pair). Is my understanding correct?

Regards,
Chaitra

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 30 Sep 2008 08:15:52 +0200

On Sep 30, 2008, at 3:12 AM, Somsak Vanit-anunchai wrote:

> Hi Michael
>
> Thank you very much for your reply.  See my answer below.
>
> Yes, I agree.
> Yes, agree
> Yes, this is the problem I was confused. This leads to another  
> question.
OK. Fine.
>
> What is the purpose to store Tie-Tags in an association's TCB???
The Tie Tags are random nonces to "tie together" the COOKIE
for the "new" association and the old association. So you
compare the tie tags in the received cookie with the ones stored
in the TCP to make sure that the cookie is sent by the end-point for
this association.
>>>>>>> I have a problem with using Tie-Tags for restarting connection  
>>>>>>> in
>>>>>>> SCTP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Sep 2008 00:12:31 -0600

Ramaiah,

The reply path does not matter.  The HEARTBEAT ACK
must simply be "addressed" to sender of the HEARTBEAT.
How it might get to that address is up to the network.

--brian

Ramaiah, Chaitra M (STSD) wrote:           (Tue, 30 Sep 2008 04:02:14)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 30 Sep 2008 09:07:16 +0200

Hi Chaitra,

comments in-line.

Best regards
Michael

>  I need a small clarification. RFC 2960 quotes the following:
As a general note: Please use RFC 4960 instead of RFC 2960.
> Assume I have two hosts connected through two interfaces and a  
> router in between so that there are 4 routes between them.
>
> A and C are in the same network and so are B and D. Since we have a  
> router in between, I also have the paths A <----> D and B <----> C  
> set up.
>
> The question is, if a HEARTBEAT is sent from A <----> D, RFC says  
> that the HEARTBEAT ACK has to be sent back to the source IP address  
> i.e. A in this case. Now, what should be the reply path of the  
> HEARTBEAT ACK? Should it be D <----> A or is an implementation  
> allowed to send it from C <----> A?
The RFC only requires that the destination address of the HEARTBEAT- 
ACK is A. The RFC
does not require that an SCTP implementation can control the source  
address of
the packets it is sending. So the sender of the HEARTBEAT must accept  
the HEARTBEAT-ACK
no matter if the source address of it is C or D.
>
>
> My understanding is that D <----> A makes more sense for HEARTBEAT  
> ACKs since these messages are to monitor the health of the path  
> (source/destination IP pair). Is my understanding correct?
The HEARTBEAT procedure is used to supervise the reachability of a  
destination address.
You do not test the reachbility of pairs of source/destination  
addresses.

---

From: Randy Stewart <[email-masked]>
Date: Tue, 30 Sep 2008 07:31:14 -0400

It can be either source address.

I.e. if you were to HB
A <-> D

then the reply could come from either D or C back to A.

In the normal case (assuming no network problems) I would
expect your HB's to be sourced from A -> C
and B -> D.. assuming, as you say A/C are on the same
network and B/D on a separate. That might not be the
case of course depending on hour your routing is setup.

Usually you should be using the source address of the interface
that the packet exits the box on... you are not required to do
this.. but its a good idea due to ingress filtering etc.

R

> (source/destination IP pair). Is my understanding correct?

-----
Randall Stewart
[email-masked]

---

From: David Borman <[email-masked]>
Date: Tue, 30 Sep 2008 08:00:31 -0500

This is an issue that has caused us grief in the past.  Take a  
scenario where A, B, C and D are all on different networks (and the  
specific implementation at the time was Linux 2.6.19), with multiple  
routers in between them.  Each host has routes for the two directly  
attached networks, plus one default route.  So, the heartbeats are  
sent to both remote addresses, but because the default route is used,  
they are sent out only out one interface with one source address: A->C  
and A->D.  On the other side, the acks are are sent back C->A and C- 
 >A, for the same reason.  Meanwhile, the other side is sending  
heartbeats as D->A and D->B, and getting acks A->C and A->C.  (I might  
not have all the details correct, but you get the general idea.)

Of course, the problem here is that you really don't have good  
heartbeat detection, because on both sides all the ACKs are going out  
the same interface and coming from a single address.  If the path goes  
down between A and C, you loose the entire connection, even though the  
path between B and D is still up and running.

The only real way to do full connectivity detection in this scenario  
is to be sending out 4 heartbeats:
	A -> C
	A -> D
	B -> C
	B -> D
And to have the acks come back with the same pair of IP addresses:
	C -> A
	D -> A
	C -> B
	C -> D
Then, no matter what link goes down, if there is still connectivity it  
will be found.  Part of the problem is that people think about this  
scenario as two separate pipes between the two hosts, when there  
really isn't: there are 4 different paths between them.

In the particular case I was dealing with, without changing the  
kernel, the only way to address this problem was to manually add host  
routes with specific source addresses on each host, so that you had:
	A <-> C
	B <-> D

			-David Borman

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Sep 2008 16:09:43 +0300

On 2008-9-30, at 16:00, ext David Borman wrote:
> kernel, the only way to address this problem was to manually add  
> host routes with specific source addresses on each host, so that you  
> had:
> 	A <-> C
> 	B <-> D

FWIW, a slightly nicer hack is to use source-based routing on  
platforms that offer it, i.e., forward outgoing packets with source  
address X to the next hop router of the interface that X is assigned  
to. (It's a bit nicer, because it doesn't require per-destination  
routes, only per interface routes, of which there are usually fewer  
and they're more stable.)

Lars

---

From: David Borman <[email-masked]>
Date: Tue, 30 Sep 2008 08:32:19 -0500

Yes.  The problem was that the SCTP implementation was relying on the  
routing table to determine the outgoing interface and from that, make  
the source address selection.

One detail that I didn't mention is that the addressing is really X.A/ 
X.B and Y.C/Y.D, where A and B are different subnets of network X, and  
C and D are different subnets of network Y.  So on the first host,  
even if it has a full routing table, it only has one route to network  
Y, and vice-versa, the second host only has one route to network X.

My main point is that while just sending one HB to each remote IP make  
sense in the simple case of two hosts each attached to two common  
networks, it does not address more complex situations where you have  
full routing permutations between the two hosts.  In the more general  
case where you have M addresses on one host, and N on the other, you  
need to send M*N heartbeats to cover all the combinations.

			-David Borman

On Sep 30, 2008, at 8:09 AM, Lars Eggert wrote:

>> host routes with specific source addresses on each host, so that  
>> you had:
>> 	A <-> C
>> 	B <-> D
>

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 30 Sep 2008 18:11:22 +0200

David,

a comment in-line.

Best regards
Michael

On Sep 30, 2008, at 3:32 PM, David Borman wrote:

> Yes.  The problem was that the SCTP implementation was relying on  
> the routing table to determine the outgoing interface and from that,  
> make the source address selection.
>
> One detail that I didn't mention is that the addressing is really  
> X.A/X.B and Y.C/Y.D, where A and B are different subnets of network  
> X, and C and D are different subnets of network Y.  So on the first  
> host, even if it has a full routing table, it only has one route to  
> network Y, and vice-versa, the second host only has one route to  
> network X.
>
> My main point is that while just sending one HB to each remote IP  
> make sense in the simple case of two hosts each attached to two  
> common networks, it does not address more complex situations where  
> you have full routing permutations between the two hosts.  In the  
> more general case where you have M addresses on one host, and N on  
> the other, you need to send M*N heartbeats to cover all the  
> combinations.
But you need to change the protocol (the procedures, not the packet  
format): You need to
consider source/destination address pairs when doing the error  
counting, path supervision,
congestion control and so on. It might be doable, but it requires some  
non-trivial work...
>> address X to the next hop router of the interface that X is  
>> assigned to. (It's a bit nicer, because it doesn't require per- 
>> destination routes, only per interface routes, of which there are  
>> usually fewer and they're more stable.)
>>
>> Lars
>
>

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 30 Sep 2008 18:08:24 +0200

Hi David,

see my comments in-line.

Best regards
Michael

On Sep 30, 2008, at 3:00 PM, David Borman wrote:

> sent to
So the routing setup does not reflect what you want to achieve....
> both remote addresses, but because the default route is used, they  
> are sent out only out one interface with one source address: A->C  
> heartbeats as D->A and D->B, and getting acks A->C and A->C.  (I  
> might not have all the details correct, but you get the general idea.)
>
> heartbeat detection, because on both sides all the ACKs are going  
> out the same interface and coming from a single address.  If the  
> path goes down between A and C, you loose the entire connection,  
> even though the path between B and D is still up and running.
The point is that you are testing with HEARTBEATs what you would do  
for sending DATA. You are
only testing destination addresses, as you would select destination  
addresses for sending
DATA to. You also have path error counters per destination....
> Then, no matter what link goes down, if there is still connectivity  
> it will be found.  Part of the problem is that people think about  
> this scenario as two separate pipes between the two hosts, when  
> there really isn't: there are 4 different paths between them.
You are then forcing SCTP to control the source address and also to  
supervise source/destination
address pairs, doing the error counting for is and also using it for  
transferring DATA. This
is not specified in RFC 4960.

The redundancy SCTP provides is only provided when the routing is set  
up accordingly.
> host routes with specific source addresses on each host, so that you  
That is one way. What I saw in SIGTRAN networks is that you have two  
networks and all nodes
are connected to both networks. So you added two routes, one for each  
network.
>>> A and C are in the same network and so are B and D. Since we have  
>>> a router in between, I also have the paths A <----> D and B <---->  
>>> C set up.
>>>
>>> that the HEARTBEAT ACK has to be sent back to the source IP  
>>> address i.e. A in this case. Now, what should be the reply path of  
>>> the HEARTBEAT ACK? Should it be D <----> A or is an implementation