Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Jul 2010 12:37:41 -0400

Howdy,
I submitted an updated version of the session-id draft, for consideration as a solution for the (hopefully) new WG for such purpose.

The major changes are:
1)    Reverted the generation of the session-id value to be a defined 128-bit hash mechanism, as it was prior to version 1, based on feedback that having it be a known algorithm allows a monitoring system with the same private key to generate the value itself for matching purposes.
2)    Added a section on transfer handling, for REFER and INVITE-with-Replaces, such that a transferred call uses the same session-id.  This section is just a beginning strawman and will need more thought.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

      Title           : A Session Identifier for the Session Initiation Protocol (SIP)
      Author(s)       : H. Kaplan
      Filename        : draft-kaplan-dispatch-session-id-02.txt
      Pages           : 13
      Date            : 2010-07-12

There is a need for having a globally unique session identifier for the same SIP session, which can be consistently maintained across Proxies, B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting.  This draft proposes a new SIP header to carry such a value: Session-ID.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-02.txt

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 13 Jul 2010 13:24:46 -0500

On 07/13/2010 11:37 AM, Hadriel Kaplan wrote:
> There is a need for having a globally unique session identifier for the
> same SIP session, which can be consistently maintained across Proxies,
> B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting.
> This draft proposes a new SIP header to carry such a value: Session-ID.

Hadriel: I know are aware of this, but to point this work
out to the broader audience in the sipclf WG ... another use of
the Session-ID header can conceivably include the end-to-end
tracing of sessions that cross administrative domains.  We have
talked about this in the sipclf WG.

Session-ID can appear as one of the extension headers in the
SIP CLF record.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Jul 2010 15:07:38 -0400

Yup, and we have it indicated as one of the recorded fields in the Ipfix-based sipclf I-D, in the draft-niccolini-sipclf-ipfix-03. (though of course that's just a strawman list of fields right now anyway)

-hadriel

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Tuesday, July 13, 2010 2:25 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02
>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 20 Jul 2010 23:39:49 +0530

Hadriel,
 
I have a security related concern with session-id. One of the
requirements in the draft is:
 
   REQ2a: The identifier must not reveal any information related to any
   SIP device or domain identity, including IP Address, port, hostname,
   domain name, username, Address-of-Record, MAC address, IP address
   family, transport type, etc.
 
And then is says:
 
   A B2BUA compliant with this document MUST copy the Session-ID header
   field it receives in requests as a UAS into the related requests it
   generates as a UAC; and any Session-ID field it receives in
   responses as a UAC into the correlated responses it generates as a
   UAS.
 
Now, how is a B2BUA, and a SBC in particular, going to verify that
session-id isn't revealing any of these information unless it inspects
the session-id header? What if an UA uses these 128-bits to encode any
of these information to bypass the policies configured at an SBC? For
example, an UA can stuff in up to 4 IPv4 addresses or an IPv6 address
into the 128-bit session-id header value and get it intact across all
SBC bypassing their address/topology hiding policies.
 
Worst, a SBC in the signaling path can strip off the incoming
session-id, construct a new session-id, encoding some information into
it in order to bypass the policies configured in upstream SBCs, and send
it out. When it receives the response, it does the reverse and sends the
original session-id back -- a kind of man-in-the-middle attack that none
of the SIP elements can detect, unless someone captures the messages
across both sides of this SBC.
 
I am not sure SBC vendors are going to be comfortable blindly trusting
the sender and considering session-id as an opaque data. Unless we solve
this problem they might be reluctant to support session-id.
 
Muthu

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Jul 2010 13:50:20 -0500

> SBC bypassing their address/topology hiding policies.

They could also send in in the RTP as DTMF (which a colluding UA on the 
far end can trivially decode). Or, if you block DTMF, they could play 
this information out as text-to-speech in the audio stream; a colluding 
UA on the other end could run speech recognition on this audio to 
retrieve the information (numbers are very easy to pick out with speech 
recognition). Or, if you start looking for spoken digits at the 
beginning of the audio stream, they can steganographically encode the 
information in the RTP stream (using lost-audio-packet steganography) or 
even in the contents of the transmitted audio stream itself (yes, there 
are forms of steganography that survive compression and even transcoding).

Basically, if the client is bound and determined to leak this 
information, it's going to do it. There's nothing an SBC can do about 
it. Until you actually prevent all communication from the caller to the 
callee, there will be holes.

/a

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 21 Jul 2010 00:31:17 +0530

Sure, they could even fax/email it and a SBC can do nothing about it.
However, if the information is leaked through a SIP header a SBC vendor
would find it hard to digest -- a perception that I don't think can
easily be changed.
 
Muthu 
 
From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, July 21, 2010 12:20 AM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02

 

are forms of steganography that survive compression and even
transcoding).

