Subject: [Sigtran] M3UA: Message Length

From: santosh nayak <[email-masked]>
Date: Thu, 10 Oct 2013 15:10:48 +0530

Hi,

We have a situation where message is being rejected at M3UA layer due to
buffer length is not equal to message length.

What is the significance of Message Length and its importance with
padding...

in the current issue M3UA peer is sending the data buffer of size 122 bytes
to KSCTP. But message length parameter of M3UA common header contains a
value of 124 and KSCTP is doing the padding at its level of 2 bytes which
is observed from the wireshark traces.

Now at DUT message droped with reason  (*message length parameter is
greater than actual M3UA data buffer size*)

Is this expected??? Please comment on this...

As per RFC 4666
------------------------

3.1.4.  Message Length: 32-Bits (Unsigned Integer)

   The Message Length defines the length of the message in octets,

   including the Common Header.  The Message Length MUST include

   parameter padding octets, if there are any.

*   Note: A receiver SHOULD accept the message whether or not the final*

*   parameter padding is included in the message length.*
---------------------

Thanks,
Santosh

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 10 Oct 2013 14:05:30 +0200

On Oct 10, 2013, at 11:40 AM, santosh nayak <[email-masked]> wrote:

> Hi,
> 
> We have a situation where message is being rejected at M3UA layer due to buffer length is not equal to message length. 
> 
> What is the significance of Message Length and its importance with padding...
> 
> in the current issue M3UA peer is sending the data buffer of size 122 bytes to KSCTP. But message length parameter of M3UA common header contains a value of 124 and KSCTP is doing the padding at its level of 2 bytes which is observed from the wireshark traces. 
> 
> Now at DUT message droped with reason  (message length parameter is greater than actual M3UA data buffer size) 
> 
> 
At least the behaviour of the sender is not expected, since the sender
violates a MUST.

Best regards
Michael
>    Note: A receiver SHOULD accept the message whether or not the final
> 
>    parameter padding is included in the message length.
> 
> ---------------------
> 
> 
> 
> Thanks,
> Santosh
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

---

From: "David Laight" <[email-masked]>
Date: Thu, 10 Oct 2013 13:27:11 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Tuexen
> > to KSCTP. But message length parameter of M3UA common header contains a value
> > of 124 and KSCTP is doing the padding at its level of 2 bytes which is
> > observed from the wireshark traces.

Are you sure that pad isn't just from SCTP aligning it's chunks?

> At least the behaviour of the sender is not expected, since the sender

I'm not sure what the note in section 3.1.4 is trying to allow, but
I think the message you are describing is definitely illegal.

I believe that the overall length in the 'common' header should always
match that of the SCTP data chunk.
This allows M3UA data to be separated into messages when sent using (say)
TCP rather than SCTP.

I suspect the note allows an implementation to add the pad (following a
parameter) when it adds a new one, rather than when it adds a parameter
that isn't a multiple of 4 bytes.

In any case I'd change your sending end.

	David

---

From: "David Laight" <[email-masked]>
Date: Mon, 14 Oct 2013 10:20:28 +0100

I’ve NFI what you used to take that trace – Wireshark will only give me a hexdump.

Anyway the packet decodes as:

Pad, MAC addresses, ethertype

0000  00 00 00 01 00 06 00 1a  30 2b 4b c0 00 00 08 00

IP header

0010  45 02 00 ac 13 31 00 00  fe 84 3f ca 0a 3a 70 c8

0020  0a 3a e3 94

SCTP

      ports: 0f 53 0f 59

      tag:   49 33 5f c5

      cksum: 7f 3e b6 8d

0030  chunk type: 00

      flags:      03

      length:     00 8a

      TSN:        da 58 6c 93

      Stream id:  00 01

      Stream-seq: 00 08

      Payload-id: 00 00 00 03

M3UA data, length 0x7c

0040  01 00 01 01 00 00 00 7c

            02 00 00 08

                  00 00 00 02

0050        00 06 00 08

                  00 00 00 08

            02 10 00 62

                  00 00 0b ba

0060              00 00 13 8b 03 03 01 00  11 01 03 04 08 0c 45 04

0070              43 8b 13 07 04 43 ba 0b  07 39 00 00 00 00 00 00

0080              00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 04

0090              04 04 04 04 04 04 04 04  04 04 04 04 04 04 04 04

00a0              04 04 04 04 04 04 04 04  04 04 04 04 04 04 04 04

00b0              04 04 04 10 04 40 00 00  00 00

Inter-chunk pad: 00 00

The problem is that the length of the M3UA message (0x7c)  is larger than the payload

part of the SCTP message (0x8a – 0x10 = 0x7a).

The RFC might let you send that if the M3UA length were 0x7a, but I know that

all implementations will not be able to receive such messages – so it is best not

to send them.

                David

From: santosh nayak [mailto:[email-masked]] 
Sent: 14 October 2013 05:47
To: David Laight
Subject: Re: [Sigtran] M3UA: Message Length

Hi,

Thanks for the response...

I am attaching the pcap... packet number 85

Could you explain what MUST is violated???

Thanks,

Santosh

        David

---

From: "Saxena, Ravi (CMS)" <[email-masked]>
Date: Fri, 25 Oct 2013 12:34:15 +0000

Message should be discarded, if the length mentioned in the message doesn't match with the received buffer.
We have always seen this behavior.

Regards,
Ravi Saxena

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Laight
Sent: Monday, October 14, 2013 2:50 PM
To: santosh nayak
Cc: [email-masked]
Subject: Re: [Sigtran] M3UA: Message Length

I've NFI what you used to take that trace - Wireshark will only give me a hexdump.
Anyway the packet decodes as:

M3UA data, length 0x7c

Inter-chunk pad: 00 00

The problem is that the length of the M3UA message (0x7c)  is larger than the payload
part of the SCTP message (0x8a - 0x10 = 0x7a).
The RFC might let you send that if the M3UA length were 0x7a, but I know that
all implementations will not be able to receive such messages - so it is best not
to send them.

                David

Hi,

Thanks,
Santosh

On Thu, Oct 10, 2013 at 5:57 PM, David Laight <[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael Tuexen
> On Oct 10, 2013, at 11:40 AM, santosh nayak <[email-masked]<mailto:[email-masked]>> wrote:
>
> > Hi,
> >

        David

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

P Please consider the environment and don't print this e-mail unless you really need to