Subject: [Sip] FW: Changing Via In NAT

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

Hi Guys,

  Can anybody have some comments about the discussion below.

Thanks in Advance,

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.

-----Original Message-----
From: Anil Bollineni 
Sent: Friday, February 13, 2004 11:08 AM
To: [email-masked]'
Subject: Changing Via In NAT

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: Anil Bollineni <[email-masked]>
Date: Wed, 18 Feb 2004 14:29:18 -0800

Hi Rohan,

            Thanks for pointing me to right RFC. I am thinking that how many
UA's correctly support this STUN protocol. I am thinking that we need to add
SIP ALG in NAT that if we want to support UA's that don't support any SIP
NAT extensions and STUN protocol. I thought that this supporting all SIP
aware functionality in ALG is difficult as changes made to SIP protocol need
to accommodate in SIP ALG. 

Thanks,

Anil

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2004 4:46 AM
To: Anil Bollineni
Cc: [email-masked]'
Subject: Re: [Sip] Changing Via In NAT

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

Dear All, 

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 

 
(Maintain mapping) 

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