Re: [Insipid] Will the identifier pass unchanged through B2BUAs?

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 31 July 2013 10:27 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED9A21F9F5B for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 03:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.404
X-Spam-Level:
X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtei-dDE5K2E for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 03:27:08 -0700 (PDT)
Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id CA44C21F9FF1 for <insipid@ietf.org>; Wed, 31 Jul 2013 03:27:07 -0700 (PDT)
Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 6yRG1m0021wfjNsA7yT7gt; Wed, 31 Jul 2013 10:27:07 +0000
Received: from dhcp-15fb.meeting.ietf.org ([130.129.21.251]) by omta23.emeryville.ca.mail.comcast.net with comcast id 6yQx1m00G5R2GH68jyR0WB; Wed, 31 Jul 2013 10:25:05 +0000
Message-ID: <51F8E5F3.6050101@alum.mit.edu>
Date: Wed, 31 Jul 2013 12:24:51 +0200
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: insipid@ietf.org
References: <51F7A26B.1000704@ericsson.com> <C6504F53-FAF0-4DBF-811D-DD7960961B2B@oracle.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com>
In-Reply-To: <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375266427; bh=iLoJ3pNK8wrVpCmmLi8fGV+AZnkfXJbOcdlU4mkng9Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K2F31aJkQnoo2vbTw7GPoiGxS3Py5Z/LMYdS0Fj8KeuWOCG00MrtDbj1JlMEV/gfp fgLzNsaPgtwA6f8LzwehJtRFS0ScVNzrDsj2BaFccLe44WzRdSGkGHFIbR9Y2cQ9qv 8OOT04lbbOVlcUVfbnEXhogj5vEczQlJGGSc3nclbwDJo4gHepwMP5CDXvX5sw5J1l zT10rRqXA7da/wfsmh7rdWKkarcBQARjGopeHrbN0b7lY5n7qcsuDHLrym7zfjFNy+ c/TidbK7FdBeud8WrXeGqPpGrW4j+nWQz4xW40w83FsFVX6iesNvMm3JgbCaEfytOP NNb62bNrfCZwg==
Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs?
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 10:27:14 -0000

On 7/31/13 11:58 AM, Hadriel Kaplan wrote:
>
> I don't think it's a failure of specification, in either requirements or solution; and it's not fair to hold up work or raise a red flag just because of a personal hunch.  I am not asking to hold up anything, nor raising a red flag for INSIPID.  It's just a personal observation that when we use things for more than their originally intended use-case, or when it becomes complicated, interoperability issues happen or other motivations exist, that end up with having SBCs changing stuff.
>
> When we began the INSIPID work, back in DISPATCH, there was general agreement/understanding that we couldn't make mandatory compliance statements for B2BUAs and expect them to comply to it simply because it's in an RFC.  Instead, we had to define mechanisms which a B2BUA would have no need to change/muddle-with, that its operators would want to leave alone, for some beneficial purpose that the operators/owners of the B2BUAs would want.
>
> So when I submitted the Session-ID draft, the main goal/use-case for it was to help troubleshooting.  After much discussion of things that could go wrong with any other use of it, there was some consensus that if we use Session-ID for anything else, then things will go wrong somewhere or people will want to control it, resulting in B2BUAs modifying the value somewhere or other.  Thus it would lose the troubleshooting value a bit, and lose the end-to-end property in some cases.
>
> The truth is we in the IETF don't care much about having a new header simply/only for troubleshooting purposes.  We're not good about Operations-type considerations in the IETF RAI group.  We want new features.  So when I ask people what they're planning to use Session-ID for if not just troubleshooting, the answers I get are for call-control related purposes: things like QoS bandwidth CAC, out-of-dialog message correlation, and various "policies".  By definition, that means the Session-ID string will have a direct correlation to whether calls/messages/mechanisms fail or succeed, and thus my hunch is SBCs will end up changing the string in certain scenarios to make it match or not-match other calls/messages.  It's just a hunch, and I have no proof, though I can already imagine scenarios where we'd end up doing that.
>
> But this is just a personal observation, and there's nothing wrong with INSIPID continuing down the path it's on since it's clear people want it for the purposes they want it for.  I was only commenting in the STIR list, that for *STIR* purposes we couldn't rely on it for end-to-end caller-id verification.

Well, the point of doing the work was to get an id that would survive 
e2e, in spite of b2buas, for use in *some* way or ways. If it is likely 
not to survive e2e, for whatever reason, then ISTM there is no point in 
progressing the work.

The fact that you are only offering a "hunch" about survivability 
doesn't make it a strong justification for giving up on the work. We 
aren't likely to get any definitive answers. But maybe we can solicit 
opinions from those who might have influence over the survivability of 
the session id. Maybe we can ensure that it will survive if we promise 
not to use it for anything useful.

Just plunging ahead in blissful ignorance doesn't seem like a good plan.

	Thanks,
	Paul

