Subject: General Comments on the SIP Protocol

From: Yaron Goland <[email-masked]>
Date: Tue, 28 Apr 1998 01:15:09 -0700

4 General Comments on the SIP Protocol

4.1 1.4.4. SIP Invitation

Given that SIP allows for different kinds of session descriptions to be used
it seems inappropriate to describe details of the session description's
behaviors. For example, the third paragraph talks about session
description's with times set to the future. It would seem to me to be the
job of the particular session description to explain what it means to
receive a description set to the future. SIP should be silent on the
subject.

For example, I can imagine a session protocol whose policy is that if you
receive an invitation in the future you should try to connection immediately
and ask for the current clock on the inviting server to determine if there
are any clock skew problems. The point isn't that the previous is a real
world scenario only that in general SIP should remain silent on the behavior
of session descriptions. SIP's job is ONLY to move session descriptions
around. It should leave the functionality of those descriptions to others.

4.2 4.2.2 ACK

An ACK message is not necessary when using TCP since TCP itself will let the
callee know that the caller has received the appropriate response. Obviously
if a proxy is using TCP on one end and UDP out the other as soon as the
proxy receives TCP confirmation of receipt it needs to send an ACK on the
UDP connection.

4.3 4.2.4 BYE

My understanding of this section is that once someone sends an INVITE, thus
causing a ringing, the ringing doesn't stop until a BYE or ACK is received?
That sounds like an attack not a feature. Also, I would put in a note that
even when using TCP/IP it is probably better to send a BYE method rather
than just closing the connection. Just closing connections causes all sorts
of havoc for servers. If the client sends a BYE with a connection: close
header then the server knows that the connection is going to be closed and
can clean things up nicely. In HTTP we have found all sorts of problems with
TCP/IP stacks when folks just close a connection without letting the server
know what is going on. Please don't repeat our mistakes.

4.4 4.2.6 Register

What is the point of the broadcasted public key? Since you have nary a clue
whose public key has been broadcasted this doesn't seem to be a good idea
from a security point of view.

4.5 6.11 Call-ID

Why is the requirement for global uniqueness only held for the duration of
the request? Given that these requests can be forked who can even know what
the duration of a request is? Even if the caller sends out a BYE you still
can't be sure how far the request has propagated so if another request with
the same call-id is issued the two could collide. I think you have to
require that the call-id be unique for all requests for all time. There
already exists a draft to give you the functionality you need at
http://www.ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt. It has
just finished its IESG last call and will be voted on by the IESG to be
moved to standards status any day now.

4.6 6.14 CSeq

Sequence numbers are a general facility that allows one to match requests
and responses. However the current specification for sequence numbers
suffers from the "restart" problem. If a server crashes and restarts it
won't remember the last sequence number it sent out. A simple way to solve
this problem is to require that servers generate a GUID and then append
numbers to it in order to represent a sequence. If the server ever crashes a
new GUID will be generated and thus collisions avoided.

4.7 6.16 Encryption

You could encrypt the method. You could invent a new method called ENCRYPT.
In the encrypted body of the method is a header called "method" whose value
equals the method that was supposed to be used. Also, if you switch to
HTTP/1.1, thus using an HTTP request-URI, you can use the "*" URI to mean
server. In that case you could add another header "request-URI" which
encodes the original request-URI. The same logic applies to the From header.
Even the To header could be encrypted if you are using the public key of the
server. Regardless, A proxy will just forward the message to the indicated
server and return the response.

BTW, while I can guess how one would encrypt a response there is no text in
SIP on how this is actually done.

4.8 6.38 Via

4.8.1 Sent-By

The host production in sent-by isn't IPv6 compliant.

4.8.2 Removing the Via Header on Response Paths

HTTP does not remove Via headers as a message goes down the response path
because the information in the Via header is critically important for
determining path capabilities. For example, if the client is an HTTP/1.1
client but the message eventually goes through an HTTP/1.0 proxy this limits
certain things the client can successfully do. Getting back the Via header
stream on the response gives the client this data and allows it to adjust.

