Subject: Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Sep 2014 11:23:33 +0000

Hi,

Below are some comments on version -07:

General:
-----------

-	The document claims that the Session-ID is true end-to-end, because it will not be modified by intermediaries. But, there is no text on how that is achieved. Obviously, we cannot guarantee that it won't happen (even if there is "MUST NOT" wording), but I think you need to have some text which talks about the reasons why Call-IDs are modified, and why those reasons don't apply to the Session-ID.
-	The document talks about interoperability with H.323, but nowhere is there any text showing that both protocols now use the same format for the session id.

Section 5:
-------------

I suggest to re-name the section name to "SIP Session-ID Header Field"

You need to split the text into subsections. 

Something like:

5.1 General
5.2 Syntax
5.3 UA Behavior
5.3.1 UAC Behavior
5.3.2 UAS Behavior
5.4 Proxy Behavior
5.5 B2BUA Behavior

Section 6:
-------------

The text in this section should go into UA Behavior.

Section 7:
-------------

The text in this section should go into Proxy Behavior and B2BUA Behavior.

I do have more comments on section 6 and 7, but I'd like to see the restructuring (as suggested in my comment on section 5) before giving those, because some may go away.

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 05 Sep 2014 01:00:55 +0000

Christer,

Thanks for the feedback.  I'll try to address each point:

>General:
>-----------
>
>- The document claims that the Session-ID is true end-to-end, because 
>it will not be modified by intermediaries. But, there is no text on how 
>that is achieved. Obviously, we cannot guarantee that it won't happen 
>(even if there is "MUST NOT" wording), but I think you need to have 
>some text which talks about the reasons why Call-IDs are modified, and 
>why those reasons don't apply to the Session-ID.

In the introduction, we specify two examples of why the current Call-ID 
values are not suitable, including the fact that SBCs change the values 
as they go through.  We also mention protocol interworking as an issue.

I'm not sure what we can write into the document to ensure that devices 
do not change the Session-ID.  It's certainly possible, just as the 
Call-ID is changed.  However, changing the session ID would mean the 
device is not compliant with the specification.  That could happen on 
purpose (violating the spec) or it could happen because there is an 
older device that does not know the header and simply discards it.  
That's certainly true of any new protocol element one might introduce.  
If you think we should say something explicit about this, where should 
we say it and how should we phrase it?

>- The document talks about interoperability with H.323, but nowhere is 
>there any text showing that both protocols now use the same format for 
>the session id.

That is true, though RFC 7602 (requirements) mentions that a parallel 
effort is taking place in SG16.  In fact, here's the draft text: 
http://ftp3.itu.int/av-arch/avc-site/2013-2016/1406_Sap/Draft-H.460.SessionID.zip.

That text was accepted as the baseline text for an extension to H.323.  
However, it's not something we can reference right now.  Do you feel we 
should re-state the fact that the ITU is undertaking the same work for 
H.323, or do you think leaving that fact in the requirements document is 
enough?

>Section 5:

I think renaming this is a good idea.  Given the whole document is about 
SIP, I think we can get rid of that, too.  I think "The Session-ID 
Header Field" would be sufficient.

However, I think making the structural changes is probably unnecessary.  
Splitting UAS and UAC behavior, for example, will result in a lot of 
redundant text.   The same is said of a SIP proxy or B2BUA.  Both are 
intermediaries and should operate in the same way. We considered that 
arrangement before, but felt it was simpler to just describe endpoint 
behavior and intermediary behavior as we have it.

>I do have more comments on section 6 and 7, but I'd like to see the 
>restructuring (as suggested in my comment on section 5) before giving 
>those, because some may go away.
OK, let's talk about those.  I just submitted -08 with a few minor 
changes.

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Sep 2014 10:21:34 +0000

Hi Paul,

Comments inline.

> In the introduction, we specify two examples of why the current Call-ID values are not suitable, including the fact that SBCs change the values as they go through. 

Sure, but how does that ensure that SBCs won't do the same for the Session-ID? 

> We also mention protocol interworking as an issue.

Sure. But, as I said below, the document doesn't show that. But, more on that below.

>I'm not sure what we can write into the document to ensure that devices do not change the Session-ID.  It's certainly possible, just as the Call-ID is changed.  
>However, changing the session ID would mean the device is not compliant with the specification.  

You could say that about lots of things, but that doesn't prevent SBCs to do "non-compliant" things :)

You need to give people technical reasons why they reasons they modify Call-ID don't apply to Session-ID. "Because the draft says so" is not such reason :)

>That could happen on purpose (violating the spec) or it could happen because there is an older device that does not know the header and simply discards it.  
>If you think we should say something explicit about this, where should we say it and how should we phrase it?

For example, one reason is that, traditionally, the Call-ID often contains the IP address of the endpoint, which is not the case for Session-ID. So, there is no need for the SBC to modify the Session-ID for privacy reasons.

Another example is that the Call-ID is part of the SIP session identifier, which is not the case for Session-ID. So, even if people want to use different SIP sessions on each side of an SBC, that does not require a change to Session-ID.

Hadriel have had a number of reasons, so if he is still following this work then he can perhaps give more input.

