[VOIPSEC] Cisco 7920 wireless IP Phones
Scott Keagy
Scott.Keagy at webex.com
Tue May 31 20:20:39 CDT 2005
Agree that overhead for signaling is not a concern. Also agree that SRTP is
preferred solution for media encryption if you're building a closed system
or if you're a service provider offering VoIP over the public Internet.
But in many cases, clients will be using wireless network as basic internet
access, with VPN back to somewhere else like company intranet (and VoIP
inside this VPN). To sidestep these VPN issues, perhaps a best practice
should be for companies to provide remote access for VoIP directly to SBCs
at edge of the enterprise, rather than bringing all traffic in via the VPN.
Regards,
Scott
-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net]
Sent: Tuesday, May 31, 2005 6:10 PM
To: 'Scott Keagy'; 'Robert Moskowitz'; 'Guillermo Marro';
Chris at infravast.com
Cc: Voipsec at voipsa.org
Subject: RE: [VOIPSEC] Cisco 7920 wireless IP Phones
Scott
The signaling doesn't need compression; not enough bits to worry about.
The media wouldn't use any form of IPSEC, it would use sRTP, which has
minimal overhead.
Brian
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]
> On Behalf Of Scott Keagy
> Sent: Friday, May 27, 2005 6:14 PM
> To: Robert Moskowitz; Scott Keagy; Guillermo Marro;
> Chris at infravast.com
> Cc: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Cisco 7920 wireless IP Phones
>
> Just want to clarify something I mentioned earlier to which Robert
> replied....
>
> I recognize 802.11i as a link-layer security mechanism. What I was
> discussing is a method to shorten layer3 headers associated with IPSEC
> on a per-hop basis (so that IPSEC on top of IP/UDP/RTP can be
> realistically used on 802.11 links). So a layer3 header compression
> mechanism that operates link-by-link much like CRTP, but instead
> focused on IPSEC headers. This is very different from the focus of
> 802.11i.
>
> Might be more under the bailywick of ROHC (robust header compression)
> work.
> Lo and behold, I just checked ROHC RFC 3095 and the profile for
> Encapsulating Security Payload seems like the appropriate tool. The
> RFC discusses models for cellular telephony, but the use case here
> with 802.11 fits the bill too.
>
> So overarching solution framework (beyond scope of this immediate
> discussion):
> Layer 1 security (control E&M radiation, physical access (beware
> social engineering; unique badged entry- no shared keys), watch for
> acoustic bugging or physical taps of wires from desktops to switches,
> etc.) Layer 2 security (802.11i (need per-frame Ethernet integrity
> checks on wired links too), L2 port security, anti arp-spoofing,
> protect switch control traffic, harden switches, etc.) Layer 3
> security (IPSEC, etc.) Layer 4 security (TLS, SRTP, etc.) Application
> security (SIP authentication, S/MIME, etc.) Bandwidth efficiency to
> fix problems caused by IPSEC overhead (something like ROHC) Session
> Border Controllers at voice/video/etc provider boundaries to maintain
> policies (can't rely on Firewall ALGs with encrypted signaling) and
> help with NAT traversal (who knows when IPv6 will be widely deployed,
> so living with NAT is real).
>
> For a Cisco product-centric view (still relevant for conceptual issues
> to
> address) of VoIP security across layers of the protocol stack, check
> Chapter
> 6 of this book:
> http://www.amazon.com/exec/obidos/ASIN/1587051397/
>
> Many of the issues explained, with pointers to relevant Cisco
> technologies to mitigate the threats.
>
> Regards,
> Scott
>
>
> -----Original Message-----
> From: Robert Moskowitz [mailto:rgm at icsalabs.com]
> Sent: Friday, May 27, 2005 7:09 AM
> To: Scott Keagy; Guillermo Marro; Chris at infravast.com
> Cc: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Cisco 7920 wireless IP Phones
>
> At 02:26 PM 5/26/2005, Scott Keagy wrote:
> >IPSEC overhead with VoIP is a real concern, given a typical 20 byte
> >audio codec payload and 12+8+20 byte headers of RTP+UDP+IP (before we
> >talk about IPSEC overhead). Even with CRTP inside of IPSEC
> >(compressing 40 bytes down to 2-4 bytes depending on UDP checksums),
> >still have serious IPSEC overhead with abysmal VoIP throughput.
>
> The shame is that most people miss the transport mode of IPsec and get
> hung up on the tunnel mode. Transport has a much more reasonable size
> hit. It is an end-to-end, not end-to-gateway technology.
>
> Better yet, look at HIP (disclaimer, my invention but others running
> with it). It looks like IPsec transport mode, but really works with
mobility.
>
> Also consider AES with counter mode to eliminate the ESP padding hit
> of CBC. Better yet go with AES with CCM mode (encrypt and
> authenticate in one pass). Once we get AES with GCM for 802.1AE
> (MACsec) we can get an IPsec version of that cipher suite and
> eliminate all padding.
>
> >Service providers can have reasonable work-arounds with CRTP
> >packet-stacking inside an IPSEC tunnel (something along the lines of
> >TCRTP) if you have high traffic corridors with well defined sources
> >and destinations. But for general use as in a wireless case, the
> >overhead is just going to suck unless there are special new methods
> >of creating a shortened identifer tagged on the encrypted payload
> >that operates only at the link layer (and requires negotiation and
> >state maintenance between the wireless devices). Now I'm pretty
> >ignorant of current activities in wireless networking, so have no
> >insight into whether such
> work exists or is underway.
>
> It looks like my messages are not making it to the list. Don't know
> why, but I have covered much of wireless security. I was one of the
> contributors to the 802.11i work.
>
>
> >-----Original Message-----
> >From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]
> >On Behalf Of Guillermo Marro
> >Sent: Thursday, May 26, 2005 10:46 AM
> >To: Chris at infravast.com
> >Cc: Voipsec at voipsa.org
> >Subject: RE: [VOIPSEC] Cisco 7920 wireless IP Phones
> >
> >Chris,
> >
> >IMHO, saying that wireless infrastructure is insecure (irrespective
> >of what preventive measures you take to mitigate risks) is perhaps an
> >unnecessary simplification that might cause a lot of misconception.
> >
> >In my eyes, wireless infrastructure will never be safe from layer-1
> >local DoS attacks (signal jamming). Irrespective of how smart your
> >modulation scheme is, there is not much you can do about powerful
> >wide- band white noise generators. So it's probably safe for now to
> >say that availability is and will be an issue.
> >
> >Regarding confidentiality and integrity, I'm with Tom: strength of
> >WPA protection DOES MATTER.
> >
> >It'd be interesting to know about successful attacks to WPA2-AES
> >achieved in feasible time frames. I'd also be more than happy to know
> >about successful attacks to TLS and SSH (patched implementations on
> >both wireless or wired deployments).
> >
> >Regarding the overhead added by IPSec, I believe it is entirely
> >dependent on the size of the IP datagram. A datagram with a payload
> >of
> >64 bytes does not clearly have the same overhead (in proportion) that
> >one with 1480 bytes of payload. I'm no VoIP expert, so I don't know
> >what the average VoIP packet looks like, but I'd like to know how you
> >reach that 40% overhead figure.
> >
> >Thanks,
> >
> >-G
> >
> >
> >On Wed, 2005-05-25 at 22:26 -0500, Christopher A. Martin wrote:
> > > TLS is SSL all grown up.
> > >
> > > SSL and SSH can be hijacked (MiM, Man in the middle) by hacker
> > > tools crafted specifically for VoIP. A good example of ssl
> > > hijacking is a tool called airsnarf.
> > >
> > > http://airsnarf.shmoo.com/
> > >
> > > I believe that this would be a trivial task to convert to SIP
> > > since it is merely a cousin to html.
> > >
> > > The author, Beetle, gave some very good demonstrations of how easy
> > > it is to break "ANY" wireless encryption/protection scheme and,
> > > with this tool, hijack any ssl/tls encrypted page to capture
> > > authentication/credit card or any other info that was supposed to
> > > be encrypted. Over two days he was able to show a class of about
> > > 60 people, many new to wireless how to do the same thing.
> > >
> > > When I say that IPSec adds too much overhead I refer to the fact
> > > that, due to encapsulation, IPSec adds approximately 40%
> > > additional overhead to an IP packet and often fragmentation due to
> > > packets that need to be fragmented for encapsulation.
> > >
> > > Chris
> > >
> > > -----Original Message-----
> > > From: Robert Thompson Jr. [mailto:rthompson at columbiabank.com]
> > > Sent: Wednesday, May 25, 2005 1:19 PM
> > > To: Chris at infravast.com; Voipsec at voipsa.org
> > > Subject: RE: [VOIPSEC] Cisco 7920 wireless IP Phones
> > >
> > > I am very new to VOIP, so please bear with me.
> > >
> > > But when you say that it is trivial to intercept the traffic, you
> > > just mean to receive it right? You are not talking about
> > > deciphering the information and being able to listen in on the
> conversation are you?
> > >
> > > Why would IPSEC add too much overhead?
> > >
> > > Instead of SSH and SSL, could TLS be used? As I am under the
> > > understanding that TLS doesn't have any more overhead than SSL
> > > though is quite more secure.
> > >
> > > Rob.
> > >
> > > -----Original Message-----
> > > From: Voipsec-bounces at voipsa.org
> > > [mailto:Voipsec-bounces at voipsa.org]
> > > On Behalf Of Christopher A. Martin
> > > Sent: Tuesday, May 24, 2005 5:47 PM
> > > To: 'Finnegan, James M SAM Contractor'; Voipsec at voipsa.org
> > > Subject: RE: [VOIPSEC] Cisco 7920 wireless IP Phones
> > >
> > >
> > > It is trivial to hijack, intercept, impersonate any type of
> > > traffic over wireless, whether WEP, WAP, etc is implemented. IPSec
> > > over it is about the only safe bet (which adds too much overhead).
> > > SSH and SSL can also be compromised due to wireless hijacking.
> > >
> > > -----Original Message-----
> > > From: Voipsec-bounces at voipsa.org
> > > [mailto:Voipsec-bounces at voipsa.org]
> > > On Behalf Of Finnegan, James M SAM Contractor
> > > Sent: Tuesday, May 24, 2005 12:03 PM
> > > To: Voipsec at voipsa.org
> > > Subject: [VOIPSEC] Cisco 7920 wireless IP Phones
> > >
> > > Greetings all,
> > >
> > > I have run into a problem I was hoping to get feedback on. We
> > > are using the 7920 IP Phones at our sites, running CCM 3.3.
> > >
> > > The Army has decided the wireless link needs to be encrypted with
> > > something other than WEP or WEP w/LEAP. Our standard wireless
> > > encryption is 3DES.
> > > The
> > > 7920's only support WEP or WEP w/LEAP. Has anyone run into this
> problem?
> > >
> > >
> > >
> > > Thanks
> > >
> > >
> > >
> > > Mike Finnegan
> > >
> > > B.I.T.S.
> > >
> > > U.S.Army Corp of Engineers
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> > >
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > >
> > >
> >--
> >...........................
> >Guillermo Marro
> >Synaptes
> >Comunicacion Inteligente
> >http://www.synaptes.com
> >
> >
> >_______________________________________________
> >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
>
> Robert Moskowitz
> Senior Technical Director
> ICSA Labs, a division of Cybertrust, Inc.
> W: 248-968-9809
> F: 248-968-2824
> VoIP: 248-291-0713
> E: rgm at icsalabs.com
>
> There's no limit to what can be accomplished if it doesn't matter who
> gets the credit
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
More information about the Voipsec
mailing list