Subject: [Sipping] SIPPING review of draft-vanelburg-sipping-served-user-02.txt

From: Spencer Dawkins <[email-masked]>
Date: Mon, 08 Oct 2007 12:52:42 -0500

I was asked to provide an expert review for this draft. My review follows.

The ADs should pay particular attention to notes 3 and 7 below - they are 
the requirements I'm still not sure are satisfied.

I also included additional comments for the authors, but these comments 
should not be considered part of the expert review.

Thanks,

Spencer

Summary...

1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
       proposal for applicability to SIP and conformance to these
       guidelines.  The Expert Reviewer will send email to the Transport
       Area Directors on this determination.  The expert reviewer can
       cite one or more of the guidelines that haven't been followed in
       his/her opinion.

* Spencer Dawkins is the designated expert. This e-mail is sent to the
SIPPING mailing list. The RAI ADs are copied in this email.

   2.  The proposed extension MUST NOT define SIP option tags, response
       codes, or methods.

* The draft satisfies this requirement: The draft defines a new P-Header
called "P-Served-User" that identifies an IMS Public User Identity.

I should mention that I didn't see any explanation of usage for this
P-Header - is it applicable for all SIP methods? response codes? etc.

   3.  The function of the proposed header MUST NOT overlap with current
       or planned chartered extensions.

* The draft satisfies this requirement to the best of my ability to tell
(although this isn't easy to know for sure because "served user" is only
defined as "IMS Public User Identity of the user" in this specification -
I'm fairly sure that we don't have current or planned chartered extensions
for exactly this, but can't be sure that we don't have current or planned
chartered extensions for anything analogous to this, and that's the critical
question).

I wish this draft did not define Yet Another Identity (as Jeroen pointed
out), but I don't think this concern belongs in my expert review.

   4.  The proposed header MUST be of a purely informational nature, and
       MUST NOT significantly change the behavior of SIP entities which
       support it.  Headers which merely provide additional information
       pertinent to a request or a response are acceptable.  If the
       headers redefine or contradict normative behavior defined in
       standards track SIP specifications, that is what is meant by
       significantly different behavior.

* The draft satisfies this requirement: the P-Served-User header contains an
IMS Public User Identity. This header does not redefine or contradict
normative behavior defined in standards track SIP specifications.

A proxy or AS might change its behavior based on a difference between
P-Served-User and some other identity, but since conveying the difference
between this the P-Served-User identity and other SIP identities is the goal
for this P-header, this effect seems reasonable.

   5.  The proposed header MUST NOT undermine SIP security in any sense.
       The Internet Draft proposing the new header MUST address security
       issues in detail as if it were a Standards Track document.  Note
       that, if the intended application scenario makes certain
       assumptions regarding security, the security considerations only
       need to meet the intended application scenario rather than the
       general Internet case.  In any case, security issues need to be
       discussed for arbitrary usage scenarios (including the general
       Internet case).

* The draft satisfies this requirement:  The security section describes the
security considerations that apply to insecure network paths and allows for
two methods of securing those paths (physical security and IPsec). The draft
also points out the need to remove these headers at domain trust boundaries.

   6.  The proposed header MUST be clearly documented in an (Individual
       or Working Group) Informational RFC, and registered with IANA.

* The draft satisfies this requirement:  It is intended to become an
Informational RFC, and lists the header in its IANA section. The IANA
section includes all the information that
http://www.iana.org/assignments/sip-parameters contains for entries in the
header field subregistry.

   7.  An applicability statement in the Informational RFC MUST clearly
       document the useful scope of the proposal, and explain its
       limitations and why it is not suitable for the general use of SIP
       in the Internet.

* The draft may very well satisfy this requirement:  Two points here.

First, I'm reading "in the Internet" as "in non-IMS environments", so the
text that says

   When SIP is used on the Internet, there are typically no proxies
   involving an application server over an ISC interface.  Consequently,
   the P-Served-User header field does not seem useful in a general
   Internet environment.

