Subject: [Tsvwg] sctp

From: devayya <[email-masked]>
Date: Tue, 20 Jun 2006 18:08:55 +0530

Hi,

I have a SCTP multi-home setup.
Consider a case where there are two paths on the originating side 79 and 
7a, And there are two destination paths 7b (path index 0) and 7c(path 
index 1).

If INIT has gone from 79 to 7b and INITACK recived from 7b to 79, then 
if we receive cookie echo from 7c to 79 Is it valid chunk?
Then, we send cookie Ack from 79 to 7c. The heartbeat is sent from 79 to 
7b with path index 0 and 79 to 7c and path index 1.
Now if the destination side sends hearbeat Ack from 7b to 79 with path 
index as 1 and 7b to 79 as path index 0, Is it valid hearbeat ack, Do we 
continue with the association?

Can somebody please clarify this...

Thanks and Best regards,
devayya

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Jun 2006 06:51:27 -0600

devayya,

devayya wrote:                                 (Tue, 20 Jun 2006 18:08:55)
> Can somebody please clarify this...

I think that you need to provide more detail (e.g. what addresses are in
the packets involved, not just where there are sent from and too).  Could
you draw it out in detail?

--brian

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

---

From: devayya <[email-masked]>
Date: Tue, 20 Jun 2006 18:45:56 +0530

Brian,
Sorry for the long discripton. I had no intention of confusing anybody.

Here is the flow,

x.x.x.x             ---------INIT---------->        p.p.p.p  (for him 
x.x.x.x is path 1 and y.y.y.y is path 2)
y.y.y.y                                                            q.q.q.q

x.x.x.x             <--------INIT ACK------      p.p.p.p
y.y.y.y                                                            q.q.q.q

y.y.y.y             -------COOKIE ECHO->       p.p.p.p        (Is it valid)
                          
y.y.y.y              <------COOKIE ACK---       p.p.p.p

y.y.y.y              <-----HEART BEAT ------     p.p.p.p (sends with 
heartbeat info to path 2)

x.x.x.x               <----HEART BEAT------     p.p.p.p (sends with 
heart beat info to path 1)

y.y.y.y               ------HEARTBEAT ACK-->   p.p.p.p (response in 
heart beat info is from path 2 but the heartbeat info filled as if it  
is sending from path 1)

x.x.x.x               ------HEART BEAT ACK-->  p.p.p.p (response in 
heart beat info is from path 1 but the hearbeat info filled as if it  is 
sending from path 2)

In this scenario should we accept hearbeat Ack , as it is received from 
correct path but the info contained in it is indicating the other path 
index. In our case y.y.y.y is actually path 2 but he is sending 
heartbeat info saying he is actually path 1.

Thanks and best regards,
devayya

---

From: <[email-masked]>
Date: Tue, 20 Jun 2006 16:54:53 +0300

Hi!

	The COOKIE ECHO is valid as it is sent from a valid source address indicated already in the INIT chunk. Same would happen if for example the INIT ACK would have been sent from q.q.q.q.

	But I don't understand your problem about the HEARTBEAT ACK. I suppose that what you mean is that the HEARTBEAT sent p.p.p.p->y.y.y.y is answered by a HEARTBEAT ACK sent from x.x.x.x. This is not what one should normally expect, but if the HEARTBEAT is legal and has the correct nonce, you should simply recognize it and clear the retransmission counter of y.y.y.y. I'm not that sure about the RTO measure, but I think that you could make the measure in any case.

	BR Iván Arias Rodríguez 

________________________________

	From: ext devayya [mailto:[email-masked]] 
	Sent: 20 June, 2006 16:16
	To: [email-masked]; tsvwg
	Subject: Re: [Tsvwg] sctp

	Brian,
	
	Here is the flow,
	
	x.x.x.x             ---------INIT---------->        p.p.p.p  (for him x.x.x.x is path 1 and y.y.y.y is path 2)
	y.y.y.y                                                            q.q.q.q

	                           
	
	y.y.y.y              <-----HEART BEAT ------     p.p.p.p (sends with heartbeat info to path 2)
	
	x.x.x.x               <----HEART BEAT------     p.p.p.p (sends with heart beat info to path 1)
	
	y.y.y.y               ------HEARTBEAT ACK-->   p.p.p.p (response in heart beat info is from path 2 but the heartbeat info filled as if it  is sending from path 1)
	
	x.x.x.x               ------HEART BEAT ACK-->  p.p.p.p (response in heart beat info is from path 1 but the hearbeat info filled as if it  is sending from path 2)
	
	In this scenario should we accept hearbeat Ack , as it is received from correct path but the info contained in it is indicating the other path index. In our case y.y.y.y is actually path 2 but he is sending heartbeat info saying he is actually path 1.
	
	Thanks and best regards,
	devayya

		devayya,

		
		
		--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Jun 2006 13:46:44 -0600

