Subject: [Insipid] Comment on REQ1, REQ6 and REQ7

From: Laura Liess <[email-masked]>
Date: Thu, 26 Apr 2012 15:50:02 +0200

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 26 Apr 2012 13:48:06 -0400

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:[email-masked]]
> Sent: Thursday, April 26, 2012 9:50 AM
> To: [email-masked]; 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.
> 
> 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

---

From: Laura Liess <[email-masked]>
Date: Fri, 27 Apr 2012 15:18:18 +0200

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 27 Apr 2012 15:07:24 +0000

REQ-6 is important to avoid using Session-id being used as rathole for passing any information. IMO, it is important. 

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Laura Liess
>Sent: Friday, April 27, 2012 6:48 PM
>To: Paul E. Jones
>Cc: [email-masked]; 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.
>
>> 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
>>
>>> Session-ID. The B2BUA changes the Call-ID from x to y and calculates
>a Session-ID z.
>>> 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.
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Laura Liess <[email-masked]>
Date: Mon, 30 Apr 2012 16:12:05 +0200

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