netdev - Re: [PATCH net-next-2.6 v4 4/5] sctp: Add ASCONF operation on the single-homed host

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 26 Apr 2011 00:34:14 +0900
From:	Michio Honda <micchie@....wide.ad.jp>
To:	Wei Yongjun <yjwei@...fujitsu.com>
Cc:	netdev@...r.kernel.org, lksctp-developers@...ts.sourceforge.net
Subject: Re: [PATCH net-next-2.6 v4 4/5] sctp: Add ASCONF operation on the single-homed host

I just re-submitted cumulative patches.  

About your suggestion to split the patch that reset route at the reception of ASCONF-ACK, I removed those codes.  
Because we'd already reset the route just before ASCONF, so not needed after the ASCONF-ACK reception.  
I believe the other parts follow all your comments.  
I also cleaned up many parts in single-homed host support patch.  

Thanks,
- Michio

On Apr 25, 2011, at 11:45 , Wei Yongjun wrote:

> 
>> Yes, I think the association cannot be kept, if the single-homed ASCONF receiver moves to the new network before sending ASCONF-ACK.  
>> Am I missing?
> 
> Oh, yeah, you are right.:-)
> 
>> Thanks,
>> - Michio
>> 
>> On Apr 25, 2011, at 11:02 , Wei Yongjun wrote:
>> 
>>>> Hi, 
>>>> 
>>>> Such operation would not be supported by specification, in Sec.5.3 in RFC 5061:
>>>>  F1)  When adding an IP address to an association, the IP address is
>>>>       NOT considered fully added to the association until the ASCONF-
>>>>       ACK arrives.  This means that until such time as the ASCONF
>>>>       containing the add is acknowledged, the sender MUST NOT use the
>>>>       new IP address as a source for ANY SCTP packet except on
>>>>       carrying an ASCONF Chunk. 
>>>> 
>>>> I think this means we cannot send ASCONF-ACK from the new address even if it bundles ASCONF...
>>> If so, both side do not have valid address to send the such
>>> ASCONF-ACK, and can not recv ASCONF-ACK.
>>> 
>>>> - Michio
>>>> 
>>>> On Apr 25, 2011, at 9:57 , Wei Yongjun wrote:
>>>> 
>>>>>> On Apr 22, 2011, at 13:10 , Wei Yongjun wrote:
>>>>>> 
>>>>>>>> Since the sender MUST NOT use the  new IP address as a source for ANY SCTP
>>>>>>>> packet except on  carrying an ASCONF Chunk. And ASCONF chunk can be bundled.
>>>>>>>> How about this change. If so, you do not need change to sctp_outq_tail();
>>>>>>>> 
>>>>>>>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>>>>>>>> index 1c88c89..bd6cc9c 100644
>>>>>>>> --- a/net/sctp/outqueue.c
>>>>>>>> +++ b/net/sctp/outqueue.c
>>>>>>>> @@ -754,6 +754,13 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
>>>>>>>> 	 */
>>>>>>>> 
>>>>>>>> 	list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) {
>>>>>>>> +		/* RFC 5061, 5.3
>>>>>>>> +		 * F1) This ...
>>>>>>>> +		 */
>>>>>>>> +		if (q->asoc->src_out_of_asoc_ok &&
>>>>>>>> +		    chunk->chunk_hdr->type != SCTP_CID_ASCONF)
>>>>>>> SCTP_CID_ASCONF_ACK should be also allowed, the peer may
>>>>>>> send ASCONF to do the same thing at the same time.
>>>>>> Sorry for my bad understanding, 
>>>>>> Do you mean the situation: "the peer (ASCONF receiver) may send ASCONF-ACK to the unconfirmed destination"?
>>>>>> Or do you mean following situation?
>>>>>> 1. the pear sends ADD/DEL ASCONF to me, 
>>>>>> 2. I receive it, 
>>>>>> 3. I migrate to the other network and get new address, 
>>>>>> 4. I send ASCONF-ACK to the peer from the new address
>>>>> Yes, If both side send ADD/DEL ASCONF to del the last one
>>>>> address at the same time like this:
>>>>> 
>>>>> ASCONF  -----    ------ASCONF
>>>>> (ADD/DEL)    \  /     (ADD/DEL)
>>>>>            \/        
>>>>>            /\
>>>>>      <----/  \----->
>>>>> ASCONF-ACK---\  /------ASCONF-ACK
>>>>>            \/
>>>>>            /\
>>>>>      <----/  \----->
>>>>> 
>>>>> But I do not test for it. Not sure we need to do this, can you
>>>>> check this before commit your new patchset?
>>>>> 
>>>>> 
>>>>>>>> +			continue;
>>>>>>>> +
>>>>>>>> 		list_del_init(&chunk->list);
>>>>>>>> 
>>>>>>>> 		/* Pick the right transport to use. */
>>>>>>>> @@ -881,6 +888,9 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
>>>>>>>> 		}
>>>>>>>> 	}
>>>>>>>> 
>>>>>>>> +	if (q->asoc->src_out_of_asoc_ok)
>>>>>>>> +		goto sctp_flush_out;
>>>>>>>> +
>>>>>>>> 	/* Is it OK to send data chunks?  */
>>>>>>>> 	switch (asoc->state) {
>>>>>>>> 	case SCTP_STATE_COOKIE_ECHOED:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>> the body of a message to majordomo@...r.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@...r.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>> 
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@...r.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html