Subject: Re: [Sip] refreshing NAT binding for SIP with UDP registrations

From: Chris Martin <[email-masked]>
Date: Fri, 28 Jun 2002 20:06:42 -0500

Jonathan Rosenberg wrote:
> 
> The holes that this "CRLF approach" has are similar to some of the
> generic problems of STUN, which I would prefer be kept isolated there.
> THe main one really is that the frequency of the refreshes is dependent
> on the binding lifetime; that is not generally known, either to the UA,
> or the registrar. TCP works better there. Because TCP connections have
> an explicit teardown, they are held in NATs for a long time without
> keepalives.
> 
> There is also the needless network traffic from these 1 byte UDP packets
> flying around (with 8 bytes UDP, 20 bytes IPv4 headers), a huge waste.

I agree on both points...and the majority of corporate network admins
would also agree with this, not to mention ISP's if they continue to see
constant keepalives....as opposed to what appears to be valid traffic,
they may be inclined to cancel service. 

SIP clients could be considered a violation of ISP policy (in the sense
that the majority of existing ISP's forbid web servers on home accounts,
for instance, at this point the client represents an internal service
listening for connections), excess traffic would cause more notice to
these services. 

I only mention this since many of the NAT scenarios described in past
drafts offering solutions for SIP, that I have read, seem to be more
suited to SOHO NAT solutions rather than intra/extranet entities, and
many of the solutions would not be considered as valid solutions by many
corporate administrators/policies due to security issues that would
arise from the solutions operation. 

To clarify the latter comment SIP traversal solutions for the enterprise
that involves keep alives or topology discovery on enterprise firewalls
may be considered a violation of enterprise security policy, not to
mention the excess traffic, which is typically hunted down to be
silenced on many of these types of networks, and lastly the potential
risk of providing additional vulnerabilities to the internal network
that are yet unknown. Many infrastructures do not want internal users
having knowlege of the topology. Placing the ability to do so on a
client to determine this information may be frowned upon as well.

Anyway the firewall vendors have begun to provide SIP solutions to
address this now, so it is becoming a moot point. MIDCOM may provide a
way to offer additional support for many items other than firewalls,
such as load balancing devices etc, so this has much merit, but a
traversal solution, IMHO, is not necessary or acceptable, except in the
SOHO realm, if that. 

But if we must work on and develop this capability then the direction
that you stated above is the way I would go as well because there are
other implications and benefits that we may possibly get from doing this
in addition to reducing the excess traffic.

Chris Martin

> 
> -Jonathan R.
> 
> Sean Olson wrote:
> > This seems to have too many holes.
> > However, it *might* be useful to define a
> > lightweight SIP keep-alive mechanism.
> >
> > /sean
> >
> > --- Cullen Jennings <[email-masked]> wrote:
> >
> >>One point about UDP registrations, I don't know if
> >>you really need to send a
> >>true registration, you can just send any message
> >>that creates minimal load
> >>on the proxy. For example the UA could send a single
> >>CRLF to the proxy. The
> >>proxy could have some code to silently ignore any
> >>message that is clearly
> >>too short to be a valid SIP message. Obviously this
> >>won't work in the cases
> >>where the UA sends to a proxy inside the NAT then
> >>the proxy sends to a
> >>another proxy outside the NAT. It also has the
> >>problems with no response so
> >>you don't know if the message made it to the NAT or
> >>not.
> >>
> >>Do folks see this as an ideal worth pursing or a
> >>really bad idea that we
> >>should suggest people don't do?
> >>
> >>Cullen
> >>
> >>
> >>_______________________________________________
> >>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
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> >
> 
> --
> 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
> 
> _______________________________________________
> 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

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Jul 2002 00:45:16 -0400

> client to determine this information may be frowned upon as well.

I can only assume you are talking about STUN. STUN doesn't discover 
topology, it just determines whether or not there exist one or more NATs 
between the client and the public Internet.

> traversal solution, IMHO, is not necessary or acceptable, except in the

I disagree.

You are assuming that the only solution an enterprise would find viable 
is an ALG or a midcom-controllable firewall. I think it is legitimate 
for an enterprise to decide to deploy SIP using one of several other 
approaches, all of which are documented in 
draft-ietf-sipping-nat-scenarios. One of these, for example, involves 
the deployment of a SIP server in the DMZ, along with a configuration 
change in the firewall. I claim that it should be possible to configure 
the firewall to support SIP without requiring that configuration to be 
excessively permissive; this basically means that SIP should be workable 
with client initiated "connections", much like many other application 
protocols, and that is the aim of this draft.

-Jonathan R.

---

From: Chris Martin <[email-masked]>
Date: Tue, 02 Jul 2002 22:03:09 -0500

Chris Martin wrote:
> I am not focusing on one implementation over another...many of them
> provide this level of vulnerability. A client that uses mechanisms to
> ascertain information of topology is an additional risk that many
> enterprise, or for that matter any responsible network administrator,
> would permit to be implemented.
       ^ Would not permit
> > change in the firewall.
> Why deploy a SIP proxy in the DMZ if you can deploy or upgrade a
> firewall that provides SIP functionality? The solutions being devloped
> today range from ALG's to B2BUA type firewall solutions. In many cases
> the B2BUA's can also act as standalone proxy/registrars at a minimum
> cost, and they are capable of interoperability with external SIP
> proxies.
> 
> > I claim that it should be possible to configure
> > excessively permissive
> Thats exactly what I said about what the firewall vendors are doing...it
> is not complicated and it is not overly permissive, and it does not
> require additional physical proxy in the DMZ to provide the desired
> functionality.
> 
> Hence, the SIP enabled firewalls that are being developed and deployed
> currently by well known and emerging vendors. These solutions provide
> far better solutions that fit the enterprise model than those that
> provide a discovery or traversal mechanism or the requirement of
> additional boxes on the enterprise..
> 
> >; this basically means that SIP should be workable
> Nothing like adding a denial of service tool to all of ones internal
> clients.
> 
> >
> > -Jonathan R.
> > --

---

From: Chris Martin <[email-masked]>
Date: Tue, 02 Jul 2002 21:41:56 -0500