Subject: [Fwd: Re: [Tsvwg] [SCTP implementor]multi-home initialization]

From: devayya <[email-masked]>
Date: Tue, 01 Aug 2006 16:43:12 +0530

I am just forwarding this mail to sctp implementors list.

-------- Original Message --------
Subject: 	Re: [Tsvwg] [SCTP implementor]multi-home initialization
Date: 	Tue, 01 Aug 2006 15:30:00 +0530
From: 	Bhanu Prakash <[email-masked]>
To: 	[email-masked]
CC: 	[email-masked]
References: 	<[email-masked]> 
<[email-masked]>

Brian,

Consider the following scenario, where endpoint A is having IP x.x.x.x (not multi-homed) and endpoint B is having p.p.p.p and q.q.q.q multi-homed) 
ip addresses.

 | Endpoint A|                                           |Endpoint B|
 (x.x.x.x)                                            (p.p.p.p and q.q.q.q)
     |                                                        |
     |           --------------INIT-------------------->      |
                                    (DEST = q.q.q.q)
     |                                                        |
     |           <------------INIT ACK -----------------      |
                                    (SOURCE = p.p.p.p in IP header)
                                    (address list = p.p.p.p and q.q.q.q)

In the above case the end point A is sending ABORT since it has received
INIT-ACK from a destination unknown to it (i.e. by looking at source ip
address in IP header) address, is it correct..?

Should the endpoint A accept this INIT-ACK considering the fact that the
ip address list in INIT-ACK had q.q.q.q  or  should the end point B send the
INIT-ACK having source ip address q.q.q.q in IP header ..?

Thanks,
Bhanu.

Brian F. G. Bidulock wrote:

>Bhanu,
>
>Bhanu Prakash wrote:                            (Thu, 27 Jul 2006 14:47:24)
>  
>
>>   Hi,
>>   Please  consider the following scenario, where endpoint A is having IP
>>   x.x.x.x (not multi-homed) and endpoint B is having p.p.p.p and q.q.q.q
>>   (multi-homed) ip addresses.
>>         | Endpoint
>>   A|
>>   |Endpoint B|
>>         |           --------------INIT-------------------->      |
>>                                             (DEST = p.p.p.p)
>>          |            <-----------INIT ---------------------       |
>>                  (SRC  = q.q.q.q) (has the list of ip address from B i.e
>>   q.q.q.q and p.p.p.p)
>>          |             ------------INIT ACK --------------->    |
>>                                     (DEST = q.q.q.q)
>>             |                    <--------- COOKIE ECHO-----------     |
>>   Should we accept this COOKIE p.p.p.p?
>>                                           (SRC= p.p.p.p )
>>
>>             |                  <----------COOKIE ECHO----------     | Or
>>   should we accept this COOKIE  q.q.q.q?
>>                                            (SRC = q.q.q.q)
>>          |              -------------COOKIE ACK---------->    |
>>                                                         (DEST = q.q.q.q)
>>
>>   If  we  accept  COOKIE  from  p.p.p.p  then  is it considered as a new
>>   association or is it considerd for the INIT and INIT ACK association.?
>>   Please explain.
>>   Best regards,
>>   bhanu
>>    
>>
>
>If the COOKIE-ECHO contains the valid signed Cookie from the INIT-ACK, then
>it belong to nothing else (regardless of what its source address is).
>Endpoint A will have verified destination q.q.q.q (with the cookie) and can
>send to q.q.q.q so that is then appropriate address for the COOKIE-ACK.
>
>The only question is why Enpoint B does not respond with an INIT-ACK?  It
>should.
>
>--brian
>
>  
>

---

From: Randall Stewart <[email-masked]>
Date: Tue, 01 Aug 2006 22:20:23 -0400

devayya wrote:
> Consider the following scenario, where endpoint A is having IP x.x.x.x 
> (not multi-homed) and endpoint B is having p.p.p.p and q.q.q.q 
> multi-homed) ip addresses.
> 
> 
> 

No, its incorrect... Endpoint A is in error.. it needs to
look into the address list and find the address q.q.q.q.q  (where
he sent the data).. Sending an ABORT is an error..

> INIT-ACK having source ip address q.q.q.q in IP header ..?

Yes.. it should.. to do otherwise is incorrect.

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: devayya <[email-masked]>
Date: Wed, 02 Aug 2006 10:18:28 +0530

Randall,

Please see the attached mail discussion we had earlier with the tsvwg 
group.  As per this,  INIT ACK chunk should have source IP address same 
as the destination IP address to which the INIT was sent.
What is your opinon on this.

thanks and regards,
devayya

Randall Stewart wrote:

>> Consider the following scenario, where endpoint A is having IP 
>> x.x.x.x (not multi-homed) and endpoint B is having p.p.p.p and 
>> q.q.q.q multi-homed) ip addresses.
>>
>>
>>

Subject: Re: [Tsvwg] sctp
From: "Brian F. G. Bidulock" <[email-masked]>
To: Amit Goel <[email-masked]>
Cc: tsvwg <[email-masked]>
Date: Wed, 21 Jun 2006 05:13:43 -0600
List-Id: Transport Area Working Group <tsvwg.ietf.org>

Amit,

Amit Goel wrote:                           (Wed, 21 Jun 2006 01:44:57)
> 
> If an SCTP implementation uses raw sockets and also populates the source
> address in the IP Header itself, for HB-ACK / SACK messages does it need
> to care about filling correct source address (interface on which data
> packet arrived) , or can SCTP also be careless about it since there is
> no response expected for an ACK.

