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

[Scott Lawrence <[e-mail]>]

On Fri, 2010-03-19 at 19:40 +0100, Elwell, John wrote:

> Thanks for your review. Responses below. 


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

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

That's what I had in mind - a wording suggestion:

        'HERFP' is shorthand for a common problem with error responses
        to requests forked at a proxy; if multiple UAs return error
        responses to such a request, RFC 3261 requires that the proxy
        forward only one error response to the UAC. Thus an error
        response of possible significance may not reach the UAC.

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

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

Better.

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

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

Good.

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

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

I've made my point.  Implementations will do what they need to do
anyway.

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

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

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

> [JRE] It means responding to indicate the state, and leaving the proxy
> to determine any subsequent action.

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

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

My real point is that I'm not sure that there is any value in making
statements about what is 'typically' true.  Any system that includes a
voicemail service that I've ever seen includes sending calls to
voicemail by default when not answered.

I certainly agree that it should be possible to tell either a proxy or a
UA not to do any redirection or retargeting... if you like MUST for
that, that's fine.

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

> [JRE] Exactly, if I send a CANCEL, the UA will respond to the INVITE with 487.

My reading of that suggestion was that if my phone rings, and I press
the 'reject silently' button on my phone, then it should send 487.  I
don't think that's correct behavior because there was no CANCEL from the
UAC.  If that's not what you meant, then that section is confusing.

> [JRE] We had a long discussion on this a couple of years ago, and I
> don't want to re-open the debate now.

Ok...