Subject: Re: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound calls

From: "Dave Burke" <[email-masked]>
Date: Wed, 16 Jan 2008 12:58:28 +0000

Just to close off this thread. Myself and Mark had a good discussion
on the issues raised  Mark makes a good point that removing S5.2 on
the basis of security concerns would be inconsistent with allowing
bridge transfer. In the end, we decided to remove S5.2 for the reasons
that the approach is not a widely accepted or practiced method and
we've yet to see where 3GPP goes with it. Moreover, the fact that
we're not standardizing this mechanism is not the same as forbidding
it

A new version of the document has been posted with S52. removed (and a
few other fixes resulting from the last call review). In particular,
the security section has been updated with information about transfers
and potential implications. See -
http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-vxml-01.txt

Dave

On Dec 21, 2007 2:05 PM, Mark Scott <[email-masked]> wrote:
>
>
>
>
> On the security issue, I suppose that we could make statements to this
> effect, although I'm not certain it would go all that far.  After all, if
> you've got a scenario in which the MS is making an outbound toll call out of
> some MG element somewhere, it'd be straightforward for evil.org to just make
> the call via the MG directly if it had infrastructure access.  That is to
> say, if you're assuming that the attacker has unfettered access to run SIP
> UAs within a SIP deployment, then preventing the attacker from bouncing off
> proxies (in the general sense of the term) is sort of moot if they can just
> perform the attack directly.  In reality you'd prevent direct and indirect
> attacks by putting an adequate security policy around the MG or whatever
> resource it was that you were trying to prevent the exploitation of.  I'm
> fine with a note if we want to add it, though.
>
>
>
> On the AS issue, the point I was trying to make was that "make outbound
> call" and "handle inbound call" are both really basic use cases that those
> in simple non-AS environments; the evidence of being that almost all
> VoiceXML Media Servers (which act as standalone platforms and not just as
> elements in an AS/MS environment) out there provide a non-standardized
> mechanism for performing exactly this function.  I can live with this
> function continuing to be non-standardized, and just thought of this as
> probably the only opportunity we'll have to standardize this widely
> implemented function.  I didn't imagine there would be a lot of sympathy on
> the 'mediactrl' list for something like this, though, given that the charter
> of the group is AS control over media functions J.
>
>
>
> However, if I had better phrased the tertiary argument, I would probably
> have said that even in an AS environment, the REFER option provides the AS
> with a lightweight mechanism for outbound calls in which it is not required
> to be on the call control path throughout the duration of the call.  There
> are many useful scenarios, like proactive notification, in which this could
> be the desired approach.  It looks like I may not be completely off my
> rocker, nor even original, in suggesting the use of REFER in this manner;
> the current version of 3GPP TS 23.228 (v8.30, but I recalled this from the
> R6 specs) notes:
>
>
>
> 5.14.2      Service control based interactions between the MRFC and the AS
>
>
>
> …
>
> There are two approaches for the AS to control the sessions. In the first,
> the AS uses 3rd party call control. The second approach uses the SIP REFER
> method.
>
> …
>
>
>
> This isn't elaborated upon (in 23.228), and I can't tell for certain whether
> that one line of text is in fact similar to the mechanism proposed in 5.2.
> I don't know the IMS specs well enough to even know where to look for
> something that better defines this.  However, if you look at Paul Kyzivat's
> comments on the 3PCC flow we did provide (on how exactly to manipulate the
> SDP to still be compliant with offer/answer), it certainly does highlight
> how non-trivial it can be to do the 3PCC flow correctly and in compliance
> with the relevant standards.
>
>
>
> Regards,
>
>
>
> Mark.
>
>
>
>  ________________________________
>
>
> From: Dave Burke [mailto:[email-masked]]
>  Sent: December-21-07 7:16 AM
>  To: Mark Scott
>  Cc: Eric Burger; David Burke; [email-masked]
>
>
>  Subject: Re: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound calls
>
>
>
>
>
> Going back to RJ's original mail, the two issues he laid out in connection
> with out-of-dialog REFERs were:
>    (1) Security concerns
>    (2) Non-conventional (no AS managed) call control
>
>  We could ameliorate security concerns by stating the MS SHOULD/MUST
> implement authentication ( e.g. HTTP authentication or a transport layer
> solution) on an out-of-dialog REFER. We would need to extend this to INVITE
> too if transfer is supported for the reasons Mark points out.
>
>  However, point 2 is more compelling IMO. We have included SIP flows for
> transfer because we have taken the pragmatic viewpoint that many networks
> today deploy and will continue to deploy IVR solutions without an AS and use
> the <transfer> element. (Typically in conjunction with PSTN gateways or
> PBXs). We explicitly recommend against using transfer with an AS because the
> AS cannot easily manage the ensuing flows. Therefore, it seems that offering
> yet another mechanism to do call control which is not under the management
> of an AS ( i.e. this unsolicited REFER for outbound calls) would be contrary
> to that recommendation, especially since there is a recommended alternative
> (3pcc).
>
>  Finally, Eric has already pointed out that the Security Considerations
> section needs to be updated to discuss transfer/billing issues. This thread
> should serve as input.
>
>  Dave
>
>
> On Dec 21, 2007 4:41 AM, Mark Scott <[email-masked]> wrote:
>
> Hi Everyone,
>
>  Thanks to Eric for sending this explicitly to my E-mail address; for
>  some reason I updated my sip and sipping subscriptions but not my
>  mediactrl one, so I had missed this entire dialog.  That would have been
>  a shame, since I believe I was the one responsible for this mechanism
>  appearing here in the first place!
>
>  First, let me say that there seems to be a fair amount of consensus here
>  that this should go away.  Despite proposing this, I'm not married to it
>  being there, so if this is the consensus of the group then I can
>  certainly live with it.  But before we axe it, I'd like to discuss some
>  of the points as a reminder of why it is there in the first place.
>
>
>  1.  Virtually everyone on mediactrl and most of us as participants come
>  from an environment in which there's always an application server
>  present.  However, it was intended that draft-ietf-mediactrl-vxml be
>  applicable even in the simplest environments possible, as described in
>  section 1.1.2 - where there's just a media gateway, a VoiceXML Media
>  Server, and no other elements.
>
>  This scenario is exactly why <transfer> was relevant enough to still be
>  in VoiceXML 2.1.  And while I've personally always advocated an
>  application server based approach, whether using CCXML or some other
>  mechanism for writing application server logic, it is definitely the
>  case that there are a very, very large number of deployments out there
>  that look exactly like section 1.1.2.  I do believe there's substantial
>  value in defining draft-ietf-mediactrl-vxml broadly enough that it
>  applies whether you're in this trivial situation, or you've got an
>  intelligent application server making full use of the specified
>  interface.
>
>  In these simplistic cases there's often only two "call control"
>  operations of interest - hang up, or transfer to an agent.  In such
>  situations, suggesting to the end user that they (a) deploy an
>  application server, (b) split the (trivial) "call control" vs. dialog
>  portions of their applications, and (c) learn a new language like CCXML
>  or JSR-116/289 to handle the application server pieces results in
>  exactly one answer: "Why?"  For these people, <transfer> is entirely
>  sufficient.
>
>  That's not the main issue in this thread, but as someone who did at one
>  point wish that <transfer> was never defined, I do see that being able
>  to handle the simple cases simply does have some value.  This point of
>  view is relevant in dealing with the real issue here.
>
>  This statement isn't self-serving at all, by the way; the next version
>  of our own products will *always* use a SIP AS in front of the MS, but
>  I've definitely seen enough of the simple scenarios to understand the
>  other view.
>
>
>  2.  The real debate here is about 5.2 and REFER outside a dialog to
>  trigger an outbound call.
>
>  Above, I argued that there are a lot of deployments using the simple MG
>  <-> MS scenario, who don't have (or want) an application server in the
>  picture.  One thing, beyond hangup and transfer, that many of these
>  applications *do* want is the ability to make an outbound call.  As a
>  consequence, this is something that virtually every VoiceXML platform
>  provides some mechanism for accomplishing (without requiring the use of
>  an application server).
>
>  An obvious and immediate argument is that sending a REFER to perform an
>  outbound call requires a UA anyways, and if you're going to go that far,
>  why not just put an AS there?  There's some validity to that, but there
>  are substantial differences.  It's a lot easier to send a REFER to an
>  MS, where the only two things you need to worry about are (a) the
>  destination, and (b) the VoiceXML URI & parameters, than it is to deploy
>  an AS that does everything correctly in terms of SDP offer/answer,
>  Accept/Requires, PRACK, and so forth.  Even assuming that you're willing
>  to go out and get a decent AS implementation (which probably won't be
>  free) so that you don't have to deal with the details, we've now put an
>  extra element in the call path.  That's one more element that can fail
>  and that thus we have to worry about high availability on, one more set
>  of messages for every SIP transaction related to that call, and so
>  forth.
>
>  If you agree that there are non-mediactrl deployment scenarios in which
>  the overhead of an AS might not be called for, then you might accept the
>  need for an MS to send an outbound INVITE.  And after all, unless we
>  kill <transfer> with bridge=true, then the MS is going to need to
>  support sending INVITEs properly anyways.  However, even if you agreed
>  with this, you might still feel that a REFER was the wrong way to do
>  this.
>
>  You could argue, for instance, that an HTTP or WS based approach to
>  providing such a capability is more appropriate than putting it on the
>  SIP interface.  There are valid reasons why this is true, but two
>  counter-points that led me to propose REFER in the first place:
>
>  * This is definitely a platform-level (not language-level) capability,
>  which every implementation provides, which we really have no other venue
>  to standardize;
>
>  * REFER can take advantage of SIP infrastructure for distributing
>  requests to available resources, whereas HTTP/WS-based interfaces would
>  be direct to the MS; if you had multiple MS instances you'd need
>  orthogonal load balancing of the HTTP/WS requests separately from the
>  balancing of inbound INVITE requests, despite that both requests are in
>  effect competing for the same resources.
>
>  These are the same reasons I presented the first time around as to why
>  outbound calls triggered via REFER made sense.
>
>
>  3.  Security.  Yes, on the surface of things, REFER looks dangerous if
>  you let evil.org send an unchecked REFER to the MS, triggering an
>  outbound call to some invalid number.
>
>  But there's *absolutely* no difference if evil.org sends an INVITE to
>  the MS, referring to a VoiceXML page containing a <transfer> with
>  bridge=true to exactly the same Request-URI.
>
>  The use of REFER here, IMO, presents no more of a security consideration
>  than the use of REFER anywhere.  We are not novel in proposing the use
>  of REFER outside a dialog, that option is explicitly stated in RFC 3515,
>  and we're not offering any reasons specific to a media server as to why
>  the use of REFER in this manner is problematic.
>
>  It is important here, of course, that supporting the receipt of a REFER
>  outside a dialog isn't mandatory; if implementations don't provide
>  adequate security, they aren't compelled to provide or to enable the
>  feature.
>
>  So, all in all, I don't think we've identified security related reasons
>  as to why this shouldn't be here.
>
>
>  For the reasons above, I actually do still favour supporting 5.2 -
>  though other issues have been noted with it that may need fixing.  I
>  don't believe there are any specific security issues at play here, and
>  while I am personally an advocate of the AS model, I have seen many
>  VoiceXML MS deployments where an AS is neither desired nor appropriate -
>  and draft-ietf-mediactrl-vxml is explicit in the intent of applying to
>  such environments (while obviously catering more to AS ones).
>
>  As noted at the beginning of this message, I am willing to yield to
>  group consensus, but I don't think we've yet identified valid reasons
>  why it should be axed (though, with nobody arguing for keeping it, many
>  may not have bothered stating their arguments :)).
>
>  Regards,
>
>  Mark.
>
>
>
>
>  -----Original Message-----
>  From: Eric Burger [mailto:[email-masked]]
>  Sent: December-20-07 6:15 PM
>  To: David Burke; Mark Scott
>  Cc: [email-masked]
>  Subject: RE: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound
>  calls
>
>  <chair-hat off>
>  I would love to see 5.2 just go away.
>
>  <chair-hat on>
>  Anyone want to see it stay?
>
>  ________________________________
>
>  From: Dan York [mailto: [email-masked]]
>  Sent: Thursday, December 20, 2007 1:46 PM
>  To: RJ Auburn
>  Cc: David Burke; [email-masked]
>  Subject: Re: [MEDIACTRL] SIP-VXML - 5.2 REFER Mechanism for outbound
>  calls
>
>
>  If section 5.2 is simply removed as per the ongoing discussion, you can
>  ignore this comment.
>
>  If the section is retained in some modified form, I would just point out
>  that the call flow diagram under 5.2 is the reverse of all the other
>  call flows in the document.  In all other similar call flows (2.6.x,
>  3.2, , "User Agent" is on the left and "HTTP Application Server" is on
>  the right.  The call flow in 5.2 is the opposite - HTTP App Svr on left
>  and UA on right.  I would suggest it be changed to be consistent with
>  all other similar call flows.
>
>  Again, if the entire section 5.2 is simply removed, the issue of the
>  reversed call flow goes away.
>
>  Regards,
>  Dan
>
>  On Dec 10, 2007, at 1:16 PM, RJ Auburn wrote:
>
>
>         As David says REFER outbound and <transfer> are two different
>  things. I would love to kill of <transfer> as well but recognize that is
>  not an option at this point.
>
>         It sounds like nobody  is really in love with the REFER based
>  outbound interface as specified in 5.2. Assuming noone comes up with a
>  reason not to it sounds like killing it off may be a quick and easy
>  thing to do here.
>
>         RJ
>
>
>                 ---
>         RJ Auburn
>         CTO, Voxeo Corporation
>         tel:+1-407-418-1800
>
>
>
>
>         On Dec 7, 2007, at 13:42 :26, Dave Burke wrote:
>
>
>                 So, I'm inclined to agree with RJ that REFER outside of
>  a dialog to initiate outbound calls is dangerous and that simply
>  omitting section 5.2 is the fix.
>
>                 To be clear, the use of REFER for call transfer, on the
>  other hand, does not suffer the problems RJ mentions (since the
>  application server is the receiver of the REFER) and for this reason and
>  others (like VoiceXML has transfer and people use it in a variety of
>  architectures), I would like to keep the transfer section as is.
>
>                 Dave
>
>                 On the subject of call transfer, I would prefer to leave
>  this section in.
>
>
>                 On Dec 7, 2007 1:02 AM, Eric Burger <[email-masked]>
>  wrote:
>
>
>                         <contributor hat on>
>                         My preference would be to KILL <transfer> once
>  and for all.  It has no right
>                         to exist.
>
>                         However, it is still Optional in VoiceXML 2.1,
>  so we have to live with it.
>                         I would almost say, "Live by the sword, die by
>  the sword."  If you have a
>                         media server that allows <transfer>, by
>  definition the application does not
>                         care about billing, and so the blind REFER is
>  OK.
>
>                         Conversely, if you own a media server and do
>  care about billing, you will
>                         not honor a <transfer> request in your
>  interpreter.
>
>
>
>                         On 12/3/07 3:31 PM, "RJ Auburn" < [email-masked]>
>  wrote:
>
>                         > Folks,
>                         >
>                         > I really hate to bring this up so late in the
>  game but one of the
>                         > sections of the SIP-VXML draft that has really
>  given me concern is the
>                         > REFER mechanism for outbound calls (section
>  5.2). Overall I think this
>                         > section needs somemore detail before I would
>  be comfortable with it
>                         > becoming an RFC. My concerns come down to two
>  main points:
>                         >
>                         > * Security - As it stands right now all we
>  have said is that platforms
>                         > should have some sort of local security policy
>  but there is very
>                         > little in the way of details on how it is
>  managed or implemented.
>                         > Given that in this case sending a REFER
>  outside of an existing dialog
>                         > causes a number of billing related issues that
>  can come up (for
>                         > example if evil.org decided to send a REFER
>  request to a VoiceXML
>                         > platform to cause it to dial toll services
>  causing charges to be sent
>                         > to the owner of the media server).
>                         >
>                         > * AS vs MS responsibility for placing calls -
>  Architecturally it
>                         > really feels to me we are mixing things up
>  when we have the media
>                         > server placing outbound calls without an AS
>  controlling the session.
>                         > the 3rd party call control option as specified
>  in 5.1 personally seems
>                         > like a *much* better fit and in general seems
>  to align much closer
>                         > with how I have seen VXML platforms deployed
>  in the field. To be fair
>                         > <transfer> is guilty of this as well and I am
>  not sure we should kill
>                         > it off but I would really rather avoid
>  muddling the waters any more
>                         > then we have to with adding pure outbound
>  calling via REFER.
>                         >
>                         > My preference would be to strike 5.2 from the
>  document and leave 5.1
>                         > (3rd party call control) as the recommended
>  approach to establishing
>                         > outbound VoiceXML sessions. The result is
>  something that lines up very
>                         > well with how I have seen system being
>  deployed and is able to avoid
>                         > stepping into a number of security issues that
>  come out of REFER based
>                         > outbound calling.
>                         >
>                         > Thoughts?
>                         >
>                         > RJ
>                         >
>                         > ---
>                         > RJ Auburn
>                         > CTO, Voxeo Corporation
>                         > tel:+1-407-418-1800
>
>
>
>                         Notice:  This email message, together with any
>  attachments, may contain information  of  BEA Systems,  Inc.,  its
>  subsidiaries  and  affiliated entities,  that may be confidential,
>  proprietary,  copyrighted  and/or legally privileged, and is intended
>  solely for the use of the individual or entity named in this message. If
>  you are not the intended recipient, and have received this message in
>  error, please immediately return this by email and then delete it.
>
>
>
>                         _______________________________________________
>                         MEDIACTRL mailing list
>                         [email-masked]
>                          https://www1.ietf.org/mailman/listinfo/mediactrl
>                         Supplemental Web Site:
>                         http://www.standardstrack.com/ietf/mediactrl
>
>
>
>
>         _______________________________________________
>         MEDIACTRL mailing list
>         [email-masked]
>          https://www1.ietf.org/mailman/listinfo/mediactrl
>         Supplemental Web Site:
>         http://www.standardstrack.com/ietf/mediactrl
>
>
>  --
>  Dan York, CISSP, Director of Emerging Communication Technology
>  Office of the CTO    Voxeo Corporation     [email-masked]
>  Phone: +1-407-455-5859  Skype: danyork   http://www.voxeo.com
>  Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com
>
>  Bring your web applications to the phone.
>  Find out how at http://evolution.voxeo.com
>
>
>
>
>
>  Notice:  This email message, together with any attachments, may contain
>  information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>  entities,  that may be confidential,  proprietary,  copyrighted  and/or
>  legally privileged, and is intended solely for the use of the individual
>  or entity named in this message. If you are not the intended recipient,
>  and have received this message in error, please immediately return this
>  by email and then delete it.
>
>
>
> -------------------------------------------------------------------------------------------------------------------
>  CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is authorized.
> Any liability arising from any party acting, or refraining from acting, on
> any information contained in this e-mail is hereby excluded. If you are not
> the intended recipient, please notify the sender immediately, destroy the
> original transmission and its attachments and do not disclose the contents
> to any other person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any attachments
> belongs to Alcatel-Lucent and/or its affiliated entities.
>
>
>
>
>
>
>  _______________________________________________
>  MEDIACTRL mailing list
>  [email-masked]
>  https://www1.ietf.org/mailman/listinfo/mediactrl
>  Supplemental Web Site:
>  http://www.standardstrack.com/ietf/mediactrl
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is authorized.
> Any liability arising from any party acting, or refraining from acting, on
> any information contained in this e-mail is hereby excluded. If you are not
> the intended recipient, please notify the sender immediately, destroy the
> original transmission and its attachments and do not disclose the contents
> to any other person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any attachments
> belongs to Alcatel-Lucent and/or its affiliated entities.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl