Re: [Sigtran] M3UA: Message Length

["Saxena, Ravi (CMS)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of David Laight
Sent: Monday, October 14, 2013 2:50 PM
To: santosh nayak
Cc: [e-mail]
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:

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:[e-mail]]
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


On Thu, Oct 10, 2013 at 5:57 PM, David Laight <[e-mail]<mailto:[e-mail]>> wrote:
> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Michael Tuexen
> On Oct 10, 2013, at 11:40 AM, santosh nayak <[e-mail]<mailto:[e-mail]>> 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.
Are you sure that pad isn't just from SCTP aligning it's chunks?

> > 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...
>
> At least the behaviour of the sender is not expected, since the sender
> violates a MUST.
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



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