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

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 30 Jul 2013 13:24:27 +0200

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 <[email-masked]>
To: 	Richard Shockey <[email-masked]>
CC: 	IETF STIR Mail List <[email-masked]>

On Jul 16, 2013, at 9:35 AM, "Richard Shockey" <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Jul 2013 15:38:44 -0400

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

On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo <[email-masked]> wrote:

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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 31 Jul 2013 09:18:03 +0200

> 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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Jul 2013 07:37:28 +0000

I am getting very confused here.

Is there a problem with this requirement in the requirements document?

If not, then lets move on with the requirements document.

Is there a problem with the solutions document?

If so it is a working group item - make sure it contains what the working group wants. The original authors no longer have responsibility for the technical direction, only for making sure it contains what the working group wants. Hadriel may be on the author list, but you are a member of the working group.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Robert Sparks
> Sent: 31 July 2013 08:18
> To: [email-masked]
> Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs?
> 
> > 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 -
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 31 Jul 2013 09:47:06 +0200

> Is there a problem with this requirement in the requirements document?
That's the question. More specifically, is this requirement conflicting 
with some other requirement in this document?
Is Hadriel's comment below saying the group is requiring a solution that 
won't work, or is he saying the proposed solution doesn't meet the 
requirements?

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Jul 2013 08:05:45 +0000

> with some other requirement in this document?

None of the comments so far have given me enough information to evaluate this. Can someone please elaborate.

> won't work, or is he saying the proposed solution doesn't meet the

That is not necessarily a problem of the requirements document. If this occurs, the the solutions document in an informative place dealing with conformance to the requirements document will identify the inability to meet the requirement and the reason why. 

However, I do not have enough information to understand whether we will be needing that or not, because I do not understand whether we have a problem.

Regards

Keith

> From: Robert Sparks [mailto:[email-masked]]
> Sent: 31 July 2013 08:47
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; Gonzalo Camarillo
> > If so it is a working group item - make sure it contains what the
> working group wants. The original authors no longer have responsibility
> for the technical direction, only for making sure it contains what the
> working group wants. Hadriel may be on the author list, but you are a
> member of the working group.
> >
> > Regards
> >
> > Keith
> >
> >>>> of the requirements document, sent the comments below to the STIR
> list
> >> a

---

From: Robert Sparks <[email-masked]>
Date: Wed, 31 Jul 2013 10:17:11 +0200

> None of the comments so far have given me enough information to evaluate this. Can someone please elaborate.
That was the point of asking Hadriel for clarification.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Jul 2013 04:40:17 -0400

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.

-hadriel

On Jul 31, 2013, at 3:18 AM, Robert Sparks <[email-masked]> wrote:

> This wasn't a question about STIR, it was a question about the publication of this INSIPID document.
> 
> 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
>> 
>>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 31 Jul 2013 11:00:06 +0200

> 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Jul 2013 05:58:58 -0400

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.

-hadriel

On Jul 31, 2013, at 5:00 AM, Robert Sparks <[email-masked]> wrote:

> 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
>> 
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Jul 2013 10:13:24 +0000

If the deployer of an SBC wants to break the Session-ID header field, then they will break it. They will also break the Alternative-to-Session-ID-for-SBCs-that-break-Session-ID header field, and so on.

It seems to me we are just back in the paradigm that we design header fields that we say to SBC deployers that really you should pass these through, but at the end of the day, there will always be someone with a desire to break them. 

We know this happens, there is nothing we can do about it except warn.

Further, the INSIPID group does have limitations on what it is working on, for example:

   REQ9: It must be possible to correlate two end-to-end sessions when
   the sessions are created by a third party controller using 3PCC
   procedures shown in Figure 1 of RFC 3725 [7].

Is not a requirement that one entity knows all the session identifiers in use on all the other legs.

Regards

Keith

> Sent: 31 July 2013 10:00
> To: Hadriel Kaplan; [email-masked]
> > 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.
> >
> list a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Jul 2013 12:24:51 +0200

> 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 comme…

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Jul 2013 07:04:24 -0400

On Jul 31, 2013, at 6:24 AM, Paul Kyzivat <[email-masked]> wrote:

> 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.

Sure there is: for the use-cases people have in mind.   Afaict, that's mostly around correlating multiple SIP dialogs of the same conference or 3PCC scenario, and applying policies on such matching cases.  Those use-cases don't actually need true, world-wide end-to-end survival.  They only need to survive through *some* B2BUAs, not all; and only in/across some domains, not all; and only in certain scenarios, not all.

