Subject: Re: [siprec] Ben Campbell's Discuss on draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 18 Jun 2015 23:49:41 +0000

Hi Ben,

Thanks for all these valuable comments. Some of your points have been
discussed in other threads, but I do not see any direct response. Sorry
for the long delay. Let me try to summarize by commenting inline.

On 5/26/15, 4:11 PM, "Ben Campbell" <[email-masked]> wrote:

>Ben Campbell has entered the following ballot position for
>draft-ietf-siprec-protocol-16: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>I am concerned that this draft allows the recording session to downgrade
>security from the communication session. It says "SHOULD NOT", but then
>explicitly allows for the downgrade when the SRC and SRS are in the same
>administrative domain. This seems to create a whole new "last hop
>exception" for media, similar to the one for SIPS that we took so many
>years to deprecate. (Except it's worse because the potentially insecure
>hop goes to an endpoint not necessarily expected to be a party to the
>media.)

Andy explained as follows:

"I think the issue here is that the SRC and SRS will often be co-located
in an environment where mutual authentication was just not necessary and
therefore the WG did not want to mandate this in all cases.²

>
>Section 6.1.2 includes a "contract in place" as a form of recording
>indication. The other mechanisms seem to say that a given call is being
>recorded. A contract cannot do that, except in the degenerate case of
>"all calls are recorded." This doesn't seem to fit the spirit of the
>"MUST provide recording indication" language.

I expanded section 6.3 in an attempt to address similar concerns:

A recording-aware UA MUST provide a recording indication to the end user
 through an appropriate user interface, indicating whether recording is
on, off, or paused for each medium. Appropriate user interfaces may
include real-time notification or previously established agreements that
 use of the device is subject to recording.  Some user agents that are
automatons (e.g., IVR, media server, PSTN gateway) may not have a user
interface to render recording indication.  When such a user agent
indicates recording awareness, the UA SHOULD render recording indication
 through other means, such as passing an in-band tone on the PSTN
gateway, putting the recording indication in a log file, or raising an
application event in a VoiceXML dialog.  These user agents MAY also
choose not to indicate recording awareness, thereby relying on whatever
mechanism an SRC chooses to indicate recording, such as playing a tone
in-band.

>
>Section 12, 2nd paragraph says the SRC and SRS "MUST support SIP with TLS
>and MAY support SIPS with
>   TLS as per [RFC5630]". That actually downgrades the requirement for
>SIPS support from that in 3261/5630. (3261 says you MUST support SIPS if
>you support TLS.)

As noted in RFC 5630, SIPS was underspecified in RFC 3261 and this was a
source of confusion. RFC 5360 aimed to fix this, and states:

Because a SIPS URI implies that requests sent to the resource
   identified by it be sent over each SIP hop over TLS, SIPS URIs are
   not suitable for "best-effort TLS": they are only suitable for "TLS-
   only" requests.  This is recognized in Section 26.2.2 of [RFC3261]
<http://tools.ietf.org/html/rfc3261#section-26.2.2>.
Users that distribute a SIPS URI as an address-of-record may elect
      to operate devices that refuse requests over insecure transports.
   If one wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.

>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>The reference to 7245 is informational. Do you expect that a
>reader/implementor could understand/implement this draft without
>understanding the architecture and terminology from that RFC? The same
>applies for 3550--I'm skeptical that one could implement this draft
>without understanding RTP.

I will change these references to normative.

>
>-- Figure 1: The text says the flow is basically the same whether the SRC
>is in an endpoint or separate. This may be logically true, but the flow
>really would change--none of of the flow between UA(A) and SRC would
>exist.

I broke into two call flows, one illustrating each case.

>
>-- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS"
>reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to add
>some motivation as to why this draft seems to prefer UPDATE.

Added a citation. UPDATE is preferred, actually required, for the SRS to
request to snapshot, but re-INVITE or UPDATE can be used by the SRC to
send metadata. I don¹t believe any preference was meant to be implied.
UPDATE was chosen for the SRS to request metadata because it could be sent
regardless of the state of the dialog. This was seen as better than
requiring support for both UPDATE and re-INVITE for this operation.

>
>-- 5.3: It seems odd to me that the SRC can ignore an explicit preference
>not to record. Wouldn't it be better just to refuse to complete/accept
>the call, if some policy overrides the end-user's preference?

We decided to leave this choice to the user, who can drop the call if the
recording state of the call is not acceptable to the user.

