linux-sctp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: linux-sctp@vger.kernel.org
Subject: RE: Heartbeat on closed SCTP sockets?
Date: Thu, 08 Oct 2020 08:13:38 +0000	[thread overview]
Message-ID: <3600af6969d14fcfbe33e05cef8beac2@AcuMS.aculab.com> (raw)
In-Reply-To: <1FB70B30-857C-4CD9-A05C-4BA15F57B1D2@list.fink.org>

From: Andreas Fink
> Sent: 08 October 2020 07:40
> 
> by reading the linux diver source I discovered this code segment in input.c around line 188
> 
> 
> /*
> 	 * RFC 2960, 8.4 - Handle "Out of the blue" Packets.
> 	 * An SCTP packet is called an "out of the blue" (OOTB)
> 	 * packet if it is correctly formed, i.e., passed the
> 	 * receiver's checksum check, but the receiver is not
> 	 * able to identify the association to which this
> 	 * packet belongs.
> 	 */
> 
> if (!asoc) {
> 	if (sctp_rcv_ootb(skb)) {
> 		__SCTP_INC_STATS(net, SCTP_MIB_OUTOFBLUES);
> 		goto discard_release;
> 	}
> }
> 
> This means out of the blue packets are always ignored and dropped.
> 
> the RFC however says:
> 
>    8) The receiver should respond to the sender of the OOTB packet with
>       an ABORT.  When sending the ABORT, the receiver of the OOTB packet
>       MUST fill in the Verification Tag field of the outbound packet
>       with the value found in the Verification Tag field of the OOTB
>       packet and set the T-bit in the Chunk Flags to indicate that no
>       TCB was found.  After sending this ABORT, the receiver of the OOTB
>       packet shall discard the OOTB packet and take no further action.
> 
> I think this is what I am seeing. The remote sends OOTB messages, we dont reply with abort which means
> the remote doesnt reset the connection.
> There must be a second issue that the socket structures are not in sync up.

But I'm not sure sending an ABORT is right.
You need to stop the remote sending messages to your IP address
not abort the SCTP connection itself.
Especially on an unverified path.

It is pretty easy to get an IP address that is just 'wrong'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andreas Fink' <afink@list.fink.org>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>
Subject: RE: Heartbeat on closed SCTP sockets?
Date: Thu, 8 Oct 2020 08:13:38 +0000	[thread overview]
Message-ID: <3600af6969d14fcfbe33e05cef8beac2@AcuMS.aculab.com> (raw)
Message-ID: <20201008081338.3y6B8Lux6Jom3AdYemDe020j5cmPiJ0h_P2o0G_l1sM@z> (raw)
In-Reply-To: <A95BC0CF-7C1D-4BB2-B9EF-8222C5BE9B49@list.fink.org>

From: Andreas Fink
> Sent: 08 October 2020 07:40
> 
> by reading the linux diver source I discovered this code segment in input.c around line 188
> 
> 
> /*
> 	 * RFC 2960, 8.4 - Handle "Out of the blue" Packets.
> 	 * An SCTP packet is called an "out of the blue" (OOTB)
> 	 * packet if it is correctly formed, i.e., passed the
> 	 * receiver's checksum check, but the receiver is not
> 	 * able to identify the association to which this
> 	 * packet belongs.
> 	 */
> 
> if (!asoc) {
> 	if (sctp_rcv_ootb(skb)) {
> 		__SCTP_INC_STATS(net, SCTP_MIB_OUTOFBLUES);
> 		goto discard_release;
> 	}
> }
> 
> This means out of the blue packets are always ignored and dropped.
> 
> the RFC however says:
> 
>    8) The receiver should respond to the sender of the OOTB packet with
>       an ABORT.  When sending the ABORT, the receiver of the OOTB packet
>       MUST fill in the Verification Tag field of the outbound packet
>       with the value found in the Verification Tag field of the OOTB
>       packet and set the T-bit in the Chunk Flags to indicate that no
>       TCB was found.  After sending this ABORT, the receiver of the OOTB
>       packet shall discard the OOTB packet and take no further action.
> 
> I think this is what I am seeing. The remote sends OOTB messages, we dont reply with abort which means
> the remote doesnt reset the connection.
> There must be a second issue that the socket structures are not in sync up.

But I'm not sure sending an ABORT is right.
You need to stop the remote sending messages to your IP address
not abort the SCTP connection itself.
Especially on an unverified path.

It is pretty easy to get an IP address that is just 'wrong'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2020-10-08  8:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 16:39 Heartbeat on closed SCTP sockets? Andreas Fink
2020-10-05 16:39 ` Andreas Fink
2020-10-05 17:16 ` Marcelo Ricardo Leitner
2020-10-05 17:16   ` Marcelo Ricardo Leitner
2020-10-06 13:31 ` Andreas Fink
2020-10-06 13:31   ` Andreas Fink
2020-10-08  6:40 ` Andreas Fink
2020-10-08  6:40   ` Andreas Fink
2020-10-08  8:13 ` David Laight [this message]
2020-10-08  8:13   ` David Laight
2020-10-08  9:08 ` Michael Tuexen
2020-10-08  9:08   ` Michael Tuexen
2020-10-08 10:57 ` Andreas Fink
2020-10-08 10:57   ` Andreas Fink
2020-10-08 11:02 ` Andreas Fink
2020-10-08 11:02   ` Andreas Fink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3600af6969d14fcfbe33e05cef8beac2@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=linux-sctp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).