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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 May 2006 07:55:21 -0400

Amen. I agree with all of Dean's points, and his assessment of my 
position is spot on.

	Paul

Dean Willis wrote:
> 
> On Apr 28, 2006, at 9:10 PM, Hadriel Kaplan wrote:
> 
>> You guys crack me up.
>> Yes SBCs can stop early media, and can do it now (though it's not very
>> common for them to do it).  But here you have a draft that proposes  a 
>> way
>> for a UAC to do it without an SBC, and only if the UAC wants to, so  that
>> SBCs don't have to - isn't that good thing from your perspective?
>>
>> It's trying to do it in a way that only a proxy needs to give it an
>> indication of the trust level of the UAS.  And proxies do trust
>> determination for other things already in the IETF.
>>
> 
> The question, as I see it, is "Is this 1) something that it's ok for  a 
> P-header to do, 2) something that is a general sort of problem that  we 
> should tackle as a standards track effort, or 3) something that  should 
> not be done at all?"
> 
> I believe Brian and Francois have argued for case 3, and that Paul's  
> position was more-or-less "If we must do it, then it would need to be  a 
> standards-track extension". Please correct me if I'm wrong here,  folks.
> 
> RFC 3427 lays out a few conditions for helping us make this decision:
> 
>    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.
> 
>    2.  The proposed extension MUST NOT define SIP option tags, response
>        codes, or methods.
> 
>    3.  The function of the proposed header MUST NOT overlap with  current
>        or planned chartered extensions.
> 
>    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.
> 
>    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).
> 
>    6.  The proposed header MUST be clearly documented in an (Individual
>        or Working Group) Informational RFC, and registered with IANA.
> 
>    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.
> 
> 
> So let's take these one at a time.
> 
> 1) Aki handled a review. He found the draft acceptable.  Other folks  
> pointed out some aspects he may not have considered, so it would be  
> useful to get his opinion about those aspects "post discussion".
> 
> 2) The document defines no option tags, although I think Paul (or  
> somebody on the thread he started) indicated that we may need an  option 
> tag in order to effectively negotiate this option.
> 
> 3) If we recognize the underlying problem here and accept it as a  
> general problem that we would work on with a standards-track SIP  
> extension, then we'd run afoul here. Otherwise, probably not, and  we're 
> ok on this question.
> 
> 4) This is where most of the argument is. Several folks have argued  
> that we're changing the behavior of SIP entities in a non- interoperable 
> way, and given the lack of an OPTION tag, can't  negotiate or even 
> detect a requirement for the non-interoperable  behavior. This makes me 
> very, very nervous. SIP is already complex  enough -- deliberately 
> introducing multiple-personality-disorder  would not make it any better.
> 
> 5) I think we're safe on the security considerations.
> 
> 6) This document is most of what would be required to make an RFC. I  
> think we've had some feedback in the review that would, at the least,  
> require a revision or two.
> 
> 7) I personally find the applicability statement a little week. It  
> needs to explain the limitations and why it is not suitable for the  
> general internet much more strongly. For example, the impact of not  
> being able to negotiate the behavior needs to be discussed and the  
> failure scenarios that Paul described need to be discussed. In short,  
> we must make clear why the "IMS gateway" case is special, different  
> from the common case, and requires handling in a non-standard manner.  
>  From my perspectives, P-headers are appropriate only where we have a  
> clearly constrained case that obviously won't occur in the general  
> Internet. I'd like to point out that P-Asserted-Identity was probably  
> not a good P-header, since it fails on Questions 3 and 5, and that  this 
> has caused us a substantial amount of grief. Live and learn, right?
> 
> Now, the good news (from my personal perspective) is I'm neither  chair 
> nor AD of the SIPPING working group, so I don't have to make a  call 
> here. Yay! But I will go on record (as a co-author of RFC 3427)  that I 
> don't believe that this draft, at this time, quite meets the  
> publication requirements of RFC 3427, and that I remain uncertain  (due 
> to Question #4, above) as to whether it ever will.
> 
> -- 
> Dean Willis
> 
> 

_______________________________________________
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: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 08:26:09 -0400

Hi Dean,
Comments inline...

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Sunday, April 30, 2006 1:44 PM
>
> extension, then we'd run afoul here. Otherwise, probably not, and
> we're ok on this question.

If you'd rather recognize the underlying problem and create an
IETF-originated solution, that's cool.  

> that we're changing the behavior of SIP entities in a non-
> interoperable way, and given the lack of an OPTION tag, can't
> negotiate or even detect a requirement for the non-interoperable
> behavior. This makes me very, very nervous. SIP is already complex
> enough -- deliberately introducing multiple-personality-disorder
> would not make it any better.

I agree that sending an indication in the Invite that the UAC is such a type
would be good.  There's no "negotiation" needed beyond the response, because
a UAC that wants to not bridge such media won't be convince otherwise with
more exchanges.

One of the problems with this draft I think is that it says a proxy that can
block, must block such early media.  There is no such "proxy" in the IETF,
AFAIK, and that is a big change.  That should be removed, IMO.

I think some people are concerned that the offer SDP is "lying", and
changing 3264 semantics, which I empathize with.  It's what I thought at
first, but now I'm thinking otherwise.  Although 3264 says that once an
offer is sent with recvonly or sendrecv the UAC must be ready to receive
RTP, I'm not sure it requires such received RTP to be bridged over TDM in
case of a PSTN gateway. (Does it?)  I think it implies the UAC must present
it to the user, but not when - and the term user is ambiguous when the UAC
is a PSTN gateway. (Does the IETF's term "user" include a POTS phone, or the
Class-5 switch?)  Isn't it up to the GW's local policy?  

Most PSTN-GWs I've seen won't play the received media until at least a 183
with SDP answer is received.  So pre-answer early media already doesn't work
today to such UAC types, nor does it for UACs behind NATs.  Even for
after-answer early media, wouldn't it be up to local policy when to bridge
such media?  If so, the UAS cannot rely on it making it to a PSTN handset
any earlier.

So from that perspective it isn't changing anything to be non-interoperable
- it is trying to fix things that are broken right now for one specific case
not applicable to the general Internet. (which is why it's a private header
extension) 

> Internet. 

In my mind this draft is for one "legitimate" use case: a PSTN gateway
initiating a session as a SIP UAC.  The obvious issue is if the resultant
UAS is a PSTN GW, trusted IVR or PBX or some such, then the UAC GW needs to
bridge the early media into the PSTN.  If it's an untrusted voip-only UAS,
then that UAS could use this behavior to play non-progress media.  For
example, an 800 movie theater number could play their movie times and never
pay a cent for calls - even if the PSTN caller was in Timbuktu.  The fraud
that can be committed is on the PSTN side, so is not applicable to the
general Internet.

One could do this with SDP with sendonly or inactive, or creating some SDP
parameter which means "I'll bridge media if you're good", but those all
require additional Updates/Re-Invites for all sessions from that UAC.  My
guess is initiating a PSTN-originated call to another PSTN-gw will have
problems if the first Invite's SDP isn't sendrecv or recvonly, because it
needs to send back progress indication immediately after the 183. (I don't
know that, just guessing)  Again, it's not applicable to the general
Internet usage.

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 09:09:30 -0400

I'm curious: is your objection because it's an "opt-in" signaling mechanism
vs. an "opt-out", or is it the idea of some UACs not bridging early media
when their signaling appeared as if it would that seems bad to you? 

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, May 01, 2006 7:55 AM
> To: Dean Willis
> Cc: Hadriel Kaplan; 'Brian Rosen'; [email-masked]; 'Sipping'
> Subject: Re: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
> xt
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 1 May 2006 09:23:18 -0400

Sorry, I'm confused.

On the PSTN today, anyone with a T1 can support one way early media (UAS to
UAC).  "Dumb" phones can't, but most everything else can.  We allow that.
It's really a strange thing; if you have enough money to have a T1, you can
give early media, if you don't, you can't.  It has nothing to do with
"legitimacy"; it's the size of the fraud: big ones work, little ones don't.

And now you come along and suggest we replicate that behavior in SIP?

Actually, the little UAC in SIP WILL get early media from the little UAS.
So, big fraud and little fraud works if your client in on the SIP side.

You want to perpetuate the big fraud to the PSTN caller, and not let him get
the little fraud.

Nice

Brian

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, May 01, 2006 8:26 AM
To: 'Dean Willis'
Cc: 'Sipping'
Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
xt

Hi Dean,
Comments inline...

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 11:05:06 -0400

Funny, this is starting to sound like the arguments we used against service
providers who wanted us blocking it as an SBC (we tried our hardest not to
block EM and only lamented relatively recently).

Their answer was: with TDM PBXs the cost/charge model covers if it's fraud,
and modifying the PBX to do so maliciously is much harder anyway.  With SIP
consumer phones the small-pstn-fraud can add up to very-big-pstn-fraud,
especially when those SIP phones are reached through other providers.

-hadriel
p.s. I'm not suggesting you replicate the behavior in SIP - TISPAN is, for
private network use cases. (and we did not contribute to that idea in tispan
either)  It may be useful, though, even for SBCs to have this header for
inter-provider peering cases, instead of using proprietary means. 

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, May 01, 2006 9:23 AM
> To: 'Hadriel Kaplan'; 'Dean Willis'
> Cc: 'Sipping'

---

From: Dean Willis <[email-masked]>
Date: Mon, 1 May 2006 12:40:22 -0500

> inter-provider peering cases, instead of using proprietary means.

It never cease to amaze me how many people keep insisting on building  
billing models off the SIP signaling despite being told time after  
time that this is NOT a good idea and will NOT be supported by the  
ongoing design work in IETF. Then they find out their billing model  
doesn't work, and come back to us for extensions to SIP to fix it.

This reminds me of a similar thread in:

http://www1.ietf.org/mail-archive/web/sip/current/msg09580.html

Wherein I asked: No, hell no, and what part of "no" did you not  
understand?

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 14:24:51 -0400

I do believe you're preaching to the choir on that one.  Media is what
people pay for, not signaling.  And this particular choir member has the
ability to do billing based on media right now.  ;)  But the reality is
signaling is used all over the place as you know.

