[Insipid] Will the identifier pass unchanged through B2BUAs?

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