/a

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 20 Jul 2010 15:12:51 -0400

Are there other headers an SBC would normally forward which could
exploited in this way?

I suspect in practice there are - although there is no requirement
that an SBC forward headers if it wants to be very cautious about such
things.

In this case I suggest such an SBC would extend it's policy to
Session-ID and simply not support it - or regenerate it and break the
chain.

Peter Musgrave

On Tue, Jul 20, 2010 at 3:01 PM, Muthu ArulMozhi Perumal (mperumal)
<[email-masked]> wrote:
> would find it hard to digest -- a perception that I don't think can easily
> be changed.
>
>
>
> Muthu
>
>
>
> session-id isn't revealing any of these information unless it inspects the
> session-id header? What if an UA uses these 128-bits to encode any of these
> information to bypass the policies configured at an SBC? For example, an UA
> can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128-bit
> session-id header value and get it intact across all SBC bypassing their
> address/topology hiding policies.
>
> They could also send in in the RTP as DTMF (which a colluding UA on the far
> end can trivially decode). Or, if you block DTMF, they could play this
> information out as text-to-speech in the audio stream; a colluding UA on the
> other end could run speech recognition on this audio to retrieve the
> information (numbers are very easy to pick out with speech recognition). Or,
> if you start looking for spoken digits at the beginning of the audio stream,
> they can steganographically encode the information in the RTP stream (using
> lost-audio-packet steganography) or even in the contents of the transmitted
> audio stream itself (yes, there are forms of steganography that survive
> compression and even transcoding).
>
> Basically, if the client is bound and determined to leak this information,
> it's going to do it. There's nothing an SBC can do about it. Until you
> actually prevent all communication from the caller to the callee, there will
> be holes.
>
> /a
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Jul 2010 15:18:46 -0400

Hi Muthu,
See section 9.2 of the draft, which has some text around some of the issues you raised.

As for the issue of a UA maliciously trying to pass through addressing in the session-id value, that's unavoidable and not a real issue I think.  It's unavoidable because there are multiple ways for a UA which is really intent on getting IP Addressing through an SBC to do so anyway, at least by encoding it in the media.  But I also think it's not a real issue because in my opinion generally SBC's hide the IP Addressing because people _want_ it hidden.  Even the end-users generally want it hidden; if they don't, if they want to learn IP Addresses of each other, nothing will stop them from just telling each other what it is. (since it takes both sides to collude for it to work anyway)

But as the draft points out, if some vendor (including SBC vendors themselves) use this header for some nefarious purpose, then no RFC can prevent them from doing so; but what will happen is the word will get out and the SBC vendors will be forced to remove/replace the header, negating its value to all.

I think/hope the need for a consistent value which crosses b2bua's for troubleshooting purposes will be useful enough to vendors, if even to help their own TAC with debugging issues, that they leave it alone - or their customers to tell them to anyway.

-hadriel

> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
> Sent: Tuesday, July 20, 2010 2:10 PM
> 
> I have a security related concern with session-id. One of the requirements
> in the draft is:
> session-id header? What if an UA uses these 128-bits to encode any of
> these information to bypass the policies configured at an SBC? For example,
> an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128-
> bit session-id header value and get it intact across all SBC bypassing
> their address/topology hiding policies.
> 
> Worst, a SBC in the signaling path can strip off the incoming session-id,
> construct a new session-id, encoding some information into it in order to
> bypass the policies configured in upstream SBCs, and send it out. When it
> receives the response, it does the reverse and sends the original session-
> id back -- a kind of man-in-the-middle attack that none of the SIP
> elements can detect, unless someone captures the messages across both
> sides of this SBC.
> 
> I am not sure SBC vendors are going to be comfortable blindly trusting the
> sender and considering session-id as an opaque data. Unless we solve this
> problem they might be reluctant to support session-id.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 21 Jul 2010 02:03:12 +0530

Hadriel,

I agree with most of what you are saying. However, my questions is, do
we want to just ignore it, acknowledging session-id as yet another
header through which information can be leaked bypassing SBC policies,
or develop a mechanism to equip a SBC with the ability to actually
verify that the session-id was indeed constructed form the Call-ID and
doesn't reveal anything else, boosting the confidence of SBC vendors.

Once quick solution I can think of is, the UA generating a session-id
could share a secret with its SBC. It can then encrypt the 128-bit
pseudo-random key it generates for constructing the hash with this
shared secret, and attach the encrypted value as a session-id header
parameter. The SBC can then decrypt the key (using the shared secret),
re-compute the hash of the incoming Call-ID, compare it with the
session-id value to make sure it was indeed constructed as it should
have been.

