Re: DATA chunks with an invalid length

On Jul 8, 2011, at 11:41 AM, Horsham, Ian wrote:

> 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?
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
> 
> What are your views? I could be overlooking something I hadn't considered.
> 
> Many Thanks
> Ian
> 
> 
> -----Original Message-----
> From: Michael Tüxen [mailto:[email protected]] 
> Sent: 07 July 2011 22:01
> To: Chris Benson
> Cc: Horsham, Ian; [email protected]
> 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" ...
>> 
>>  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!
> 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
>> 
>> 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 protected]>
>>>> To: Michael Tüxen <[email protected]>
>>>> Cc:  <[email protected]>
>>>> Subject: Re: [Sigtran] DATA chunks with an invalid length
>>>> 
>>>> 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 protected]]
>>>> Sent: 06 July 2011 19:49
>>>> To: Horsham, Ian
>>>> Cc: [email protected]
>>>> Subject: Re: [Sigtran] DATA chunks with an invalid length
>>>> 
>>>> 
>>>> 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
>>>>> 
>>>>> 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 _______________________________________________
>>>>> Sigtran mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/sigtran
>>>> 
>>>> 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 protected] https://www.ietf.org/mailman/listinfo/sigtran
>>> 
> 
> 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
> 
>