Subject: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.txt

From: Aki Niemi <[email-masked]>
Date: Wed, 12 Apr 2006 13:06:07 +0300

Howdy,

I was asked to make an expert review of
draft-ejzak-sipping-p-em-auth-00.txt. Please see below.

ADs are also CC'd, as instructed by RFC 3427. I'm also citing the
relevant portions of that RFC as reference.

   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.

Yours truly.

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

Check; defines a single P-header field.

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

The proposed mechanism in this draft relates to early media, specified
in RFC3959 and RFC3960. But it is an orthogonal mechanism to early media
as such, being that it is solving the authorization issue of
(bidirectional) early media also mentioned in the Security
Considerations of RFC3959. Therefore there is no overlap, AFAICS, to
existing or planned chartered extension work in SIP.

   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.

Strictly speaking, the behavior of SIP entities is not altered, but the
extension serves as an indication to controlling related media session
gating. Therefore this extension isn't contradicting #4.

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

Check. The draft is explicitly scoped for systems where RFC3325 security
model based on transitive trust applies. In such scenarios, the security
properties are not affected by the proposed mechanism.

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

The ABNF of the extension header field is defined, but the IANA
considerations section is missing.

   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 applicability statement does state that the extension is not
suitable for the Internet at large, but is only intended for specialized
deployments that have the RFC 3325 security and trust model. However, it
doesn't go into details as to what are the exact reasons this mechanism
couldn't have wider applicability. I suspect many of those reasons have
to do with coupling of signaling and media resources, and especially the
charging model of those media resources. Since this coupling can not be
made in the general case, the authorization decisions can not be made
based on signaling alone.

So in conclusion, it seems this proposed extension is in line with the
criteria of RFC 3427. The only thing missing is the IANA considerations
section, which should make a registration of a new SIP header field.

As a side comment, the draft also doesn't explain what would happen in a
scenario where early media is not allowed, indicated by "P-Early-Media:
inactive", and is therefore gated off; yet the UAC doesn't support the
proposed extension. How does it handle getting silence while expecting
early media?

Also a nit: the short draft title says P-Early-Media-Auth, but the
header field is called P-Early-Media.

Cheers,
Aki

Designated Expert reviewer

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Apr 2006 18:21:52 -0400

I'd like to add to, and disagree with some of, what Aki says. Comments 
inline.

	Paul

>        or planned chartered extensions.

There may be some potential overlap with RFC 3959. It provides an 
explicit way to signal an intent to exchange early media. This draft 
doesn't explain what if any impact it has on that mechanism.

That mechanism can result in two offer/answer exchanges going on in 
parallel, and negotiating different media streams. Those negotiated 
using early-session are *intended* for early media. One would hope that 
P-Early-Media would not apply to those.

> gating. Therefore this extension isn't contradicting #4.

IMO a case can be made that this at least aids and abets a violation of 
normative behavior in standards track extensions.

This header is only required because, in its absence, there is an intent 
to block early media. But early media is normative behavior:

- RFC 3264 specifies that an answerer MAY send media immediately upon 
sending an answer. If the network blocks early media it violates that.

- ICE depends on being able to send packets that are for all intents a 
form of early media.

- using the "gateway" model, early media cannot be distinguished from 
"regular" (late?) media that outruns the signaling that the call has 
been answered. So blocking "early" media can also block some "regular" 
media.

> header field is called P-Early-Media.

I have a number of other lesser issues with this draft:

- It isn't clear about state model - how the use of this new header 
interacts with offer/answer. Is this a new piece of dialog-usage state 
that remains until changed? Is it permissible to change the state in a 
response that doesn't contain an offer or answer?

- It doesn't discuss the relationship of this header to cases where 
there is more than one early dialog. (As a result of forking.)

- It doesn't discuss its impact on reINVITE. One might presume that this 
header is meaningless once the call is answered, but that isn't discussed.

- It doesn't discuss its interaction with UPDATE, which may happen 
before the call is answered, and which may have an additional offer or 
answer. For instance the UAS for the INVITE may send an UPDATE with a 
new offer. There might be need to change early media authorization at 
this time.

- It assumes that authorization for early media is all-or-nothing if 
there are multiple media streams. If you believe early media needs to be 
authorized, then it seems likely that the policy might vary from stream 
to stream. Using 3pcc and B2BUAs it is even possible that two media 
streams in one offer or answer may originate at different UAs.

- NIT: there are no provisions in the header syntax for future 
extensibility.

	Paul