Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision

[Michael Tuexen <[e-mail]>]

> On 1. Mar 2019, at 14:46, Proshin, Maksim <[e-mail]> wrote:
> 
> Hi Michael,
> 
> Yes, it seems lksctp always puts a new random number into INIT ACK when it receives INIT. 
I see. Did you also test with FreeBSD? However, it seems to be a motivation to add SCTP-AUTH
support to packetdrill...

Best regards
Michael
> Thanks for your prompt response!
> 
> BR, Maxim
> 
> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]] 
> Sent: Friday, March 1, 2019 16:29
> To: Proshin, Maksim <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision
> 
> 
> 
>> On 1. Mar 2019, at 14:05, Proshin, Maksim <[e-mail]> wrote:
>> 
>> Hi Michael, tsvwg,
>> 
>> I have a doubt about the RANDOM parameter from RFC 4895 which was caused by interoperability tests with different SCTP implementations.
>> RFC 4895 has the following text in Section 6.1:
>>   In case
>>   of INIT collision, the rules governing the handling of this Random
>>   Number follow the same pattern as those for the Verification Tag, as
>>   explained in Section 5.2.4 of RFC 2960 [5].  Therefore, each endpoint
>>   knows its own Random Number and the peer's Random Number after the
>>   association has been established.
>> 
>> and RFC 4960 which obsoletes RFC 2960 has the following statement in Section 5.2.1:
>> 
>>   Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
>>   respond with an INIT ACK using the same parameters it sent in its
>>   original INIT chunk (including its Initiate Tag, unchanged).
>> 
>> Based on those 2 statements I assume that SCTP must always respond with the same Random Number when it sends INIT ACK in response to INIT received in the COOKIE-WAIT state. Is my understanding correct?    
> Yes, I would say so.
> 
> Is an open source implementation not following these rules?
> 
> Best regards
> Michael
>> 
>> BR, Maxim
>