Besides, isn't this case an example of when media-based billing fails?  One
UA type can send media for free and another cannot.  How do they
differentiate the "types"?

-hadriel

> Sent: Monday, May 01, 2006 1:40 PM
> To: Hadriel Kaplan
> Cc: 'Brian Rosen'; 'Sipping'

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 1 May 2006 21:36:52 +0300

Hadriel Kaplan writes:

 > people pay for, not signaling.

no, people pay for internet acess (wireline or wireless) and then run
whatever they want on top of it.  it is thei option to also pay for
hosting of applications, such as web page space, email service, or sip
signaling service.  they don't want to pay for each call they make using
sip signaling service in the same way they don't pay for each email they
send or receive.

if you or someone want to bill for the media, you can do your own thing
and stop wasting bandwidth on this list.  same goes for 3gpp
requirements (roots of which are in PSTN charging model), to which IETF
should said no long time ago.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 May 2006 14:44:15 -0400

> differentiate the "types"?

Why does it fail?

The signaling could be used to negotiate one "account" to be charged for 
early media and a different one to be charged for "confirmed" media.

Using the gateway model for early media there is a small window when 
some media that should be viewed as confirmed may be counted as early 
media instead, but it should be a small amount.

Then it just comes down to deciding on the policy to be used to decide 
who pays for the early media, not whether it is permitted.

	Paul

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 14:58:55 -0400