Off course, it doesn't prevent a SBC in performing a man-in-the-middle
kind of an attack, but might be worth exploring.

So, if we do want to address it, we could add another requirement like
this:

   REQ2c: It should be possible to verify that the identifier does not
reveal 
   any information related to any SIP device or domain identity,
including
   IP Address, port, hostname, domain name, username, Address-of-Record,
MAC 
   address, IP address family, transport type, etc. 

The WG can then break its head to see how to solve it -:)

Muthu
 
|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Wednesday, July 21, 2010 12:49 AM
|To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02
|
|Hi Muthu,
|See section 9.2 of the draft, which has some text around some of the
issues
|you raised.
|
|As for the issue of a UA maliciously trying to pass through addressing
in
|the session-id value, that's unavoidable and not a real issue I think.
It's
|unavoidable because there are multiple ways for a UA which is really
intent
|on getting IP Addressing through an SBC to do so anyway, at least by
|encoding it in the media.  But I also think it's not a real issue
because in
|my opinion generally SBC's hide the IP Addressing because people _want_
it
|hidden.  Even the end-users generally want it hidden; if they don't, if
they
|want to learn IP Addresses of each other, nothing will stop them from
just
|telling each other what it is. (since it takes both sides to collude
for it
|to work anyway)
|
|But as the draft points out, if some vendor (including SBC vendors
|themselves) use this header for some nefarious purpose, then no RFC can
|prevent them from doing so; but what will happen is the word will get
out
|and the SBC vendors will be forced to remove/replace the header,
negating
|its value to all.
|
|I think/hope the need for a consistent value which crosses b2bua's for
|troubleshooting purposes will be useful enough to vendors, if even to
help
|their own TAC with debugging issues, that they leave it alone - or
their
|customers to tell them to anyway.
|
|-hadriel
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|> Sent: Tuesday, July 20, 2010 2:10 PM
|>
|> I have a security related concern with session-id. One of the
requirements
|> in the draft is:
|>    REQ2a: The identifier must not reveal any information related to
any
|>    SIP device or domain identity, including IP Address, port,
hostname,
|>    domain name, username, Address-of-Record, MAC address, IP address
|>    family, transport type, etc.
|>
|> And then is says:
|>    A B2BUA compliant with this document MUST copy the Session-ID
header
|>    field it receives in requests as a UAS into the related requests
it
|>    generates as a UAC; and any Session-ID field it receives in
|>    responses as a UAC into the correlated responses it generates as a
|>    UAS.
|>
|> Now, how is a B2BUA, and a SBC in particular, going to verify that
|> session-id isn't revealing any of these information unless it
inspects the
|> session-id header? What if an UA uses these 128-bits to encode any of
|> these information to bypass the policies configured at an SBC? For
|example,
|> an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the
128-
|> bit session-id header value and get it intact across all SBC
bypassing
|> their address/topology hiding policies.
|>
|> Worst, a SBC in the signaling path can strip off the incoming
session-id,
|> construct a new session-id, encoding some information into it in
order to
|> bypass the policies configured in upstream SBCs, and send it out.
When it
|> receives the response, it does the reverse and sends the original
session-
|> id back -- a kind of man-in-the-middle attack that none of the SIP
|> elements can detect, unless someone captures the messages across both
|> sides of this SBC.
|>
|> I am not sure SBC vendors are going to be comfortable blindly
trusting the
|> sender and considering session-id as an opaque data. Unless we solve
this
|> problem they might be reluctant to support session-id.

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Jul 2010 15:40:16 -0500

No, this is ridiculous.

There is no point to having a 4-foot-thick solid metal door that can 
withstand a nuclear blast next to a large, open window. Unless you're 
planning on locking down every other bit of information that can 
possibly go between user agents -- including the media -- this kind of 
requirement is paranoid overkill.

/a

---

From: [email-masked]
Date: Wed, 21 Jul 2010 10:11:47 +0800

Hi Muthu and Adam,

I just read the argument from both of you. 

In fact, as we know, SBC can not guarantee absolute security by Adam's 
argument, as the user(UAC/UAS) can pass information in media plane, or 
using a private encryption for session-id/dialog-id. And the SBCs have no 
way to inspect it.

As we know that we should not do nothing (for security), while we can not 
do everything (for security). So, IMO, Muthu's argument is also meaningful 
for relative security.

