Re: General Comments on the SIP Protocol

[Henning Schulzrinne <[e-mail]>]

Yaron Goland wrote:
> 
> 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.

I commented out the sentence.

> 
> 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.

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.

> 
> 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.

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

> 
> 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.

Presumably the public key would be signed?

> 
> 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.

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?


> 
> 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.

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.)

> 
> 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.

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.

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

Text, anyone?

> 
> 4.8 6.38 Via
> 
> 4.8.1 Sent-By
> 
> 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).


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

To reproduce the path.

> 
> 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.

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.

> 
> 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.

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.)

> 
> 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.

See comment above.

> 
> 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.

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).

> 
> 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.

Change tentatively made, barring protests from elsewhere.

-- 
Henning Schulzrinne   [e-mail]
Dept. of Comp. Sci.   ph  [phone]
Columbia University   fax [phone]
New York, NY 10027    http://www.cs.columbia.edu/~hgs