Subject: RE: [Sipping] new draft on session policies in SIP

From: David Oliver <[email-masked]>
Date: Wed, 19 Jun 2002 13:05:31 -0500

I agree that clients must be NAT-aware.

SDP endpoints generally only have numeric IP addresses (a protocol design
practice which has been recommended against for many years, but which is
necessitated by the prevalence of NAT), so either a transparent ALG is
needed to traverse their NAT, or they need to be aware of the NAT.

Transparent ALGs have the severe limitation that they cannot work with
encrypted data, and many users require their conversations to be private.

Arbitrary NAT awareness by clients is problematic, as clients are likely to
be small embedded hosts (e.g. net-phones), which cannot be easily configured
to work with different NATs, and protocols such as STUN do not work in all
cases. This is especially important for essentially untrusted guest users,
such as in hotels or airport hospitality suites.

The best solution is to make the client aware of the existence of NATs,
while limiting the impact on the client to a simple address replacement
protocol. The appropriate place for this is the proxy server nearest the
NAT: configuration and administration are normally the same as the NAT's, it
can be trusted by the NAT (especially important for guest users), and has
minimal administrative impact as Midcom protocols appear and stabilize to
replace ad hoc and proprietary solutions.

This can be done in either of (at least) two ways:

1. The sending client sends its outgoing address/port number to the proxy
(in a new header), with the proxy adding the NATed address for the receiving
client substituting the new address into its received (possibly e-e
encrypted) SDP.

2. The sending client sends its outgoing address/port number to the proxy
(in a new header), with the proxy returning the NATed address for the
sending client to substitute into its outgoing SDP.

The first option is more consistent with most SIP processing, as it is
linear (messages keep moving towards the recipient), but it exposes
addresses to trivial snoopers and requires clients *not* behind a NAT to
implement the protocol, including eventually IPv6 clients, prolonging the
protocol's life beyond necessity.

The second option makes snooping slightly more difficult (snoopers must
watch packet traffic) and only requires the NAT encumbered client to be
NAT-aware, at the expense of "bouncing" initial packets (much like
authentication).

Either of these mechanisms would be sufficient to provide end-to-end
security for communications, together with a manageable enterprise security
model. I believe that an approach such as these is necessary for successful
full deployment of SIP-based VoIP.

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: [email-masked] <mailto:[email-masked]>
Tel:   210.402.9669
Fax:   210.402.6996 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 1:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] new draft on session policies in SIP

Yes, yes, more responses to ancient mail - my apologies...

<...>

Having been working on these nasty NAT issues for a long time, I have 
come to the conclusion that the only really viable solutions all involve 
the endpoints becoming aware of the existence of NAT, so that they can 
properly handle it. I believe this is actually an instantiation of the 
end-to-end principle. Given that nats exist, the best place to deal with 
them is at the ends.

An example is midcom itself. Ultimately, midcom found that when proxies 
try to control the firewalls, you end up in all kinds of hard topology 
problems. How does the proxy know which firewalls are traversed by 
media? There really is no solution to this. Ultimately, the right answer 
(IMHO) is that the controls on the firewall/NAT are executed by the 
endpoints by passing messages along the media path, since these control 
messages will traverse the firewalls/NATs that need to be controlled, by 
nature of the underlying IP routing. There is a bof on this subject at 
the next IETF (tist bof).

Another example is STUN. Look how easy the whole problem becomes when 
the UA itself can actually put the right IP address inside the SDP in 
the first place.

<...>

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 19 Jun 2002 16:59:33 -0500

>The appropriate place for this is the proxy server nearest the
>NAT: configuration and administration are normally the same as the
NAT's,

DSL and cable users may be behind a NAT in the C.O. where they can have
absolutely no control. What alternative to STUN, if any do you
recommend?

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David Oliver
> Sent: Wednesday, June 19, 2002 1:06 PM
> To: 'Jonathan Rosenberg'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] new draft on session policies in SIP
> 
> 
> SDP endpoints generally only have numeric IP addresses (a 
> protocol design practice which has been recommended against 
> for many years, but which is necessitated by the prevalence 
> of NAT), so either a transparent ALG is needed to traverse 
> their NAT, or they need to be aware of the NAT.
> 
> Transparent ALGs have the severe limitation that they cannot 
> work with encrypted data, and many users require their 
> conversations to be private.
> 
> Arbitrary NAT awareness by clients is problematic, as clients 
> are likely to be small embedded hosts (e.g. net-phones), 
> which cannot be easily configured to work with different 
> NATs, and protocols such as STUN do not work in all cases. 
> This is especially important for essentially untrusted guest 
> users, such as in hotels or airport hospitality suites.
> 
> The best solution is to make the client aware of the 
> existence of NATs, while limiting the impact on the client to 
> a simple address replacement protocol. The appropriate place 
> for this is the proxy server nearest the
> NAT: configuration and administration are normally the same 
> as the NAT's, it can be trusted by the NAT (especially 
> important for guest users), and has minimal administrative 
> impact as Midcom protocols appear and stabilize to replace ad 
> hoc and proprietary solutions.
> 
> 1. The sending client sends its outgoing address/port number 
> to the proxy (in a new header), with the proxy adding the 
> NATed address for the receiving client substituting the new 
> address into its received (possibly e-e
> encrypted) SDP.
> 
> 2. The sending client sends its outgoing address/port number 
> to the proxy (in a new header), with the proxy returning the 
> NATed address for the sending client to substitute into its 
> outgoing SDP.
> 
> The first option is more consistent with most SIP processing, 
> as it is linear (messages keep moving towards the recipient), 
> but it exposes addresses to trivial snoopers and requires 
> clients *not* behind a NAT to implement the protocol, 
> including eventually IPv6 clients, prolonging the protocol's 
> life beyond necessity.
> 
> The second option makes snooping slightly more difficult 
> (snoopers must watch packet traffic) and only requires the 
> NAT encumbered client to be NAT-aware, at the expense of 
> "bouncing" initial packets (much like authentication).
> 
> Either of these mechanisms would be sufficient to provide 
> end-to-end security for communications, together with a 
> manageable enterprise security model. I believe that an 
> approach such as these is necessary for successful full 
> deployment of SIP-based VoIP.
> 
> Regards,
> 
> David C. Oliver
> Principal Engineer
> SecureLogix Corp
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>