Subject: [Sigtran] DATA chunks with an invalid length

From: "Horsham, Ian" <[email-masked]>
Date: Wed, 6 Jul 2011 15:13:43 +0100

Hello Everyone

I wonder if you would be able to help me regarding a question I have
about SCTP.

How should SCTP DATA chunks should be handled if the chunk length is
incorrectly set by the sender? Would I be right in thinking that these
chunks should be acknowledged and silently discarded or should they be
identified as gaps when sending a SACK in response? 

If anyone can help with this I would be very much appreciated.

Many Thanks and Kind Regards

Ian Horsham

This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-mail security system. For more information on a proactive 
managed e-mail secure service, visit http://www.cw.com/managed-exchange

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. 
If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you 
have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable & Wireless Worldwide plc 
Registered in England and Wales. Company Number 07029206
Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, England

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 6 Jul 2011 20:48:40 +0200

On Jul 6, 2011, at 4:13 PM, Horsham, Ian wrote:

> 
> 
> Hello Everyone
> 
> I wonder if you would be able to help me regarding a question I have about SCTP.
> 
> How should SCTP DATA chunks should be handled if the chunk length is incorrectly set by the sender? Would I be right in thinking that these chunks should be acknowledged and silently discarded or should they be identified as gaps when sending a SACK in response?
The behavior is not explicitly defined in the RFC... Could you be a bit more explicit what
is wrong with the length of the DATA chunk you are considering?

Best regards
Michael
> This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-mail security system. For more information on a proactive managed e-mail secure service, visit http://www.cw.com/managed-exchange 
> 
> The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. 
> 
> Cable & Wireless Worldwide plc Registered in England and Wales. Company Number 07029206 Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, England
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

---

From: "Horsham, Ian" <[email-masked]>
Date: Thu, 7 Jul 2011 09:31:24 +0100

Hi Michael

Thanks for taking the time to respond so quickly.

The data chunks have a chunk length which is larger than the actual chunk length. I've tried to show this by editing the format shown in the RFC (the length field is incremented by 1):-

3.3.1.  Payload Data (DATA) (0)

   The following format MUST be used for the DATA chunk:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0    | Reserved|U|B|E|    Length +1                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              TSN                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Stream Identifier S      |   Stream Sequence Number n    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Payload Protocol Identifier                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       /                 User Data (seq n of Stream S)                 /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I hope that this is clear, if not let me know and I'll see if I can provide a capture of an actual message.

Many thanks
Ian

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: 06 July 2011 19:49
To: Horsham, Ian
Cc: [email-masked]
Subject: Re: [Sigtran] DATA chunks with an invalid length

On Jul 6, 2011, at 4:13 PM, Horsham, Ian wrote:

> incorrectly set by the sender? Would I be right in thinking that these chunks should be acknowledged and silently discarded or should they be identified as gaps when sending a SACK in response?
The behavior is not explicitly defined in the RFC... Could you be a bit more explicit what is wrong with the length of the DATA chunk you are considering?

Best regards
Michael
> This e-mail has been scanned for viruses by the Cable&Wireless 
> Worldwide e-mail security system. For more information on a proactive managed e-mail secure service, visit http://www.cw.com/managed-exchange
> 
> The information contained in this e-mail is confidential and may also 
> be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
> 
> Cable & Wireless Worldwide plc Registered in England and Wales. 
> Company Number 07029206 Registered office: Liberty House, 76 
> Hammersmith Road, London W14 8UD, England _______________________________________________
> Sigtran mailing list
> [email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 7 Jul 2011 12:44:19 +0200

>   The following format MUST be used for the DATA chunk:
... and the additional byte is not present in the packet, right? (A tracefile (.pcap format) might
be helpful, you can send it privately). Then it would be a partial chunk? Or are the byte
available (either as padding or in a different chunk)?

Best regards
Michael

---

From: Chris Benson <[email-masked]>
Date: Thu, 7 Jul 2011 09:47:20 -0700 (PDT)

Ian,

There is one type of incorrect chunk length that is mentioned
in RFC 4960 Section 3.2. "Chunk Field Descriptions", in the
paragraphs about "Chunk Length" ...

   The Chunk Length value does not include terminating 
   padding of the chunk.  However, it does include 
   padding of any variable-length parameter except 
   the last parameter in the chunk.  The receiver
   MUST ignore the padding.

   Note: A robust implementation should accept the chunk 
   whether or not the final padding has been included in 
   the Chunk Length.

So if the Chunk Length field incorrectly includes the final
chunk padding bytes, then the chunk can be accepted and
processed normally. As Michael pointed out, the general 
behaviour is not specified, so I would suggest being 
robust (accepting the chunk normally) in most cases,
unless you are trying to validate the remote peer!

With thanks, from Chris Benson.

On Thu, 7 Jul 2011, Horsham, Ian wrote:

>>  Date: Thu, 7 Jul 2011 09:31:24 +0100
>>  From: "Horsham, Ian" <[email-masked]>
>>  To: Michael TÃ¼xen <[email-masked]>
>>  Cc:  <[email-masked]>
>>  From: Michael TÃ¼xen [mailto:[email-masked]] 
>>  Sent: 06 July 2011 19:49
>>  To: Horsham, Ian
>>  Cc: [email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 7 Jul 2011 23:00:32 +0200

> unless you are trying to validate the remote peer!
The situation is that the DATA chunk has a reported length of 37 bytes,
is the only chunk in the SCTP packet but the packet contains only 36 bytes
for the chunk. So it is a partial chunk. Sending such a chunk is a protocol
violation. FreeBSD just drops the packet, sending an ABORT would also be
OK for me. However, you can't SACK the TSN since you are missing at least
one byte of application data.

Best regards
Michael

---

From: "Horsham, Ian" <[email-masked]>
Date: Fri, 8 Jul 2011 10:41:46 +0100

Michael, Chris

Thanks very much for your advice on this.

As I thought, the RFC doesn't seem to cover this scenario and I guess it will depend on whether the chunk is "valid" and the function that SCTP does. These chunks are obviously being incorrectly formatted at source so the message has been delivered as expected. These chunks have been built incorrectly at source so the error has not been picked up in the transmission. 

My concern is if the chunks are not acknowledged then they may be retransmitted eventually resulting in association failure (one the max retransmissions have been exceeded). I would like to see these chunks acknowledged and discarded to avoid a potential ASP failure (if considering M3UA as the upper layer).

Is the function of SCTP is to verify the delivery and/or validate the remote peers formatting or just the delivery?

What are your views? I could be overlooking something I hadn't considered.

Many Thanks
Ian

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: 07 July 2011 22:01
To: Chris Benson
Cc: Horsham, Ian; [email-masked]
Subject: Re: [Sigtran] DATA chunks with an invalid length

On Jul 7, 2011, at 6:47 PM, Chris Benson wrote:

> Ian,
> 
> There is one type of incorrect chunk length that is mentioned in RFC 
> 4960 Section 3.2. "Chunk Field Descriptions", in the paragraphs about 
> "Chunk Length" ...
> 
> So if the Chunk Length field incorrectly includes the final chunk 
> padding bytes, then the chunk can be accepted and processed normally. 
> As Michael pointed out, the general behaviour is not specified, so I 
> would suggest being robust (accepting the chunk normally) in most 
> cases, unless you are trying to validate the remote peer!
The situation is that the DATA chunk has a reported length of 37 bytes, is the only chunk in the SCTP packet but the packet contains only 36 bytes for the chunk. So it is a partial chunk. Sending such a chunk is a protocol violation. FreeBSD just drops the packet, sending an ABORT would also be OK for me. However, you can't SACK the TSN since you are missing at least one byte of application data.

Best regards
Michael
>>> The data chunks have a chunk length which is larger than the actual 
>>> chunk length. I've tried to show this by editing the format shown in 
>>> the RFC (the length field is incremented by 1):-
>>> 
>>> The behavior is not explicitly defined in the RFC... Could you be a 
>>> bit more explicit what is wrong with the length of the DATA chunk 
>>> you are considering?
>>> 
>>> Best regards
>>> Michael
>>>> 
>>> Worldwide e-mail security system. For more information on a proactive
>>> The information contained in this e-mail is confidential and may 
>>> also be subject to legal privilege. It is intended only for the recipient(s) named above.
>>> [email-masked] https://www.ietf.org/mailman/listinfo/sigtran
>>

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 8 Jul 2011 11:59:58 +0200

> Is the function of SCTP is to verify the delivery and/or validate the remote peers formatting or just the delivery?
OK, I've looked at http://tools.ietf.org/html/rfc4960.

The chunk we are discussing here is a partial chunk. On page 93 it is stated:

   An endpoint MUST process received chunks in their order in the
   packet.  The receiver uses the Chunk Length field to determine the
   end of a chunk and beginning of the next chunk taking account of the
   fact that all chunks end on a 4-byte boundary.  If the receiver
   detects a partial chunk, it MUST drop the chunk.

The last sentence make clear that the FreeBSD behavior is the right one.
Not sending an ABORT, not sending a SACK.

Best regards
Michael
>>>>> also