devayya,

devayya wrote:                                (Tue, 20 Jun 2006 18:45:56)
>
>    In  this  scenario  should  we accept hearbeat Ack , as it is received
>    from correct path but the info contained in it is indicating the other
>    path  index.  In our case y.y.y.y is actually path 2 but he is sending

There is really no such thing as a "path" in IP, at least not in the
stable circuit-oriented sense that you take here.  It is a datagram
protocol.  All other things being the same, as long as the HB-ACK can be
verified (with the nonce) there no reason to believe that it is not from
the address from which it claims to be from.  Most implementations have
little (or no) control over what "path" a packet takes, just what
destination to which it is sent.  Some implementations cannot control
the source address of sent packets, they are automatically addressed
with a source address belonging to the outgoing interface.  Therefore
one accepts the HB-ACK if it truely corresponds to a sent HB (as Ivan
says, has the correct nonce).

--brian

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Jun 2006 11:45:39 -0400

Ivan:

I agree 100% with you... in fact many implementations
that I have seen tend to end up putting the sent
to IP address in the HB.. that way they know
where it was sent no matter where it came from..

Since the peers routing is NOT under your control just
because you send to an address does NOT mean the
peer will send the HB-ACK back from the same address.. its
routing tables could make that impossible :-0

R

[email-masked] wrote:
> Hi!
> 
> The COOKIE ECHO is valid as it is sent from a valid source address
> indicated already in the INIT chunk. Same would happen if for example
> the INIT ACK would have been sent from q.q.q.q.
> 
> But I don't understand your problem about the HEARTBEAT ACK. I
> suppose that what you mean is that the HEARTBEAT sent
> p.p.p.p->y.y.y.y is answered by a HEARTBEAT ACK sent from x.x.x.x.
> This is not what one should normally expect, but if the HEARTBEAT is
> legal and has the correct nonce, you should simply recognize it and
> clear the retransmission counter of y.y.y.y. I'm not that sure about
> the RTO measure, but I think that you could make the measure in any
> case.
> 
> BR Iván Arias Rodríguez
> 
> 
> From: ext devayya [mailto:[email-masked]] Sent: 20 June,
> 2006 16:16 To: [email-masked]; tsvwg Subject: Re: [Tsvwg] sctp 
> 

>  Brian, Sorry for the long discripton. I had no intention of
> confusing anybody.  Here is the flow,  x.x.x.x
> ---------INIT---------->        p.p.p.p  (for him x.x.x.x is path 1
> and y.y.y.y is path 2) y.y.y.y
> q.q.q.q  x.x.x.x             <--------INIT ACK------      p.p.p.p 
> y.y.y.y
> q.q.q.q  y.y.y.y             -------COOKIE ECHO->       p.p.p.p
> (Is it valid)  y.y.y.y              <------COOKIE ACK---
> p.p.p.p  y.y.y.y              <-----HEART BEAT ------     p.p.p.p
> (sends with heartbeat info to path 2)  x.x.x.x
> <----HEART BEAT------     p.p.p.p (sends with heart beat info to path
> 1)  y.y.y.y               ------HEARTBEAT ACK-->   p.p.p.p (response
> in heart beat info is from path 2 but the heartbeat info filled as if
> it  is sending from path 1)  x.x.x.x               ------HEART BEAT
> ACK-->  p.p.p.p (response in heart beat info is from path 1 but the
> hearbeat info filled as if it  is sending from path 2)  In this
> scenario should we accept hearbeat Ack , as it is received from
> correct path but the info contained in it is indicating the other
> heartbeat info saying he is actually path 1.  Thanks and best
> regards, devayya   Brian F. G. Bidulock wrote: 
> 
> devayya,  devayya wrote:                                 (Tue, 20 Jun
> 2006 18:08:55) 
> 
>  I think that you need to provide more detail (e.g. what addresses
> are in the packets involved, not just where there are sent from and
> too).  Could you draw it out in detail?  --brian  
> 
> 
> 
> 
> 

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)