> -hadriel
>
>
> On Jul 31, 2013, at 5:00 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
>
>> On 7/31/13 10:40 AM, Hadriel Kaplan wrote:
>>> No, there's nothing wrong with the requirements document.  My email wasn't about the requirements document, nor addressed to INSIPID - it was an email in the STIR mailing list related to using an INSIPID Session-ID for caller-id verification purposes.  That's all.
>>>
>>> The INSIPID requirements doc is fine.
>> Your mail, whether it was to INSIPID or not, says that INSIPIDs current trajectory will fail to meet the requirement in this document
>> (and will, in fact, fail to achieve the goal in its charter or even its name).
>>
>> I take this response to say you believe that failure is in the proposed solution document, not the requirements document.
>>
>> What do we need to change, then, in the proposed solution to not fail to meet the chartered goal (specifically the requirement called out below).
>>
>> RjS
>>>
>>> -hadriel
>>>
>>>
>>> On Jul 31, 2013, at 3:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
>>>
>>>> On 7/30/13 9:38 PM, Hadriel Kaplan wrote:
>>>>> Uhhh... just to be clear, I was making an individual comment in that email, not a corporate position statement or any some such.
>>>>>
>>>>> My point was that since the use-cases people are planning to do for INSIPID's Session-ID have now gone far beyond troubleshooting, the odds are we can't rely on it always being passed through end-to-end from originating Enterprises through various service providers to the far-end, without being modified in-transit.  I can't *prove* it won't be, but that's just my hunch, since we've seen this movie play out before.
>>>>>
>>>>> The good news is we don't need the Session-ID to be used in STIR for caller-id verification, so there's nothing to worry about.
>>>> Hadriel -
>>>>
>>>> This wasn't a question about STIR, it was a question about the publication of this INSIPID document.
>>>>
>>>> Look again at the requirement called out from the document below.
>>>>
>>>> Is your assertion that the proposed solution is not going to satisfy that requirement, or are you saying there's a problem with this requirement document being inconsistent (by requiring things that won't pass unchanged through intermediaries). If the latter, please re-engage the working group and fix the document (you are on the author list).
>>>>
>>>> RjS
>>>>> :)
>>>>>
>>>>> -hadriel
>>>>>
>>>>>
>>>>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just got a publication request for the requirements document:
>>>>>>
>>>>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08
>>>>>>
>>>>>> The following is one of the requirements in the draft, which was one of
>>>>>> the main reasons for creating this WG:
>>>>>>
>>>>>>>    REQ3: The solution must require that the identifier, if present, pass
>>>>>>>    unchanged through SIP B2BUAs or other intermediaries.
>>>>>> Hadriel, who works for an important SBC vendor and is one of the authors
>>>>>> of the requirements document, sent the comments below to the STIR list a
>>>>>> couple of weeks ago (see email below).
>>>>>>
>>>>>> How should I interpret those comments in the context of my AD review of
>>>>>> this document and, even more importantly, as the responsible AD for this
>>>>>> WG (as you know, we have had many scope-related discussions in the past)?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Subject: 	Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter)
>>>>>> Date: 	Tue, 16 Jul 2013 10:21:13 -0400
>>>>>> From: 	Hadriel Kaplan <hadriel.kaplan@oracle.com>
>>>>>> To: 	Richard Shockey <richard@shockey.us>
>>>>>> CC: 	IETF STIR Mail List <stir@ietf.org>
>>>>>>
>>>>>>
>>>>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" <richard@shockey.us> wrote:
>>>>>>
>>>>>>> I actually believe INSIPID is equally important to the overall task
>>>>>> since it
>>>>>>> is the track and trace elements of this that can ultimately enable some
>>>>>>> enforcement. I wish there was some more discussion on how the mechanisms
>>>>>>> would work at the edge SIP/SS7 network gateways since that clearly has
>>>>>> been
>>>>>>> the center of most of the reported problems.  I still think something
>>>>>> needs
>>>>>>> to be done to police that traffic but that is still ultimately a
>>>>>> regulatory
>>>>>>> effort.
>>>>>> I agree we need a tracking/tracing mechanism, but in my opinion we
>>>>>> cannot and should not rely on INSIPID Session-ID at all for that.  They
>>>>>> have gone beyond benign troubleshooting-type purposes now, which means
>>>>>> there is absolutely no guarantee the Session-ID will make it intact
>>>>>> across service providers in all cases.  In fact, my hunch is it won't.
>>>>>>
>>>>>> Regardless, the Session-ID isn't what we really need for tracing a bad
>>>>>> caller-id call.  Even without Session-ID, the service provider's CDRs or
>>>>>> logs can be used to trace it back to the peering connection and peer
>>>>>> upstream provider the call came in from.  What we also need is a list of
>>>>>> SPIDs the call request has crossed through, so we can trace it back
>>>>>> further upstream.  Kinda like a Via header, but with very different
>>>>>> properties and purpose.  We've talked about doing that before, back when
>>>>>> there was talk about creating a registry of SPIDs.  What ever happened
>>>>>> to having a registry of SPIDs?
>>>>>>
>>>>>> -hadriel
>>>>>>
>>>>>> _______________________________________________
>>>>>> stir mailing list
>>>>>> stir@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>
>>>>>> _______________________________________________
>>>>>> insipid mailing list
>>>>>> insipid@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>> _______________________________________________
>>>>> insipid mailing list
>>>>> insipid@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>> _______________________________________________
>>>> insipid mailing list
>>>> insipid@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/insipid
>>> _______________________________________________
>>> insipid mailing list
>>> insipid@ietf.org
>>> https://www.ietf.org/mailman/listinfo/insipid
>>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid
>