The goal has never really been to simply "get an ID that would survive e2e" - it's been to get something we could use for some *purpose*.  I believe an e2e identifier would be quite useful for a troubleshooting purpose, and so long as it was used for only that then the odds of someone wanting to change it would be minimized.  But if people use it for other purposes, then each and every purpose it is used for expands the scenarios and likelihood in which someone would need to change it and no longer make it truly e2e.  That's *ok* - it just means it's not going to be as useful for troubleshooting as it could have been, is all.  It's not doom and gloom.

> 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.

How can we promise not to use it for anything useful?  We already know some people want to use it for things that are useful *for them*.

-hadriel

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 31 Jul 2013 12:01:05 +0000

Hello All,
The question from Gonzalo was about REQ3:

My interpretation was that 1) the solution document must contain the text "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value." and 2) no future drafts/RFCs are allowed to specify that a SIP B2BUA or intermediary may change the Session-ID header field value.

This is simplistic but I think it meets REQ3. The discussion on Gonzalo's question seems to me to be about a different requirement along the lines of "how the Session-ID header field is generated and used must be compared with generation and use of header fields that a SIP B2BUA or other intermediary removes or modifies to ensure that a SIP B2BUA or other intermediary does not have any reason to remove the Session-ID: header field."

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: 31 July 2013 13:04
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Jul 2013 10:33:47 -0400

> My interpretation was that 1) the solution document must contain the text "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value." and 2) no future drafts/RFCs are al…

Right.  It's kinda silly requirement wording, but yes ISTM that a statement in a solution document stating "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value", would indeed satisfy REQ3. 

> This is simplistic but I think it meets REQ3. The discussion on Gonzalo's question seems to me to be about a different requirement along the lines of "how the Session-ID header field is generated a…

Yup.  Basically a "why do we think the MUST statement generated by REQ3 would actually be followed or not".

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Jul 2013 18:48:03 +0200

> Yup.  Basically a "why do we think the MUST statement generated by REQ3 would actually be followed or not".

Because if they don't follow it then any product that wants to claim 
conformance to a feature that requires session-id will fail in the 
presence of such B2BUA. If those features are themselves valuable, then 
people will demand products that conform to them.

Yes, I know that is naive, but its all the leverage we have.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Jul 2013 18:24:25 -0400

On Jul 31, 2013, at 12:48 PM, Paul Kyzivat <[email-masked]> wrote:
> Because if they don't follow it then any product that wants to claim conformance to a feature that requires session-id will fail in the presence of such B2BUA. If those features are themselves valuable, then people will demand products that conform to them.

It's not the "products that conform to them" that's the issue, it's whether the operators/admins of the products want them to do it and whether it's possible to do without breaking something else.  

Take the Call-ID header, for example - even if there weren't a security problem with revealing IP Addresses, fundamentally there are call scenarios that simply don't work if the Call-ID is left unchanged by B2BUAs.  Some of the scenarios are very subtle and only show up in certain deployments; others are more obvious, like out-of-dialog REFER handling.  B2BUA products don't change the Call-ID because it's fun, they change it to make things *work*.[1]  So if a new feature/mechanism is defined in the IETF which relies on Call-ID remaining unchanged, it doesn't matter if the product vendor and owner/admins want to support the new feature; it's giving them a choice of: "to get this new feature, you must break other features".

> Yes, I know that is naive, but its all the leverage we have.

It's not naive - it *is* all the leverage we have.  The entire concept of INSIPID and STRAW docs is that a purchaser of equipment who wants feature X in RFC Y, tells its vendors to comply with RFC Y; if the vendors don't do RFC Y, then they can't have feature X. 

The challenge is when we use RFC Y to accomplish multiple different features Z and W, we run the risk that not all of X+Z+W are achievable simultaneously, in practice.  So in the Session-ID case, if it turns out a SBC has to change a Session-ID to match/not-match others in order to make calls work right, vs. leaving it alone for troubleshooting purposes, it will invariably choose to change it to make calls work instead of help troubleshooting, as will its owner.  Calls have to work... the spice must flow.

Thus when faced with the STIR stuff needing to do caller-id verification, in my opinion it would be safer to not use Session-ID, than rely on it surviving e2e.  I don't *know* it won't survive e2e, since Session-ID hasn't gotten much deployment yet.  It's just a hunch based on the use-cases people have in mind for it.  They're not "benign" use-cases; they affect calls failing or succeeding.

-hadriel
[1] This isn't entirely the case - I've been told by some B2BUA vendors that their internal architecture limits their ability to do certain things transparently, such as Call-ID handling.  I won't name who they are because I was told in confidence, but they don't all attend the IETF and it's not my place to represent their views/issues.