But I am not going to be the peacemaker for this argument :)
As we know, session-id is troubleshooting/debugging oriented. So, it is a 
tool level thing, not normative level, that is optional. And about SBC, it 
has it's local policy, that is it has the right to decide supporting 
session-id or blocking it. And SBC can even make this a configuration, 
such as just supporting session-id in debugging mode, and blocking it in 
real deployment.

Further, I'd like to blocking session-id in real deployment for some 
special kinds of B2BUA equipment, such as 3GPP's routing_B2BUA_AS and 
topology_hidden_oriended_SBC.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

"Muthu ArulMozhi Perumal (mperumal)" <[email-masked]> 
发件人:  [email-masked]
2010-07-21 04:33

收件人
"Hadriel Kaplan" <[email-masked]>, <[email-masked]>
抄送

主题
Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02

Hadriel,

Muthu

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 21 Jul 2010 12:06:25 +0530

The fact that there are many backdoors doesn't seem a good excuse for
opening one more, especially when there is a possibility of building
that 4-foot-thick solid metal door.

Irrespective of whether we add this verifiability requirement or not,
the fact that session-id can be extended using header parameters isn't
going to stop someone from adding that capability -- if IETF doesn't do
it, don't be surprised if 3GPP standardizes it -:)

Muthu 

|-----Original Message-----
|From: Adam Roach [mailto:[email-masked]]
|Sent: Wednesday, July 21, 2010 2:10 AM
|To: Muthu ArulMozhi Perumal (mperumal)
|Cc: Hadriel Kaplan; [email-masked]
|Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02
|
|
|  No, this is ridiculous.
|
|There is no point to having a 4-foot-thick solid metal door that can
|withstand a nuclear blast next to a large, open window. Unless you're
|planning on locking down every other bit of information that can
|possibly go between user agents -- including the media -- this kind of
|requirement is paranoid overkill.
|
|/a
|
|On 7/20/10 15:33, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote:
|> Hadriel,
|>
|> I agree with most of what you are saying. However, my questions is,
do
|> we want to just ignore it, acknowledging session-id as yet another
|> header through which information can be leaked bypassing SBC
policies,
|> or develop a mechanism to equip a SBC with the ability to actually
|> verify that the session-id was indeed constructed form the Call-ID
and
|> doesn't reveal anything else, boosting the confidence of SBC vendors.
|>
|> Once quick solution I can think of is, the UA generating a session-id
|> could share a secret with its SBC. It can then encrypt the 128-bit
|> pseudo-random key it generates for constructing the hash with this
|> shared secret, and attach the encrypted value as a session-id header
|> parameter. The SBC can then decrypt the key (using the shared
secret),
|> re-compute the hash of the incoming Call-ID, compare it with the
|> session-id value to make sure it was indeed constructed as it should
|> have been.
|>
|> Off course, it doesn't prevent a SBC in performing a
man-in-the-middle
|> kind of an attack, but might be worth exploring.
|>
|> So, if we do want to address it, we could add another requirement
like
|> this:
|>
|>     REQ2c: It should be possible to verify that the identifier does
not
|> reveal
|>     any information related to any SIP device or domain identity,
|> including
|>     IP Address, port, hostname, domain name, username,
Address-of-Record,
|> MAC
|>     address, IP address family, transport type, etc.
|>
|> The WG can then break its head to see how to solve it -:)
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: Hadriel Kaplan [mailto:[email-masked]]
|> |Sent: Wednesday, July 21, 2010 12:49 AM
|> |To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|> |Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02
|> |
|> |Hi Muthu,
|> |See section 9.2 of the draft, which has some text around some of the
|> issues
|> |you raised.
|> |
|> |As for the issue of a UA maliciously trying to pass through
addressing
|> in
|> |the session-id value, that's unavoidable and not a real issue I
think.
|> It's
|> |unavoidable because there are multiple ways for a UA which is really
|> intent
|> |on getting IP Addressing through an SBC to do so anyway, at least by
|> |encoding it in the media.  But I also think it's not a real issue
|> because in
|> |my opinion generally SBC's hide the IP Addressing because people
_want_
|> it
|> |hidden.  Even the end-users generally want it hidden; if they don't,
if
|> they
|> |want to learn IP Addresses of each other, nothing will stop them
from
|> just
|> |telling each other what it is. (since it takes both sides to collude
|> for it
|> |to work anyway)
|> |
|> |But as the draft points out, if some vendor (including SBC vendors
|> |themselves) use this header for some nefarious purpose, then no RFC
can
|> |prevent them from doing so; but what will happen is the word will
get
|> out
|> |and the SBC vendors will be forced to remove/replace the header,
|> negating
|> |its value to all.
|> |
|> |I think/hope the need for a consistent value which crosses b2bua's
for
|> |troubleshooting purposes will be useful enough to vendors, if even
to
|> help
|> |their own TAC with debugging issues, that they leave it alone - or
|> their
|> |customers to tell them to anyway.
|> |
|> |-hadriel
|> |
|> |>  -----Original Message-----
|> |>  From: Muthu ArulMozhi Perumal (mperumal)
[mailto:[email-masked]]
|> |>  Sent: Tuesday, July 20, 2010 2:10 PM
|> |>
|> |>  I have a security related concern with session-id. One of the
|> requirements
|> |>  in the draft is:
|> |>     REQ2a: The identifier must not reveal any information related
to
|> any
|> |>     SIP device or domain identity, including IP Address, port,
|> hostname,
|> |>     domain name, username, Address-of-Record, MAC address, IP
address
|> |>     family, transport type, etc.
|> |>
|> |>  And then is says:
|> |>     A B2BUA compliant with this document MUST copy the Session-ID
|> header
|> |>     field it receives in requests as a UAS into the related
requests
|> it
|> |>     generates as a UAC; and any Session-ID field it receives in
|> |>     responses as a UAC into the correlated responses it generates
as a
|> |>     UAS.
|> |>
|> |>  Now, how is a B2BUA, and a SBC in particular, going to verify
that
|> |>  session-id isn't revealing any of these information unless it
|> inspects the
|> |>  session-id header? What if an UA uses these 128-bits to encode
any of
|> |>  these information to bypass the policies configured at an SBC?
For
|> |example,
|> |>  an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into
the
|> 128-
|> |>  bit session-id header value and get it intact across all SBC
|> bypassing
|> |>  their address/topology hiding policies.
|> |>
|> |>  Worst, a SBC in the signaling path can strip off the incoming
|> session-id,
|> |>  construct a new session-id, encoding some information into it in
|> order to
|> |>  bypass the policies configured in upstream SBCs, and send it out.
|> When it
|> |>  receives the response, it does the reverse and sends the original
|> session-
|> |>  id back -- a kind of man-in-the-middle attack that none of the
SIP
|> |>  elements can detect, unless someone captures the messages across
both
|> |>  sides of this SBC.
|> |>
|> |>  I am not sure SBC vendors are going to be comfortable blindly
|> trusting the
|> |>  sender and considering session-id as an opaque data. Unless we
solve
|> this
|> |>  problem they might be reluctant to support session-id.
|>
|> _______________________________________________
|> dispatch mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/dispatch

