[VOIPSEC] Cisco 7920 wireless IP Phones
Scott Keagy
Scott.Keagy at webex.com
Fri May 27 17:14:12 CDT 2005
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
More information about the Voipsec
mailing list