[asterisk-dev] Re: IAX native bridge and NAT

[Tim Davies]

Not that I have cut any code yet, but...

As far as I know, the current transfer code only uses the call number
and a transfer id to verify the host.  Hardly a security measure, it is
really just to make sure the correct channel is bridged.  I hadn't
intended on changing this.

I was thinking about it, and I figured an attacker would have to be
intercepting the packets to start with (to get the addresses and call
numbers etc).  If the intent is to listen in on the call, then
manipulating the routing is not really relevant (to prevent
eavesdropping, use encryption!).  They could just as easily prevent the
transfer as make a man-in-the-middle attack, and still listen in.  

But if an attacker CAN get in the routing path, they can easily inject
IAX packets (like DTMF, audio or whatever).  What are the implications
of this?

It might be made easier by these modifications, although I think it is
possible to do now.  Can we use a challenge/response on the transfer
packets?  I think ALL packets would need to verify the other end: 
TXCNT/TXACC and TXREQ/TXREADY/TXREL?  Is it a big risk not to?


Tim.




Benny Amorsen wrote:
>>>>>> "TD" == Tim Davies <tim at opensystems.net.au> writes:
>>>>>>             
>
> TD> - always sending the TXACC to where the TXCNT came from, and then
> TD> either - resending TXCNTs back to the address that TXCNTs were
> TD> received from (if it different from the original address given in
> TD> the TXREQ), or - sending an additional TXACC back to where a TXACC
> TD> came from, in case the TXCNT never made it. A kind of 3-way
> TD> handshake.
>
> Does the IAX protocol or your changes authenticate that it's actually
> the right peer you end up talking to? It sounds like a change which
> has security implications.
>
>
> /Benny
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060617/7926b959/attachment.htm