[BLISS] Review of draft-ietf-bliss-ach-analysis-06.txt

["Scott Lawrence" <[e-mail]>]

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.