Actually it is media to/from the pstn I was talking about.
No one's forcing you to pay for media or signaling for sip over the
Internet.  If you don't want to pay per-call or per-month or whatever,
download a sip client and send your sip signaling through someone that
doesn't charge you anything (or send it direct).

If you don't think making calls to/from the pstn is worthwhile, then that's
up to you - ignore this thread. (I assume you don't pay per email :)  But I
think others wish to have pstn access.  I suspect sip would be a fairly
niche application today if that were not the case. 

-hadriel

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Monday, May 01, 2006 2:37 PM
> To: Hadriel Kaplan
> Cc: 'Dean Willis'; 'Sipping'

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 1 May 2006 22:12:20 +0300

> Actually it is media to/from the pstn I was talking about.

they you charge whatever you want at the pstn switch, which is out of
scope of sip.

-- juha

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 1 May 2006 14:30:10 -0500

Yuha is absolutely right and I would only like to add that the billing for
media and/or for signaling is so expensive as to be impractical.

Even PSTN services are now mostly flat rate in order to eliminate the mind
boggling per use charges.

Thanks, Henry

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Monday, May 01, 2006 1:37 PM
To: Hadriel Kaplan
Cc: 'Sipping'; 'Dean Willis'
Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
xt

-- juha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 16:32:53 -0400

I believe your anger is directed at the wrong person - I did not submit this
to SIPPING WG.  The draft came from Richard Ejzak, and through Tispan.  It
is for a "P-" header, and is for private network use and not for IETF SIP
standardization. 

I was hoping Tispan members would be willing to inject themselves in this
discussion, but since it is a European standards body and today is a major
European holiday many of them may not be checking email.

-hadriel

> Sent: Monday, May 01, 2006 3:12 PM
> To: Hadriel Kaplan

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 16:41:33 -0400

Somehow my monthly bill for calls to Europe and Asia doesn't jive with that.
And my cell phone is flat only for a limited number of minutes, after which
I seem to pay so much it makes gas prices seem reasonable.
:)
But I agree as more sip/ip gets deployed it will get flatter.
-hadriel

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Monday, May 01, 2006 3:30 PM
> To: 'Juha Heinanen'; 'Hadriel Kaplan'

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 1 May 2006 23:48:45 +0300