does make me wonder if similar functionality is useful in non-IMS
environments (for example, MEDIACTRL use of ASs might also find a similar
capability useful).

Second, sections 3.1-3.4 are very dense (a lot of 3GPP-specific call flows
that are mostly the same from scenario to scenario), and I'm not sure how
"clear" this text is to the non-3GPP SIP community that needs to reach 
consensus that this P-Header would not be useful in a non-3GPP environment.

--------------------------------------------------------------

The following notes are included for the draft authors, but aren't part of
the expert review.

1.  Introduction

   The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia
   Subsystem) uses SIP (RFC3261 [2]) as its main signalling protocol.
   (For more information on the IMS, a detailed description can be found
   in 3GPP TS 23.228 [8] and 3GPP TS 24.229 [10].) 3GPP has identified a
   set of requirements that can be met, according to the procedures in
   RFC 3427 [5], by defining a new SIP P-header.

Spencer: I am hoping that you're saying "that are most appropriately met",
but (nit) this should probably be "met by defining a new SIP P-header,
according to the procedures in RFC 3427 [5]".

Spencer: I note that neither the abstract nor the introduction actually
summarize what that requirement is. Could a one-sentence description be
added?

   The remainder of this document is organized as follows.  Section 3
   outlines the problem using particular service scenarios and Section 4
   discusses the requirements derived from these scenarios.  Section 5
   defines the P-Served-User header field, which meets those
   requirements, and Section 6 discusses the applicability and scope of
   this new header field.  Section 7 registers the P-Served-User header
   field with the IANA and Section 8 discusses the security properties
   of the environment where this header field is intended to be used.

3.1.  General

   In the 3GPP IMS the S-CSCF (Serving CSCF) is a SIP proxy that serves
   as a registrar and handles originating and terminating session states
   for users allocated to it.  This means that any call that is
   originated by a specific user or any call that is terminated to that
   specific user will pass through an S-CSCF that is allocated to that
   user.

Spencer: If this draft can be slightly de-3GPPed, it would be much easier
for the IETF community to understand (and to agree with). Simply referring 
to the CSCF as a SIP proxy in many places would be a simple change, and text 
like "over the Cx interface" is true but not necessary for an understanding 
of this proposed P-header within the IETF. Some uses of 3GPP terminology in 
the Abstract and Introduction are useful, because they provide context for 
the request.

   At the moment that an S-CSCF is allocated for a specific user, a user
   profile is downloaded to the S-CSCF from the HSS (Home Subscriber
   Server) over the Cx interface.  This user profile tells the S-CSCF
   whether the user is allowed to originate or terminate calls or

Spencer: either this is garbled or my English skills have evaporated.
Perhaps "important for this particular document" was cut-and-pasted in
error?

   important for this particular document whether an AS needs to be
   linked in over the ISC interface.  The user profile information that
   determines whether particular initial request need to be sent to a
   particular AS is called initial Filter Criteria (iFC), see for
   example 3GPP TS 23.218 [7].

