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

[Paul Kyzivat <[e-mail]>]

On 8/1/13 12:24 AM, Hadriel Kaplan wrote:
>
> On Jul 31, 2013, at 12:48 PM, Paul Kyzivat <[e-mail]> wrote:
>>>> 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."
>>>
>>> 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.
>
> 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".

I "understand" the rationale for changing callid to hide ip or dns 
addresses. (I think its silly, but I understand there are people that 
are paranoid about such things. I'm paranoid about *different* things.)

I don't understand why you would need to "fix" callids for other 
reasons. I'd be interested in hearing (offline) about such cases. I 
can't think of anything except broken implementations.

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

The implication of this is that we should have *no* general mechanisms.
Rather we should have many many feature-specific mechanisms. IIUC, that 
is a description of the systems we have been replacing, and one of the 
main reasons they needed to be replaced.

	Thanks,
	Paul

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