Subject: [SIP] I-D ACTION:draft-ietf-sip-100rel-03.txt

From: [email-masked]
Date: Thu, 08 Mar 2001 06:58:36 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Reliability of Provisional Responses in SIP
	Author(s)	: J. Rosenberg, H. Schulzrinne
	Filename	: draft-ietf-sip-100rel-03.txt
	Pages		: 18
	Date		: 07-Mar-01
	
This document specifies an extension to the Session Initiation
Protocol (SIP) providing reliable provisional response messages. This
extension uses the option tag org.ietf.sip.100rel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-100rel-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-100rel-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 08 Mar 2001 21:48:09 +0200

My comments to the draft.

First, some cosmetic issues:

1.

Chapter 4 says:

"Note that a UAS MUST NOT send a response reliably unless there was a
Supported or Require header in the request indicating this extension
[4].

...while chapter 6.2 says:

"If the request did not include either a Supported or Require header
indicating this feature, the UAS SHOULD send the provisional response
unreliable"

Q: Shouldn't it be "..., the UAS MUST send the provisional response
unreliable" in 6.2, because that is what is said in 4.?

2.

In chapter 6.3 it is said that specific proxy support for this feature
is not needed. Still, there is a MUST that proxies must forward all
provisional responses, even if the RFC 2543 doesn't mandate that.

I think that it should say that proxies that DOES support PRACK MUST
forward all provisional responses. In the RFC, it should then be said
that proxies SHOULD (since it's not mandatory) do so. This may sound
like a small issue, but if these kind of "MUSTs" start to come up in
every draft/extensions, even if they are not required by the RFC, I can
see interop problems coming up...

Then, some functional comments:

3.

It is said that a UAC MUST NOT generate an additional reliable
provisional response until the first is acknowledged. Personally I
don't, which I have mentioned before, like this, but I do understand the
reason.

So, my question is: why can't the UAC include the initial RSeq value in
the INVITE? Then the UAC knows which will be the first value to be used,
and the UAS doesn't have to wait for the PRACK to the first provisional
response before it sends additional provisional responses.

Now, it may be argued that this is not good for security reasons, but I
don't think it affects security at all. In fact, I don't think the idea
of using a random value will provide much security in the first place. A
third party person can send a first provisonal response using any number
it wants (1 or a random), since the UAC doesn't know which value is
"correct". This problem would not be solved by putting the RSeq in the
INVITE, but I think security would be decreased either.

And, I don't think we are going to provide SIP security just by using
random numbers for some headers. There will always be ways for third
parties to send crap messages. If security is wanted, security has to be
added - either in the protocol or by a underlaying mechanism (IPSec,
TLS, or whatever...)

4.

Chapter 5 it says:

"The Route header that is constructed from some provisional response
MUST NOT be placed in any other request except for the PRACK for the
specific provisional response"

First, IF this is a rule it should be in the RFC. Second, I don't think
it should be written anywhere. The ISUP related discussion we've had
(overlap dialing, INFO before 200,...) has shown that it may be needed
to use Route headers from provisional responses also in other requests
(INVITEs, INFOs,...), and it's also an issue for routing in general.

That's all from me :) Comments?

Regards,

Christer Holmberg
Ericsson Finland

[email-masked] wrote:
>   ------------------------------------------------------------------------