---------------

> That is true, though RFC 7602 (requirements) mentions that a parallel effort is taking place in SG16.  In fact, here's the draft text: 
> However, it's not something we can reference right now.  Do you feel we should re-state the fact that the ITU is undertaking the same work for H.323, or do you think leaving that fact in the requirements document is enough?

IF we are going to talk about H.323, and interoperability, we have to show it.

And, we can always finalize the other parts of the draft, and move it to the RFC editor's queue, where it will be held while waiting for the ITU work to finalize.

When do you think ITU will have something we can reference? 

---------------

> I think renaming this is a good idea.  Given the whole document is about SIP, I think we can get rid of that, too.  I think "The Session-ID Header Field" would be sufficient.

Agree.

>redundant text.

Such text should go into a "General" section.

E.g.

5.3 UA Behavior
5.3.1 General
5.3.2 UAC Behavior
5.3.3 UAS Behavior
---

>The same is said of a SIP proxy or B2BUA.  Both are intermediaries and should operate in the same way. 

Is that really true? What about the PBX case where you have an endpoint joining sessions together etc?

> We considered that arrangement before, but felt it was simpler to just describe endpoint behavior and intermediary behavior as we have it.

Then you should call the section "Proxy Behavior". "Intermediary" is a very confusing word.

> OK, let's talk about those.  I just submitted -08 with a few minor changes.

I'll take a look later :)

Regards,

Christer

---

From: James Polk <[email-masked]>
Date: Wed, 10 Sep 2014 15:33:15 -0500

Christer

Thanks for the review

but... although most SIP Header definitions have taken something like 
the above form,

a) the UAS section would only comprise exactly 3 sentences, conveying 
in essence:
    1 - the UA would receive a SIP request.
    2 - the UA, acting as a UAS for in this transaction, would 
generate a type 4 and type 5 UUID according to RFC 4122 (mirroring 
the type in the SIP request).
    3 - copy the value exactly of the UUID into a new header 
parameter "remote".
    4 - send the SIP response whichever it might be in the response 
(meaning, now, the SIP message will have 2 UUIDs for the remainder of 
this dialog).

and

b) all SIP servers in the signaling SHOULD do the same thing, 
although we can never be sure 'stateless' proxies will do anything 
(with regard to this header); at the same time, we cannot be sure, no 
matter how much we threaten, that B2BUA or SBCs will not muck with this header.

This makes any conventional "Section 5" pretty pointless IMO

thoughts?

James

>restructuring (as suggested in my comment on section 5) before 
>giving those, because some may go away.
>
>Regards,
>
>Christer
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 12 Sep 2014 20:13:30 +0000

Christer,

>You need to give people technical reasons why they reasons they modify 
>Call-ID don't apply to Session-ID. "Because the draft says so" is not 
>such reason :)

How about we modify the first paragraph of Section 7 to read this way:

"In order to ensure the integrity of the end-to-end session identifier, 
intermediaries, such as proxies or session border controllers, MUST NOT 
alter the UUID values found in the Session-ID header, except as 
described in this section."

Would that help or do you think we need something else?

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Sep 2014 20:26:34 +0000

Hi Paul,

>"In order to ensure the integrity of the end-to-end session identifier, intermediaries, such as proxies >or session border controllers, MUST NOT alter the UUID values found in the Session-ID header, >except as described in this section."
>

Unfortunately I don't think it will help.

No matter what the spec says, intermediaries will modify the header field if they see a need to do so. You need to describe why such need does not occur for the Session-ID header field.

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 12 Sep 2014 20:48:03 +0000

Christer,

>>"In order to ensure the integrity of the end-to-end session 
>>identifier, intermediaries, such as proxies >or session border 
>>controllers, MUST NOT alter the UUID values found in the Session-ID 
>>header, >except as described in this section."
>>
>No matter what the spec says, intermediaries will modify the header 
>field if they see a need to do so. You need to describe why such need 
>does not occur for the Session-ID header field.
>

The reasons the Call-ID or other headers were changed at the SBC was 
because they revealed specific information about the user, including 
device information, user identifiers, etc.  The Session Identifier is 
defined to be random (per section 4.1 of the solution spec).  This is 
also spelled out in the referenced requirements document.

Given that, what more do we really need to say here?  I'm happy to 
modify that sentence in some way that helps, but I don't want to make it 
so complex that it gets in the way of the procedures.  Maybe we need 
something in the security considerations section?

I think I understand roughly what you're shooting for, but I'm not sure 
what we can add that doesn't confuse the text, replicate text from the 
requirements document, etc.  Can you suggest some text and where to put 
it?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 12 Sep 2014 20:53:42 +0000

Christer,

Taking another point...

>And, we can always finalize the other parts of the draft, and move it 
>to the RFC editor's queue, where it will be held while waiting for the 
>ITU work to finalize.
>

The ITU should have something we can reference in February 2015 or 
within 60 days following.  I suggest we add a second paragraph to 
Section 3 that reads:

"As mentioned in section 6.1 of RFC 7206, the ITU-T undertook a parallel 
effort to define compatible procedures for an H.323 Session Identifier. 
They are documented in Recommendation ITU-T H.460.27."

