Subject: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-06.txt

From: [email-masked]
Date: Mon, 8 Mar 2010 03:15:03 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF.

	Title           : An Analysis of Automatic Call Handling (ACH) Implementation Issues in the Session Initiation Protocol (SIP)
	Author(s)       : J. Elwell
	Filename        : draft-ietf-bliss-ach-analysis-06.txt
	Pages           : 25
	Date            : 2010-03-08

This discusses problems associated with automatic call handling (ACH)
when using the Session Initiation Protocol (SIP) and specifies some
best practices to help achieve interoperability.

This work is being discussed on the [email-masked] mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bliss-ach-analysis-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Mar 2010 12:26:52 +0100

Changes from 05 to 06 are mainly to address comments from Gonzalo Camarillo recently. Change summary:
- Unused reference to RFC 3840 removed.
- Reference to RFC 2119 added.
- Reference to draft-griffin-bliss-rest replaced by reference to draft-zourzouvillys-bliss-ach (although the latter is more recent, it has already expired).
- Added a Terminology section to cover use of RFC 2119 key words.
- Expanded acronyms on first use.
- Added clarification to 6.3 (was 5.3)
- Deleted open issue related to draft-roach-sip-http-subscribe.
- Added an appendix reproducing the survey results from the web page concerned (since that resource might cease to exist).

After submission I noticed that I had not replaced the web reference by a forward reference to the new appendix, so I already have this on the TODO list for 07.

Note that this work item is stuck on the need for a reference to an adopted draft covering RESTful procedures for ACH manipulation - all we have at present is an expired individual draft.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: 08 March 2010 11:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-06.txt
> 
> This draft is a work item of the Basic Level of 
> Interoperability for SIP Services Working Group of the IETF.
> 
> 
> 	Title           : An Analysis of Automatic Call 
> Handling (ACH) Implementation Issues in the Session 
> Initiation Protocol (SIP)
> 	Author(s)       : J. Elwell

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 08 Mar 2010 12:23:56 -0500

On Mon, 2010-03-08 at 12:26 +0100, Elwell, John wrote:
> - Reference to draft-griffin-bliss-rest replaced by reference to
> draft-zourzouvillys-bliss-ach (although the latter is more recent, it
> has already expired).
> - Added an appendix reproducing the survey results from the web page
> concerned (since that resource might cease to exist).
> 
> After submission I noticed that I had not replaced the web reference
> by a forward reference to the new appendix, so I already have this on
> the TODO list for 07.
> 
> Note that this work item is stuck on the need for a reference to an
> adopted draft covering RESTful procedures for ACH manipulation - all
> we have at present is an expired individual draft.

Unless someone steps up very very soon and commits to driving that
RESTful API draft forward, I think you're going to have to find some
other solution, John.  The current plan of the co-chairs is to drop that
work item, since no one is claiming to be working on it.

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 12 Mar 2010 14:54:53 -0500

My review of this draft (wearing individual contributor hat)...

Section 4.3:

  The draft references an expired I-D (elwell-bliss-dnd).  I suggest
  that you either remove the reference, or add the required material
  somewhere in this document.  (Personally, I think the truth of the
  assertion that there is not standardized response to indicate DND is
  apparent, but I suspect that others would disagree).

Section 4.4, second paragraph:

  The draft says:

    Where there is forking proxy between the entity performing ACH and
    the calling UA, information may be lost because of the
    Heterogeneous Error Response Forking Problem (HERFP).

  While many readers may believe that they understand what HERFP is, I
  don't think it's appropriate to either assume that they all believe
  the same thing, or leave the uninitiated in the dark.  I suggest
  either finding an existing description appropriate to reference,
  adding an appendix to include one, or replacing this shortcut with
  some short description of what happens.

Section 4.4, third paragraph:

  This paragraph make some assumptions about how forwarding is
  implemented that I believe are not universal.  It may or may not be
  true that a UA receives no information when a request is retargeted
  (even provisional responses provide some information, as might the
  use of History-Info).  When redirection is used, the the calling UA
  may or may not see any 3xx response, depending on whether or not
  there is a forking proxy between the requester and the UAS returning
  the 3xx.

Section 4.6, first paragraph:

  The draft says:

    If ACH is performed at the proxy, the user needs a means to configure
    the proxy with the required rules.  There is no SIP means of doing
    this, but a number of mechanisms can perform the basis for this task,
    e.g.:

  that last sentence would be better made both active and
  conditional... something like

    There is no standard mechanism in SIP to configure ACH rules in a
    proxy, but implementations might provide non-standard mechanisms
    such as:

Section 4.6, page 9 second paragraph:

  The draft says:

    Related to this is the means by which a UA (and hence the user) can
    discover how the proxy is configured.  Most of the mechanisms listed
    above are applicable, and also a SIP SUBSCRIBE/NOTIFY mechanism could
    be used.  The survey indicated that only a minority of proxies
    provided support in this respect.

  Again, making this conditional would be clearer, and it should also
  be more specific - what's of interest is how the proxy is configured
  with respect to ACH.  With respect to the survey result, again being
  more explicit would be clearer.

    Related to this is the means by which a UA (and hence the user)
    can discover what ACH rules a proxy is currently using.  Most of
    the mechanisms listed above might be used, and it might also be
    possible to define a SIP SUBSCRIBE/NOTIFY mechanism.  The survey
    indicated that only a minority of proxies provided ...

  The '...' is left to you, since it's not clear to me what it is the
  survey indicated (do only a minority of proxies provide any way at
  all of figuring out what will happen to a call?  seems unlikely).

Section 5 (Discussion):

  This section is pretty good, but misses one issue with implementing
  ACH in UAs that I think is important, that being the security of
  responses from UAs.  Unless the connection to a UA is authenticated
  either with TLS (rare, especially on the last hop) or through Digest
  authentication (whose integrity protections are not strong enough),
  the response from a UA might be modified by an attacker.  Even if
  the signalling can, by some means, be secured there remains the
  problem that a UA might be physically compromised (I step into your
  office while you're momentarily away, and change the ACH in your
  phone).  In general, ACH in a central system is more easily secured
  and changes more easily audited.

Section 6.5:

  The draft says:

    In view what is specified in [RFC3261] for 6xx response codes and
    with some, but not all existing practice, it is safest to regard 6xx
    response codes as impacting all branches of a forked INVITE request.

  In what sense is this 'safest'?  Perhaps if your motivation is to
  have some 'pure' implementation of a literalist interpretation of
  3261, but if you want a phone system people are happy with then I
  think not.  In my experience, some phones return 6xx codes for local
  rejection, and users complain bitterly if the call is not then sent
  to voicemail or some other reasonable action is taken; they rarely
  seem to mean "disconnect this caller with extreme prejudice".

Section 6.6:

  The draft says:

    General methods for configuring proxies (including synchronization of
    multiple proxies serving a domain) are considered outside the scope
    of BLISS work.

  Even if true (and I'm not sure it is), I don't think that statement
  adds anything to the document, and will make little sense in an
  archival document when no one remembers what BLISS was.

Section 7.1:

  I don't know that the two normative (MUST) statements here actually
  make any sense in practice, and in any event they are not very
  specific.

  What does a UA having 'all ACH features turned off' really mean?
  Never return a 3xx response?  Never return a 486 busy response?
  Disable the 'Do Not Disturb' button?  Don't give the user the option
  to reject a call?

  Similarly, what does it mean that a proxy must 'operate when ACH is
  provided by the registered UA'?  That the proxy cannot implement any
  redirection or retargeting?  If so, then the assertion that this
  'typically would be the default configuration' is certainly not true
  of any system I've encountered.

Section 7.2 says:

   o  Response code 487 for silent rejection/local.  This is the same
      response code that would be used if a proxy were to issue a CANCEL
      request.

  That's a new (to me, at least) usage that does not seem to me to be
  within the meaning given to it by 3261:

    The request was terminated by a BYE or CANCEL request.  This response
    is never returned for a CANCEL request itself.

  It would not surprise me if a UAS (either the originator of the
  INVITE or some intermediate system) would not expect to see a 487
  when it had not sent either a BYE or a CANCEL.

  In practice, I think that the only way to really have a 'silent'
  rejection (which I define as a rejection that the caller cannot tell
  is a rejection) is to simply not send any final response at all,
  just as though I just let the phone ring until it stopped on its
  own.  I've encountered SIP phones that did it this way - a silent
  rejection on the phone UI suppressed the local call indication, but
  did not send any final response at all, leaving the caller to time
  out the early dialog.  This approach is mentioned in section 6.3.1,
  and I think that would be better advice to give for this case.

  As for global rejection, I think that UAs should never issue 6xx
  responses unless it is absolutely clear to the user that what they
  are doing is disconnecting the caller completely and preventing any
  ACH in any upstream system.  In practice, no UA can really know
  that, so a 6xx response is alway ambiguous (in my proxy, we've just
  changed them so they are handled as local rejections with no effect
  on subsequent ACH by the proxy).

  Nit: don't use the term 'SPIT' without defining it.

Sections 7.3 and 7.4:

  These don't have any content now, and it's not clear (given the
  discussion earlier in this draft) that there's much of anything to
  say.  Hopefully we can get the effort to specify mechanisms for this
  done, but it would seem to me to be out of scope for this draft.

Section 9 (Security considerations):

  I'm not sure that I agree that there are no security considerations
  as the draft stands now.  If the final version of this draft
  actually recommends that 6xx responses (which are difficult or
  impossible to authenticate in most systems).  See the discussion
  above of the security implications of response authentication.

Multiple Sections:

  There are a number of references to the SIPPING config framework as
  a possible means of doing various things.  One such example is in
  section 6, page 12, second bullet:

   o  Configure the UA and proxy independently.  The SIP configuration
      framework [I-D.ietf-sipping-config-framework] is one possible
      means of configuring the UA.

  In fact, I don't believe that I-D specifies anything remotely like a
  means to configure any ACH behavior in the UA.  At this point, I
  know of no standard means of configuring UA behavior for ACH (or
  anything else), certainly not in any IETF document.

  I think that all those references need to be examined to see whether
  or not they are actually supported by
  I-D.ietf-sipping-config-framework as it exists today.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Mar 2010 19:40:02 +0100

Scott,

Thanks for your review. Responses below. 

> From: Scott Lawrence [mailto:[email-masked]] 
> Sent: 12 March 2010 19:55
> To: Elwell, John
> Cc: [email-masked]
> Subject: Review of draft-ietf-bliss-ach-analysis-06.txt
> 
[JRE] This is a difficult one. I thought about adding the material in an appendix, but the DND draft is too lengthy and goes beyond the topic of response code. Even the material on response code is somewhat lengthy, may not stand alone too well, and duplicates some of the material already in the ACH-analysis draft. Therefore the only simple solution is just to remove the reference. Any other opinions?

>   some short description of what happens.
[JRE] Added a short description: "HERFP is where different forked-to UASs return different error responses, yet in accordance with RFC 3261 rules for forking proxies, only one of these reaches the UAC. Thus an error response of possible significance may not reach the UAC."

>   there is a forking proxy between the requester and the UAS returning
[JRE] I have clarified the wording for both the retargeting case and the redirection case. In addition I have added a sentence at the end:
"In other words, information received by the calling UA is variable, although this is not necessarily a bad thing since provision of information needs to be governed by policy."

>     proxy, but implementations might provide non-standard mechanisms
[JRE] Done.

>     indicated that only a minority of proxies provided ...
[JRE] Done.

>   all of figuring out what will happen to a call?  seems unlikely).
[JRE] I don't know what was meant by that sentence. I will delete it.

