Subject: RE: [Sip] Changing Via In NAT

From: "Eric Burger" <[email-masked]>
Date: Wed, 18 Feb 2004 10:44:09 -0500

An ALG is an ALG: a B2BUA.
 
Do whatever you want.  It is not subject to standardization.  It is not a good idea.  Do so at your own peril.

-----Original Message-----
From: Anil Bollineni [mailto:[email-masked]]
Sent: Friday, February 13, 2004 2:08 PM
To: [email-masked]'
Subject: [Sip] 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: Rohan Mahy <[email-masked]>
Date: Wed, 18 Feb 2004 13:53:16 -0800

There is one critical difference between an ALG and a SIP proxy or  
B2BUA.

ALGs don't insert Via headers, Contact, Record-Route, Route, etc..   
They just rewrite stuff going by on the wire, assuming that packets  
will happen to go through this particular firewall of NAT on their way  
to the "outside".

SIP intermediaries insert some sort of SIP identifier so that requests  
and responses get routed to them.

In this way, ALGs are much, much worse.

thanks,
-rohan

On Feb 18, 2004, at 7:44 AM, Eric Burger wrote:

> Do whatever you want.  It is not subject to standardization.  It is  
> not a good idea.  Do so at your own peril.
> 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
>
> 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.
>
>