Subject: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22

From: "Ben Campbell" <[email-masked]>
Date: Sat, 14 May 2016 19:46:42 -0500

Hi,

This is my AD Evaluation of draft-ietf-insipid-session-id-22. I have a
number of comments, and think that at least the "substantive" comments
should be addressed prior to IETF last call.

Thanks!

Ben.

------------- Substantive Comments:

- Abstract: The abstract makes it sound like the draft is
multi-protocol. It's not, it's SIP specific. I recognize the idea is
that the syntax could be used across signaling protocols, but this
particular draft only defines how to do so for SIP. Please clarify.

- General

- 4.1, 2nd paragraph: Why is the requirement for version 4 or 5 UUIDs
only a SHOULD? It seems like we should really avoid any sort of
persistent identifies in the UUID. If we really need the SHOULD, please
describe when it might be reasonable to choose otherwise.

- 4.2, 2nd paragraph: "such as when a UA first initiates a SIP request,"

Should that be a SIP INVITE request, or SIP dialog-initiating request?

-- 2nd to last paragraph: Is there a normative statement elsewhere than
devices other than conference-focuses MUST NOT reuse UUIDs? (Also, the
MUST in this paragraph belongs with the section on MDUs. If this text
means to simply point out that the MDU section has this requirement,
then please state it descriptively here.)

-- last paragraph: I'm a bit uncomfortable with making storage
completely out of scope, due to the potential "information-at-rest"
security or privacy implications. (I note that RFC7206 cites 6872 for
this purpose).

- 6, paragraph 8: Has the working group discussed the privacy
implications of requiring an endpoint to keep the same UUID after a
redirect, refer, or INVITE-with-replaces? It may be that the peer and
intermediaries already know the source of the 2nd dialog is the same
that of the first, but I think it's a topic that needs some mention in
the text.

-- paragraph 10: Both the MAY and MUST seem incorrect here. The MAY is a
statement of fact, and the MUST is a description of rules elsewhere in
the draft. I suggest using descriptive language for both.

-7, first paragraph: Does the assumption of no "special treatment" means
the intermediary  passing the session-id unchanged? Removes it? Either?

-- 4th paragraph: What happens when a B2BUA that does not implement
session-id aggregates responses? If it passes through the peer UUIDs
unchanged, does anything break? Can the UAC be misled about the UUID of
the resulting peer?

-- 3rd paragraph from end: I'm confused by "A non- redirected or
rejected response", since responses neither get redirected or rejected.
Do you mean a redirection response or a rejection response? (Perhaps
using response code classes would be more clear.)

"MUST replace its own UUID" - In what message(s)?

-- 2nd to last paragraph: Why are the SHOULDs not MUSTs? Can you
describe situations in which one might reasonably not follow the
SHOULDs?

-- last paragraph: The first "MAY" seems like a statement of fact. Is
the 2nd MAY appropriate? That is, intermediary allowed to _not_ do this,
and let endpoints get out of sync?

-8, last paragraph: Why is the SHOULD not a MUST? When might one
reasonably not follow it?

-9, 2nd paragraph: Does this assume that the conference is new to each
subsequent MCU? That is, one would never use this approach to bridge two
existing conferences that already have their own UUIDs?

- 10.3: Why doesn't the b2bua send a re-invite to update the uuid as in
the next example?

- 10.5: Please don't use the name of a trademarked, commercial service
in an RFC. Can you recast this as a "web-based conference service"?

Also, this should be clarified to be one of many ways to implement this
use case, not necessarily a preferred way. (For example,  endpoints
might initiate the INVITE requests toward the focus.)

- 10.7, first bullet: It seems highly unlikely that a 3pcc server would
not be dialog stateful.

- 11: This section creates MUST level requirements for an implementation
to be backwards compatible with a pre-standard, proprietary version.
That seems to be a stretch. Did the working group really intend that an
implementation could not choose not to implement this section?

-- 4th bullet: Wny isn't the presence or absence of remote-uuid
sufficient for responses?

-- 5th bullet: This seems out of place; it's about non-compliant
implementations of this document, not about backwards compatibility.

- 6th bullet: Why would an "old" implementation include "remote-uuid" at
all?

- 12, first paragraph: The MUST here seems to conflict with the previous
SHOULD about using UUID versions other than 4 or 5. (see previous
comment).

-- 3rd paragraph: Is there an impact if something tampers with or lies
about session-Id values?