>   and changes more easily audited.
[JRE] I don't want to get into issues of security of SIP messages on the wire, because that can have some impact almost anywhere in the document. The point about an unauthorised user changing the UA while my back is turned is reasonable, so I will add "Furthermore a proxy can be more secure, since a UA might be vulnerable to manipulation by an unauthorized user while the normal user is momentarily absent."

>   seem to mean "disconnect this caller with extreme prejudice".
[JRE] I seem to recall quite a lot of discussion on this at the time (a couple of years ago), and that this was the consensus. So I won't make any change. If you want to re-open it, please start a separate thread, but I would prefer that you don't.

>   archival document when no one remembers what BLISS was.
[JRE] Probably more accurate to say "outside the scope of this document".

>   make any sense in practice, and in any event they are not very
[JRE] Perhaps SHOULD? But I don't like that. We are trying to improve interoperability, and the conclusion was that by turning off ACH features at the UA, leaving it to the proxy, a certain class of interoperability problem can be avoided.

>   Disable the 'Do Not Disturb' button?  Don't give the user the option
[JRE] It means responding to indicate the state, and leaving the proxy to determine any subsequent action.

>   of any system I've encountered.
[JRE] Normally an out-of-the-box proxy has all ACH features turned off. It will need some configuration to cause forwarding from A to B, for example, this can never be default.

>     is never returned for a CANCEL request itself.
[JRE] Exactly, if I send a CANCEL, the UA will respond to the INVITE with 487.

>   when it had not sent either a BYE or a CANCEL.
[JRE] We had a long discussion on this a couple of years ago, and I don't want to re-open the debate now.

>   and I think that would be better advice to give for this case.
[JRE] The point is, the proxy can interpret the 487 as meaning silent rejection, and not pass it on to the UAC, thereby letting it time out. However, the proxy might perform other local actions if it knows that silent rejection is required, in particular cancel other branches.

>   on subsequent ACH by the proxy).
[JRE] Again, this was the group consensus a couple of years ago.

>   Nit: don't use the term 'SPIT' without defining it.
[JRE] OK

>   above of the security implications of response authentication.
[JRE] I will think about adding something.

>   I-D.ietf-sipping-config-framework as it exists today.
[JRE] Yes, as that work hasn't progressed to the extend envisaged (work on profiles has stopped), it is perhaps best just to delete those references.

I will not post a new version until after IETF#77.

John