A Session Identifier for the Session Initiation Protocol (SIP)
draft-kaplan-insipid-session-id-04
Yes
(Alissa Cooper)
(Richard Barnes)
No Objection
(Alia Atlas)
(Barry Leiba)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Ted Lemon)
Note: This ballot was opened for revision 04 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
()
Unknown
Richard Barnes Former IESG member
Yes
Yes
()
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2014-03-21)
Unknown
Adrian's questions seem like excellent things to think about.
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-03-13)
Unknown
It seems to me to be slightly simplistic to say that because the Session ID has no sensitive information in it, it will not reveal any information related to any SIP device or domain identity. That is, of course, examined in isolation it will not reveal anything, but it becomes a piece of metadata that can be examined at several points in the network to discover information about the session. Indeed, it seems that the purpose of the Session ID is exactly to provide correlation that would not otherwise be possible (or might only be possible if the B2BUAs sisn't mess with the Call IDs). This does not speak against the use of a Session ID, but does suggest that its use might not be quite as harmless as this document suggests. --- There is a wrinkle with 4.5.1... Imagine there are two B2BUAs along the path both of which change the Call-ID. Suppose also that the original request does not contain a Session ID. The first B2BUA does not add a Session ID (it is a "MAY" and anyway it is a legacy implementation). The second B2BUA adds a Session ID using the received Call-ID, but this is not original one. Question: why does the text require that the Session ID inserted by a B2BUA be derived from the received Call-ID? It doesn't seem to make any difference (it is, after all, using the B2BUA's secret) and the received Call-ID is no different to the B2BUA's substituted Call-ID. --- There is, of course, a very small chance that two Session IDs will be identical. This could happen at one point of generation or across two such points. Should you include advice to a Session ID generator to catch such cases? Should you give a warning to users of the Session ID that this might happen? Unlikely though it is, it will happen in the field the first time the function is enabled :-)
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-03-27)
Unknown
This is a non-blocking comment/suggestion: The security considerations section should include a sentence about the requirement to avoid any values that may raise privacy concerns in the SIP header. This is already listed earlier int he document, but may be helpful to repeat in this section.
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-03-23)
Unknown
- Were the IESG discusses/comments on the insipid WG requirements document considered in this text? If not, why not? I suspect (without having looked back) that some of them might apply here and be ok to handle here as well. (I had a discuss on that that I'd like you to look at.) - Why are we only implicitly recommending implementations follow the standards track approach and not this?
Ted Lemon Former IESG member
No Objection
No Objection
()
Unknown