linux-kernel - Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <54C2807E.8080607@redhat.com>
Date:	Fri, 23 Jan 2015 18:10:22 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Vlad Yasevich <vyasevich@...il.com>
CC:	Sun Paul <paulrbk@...il.com>, linux-sctp@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	tuexen@...muenster.de
Subject: Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans
 is reached

On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>> ...
>>> I would like to check the behave in LKSCTP.
>>>
>>> we are running DIAMETER message over SCTP, and we have set the
>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>
>>> We noticed that when remote peer have retry to send the same request
>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>> "association exceeded its max_retrans count".
>>>
>>> We would like to know whether this is the correct behavior? is there
>>> any other option that we can alter in order to avoid the ABORT chunk
>>> being sent?
>>
>> I don't recall the RFC saying to send an ABORT, but let me double
>> check in the mean time.
>
> The RFC is silent on the matter.  The abort got added in 3.8 so
> it's been there for a while.

I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
exceeded") added the behaviour.

>> Hmm, untested, but could you try something like that?
>>
>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>> index fef2acd..5ce198d 100644
>> --- a/net/sctp/sm_sideeffect.c
>> +++ b/net/sctp/sm_sideeffect.c
>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>           sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>                   SCTP_ULPEVENT(event));
>>
>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>> +        error != SCTP_ERROR_NO_ERROR) {
>>           abort = sctp_make_violation_max_retrans(asoc, chunk);
>>           if (abort)
>>               sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>
> This would pretty much stop all ABORTs due to excessive rtx.  Might
> as well take the code out :).
>
> I was a bit concerned about this ABORT when it went in.

So effectively, if I understand the argument from the commit, the
assumption is that the ABORT would never reach the peer anyway, but
is a way for tcpdump users to see on the wire that rtx limit has
been exceeded and since there's not mentioned anything in the RFC
about this, it doesn't break it. Hm.

Sun Paul, what exactly broke in your scenario? Can you be more explicit?

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/