Subject: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)]

From: Dean Willis <[email-masked]>
Date: Thu, 06 Nov 2003 15:11:22 -0600

On Thu, 2003-11-06 at 08:34, Scott Lawrence wrote:
>   This draft presents an excellent explanation of how and why the
>   use of UDP in SIP can (and therefor by Murphys Law, will :-) cause
>   network operation problems.  In doing so, it makes a good case for
>   SIP having been designed differently, possibly not using UDP at
>   all, but acknowleges that it is too late for that.  It goes on to
>   propose mechanisms by which this oversight can now be corrected by
>   defining a congestion-safe mode of operation and adding a protocol
>   feature to require operation in that mode.

>  Unfortunately, I don't think that creating such a mechanism is
>   useful, because there is little or no incentive for any
>  significant number of systems to use it.  The cat is not only out
>  of the bag in that SIP was designed to support UDP, but later
>  standards (SIP use of NAPTR and DNSSRV in RFC 3263) have provided
>  for explicit administrative control mechanisms by which users
>  (administrators) can (perhaps unwisely) prefer the use of UDP.

. . . 

Excellent summary and commentary.

Here's the deal. Before long, EVERY e2e-secured SIP request or response
is going to be bigger than one packet. The security people aren't going
to give up on e2e.

This gives us two viable alternatives, as I see them:

1) Deprecate UDP usage in SIP.

2) Deprecate SIP.

Since #2 would leave me unemployed :-(, the question I'm interested is
how to do #1.

Three possibilities suggest themselves, and I'd like to get a sense of
consensus from the group on the direction (or other suggestions, if
there are any).

1) Leave the UDP stuff in place, but convince people not to use it by
doing a "UDP Considered Harmful for SIP" BCP,  (which Scott seems to be
suggesting). 

2) Leave the UDP stuff in place, but give people tools to keep it from
being used (which this draft suggests).

3) Rev the spec to 3.0 and rip UDP out by the toenails.

Any other ideas? What is the right thing to do here?

--
Dean

_______________________________________________
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: Scott Lawrence <[email-masked]>
Date: Thu, 06 Nov 2003 16:56:30 -0500

Dean Willis <[email-masked]> writes:

> The security people aren't going to give up on e2e.

Which is not the same thing as saying that users will use it... but
that's a different discussion.

> Any other ideas? What is the right thing to do here?

#1 is a good start, but in the absense of an alternative that is
perceived as being equally good, it won't matter.

accordingly, I'd modify #2 slightly to: 

Leave the UDP stuff in place, _and_ provide good alternatives that are
better.

The BCP will be a valuable part of getting the word out that something
else is better by educating administrators & users about the problem
with SIP/UDP.  I do think that we need to refine some other things
further to provide the alternative.

One suggestion I'd make toward that end is that everyone look closely
at draft-mahy-sip-connect-reuse-00 - I think that it goes a long way
to solving some of the barriers to wider adoption of SIP over TCP.
I've a comment or two on that that I'll send separately...

-- 
Scott Lawrence        
  Pingtel Corp.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Nov 2003 19:05:15 -0500

> 3) Rev the spec to 3.0 and rip UDP out by the toenails.

For the historical record, that was roughly SIP 1.0 :-)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Nov 2003 12:50:52 -0600

> 1) Deprecate UDP usage in SIP.

Deprecate SIP!! What'choo talkin' about, Willis?  (Sorry, always
wanted to say that :-) )

> Three possibilities suggest themselves
> 

If we rev the spec to 3.0, can we guarantee that the only
change in SIP/3.0 will be UDP removal?  What if someone wants
to take this opportunity to put other behavior in the spec?  Do
we run the risk of ending up with a protocol that does not quite
resemble SIP/2.0.  I do not know what the criteria of IESG is
to rev up a protocol version.  The only instance of this
happening that I am actively aware of is the rev from HTTP/1.0
to HTTP/1.1.  But in that particular instance, backward
compatibility was preserved, I believe.

I think it may be too late to deprecating UDP completely; so
much deployed gear uses it.  I have also witnessed many
 >>new<< SIP implementations start out with only supporting UDP
with the (mistaken) belief that it will be easier to code.

> Any other ideas? What is the right thing to do here?

I like Aki's idea of selectively deprecating UDP-related
backwards compatibility issues in rfc3261 which haunt us
at this point, but still maintain UDP as a transport (albeit
not endorse it as the preferred transport, which it was in
rfc2543).

Cheers,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216