Re: Fwd: RFC3261 rules

In my understanding, RFC-defined behaviour should be used by default.
Without a special config prepared.

Please check issue with double "To" headers.
https://kamailio.org/mailman3/hyperkitty/list/[email protected]/thread/MKFXVHHA5QLIZGENNK3CI2MU45SSPPAT/

Second "To" header also can be stripped at the Kamailio config. Here is
kamailio config example
https://github.com/2600hz/kazoo-configs-kamailio/blob/master/kamailio/sanity.cfg#L23-L27
Security advisory
https://nvd.nist.gov/vuln/detail/CVE-2018-14767

Why this need to "hardcoded" in the C code and we do not force Kamailio
admin to use config workarround?
Why "To" header RFC-defined behaviour need to hardcored in the C code,
but for message body is not?

Sergey


On Sun, 2025-06-22 at 09:16 +0200, Daniel-Constantin Mierla wrote:
>  
> Hello,
>  
> like also commented in the issue references previously in this
> discussion, Kamailio is a framework for building SIP systems, it is
> the config script that can make it to behave as one needs, being that
> stricter or looser from the specs point of view. Kamailio tries not
> to (hard-)enforce rules in the C code, but provide the
> tools/components for the config writers to implement what suit best
> their needs.
>  
> If one wants to shrink the body, for what ever purposes, including
> the mismatch of the body, it can do it, e.g.,:
>  
> if(is_present_hf("Content-Length") && $cl < $bs) {
>     set_body("$(rb{s.substr,0,$cl)", "$ct");
>     msg_apply_changes();
> }
>  
> Cheers,
> Daniel
>  
> On 21.06.25 20:28, James Browne via sr-users wrote:
>  
> > 
> >  
> > It's not an issue.  
> > https://kamailio.org/docs/modules/5.8.x/modules/sanity.html#sanity.p.default_checks
> > 
> > "By default all implemented checks are included in the execution of
> > the sanity_check function."
> > 
> > 
> > 
> > 
> > By running it with no argument, you're asking kamailio to do
> > exactly what it then does: reject the request.
> > 
> > My previous reply also suggested this: if value 128 is included
> > (which is included by default), then the Content-Length will be
> > checked.
> > 
> > I'll put a note in the issue, too.
> > 
> > 
> > 
> > 
> > James
> > 
> > 
> > 
> > 
> > On Sat 21 Jun 2025, 09:42 Sergei Safarov via sr-users,
> > <[email protected]> wrote:
> > 
> > > 
> > > 
> > > Thanks for good reference to RFC
> > > 
> > > 
> > > 
> > > 
> > > I have described issue at
> > > 
> > > https://github.com/kamailio/kamailio/issues/4290
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Fri, 2025-06-13 at 09:51 +0200, Aymeric Moizard via sr-users
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > 
> > > > Hi Sergey,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > The extra chars are acceptable for UDP, as James reported.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Several things:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 1/ the port reported in logs 60083 is not the same as your
> > > > OPTIONS (just worth to say: is your error for another message?
> > > > I guess not...)
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 2/ Your OPTIONS contains a Tag in From, but it doesn't contain
> > > > a "branch" in the Via header: so your OPTIONS looks to be a mix
> > > > of 
> > > > 
> > > > old rfc2543 and not compliant to rfc3261.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > The Via header should contain a branch and it should start with
> > > > the magic cookie: "z9hG4bK", such as:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Via: SIP/2.0/UDP 192.168.1.1:51253;branch=z9hG4bKyjoyW1QOas
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Looking at sanity code, it doesn't look to be the reason for
> > > > failure...
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Aymeric
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Antisip - http://www.antisip.com
> > > > 
> > > > 
> > > > 
> > > > Le jeu. 12 juin 2025, 22:38, James Browne via sr-users
> > > > <[email protected]> a écrit :
> > > > 
> > > > > 
> > > > > 
> > > > > I read your pcap file. I thought it was invalid, but it looks
> > > > > valid to me, even though it's strange and I've never seen
> > > > > this nonsense in normal SIP traffic.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > RFC3261 Section 18.3
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >    In the case of message-oriented transports (such as UDP),
> > > > > if the
> > > > >    message has a Content-Length header field, the message
> > > > > body is
> > > > >    assumed to contain that many bytes.  If there are
> > > > > additional bytes in
> > > > >    the transport packet beyond the end of the body, they MUST
> > > > > be
> > > > >    discarded.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Therefore it looks to me that any server/client should simply
> > > > > ignore anything after the header when the Content-Length is
> > > > > zero.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > I don't see that error "dropping insane message" in kamailio
> > > > > source code, so I suppose your config file generates that.
> > > > > 
> > > > > The sanity module, which Antonio mentions, would drop this
> > > > > message, so I guess that's what's happening in your config.
> > > > > 
> > > > > - content length - (128) - checks if the size of the body
> > > > > matches with the value from the Content-Length header.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > James
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On Sat, 31 May 2025 at 07:27, Sergey Safarov via sr-users
> > > > > <[email protected]> wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Could you look at the attached PCAP with OPTIONS message.
> > > > > > When OPTIONS message is received, then Kamailio generates
> > > > > > error logs like
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > dropping insane message from 10.140.6.38:60083
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > After checking the PCAP, I see extra %x00 characters after
> > > > > > the OPTIONS message in the same UDP frame.
> > > > > > 
> > > > > > Example
> > > > > > 
> > > > > > image.png
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > I have checked RFC3261 and do not see a definition of "x00"
> > > > > > chars.
> > > > > > 
> > > > > > Also in the same RFC, present a reference to the RFC2234
> > > > > > [1] where is described "space chars", "white space".
> > > > > > According to RFC2223, char %x00 cannot be treated as
> > > > > > "space" and should be treated as control (CTL) char.
> > > > > > 
> > > > > > Also, RFC3261 does not use "CTL" chars.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Using these two RFC, I can conclude, OPTIONS in the
> > > > > > attached PCAP breaks RFC requirements, and we can
> > > > > > request partner fix this issue on their equipment.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Is anything else in the RFC can be used to justify that the
> > > > > > given examples of OPTIONS messages violate RFCs?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Sergey
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > __________________________________________________________
> > > > > > Kamailio - Users Mailing List - Non Commercial Discussions
> > > > > > -- [email protected]
> > > > > > To unsubscribe send an email to
> > > > > > [email protected]
> > > > > > Important: keep the mailing list in the recipients, do not
> > > > > > reply only to the sender!
> > > > > > 
> > > > > 
> > > > > 
> > > > > __________________________________________________________
> > > > > Kamailio - Users Mailing List - Non Commercial Discussions --
> > > > > [email protected]
> > > > > To unsubscribe send an email to
> > > > > [email protected]
> > > > > Important: keep the mailing list in the recipients, do not
> > > > > reply only to the sender!
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > __________________________________________________________
> > > > 
> > > > Kamailio - Users Mailing List - Non Commercial Discussions --
> > > > [email protected]
> > > > 
> > > > To unsubscribe send an email to
> > > > [email protected]
> > > > 
> > > > Important: keep the mailing list in the recipients, do not
> > > > reply only to the sender!
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > __________________________________________________________
> > > Kamailio - Users Mailing List - Non Commercial Discussions --
> > > [email protected]
> > > To unsubscribe send an email to [email protected]
> > > Important: keep the mailing list in the recipients, do not reply
> > > only to the sender!
> > > 
> > 
> >  
> > 
> > 
> > __________________________________________________________
> > Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
> > To unsubscribe send an email to [email protected]
> > Important: keep the mailing list in the recipients, do not reply only to the sender!
> >  
>  


[1] RFC2234 https://datatracker.ietf.org/doc/html/rfc2234

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!