---

From: [email-masked]
Date: Wed, 21 Jul 2010 15:54:53 +0800

Muthu,

> it, don't be surprised if 3GPP standardizes it -:)

+1 for this point. 
And this is a important and general issue for interworking of 3GPP's 
equipment and common SIP network.

And as Hadriel has pointed out in the draft:
Although the Session-ID concept is similar to the Call-ID, it is not 
   used for message dialog-matching rules in RFC 3261, nor does it 
   change the Call-ID usage, nor does it replace the Call-ID value. 
   Instead this new header field provides an identifier for 
   troubleshooting uses only. 

So, I guess if all of us can stick to this declaration, it would be OK.

Thanks,

Gao

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Jul 2010 10:11:52 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Muthu 
> ArulMozhi Perumal (mperumal)
> Sent: 20 July 2010 21:33
> To: Hadriel Kaplan; [email-masked]
> could share a secret with its SBC. 
[JRE] Sharing a secret with "its SBC", whatever that might mean, might be possible, but what about downstream SBCs? A SIP request can potentially traverse any number of SBCs.

I agree with those who say this is a problem we don't need to solve, since there are so many other ways a UA could deliberately convey sensitive information through an SBC. Just a brief discussion of the issue under Security Considerations should suffice.

John

It can then encrypt the 128-bit

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jul 2010 13:41:18 -0400

Hadriel,

A somewhat related question for you on the draft:

Is the algorithm described in the draft intended to be normative?
AFAICT there is no *normative* language about the algorithm itself.
Nor can I find much value in making it normative.

The only stated reason for using a defined algorithm is so that two 
boxes can produce the same output from the same input. But when is that 
required? I think it may be needed when pairs (or more) of servers share 
responsibility for a given dialog. And in such cases it will almost 
always be the case that they are a matched set from the same vendor.

I interpret the algorithm as an *example* of a suitable algorithm.

Can we have some clarity on the normativeness of this?

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 23 Jul 2010 14:59:47 +0530

Hi Hadriel,

