Subject: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Nov 2008 19:36:36 -0500

Howdy,
I know it's bad form to submit a draft during the IETF, but oh well.
I submitted a draft for a call-id type thing that's not actually a call-id, to get through B2BUA's, for a bunch of uses noted in the draft.

Comments appreciated, as always.  Heckling welcomed too. :)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Tuesday, November 18, 2008 7:30 PM
> To: [email-masked]
> Subject: I-D Action:draft-kaplan-sip-session-id-00.txt
>
> 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-sip-session-id-00.txt
>         Pages           : 9
>         Date            : 2008-11-18
>
> There are several reasons for having a globally unique session
> identifier for the same SIP session, which can be maintained across
> B2BUA's and other SIP middle-boxes.  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-sip-session-id-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Laura Liess" <[email-masked]>
Date: Wed, 19 Nov 2008 04:20:49 +0100

Hadriel,

you bra

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "SIP List" <[email-masked]>
Sent: Wednesday, November 19, 2008 1:36 AM
Subject: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

Howdy,
I know it's bad form to submit a draft during the IETF, but oh well.
I submitted a draft for a call-id type thing that's not actually a call-id, 
to get through B2BUA's, for a bunch of uses noted in the draft.

-hadriel

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------------

---

From: "Laura Liess" <[email-masked]>
Date: Wed, 19 Nov 2008 04:28:37 +0100

Hadriel,
I am glad you bruoght up this issue. As a carrier, we need such a mechanism 
for diagnostics.
The problem which I  have with this particular solution is that it requires 
changes in existing user devices.

Regards
Laura

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "SIP List" <[email-masked]>
Sent: Wednesday, November 19, 2008 1:36 AM
Subject: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

Howdy,

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Nov 2008 00:24:13 -0600

> The problem which I  have with this particular solution
> is that it requires changes in existing user devices.

For UAs that don't generate session-id the first B2BUA 
could synthesize a session-id.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 01:49:27 -0500

Yeah I was going to mention that but I thought it would seem almost hypocritical.  :)
But it's true really - the draft is about B2BUA's not changing a Session-ID they received.  It doesn't say they can't mint a new one if one was NOT received, and indeed I would expect that's exactly what they'd do if the UAC didn't do it itself.  It would make it less useful for some of the use-cases, but it's better than nothing, and hopefully the header is such a trivial concept that UA's would implement it.

-hadriel

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2008 1:24 AM
> To: 'Laura Liess'; Hadriel Kaplan; 'SIP List'
> Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
>

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 19 Nov 2008 12:39:30 +0100

Dan, Hadriel,

I don't think that having the first B2BUA synthesize the session-id
would work. The idea is to have it end-to-end to solve the problem so
having it put in by a B2BUA would not solve the problems.

The bigger issue is what is to stop a B2BUA either removing the
session-id or generating one of its own. While this draft proposes B2BUA
actions the defined actions will only occur if the B2BUA fully
implements this draft.

RFC 3261 defines a B2BUA as a concatenation of a UAS and a UAC. What
happens between the UAS and UAC parts is undefined and there is no
specification as to what actions the B2BUA should take when passing a
request from the UAS to the UAC. There was a draft presented to the
sipping wg to try an define actions of B2BUAs but this was rejected by a
hum as dangerous. I guess that the consensus was that the B2BUA should
remain totally undefined so that it could perform any action that was
required. [Declaration of interest: I was a contributor to this now
expired draft.]

Hadriel,

A couple of additional items which may need to be considered in the
draft.

Is it possible to include a list of headers which currently use the
existing dialog identifiers? Others which you have not mentioned include
Target-dialog, Join and In-reply-to.

Is it proposed to propose modifications to the RFCs for the existing
headers which use dialog ids to use the session-id?

It is probably necessary to specify B2BUA actions in cases of 3PCC and
what happens to the session-id in these cases.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 19 November 2008 06:24
To: 'Laura Liess'; 'Hadriel Kaplan'; 'SIP List'
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Nov 2008 08:33:01 -0600

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ian Elz
> Sent: Wednesday, November 19, 2008 5:40 AM
> To: Dan Wing; Hadriel Kaplan
> Cc: SIP List

Yes.  But until UAs generate the header, the best you can do is have
the first B2BUA insert the header for the benefit of the rest of the
SIP network.  This is akin to the 'authentication proxy' described
in RFC4474, where the proxy inserts the authentication headers if
the UA hasn't done so.

> session-id or generating one of its own. 

Nothing stops the B2BUA from doing anything it wants.

> While this draft proposes B2BUA

That is correct.

Is the draft complex to implement?