Spencer: the previous paragraph has a lot more detail than necessary. Is
this saying more than "When a S-CSCF is allocated for a specific user, the
S-CSCF receives a profile that tells the S-CSCF whether the user is allowed
to originate or terminate calls, or whether an application server is
required"?

   To be able for an S-CSCF to perform its responsibilities it needs to
   determine on which users behalf it is performing its tasks and which
   session case is applicable for the particular request.  (For session
   case see 3GPP TS 29.228 [11]) The session case distinguishes the
   originating and terminating call cases and whether the particular
   user is registered or not.

   When the S-CSCF determines that for an incoming initial request the
   originating call case applies, it determines the served user by
   looking at the P-Asserted-Identity header field ( RFC 3325 [4]) which
   carries the network asserted identity of the originating user.  When
   after processing the iFC for this initial request the S-CSCF decides
   to forward the request to an AS, the AS has to go through a similar
   process of determining the session case and the served user.  Since
   it should come to the same conclusion that this is an originating
   session case it has to look at the P-Asserted-Identy header field as
   well to determine the served user.

   When the S-CSCF determines that for an incoming initial request the
   terminating call case applies, it determines the served user by
   looking at the Request-URI ( RFC 3261 [2]) which carries the identity
   of the intended terminating user.  When after processing the iFC for
   this initial request the S-CSCF decides to forward the request to an
   AS, the AS has to go through a similar process of determining the
   session case and the served user.  Since it should come to the same
   conclusion that this is a terminating session case it has to look at
   the Request-URI as well to determine the served user.

   In the originating case it can be observed that while the P-Asserted-
   Identity header field just represents the originating user when it
   enters the S-CSCF, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In the terminating case a similar overloading happens to the Request-
   URI, while it first only represented the identity of the intended
   terminating user, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In basic call scenarios this does not show up as a problem, but once
   more complicated service scenarios (notably forwarding services)
   needs to be realised it poses severe limitations.  Such scenarios are
   brought forward in the following sub sections.

3.2.  Diversion; continue on terminating leg, but finish subsequent
      terminating iFC first

Spencer: given that sections 3.1-3.4 are very dense and repetitive, and you
think 3.2 justifies this header, you might either delete the others or 
simply list additional scenarios in one paragraph. 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 12 Oct 2007 15:02:46 +0200

Hi Spencer,

Thanks a lot for performing the review!

Some short response on the expert review comments below:
- On note 2:
There is some indication of the use of this header in clause 5 where it
states that 
"This header field can be added to initial requests routed from an
S-CSCF to an AS
or from an AS to an S-CSCF."
However I think we need to improve this to: 
"initial requests for a dialog or standalone requests".

- On note 3:
This is not yet another identity header being transported end to end. It
is only information shared between a SIP proxy (S-CSCF) and an
Application Server in the IMS architecture, as such it is not another
identity. 

- On note 7:
I quickly glanced through the main MEDIACTRL drafts, but they don't seem
to link in an AS on the dialog between two endpoints. But use a
dedicated dialog between an MS and an AS that manages the control
channel. Therefore I doubt that P-Served-User has application in that
context, I would expect the existing identity mechanisms to be
sufficient. 

Further I have tried to introduce all 3GPP specifics in a way that I
thought understandable to IETF, that is why certain parts are quite
chatty. If I failed there then we need to improve, but it is not yet
clear to me what is not clear.

Response to the other comments can be found inline tagged with
"HansErik:".

I sumitted an 03 version that until it appears on the IETF site can be
found here:
http://elburg.eln-research.nl/drafts/draft-vanelburg-sipping-served-user
-03.txt

Best Regards,
/Hans Erik

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, October 08, 2007 7:53 PM
To: [email-masked]
Cc: ext Cullen Jennings; Jon Peterson
Subject: [Sipping] SIPPING review
ofdraft-vanelburg-sipping-served-user-02.txt

I was asked to provide an expert review for this draft. My review
follows.

The ADs should pay particular attention to notes 3 and 7 below - they
are the requirements I'm still not sure are satisfied.

Thanks,

Spencer

Summary...

