Inter-Asterisk eXchange

From Wikipedia, the free encyclopedia

Jump to: navigation, search

IAX is the Inter-Asterisk eXchange protocol native to Asterisk PBX and supported by a number of other softswitches and PBXs. It is used to enable VoIP connections between servers as well as client-server communication.

IAX now most commonly refers to IAX2, the second version of the IAX protocol. The original IAX protocol has been deprecated in favor of IAX2.

The IAX2 protocol was published as an informational (non-standards-track) RFC 5456 by discretion of the RFC Editor in February 2009.[1]

Contents

[edit] Basic properties

IAX2 is a VoIP protocol that carries both signaling and media on the same port. The commands and parameters are sent in binary format and any extension has to have a new numeric code allocated. Historically this was modeled after the internal data passing of Asterisk modules[citation needed].

IAX2 uses a single UDP data stream (usually on port 4569) to communicate between endpoints, multiplexing signaling and media flow. IAX2 easily traverses firewalls and network address translators. This is in contrast to SIP, H.323 and MGCP which use an out-of-band RTP stream to deliver information.

IAX2 supports trunking, multiplexing channels over a single link. When trunking, data from multiple calls are merged into a single stream of packets between two endpoints, reducing the IP overhead without creating additional latency. This is advantageous in VoIP transmissions, in which IP headers use a large percentage of bandwidth.

[edit] Origin of IAX

The IAX and IAX2 protocols were created by Mark Spencer for Asterisk for VoIP signaling. The protocol sets up internal sessions and these sessions can use whichever codec they want for voice transmission. The Inter-Asterisk Exchange protocol essentially provides control and transmission of streaming media over IP (Internet Protocol) networks. IAX is extremely flexible and can be used with any type of streaming media including video, however it is mainly designed for control of IP voice calls.

[edit] The goals of IAX

The primary goals for IAX were to minimize bandwidth used in media transmissions, with particular attention drawn to control and individual voice calls, and to provide native support for NAT (Network Address Translation) transparency. Another goal is to be easy to use behind firewalls.

The basic structure of IAX is that it multiplexes signaling and multiple media streams over a single UDP (user datagram protocol) stream between two computers. IAX is a binary protocol, designed to reduce overhead especially in regard to voice streams. Bandwidth efficiency in some places is sacrificed in exchange for bandwidth efficiency for individual voice calls. One UDP stream is easier to setup for users that are behind a firewall.

An additional benefit to having a single stream is the added security, which can be implemented very easily. Furthermore, in countries where ISPs are filtering VoIP, IAX can be easily hidden.

[edit] IAX drawbacks

IAX2 uses one path for both signaling and media. This leads to the following issues:

  • According to an email[2] by Mark Spencer, when you use a centralized server and transfer to a media gateway for call completion, the centralized server loses track of the phone call. As a result, the centralized server does not know when the call terminated and cannot provide billing information on that call. Asterisk 1.4 includes support for a new IAX2 message, TXMEDIA, which allows transferring only the media to flow between two other endpoints so that the server may still receive signaling and not media.
  • As per ISS security advisory[3] an attacker (or fairly busy network, i.e. enterprise-level) can use up all the available sessions, in which case no future sessions can be assigned until current ones expire or the session ends and they are removed. Sessions are used for call requests, authentication requests, basically any time a unique id is required for a series of related packets. Version 1.2.10 (and above) of Asterisk mitigates the attack by setting the maximum amount of unauthenticated requests made for a single username, but it is still possible to fill up this session queue if many usernames are used and there are sufficiently many calls.
  • As Per Jeremy McNamara and Blake Cornell[4] - By flooding an Asterisk server with IAX2 ‘POKE’ requests, an attacker may eat up all call numbers associated with the IAX2 protocol on an Asterisk server and prevent other IAX2 calls from getting through. Due to the nature of the protocol, IAX2 POKE calls will expect an ACK packet in response to the PONG packet sent in response to the POKE. While waiting for this ACK packet, this dialog consumes an IAX2 call number, as the ACK packet must contain the same call number as was allocated and sent in the PONG. Exploit code[5] was released at The Last Hope. Shortly after a fix was released not reserving an IAX call number any more [6]
  • IAX2 is vulnerable to Resource Exhaustion DoS 0days that are currently available to the public. [7]. There are currently no solutions to these issues. Current best practices include limiting UDP port access to specific trusted IP addresses. Internet facing IAX2 ports are considered vulnerable and should be monitored closely.
  • Some implementations of IAX2 do not require a handshake when initiating a call. If a system has any accounts with no password (such as the default account ‘guest’, provided so that others can call via IAX without having an account) then the media from that call can be used in a DoS attack against anyone that that system can route packets to, by saturating the victim’s network. A security advisory[8] by ISS has been issued on this problem. In Asterisk, versions 1.2.20, 1.4.5 and later require a three way handshake before beginning to send media. This vulnerability can be avoided in earlier versions of Asterisk by not allowing any unauthenticated calls. It is also worth noting that this same problem exists with SIP, but in a worse way. The protocol is defined in such a way that directing media streams at arbitrary endpoints is a feature of the protocol, and no falsifying of packets is required to make this happen.
  • Due to the lack of a generic extension mechanism, every new feature has to be added in the protocol specification, which makes it less flexibile than H.323, SIP or MGCP.

[edit] See also

[edit] References

  1. ^ IETF memo RFC5456
  2. ^ [Asterisk-Dev] IAX2 Transfer Message Sequence?
  3. ^ Asterisk IAX2 Protocol Denial of Service Attack
  4. ^ IAX Poke Resource Exhaustion
  5. ^ IAXPingPoker
  6. ^ Asterisk IAX 'POKE' Resource Exhaustion
  7. ^ VoIP 0day
  8. ^ IAX2 Protocol Denial of Service Amplification Attack

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Inter-Asterisk_eXchange"
Personal tools