In general the source IP address can be any IP address belonging to the
association at the sending endpoint.  The exception is, of course, the
INIT-ACK chunk whose source IP address must be the destination IP
address to which the INIT was sent, and the recommendations in RFC 4460
Section 2.39.

--brian

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Aug 2006 08:07:06 +0200

Devayya,

Brian is wrong here... The destination address of the INIT must be the
source address of the INIT-ACK or listed in the list of addresses inside
the INIT-ACK.

Best regards
Michael

On Aug 2, 2006, at 6:48 AM, devayya wrote:

> Randall,
>
> Please see the attached mail discussion we had earlier with the  
> tsvwg group.  As per this,  INIT ACK chunk should have source IP  
> address same as the destination IP address to which the INIT was sent.
> Date: June 21, 2006 1:13:43 PM GMT+02:00
> Reply-To: [email-masked]
>
>
> Amit,
>

---

From: devayya <[email-masked]>
Date: Wed, 02 Aug 2006 12:38:11 +0530

Michael,

But rfc 4460 section 2.36.2 says following:
"   1) Any address passed to the sender of the INIT by its upper layer is
      automatically considered to be CONFIRMED.
   2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
      the one that the INIT-ACK was sent to.
   3) All other addresses not covered by rules 1 and 2 are considered
      UNCONFIRMED and are subject to probing for verification.
   To probe an address for verification, an endpoint will send
   HEARTBEATs including a 64-bit random nonce and a path indicator (to
   identify the address that the HEARTBEAT is sent to) within the
   HEARTBEAT parameter. "

So doesnt this mean that the only after confirmation of the Ip address 
the packets can be sent to any address in the INIT or INIT ACK ip 
address list.

Thanks and regards,
devayya

---

From: devayya <[email-masked]>
Date: Wed, 02 Aug 2006 19:20:30 +0530

Michael,

Refer rfc 3286, section 4. Which clearly says that
"when the server receives an INIT chunk from a client to initiate an 
SCTP association, the server always sends the response INIT ACK chunk to 
the source address that was in the IP header of the INIT.

Thanks and regards,
devayya

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Aug 2006 16:21:27 +0200

Devayya,

RFC 3286 is informational and not a protocol specification. RFC 2960  
states
that you need to look into the INIT and INIT-ACK. See section of 2.18
of RFC 4460, or the bis document of RFC 2960.

Best regards
Michael

On Aug 2, 2006, at 3:50 PM, devayya wrote:

> "when the server receives an INIT chunk from a client to initiate  
> an SCTP association, the server always sends the response INIT ACK  
> chunk to the source address that was in the IP header of the INIT.
>
> Thanks and regards,
> devayya
>
> Michael Tuexen wrote:
>
>> Devayya,
>>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Aug 2006 16:23:03 +0200

Devayya,

path confirmation is about the selection of the destination address, not
about the the lookup process. You accept packets from unconfirmed  
addresses,
of course.

Best regards
Michael
On Aug 2, 2006, at 9:08 AM, devayya wrote:

> So doesnt this mean that the only after confirmation of the Ip  
> address the packets can be sent to any address in the INIT or INIT  
> ACK ip address list.
>
> Thanks and regards,
> devayya
>
> Michael Tuexen wrote:
>
>> Devayya,
>>

---

From: devayya <[email-masked]>
Date: Thu, 03 Aug 2006 09:28:48 +0530

But if we accept from any unconfirmed ip address, will it not create 
security issue.
i.e if a endpoint has sent a INIT / INIT ACK with confirmed address and 
in between any third party endpoint can send a INIT / INIT ACK with a 
unconfirmed address and try to create a association out of this. How 
sctp stack be able to prevent this?

regards,
devayya

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 3 Aug 2006 16:02:57 +0200

The only crucial points security wise is which addresses you consider  
confirmed... If you
send an INIT to A and get back an INIT-ACK from B you consider A  
confirmed, not B.

Best regards
Michael

On Aug 3, 2006, at 5:58 AM, devayya wrote:

> But if we accept from any unconfirmed ip address, will it not  
> create security issue.
> i.e if a endpoint has sent a INIT / INIT ACK with confirmed address  
> and in between any third party endpoint can send a INIT / INIT ACK  
> with a unconfirmed address and try to create a association out of  
> this. How sctp stack be able to prevent this?
>
> regards,
> devayya
>
> Michael Tuexen wrote:
>
>> Devayya,
>>
>>> address the packets can be sent to any address in the INIT or  
>>> INIT  ACK ip address list.
>>>
>>> Thanks and regards,
>>> devayya
>>>
>>> Michael Tuexen wrote:
>>>
>>>> Devayya,
>>>>
>>>>> Please see the attached mail discussion we had earlier with  
>>>>> the   tsvwg group.  As per this,  INIT ACK chunk should have  
>>>>> source IP   address same as the destination IP address to which  
>>>>> the INIT was  sent.
>>>>>>> Consider the following scenario, where endpoint A is having  
>>>>>>> IP   x.x.x.x (not multi-homed) and endpoint B is having  
>>>>>>> p.p.p.p and   q.q.q.q multi-homed) ip addresses.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> | Endpoint A|                                           |  
>>>>>>> Endpoint B|
>>>>>>> (x.x.x.x)                                             
>>>>>>> (p.p.p.p  and  q.q.q.q)
>>>>>>>     |                                                        |

---

From: Randall Stewart <[email-masked]>
Date: Thu, 03 Aug 2006 21:50:44 -0400

I did not take part in that discussion.. and NO  the
email sent is INCORRECT ..

R

devayya wrote:
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [Tsvwg] sctp
> From:
> "Brian F. G. Bidulock" <[email-masked]>
> Date:
> CC:
> tsvwg <[email-masked]>