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

["Ben Campbell" <[e-mail]>]

Thanks for the response. Some more comments inline. I removed sections 
that do not seem to need further comment.

Thanks!

Ben.

On 30 May 2016, at 22:27, Paul Giralt wrote:

[...]

>
> [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.

I think there is room for clarification in the abstract. Perhaps 
something along the lines of "While the identifier is intended to work 
across multiple protocols, this document describes its usage in SIP."

>
>
>> - 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.
>>
>
>
> [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.

I haven't seen any work group feedback. I suggest sending a separate 
email for just this issue to the working group list to propose changing 
this to a MUST, and see if anyone objects.

>
>
>> - 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?
>>
>
>
> [PG] Cloud be any dialog-initiating request.

Then I suggest s/initiates a SIP request/initiates a potentially 
dialog-initiating SIP 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).
>>
>
>
> [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.

I think that since 7206, which was intended to be the requirements for 
this draft, cites 6872 then the solution really needs to cite it as 
well.

Also, SHOULD _is_ a mandate. Just not quite as strong of a mandate as 
MUST. I think that, if there's any SHOULDs there that do not apply, then 
this draft needs to explain that and why. Changing the SHOULD use 
version 4 or 5 to a MUST will help here, but that's also worth 
mentioning.



>
>
>> - 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.
>>
>
>
> [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.

If a user would prefer _not_ to be tracked across a transfer or 
redirect, is the UA allowed to ignore this? Or is the ability of a 
provider to track the call across dialogs assumed to outweigh the user's 
preference? (I suspect the answer is, if you don't want to be tracked, 
don't use the mechanism in the first place.)

But whatever the answer, this is a privacy tradeoff, and should be 
documented in the draft. As it is, I see the word privacy exactly once 
in version 22. That will be a red flag during the IESG evaluation. A 
privacy considerations would be helpful.

>
>
>> -- 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.
>>
>
> [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:

You are correct. I mean the second MUST.

>
>    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.
>

That works for me.

>
>> -7, first paragraph: Does the assumption of no "special treatment" 
>> means
>> 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.
>

A note to that effect would be helpful. (I think the implication is that 
this puts no requirements whatsoever on intermediaries--is that 
correct?)

>
>> -- 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?
>>
>
>
> [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.

A note to that effect would be helpful.


[...]

>
>
>> -- 2nd to last paragraph: Why are the SHOULDs not MUSTs? Can you
>> describe situations in which one might reasonably not follow the
>> SHOULDs?
>>
>
>
> [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?

As with the version 4 and 5 issue, it's probably worth sending a 
separate email to the working group proposing something. Otherwise this 
is buried in a long review and people may not notice it. (I also suggest 
making it clear what the choice will be if people don't respond.)

>
>
>> -- 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?
>>
>
>
> [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.

Okay.

>
>
>> -8, last paragraph: Why is the SHOULD not a MUST? When might one
>> reasonably not follow it?
>
>
> [PG] This is also related to the above two comments.

Okay.

>
>
>>
>> -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?
>>
>
>
> [PG] Yes, this assumes the conference is new to each subsequent MCU. 
> The case of two existing conferences is not addressed in the draft.

A note to that effect might be helpful.

>
>
>> - 10.3: Why doesn't the b2bua send a re-invite to update the uuid as 
>> in
>> the next example?
>>
>
> [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.

I agree. Examples should follow the SHOULDs unless they exist for the 
purpose of illustrating a violation of a SHOULD :-)

[...]

>
>
>> - 10.7, first bullet: It seems highly unlikely that a 3pcc server 
>> would
>> not be dialog stateful.
>>
>
>
> [PG] I agree, but any harm in leaving as is? Are we just stating the 
> obvious and we can leave it out entirely?

I guess it doesn't hurt anything either way.

>
>
>> - 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?
>>
>
> [PG] Yes, this was the intention. The pre-standard version is a bit 
> more than just proprietary.

Well, section 1 explicitly uses the word "proprietary". Maybe that needs 
to change?


> 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.

We can run with this as a MUST, but I won't be surprised if we get 
objections during IETF last call or IESG evaluation. It might be helpful 
to include a note to the effect that, even thought the legacy version 
was not standards-track, it was heavily implemented and adopted by other 
SDOs.

(My personal preference [which I will not try to push over working group 
consensus] would to include this sort of guidance non-normatively, where 
you say something the effect of "there's a lot of implementations of 
"there's a lot of deployed 7329 implementations; if you care do these 
things.")

>
>
>> -- 4th bullet: Wny isn't the presence or absence of remote-uuid
>> 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.

Okay. (Out of curiosity, is that allowed by 7329?)

[...]




>
>
>> -- 3rd paragraph: Is there an impact if something tampers with or 
>> lies
>> about session-Id values?
>>
>
>
> [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?
>

No, probably not.


[...]