- 15: Thank you for including this.

Editorial Comments and Nits:

-1, first paragraph: Please expand SIP on first mention.

- 4.2, 4th paragraph: Please expand PBX on first mention.

-- 2nd to last paragraph: This referes to conference focus, but most of
the relevant section discusses MDUs. Please use consistent terms.
(either may be okay, but "focus" probably better captures the signaling
vs media role.)

-6, paragraph 9: What is meant by "negatively affect"? Is this allowed
to affect the session in neutral or positive ways?

-- paragraph 11: Consider s/"MUST take care to ensure"/"MUST ensure".
The "take care" part softens the message.

-- 2nd to last paragraph: Redundant normative statements. Consider
making the first one descriptive, since the second is the more precise
of the two. (This pattern repeats in section 7 paragraph 7)

- 7, 2nd paragraph: "which is why intermediaries" I think that's one
reason why. There are likely others.

-- 7th paragraph: "If an intermediary receives a SIP message without a
Session-ID header field or valid header field value..."

Does this mean either without session-id, or with session-Id but without
a valid value? (As worded, the second part reads like it means without
any valid header fields, but that doesn't make sense.)

-8, first paragraph: This seems redundant to previous sections.

10.1, paragraph before SIP detail: It's not really complete if you omit
stuff :-)

10.3: There's no description of the initial re-invite.

11, paragraph 5: It's not clear what "that" refers to.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 May 2016 14:57:28 -0500

Authors, any thoughts on these?

Thanks!

Ben.

On 14 May 2016, at 19:46, Ben Campbell wrote:

> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 May 2016 20:10:40 +0000

We've been formulating a reply.  Coordination, time, etc.  But, a reply 
is coming very soon.

Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 May 2016 15:26:17 -0500

Okay, thanks!

Ben.

On 25 May 2016, at 15:10, Paul E. Jones wrote:

> We've been formulating a reply.  Coordination, time, etc.  But, a 
> reply is coming very soon.
>
> Paul
>

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 25 May 2016 20:28:27 +0000

Ben,

Sorry for not replying earlier. I’m almost done with replies to all your questions. Should have a formal reply within a couple of days.

-Paul

> On May 25, 2016, at 3:57 PM, Ben Campbell <[email-masked]> wrote:
>

---

From: Paul Giralt <[email-masked]>
Date: Mon, 30 May 2016 23:27:42 -0400

Ben,

Thank you for your detailed evaluation. Here are some replies to your comments. I welcome WG feedback as well.

> particular draft only defines how to do so for SIP. Please clarify.

[PG] While the draft is SIP-specific, the Session Identifier defined in the draft is designed to be multi-protocol (e.g. the H.323 implementation described in H.460.27). If you feel we should be more clear that the document is SIP-specific, but the identifier is designed to be multi-protocol, I can modify.

> describe when it might be reasonable to choose otherwise.

[PG] The WG agreed on this because of existing endpoints that might want to implement Session-ID but are currently generating other identifiers using other mechanisms such as using the device MAC address. This statement clearly contradicts Section 12 as you pointed out below, so one of the two needs to change. I welcome WG feedback as to which direction would be best. I tend to agree that this should be a MUST and we should make all endpoints use version 4 or 5. Then again, even if an endpoint did not conform to this, everything would still work fine.

> Should that be a SIP INVITE request, or SIP dialog-initiating request?

[PG] Cloud be any dialog-initiating request.

> then please state it descriptively here.)

[PG] There does not appear to be a normative statement elsewhere, but I agree there probably should be for the sake of clarity. It’s implied in section 4 and 6 when we talk about constructing a UUID for a new session, but could be called out explicitly.