> is for a "P-" header, and is for private network use and not for IETF SIP

i'm not angry.  this is just a game.  

it was a big mistake for IETF to allow P header RFCs to be published in
the first place.  those could have been done in their respective
standardization bodies, such as 3gpp, so that bandwidth on this list
could be saved for important things.

i feel that the most urgent of all current i-ds is the outbound one,
because it will allow for the first time building in a standard manner
a load balanced, fault tolerant sip proxy infrastructure.

-- juha

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 1 May 2006 16:44:07 -0500

> Somehow my monthly bill for calls to Europe and Asia doesn't jive with 

Use SIP phones or Skype.

Henry

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, May 01, 2006 3:42 PM
To: [email-masked]
Cc: 'Sipping'
Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
xt

---

From: Aki Niemi <[email-masked]>
Date: Wed, 03 May 2006 09:44:11 +0300

> useful to get his opinion about those aspects "post discussion".

Frankly, the PSTN in all its interesting details was never really my
bag, so this discussion for the most parts flew by without me finding
anything to add.

Overall, I counted 80 messages on this thread landing in my inbox.
That's a lot. If anything, this further solidifies my belief that the
SIP change process of RFC 3427 is not working. We're getting wrapped
around the axle on discussing whether or not a proposal is evil or has
the "wrong" business model attached to it -- not whether it works as
intended. Honestly, I don't see these discussions on P-headers generally
very beneficial to have here. I tend to think that the markets will take
care of proposals attached with bad business models eventually anyway
and we need not bother.

That said, I still don't buy the argument that this header field changes
behavior of nodes in a *significant* way. If it did, I can't imagine why
blocking early media in terms of authorization of early media is then
mentioned in RFC3959, which is after all standards track.