Removing the Via headers based on privacy concerns doesn't hold up because
of the concealed-host facility.

Additionally the presence of the Via headers on the response is also useful
for debugging.

For these reasons the Via headers should not be removed on the return path.

4.8.3 ttl

Why is it necessary to give this information in the via header?

4.8.4 hidden-host

The Via header allows for the use of a token in lieu of a host name for
security reasons. Reasonable enough, however the token namespace does not
have any guarantees of non-collision. I realize that it may seem unlikely
that two unrelated system administrators would pick the same pseudonym for
their proxies until you remember how many servers in the world have the same
name. How many DNS names have you seen whose high level domain is Calvin?
Hobbs? Hacker? Etc. The reason these don't collide, obviously enough, is
that the rest of the name is a DNS address that guarantees uniqueness. No
such protection exists here so two proxies both named Dilbert will think a
loop exists because they will see their own names.

As such you need to require that pseudonyms be something that is guaranteed
to be unique, such as a GUID (they are useful, aren't they? =). You can also
put in a note that for maximum security a proxy can change its name BUT it
must remember its old name for some reasonable period of time. A proxy can
also have multiple names simultaneously, so long as it remembers all of
them.

4.9 9 Compact Form

Rather than using compact header names why not just compress the entire
message, including headers? Compression is incredibly fast and this will
make your UDP messages even smaller than the compact header names can make
them, a major benefit for UDP. You can use a similar format to your message
encryption mechanism to provide for compression.

4.10 11.2 - Connection Management for TCP

In general we have found that giving meaning to the creation or destruction
of connections is not a good idea. It makes it difficult to create generic
transmission systems and for proxies to combine multiple requests from
multiple users all going to the same place in the same connection. This
ability will be especially critical for SIP where each individual's message
is likely to be very small and having to build and tear down TCP/IP
connections would suck. As such it is advisable to use a timer rather a
connection loss and of course encourage clients to send BYE.

4.11 Connection Header

SIP clients are already compliant with HTTP/1.1 persistent behavior. However
you may want to consider adding support for the connection: close header.
This lets clients tells servers or servers tell clients that they intend to
close the connection. This helps harvest connections more efficiently but is
NOT an HTTP/1.1 requirement.

4.12 OPTIONS

I would strongly recommend you make OPTIONS support mandatory. Discovery is
a fundamental feature. We have regretted not guaranteeing support of
OPTIONS.

---

From: Lewis McCarthy <[email-masked]>
Date: Wed, 29 Apr 1998 00:31:53 -0400

[It took me a little while to realize that the SIP draft you're reviewing
(-05, I guess) is not the version available at www.ietf.org -- the latest
there is -04.]

> from a security point of view.

Sec 4.2.5 says that

   A site MAY wish to advertise a common public key for all local proxies to 
   allow users to encrypt their registration for privacy.

I take this to mean that a sysadmin may configure all the proxies in the
administrative domain with a single public key, and then notify all users
in that domain of that key out-of-band (w.r.t. SIP). Thus REGISTERs can be 
kept confidential from other users on the local subnet. I don't see this
local key distribution as part of the SIP protocol per se.

-- 
Lewis    http://www.cs.umass.edu/~lmccarth/

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 May 1998 22:32:37 -0400

> around. It should leave the functionality of those descriptions to others.

I commented out the sentence.

> proxy receives TCP confirmation of receipt it needs to send an ACK on the

This is roughly true, but needs a bit more discussion:

- We may (in the future) make use of ACK to generate a final session
description. (Caller proposes, callee makes counteroffer with its
receive capabilities, caller provides final set of capabilities.) This
is currently allowed. Imagine the following slightly contrived scenario:

Caller can use either of two applications to receive audio, with
different sets of media types (say, MPEG3 and the typical "Mbone
codecs", to give a somewhat realistic example). It offers both, to give
the callee more flexibility. The callee chooses the Mbone codecs as its
receive capability (and, if the session description allowed, would also
indicate its send preference), but now the caller needs to make a
decision and tell the callee what its final choice is, namely the
original list minus MPEG.

- I'd like to keep the "upper layers" of SIP to be as ignorant of the
transport as possible.

> know what is going on. Please don't repeat our mistakes.

Agreed. I believe I have removed the mentioning of connections as being
semantically significant. Let me know if I missed an instance.

> from a security point of view.

Presumably the public key would be signed?

> moved to standards status any day now.

For Call-IDs, only version-4 UUIDs are appropriate, as they provide a
modest, but important protection against BYE attacks (where the bad guy
sends a BYE to your existing call, with a guessed Call-ID).

I've included the version-4 UUIDs for now, as it's backward compatible
with what we had and since these are only compared for equality.

Objections?

> new GUID will be generated and thus collisions avoided.

We rely for sequence numbers also for ordering, so that may not be
sufficient. Also, since sequence numbers are only generated by user
agents and are only unique within a Call-ID, it seems very unlikely that
a user agent would crash and restart the same Call-ID, unless it saved
that to stable storage. (In that case, it should save the CSeq as well.)

> server and return the response.

I had considered a "wrapper" method that simply includes Content-Type:
message/sip. Unless somebody feels strongly about this, I'd like to
defer this until the next round, since it is a backward-compatible
addition.

> SIP on how this is actually done.

Text, anyone?

> The host production in sent-by isn't IPv6 compliant.

Once somebody else figures out what the appropriate "host" IPv6
representation is, we should use it. If possible, I'd like to avoid
having two different versions of "host" (within and outside of a URL).

> Why is it necessary to give this information in the via header?

To reproduce the path.

> also have multiple names simultaneously, so long as it remembers all of

Unless I'm missing something, this is tied to the "Need-to-keep-Via"
issue (and my message from a few weeks ago).

Pseudonym Vias don't work for forwarding.

> encryption mechanism to provide for compression.

I'll let somebody else comment on this. One minor comment: I don't want
to have to assume that all systems do compression, as they may be
extremely memory-limited. (Remember, not all SIP clients are PCs or even
Windows CE devices.)

> connection loss and of course encourage clients to send BYE.

See comment above.

> NOT an HTTP/1.1 requirement.

Anybody else have an opinion on this? I'm inclined to agree, although I
may need a reminder why telling the other side that it is going to close
the connection is all that helpful (compared to just closing it).

> a fundamental feature. We have regretted not guaranteeing support of

Change tentatively made, barring protests from elsewhere.

-- 
Henning Schulzrinne   [email-masked]
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 May 1998 09:27:23 -0400

> is currently allowed. Imagine the following slightly contrived scenario:

Actually, being able to send a description in the ACK makes
interoperability with non-fast-start H.323 systems a little easier. An
H.323 to SIP gateway won't have any media information when it receives
the first H.225.0 SETUP message from an H.323 terminal, and so it must
generate a SIP INVITE with a "fake" session description. When the 200 OK
comes back, the gateway can perform the H.245 negotiation and logical
channel procedures. When done, it can then send the ACK with the
"correct" session description. Of course this is not the only way to do
it; one could just reissue the INVITE with a modified SDP later on.
However, this approach saves a few messages and allows call setup to
operate with a single transaction.

> semantically significant. Let me know if I missed an instance.

I'm not sure including a connection: close header in a BYE helps. After
the initial INVITE transaction, subsequent requests (both ACK and BYE)
are likely to be sent directly to the destination party. This means that
the proxy servers along the initial request path are not likely to see
either a BYE or an ACK. 

CANCEL seems to be what we are looking for here, anyway. A proxy
receiving a CANCEL can expect the client to close the connection once it
has received the response.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen