Re: 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
>>