[asterisk-bugs] [Asterisk 0008855]: nat=no is not RFC 3261 compliant regarding sending responses

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=8855 
====================================================================== 
Reported By:                mikma
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   8855
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!): 51305 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             01-19-2007 14:32 CST
Last Modified:              07-22-2008 18:34 CDT
====================================================================== 
Summary:                    nat=no is not RFC 3261 compliant regarding sending
responses
Description: 
A note should be added to sip.conf.sample that using nat=no makes Asterisk
send responses to the address in the "sent-by" value instead of using the
source address of the request. This doesn't comply with RFC 3261 section
18.2.1 and 18.2.2.


   RFC 3261 section 18.2.1 Receiving Requests

   If the host portion of the "sent-by" parameter
   contains a domain name, or if it contains an IP address that differs
   from the packet source address, the server MUST add a "received"
   parameter to that Via header field value.  This parameter MUST
   contain the source address from which the packet was received.  This
   is to assist the server transport layer in sending the response,
   since it must be sent to the source IP address from which the request
   came.


   RFC 3261 section 18.2.2 Sending Responses.

         Otherwise (for unreliable unicast transports), if the top Via
         has a "received" parameter, the response MUST be sent to the
         address in the "received" parameter

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0012577 Asterisk MUST add VIA "received&qu...
has duplicate       0013008 [patch] chan_sip ignores rport and does...
====================================================================== 

---------------------------------------------------------------------- 
 kpfleming - 07-22-08 18:34  
---------------------------------------------------------------------- 
I fear there are much deeper issues here than have been described, and that
the patches offered on this issue and on
http://bugs.digium.com/view.php?id=13008 don't really address the
larger problems.

Let's start with a simple question: if RFC3261 says we always have to
respond to the IP/port we received the request from, regardless of what
appears in the Via header that the request contained, then (a) we don't
need to bother doing a DNS resolution on the hostname in the Via header
since we'll never respond there and (b) exactly what does 'nat=no' mean in
this context? (For the moment let's only worry about the SIP signaling and
not the media layers... let's sort out one thing at a time). If 'nat=no'
was supposed to turn off the RFC compliant behavior, I don't see why we
should offer that option at all. If 'nat=no' was supposed to do something
else, then I can't figure out what it is.

Based on my reading of the code today (for Asterisk 1.4):

1) we always add a 'received' tag to the Via header, regardless of what
NAT mode has been set (even nat=never)

2) if RFC3581 is enabled (nat=no or nat=yes), we add an 'rport' tag to our
outgoing Via headers, and we add an 'rport' tag to our copy of the incoming
Via header whether it was requested or not. The RFC3581 setting *never*
affects where we send signaling or media. If we see an incoming 'rport' tag
in the topmost Via header, we attempt to enable RFC3581 processing for that
dialog, but that behavior is broken, because it will later be overriden by
the user/peer NAT settings.

3) There is also 'ROUTE' NAT mode (nat=route or nat=yes), which is the
mode that is used to trigger responding to the source IP/port instead of
the Via header IP/port. I don't understand why this mode is useful, if that
behavior is required by the RFC.

4) There are some parts of request processing that use the global NAT
settings, when later parts use the settings found for the peer or user in
question. I haven't yet determined if the results of those early steps are
*always* overwritten (re-performed) by later steps, but if not, then we
could easily get non-obvious behavior. The trace in this bug is one
example; when check_via() is called (which outputs the "Sending to.." line,
the global NAT settings are in place. Later, when register_verify() has
found a peer to process the registration for, the peer's NAT settings are
in place, which is why the "Transmitting (no NAT)..." line has a different
destination address (and says "no NAT"). This is at a minimum very
confusing, because if the admin has configured everything with
'nat=rfc3581' then turns on debugging, all the debug messages will say
"Transmitting (no NAT)...".

I can't remember ever seeing a system configured with anything but
'nat=yes', and I suspect that is because nobody really understands these
modes and changing it from 'yes' breaks connectivity under unexpected
circumstances, even when a NAT may not be involved.

So let's try to answer three questions first:

1) Is there ever a case where we will send our response for a SIP request
to an address/port *OTHER* than the one we received it from?

2) Is RFC3581 *PURELY* informational? If so, it should be broken out into
a separate configuration option or made clearer that that is the case.
Based on comments in the code, the only reason it was added was to help
some buggy phone firmware in the distant past that broke if it received an
'rport' tag in our Via header.

3) Is there any real need to *DISABLE* NAT mode, and if so, what exactly
are we disabling? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-22-08 18:34  kpfleming      Note Added: 0090586                          
======================================================================