It is nice to have the mechanism by which one/some of the header(s) pass(es) through B2BUA. This provides facility for end-to-end service to work. But the current draft is proposed only for the "troubleshooting" only. IMO, the scope of the draft *MUST* be increased to provide more services. Some of the services comes to my mind are 

1) In SIP recording mechanism, B2BUA exist between Session Recording Client (SRC) and Session Recording Server (SRS). It is better to have the unique id like session id passed from SRC to SRS.

2) In Media antitrombone mechanism, the session id shall be used to identify the loop for the same call. In the mentioned Antitrombone scenario, the signalling is required to be looped and only media should not be looped (SBC standard requirement). The trombone shall be identified by SDP attributes and the service shall kick start. The SDP attributes using trombone will not work in case B2BUA without media handling (Media flowaround) in one dialog and B2BUA with media handling (media topology hiding) in another dialog. To identify the trombone due to B2BUA without media dialog is not possible without keep track of all the endpoint IP addresses. In case session-id header exists in the dialog, it will help to relate the dialog in B2BUA. 

There may be other requirements for passing the headers. It is better to create the generic header mechanism or B2BUA guidelines instead of service specific header standardization as it may leads to multiple standards instead of one generic approach.

Regards

Partha

________________________________

From: [email-masked] on behalf of Hadriel Kaplan
Sent: Tue 7/13/2010 10:07 PM
To: [email-masked]
Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02

Howdy,

The major changes are:

 

      Author(s)       : H. Kaplan

      Pages           : 13

      Date            : 2010-07-12

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Jul 2010 09:06:35 -0400

Hi Paul,
The algorithm was intended to be normative, although I'm certainly open to doing whatever the WG wants of course.

The reason for it is not for b2bua server pairs, but rather for monitoring equipment correlation, based on feedback from Laura Liess.  Assume a call flow like this:

Alice      B2BUA      Bob
  |          |         |
  |INVITE_1  |         |
  |--------->|INVITE_2 |
  |          |-------->|
  |          |         |
           \   /
            \ /
          Monitor

The monitor can see INVITE_1 and INVITE_2.  Alice is a legacy UA, so the B2BUA inserts Session-ID.  If the session-id the B2BUA creates is based on the known algorithm, and if the monitor has the same key, then the monitor can know that INVITE_2 is from INVITE_1 because it can create the same value from INVITE_1.

Since the monitor and B2BUA are probably not from the same company, the idea was to specify the algorithm in the draft and require its implementation.  But we could instead just specify it as the algorithm to use for such cases, but leave it up to implementations to decide if they want to support such cases on their own.  Like call it some named algorithm so vendors can say whether they do it or not.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, July 22, 2010 1:41 PM
> To: Hadriel Kaplan
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jul 2010 09:25:40 -0400

Hadriel,

> The reason for it is not for b2bua server pairs, but rather for monitoring equipment correlation, based on feedback from Laura Liess.  Assume a call flow like this:

Thanks for clarifying the purpose of specifying the algorithm.

>   |--------->|INVITE_2 |

ISTM the above can be solved without standardizing anything.
The first response to INVITE_1 will have the session id.
At that point the Monitor will know the correlation.

> Since the monitor and B2BUA are probably not from the same company, the idea was to specify the algorithm in the draft and require its implementation.  But we could instead just specify it as the a…

Especially in cases like this I would think it to be logistically 
difficult to share the keys

Note I'm not overly concerned about standardizing the algorithm if there 
is a good reason to do so.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Jul 2010 09:56:54 -0400

Hi Partha,
Comments inline...

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: Friday, July 23, 2010 5:30 AM
> It is nice to have the mechanism by which one/some of the header(s)
> pass(es) through B2BUA. This provides facility for end-to-end service to
> work. But the current draft is proposed only for the "troubleshooting"
> only. IMO, the scope of the draft *MUST* be increased to provide more
> services. 

Why?  What's wrong with having a header value whose sole purpose is for troubleshooting?  Do you think it's not enough purpose to make people support it?

> 1) In SIP recording mechanism, B2BUA exist between Session Recording
> Client (SRC) and Session Recording Server (SRS). It is better to have the
> unique id like session id passed from SRC to SRS.

So far SIPREC has not defined a protocol mechanism in any draft, afaik.  There're requirements and architecture drafts, but no reason so far as I can tell that one would need to use session-id for anything new there.  Can you explain what it would be used for that call-id and tags would not?

> 2) In Media antitrombone mechanism, the session id shall be used to
> identify the loop for the same call. In the mentioned Antitrombone
> scenario, the signalling is required to be looped and only media should
> not be looped (SBC standard requirement). The trombone shall be identified
> by SDP attributes and the service shall kick start. The SDP attributes
> using trombone will not work in case B2BUA without media handling (Media
> flowaround) in one dialog and B2BUA with media handling (media topology
> hiding) in another dialog. To identify the trombone due to B2BUA without
> media dialog is not possible without keep track of all the endpoint IP
> addresses. In case session-id header exists in the dialog, it will help to
> relate the dialog in B2BUA.

