Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-23.txt

From: [email-masked]
Date: Thu, 23 Jun 2016 21:37:51 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the INtermediary-safe SIP session ID of the IETF.

        Title           : End-to-End Session Identification in IP-Based Multimedia Communication Networks 
        Authors         : Paul E. Jones
                          Gonzalo Salgueiro
                          Chris Pearce
                          Paul Giralt
	Filename        : draft-ietf-insipid-session-id-23.txt
	Pages           : 40
	Date            : 2016-06-23

Abstract:
   This document describes an end-to-end Session Identifier for use in
   IP-based multimedia communication systems that enables endpoints,
   intermediary devices, and management systems to identify a session
   end-to-end, associate multiple endpoints with a given multipoint
   conference, track communication sessions when they are redirected,
   and associate one or more media flows with a given communication
   session.  While the identifier is intended to work across multiple
   protocols, this document describes its usage in SIP.

   This document also describes a backwards compatibility mechanism for
   an existing session identifier implementation (RFC 7329) that is
   sufficiently different from the procedures defined in this document.

   This document obsoletes RFC 7329.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-insipid-session-id-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-23

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Fri, 24 Jun 2016 15:48:25 +0000

Ben,

I’m hoping this version of the draft addresses your concerns. Please let me know your thoughts on the latest changes.

Thanks,
-Paul

> On Jun 24, 2016, at 12:37 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 27 Jun 2016 16:57:25 -0500

Hi Paul,

That version mostly addresses my concerns. I have a couple of comments 
about the updated section 12:

- The text states that, since the session-IDs must not contain device or 
user identifying information, they have no privacy considerations. That 
sort of statement is a bit of a red flag during IESG review. In 
particular, it would be good to also say something about the use of a 
session-ID as a persistent identifier to correlate across session. As it 
is, 4.2 says they generate a new, previously unused UUID. Is there any 
normative text about reusing the UUID for more than one "session"? (Not 
counting the text about transfers, etc.).

- The statement that session-id "MUST NOT be used for billing purposes" 
will probably draw objections. I suggest that be changed ot "is not 
appropriate for billing purposes." (Not really new text, but the 
revisions drew my attention to it.)

Thanks!

Ben.

On 24 Jun 2016, at 10:48, Paul Giralt (pgiralt) wrote:

> Ben,
>
> I’m hoping this version of the draft addresses your concerns. Please 
> let me know your thoughts on the latest changes.
>
> Thanks,
> -Paul
>
>>        Title           : End-to-End Session Identification in 
>> IP-Based Multimedia Communication Networks
>>        Authors         : Paul E. Jones
>>                          Gonzalo Salgueiro
>>                          Chris Pearce
>>                          Paul Giralt

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Tue, 28 Jun 2016 20:06:21 +0000

Ben,

Thanks for the guidance. See inline…

> - The text states that, since the session-IDs must not contain device or user identifying information, they have no privacy considerations. That sort of statement is a bit of a red flag during IESG review. In particular, it would be good to also say something about the use of a session-ID as a persistent identifier to correlate across session.

Ok - I will fix this.

> As it is, 4.2 says they generate a new, previously unused UUID. Is there any normative text about reusing the UUID for more than one "session"? (Not counting the text about transfers, etc.).

The only the only text  is Section 6 which describes the conditions under which the UUID is maintained. The transfer / redirect cases are the only time a UUID is “reused” and even then, it’s not really being reused for a different “session” but that depends on what you fine as being a session. That may be the issue - that we don’t clearly define what a session is.

I added an additional line at the end of paragraph 1 in section 4.2 to highlight the persistence of the UUID mentioned in Section 6:

	Section 6 describes how the UUIDs selected by the source and destination UAs persist
        for the duration of the session.

Not sure if that’s necessary, but I figured it can’t hurt.

Would it help if we give a clearer definition of what a “session” means in the context of this specification?

> 
> - The statement that session-id "MUST NOT be used for billing purposes" will probably draw objections. I suggest that be changed ot "is not appropriate for billing purposes." (Not really new text, but the revisions drew my attention to it.)
> 

