Subject: [Sip] review of draft-ietf-sip-refer-02

From: William Marshall <[email-masked]>
Date: Tue, 13 Nov 2001 10:50:04 -0500 (EST)

Following are comments from a careful reading of draft-ietf-sip-refer-02.
All but the last two (or three) items qualify as nits.

Section 1, second sentence, "This SIP SIP [1] extension" change to
"This SIP [1] extension"

Section 2 should be dropped before passing on to IESG.

Section 3, last sentence of first paragraph, "A success response
indicates that the recipient was able to contact the third party." is
no longer accurate, and should be re-worded to indicate the only that
the recipient understands what is being asked.

Section 3.1 depends on RFC2396 to include the "?hdr=value" tag values
of the URL.  Perhaps a ref to RFC2396 is appropriate.

Section heading for 3.1.1 should be removed, since there is no 3.1.2.

Section 3.1.1, third example, "Replaces:12345" should be "Replaces=12345"

Section heading for 3.2.1 should be removed, since there is no 3.2.2.

Section 3.5.1 should add some text describing the handling of
"to-tag" and "from-tag" (as shown in one of the examples in 3.1.1).
Without any special exception handling, they would turn into SIP
headers "to-tag: ..." and "from-tag: ...".  

Note that the above exception handling also means that SIP header names
of "to-tag" and "from-tag" should be reserved.  Another entry for IANA.

A general structural suggestion to the document.  When REFER was one
part of a larger draft, it made sense to have everything relating to
REFER inside one section (section 3 in this draft).  Since the entire
draft deals with REFER, this should not still be the case.  I recommend
promoting section 3.8 (Examples) to section 4, and 3.9 (Security 
considerations) to section 5

Section 3.9, fourth paragraph.  The security considerations section
SHOULD NOT contain normative language; the second sentence of this
paragraph should be moved to section 3.5.

Section 5. In addition to the IANA items already listed, this I-D
also defines an Event package name "refer" and a message body type
of "message/sipfrag".

The purpose of an "IANA Considerations" section (chairs, please confirm)
is to establish a new registry.  The text in section 5 merely lists
items that IANA should add to existing registries; this should be
done by the author (or WG chairs) before finalizing the document.
Therefore section 5, as it exists in this I-D, should be deleted
in the final version.

And also a couple of substantive discussion issues to raise with this 
draft; so consider the remainder some early last-call comments.

(1) Dependencies.  This draft makes a normative reference to 
draft-ietf-sip-events-00.  While I sincerely hope sip-events
is stable, the refer draft should probably not be sent to IESG
until events has completed its last call, just in case sip-events is
not as stable as I hope, and there are changes that affect REFER.

(2) compact form of headers.
Refer-To and Refer-By do not seem to be such "high-runners" of SIP
headers to deserve compact forms.  I doubt they will occur more often
than headers such as "Route", "Record-Route" and "Supported" which do
not have compact forms.  Draft-ietf-sip-guidelines seems to suggest
the first 17 (26 minus the 9 compact forms defined in bis-05) new headers
defined in extension drafts should use them up.  A better guideline
is needed.

(3) security
The security section is correct in the second paragraph that anyone
can issue a request claiming that they were referred to that resource
by an arbitrary third party.  I think the refer draft should get the 
level of security at least as high as general SIP, so that the final UAS
can reasonably restrict access to itself.

Has 3GPP accepted REFER as the way to implement call transfer?  Security 
was a huge consideration when my proposal to use REFER in 3G was initially 
rejected last May.  My suspicion is that without a "reasonable" security 
mechanism (like comparable to HTTP digest authentication, a sufficiently
low threshold to meet), no service provider will allow REFER.  

While a mechanism to protect header integrity is sorely needed in SIP,
I don't believe it will solve the problems of REFER.  The UAS would
want to authenticate the referrer (UA that initiated the REFER), not just
the UA that initiated the refer-requested INVITE.

Consider the following as a strawman proposal:

  Agent A                Agent B                 Agent C
     |                      |                      |
     |---REFER------------->|                      |
     |<--202 Accepted-------|                      |
     |                      |---INVITE------------>|
     |                      |<--4xx Ref Auth-(*1)--|
     |<--NOTIFY (w/4xx)-----|---ACK--------------->|
     |---200 OK------------>|                      |
     |                      |                      |
     |---REFER-(w/Auth,*2)->|                      |
     |<--202 Accepted-------|                      |
     |                      |---INVITE-(w/Auth)--->|
     |                      |<--200 OK-------------|
     |<--NOTIFY (w/200)-----|---ACK--------------->|
     |---200 OK------------>|                      |
     |                      |                      |

Agent C, (*1) responds to the INVITE with a Referred-By header by a new 4xx
response code, requesting authentication by the Referred-By-entity.
Agent C provides a challenge.  This information is passed back to Agent
A in the NOTIFY; more than just the 4xx response code is in this
message/sipfrag.

Agent A then re-issues the REFER with the proper authentication (*2)
response.  This authentication information is included in the INVITE
sent by Agent B to Agent C, who then accepts the request.

Can this use the existing "Authentication-Info" and "Authorization" headers?
If so, how does Agent B know whether to answer the authorization request,
or pass it back to Agent A?  A new 4xx response code could help, but what
if Agent C also wanted to authenticate Agent B?  Perhaps new headers 
are required for this. If so, they would seem to be REFER-specific, and 
should be included in this draft instead of in a general security 
principles and procedures document.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  http://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: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 16 Nov 2001 16:13:20 +0200

Hi Bill:

See my comments below.

William Marshall wrote:
[snip]
> low threshold to meet), no service provider will allow REFER.

3GPP has flows based on the REFER, but they are in stand-by, in the annex
of the specification, waiting to have a wider acceptance and to resolve
the security issues that you point out.

> principles and procedures document.

I agree with you that some sort of authentication mechanism is desirable.
However I think that the problem is difficult to solve. In your example,
does it mean that A and C must share some secret key in order to authenticate
each other? 

If the answer is yes, I don't think the mechanism is valid, because it 
implies a heavy key management scheme between agents A and C in your 
example. Or are you thinking of something completely different.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002