Subject: [Sip] Changing Via In NAT

From: Anil Bollineni <[email-masked]>
Date: Fri, 13 Feb 2004 11:07:47 -0800

Dear All,

In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT traversal.
The received and rport parameter are used to send back the responses
correctly. However if we don't use these extensions, and change the via ip
address and port with that of firewall/port then the SIP responses will come
directly to firewall, in that case the firewall permits the responses. UA1
inside the network sends requests to firewall/NAT.

UA1 

INVITE sip:[email-masked] SIP/2.0 ----------------> Firewall/NAT
----------------------------------------------->UA2

Via: SIP/2.0/UDP 10.1.1.1:4540                          INVITE
sip:[email-masked] SIP/2.0                             

Via: SIP/2.0/UDP firewall_ip:5060

(Maintain mapping) 

the UA2 will send the responses to firewall/NAT and firewall/NAT will write
back the addresses in Via to original IP/port. I understand from the draft,
if there are no SIP ALG functionality in firewall, then the extensions are
used to make SIP traverse through NAT. However if we implement SIP ALG in
firewall then we can make SIP traverse through NAT. Can anybody tell that
this way is per SIP spec.

Thank you,

Anil

This email contains material that is confidential. The content of this email
is for the sole use of the intended recipient(s). Any review or distribution
by persons other than the intended recipient(s) without the express
permission of NetScreen Technologies, Inc. is strictly prohibited. If you
are not the intended recipient, please contact the sender and delete/destroy
all copies of this email and any related attachments. NetScreen does not
guarantee the accuracy or completeness of third party materials or
information.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 18 Feb 2004 04:46:23 -0800

On Feb 13, 2004, at 11:07 AM, Anil Bollineni wrote:

> Dear All,
>
> In draft-ietf-sip-nat-01.txt, there are SIP extensions for NAT  
> traversal. The received and rport parameter are used to send back the  
> responses correctly.

This is an extremely old reference.  The name was changed to  
draft-ietf-sip-symmetric-response, and is now published as RFC 3581.

> However if we don't use these extensions, and change the via ip  
> address and port with that of firewall/port then the SIP responses  
> will come directly to firewall, in that case the firewall permits the  
> responses. UA1 inside the network sends requests to firewall/NAT.
>
>
> UA1
>
>  INVITE sip:[email-masked] SIP/2.0 --------------à Firewall/NAT  
>               ---------------------------------------------àUA2
>
> the UA2 will send the responses to firewall/NAT and firewall/NAT will  
> write back the addresses in Via to original IP/port. I understand from  
> the draft, if there are no SIP ALG functionality in firewall, then the  
> extensions are used to make SIP traverse through NAT. However if we  
> implement SIP ALG in firewall then we can make SIP traverse through  
> NAT. Can anybody tell that this way is per SIP spec.

The experience of the working group has shown that implementing a SIP  
ALG in a firewall is "a bad thing".  I have personal experience with  
the failings of SIP ALGs at my own company, not the least of which is  
that they don't work at all when SIP is integrity-protected using TLS.

Many UAs now support RFC 3581 and can use the STUN protocol to get  
valid public addresses and ports to advertise in SDP for their RTP  
traffic. This has been relatively painless compared to working with the  
shortcomings of ALGs.

thanks,
-rohan

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 19 Feb 2004 17:11:38 +0100

At 01:46 PM 2/18/2004, Rohan Mahy wrote:
>The experience of the working group has shown that implementing a SIP ALG in a firewall is "a bad thing".  I have personal experience with the failings of SIP ALGs at my own company, not the least of which is that they don't work at all when SIP is integrity-protected using TLS. 
>
>Many UAs now support RFC 3581 and can use the STUN protocol to get valid public addresses and ports to advertise in SDP for their RTP traffic. This has been relatively painless compared to working with the shortcomings of ALGs. 

Absolutely -- rport is very essential part of the story as it adds lot of
robustness to traversal of SIP transactions over NATs. Sending replies
back symmetricaly simply works. Not using rport leads to all kind of
instabilities such as missed SIP replies when STUN address in Via without
rport becomes invalid for whatever reason.

Besides that, adding rport to UAC is banal.

-jiri  

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip