Subject: [siprec] Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 02 Mar 2016 03:08:53 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-siprec-metadata-20: 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-metadata/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) In section 10 you have a MUST for integrity and confid,
which is good, but then RECOMMEND S/MIME, which is, I think,
mythical. Wouldn't it be better to reflect reality
(hop-by-hop TLS) and then say what actual security
considerations arise, e.g. who might be on the path and how
can they (mis)behave?

(2) 6.10: Don't you need to say to use UUID version 4 with
random numbers and to not use MAC addresses?  IOW, refer to
RFC4122, Section 4.4 for how to generate UUIDs. 

Note that issues related to both of the above were part
of the discussion that ensued from the secdir review. [1]

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06370.html

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 4, last para: How could an SRC know this and hence
what it's safe to omit?

- 6.9: I would have thought that more precision about
fractional seconds support would be useful here, or else, to
just say that you're limiting to single-second granularity.
Wouldn't doing one or the other be better? Otherwise you
might get different s/w ordering events in different orders
unexpectedly.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 10:23:12 -0500

> RFC4122, Section 4.4 for how to generate UUIDs.

I don't think we want to restrict to the section 4.4 algorithm. SRCs may 
need quite a lot of UUIDs. There is no reason to be using a random 
number generator for each one. And there could be cases where two SRCs 
that are cooperating on recording might want to algorithmically 
synchronize their uuid generation. For both of these cases the 
name-based algorithm can work well. For that to be safe it is only 
necessary that the namespace be unique.

So I would rather not be so proscriptive about *how* the UUIDs are 
generated, as long as they avoid accidental collisions and collisions 
due to malice.

	Thanks,
	Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2016 15:47:36 +0000

On 02/03/16 15:23, Paul Kyzivat wrote:
> number generator for each one. 

Using a good PRNG for this should be fine and is allowed by 4.4.
There's no need to block on /dev/random for this anyway:-)

> And there could be cases where two SRCs

I'd be fine with allowing that too. I think the main thing is
to exclude using MAC addresses. So maybe saying "Follow RFC4122,
Section 4.3 or 4.4" would work?

S.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 11:26:44 -0500

> Section 4.3 or 4.4" would work?

Looking carefully at 4122: IIUC your objection is to using the algorithm 
in section 4.1? So 4.2 and 4.3 are ok. And I would think 4.5 is also ok? 
(But not the NIL UUID.)

If 4.3 is used, does it matter what algorithm is used to create the name 
space ID?

	Thanks,
	Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2016 16:45:00 +0000

Hiya,