> 4) This is where most of the argument is. Several folks have argued that
> we're changing the behavior of SIP entities in a non-interoperable way,
> and given the lack of an OPTION tag, can't negotiate or even detect a
> requirement for the non-interoperable behavior. This makes me very, very
> nervous. SIP is already complex enough -- deliberately introducing
> multiple-personality-disorder would not make it any better.

I don't believe this non-interoperablility argument, not at least when
this is still on paper. Would an option-tag make the problem go away?
Hardly. I think the problem is we're measuring a P-header by the same
standards we have for real headers.

Is there rather something that could be put into the applicability
statement to make these concerns go away, like to write down exactly the
cases when interop problems are expected to happen? So that implementors
and deployers can take notice.

I think there are much worse interoperability problems with "extensions"
vendors are making today, and they are definitely not writing them in
P-header drafts.

> require a revision or two.

Agreed. I'd give the authors a chance to make a revision of the draft,
and see if that gets a better reception. I still think it's not all that
bad a proposal, but then again, I don't even pretend to understand the
intricate details of early media as well as the others in this thread.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 May 2006 09:33:18 -0400

Snipping to just the key points...

> mentioned in RFC3959, which is after all standards track.

I can't find a reference to blocking early media in RFC3959, I suppose 
you meant RFC3960. I don't know why it meantions media authorization - 
maybe Gonzalo or Henning can explain.

> standards we have for real headers.

I continue to have difficulty deciding how RFC 3427 should be applied, 
especially condition 4. I would be happy to have more guidance on this.

We start down the road of measuring P-headers the same as real headers 
when it appears that the proposal has violated this condition.

Frankly, I wouldn't care if the applicability was really for a truly 
closed garden, that would never interoperate with anything else based on 
sip standards. But I don't for a moment believe that is the case or the 
intent.

Re an options tag: I didn't specifically propose one. What I did suggest 
was that the media authorization be done in such a way that both ends 
know if early media will be permitted or not. I'm not convinced that 
option tags are the way to achieve that. But if achieved, what it would 
do is provide both ends with the opportunity to avoid doing things that 
aren't going to work. It doesn't solve the problem in cases where there 
is no alternative to early media, but it at least mitigates the problem.

> and deployers can take notice.

There are practical problems with this. Suppose user A is connected 
through a service provider that is using the mechanisms of 
draft-ejzak-sipping-p-em-auth-00 to block early media from unauthorized 
sources. User B gets service from a "rogue" service provider that isn't 
part of the oligarchy that A's provider belongs to. But both providers 
are connected to the internet, and do interconnect via basic SIP routing 
rules. But because B's provider isn't part of the club, A's provider 
doesn't "trust" it, and so does not authorize early media.

B has configured his service to forward calls to his cell phone number 
on the PSTN when no sip device is registered. But B also forgot to pay 
his cellphone bill, and his service has been terminated.

Then A calls B. The call goes to B's provider. Nothing is registered, so 
B sends the call to its PSTN gateway, toward B's cell phone number. The 
cell phone provider plays a disconnected message in the media stream 
without answering the call. The gateway in B's network sends this media 
as early media towards A. But A's provider has blocked early media. So A 
hears nothing, and eventually the call drops.

Later A talks to B and says: I've been calling you and calling you 
without success. There must be something wrong because I just get 
silence and a disconnect.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 10 May 2006 14:33:49 +0300

Hi Paul,

> maybe Gonzalo or Henning can explain.

this is the paragraph you are probably referring to:

      "Note that, in some situations, the UAC needs to receive the answer
       before being able to play any media.  UAs in such a situation
       (e.g., QoS, media authorization, or media encryption is required)
       use preconditions to avoid media clipping."

It means that sometimes you will use media security and that you will 
need to see the answer in order to be able to perform media decryption 
or to check the integrity of the incoming integrity-protected media. 
This is what media authorization is is that context (it is related to 
data origin authentication). If the media packets have been modified, 
they are not authorized to be played.

Therefore, that paragraph is not directly related to the discussions on 
this thread.

Cheers,

Gonzalo