I know there are benefits to detecting when a call hairpins/loops, and there's no debate a session-id could be used to detect that - in fact it used to be one of the reasons for session-id in the first versions of the draft back when it was draft-kaplan-sip-session-id.  But I removed that motivation a while back, as it was effectively the same thing as monitoring correlation - the monitoring system just happens to be incorporated into the b2bua.  

BTW, in my experience using it for a media-trombone scenario as you describe won't work, because it only handles the case of the same SBC being traversed.  We've had to use other techniques to make that scenario work.  Unfortunately the techniques vary depending on the vendor of the core equipment (softswitch/pbx/S-CSCF), but the problem's been solved for years.

> There may be other requirements for passing the headers. It is better to
> create the generic header mechanism or B2BUA guidelines instead of service
> specific header standardization as it may leads to multiple standards
> instead of one generic approach.

I disagree.  I don't think we'll be successful in getting B2BUA vendors (and their owners) to pass a generic header through unless they know its purpose.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Jul 2010 10:03:11 -0400

> Sent: Friday, July 23, 2010 9:26 AM
> To: Hadriel Kaplan
> 

This feels like déjà-vu, and I just found out why: I said the same thing back when this was discussed previously :)
here:
http://www.ietf.org/mail-archive/web/dispatch/current/msg01655.html

And here's Laura's reply:
http://www.ietf.org/mail-archive/web/dispatch/current/msg01668.html

-hadriel

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 23 Jul 2010 19:52:40 +0530

Can't we include the key, the pseudo-random number generated by the B2BUA, in a session-id header parameter so that the B2BUA doesn't have to share anything with the monitor? It should still be computationally infeasible to derive the original call-id from its hash, since neither this call-id not the key is reused later for another hash.

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Friday, July 23, 2010 7:33 PM
|To: Paul Kyzivat (pkyzivat)
|Cc: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02
|
|> -----Original Message-----
|> From: Paul Kyzivat [mailto:[email-masked]]
|> Sent: Friday, July 23, 2010 9:26 AM
|> To: Hadriel Kaplan
|>
|> ISTM the above can be solved without standardizing anything.
|> The first response to INVITE_1 will have the session id.
|> At that point the Monitor will know the correlation.
|
|This feels like déjà-vu, and I just found out why: I said the same thing
|back when this was discussed previously :)
|here:
|http://www.ietf.org/mail-archive/web/dispatch/current/msg01655.html
|
|And here's Laura's reply:
|http://www.ietf.org/mail-archive/web/dispatch/current/msg01668.html
|
|-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jul 2010 10:27:20 -0400

> http://www.ietf.org/mail-archive/web/dispatch/current/msg01668.html

Interesting.

I guess its hard to appreciate this without more detail about the goal 
and techniques of monitoring. My immediate reaction is that if there is 
no response to the initial INVITE, then there is precious little to 
monitor and the whole thing is moot.

I'm personally not finding this compelling. But certainly I'm not the 
last word on this.

The most disturbing parts about this to me are the ones that are only 
implied. E.g.  that key needs to provisionable and/or query-able in 
order for the use case to work.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Jul 2010 10:38:41 -0400

> Sent: Friday, July 23, 2010 10:23 AM
> To: Hadriel Kaplan; Paul Kyzivat (pkyzivat)
> 
> Can't we include the key, the pseudo-random number generated by the B2BUA,
> in a session-id header parameter so that the B2BUA doesn't have to share
> anything with the monitor? It should still be computationally infeasible
> to derive the original call-id from its hash, since neither this call-id
> not the key is reused later for another hash.

That wouldn't fulfill Requirement 2b in the draft: "The identifier must not reveal to the receiver of it that the Call-ID, tags, or any other SIP header or body portion have been changed by middle-boxes, with as high a probability as possible."

I think Laura's use-case isn't for some random monitor device introduced ad-hoc - it's really for a permanent monitor probe.  Such devices are currently deployed in lots of service providers.  They're deployed on a permanent basis, constantly monitoring SIP traffic.  So the idea would be for the operator to install the session-id key(s) on the probes or the probe-manager through an out-of-band method.  In other words, the process of putting the key in the monitor does not have to be elegant or defined, and isn't done very often.

I will ping the monitoring vendors again and see if some of them can join this conversation, although it may be easier to get them to do it once we get a WG for the concept... just so the mailing list they have to join will be more focused.

