[VOIPSEC] 4G Issue Map: signaling complexity

[Hallam-Baker, Phillip]

Security and the NAT traversal story may have an interaction here.

NAT traversal is hard because NAT is used as a lightweight security mechanism. With NAT in place and no traversal mechanism it is awfully hard to attack up to my local network servers. 

Universal Plug and Play has a NAT traversal solution in theory, many devices support it, yet I don't see much momentum behind UPnP otherwise at the moment. Where are the UPnP printers? Disk Drives etc?

In part this appears to be that UPnP has a broken discovery scheme that relies upon broadcast working in the local network (it won't) and thus that the local network will be geographically constrained (it won't, I work at home, in the office, in the coffee bar, in hotels). 

The bigger problem is that UPnP has failed to provide what is generally accepted to be a credible security story.


I think that most of what we are referring to as VOIP security issues are really network security issues that are the result of an inadequate model of what a network is, what an acceptable administrative effort for a network is and the assumption that these are 'enterprise' features not 'every Internet user' features.

There are VOIP specific security issues but I don't hear them raised. For example I have a computer on my desk that has an address book with phone numbers. I have a phone next to it. Why can't I make the two talk in a sensible yet totally transparent fashion? I want to be able to click on a link in an address book and have it place the call on my desktop phone but only if I happen to be in the office. Otherwise I want it to place the call on my cell phone.


I can think of a few ways to do this but none of the ones that are available to me at the moment are ones I would consider 'robust' or architectured in a manner that is capable of being robust.

This may seem an unreasonable type of demand but often the way to make a system work better is to start asking the unreasonable demands rather than thinking exclusively about incrementalism. The Web was not an incremental advance on FTP, it was a totally different model that rendered FTP completely obsolete.

At the moment we are creating a VOIP world that is simply a cheaper way to deploy POTS. Every improvement over POTS is non standard. My comcast VOIP interface is completely different to my Vonage interface and neither is properly integrated into Outlook or my Treo or even my home phone system.


The main reason that engineers seem to refuse to think about these features and the need to support them is that they get frightened of security issues and just wimp out.

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Brian Rosen
> Sent: Thursday, August 24, 2006 9:41 PM
> To: 'Simon Horne'
> Cc: voipsec at voipsa.org
> Subject: Re: [VOIPSEC] 4G Issue Map: signaling complexity
> 
> Well, more or less, I agree with you.
> 
> I definitely think users don't care about text or binary.  
> Carriers don't care either.  Only implementors care.
> 
> I think we made a whole lot of mistakes with SIP, and with 
> VoIP in general.
> Security was one of them.  We didn't move fast enough on NAT 
> traversal, but it's hard, and we kept thinking there would be 
> other things (like ALGs) that would help us. Alas, not true, 
> and now we have ICE, which is probably pretty close to what 
> Skype does bottom line.
> 
> I think Skype has taught me a lot.  I don't think many people 
> on this list get it:
> 
> You can have complete signaling security, every time.
> 
> You can have excellent quality audio, except when you go to 
> the PSTN, and even then, the average Skype out call sounds 
> much better than the average PSTN caller.  VoIP without 
> wideband should never have existed.
> 
> You don't need many features, and some of the ones you need 
> don't exist in the PSTN (like portable phonebooks and chat).
> 
> Telephone numbers are starting to be less important
> 
> We still don't know what a sustainable revenue model is, but 
> it's highly unlikely to look like the current one.
> 
> What have you learned?
> 
> > -----Original Message-----
> > From: Simon Horne [mailto:s.horne at packetizer.com]
> > Sent: Thursday, August 24, 2006 7:09 PM
> > To: Brian Rosen
> > Cc: voipsec at voipsa.org
> > Subject: Re: [VOIPSEC] 4G Issue Map: signaling complexity
> > 
> > 
> > Brian
> > 
> > Customers don't care whether it's text or binary, they just 
> care that 
> > it works and whether it can it deliver the solution to the customer 
> > requirements and that today includes PSTN integration, Security and 
> > NAT Traversal.  As SKYPE would say, arguing about which or what is 
> > better is just purely academic. Can you deliver the solution? The 
> > truth is after 10 years with SIP we're all still scratching 
> our heads.
> > 
> > Simon
> > 
> > At 06:00 AM 25/08/2006, you wrote:
> > >Paul
> > >
> > >Re: Text vs Binary.
> > >
> > >I was there.  I was the IETF editor for the first Megaco RFC.  The 
> > >design was a compromise.  You can say, after the fact we 
> could have 
> > >done better, and no doubt that was true.  However, the 
> text guys will 
> > >tell you the
> > same
> > >thing: if they could have ignored the binary guys, they could have 
> > >done better.
> > >
> > >The only think I have heard that MAY have some validity is that the
> > binary
> > >guys should have pushed PER instead of BER.
> > >
> > >I don't understand the compress SIP issue.   If you have a 
> SIP device on
> > a
> > >network with hundreds of kilobits or megabits or gigabits of 
> > >bandwidth,
> > then
> > >you can ignore compression; not worth it.  When you are on 
> a device 
> > >that
> > has
> > >kilobits of signaling channel, then compression is a good 
> idea.  SIP 
> > >compresses well, without significant compute expense.  I 
> don't think
> > ASN.1
> > >would compress well.  I'm not sure I've actually seen 
> anyone try, but
> > many
> > >the normal compression tricks wouldn't work well except on the 
> > >obvious repeated URI stuff, which is text always.
> > >
> > >What we have discovered about text encoding is that they are much 
> > >easier
> > to
> > >get right IN THE BIG PICTURE.  They are much, much easier to debug.
> > >
> > >The usual claimed ASN.1 advantage beyond message size is the 
> > >automatic syntax correctness.  My personal experience with that is 
> > >that it's true
> > on
> > >the wire, but not in the implementation.  It takes more 
> time to get 
> > >an interoperable implementation with ASN.1, because it takes more 
> > >time to
> > get
> > >through the edit/compile/test loop, and it takes longer to 
> diagnose.
> > Once
> > >you have the implementation working (and I mean interoperable) the 
> > >correct-by-construction syntax advantage goes away.  The 
> thing that 
> > >surprised me the most was watching bakeoffs (sorry 
> Pillsbury).  ASN.1
> > based
> > >bakeoffs are painful, text ones are much, much easier.  Total time
> > clearly
> > >favors text in a bakeoff.  Syntax errors are easy to 
> diagnose and fix.
> > >Semantic errors are much harder, and diagnosing them when 
> you fumble 
> > >with your decoding tools is hard.
> > >
> > >Also, of course, we're a whole lot better with our ABNF 
> parser tools now.
> > >
> > > > > If we were to start over in the IETF, the golden rule 
> would be: 
> > > > > This protocol is NOT INTENDED to replace the PSTN, and any 
> > > > > suggestion
> > that a
> > > > > feature is needed because the PSTN has it, or does it some
> > particular
> > > > way,
> > > > > is sufficient reason for outright rejection of the feature or
> > method.
> > > >
> > > > :-)  Yes and no.  When the user attempts to call a remote party 
> > > > and a recording says "the number you've dialed has been 
> > > > disconnected" is
> > played,
> > > > that needs to be heard.  It's either that, or devices have to 
> > > > process
> > a
> > > > lot
> > > > of different (and equivalent) error codes.
> > > >
> > > > I was once using a SIP phone that would not properly 
> play in-band 
> > > > announcements.  It was several days later (when I used my mobile
> > phone)
> > > > before I discovered why the phone just kept ringing and ringing.
> > >Thank you.  Couldn't have picked a better example.
> > >
> > >The bell heads forced sip to implement early media, 
> because they have 
> > >a
> > very
> > >broken billing system, that they insisted had to be copied.
> > >
> > >Your problem was your phone did not play early media.
> > >
> > >The sip mechanism is that the end device gives you your 
> error; there 
> > >are
> > no
> > >announcements in audio form played by the far end.  What 
> if you were
> > calling
> > >someone with a text phone because you are deaf?  Your phone could 
> > >text
> > you
> > >the proper message, the far end can't.
> > >
> > >If you want media, complete the call.  That's because SIP is a 
> > >session establishment protocol, and the media is the 
> session.  If you 
> > >want media, create a session.  That, in and of itself, is not the 
> > >problem.  The
> > problem
> > >is the BILLING.  They want the session to NOT be 
> established, and yet
> > they
> > >want (one way, if you please) media.
> > >
> > >Early media is a very, very bad idea, and has caused 
> untold grief and 
> > >complication in SIP.
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >Voipsec mailing list
> > >Voipsec at voipsa.org
> > >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
>