>
>-- Figure 3: If the UA prefers not to be recorded, shouldn't it express
>that at setup time, rather than wait for the SRC to indicate recording is
>happening? As shown, this almost guarantees a bit of media will be
>recorded. (Seems like there should be some guidance about this in the
>text.) The last paragraph of 6.1.2 seems to reinforce the problem by
>suggesting the participant might base the decision to express a
>preference on a tag that is optional for the SRC to send in the first
>place.

Yes, but in this case the example read, "After the call is established and
recording is in progress, UA (B) later decides to change the recording
preference to no recording². This real time interaction seemed useful as a
example. More examples can be added if necessary.
Note that the use of the a=record attribute is REQUIRED when recording. It
is not optional.

>
>-- 6.3, last paragraph: It seems odd that the requirement to render a
>recording indicator be lower for a media server than for other UAs. This
>seems to circumvent user notification in one of the most common uses of
>recording these days.

This section was reworded, as quoted in my previous comment.

>
>-- 9.1 : The last bullet seems to be a motivation to not send metadata at
>all, which is expressly forbidden in the first paragraph.

This was meant to illustrate that the SRC may not record everything to
which it has access, with privacy concerns being one example. I suppose
such filtering could be performed later on the recorded content, but that
assumes a specific relationship the administrative domain of the SRC and
that of the SRS.

>
>-- 9.2: The use of  the content-type value as the sole indicator that the
>an UPDATE request should be interpreted as an request for a metadata
>snapshot update is rather odd.  If you end up with new kinds of metadata
>requests in the future, does each one get it's own media-type?

This is being sorted out in another thread. I agree, something needs to
change here.

>
>-- 12: If this doc is to depend on the security considerations in 6341,
>that needs to be a normative reference--which is a bit of a pain because
>I think it's an informational RFC.

We tried to avoid this with the language "The use cases and requirements
document [RFC6341] outlines the general security considerations, and this
document describes specific security recommendations.²

>
>-- 12.1: 
>"recording session uses TLS" -- I assume that's for SIP? Also It's worth
>discussing how mutual authentication applies if the SRC is in an end-user
>device. Is it expected to have a client cert? No option to use  SIP
>identity?
>
>Also, I'm a bit uncomfortable assuming devices in the same administrative
>domain automatically trust each other. It might be better to say "If they
>trust each other..."

Using the word ³trust" is a slippery slope as well. For a UA acting as a
SRC, the implied requirement is that it has a cert.
 
>
>-- 12.2:
>
>I get quite a bit of heartburn out of making Security Descriptions MTI
>and dtls-srtp optional. I guess I may have to hold my nose on this one.

It is what it is.

>
>Editorial:
>
>-- 4: 2nd paragraph: " ... does not represent the protocol"
> and first bullet: "Delivering recorded media in real-time as the CS
>media"
>
>I don't understand what either of those mean.

Neither do I :(
Perhaps it means the SRS is not defined to act as a playback device to be
brought into a CS by the SRC?

>
>-- 5.1, 2nd paragraph: "B2BUA to bridge
>the media between UA(A) and UA(B)"
>
>Is there a reason not to use the terminology from RFC 7092? (e.g. ³relay²
>or ³terminate² media)?

Relay sound good. I¹ll switch to that.

>
>-- 7.3.1: The normative language in the first paragraph is redundant to
>similar language in 6.3.

Will remove the redundant normative language in 7.3.1.

Cheers,
Charles

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 22 Jun 2015 18:36:03 -0500

Hi, thanks for the response. Comments inline. (I removed things that 
don't seem to need discussion)

Ben.

> therefore the WG did not want to mandate this in all cases.²

I think Andy's comments were to Stephen's discuss about mutual 
authentication in general. This is a somewhat different issue. I'm 
talking about when the participants of a call chosen to use certain 
security protections on the CS, and the SRC and SRS downgrade that for 
the RS.

(and by the way, I wrote that it says "SHOULD NOT" in my discussion, but 
the text in 12 actually says "should not". That should probably be 
capitalized unless it's stated elsewhere in caps.)

> mechanism an SRC chooses to indicate recording, such as playing a tone

I don't think that addresses my concern. There's a fundamental 
difference between an indication that this call is being recorded, and 
an agreement that all calls might be recorded. (Unless that agreement 
says all calls _will_ be recorded). The language here seems to conflate 
the two.

I realize that the following is mostly in the domain of lawyers and not 
engineers--but what happens when my mobile operator puts a "may record" 
clause in my user agreement. That seems to qualify under the language 
used here.

> a SIP URI, and send the request over TLS.

The quoted language is about when it might not be appropriate to _use_ 
SIPS. It doesn't talk at all about _support_ requirements. In 
particular, it does not relax the 3261 requirement that says "Any 
implementation that supports TLS MUST support the SIPS URI scheme."

[...]

> requiring support for both UPDATE and re-INVITE for this operation.

It would be worth adding a sentence or two to that effect.

> recording state of the call is not acceptable to the user.

That choice makes it considerably more likely for a user to accidentally 
allow themselves to be recorded when they intended not to.

> Note that the use of the a=record attribute is REQUIRED when 

Whether there are more examples or not, it would be useful to have a 
discussion of the implications of expressing a recording preference 
proactively vs reactively.

> This section was reworded, as quoted in my previous comment.

The rewording still has the issue. a recording aware UA MUST provide a 
recording indication. UAs without appropriate user interfaces (like 
IVRs, media servers, etc) SHOULD indicate this some other way. SHOULD is 
a lower requirement than MUST.

> assumes a specific relationship the administrative domain of the SRC 

So does "not record everything" include the ability to send no metadata? 
Perhaps the first sentence in 9.1 that says "The SRC MUST send metadata" 
is overstated?

> This is being sorted out in another thread. I agree, something needs 

Understood, I will watch that thread.

> document describes specific security recommendations.²

Could the reader fully understand the security considerations without 
reading 6341? If so, then informational is okay.

> Using the word ³trust" is a slippery slope as well.

The text already uses that word. It says that if the SRS and SRC are in 
the same domain, they have an inherent trust relationship. That's not 
always the case.

> For a UA acting as a

Better to be explicit.

[...]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Jun 2015 14:00:49 -0400

> clause in my user agreement. That seems to qualify under the language

I appreciate your concern. I would be *very* unhappy if a carrier put 
such language in my contract. I can imagine that this could be presented 
as a non-negotiable condition of service, though I consider that to be 
entirely unreasonable. (However, whether the language is there or not, 
in practice that is what the current situation is in the US with CALEA.)

OTOH, there are situations where this is entirely appropriate - the call 
center case, or for stock brokers - there there are requirements to 
record. Certainly in the call center case it would be a problem to 
include an indication of recording in the audio stream to the agent. 
Potentially a call center agent work station could have other means to 
indicate recording. But that would exclude some common existing 
equipment. Also, in the call center case, if there is an indication, 
then there would probably be a preference by management to always 
indicate that calls are being recorded, even if they might not be, so 
that the agent wouldn't know when he was being recorded. Also, this 
overlaps with active listening (by conferencing in a supervisor) that is 
technically (and legally?) distinct from recording and yet has similar 
concerns.

It is unclear here how to balance the concerns. I'm certainly open to 
suggestions about how best to do this.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 24 Jun 2015 04:12:06 +0000

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Tuesday, 23 June 2015 11:30 pm
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Ben Campbell's Discuss on
draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

>technically (and legally?) distinct from recording and yet has similar

My understanding w.r.t Call Centre is the agent is informed that some of
his calls may be recorded for quality monitoring, supervising e.t.c
This could just be a contact clause/via some other means. Now exactly
which calls are being recorded/monitored is something I guess Agents may
not really know.
It is ok in a environment like CallCentre but definitely NOT acceptable
elsewhere.

Ram

---

From: "Dave Higton" <[email-masked]>
Date: Wed, 24 Jun 2015 07:34:21 +0000

On 23 June 2015 19:01 Paul Kyzivat wrote:

>suggestions about how best to do this.

Indication to users that they are being recorded is surely a system level
consideration.  For example, it's perfectly reasonable for a company to
formally inform all its staff of the policy on call recording, and it's usual
for a telephone system to answer all incoming calls with a recorded
message informing the caller that the call will or may be recorded.

I don't think it is reasonable to mandate that a UA must provide the
indication.

It's worth a mention somewhere that informing users is a common
legal requirement and that due consideration must be given to how
that is to be achieved.  But IMHO that's all that SIPREC can say.

Dave

PS My apologies if I've not got the quoting right.  The only tool I
can use here is Outlook.

NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.