> security or privacy implications. (I note that RFC7206 cites 6872 for

[PG] In looking at 6872  we could site it here as well; however, if the Session-ID is obscured in logs at res, it defeat the whole purpose of having the Session-ID in the first place as you would not be able to use it for troubleshooting. 6872 doesn’t really seem to mandate much of anything and just has a lot of SHOULDs. If you feel strongly on this, we could put a note to 6872 and highlight the fact that Session-ID should be maintained in logs at rest to be effectively used as a troubleshooting tool.

> that of the first, but I think it's a topic that needs some mention in

[PG] Yes, the privacy implications have been discussed at length. The whole point of the Session ID to allow a call to be tracked. Yes, it can open privacy concerns, since intermediaries can potentially figure out who has been talking to whom and for how long but this is not significantly different than looking at SIP signaling itself. If we do not mandate the same UUID in the situations described above, you end up losing the relationship between the two call legs which again defeats the purpose of having the Session-ID in the first place.

> the draft. I suggest using descriptive language for both.

[PG] I believe the first MUST needs to stay, but agree that the second MAY and MUST should use descriptive language. I will correct to:

   An endpoint MUST assume that the UUID value of the peer endpoint may
   change at any time due to service interactions.  Section 8 discusses
   how endpoints must handle remote UUID changes.

> the intermediary  passing the session-id unchanged? Removes it? Either?

[PG] It could be either depending on what the particular intermediary does with headers it does not understand. We should assume it could be either.

> unchanged, does anything break? Can the UAC be misled about the UUID of

[PG] The UAC should be able to handle this, although there is a potential for out of order messages to cause the UAC to be using a remote UUID that is out of sync, however even this condition should sort itself out.

> using response code classes would be more clear.)

[PG] Yes, this should have read “redirection response or rejection response. Will change to response code classes to make more clear.

> "MUST replace its own UUID" - In what message(s)?

[PG] The example cited is the best explanation, but I agree it’s not clear in the text. I will add some text here to clarify.

> describe situations in which one might reasonably not follow the

[PG] I can’t find any reason for the first SHOULD and think it should probably be a MUST. The second SHOULD is related to other comments below about whether or not an intermediary is required to update other participants in a session if it knows that the participant has an out of sync Session-ID. I’m inclined to make this a MUST as well, however I’ve been told there was some feedback from the WG that some might not want to generate additional SIP signaling for the sole purpose of updating a Session-ID.

Is there any WG opinion as to why this should remain a SHOULD instead of a MUST?

> and let endpoints get out of sync?

[PG] The first MAY should be may. The second is related to the previous comment. If we allow intermediaries to not update a participant when the Session-ID changes, then this statement is accurate (so currently the draft is consistent), however if we change the above SHOULD to a MUST, then this must change as well.

> reasonably not follow it?

[PG] This is also related to the above two comments.

> existing conferences that already have their own UUIDs?

[PG] Yes, this assumes the conference is new to each subsequent MCU. The case of two existing conferences is not addressed in the draft.

> - 10.3: Why doesn't the b2bua send a re-invite to update the uuid as in

[PG] This again goes back to the fact that updating the UUID is currently optional. That said, we do say that intermediaries SHOULD update the UUID and regardless of what decision is made regarding the mandate to update the UUID, I agree this example should still include the update as a best-practice, so I will modify regardless.

> in an RFC. Can you recast this as a "web-based conference service”?

[PG] Totally agree. Will change this.

> might initiate the INVITE requests toward the focus.)

[PG] Ok. I will clarify.

> - 10.7, first bullet: It seems highly unlikely that a 3pcc server would

[PG] I agree, but any harm in leaving as is? Are we just stating the obvious and we can leave it out entirely?

> implementation could not choose not to implement this section?

[PG] Yes, this was the intention. The pre-standard version is a bit more than just proprietary. It is my understanding that the pre-standard version is included as part of the 3GPP Release 9 specification and there are 4-5 million devices that currently implement that version. The WG felt it was important enough to mandate interoperability.

> sufficient for responses?

[PG] Great question. Some implementations of the pre-standard version would blindly copy the contents of the request’s Session-ID header into the response, so if they were to receive a standard version that contains the remote-uuid, they would echo it back. This is to deal with this possibility.

> implementations of this document, not about backwards compatibility.

[PG] Yes, that’s true. Let me find another place to put it.

> - 6th bullet: Why would an "old" implementation include "remote-uuid" at

[PG] As mentioned above, only in the case where it’s blindly reflecting the received Session-ID header.

> SHOULD about using UUID versions other than 4 or 5. (see previous

[PG] As mentioned above, you are correct. I’d like some WG feedback as to whether we should just make this a MUST in both places.

> -- 3rd paragraph: Is there an impact if something tampers with or lies

[PG] The only impact would be the inability to easily troubleshoot the call. There should be no impact to the ability to complete and interact with the call. Does this bear mentioning?

> - 15: Thank you for including this.

[PG] Thanks. It’s the least we could do.

> Editorial Comments and Nits:

[PG] I’ll address all of these in the updated version. Thank you for the feedback.