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

["Elwell, John" <[e-mail]>]

Scott,

Thanks for your review. Responses below. 

> -----Original Message-----
> From: Scott Lawrence [mailto:[e-mail]] 
> Sent: 12 March 2010 19:55
> To: Elwell, John
> Cc: [e-mail]
> Subject: Review of draft-ietf-bliss-ach-analysis-06.txt
> 
> 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).
[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?

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

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

> 
> 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:
[JRE] Done.

> 
> 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 ...
[JRE] Done.

> 
>   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).
[JRE] I don't know what was meant by that sentence. I will delete it.


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

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

> 
> 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.
[JRE] Probably more accurate to say "outside the scope of this document".

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

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

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

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

> 
>   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).
[JRE] Again, this was the group consensus a couple of years ago.

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

> 
> 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.
[JRE] I will think about adding something.

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

> 
> 
>