> required. [Declaration of interest: I was a contributor to this now

Hadriel's draft attempts to do the opposite:  instead of defining
"these are the things a B2BUA is allowed to do", it is saying "a 
B2BUA, compliant with this specification, will pass the session-id
header".

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 10:18:38 -0500

> From: Ian Elz [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2008 6:40 AM
>

Can you describe why having a B2BUA generate a Session-ID, if and only if one was not in the message already, would be worse than not generating one at all?

> actions the defined actions will only occur if the B2BUA fully

The draft doesn't say what a B2BUA should do if no header exists.  It does not say the B2BUA can not generate one in such a case.  I consciously left that as a possibility, knowing it would be a while before UAC's would generate one.

> required. [Declaration of interest: I was a contributor to this now

I'll tackle those in a separate email.

> Target-dialog, Join and In-reply-to.

Funny you mention it - I was tempted to go do it in the draft, but I thought it wasn't really the place to do it because the list could change, and there're a bunch of proprietary ones too, and the goal of the draft isn't to change them.  So I figured it was better to just give a couple examples.  But I can certainly do it if you think it would be useful.

> headers which use dialog ids to use the session-id?

Nope.  If someone wants to propose that in the future that's up to them, but I'm not suggesting that for this draft.  I *do* think some of the XML packages that include them should consider the Session-ID as an alternative (not a replacement - just an alternative).  But only for the ones in draft status or proprietary ones, not published RFCs.

> what happens to the session-id in these cases.

Would it be any different?

Thanks for reviewing!

-hadriel

---

From: "Laura Liess" <[email-masked]>
Date: Wed, 19 Nov 2008 16:46:28 +0100

B2BUAs being able to generate a new header which contains a string 
correlated somehow (e.g. a hash) with the call-ID of the initial dialog 
would be, I think,  a good idea.   There are also two other drafts dealing 
with dialog correlation: 
http://www.ietf.org/internet-drafts/draft-worley-references-00.txt which 
proposes the References-header, containing the Call-ID of the initial dialog 
and 
http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt 
, discussing the requirements for dialog correlation. Both drafts have a 
quite different focus  but I do not see why we could not use/extend them to 
cover the B2BUA scenario.  The last draft is on the sipping agenda on 
Friday.

Regards
Laura

----- Original Message ----- 
From: "Dan Wing" <[email-masked]>
To: "'Ian Elz'" <[email-masked]>; "'Hadriel Kaplan'" 
<[email-masked]>
Cc: "'SIP List'" <[email-masked]>
Sent: Wednesday, November 19, 2008 3:33 PM
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 10:48:59 -0500

> session-id or generating one of its own.

Nothing can stop a B2BUA from doing what its customer wants it to do.  Nothing can stop a UA or Proxy or Gateway from doing what they want to do either.  None of us are compliance angels, and the customers own the products, not the IETF.
All we can do is define a specification, and say what something that supports a mechanism must do to comply with the spec.  We can't force compliance on any product of any type, and there is no compliance police.

However, if we can show the value of complying to the spec, and don't try to make the device do what its customers don't want it to do, then it has a much better chance of being complied with.

And of course a B2BUA may simply just not implement/support this draft, just like a UA doesn't need to implement sip-outbound or gruu or ICE or a myriad of other IETF drafts/RFCs.

> required. [Declaration of interest: I was a contributor to this now

You mean the transparent-b2bua draft?  I don't remember what the consensus was in terms of whether it was specific to that draft or to anything about b2bua's.  I think there was concern about the type of things that draft tried to address, because it was suggesting behavior of B2BUA's that would potentially change currently deployed behavior, and its scope was rather large and people were worried about all the different types of things B2BUA's do and need to do that would need to be taken into account.

That's not the case for this Session-ID draft.

-hadriel

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 19 Nov 2008 17:00:13 +0100

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 19 November 2008 14:33
To: Ian Elz; 'Hadriel Kaplan'
Cc: 'SIP List'
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

[Ian Elz ] But there is no point having the B2BUA insert the header as
this doesn't solve the main problem, routing to the B2BUA where the
mapping occurred. 
Example: The UA which does not support the session-id will generates a
new request containing a Target-dialog with the existing dialog
identifiers. The problem of routing the new Request to the B2BUA which
inserted the session-id in the original request remains. If the original
request was forked then a Target-dialog using a dialog id would refer to
one forked dialog whilst the session-id would potentially refer to all
the forked dialogs. 

Unfortunately this is not as simple as inserting authentication headers
as authentication headers are only used by the one party to validate the
identity of the other party for the specific request. In this case the
session-id will be used in separate requests which reference other
requests. You need to ensure that you can route to the B2BUA which
inserted the session-id to map between the session-id and the dialog
identifiers. This is the problem that exists without the session-id and
this still needs to be solved.

[Ian Elz ] Agreed

That is correct.

[Ian Elz ] The part relating to passing a session-id transparently from
one side to the other does not appear difficult. The logic to map from
dialog-ids to session-id as discussed above is another matter.

[Ian Elz ] The previous draft was an attempt to define what things a
B2BUA should do to be as proxy like in the network. There were also
proposals as to how Requests containing the headers which reference
other dialogs are routed in the network.
The attempt was to define what things a B2BUA must do and which it
should not. I still believe that this needs to be defined.

-d

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 19 Nov 2008 17:02:30 +0100

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 19 November 2008 15:19
To: Ian Elz; Dan Wing
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

> having it put in by a B2BUA would not solve the problems.

Can you describe why having a B2BUA generate a Session-ID, if and only
if one was not in the message already, would be worse than not
generating one at all?

[Ian Elz ] I don't think that it will be worse but it won't solve the
problem. The biggest problem with the existing mechanism is that B2BUAs
map the call-id and tags (if they didn't then they would probably be
called proxies). The key issue when using the headers and event packages
which use dialog identities is that you need to route the new request
through the correct B2BUAs in the correct order to map the dialog
identity in the header or event correctly. If the session-id is inserted
by a B2BUA then the issue of routing a new request to this B2BUA still
exists.

> actions the defined actions will only occur if the B2BUA fully

The draft doesn't say what a B2BUA should do if no header exists.  It
does not say the B2BUA can not generate one in such a case.  I
consciously left that as a possibility, knowing it would be a while
before UAC's would generate one.

[Ian Elz ] Except that we are having a discussion about having a B2BUA
inserting a session-id.

[Ian Elz ] OK. This isn't an issue with the draft just an observation as
to what has happened in the past.

> Target-dialog, Join and In-reply-to.

Funny you mention it - I was tempted to go do it in the draft, but I
thought it wasn't really the place to do it because the list could
change, and there're a bunch of proprietary ones too, and the goal of
the draft isn't to change them.  So I figured it was better to just give
a couple examples.  But I can certainly do it if you think it would be
useful.

[Ian Elz ] Personally I think that this would be useful (I keep finding
new ones hidden away). It would only be informative at the date of the
draft. I don't think that any proprietary ones should be mentioned, only
those in RFCs.

> headers which use dialog ids to use the session-id?

Nope.  If someone wants to propose that in the future that's up to them,
but I'm not suggesting that for this draft.  I *do* think some of the
XML packages that include them should consider the Session-ID as an
alternative (not a replacement - just an alternative).  But only for the
ones in draft status or proprietary ones, not published RFCs.

[Ian Elz ] OK. This is a problem for the future then. The existing
problems based upon the existing header definitions will and mapping of
the dialog identities will remain for the present. Until these changes
are done however the usage of the session-id will be limited.

[Ian Elz ] Possibly. In simple 2 party 3PCC then probably not. The B2BUA
can simply generate a session-id and pass it to the parties at both
ends. If you have a more complicated cases involving more than 2 parties
then there may be issues. I will look at these separately.

Thanks for reviewing!

[Ian Elz ] That's fine. I am looking at how the dialog mapping can be
solved in IMS and an end-to-end identifier was one option to be
considered. This gives me the opportunity to examine this option and to
have other people involved.

-hadriel

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 19 Nov 2008 17:15:48 +0100

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 19 November 2008 15:49
To: Ian Elz; Dan Wing
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

> session-id or generating one of its own.

Nothing can stop a B2BUA from doing what its customer wants it to do.
Nothing can stop a UA or Proxy or Gateway from doing what they want to
do either.  None of us are compliance angels, and the customers own the
products, not the IETF.
All we can do is define a specification, and say what something that
supports a mechanism must do to comply with the spec.  We can't force
compliance on any product of any type, and there is no compliance
police.

However, if we can show the value of complying to the spec, and don't
try to make the device do what its customers don't want it to do, then
it has a much better chance of being complied with.

And of course a B2BUA may simply just not implement/support this draft,
just like a UA doesn't need to implement sip-outbound or gruu or ICE or
a myriad of other IETF drafts/RFCs.

[Ian Elz ] Agreed. B2BUAs are a world apart. They do have to support the
basic UAC/UAS functionality in RFC 3261, or at least they should. The
problem is that there is nothing which defines how they should behave to
any extent, e.g. passing on received headers etc, mapping Contacts if
Call-id or tags are mapped.

> required. [Declaration of interest: I was a contributor to this now

You mean the transparent-b2bua draft?  I don't remember what the
consensus was in terms of whether it was specific to that draft or to
anything about b2bua's.  I think there was concern about the type of
things that draft tried to address, because it was suggesting behavior
of B2BUA's that would potentially change currently deployed behavior,
and its scope was rather large and people were worried about all the
different types of things B2BUA's do and need to do that would need to
be taken into account.

[Ian Elz ] That's the one. I was not at the IETF when the draft was
rejected so I don't know what happened in the room at the time. I don't
think that the draft was trying to specify any specific behavior, it was
not Standards Track, but was recommending what types of things a B2BUA
should do to behave well in the network and the behavior to solve
specific problems, e.g. the dialog reference header mapping issue.
The scope of the transparent b2bua draft was large but the longer such
work is delayed the larger it becomes.

[Ian Elz ] Hopefully not. Specifying the header should not be a large
task. The hard part will be how it is used in specific network scenarios
and how it interworks with the existing mechanism based upon dialog ids.
If the draft gets pushed down that route then it could be a long haul. 
Has there been a sipping draft identifying a specific problem to be
solved and identifying requirements for this header?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 14:25:12 -0500

> Sent: Wednesday, November 19, 2008 11:03 AM
>

Ahh, but it will solve the problem far more often than not doing anything.  It will work for no matter how many hops after the first one - it just won't work if the new request gets routed *past* the first b2bua that created it.

So, for example:
Let's say your access SBC inserts it (or P-CSCF in IMS terminology).  It always works, because all requests going to the UA endpoint have to get through that node to get to the UA.

Let's say the proxy-registrar does it (the S-CSCF).  It always works, assuming you route requests to such a device before they get to the endpoint/UA.

Let's say the peering SBC does it (the I-BCF), or the app server, feature server, PSTN-gateway, whatever - it only works if the new request which needed the match is routed through that first Session-ID-inserting B2BUA; and that is *still* better than what we have now, which as you said is the new request has to flow back through the whole path.

-hadriel

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Nov 2008 13:37:39 -0600

At 12:49 AM 11/19/2008, Hadriel Kaplan wrote:

>But it's true really - the draft is about B2BUA's not changing a 
>Session-ID they received.

maybe its also about the first B2BUA inserting one where there isn't 
(on the UAS back side), and not changing it on the UAC back side - 
then just in general about not having any subsequent SIP 
server/B2BUA/SBC changing a received session-id, maybe

>It doesn't say they can't mint a new one if one was NOT received, 
>and indeed I would expect that's exactly what they'd do if the UAC 
>didn't do it itself.  It would make it less useful for some of the 
>use-cases, but it's better than nothing, and hopefully the header is 
>such a trivial concept that UA's would implement it.
>
>-hadriel
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Nov 2008 13:39:28 -0600

At 08:33 AM 11/19/2008, Dan Wing wrote:
>SIP network.

from that pov, why not have the first SIP server insert the header 
(whether or not it's a B2BUA)?

>This is akin to the 'authentication proxy' described

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Nov 2008 13:52:21 -0600

> From: James M. Polk [mailto:[email-masked]] 
> Sent: Wednesday, November 19, 2008 1:39 PM
> To: Dan Wing; 'Ian Elz'; 'Hadriel Kaplan'
> Cc: 'SIP List'
> > > Subject: Re: [Sip] FW: I-D 
> Action:draft-kaplan-sip-session-id-00.txt
> > >
> > > Dan, Hadriel,
> > >

Absolutely.

-d

> > > Subject: Re: [Sip] FW: I-D 
> Action:draft-kaplan-sip-session-id-00.txt
> > >

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Nov 2008 14:48:39 -0500

> Sent: Wednesday, November 19, 2008 2:39 PM
>

Huh, I forgot there were other things. ;)

Fair enough - I'll add that in the next revision.

We'll also need to deal with scenarios where two calls are joined by a b2bua (e.g., out-of-dialog REFER/Invite with Replaces is terminated by a  middlebox).  Someone raised this issue over lunch.  I think it's not too hard to address unless one or more of the parties don't support Session-ID but others do, and that will be hard.  At some point they are logically two different sessions really.

-hadriel

---

From: [email-masked]
Date: Wed, 19 Nov 2008 20:21:06 -0500 (EST)

In regard to adding a Session-Id to requests are not given one by the
UAC:

A B2BUA can add one, of course.  But a proxy can also add a header to
a request, and can remain strictly RFC 3261 compliant while doing so.

A larger problem is that this added Session-Id is not observable from
the "input" side of the B2BUA, meaning that the correlation between
the incoming Call-Id and the Session-Id can only be reliably extracted
from the B2BUA itself, which obviates much of the value of Session-Id.
However, the B2BUA can create a 100 response to the request that
contains the Session-Id header and can send it to the upstream
element.  This makes the added Session-Id manifest to any network
logging.

Which leads to the question of whether we want to include Session-Id
in responses as a matter of course (as we do Call-Id).

Also, given the intended ubiquity of Session-Id, a one-letter
abbreviated header name should be defined.

Dale

---

From: [email-masked]
Date: Wed, 19 Nov 2008 20:22:59 -0500 (EST)

I see:

   8. Security Considerations 
    
   There are no specific security issues for this mechanism, beyond 
   those already applicable to SIP-based session signaling. [TBD]

   9.   IANA Considerations 
    
   This document makes no request of IANA. 

And yet there are significant security considerations.  E.g.:

   The reason for specifying the mechanism, and its length, is to make
   it impossible to determine the manufacturer of the device which
   generated it by looking at its format or value.

And of course the entire *purpose* of the draft is to define a
standardized header, which is an IANA consideration.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Nov 2008 20:56:52 -0500

> element.  This makes the added Session-Id manifest to any network

Since 100 is hop by hop, that response will only be seen by the prior 
node. I'm not seeing the value in this.

Even if it were a 1xx that went all the way back to the UAC, the nodes 
that would get to see it would by definition be ones that don't 
understand it and so will not use it for anything.

Specifically, *subsequent* requests in the same dialog won't carry the 
same value, at least until the node that inserted the value is reached, 
if it is reached. And even then the same value won't be inserted unless 
the inserting node is dialog stateful. That argues for only having 
dialog stateful elements insert the header.

Ultimately, for it to be useful, the node that wants to make a reference 
must be aware of the value. AFAIK that is usually the UAC.

> abbreviated header name should be defined.

:-)

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 01:06:28 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>
> I see:
>

Quite true - my mistake.

> standardized header, which is an IANA consideration.

Yeah Bob pointed that out to me too the second after I submitted it.  D'oh!
Thanks for catching them!

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 09:38:42 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
>

Although the draft mentions a UUID as one option, it leaves the mechanism to be decided.  One thing we could do instead of UUID, for example, would be to make it a hash of the received call-id and local system/node ID and MAC or some such.  In other words take some non-volatile system data munged with the call-id, and hash it to get the 128 bits of output for the Session-ID header value.  That way a stateless proxy can re-generate the same value again for upstream and downstream requests and responses, without it compromising or being re-create-able just from the call-id value and giving a reason for folks to remove it.
But I'll have to ask some security folks about that.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Nov 2008 09:54:42 -0500

> But I'll have to ask some security folks about that.

Well, if there is already enough unchanging info that survives middle 
boxes, then we don't need the header - we can just tell everybody to use 
that.

Or, if you mean it is a hash of info that will then get munged, the 
header needs to be inserted by some box before the munging happens. And 
it still has the property that it is then only usable by those who are 
downstream.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 11:10:27 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, November 20, 2008 9:55 AM
>
>
> header needs to be inserted by some box before the munging happens.

Sure, and the question was if that inserting box could be a proxy.  The answer is yes, I think.  The generator of the Session-ID value should be the UAC, but can be any proxy or b2bua if the UAC did not do it.  The later the hop is in the path that does the generation, the less useful it becomes, but that's ok.

> And

But that's ok.  It's better than what we have now - it works in more cases than what we have now, for cases where one or more b2bua's change the call-id.  If nothing in the path changes the call-id, session-id doesn't break anything.  That's why I was saying it would be used as an alternative not replacement for things - i.e., if you subscribe for a dialog-event package, you could include both call-id+tag and session-id, such that if call-id+tags didn't match on the UAS, then session-id could be checked as a last resort.  If the UAS or UAC doesn't support session-id, that last resort won't succeed or be used either; but that's no worse, and gives a chance for it to succeed which is better.

-hadriel

---

From: [email-masked]
Date: Thu, 20 Nov 2008 14:22:46 -0500 (EST)

From: Hadriel Kaplan <[email-masked]>

   Although the draft mentions a UUID as one option, it leaves the
   mechanism to be decided.

In that regard, the draft is somewhat self-contradictory.  In one
place it mentions UUIDs and in another place, it specifies the
Session-Id as a crypto-random quantity.  But some UUID formats contain
the MAC address of the creator thereof, which violates the stated
security considerations.

   One thing we could do instead of UUID, for example, would be to
   make it a hash of the received call-id and local system/node ID and
   MAC or some such.  In other words take some non-volatile system
   data munged with the call-id, and hash it to get the 128 bits of
   output for the Session-ID header value.  That way a stateless proxy
   can re-generate the same value again for upstream and downstream
   requests and responses, without it compromising or being
   re-create-able just from the call-id value and giving a reason for
   folks to remove it.

You'll have to include in the hash a secret local key.  Otherwise an
adversary can check a guessed correspondence between a Call-Id and a
Session-Id.

Dale

---

From: [email-masked]
Date: Thu, 20 Nov 2008 14:22:52 -0500 (EST)

From: Paul Kyzivat <[email-masked]>

True, but I'm addressing a requirement that I haven't stated:
Enabling an "outside observer" to correlate network traces on the
various networks.  In practice, what you need is for the messages, as
captured in network traces, to carry enough information that you can
tell which messages are part of the same (logical) dialog.  The
Session-Id provides this information very nicely, as long as an
introducing middlebox-element emits some message on the input side
that reveals the input-side Call-Id with the Session-Id.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 04:09:23 -0500

> [email-masked]

Correct - I noted that before on the mailing list before submitting the draft that we wouldn't use the UUID based on MAC, but rather the pseudo-random one.  But I'm not tied to it being a UUID at all whatsoever - it was just an example - it's TBD based on WG input.

> adversary can check a guessed correspondence between a Call-Id and a

Yup exactly - that's what I meant by not being "re-creatable", and why I included a system/node ID and MAC into the equation.  Not really a secret local key per se - and maybe I should just say that instead in the draft.

Note the "adversary" so to speak is just that a downstream node can get a Call-ID and must not be able to tell from the Call-ID it got, what the Session-ID should be, so they can't tell the Call-ID was changed by a b2bua.  Of course an upstream node would be able to tell - for example the UAC would if it received a subscribe for the dialog-event that had a session-id it created, with a call-id+tags it didn't.  But then one of the main points of this exercise is to make those cases work.  I can't guarantee that all operators would want it to work in such cases, but for those that don't want it to, nothing will help us make it work.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Nov 2008 11:13:44 -0600

I want to make sure we're not going to re-hash all the call-id/to-tag 
mess some of use have had to live through already. Exactly what 
properties do you need this identity to have? For example, with your 
current draft, if the call forks to two automata that answer 
immediately, you'll end up with two valid sessions with the same 
"Session-ID." Is that what we want? If so, the term "Session-ID" is 
something of a misnomer. Perhaps "Session-Group-ID"?

/a

On 11/18/08 6:36 PM, Hadriel Kaplan wrote:
>> ------------------------------------------------------------------------
>>

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 27 Nov 2008 17:30:36 +0100

Dan, Hadriel,

I don't think that having a proxy insert the session-id would be
workable.

Take the following example.

UA-A does not support the session-id so it is not included in the
original request.

UA-A        Proxy1        Proxy2       Proxy3         UA-B
  |            |             |            |             |
  | INV B (F1) |             |            |             |
  |----------->|        INVITE B (F2)     |             |
  |            |------------>+----------->+------------>|
  |            |             |            |             |
  |            |        200 OK (F3)       |             |
  |   200 OK   |<------------+<-----------+<------------|
  |<-----------|             |            |             |

F1 INVITE [email-masked]
   Call-id: 123456789
   From: <[email-masked]>;tag=98765
   To: <[email-masked]>
   Contact: <[email-masked]>
   
F2 INVITE [email-masked]
   Call-id: 123456789
   From: <[email-masked]>;tag=98765
   To: <[email-masked]>
   Contact: <[email-masked]>
   Session-id: abcd1234

F3  200 OK
   Call-id: 123456789
   From: <[email-masked]>;tag=98765
   To: <[email-masked]>;tag=56789
   Contact: <[email-masked]>

Note that as UA-A here does not support the session-id that this has
been inserted by Proxy1.

What happens however if UA-B now tries to SUBSCRIBE to UA-A using the
dialog event.

Assuming the dialog event has been modified to allow the session-id.

UA-A        Proxy1        Proxy2       Proxy3         UA-B
  |            |             |            |             |
  |            |        SUBSCRIBE (F4)    |             |
  |            |<------------+<-----------+<------------|
  |            |             |            |             |

The problem here is how the SUBSCRIBE containing the dialog event
containing a session-id ensures that the new Request on a new dialog is
handled by Proxy1 to map the session-id to the call-id, to-tag, from-tag
format of the dialog event as handled by UA-A.

[If I may be flippant?]. It looks like there is a requirement for a new
header: "Pass-to-this-proxy-at-some-time" to ensure that the correct
proxy is included in the messaging sequence.

You could possibly use a ROUTE header but as UA-B does not know which if
any of the proxies inserted the session-id it would be necessary to
insert all the proxies which inserted themselves in the Record-Route of
F2 as Route headers in F4. This could however result in a lot of proxies
which would not normally want to see the SUBSCRIBE being involved in the
message sequence.

The issue is not as complex for a B2BUA as UA-B could use the Contact
received in F2 as the R-URI in the SUBSCRIBE (F4) which if the B2BUA
mapped the Contact would ensure that the B2BUA which inserted the
session-id would receive the new request.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 19 November 2008 19:52
To: 'James M. Polk'; Ian Elz; 'Hadriel Kaplan'
Cc: 'SIP List'
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

Absolutely.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Nov 2008 22:06:44 -0500

Hi Ian,
Thanks for your comments.  I should publish the update to this draft, because it now covers the middlebox-insertion-case in text, whereas before it was implicit.  And it adds text for UAC generation that was incomplete, because I forgot to put a critical aspect to this in the original draft about matching.

The basic concept is that if we want it to be usable as an alternative dialog-matching mechanism for out-of-dialog requests, then whomever generates a session-id has to have a local session-id lookup table, as does any device needing to perform matching.  That table would simply be a session-id value to dialog table, used for matching the value to a dialog.

If a device doesn't do this, then we get the troubleshooting properties but not the dialog-matching one, if a request gets to that specific node and the real dialog+tags don't match.

But it's true this would mean a Proxy that generates it *and* wanting to provide the matching property would need to be record-routing and have such a table, making it more stateful.

With regard to the issue not being as complex for B2BUA's because UA-B would send it to the B2BUA's contact:
Just being a B2BUA doesn't solve the problem without the match table being done somewhere.  The problem with dialog-event and such in out-of-dialog requests is not that B2BUA's can't "fix" it and set the contact to themselves to make sure they get the request - they do that already.  The problem is some of the requests aren't sent to their contact-URI to begin with.

For example, in the Derive case it's sending it to the From-URI, which B2BUA's sometimes do also change (ugh), but normally/hopefully to their domain not their hostname/IP; or better yet they leave it alone.  [I think that Derive is actually incorrect in sending it to the From-URI AoR, because it means the Derive message can end up at any contact for the AoR]

But the bigger issue is even if such things get sent to Contact-URIs and the Contact-URI's are GRUU's, in theory the GRUU does not specify a specific B2BUA instance, but instead the whole domain and thus can hit any number of B2BUA's getting into that domain.  We have been asked by some people in the IETF to leave contact GRUU's alone, and not replace them with the B2BUA's contact.  We'd be happy to do that if we can make requests going to the GRUU work, which without this type of matching mechanism they won't.

Ultimately the matching and troubleshooting properties work best if UA's generate the session-id themselves, and I hope it's simple enough that they do - but in the meantime B2BUA's or stateful proxies can do it for them to get it off the ground.  It won't solve all scenarios, but that's ok - it's making it better than nothing.

-hadriel

> Sent: Thursday, November 27, 2008 11:31 AM
> To: Dan Wing; James M. Polk; Hadriel Kaplan
> Cc: SIP List

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 28 Nov 2008 17:41:54 +0100

Hadriel,

May I take issue with your final statement "It won't solve all
scenarios, but that's ok - it's making it better than nothing."

Having something incomplete may be worse than nothing. We may have a
scenario where the partial solution gets implemented and then it will be
impossible to implement a final solution as you are required to be
backward compatible to the partial solution.

Let's try and get all the known problems out of this before it is
published. If as a result it only specifies the originating UAC
including the session-id then so be it. I don't want to get to a point
where middle node insert of modify the session-id and then have to
continue to support that scenario into the future.

That is not to say that all the problems will be identified. That only
happens when someone else tries to do something else in the future.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 28 November 2008 03:07
To: Ian Elz; Dan Wing; James M. Polk
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

Hi Ian,
Thanks for your comments.  I should publish the update to this draft,
because it now covers the middlebox-insertion-case in text, whereas
before it was implicit.  And it adds text for UAC generation that was
incomplete, because I forgot to put a critical aspect to this in the
original draft about matching.

The basic concept is that if we want it to be usable as an alternative
dialog-matching mechanism for out-of-dialog requests, then whomever
generates a session-id has to have a local session-id lookup table, as
does any device needing to perform matching.  That table would simply be
a session-id value to dialog table, used for matching the value to a
dialog.

If a device doesn't do this, then we get the troubleshooting properties
but not the dialog-matching one, if a request gets to that specific node
and the real dialog+tags don't match.

But it's true this would mean a Proxy that generates it *and* wanting to
provide the matching property would need to be record-routing and have
such a table, making it more stateful.

With regard to the issue not being as complex for B2BUA's because UA-B
would send it to the B2BUA's contact:
Just being a B2BUA doesn't solve the problem without the match table
being done somewhere.  The problem with dialog-event and such in
out-of-dialog requests is not that B2BUA's can't "fix" it and set the
contact to themselves to make sure they get the request - they do that
already.  The problem is some of the requests aren't sent to their
contact-URI to begin with.

For example, in the Derive case it's sending it to the From-URI, which
B2BUA's sometimes do also change (ugh), but normally/hopefully to their
domain not their hostname/IP; or better yet they leave it alone.  [I
think that Derive is actually incorrect in sending it to the From-URI
AoR, because it means the Derive message can end up at any contact for
the AoR]

But the bigger issue is even if such things get sent to Contact-URIs and
the Contact-URI's are GRUU's, in theory the GRUU does not specify a
specific B2BUA instance, but instead the whole domain and thus can hit
any number of B2BUA's getting into that domain.  We have been asked by
some people in the IETF to leave contact GRUU's alone, and not replace
them with the B2BUA's contact.  We'd be happy to do that if we can make
requests going to the GRUU work, which without this type of matching
mechanism they won't.

Ultimately the matching and troubleshooting properties work best if UA's
generate the session-id themselves, and I hope it's simple enough that
they do - but in the meantime B2BUA's or stateful proxies can do it for
them to get it off the ground.  It won't solve all scenarios, but that's
ok - it's making it better than nothing.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 13:22:03 -0500

I appreciate wanting to solve all possible scenarios (who doesn't! :), but I am fairly confident there is no possible solution to solve all possible scenarios.  I am also fairly certain we can't even anticipate or document all possible scenarios.

ISTM the only way to solve all possible scenarios is to have all B2BUA's stop changing call-id's and tags - in fact, to not have B2BUA's at all.  Because that is the assumption all RFC uses of callid+tags have made so far.

At this most recent IETF there appeared to be consensus that the real world has B2BUA's... LOTS of B2BUA's, of various flavors/roles/behaviors, from many vendors.  And there appeared to be consensus that we should try to make things work with them, as much as pragmatically possible.

> backward compatible to the partial solution.

I can't argue that some future mechanism can't be better than the session-id mechanism, obviously.  But I would point out the session-id mechanism would not prevent future mechanisms, any more than current call-id+tag usage prevents the session-id mechanism.  It would be a "if session-id match fails, then try this new thing if you understand it", or it could even be a "try this new thing first, and only if that fails or you don't understand it then try this session-id thing".  Every extension to SIP can have those properties as far as I know.  It just may need a parameter or new header to accomplish it.

But I also don't want to spend 4 years trying to come up with and standardize a perfect solution, and have the problem last for those 4 years plus whatever time it takes to actually deploy the new solution.  I'd rather have running code in weeks or months, and deployment as soon as possible - even if it means only some of the scenarios are covered but not all scenarios.  (and that's not a comment against your comments - I'm just noting that's how long things take when they're anything more than really simple)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Nov 2008 15:48:50 -0500

I think it might be worth some effort to attempt an agreement by which 
B2BUAs don't have to change callids. For instance, agree on some form of 
callid that b2bua's can recognize as "safe" - not including domain names 
that might leak some "proprietary" info about the source network.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Nov 2008 16:34:19 -0500

> Sent: Friday, November 28, 2008 3:49 PM
>

Yeah that's what I was hoping we could do too a while ago.  But it appears that won't succeed - B2BUA's are changing them for other reasons than just the security one.  One reason I know of is to track separate dialogs they create, ironically.  But I really don't know all the reasons they're doing it - there are lots of vendor devices doing it, and it's clear they're not all doing it for security purposes.

Doing this in a new header has another advantage over that as well, fwiw - if we mandate not changing "safe" call-id values, all b2bua's along the path have to stop changing it, and the UAC has to create a "safe" one.  If we do a new header, only some b2bua's need to change for matching to work in most cases.  All of them would need to pass the header for it to work, but my assumption is that's more likely.  It may be a false assumption, but from the traces I get to see, it looks like new headers get through fairly often. (at least those without URI's)

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 28 Nov 2008 23:40:51 +0100

Hi,

>Doing this in a new header has another advantage over that as well,
fwiw - if we mandate not changing "safe" call-id values, all b2bua's
along the path have to stop changing it, and the UAC has to create 
>a "safe" one.  If we do a new header, only some b2bua's need to change
for matching to work in most cases.  All of them would need to pass the
header for it to work, but my assumption is that's more 
>likely.  It may be a false assumption, but from the traces I get to
see, it looks like new headers get through fairly often. (at least those
without URI's)

As Hadriel said earlier, there are many reasons why b2bua's change the
call-id, and they would probably continue doing so no matter how "safe"
the call-id is...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Nov 2008 17:05:54 -0500

Sorry Adam somehow I missed your email,
The idea is to make it something benign enough that operators of B2BUA's would not feel the need to mess with it, with as high a probability as possible, while still have it be usable and useful.  One use for it is simply troubleshooting, but I'd like to make it usable to help resolve some dialog-matching scenarios that B2BUA's currently break.

The properties it needs to have to be as benign as possible, IMO, are:
1) Needs to not identify any identity property of the generator (no IP, no host, no domain, no MAC, no username, etc.).  If those are incorporated into the identifier, they must not be discernible to a receiver of the identifier.
2) Needs to not directly reveal the call-id/tags were changed.  This is in slight conflict with being usable for dialog-matching, but I put text in the latest draft why that's ok and B2BUA's shouldn't care. (and I will publish the latest draft ASAP)

Unfortunately, such a mechanism is not perfect for dialog matching uses.  For one, it needs both ends to support it - if middleboxes support it they can do it on behalf of the ends, but the farther away from the ends they are the less likely the matching will succeed.  It also needs B2BUA's to support it - if a B2BUA doesn't, then the matching won't work if it hits that B2BUA first.  I think that's all ok, because I think that's unavoidable, and it makes things better than they are now.

The other issue with it is a B2BUA can't use the session-id value alone for matching, because it wouldn't know which dialog side to match to (it has a UAS and possibly multiple UAC dialogs for the same session-id).  So the latest draft says matching is done with both the session-id and the remote-tag.  That also solves a security issue, fwiw.  But it means if any middleboxes along the path muck with the remote-tag, they could prevent the matching from succeeding, and we're back at square one.  The only solution to that I see would be to have surrogates for tags too, but I don't want to go that far down the rabbit hole and the draft does not.  If the WG takes this as a WG item, then it's all open to consensus of course.

-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Friday, November 21, 2008 12:14 PM
> To: Hadriel Kaplan
> Cc: SIP List

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 1 Dec 2008 10:35:01 +0100

Hadriel,

I am not expecting all problems to be solved, just to not introduce new
ones.

I believe that allowing a proxy to include a session-id header will
introduce more problems than it solves.

I know that we have to work with B2BUAs, and I understand the sentiment
behind getting rid of them all together. The ietf work tends to preclude
handling by B2BUAs but based upon the RFC3261 definition of a B2BUA as a
concatenation of the UAC and UAS then all the ietf specifications have
to ensure is that each Request can be routed to the correct B2BUA and
then it is up to the B2BUA to ensure that it performs the correct
actions for the end-to-end service.

Based upon RFC3261 a B2BUA MUST map the call-id as a Call-id MUST be
globally unique. As a B2BUA is a UAS/UAC the dialogs on either side of
the B2BUA are different dialogs and must have different Call-ids.

The major issue which currently occurs is that a PUI is used to try and
route a request which should be directed to specific UA, e.g. when
referencing an extant dialog. To reach the specific UA the Contact
should be used and if a B2BUA maps the Contact as well as the Call-id
then the new Request should route to the B2BUA which can perform its
'magic' to provide the end-to-end service.

The problem at present is that B2BUA behavior is not defined and many
implemented B2BUAs will not perform the correct actions to provide the
end-to-end service.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 28 November 2008 18:22
To: Ian Elz; Dan Wing; James M. Polk
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

I appreciate wanting to solve all possible scenarios (who doesn't! :),
but I am fairly confident there is no possible solution to solve all
possible scenarios.  I am also fairly certain we can't even anticipate
or document all possible scenarios.

ISTM the only way to solve all possible scenarios is to have all B2BUA's
stop changing call-id's and tags - in fact, to not have B2BUA's at all.
Because that is the assumption all RFC uses of callid+tags have made so
far.

At this most recent IETF there appeared to be consensus that the real
world has B2BUA's... LOTS of B2BUA's, of various
flavors/roles/behaviors, from many vendors.  And there appeared to be
consensus that we should try to make things work with them, as much as
pragmatically possible.

> backward compatible to the partial solution.

I can't argue that some future mechanism can't be better than the
session-id mechanism, obviously.  But I would point out the session-id
mechanism would not prevent future mechanisms, any more than current
call-id+tag usage prevents the session-id mechanism.  It would be a "if
session-id match fails, then try this new thing if you understand it",
or it could even be a "try this new thing first, and only if that fails
or you don't understand it then try this session-id thing".  Every
extension to SIP can have those properties as far as I know.  It just
may need a parameter or new header to accomplish it.

But I also don't want to spend 4 years trying to come up with and
standardize a perfect solution, and have the problem last for those 4
years plus whatever time it takes to actually deploy the new solution.
I'd rather have running code in weeks or months, and deployment as soon
as possible - even if it means only some of the scenarios are covered
but not all scenarios.  (and that's not a comment against your comments
- I'm just noting that's how long things take when they're anything more
than really simple)

-hadriel