[Asterisk-Users] IAX/IAX2 encryption?
Chris Albertson
chrisalbertson90278 at yahoo.com
Mon Nov 10 18:25:56 MST 2003
The below is all correct. In fact the US DoD has very restrictive
and conservative rules about how some types of data are handled.
Basically if it leaves a trusted area it will so through a hardware
crypto box.
Some of the rules are to ensure that data are protectied even if
the hardware is badly misconfigured or broken. It has to be that
way when you are literaly betting someones life that there can be
no possibilty of error. So yes, between servers use some kind of
trusted, well-debugged crypto system.
But there are reasons why you might want encryption built into
IAX(2)
1) For clients. Someone may want to "call home" using a
notebook computer and it would be far simpler if you din't have to
set up a VPN
2) A user may not have control over the network. For example,
I may want to run an IAX client on a computer where I do not
have root access.
3) dumb users. Many people don't know what a VPN is but could
(maybe) install a zip'd IAX client or at least be able to find the
local "computer expert" who knows how to un-zip a zip file.
4) keeping users isolated. Everyone on the "black" side of the VPN
box could in theory hear each other. The best place to put the
encryption would be inside the handset, so even spyware on the PC
could not intercept any cleartest data.
The "VPN box in the server room" only works in the special case
where everyone on the Ethernet LAN is trusted. In a large
enough organiation this will not be the case.
5) you may very well want touse public key cryptogrphy where each
USER (not each computer or each office) encrypts using his/her
public key. User this kind of setup users can be absolutly
certain of who they are talking too.
--- Brian D Heaton <bdheaton at c4i2.com> wrote:
> Brian,
>
> Mark was talking about it with JustinT at PN7. I caught the end of
> the
> conversation. The question I asked then (and still ask now) is, (for
> the IAX/IAX2 case at least) why load down the PBX with PBX-to-PBX
> encryption?
>
> If you look at the way most large organizations (military,
> government,
> large multi-nationals) handle encrypted network communications you'll
> find they separate site-site encryption from the data processing
> machines. You have a RED (cleartext) LAN segment connected to the
> RED
> side of an encryption device. The BLACK (encrypted) side of the
> encryption device connects to remote sites via tunnels. (Hint:
> google
> for TACLANE ) In addition to decreasing the complexity on the
> workstations/servers you reduce the number of fingers in the crypto
> device and the number of things running on it.
>
> This is the same thing we do now with router-router VPN tunnels. If
> you have only a single tunnel between sites and a best effort black
> side
> network then you do your QoS shaping on the red side and cross your
> fingers. If you've got QoS shaping on the black side then you can
> setup
> more than one tunnel between sites and use policy routing either on
> the
> ecryption device or in front of it to get the data into the correct
> tunnels. If you can do both you're better off since it give you more
> granular control.
>
> You're already running a process ( * ) that needs to do quite a bit
> of
> low-level bit manipulation and DSP on the PBX. Why load it down with
> a
> process that needs to do mucho math for encryption? Even with the
> hardware daughterboards I think you're going to at least greatly
> increase your context switching overhead.
>
> Tune the Asterisk box (and consume its resources) for Asterisk and
> tune
> the encryption/routing box for encryption/routing. How about a
> Soekris
> box with the hardware encryption daughterboard? You can get some
> pretty
> nice performance in a small space. I don't want to see * get loaded
> down with a bunch of encryption hooks rather than more refined
> features
> and bug fixes.
>
> The client case is a whole different matter. Most of the discussion
> between Mark and Justin centered on the IAXy. Thats a whole
> different
> scenario and I think the best you're going to get there is some type
> of
> symetric cipher with shared secret. I don't think you've got the
> code
> space or spare cycles to do much more. At the very least a DH key
> exchange of session keys would eat up some call-setup time.
>
> Thoughts?????
>
>
> Other Brian....
>
>
> PS - Mel says hi!
>
>
>
> On Mon, 2003-11-10 at 15:26, Brian J. Schrock wrote:
> > I second that, and I think I remember hearing Mark talking about it
> too. But.....
> >
> > What type of encryption can you do that does not introduce latency?
>
> >
> > That said, I would like it to support hardware encryption cards.
> >
> > I have done work with FreeS/WAN and it works, and yes it adds about
> 30-100ms of latency depending on what else is going on. I think it
> has something to do with keying.
> >
> >
> > On Mon, Nov 10, 2003 at 02:06:33PM -0600, Brian West wrote:
> > > I wonder if anyone else on the list has expressed any intrest in
> having
> > > some type of native support for encryption for IAX? I hear IPSEC
> adds
> > > some latency... I would like to side step that for something
> simpler to
> > > setup.
> > >
> > > bkw
> > > _______________________________________________
> > > Asterisk-Users mailing list
> > > Asterisk-Users at lists.digium.com
> > > http://lists.digium.com/mailman/listinfo/asterisk-users
> > _______________________________________________
> > Asterisk-Users mailing list
> > Asterisk-Users at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> >
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
=====
Chris Albertson
Home: 310-376-1029 chrisalbertson90278 at yahoo.com
Cell: 310-990-7550
Office: 310-336-5189 Christopher.J.Albertson at aero.org
KG6OMK
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
More information about the asterisk-users
mailing list