Sound OK?

Paul

PS - Note the number of the ITU-T document is not firm right now, but we 
can hold publication until it is.  This likely will be the assignment, 
though.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Sep 2014 21:01:04 +0000

Hi,

>>>>You need to give people technical reasons why they reasons they 
>>>>modify Call-ID don't apply to Session-ID. "Because the draft says so" 
>>>>is not such reason :)
>>>
> The reasons the Call-ID or other headers were changed at the SBC was because they revealed 
> specific information about the user, including device information, user identifiers, etc.  The Session > Identifier is defined to be random (per section 4.1 of the solution spec).  This is also spelled out in 
> the referenced requirements document.

Nobody is going to read the requirements document - you need to describe it in THIS document.

>Given that, what more do we really need to say here?  I'm happy to modify that sentence in some >way that helps, but I don't want to make it so complex that it gets in the way of the procedures.  >Maybe we need something in the security considerations section?
>
> I think I understand roughly what you're shooting for, but I'm not sure what we can add that 
> doesn't confuse the text, replicate text from the requirements document, etc.  Can you suggest 
> some text and where to put it?

I think the text above, about revealing sensitive information, is good :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Sep 2014 21:03:45 +0000

Hi,

> The ITU should have something we can reference in February 2015 or within 60 days following.  I 
> suggest we add a second paragraph to Section 3 that reads:
>
> "As mentioned in section 6.1 of RFC 7206, the ITU-T undertook a parallel effort to define 
> compatible procedures for an H.323 Session Identifier. 

I can live with that.

>PS - Note the number of the ITU-T document is not firm right now, but we can hold publication until >it is.  This likely will be the assignment, though.

Ok.

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 12 Sep 2014 21:09:09 +0000

Christer,

------ Original Message ------
From: "Christer Holmberg" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "Adam Gensler (agensler)" 
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 9/12/2014 5:01:04 PM
Subject: RE: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

>>because they revealed
>>  specific information about the user, including device information, 
>>user identifiers, etc. The Session > Identifier is defined to be 
>>random (per section 4.1 of the solution spec). This is also spelled 
>>out in

Oh, I wasted time on a document nobody will read?!?! :-)

>>modify that sentence in some >way that helps, but I don't want to make 
>>it so complex that it gets in the way of the procedures. >Maybe we 
>>need something in the security considerations section?
>>

How about this?

"In consideration of the fact that the Session Identifier is constructed 
in such a way as to not reveal any personal, device, or domain 
identifying information and in order to ensure the integrity of the 
end-to-end session identifier, intermediaries, such as proxies or 
session border controllers, MUST NOT alter the UUID values found in the 
Session-ID header, except as described in this section."

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Sep 2014 10:18:55 +0000

Hi Paul,

> Oh, I wasted time on a document nobody will read?!?! :-)

In the INSIPID WG we obviously read/used it as input for the Session-ID solution :)

> Session-ID header, except as described in this section."

I would use different wording. Something like:

"The call-id often reveal personal, device, domain or other sensitive information associated
with an end-user, which is why intermediaries, such as proxies and session border
controllers alter the call-id. In order to ensure the integrity of the end-to-end
session identifier, it is constructed in a way which does not reveal such information,
removing the need for intermediaries to alter it (except as described in this section)."

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 14 Sep 2014 20:52:29 +0000

Christer,

>removing the need for intermediaries to alter it (except as described 

This is OK, though it removes the "MUST NOT" in the paragraph that I 
think is important.  How about this slight variation?

"The Call-ID often reveal personal, device, domain or other sensitive 
information associated with a user, which is why intermediaries, such as 
proxies and session border controllers, sometimes alter the Call-ID.  In 
order to ensure the integrity of the end-to-end Session Identifier, it 
is constructed in a way which does not reveal such information, removing 
the need for intermediaries to alter it.  As such, intermediaries MUST 
NOT alter the UUID values found in the Session-ID header, except as 
described in this section."

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Sep 2014 06:02:41 +0000

Hi Paul,

If you want to keep the "MUST NOT" there, I am ok with that :)

Regards,

Christer

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: 14 September 2014 23:52
To: Christer Holmberg; Adam Gensler (agensler)
Cc: [email-masked]
Subject: Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

Christer,

>"The call-id often reveal personal, device, domain or other sensitive 
>information associated with an end-user, which is why intermediaries, 
>such as proxies and session border controllers alter the call-id. In 
>order to ensure the integrity of the end-to-end session identifier, it 
>is constructed in a way which does not reveal such information, 

This is OK, though it removes the "MUST NOT" in the paragraph that I think is important.  How about this slight variation?

"The Call-ID often reveal personal, device, domain or other sensitive information associated with a user, which is why intermediaries, such as proxies and session border controllers, sometimes alter the Call-ID.  In order to ensure the integrity of the end-to-end Session Identifier, it is constructed in a way which does not reveal such information, removing the need for intermediaries to alter it.  As such, intermediaries MUST NOT alter the UUID values found in the Session-ID header, except as described in this section."

Paul