General Comments on the SIP Protocol

[Yaron Goland <[e-mail]>]

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.