(We're spiralling in on precision... :-)

> in section 4.1? So 4.2 and 4.3 are ok. And I would think 4.5 is also ok?

Doesn't 4.2 use the node_id the same way as 4.1?

4.5 also seems fine.

> If 4.3 is used, does it matter what algorithm is used to create the name

I guess it could, e.g. using an AoR might be a bad plan I
suppose, whereas using a DNS name associated with the SRS
could be a good plan, but I'm not sure what implementers
would be likely to use here. If I were to guess, I'd guess
that some name for the SRS would be ok.

Perhaps another way to handle it would be to say "use
4122, sections 4.3, 4.4 or 4.5 but ensure that you don't
use anything potentially personally identifying to
generate the UUIDs, so if you follow 4.3 a name for the
SRS might be a good choice."

That work?

Cheers,
S.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 12:33:55 -0500

> (We're spiralling in on precision... :-)

Yeah. Hopefully it is a converging spiral. :-)

My goal is to be no more restrictive than necessary, and to be as 
concise as possible to achieve that while being clear. Sometimes it is 
hard to find the right balance. More below.

> Doesn't 4.2 use the node_id the same way as 4.1?

My mistake. Section 4 has funny structure. 4.1 isn't one of the 
algorithms. 4.2 is *the* algorithm that uses the MAC.

So 4.2 is bad, 4.3-4.5 are ok.

> SRS might be a good choice."

I don't think it is good to say anything about the *name*. The part that 
obscures it is the name space id, which is another UUID. As long as the 
name space id is good the name can be anything the SRC likes that is 
locally unique.

So perhaps "use 4122, sections 4.3, 4.4 or 4.5 but ensure that you don't
use anything potentially personally identifying to generate the UUIDs, 
so if you follow 4.3 a name space ID generated using 4.2 or 4.5 might be 
a good choice."

Would that be ok?

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 2 Mar 2016 17:51:39 +0000

Hi Stephen,

See inline

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Wednesday, 2 March 2016 at 4:38 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, Brian Rosen <[email-masked]>,
"[email-masked]" <[email-masked]>, Brian Rosen
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20: (with
DISCUSS and COMMENT)

>https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/

Yes. This needs some changes. After the discussions with SecDir we thought
it would be good to refer to Security Consideration section of protocol
draft (section 12 general and 12.1 of
https://tools.ietf.org/html/draft-ietf-siprec-protocol-18#page-38). 12.1
covers the TLS the mutual Authentication and also talk about who else can
be in the path (para 2).

Since the metadata is always going to be carried as a body in the
protocol, all the considerations there are equally applicable here.

With this the proposed text for Security consideration in this draft would
be:

NEW:
The procedures mentioned in security consideration section of
[I-D.ietf-siprec-protocol] MUST be implemented by SRC and SRS
for mutual authentication.
Some implementations may have the SRC choose parts of metadata that
     can be sent to the SRS.  In other cases, SRCs may send metadata that
     is not appropriate for the SRS to record.  Which metadata is actually
     recorded by the SRS must be carefully considered to balance privacy
     concerns with usability.  Implementations MUST control what metadata
     is recorded, and MUST NOT save metadata sent by the SRC that does not
     conform to the recording policy of the SRS.  Metadata in storage
     needs to be provided with a level of security that is comparable to
     that of the recording session.

Would this be better ? Or else we will have to replicate most of the text
from Protocol to here again.

Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 4 Mar 2016 00:00:29 +0000

Hi Stephen,

See inline for some responses to your comments.

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Wednesday, 2 March 2016 at 4:38 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]"

In this case the metadata that need not be conveyed are those that are
carried/derived from SIP headers/SDP. The SRC is a SIP element and always
sends the metadata in a SIP message (which has a SDP body as well). So the
SRC would know what it has sent in SIP/SDP.

>Wouldn't doing one or the other be better?

We are not limiting to single-second. RFC3339 does allow fractional
seconds but its optional. OTOH, the sip Date header only allows
RFC822 time, which doesn't allow fractional seconds.

In many cases the date/time values going in the recording xml document
will be those
from the Date fields in the CS. So we may not be able to mandate SRC to
send fractional seconds.

Regards,
Ram

> Otherwise you

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Mar 2016 14:03:49 +0000

Just bottoming out on this...

> so if you follow 4.3 a name space ID generated using 4.2 or 4.5 might be

Yep, that's fine.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Mar 2016 14:15:59 +0000

Hiya,

> from Protocol to here again.

Yes, that's good, and no I'd not replicate text from the protocol
spec, your reference with a MUST above is fine. (I re-read the
security considerations of the protocol spec, and I think it covers
things well enough.)

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Mar 2016 14:23:17 +0000

Hiya,

(Noting these are non-blocking comments so we don't need
to debate 'em and you should feel free to just proceed...)

> SRC would know what it has sent in SIP/SDP.

Sure, but my question is more about how an SRC can know
what to not send. The text says the SRC can leave stuff
out "if it can be obtained contextually by the SRS" but
I don't know if the SRC can know what the SRS can "obtain
contextually."

> from the Date fields in the CS. So we may not be able to mandate SRC to

Hmm. It still seems to me that specifying some goal for
precision would be better, as otherwise it'll not be clear
how reliably one can re-construct the order of events. But
I guess that might be outweighed by inaccurate clocks on
the various devices so maybe it's good enough as-is.

Cheers,
S.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 7 Mar 2016 12:50:30 +0000

Thanks for closing on this. I will add the below proposed text to the
draft.

Regards,
Ram

-----Original Message-----
From: siprec <[email-masked]> on behalf of Stephen Farrell
<[email-masked]>
Date: Friday, 4 March 2016 at 7:33 PM
To: Paul Kyzivat <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Stephen Farrell's Discuss on
draft-ietf-siprec-metadata-20: (with DISCUSS and COMMENT)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 7 Mar 2016 12:51:14 +0000

Ok. I will add the below text to the security consideration section.

Ram

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Friday, 4 March 2016 at 7:45 PM
To: Cisco Employee <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, Brian Rosen <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20:
(with DISCUSS and COMMENT)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 7 Mar 2016 12:58:49 +0000

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Friday, 4 March 2016 at 7:53 PM
To: Cisco Employee <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>,
Brian Rosen <[email-masked]>
Subject: Re: Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20:
(with DISCUSS and COMMENT)

>I don't know if the SRC can know what the SRS can "obtain

In general any thing that can learnt from SDP carried between SRC to SRS
is not carried again in metadata.
The SRS is expected to parse the SDP read the parameters, also parse the
XML that it received along with SDP and use both of the information
wherever applicable. For e.g; The metadata XML just carry the label
identifier that references a media stream. It points to a media line (m=
line) in SDP.
The SRS is expected to co-relate the label to its properties carried in
SDP. 

I will add some text for this in the section 4 where the current
text(above you pointed out) is there to give examples of what kind of
information can be derived (like the label to SDP properties).

>the various devices so maybe it's good enough as-is.

I will leave the text for this as-is for now.

Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 19 Mar 2016 05:54:50 +0000

Hi Stephen,

I have published a new revision that addresses your DISCUSS and COMMENTS.
Please review and let us know your feedback.

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-metadata-21

Regards,
Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 Mar 2016 13:37:54 -0400

Hi Ram,

This looks good. I saw a couple of nits while reviewing the changes:

* Section 6.1.2:

    CSs and CS-Groups are optional to accommodate persistent recording,
    where there may sometimes be none.  ...

That statement is correct WRT CS-Groups, but not CSs. CSs have much more 
relevance, and aren't optional for recording. So I would simply omit 
"CSs and " from the above.

* Section 6.9:

Your global change from <...> to '...' notation seems to have missed 
this section.

	Thanks,
	Paul

On 3/19/16 1:54 AM, Ram Mohan R (rmohanr) wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 21 Mar 2016 03:29:19 +0000

Paul,

Thanks for the review. I will fix the below nits.

Regards,
Ram

-----Original Message-----
From: siprec <[email-masked]> on behalf of Paul Kyzivat
<[email-masked]>
Date: Sunday, 20 March 2016 at 11:07 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Stephen Farrell's Discuss on
draft-ietf-siprec-metadata-20: (with DISCUSS and COMMENT)

>>>>>       is recorded, and MUST NOT save metadata sent by the SRC that
>>>>>does
>>>>> not
>>>>>       needs to be provided with a level of security that is
>>>>>comparable
>>>>> to

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 21 Mar 2016 14:59:34 +0000

Paul,

One comment please see inline

-----Original Message-----

>"CSs and " from the above.

Above statement is for persistent recording case where the RS may be setup
between SRC (say endpoint like voip phone) and SRS even before any CS is
setup.
Once CS is setup, the persistent RS dialog will be used to record the RS
rather than setting up another RS. This statement is to indicate the same.

Regards,
Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Mar 2016 11:32:23 -0400

> rather than setting up another RS. This statement is to indicate the same.

My point was that CSs are not optional in the same way that CSGs are.

They are optional in the sense that you can send a <recording> element 
that has none. But ultimately it is CSs that are the primary thing being 
recorded. And of course communication sessions can exist without recordings.

So maybe this just needs a few more words.

But this isn't a big deal. I won't be bothered if you leave it as-is.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:10:57 +0000

Paul,

Please see inline

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Monday, 21 March 2016 at 9:02 PM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Stephen Farrell's Discuss on

>that has none

That¹s correct. I was trying to convey this information through the above
statement. Perhaps it is not clear.
How about re-wording the sentence to some thing like this:

EXISTING:
CS and CS-Groups are optional to accommodate persistent recording,
     Where there may sometimes be none.A persistent RS is a SIP dialog
   that is setup between SRC to SRS even before any CS is setupŠ.......

NEW:
Zero instances of CS and CS-Group in a recording element is allowed to
accommodate persistent recording scenarios.
A persistent RS is a SIP dialog that is setup between SRC to SRS even
before any CS is setupŠ.......

Does this look better ?

Regards,
Ram

>. But ultimately it is CSs that are the primary thing being
>recorded.
>And of course communication sessions can exist without recordings.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Mar 2016 13:04:29 -0400

That is better.

	Thanks,
	Paul