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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 13 Apr 2006 16:20:45 -0500

Aki, Paul,
Thank you for your detailed comments.  I will draft changes to accommodate them as described below.

Paul Kyzivat wrote:
> I'd like to add to, and disagree with some of, what Aki says. 
> Comments 
> inline.
> 
> 	Paul
> 
> Aki Niemi wrote:
> > 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.
> 
> 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.

P-Early-Media was never intended to apply to "early-session" media.  I will clarify this.

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

There are plenty of examples in existing RFCs where an answerer is not able to send media immediately upon sending an answer.  Preconditions come to mind.  Receipt of a black hole address is another.  What RFC 3264 seems to say is that the answerer MAY ATTEMPT to send media.

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

Messages used for ICE, such as STUN, can be gated separately from RTP flows in networks needing to support NATs.

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

It is appropriate to include text to warn of this possibility.

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

I will add this in the next draft.

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

I don't see what else I might add regarding general applicability of the mechanism, so I propose to leave the text as is.

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

According to RFC 3960, a UAC has to be able to deal with either the presence or absence of early media, regardless of the value of the header, so I don't see what the issue might be.

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

OK.

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

The answer to both questions was intended to be "yes".  I'll make sure it's clear.

> 
> - 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 is intended to apply independently to each dialog.

> 
> - 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 is intended to apply only to the early dialog.

> 
> - 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 was intended that if early media authorization changes at the same time as an offer/answer exchange in an UPDATE transaction, that the UAS would send a separate provisional response with the early media header to indicate the change.  If you are proposing to add the header to the UPDATE request, that would be a reasonable thing to do.

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

It would be quite easy to allow multiple direction parameters to apply in order to separate media lines, as you seem to propose.  This would also be a reasonable thing to do.

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

OK.

Richard

_______________________________________________
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: Fri, 14 Apr 2006 10:40:48 -0400

Richard,

A few added words added to the draft here and there will adequately deal 
with most of the issues here.

But the fundamental issue is whether blocking early media by default, 
and without the awareness of *both* UAs, is valid or is in fact a 
violation of sip. IMO it is a violation.

In the cases you cite as examples where early media is not possible:

> There are plenty of examples in existing RFCs where an answerer is not
> able to send media immediately upon sending an answer. 
> Preconditions come to mind. 
> Receipt of a black hole address is another. 

the two UAs are complicit and aware of what is going on, and so are able 
to adapt their behavior to the circumstances.

In the case of preconditions, if they are used in the offer but the 
answerer doesn't understand, then the offerer knows the answerer doesn't 
understand and is expected to make things work appropriately.

In the case of a black hole address, again it is obvious to both that 
there will be no successful delivery of media to the black hole.

Another example you didn't mention is if the offer contains a=sendonly 
or a=inactive. Again both parties then know the score based on public 
standards. Even then the offerer is supposed to recognize if the answer 
indicates a lack of understanding, and should deal with it.

What draft-ejzak-sipping-p-em-auth-00 proposes doesn't have these 
properties. Notably, the UAs is never informed that early media will not 
work. Consider the following use case:

- UA-A is registered with AOR-A at Provider-A, which uses
   draft-ejzak-sipping-p-em-auth-00 to manage early media

- UA-B is registered with AOR-B at Provider-B, which does *not*
   use draft-ejzak-sipping-p-em-auth-00. (Provider-B
   permits early media.)

- There is no trust relationship between Providers A & B.
   Calls are forwarded between them using basic RFC 3263
   procedures. But Provider-A will not accept a P-Early-Media
   header from Provider-B. (And Provider-B wouldn't know to
   provide one anyway.)

- Provider-B provides a call screening feature. Incoming calls
   to AOR-B go to a server (AS-B) that uses early media (Gateway
   Model) to prompt for and receive a password. If the proper
   password is provided, the call is forked to the registered UA-B
   where it rings and may be answered. If the incorrect password,
   or no response, is provided, the call is rejected by the server.

- UA-A sends an INVITE to AOR-B. Then AS-B tries to
   send a password prompt in the media stream to UA-A and read
   the response. But Provider-A has blocked the media stream, so
   no response arrives. Eventually AS-B terminates the call,
   so UA-A fails in its attempt to call AOR-B.

(Note that the feature could be provided using either the Gateway Model 
or the Application Server model. I here assume the Gateway Model because 
it doesn't require support for any extensions, except possibly PRACK.)

In this case, Provider-B behaved in a standards compliant way, and yet 
the result was bad because Provider-A did something non-standard. And 
neither user has a clue why this failed, and neither had any real option 
for how to fix it.

If AS-B knew that early media was not supported, it could adjust its 
behavior - perhaps just returning a 403 Forbidden response. Then UA-A 
would at least know something was amiss. One thing that comes to mind is 
for Provider-A to insert a P-Early-Media header into the request as well 
as the response. But this would violate the rules of P-headers because 
it changes behavior and so depends on the recipient understanding the 
P-header.

Two possible solutions come to mind for me:

1) stop trying to be so picky. Just allow early media all the time.
    If you are concerned about fraud, charge for the early media.

2) explicitly indicate in the offer that early media isn't supported,
    e.g. using a=inactive. Also indicate support for the Application
    Server model of early media. Gateways and application servers that
    need early media and are allowed to use it can then negotiate an
    early-session to do it.

Some other odds and ends of comments inline. I've snipped the old text 
down to just what is relevant.

	Paul

> P-Early-Media was never intended to apply to "early-session" media.  I will clarify this.

Thanks.

> Messages used for ICE, such as STUN, can be gated separately from RTP flows in networks needing to support NATs.

It would be good to indicate that the gating is intended to be sensitive 
to the content type, rather than applying to everything to/from the port.

> It is appropriate to include text to warn of this possibility.

OK. But I'm not convinced it is sufficient to warn that one is planning 
to violate the specs.

>>>while expecting early media?
> 

My scenario above deals with a related case in more detail. It covers 
the case where the callee doesn't support the extension.

Its a little different when the caller doesn't support it. Of course the 
caller can never know for sure if the callee expected it to get early 
media. So in some sense it doesn't have to deal with this case.

> The answer to both questions was intended to be "yes".  I'll make sure it's clear.

Thanks.

> It is intended to apply independently to each dialog.

It is relatively obvious that this is intended, but it wouldn't hurt to 
mention forking and discuss the implications on all parties.

> It is intended to apply only to the early dialog.

It would be helpful to mention this then talking about the processing of 
INVITE messages and responses - that the procedures only apply to an 
*initial* (dialog forming) INVITE.

> It was intended that if early media authorization changes at the
> same time as an offer/answer exchange in an UPDATE transaction,
> that the UAS would send a separate provisional response with the
> early media header to indicate the change.  If you are proposing
> to add the header to the UPDATE request, that would be a
> reasonable thing to do.

Either way can work. Allowing the header in UPDATE and responses to 
UPDATE would save a message exchange. Either way it would be useful to 
mention the case and how it is to be handled.

> It would be quite easy to allow multiple direction parameters
> to apply in order to separate media lines, as you seem to
> propose.  This would also be a reasonable thing to do.

This would change the syntax quite a bit, and its not clear how you 
would correlate values to particular media lines. Seems like a bit of a 
hack.

Making such a change would not eliminate my primary objection to the 
overall concept. (It would be more a case of perfuming the pig.) So I'm 
not sure such a change would be an improvement.

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

Having already encountered multiple P-headers without provisions for 
extensibility, and where it has later proved to have been a mistake, I 
am going to keep raising this issue for every P-header. It is really 
cheap allow generic-param on every header.

	Paul