Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt

On Sat, 2008-11-29 at 17:05 -0500, Hadriel Kaplan wrote:
> 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.

So... given that we already have a call-id that _should_ already have
all the matching properties you want if B2BUAs would just leave it alone
(changing tags as a message passes through a B2BUA should provide the
required dialog uniqueness while leaving the call-id to recognize the
relationships), what is wrong with just creating a new set of rules for
how to construct a call-id so that it has the other properties you
suggest? 

You could even add a magic cookie to the beginning as was done with Via
branch ids to declare that the call-id is a session-id that should be
preserved.  Then it's easy to detect who supports it and understands the
semantics.  

I don't think that reformulating call-id is any harder to deploy than a
new header would be.



_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip