Subject: Re: [stir] Out of band

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 3 Jul 2013 21:11:55 +0000

On Jun 28, 2013, at 3:28 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:

> 
> On Jun 20, 2013, at 8:46 AM, "Rosen, Brian" <[email-masked]> wrote:
> 
>> You misunderstood what I said, sorry for my part of the confusion.
>> What I meant was, no matter what we do, we are sure to have some SBCs mangling whatever we need.  It's inevitable.  
> 
> I'll add to that with AFAIC, the bulk of deployed SBC are configured to remove anything they don't understand. They may support other configurations but practically speaking, they are often viewed as a security device and in that use case most operators seem to remove things they don't understand.
> 
> 

I got asked to be a bit more specific on this ….  let me give two examples. 

Take a situation were a US based servicer provider A perhaps contracts out the voice termination to Europe and Africa to larger international carrier B. Now B may not actually terminate traffic in some specific country in Africa but instead uses service provider C. The type of requirements I have seen from the "B" company for SBCs include that their SBC can strip out a messages that C put in to SIP to say "hey this is actually being terminated at carrier C for 0.01 cents / minute and if you want to cut out the middle man please give us a call and SIP trunk to us directly" 

Now I have always been a bit skeptical that carrier A could not manage to find out that carrier C existed but none the less, this does seem to be a requirements from some folks.

In the second example, imagine you have an vendor of mobile phone handsets that would like to deliver SMS like messages for free to handsets using a carriers 3G network and not paying for it. They come up with the brilliant idea to send an INVITE to the handset that includes the header like "X-IOS-SMS: Here is the message" and have the handset look for this and if the header is there, then the handset does not ring but instead just displays the message "Here is the message". 

Clearly something needs to block these type "bit smuggling" in the signaling. This is a requirement that comes up to SBC that a SP might use to police traffic that was coming from an enterprise user into the SP network. 

It has always seemed to me that someone that was really determined might find a way to smuggle the bits but none the less the requirements exist to not allow stuff like this. I'm sure the SBCs can be configured many different ways but many do have the capability to be configured like this. 

It's hard for me to test what data actually makes it from one SP to another but it's not that hard to test what makes it End to End for specific paths. Some tests of that of that would suggest, as a vague generalization, that much stuff in SIP that is not understood by the SBCs does not survive end to end. 

On related note, if we defined a new header and carriers wanted that header to make it thought there network, I think for many cases they could probably do that only by changing configuration of equipment. I realize that even a configuration change is a big deal but it's a smaller deal that software upgrades.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Jul 2013 18:12:27 -0400

I'd argue that actually the number one reason SBCs remove things is to make calls work - because systems other than SBCs can't seem to handle unknown headers.  But yes the number two reason is for security-related purposes.  In my experience, though, while SBC's have had a whitelist-model for removing all unknown headers for years, it's not nearly as popular/commonly-used as the blacklist model of only removing specific headers.

What I find most ironic about your statement is that while at least SBC's can be configured to pass/drop headers, most of the *other* B2BUAs in the call path don't pass along unknown headers at all, and can't even be configured to do so.  They've been getting better - at least some B2BUAs can now be configured with what headers to pass through - but that's a relatively new feature for B2BUAs afaict, while it's been available to every SBC I've ever seen for over a decade.

I think many people in the IETF tend to be from Enterprise-side PBX vendors, for which they consider themselves the "end" for end-to-end SIP, and then think the carriers they connect to are just SBCs getting in their way of end-end SIP.  Meanwhile the carriers all have the logical equivalent of PBXs inside their networks, and think the same of transit carriers getting in their way of end-end SIP.  And of course the transits also have the logical equivalent of PBXs inside their networks.  I find the debates in the IETF about end-end SIP transparency quite humorous, when everyone considers themselves to be the "end". :)

-hadriel

On Jul 3, 2013, at 5:11 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jul 2013 16:20:23 -0700

On 7/3/2013 3:12 PM, Hadriel Kaplan wrote:
> I find the debates in the IETF about end-end SIP transparency quite humorous, when everyone considers themselves to be the "end".:)

It was pretty obvious that email really /was/ end-to-end, until I 
started working with the EDI and fax communities that used email as a 
subordinate layer for transport, often with significant additional 
transferring, after email was done.

The meta-lesson is that end-to-end can't be guaranteed.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Thu, 04 Jul 2013 10:40:45 -0700

On 7/3/2013 3:12 PM, Hadriel Kaplan wrote:
> What I find most ironic about your statement is that while at least
> SBC's can be configured to pass/drop headers, most of the *other*
> B2BUAs in the call path don't pass along unknown headers at all,
...

>>> I'll add to that with AFAIC, the bulk of deployed SBC are
>>> configured to remove anything they don't understand.
...
>> On related note, if we defined a new header and carriers wanted
>> that header to make it thought there network, I think for many
>> cases they could probably do that only by changing configuration of
>> equipment. I realize that even a configuration change is a big deal
>> but it's a smaller deal that software upgrades.

The question of what header fields can or cannot make it through which 
devices and when is another source of entropy in the current discussions.

The group needs to settle on some basic assertions of fact about the way 
header fields are treated along various paths.

The group then needs to settle on the basic ways of resolving these.

The are 'meta' issues, in that they are getting in the way of 
lower-level debates about specific design choices.

    IMO, the worst possible choice will be to define two -- oh what the 
heck, maybe more -- parallel mechanisms.  There's no precedent for such 
a thing working at scale and the complexities, fragilities and 
incentives make it unlikely it will in this case.

    Some localized issues might be handled by specialized, /localized/ 
hacks.

    Some issues might be handled by obtaining changes in the problem 
devices.

    Some issues might be handled by excluding some cases from the 
architecture.  (Yes, I mean explicitly admitting from the start that 
specific scenarios won't be haled.)

    And so on.

If the group can settle on these matters of fact and these strategic 
scenario choices, figuring out what one, integrated design is likely to 
be viable will get quite a bit easier.

d/