-hadriel

---

From: Daryl Malas <[email-masked]>
Date: Mon, 26 Jul 2010 02:53:30 -0600

Hadriel,

I read through the draft, and I have a couple of questions.  First, let me say, I tried to read through all of the various questions and comments to see if my questions are duplicative, but I may have missed something.  Please just point me to an applicable thread if one already exists.  Also, I am fairly new in reading this issue, so bear with me if these questions seem rather naive.

Questions:

1.  Does it make more sense to modify or update call-id rather than define a new session-id?
2.  Does it make more sense to create a new session-id or tell middle devices not to mess with the call-id?
3.  The draft implies that call-id does not work, but it does not provide any good background as to all of those reasons except that "middle" devices change it.  Why do they change it, so that this option does not work?

I think answering these questions in the draft will provide a better argument for the session-id, assuming there is one.

Regards,

Daryl

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Tuesday, July 13, 2010 6:38 PM
To: [email-masked]
Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02

Howdy,

The major changes are:

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Jul 2010 05:56:23 -0400

Hi Daryl,
That's because we've been debating this since 2008, and that topic was discussed back then. :)
The argument was that a B2BUA has to change the Call-ID, per RFC 3261 and it being a UAC.  I can't remember the technical reason it had to - I thought it was for things like the dialog event-package, so when something subscribes to it on the B2BUA the B2BUA will know which dialog is actually being referred to (there is at least a UAS and UAC dialog, and possibly multiple).  But some of us were talking about this last night and couldn't figure out why just having unique From-tags wouldn't be sufficient (other than rfc2543 devices, which we can ignore for this case).

But anyway, when I first presented this in 2008 and raised b2bua's not changing the call-id, the feedback on the mic was that rfc3261 mandated it and we shouldn't be mucking with that.

-hadriel

________________________________
From: Daryl Malas [mailto:[email-masked]]
Sent: Monday, July 26, 2010 4:54 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: RE: Updated: draft-kaplan-dispatch-session-id-02

Hadriel,

Questions:

Regards,

Daryl

The major changes are:

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 27 Jul 2010 19:25:33 +0530

|That wouldn't fulfill Requirement 2b in the draft: "The identifier must

|not reveal to the receiver of it that the Call-ID, tags, or any other
SIP 
|header or body portion have been changed by middle-boxes, with as high
a
|probability as possible."

This makes sense.

|So the idea would be for the operator to install the session-id key(s) 
|on the probes or the probe-manager through an out-of-band method.  In 
|other words, the process of putting the key in the monitor does not
|have to be elegant or defined, and isn't done very often.

It is hard to imagine they would be using randomly generated keys or
provisioning them on the monitor using an out-of-band mechanism on a
call-by-call basis -- seems would make it difficult for other similar
vendors to implement. 

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Friday, July 23, 2010 8:09 PM
|To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat)
|Cc: [email-masked]
|Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02
|
|
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|> Sent: Friday, July 23, 2010 10:23 AM
|> To: Hadriel Kaplan; Paul Kyzivat (pkyzivat)
|>
|> Can't we include the key, the pseudo-random number generated by the
B2BUA,
|> in a session-id header parameter so that the B2BUA doesn't have to
share
|> anything with the monitor? It should still be computationally
infeasible
|> to derive the original call-id from its hash, since neither this
call-id
|> not the key is reused later for another hash.
|
|That wouldn't fulfill Requirement 2b in the draft: "The identifier must
not
|reveal to the receiver of it that the Call-ID, tags, or any other SIP
header
|or body portion have been changed by middle-boxes, with as high a
|probability as possible."
|
|I think Laura's use-case isn't for some random monitor device
introduced ad-
|hoc - it's really for a permanent monitor probe.  Such devices are
currently
|deployed in lots of service providers.  They're deployed on a permanent
|basis, constantly monitoring SIP traffic.  So the idea would be for the
|operator to install the session-id key(s) on the probes or the
probe-manager
|through an out-of-band method.  In other words, the process of putting
the
|key in the monitor does not have to be elegant or defined, and isn't
done
|very often.
|
|I will ping the monitoring vendors again and see if some of them can
join
|this conversation, although it may be easier to get them to do it once
we
|get a WG for the concept... just so the mailing list they have to join
will
|be more focused.
|
|-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Jul 2010 04:11:31 -0400

> Sent: Tuesday, July 27, 2010 9:56 AM

No the idea is it's the private key that is provisioned on the monitoring system, not the session-id values.  The same key would be used to generate all the session-id's, as per the algorithm in the draft.

-hadriel