* The draft satisfies this requirement to the best of my ability to tell
(although this isn't easy to know for sure because "served user" is only
defined as "IMS Public User Identity of the user" in this specification
- I'm fairly sure that we don't have current or planned chartered
extensions for exactly this, but can't be sure that we don't have
current or planned chartered extensions for anything analogous to this,
and that's the critical question).

* The draft satisfies this requirement: the P-Served-User header
contains an IMS Public User Identity. This header does not redefine or
contradict normative behavior defined in standards track SIP
specifications.

A proxy or AS might change its behavior based on a difference between
P-Served-User and some other identity, but since conveying the
difference between this the P-Served-User identity and other SIP
identities is the goal for this P-header, this effect seems reasonable.

* The draft satisfies this requirement:  The security section describes
the security considerations that apply to insecure network paths and
allows for two methods of securing those paths (physical security and
IPsec). The draft also points out the need to remove these headers at
domain trust boundaries.

* The draft satisfies this requirement:  It is intended to become an
Informational RFC, and lists the header in its IANA section. The IANA
section includes all the information that
http://www.iana.org/assignments/sip-parameters contains for entries in
the header field subregistry.

First, I'm reading "in the Internet" as "in non-IMS environments", so
the text that says

does make me wonder if similar functionality is useful in non-IMS
environments (for example, MEDIACTRL use of ASs might also find a
similar capability useful).

Second, sections 3.1-3.4 are very dense (a lot of 3GPP-specific call
flows that are mostly the same from scenario to scenario), and I'm not
sure how "clear" this text is to the non-3GPP SIP community that needs
to reach consensus that this P-Header would not be useful in a non-3GPP
environment.

The following notes are included for the draft authors, but aren't part
of the expert review.

1.  Introduction

Spencer: I am hoping that you're saying "that are most appropriately
met", but (nit) this should probably be "met by defining a new SIP
P-header, according to the procedures in RFC 3427 [5]".
HansErik: Changed accordingly.

Spencer: I note that neither the abstract nor the introduction actually
summarize what that requirement is. Could a one-sentence description be
added?
HansErik: Changed to "3GPP has identified issues with the linking in of
a SIP application server that are most appropriately resolved by
defining a new SIP P-header, 
according to the procedures in RFC 3427 <xref target="RFC3427"/>."
The issue is hinted at in the abstract and is further explained in the
remainder of the document.

3.1.  General

Spencer: If this draft can be slightly de-3GPPed, it would be much
easier for the IETF community to understand (and to agree with). Simply
referring to the CSCF as a SIP proxy in many places would be a simple
change, and text like "over the Cx interface" is true but not necessary
for an understanding of this proposed P-header within the IETF. Some
uses of 3GPP terminology in the Abstract and Introduction are useful,
because they provide context for the request.
HansErik: I think that the first sentence of section 3.1 is very clear
in this:
"In the 3GPP IMS the S-CSCF (Serving CSCF) is a SIP proxy that serves as
a registrar and handles originating and terminating session states for
users allocated to it. "
I prefer to keep the text as is, I think appropriate clarification is
provided for the IETF community to understand how this is used.

Spencer: either this is garbled or my English skills have evaporated.
Perhaps "important for this particular document" was cut-and-pasted in
error?
HansErik: I removed the offending fragment. I guess it missed the needed
punctuation. But I agree removing it completely is better.

Spencer: the previous paragraph has a lot more detail than necessary. Is
this saying more than "When a S-CSCF is allocated for a specific user,
the S-CSCF receives a profile that tells the S-CSCF whether the user is
allowed to originate or terminate calls, or whether an application
server is required"?
HansErik: But the iFC concept is referred to later on, this was a
natural place to introduce it as it is not generally understioiod in the
IETF community. Or do I misinterpret your comment here?

Spencer: given that sections 3.1-3.4 are very dense and repetitive, and
you think 3.2 justifies this header, you might either delete the others
or simply list additional scenarios in one paragraph. 
HansErik: I think all the scenarios are needed, allthough they may seem
repetitive all emphasize another crucial aspect of the problem. 3.2
overloading of the Request URI, 3.3 overloading of the
P-Asserted-Identity and 3.4 a non-forwarding scenario that shows that
there are also cases not related to forwarding that are not able to
realize because of P-Asserted-Identity overloading.

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 12 Oct 2007 16:26:15 +0300

> clear to me what is not clear.

you should not use ANY 3gpp terms in normative parts of the draft.  i
commented on this long time ago already.  if you cannot describe in pure
ietf terms what a sip ua/proxy should do in order to conform to this
specification, then ietf is wrong place to submit it.

i also asked a question that you mean my "user" and never got a reply.

see

http://www1.ietf.org/mail-archive/web/sipping/current/msg14558.html

and

http://www1.ietf.org/mail-archive/web/sipping/current/msg14558.html

-- juha

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Mon, 15 Oct 2007 14:31:59 +0200

Hi Juha,

I'm sorry for missing your earlier posts.

I will try to answer the question here then.

You should understand the term "user" in the same sense as it is used in
rfc3324 and rfc3325. The P-Asserted-Identity header carries indeed a uri
that is an (one of possibly many) identities of a user. But in this case
the network asserts that this specific user is entitled to use this
identity. 

I think all the used terms are introduced and related to known terms in
IETF. There are other RFCs that also use IMS specific terms, for example
RFC4457. In that case this did not seem to be a problem for IETF either.

Best Regards,
/Hans Erik

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 3:26 PM
To: Hans Erik van Elburg
Cc: Spencer Dawkins; [email-masked]; ext Cullen Jennings; Jon Peterson
Subject: RE: [Sipping] SIPPING
reviewofdraft-vanelburg-sipping-served-user-02.txt

Hans Erik van Elburg writes:

> thought understandable to IETF, that is why certain parts are quite  >
chatty. If I failed there then we need to improve, but it is not yet  >
clear to me what is not clear.

see

and

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 15 Oct 2007 16:42:34 +0300

> the network asserts that this specific user is entitled to use this

i understand the term "user" as an owner of an AoR specified by
"username" and "realm" fields of authorization and proxy-authorization
headers.  in my application i don't case about the served aor, but i do
care about served user.

so how about having two new headers: p-served-aor and p-served-user?

 > RFC4457. In that case this did not seem to be a problem for IETF either.

it is ok to use ims terms in ims only related rfcs, but they should not
be used in rfcs that have general applicability.

-- juha

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Tue, 16 Oct 2007 16:13:49 +0200

Hi Juha,

If you look at the P-Asserted-Identity (RFC3324, RFC3325) first an
authentication means is used like for example the Authentication schemes
from RFC3261, but it might be any authentication scheme. To tie the user
concept to one specific authentication scheme I think is not such a good
idea.

So maybe there is a need for an application as you say, but I think that
is another application different then the one that this draft is
specifying.

Best Regards,
/Hans Erik

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Monday, October 15, 2007 3:43 PM
To: Hans Erik van Elburg
Cc: Spencer Dawkins; [email-masked]; ext Cullen Jennings; Jon Peterson
Subject: RE: [Sipping] SIPPING

Hans Erik van Elburg writes:

 > You should understand the term "user" in the same sense as it is used
in  > rfc3324 and rfc3325. The P-Asserted-Identity header carries indeed
a uri  > that is an (one of possibly many) identities of a user. But in
this case  > the network asserts that this specific user is entitled to
use this  > identity. 

 > I think all the used terms are introduced and related to known terms
in  > IETF. There are other RFCs that also use IMS specific terms, for
example  > RFC4457. In that case this did not seem to be a problem for
IETF either.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 16 Oct 2007 17:21:58 +0300

Hans Erik van Elburg writes:

 > To tie the user

fine, but you are tying "user" to mean AoR, which is not a good idea
either.  if term "user" is not well specified in rfc3261, then it should
not be used in your draft either.

-- juha

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Wed, 17 Oct 2007 11:25:02 +0200

Hi Juha,

The AoR concept is defined in terms of "user" in RFC3261. Following your
argumentation we should not use the AoR concept too. In fact the term
"user" is used a lot in RFC3261.

/Hans Erik 

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 4:22 PM
To: Hans Erik van Elburg
Cc: Spencer Dawkins; [email-masked]; ext Cullen Jennings; Jon Peterson
Subject: RE: [Sipping] SIPPING

Hans Erik van Elburg writes:

 > To tie the user
 > concept to one specific authentication scheme I think is not such a
good  > idea.

-- juha