Ok - fixed.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 29 Jun 2016 14:56:08 -0500

On 28 Jun 2016, at 15:06, Paul Giralt (pgiralt) wrote:

[...]

>> As it is, 4.2 says they generate a new, previously unused UUID. Is 
>> there any normative text about reusing the UUID for more than one 
>> "session"? (Not counting the text about transfers, etc.).
>
>
>
> The only the only text  is Section 6 which describes the conditions 
> under which the UUID is maintained. The transfer / redirect cases are 
> the only time a UUID is “reused” and even then, it’s not really 
> being reused for a different “session” but that depends on what 
> you fine as being a session. That may be the issue - that we don’t 
> clearly define what a session is.

That text talks about when the UUID MUST NOT change. I'm looking for 
text that says a UUID value MUST NOT be reused across multiple 
"sessions" (as sessions are defined in this draft.) The point is to 
avoid an accidentally persistent identifier that could be used to track 
user/UA activity across multiple sessions.

>
> I added an additional line at the end of paragraph 1 in section 4.2 to 
> highlight the persistence of the UUID mentioned in Section 6:
>
> Would it help if we give a clearer definition of what a “session” 
> means in the context of this specification?

While additional clarity rarely hurts, I did not find the concept of 
session in the draft to be particularly confusing, even if it did go 
beyond conventional ideas of what constitutes a session in SIP.

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 29 Jun 2016 20:10:04 +0000

> 
> That text talks about when the UUID MUST NOT change. I'm looking for text that says a UUID value MUST NOT be reused across multiple "sessions" (as sessions are defined in this draft.) The point is to avoid an accidentally persistent identifier that could be used to track user/UA activity across multiple sessions.

I see where you are coming from now. I hadn’t payed attention to the fact that the text in 4.2 is not normative. Currently the section reads:

	The SIP User Agent (UA) initiating a new session by transmitting a SIP
         request ("Alice"), i.e., a User Agent Client (UAC), will create a new,
         previously unused, UUID and transmit that to the ultimate destination UA
         ("Bob").  Likewise, the destination UA ("Bob"), i.e., a User Agent Server (UAS),
         will create a UUID and transmit that to the first UA ("Alice").

If I just change the “will” to MUST and expand on the UAS also having to create a previously-unused UUID like below, does this address the concern?

	The SIP User Agent (UA) initiating a new session by transmitting a SIP
         request ("Alice"), i.e., a User Agent Client (UAC), MUST create a new,
         previously unused, UUID and transmit that to the ultimate destination UA
         ("Bob").  Likewise, the destination UA ("Bob"), i.e., a User Agent Server (UAS),
         MUST create a new, previously unused, UUID and transmit that to the
	first UA ("Alice").

Alternatively, I could add some normative text in Section 6 for endpoint behavior, but I think just modifying the above should address the concern. Please let me know your thoughts.

-Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 29 Jun 2016 15:12:14 -0500

On 29 Jun 2016, at 15:10, Paul Giralt (pgiralt) wrote:

>> avoid an accidentally persistent identifier that could be used to 
>> track user/UA activity across multiple sessions.
>
> I see where you are coming from now. I hadn’t payed attention to the 
> fact that the text in 4.2 is not normative. Currently the section 
> reads:
>
> If I just change the “will” to MUST and expand on the UAS also 
> having to create a previously-unused UUID like below, does this 
> address the concern?
>
> Alternatively, I could add some normative text in Section 6 for 
> endpoint behavior, but I think just modifying the above should address 
> the concern. Please let me know your thoughts.
>
> -Paul

That, plus a sentence or two in the security considerations section 
talking about how that helps avoid cross-session persistent identifiers, 
would work for me.

Thanks!

Ben.

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 29 Jun 2016 20:36:39 +0000

> On Jun 29, 2016, at 4:12 PM, Ben Campbell <[email-masked]> wrote:
> 
> That, plus a sentence or two in the security considerations section talking about how that helps avoid cross-session persistent identifiers, would work for me.
> 
> Thanks!
> 
> Ben.

Perfect. Will update with the other changes and push out a new update.

-Paul