Laura,

Your proposal (1) looks good as follows:

"REQ6: The identifier must not reveal to the receiver of it the
   Call-ID, tags, or any other SIP header or body portion. "

Thanks
Partha

>-----Original Message-----
>From: Laura Liess [mailto:laura.liess.dt@googlemail.com]
>Sent: Monday, April 30, 2012 7:42 PM
>To: Ravindran, Parthasarathi
>Cc: Paul E. Jones; insipid@ietf.org; Martin Hülsemann; Hadriel Kaplan
>Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7
>
>Hi Partha,
>
>  > REQ-6 is important to avoid using Session-id being used as rathole
>for passing any information. IMO, it is important.
>
>If I understand your point correctly, you don't want User A being able
>to transmit some critical information to User B in the Session-ID-header
>without the B2BUA between them  being able to filter out this critical
>information. Is this correct?
>
>If yes, I would propose to modify the requirement to
>
>1. "REQ6: The identifier must not reveal to the receiver of it the
>   Call-ID, tags, or any other SIP header or body portion. "
>
>or restrict the requirements to end devices:
>
>2. "REQ6: The identifier must not reveal to end devices that the
>   Call-ID, tags, or any other SIP header or body portion have been
>   changed by middleboxes."
>
>Can you live with one of these alternatives?
>
>Kind regards
>Laura
>
>>
>> Thanks
>> Partha
>>
>>>-----Original Message-----
>>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On
>>>Behalf Of Laura Liess
>>>Sent: Friday, April 27, 2012 6:48 PM
>>>To: Paul E. Jones
>>>Cc: insipid@ietf.org; Martin Hülsemann; Hadriel Kaplan
>>>Subject: Re: [Insipid] Comment on REQ1, REQ6 and REQ7
>>>
>>>Paul,
>>>
>>>What I tried to say was that I think we can drop REQ6. REQ5 and REC1
>>>are important for us.
>>>
>>>(Unfortunately, the was drawing which arrived at the mailing list was
>>>not what I intended to send. So the example is quite difficult to
>>>understand.)
>>>
>>>Kind regards
>>>Laura
>>>
>>>
>>>2012/4/26 Paul E. Jones <paulej@packetizer.com>:
>>>> Laura,
>>>>
>>>> I assume the desire for REQ6 relates to ensuring the kind of privacy
>>>that is afforded by SBCs.  They can hide network topologies, peering
>>>relations, etc.  This requirements suggests that we do not want those
>>>things disclosed via the Session-ID.
>>>>
>>>> REQ7 is a means of assigning an ID when the endpoint does not.  That
>>>would perhaps mean one cannot inspect all the way to the endpoint, but
>>>one can at least track sessions to the assigning element.
>>>>
>>>> REQ1 seems conflicting on the surface, but one may not always have
>>>access into every segment everywhere.  Those topologies and business
>>>relationships remain hidden.  Even so, it's possible to perhaps have
>>>multiple people and organizations talking about the same Session-ID,
>>>regardless of what other data is changed.
>>>>
>>>> In short, I don't think it matters if something can determine
>>>> changes
>>>made by the B2BUA if it's that something is in a position to do so
>>>(e.g., has physical access to all network segments), but the AS should
>>>not be able to see that Carrier A peered with Carrier B or some such
>>>or that the caller is using Mobile Operator C.
>>>>
>>>> Paul
>>>>
>>>>> -----Original Message-----
>>>>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com]
>>>>> Sent: Thursday, April 26, 2012 9:50 AM
>>>>> To: insipid@ietf.org; Paul Jones; Hadriel Kaplan
>>>>> Cc: Martin Hülsemann
>>>>> Subject: Comment on REQ1, REQ6 and REQ7
>>>>>
>>>>> Hi,
>>>>>
>>>>> What is the reason for having REQ6?  Do we realy need it? It seems
>>>>> to me that it will be difficult to fulfill all REQ1 and REQ6 and
>>>>> REQ7 at the same time.
>>>>>
>>>>> Take the following scenario:
>>>>>
>>>>>     -----------
>>>>> -------------                                    -----------
>>>>>    |    A     | ---------Call-ID x---------------------->| B2BUA
>>>>> |-------------Call-ID y------->|    AS   |--------
>>>>>     -----------
>>>>> -------------              Session-ID z    -----------
>>>>>
>>>>> A is an end device that does not support Session-ID.  AS is an
>>>>> Application Server and in the context of REQ6 the receiver of the
>>>>> Session-ID. The B2BUA changes the Call-ID from x to y and
>>>>> calculates
>>>a Session-ID z.
>>>>> By REQ1 and REQ7, an external device monitoring the SIP-traffic
>>>>> must be able to find out that messages with the Call-ID x and
>>>>> messages with the Session-ID z belong to the same session. So the
>>>>> B2BUA must build z as a function of x, let's say z =F(x) and the
>>>>> monitoring the B2BUA and the monitoring system have to know F.
>>>>> Otherwise,  by REQ6, the AS is not allowed to know F, otherwise he
>>>>> is able to find out that z /= F(y).
>>>>> Maybe it is in theoreticaly possible for a network to have a for
>>>>> each node a different F and the the monitoring systems knowing
>>>>> which F to use for a call leg, but in practice this is probably too
>complex.
>>>>>
>>>>> Thanks,
>>>>> Laura
>>>>
>>>_______________________________________________
>>>insipid mailing list
>>>insipid@ietf.org
>>>https://www.ietf.org/mailman/listinfo/insipid