Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 05 Feb 2010 08:35:15 -0500

Hadriel Kaplan wrote:

> >>  I've re-submitted a draft I originally submitted to the SIP WG back
> >>  when it was in existence.  The draft defines a session correlation
> >>  identifier for troubleshooting purposes.

> >>  > There are several reasons for having a globally unique session
> >>  > identifier for the same SIP session, which can be maintained across
> >>  > B2BUAs and other SIP middle-boxes.  This draft proposes a new SIP
> >>  > header to carry such a value: Session-ID.

Spencer Dawkins adds:

> I'm remembering that Hadriel had two drafts at about the same time - one was 
> a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot of 
> confusion during discussions.
> 
> So I'm hoping that at least some of the objection was caused by confusion!
> 
> https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ and
> https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just for 
> the record...

I agree with Hadriel that the 'secure call id' draft actually solves
some different problems (and think that draft should certainly be
progressed - we've already started implementing the ideas in it in some
of our user agents). 

The problem of correlation across middleboxes of various kinds is
certainly an important one, and deserving of attention.  

I'd like to point out that there is another draft that helps with some
of the other more complex scenarios in which one is attempting to
determine the relationship between different sessions: 

        http://tools.ietf.org/html/draft-worley-references
        The References Header for SIP

we've also been using this in our products and found it very useful.

With respect to what to do about the session-id proposal: I think that
in some perfect world that we don't live in, it would be better to adopt
the secure-call-id proposal and also make the rule that such ids MUST
NOT be changed when passing through a B2BUA; the call-id would then have
the characteristics that the session-id needs.  I accept, however, that
this big a change to the handling of call-id by existing products is
unlikely.

It seems to me that session-id as proposed is valuable iff we can reach
a consensus that existing non-proxy middleboxes (whether they are called
SBCs or Application Servers or whatever) will pass these through
unmodified, or at least that in some reasonable time they can be
convinced to start doing so.  Based on the discussion to date, I'm not
yet convinced of that...

I wonder whether or not it's time that we bit the bullet and try to
actually comprehensively write down what the correct and harmful
behaviors for non-proxy middleboxes are?

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 5 Feb 2010 08:47:53 -0500

> behaviors for non-proxy middleboxes are?

I think there is merit is providing guidance. SIP middle boxes are here to
stay.

There is some stuff along these line in the expired
http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01

(although I Just noticed Dale's new draft
http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 and I'm
not sure if there is any overlap).

Peter

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Feb 2010 14:56:28 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott Lawrence
> Sent: 05 February 2010 13:35
> To: Spencer Dawkins
> Cc: [email-masked]; 'Hadriel Kaplan'
> Subject: Re: [dispatch] FW: 
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
> 
> Hadriel Kaplan wrote:
> 
[JRE] If somebody is able to put together a draft, that would be good. However, bear in mind that some non-proxy middle-boxes carry out 3PCC, and this can lead to situations where the two ends of a call can comprise components of two former calls, and therefore will not have the same call-ID even if the two former calls had the same call-ID end-to-end. Yes, I know SIP has capabilities that theoretically make 3PCC unnecessary, but practical situations are likely to mean it stays around for the foreseeable future, e.g., policies that don't admit a REFER from another domain.

John

> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 05 Feb 2010 09:03:16 -0500

On Fri, 2010-02-05 at 14:56 +0100, Elwell, John wrote:
> [JRE] If somebody is able to put together a draft, that would be good.
> However, bear in mind that some non-proxy middle-boxes carry out 3PCC,
> and this can lead to situations where the two ends of a call can
> comprise components of two former calls, and therefore will not have
> the same call-ID even if the two former calls had the same call-ID
> end-to-end. Yes, I know SIP has capabilities that theoretically make
> 3PCC unnecessary, but practical situations are likely to mean it stays
> around for the foreseeable future, e.g., policies that don't admit a
> REFER from another domain.

Adding a References header as proposed in Dales draft helps with
correlating those situations.

---

From: Ian Elz <[email-masked]>
Date: Fri, 5 Feb 2010 16:52:09 +0100

The contents of the two drafts mentioned below is basically similar. The original draft contained more detail (and was perhaps harder to read as a result) but the proposals are the same.

The solution proposed is only applicable managing mapped dialog identities in the headers which reference other dialogs. The problem should be expanded to include bodies which reference other dialogs. This was mentioned in draft-marjou but a solution was not explored.

The problem with using a solution as proposed in these drafts is that to perform the dialog mapping in the bodies requires every node which modifies a dialog identity parameter (call-id,to and from tags) to be able to understand every body which may contain a reference to other dialogs. I don't believe that this is practical. To require that every B2BUA should be able to decode, modify, and re-encode every body which may contain a dialog reference is impractical.

Hadriel's secure call id draft goes some way to solving the problem of nodes mapping the call-id but it will not solve the issue. B2BUAs also modify the to and from tags in the dialogs on either side of the B2BUA. Just using an unchanged secure call id will not solve the issue when the tags are also mapped.

The original Session-id proposal to use an end-to-end identifier which would be passed transparently has more promise of a final solution. It was a shame that the usage of this proposed header was deprecated to just tracing before the full opportunities could be explored. I understand that there are issues associated with forking and 3PCC but these should be resolvable.

As for guidance then this is probably a good thing but it will only ever be guidance. There are too many nodes deployed which will not follow any guidance to ensure that they all follow ant rules which are written now. It is also easier to insert a B2BUA to overcome a specific problem as you can move outside the defined protocol rules inside the node.

Ian Elz

________________________________
From: Peter Musgrave [mailto:[email-masked]]
Sent: 05 February 2010 13:48
To: Scott Lawrence
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt

I think there is merit is providing guidance. SIP middle boxes are here to stay.

There is some stuff along these line in the expired http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01

(although I Just noticed Dale's new draft  http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 and I'm not sure if there is any overlap).

Peter

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 5 Feb 2010 18:58:39 +0100

Hi Scott,

> behaviors for non-proxy middleboxes are?

Please check draft-elwell-sip-e2e-identity-important, Section 8:
Analysis of changes to SIP requests by B2BUAs

http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03#section-8

I believe folks may have a divergence of opinion on what is considered
correct and what is considered harmful

Cheers,
-- 
Victor Pascual Ávila

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 05 Feb 2010 14:56:45 -0500

On Fri, 2010-02-05 at 14:56 +0100, Elwell, John wrote:
> If somebody is able to put together a draft, that would be good.
> end-to-end.

This is an important point about any proposed correlation mechanism:  In
various situations, as Paul describes, an element discovers that two
dialogs are correlated *after* they have been in existence some time,
which is after any putative correlation identifier has been assigned to
each call.

The advantage of Session-Id is that it addresses what is really a very
narrow application scenario, a call proceeding through an SBC, but one
that is very common.  Because of its simplicity, it has a higher chance
of being adopted.  It is not a complete solution, but it provides a lot
of value anyway.

On the other hand, if one wants a correlation mechanism that is
effective for a wide range of scenarios, one usually runs up against the
correlation-post-facto problem.  That more general case can't be solved
by assigning each dialog a unique correlation identifier.  You have to
have some method of declaring the correlation of two pre-existing
dialogs that share no identifiers.  (That's the approach taken in
http://tools.ietf.org/html/draft-worley-references.)

Dale