Hi Everyone,

Recently while analyzing multiple issues for IPv6 I determined that all
were being caused by single core issue. The SIP packets were being dropped
by the Linux Kernel SIP connection tracker.

I looked at the code of the nf_conntrack_sip.c and can clearly see that the
SDP parser here is not compliant with the recommendations of handling
section 4.1 of RFC-6157


--------------------------------------------------------------------------------------------------------

4.1 <https://tools.ietf.org/html/rfc6157#section-4.1>.  Updates to RFC
3264 <https://tools.ietf.org/html/rfc3264>

   This section provides a normative update to RFC 3264
<https://tools.ietf.org/html/rfc3264> [4
<https://tools.ietf.org/html/rfc6157#ref-4>] in the
   following manner:

   1.  In some cases, especially those dealing with third party call
       control (see Section 4.2 of [12
<https://tools.ietf.org/html/rfc6157#ref-12>]), there arises a need to
specify
       the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
       the SDP offer.  For this, IPv6 implementations MUST use a domain
       name within the .invalid DNS top-level domain instead of using
       the IPv6 unspecified address (i.e., ::).

-------------------------------------------------------------------------------------------------------------

I have below question to the broader community:

1 ) Has any one ever encountered this issue of dropping V6 packets which
contains a SDP for the above ( c = IN IP6 anonymous.invalid )

2) In general dropping a SIP packet if  SDP parsing fails seems to not
really comply with REQUEST-RESPONSE model of SIP RFC. So should this
net-filter connection tracker for SIP be really included if its behavior
for error seems to DROP_PACKET and not send a 400 Bad response

3) Is it recommended to include the SIP connection tracker in Linux Kernel
specially when it seems to have caused multiple V6 feature failure due to
above RFC non-compliance..I am not sure how compliant it is with parsing
the SDP/SIP messages as defined in respective RFCs..

Best Regards,
-- 
IK
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to