Subject: Re: [Insipid] Revised requirements document

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 2 Jun 2012 23:11:36 -0400

Partha,

I agree that as the requirements now read, we should consider merging 5 and
6.

That said, what REQ6 used to say was that the session ID must not reveal
through the Session-ID that some entity was in the path that modified the
signaling messages.

I agree merging these two now is probably reasonable, but we are missing the
spirit of the original REQ6.  Do we want to retain that?

Paul

From: Ravindran, Parthasarathi [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2012 5:58 AM
To: Paul E. Jones; [email-masked]
Subject: RE: [Insipid] Revised requirements document

Paul,

IMO, REQ-5 and REQ-6 shall be merged together to indicate that "session-id
mechanism MUST not reveal any form of identity in REQ-5 and any form of SIP
messages in REQ-6".

REQ-6 is important because it provides confidence to the operator/admin that
session-id is safe to be passed across in SBC/PBX. In case it is possible to
use any of the existing SIP headers/body, IMO there is no need to new
session-id itself. AFAIK, there is no SIP headers/body exists which qualify
for session-id as of now. 

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul E. Jones
Sent: Wednesday, May 30, 2012 1:16 AM
To: [email-masked]
Subject: [Insipid] Revised requirements document

Folks,

As requested, I posted a revised version of the INSIPID requirements
document, taking into consideration the discussions from the call today.
Here's the text:

http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01

Note that Requirement 1a needs to be completed.  I'd be delighted if someone
could propose some wording for that.

As discussed on the call, the meaning of requirement 6 was changed quite
substantially in meaning from the -00 draft.  We need to decide exactly what
meaning we want or introduce a new requirement if we want to both hide
information and also not reveal that an SBC, for example, might have changed
any of that information.

Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 4 Jun 2012 08:22:39 +0000

Paul,

First, I'll double confirm your concern. The scenario is as follows:

1)      Some of the SIP headers/body is used by UAC to create the session id(something like hashing of SIP headers) and pass towards middle box (IP PBX, SBC, or any other core server)

2)      The middle box replaces SIP headers with new values and pass the same session-id to the UAS

3)      It is possible by UAS to identify that the middle box exists in the path by the mechanism used to compute session-id

In case I understand you concern correctly, I agree that it is missing in REQ-6 & REQ-5 as of now and also your concern looks valid to me based on customer requirement for removing History-info header from SIP message in SBC.

Thanks
Partha

From: Paul E. Jones [mailto:[email-masked]]
Sent: Sunday, June 03, 2012 8:42 AM
To: Ravindran, Parthasarathi; [email-masked]
Subject: RE: [Insipid] Revised requirements document

Partha,

I agree that as the requirements now read, we should consider merging 5 and 6.

That said, what REQ6 used to say was that the session ID must not reveal through the Session-ID that some entity was in the path that modified the signaling messages.

I agree merging these two now is probably reasonable, but we are missing the spirit of the original REQ6.  Do we want to retain that?

Paul

From: Ravindran, Parthasarathi [mailto:[email-masked]]
Sent: Wednesday, May 30, 2012 5:58 AM
To: Paul E. Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [Insipid] Revised requirements document

Paul,

IMO, REQ-5 and REQ-6 shall be merged together to indicate that "session-id mechanism MUST not reveal any form of identity in REQ-5 and any form of SIP messages in REQ-6".

REQ-6 is important because it provides confidence to the operator/admin that session-id is safe to be passed across in SBC/PBX. In case it is possible to use any of the existing SIP headers/body, IMO there is no need to new session-id itself. AFAIK, there is no SIP headers/body exists which qualify for session-id as of now.

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Paul E. Jones
Sent: Wednesday, May 30, 2012 1:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Insipid] Revised requirements document

Folks,

As requested, I posted a revised version of the INSIPID requirements document, taking into consideration the discussions from the call today.  Here's the text:
http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01

Note that Requirement 1a needs to be completed.  I'd be delighted if someone could propose some wording for that.

As discussed on the call, the meaning of requirement 6 was changed quite substantially in meaning from the -00 draft.  We need to decide exactly what meaning we want or introduce a new requirement if we want to both hide information and also not reveal that an SBC, for example, might have changed any of that information.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 4 Jun 2012 12:59:41 -0400

Partha,

If we used a hash (as you describe in (1)), that's probably OK since hash
functions are one way. (I assume you were referring to SHA-1 or MD5 or
other.)

Your other examples are valid, I think.

Unfortunately, I do not recall who proposed this requirement to hide the
fact an SBC is present, but I think it was focused on topology hiding.  If
we use a non-MAC-based UUID or a hash, we could meet this requirement.  The
question, though, is whether we need to retain the spirit of the original
requirement.

Do we want to have an explicit requirement to not reveal any information
like network topology through the session ID?  I'm not sure the group feels
strongly one way or the other, but it might be because there is already
thinking that whatever we use will not reveal that information, anyway.

Paul

From: Ravindran, Parthasarathi [mailto:[email-masked]] 
Sent: Monday, June 04, 2012 4:23 AM
To: Paul E. Jones; [email-masked]
Subject: RE: [Insipid] Revised requirements document

Paul,

1)      Some of the SIP headers/body is used by UAC to create the session
id(something like hashing of SIP headers) and pass towards middle box (IP
PBX, SBC, or any other core server)

2)      The middle box replaces SIP headers with new values and pass the
same session-id to the UAS

3)      It is possible by UAS to identify that the middle box exists in the
path by the mechanism used to compute session-id

In case I understand you concern correctly, I agree that it is missing in
REQ-6 & REQ-5 as of now and also your concern looks valid to me based on
customer requirement for removing History-info header from SIP message in
SBC. 

Thanks

Partha 

Partha,

Paul

Paul,

Thanks

Partha

Folks,

Paul