Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5456

IAX: Inter-Asterisk eXchange Version 2

Pages: 101
Informational
Updated by:  8996
Part 5 of 5 – Pages 87 to 101
First   Prev   None

Top   ToC   RFC5456 - Page 87   prevText

9. Example Message Flows

This section includes call flow diagrams for some of the various types of IAX calls that can be made. In each diagram, the '=' character represents a Full Frame and the '-' character represents a Mini Frame. Notes applicable to a generic call may be presented alongside each diagram.
Top   ToC   RFC5456 - Page 88

9.1. Ping/Pong

PING->PONG Peer A Peer B ________________________________________ | | T | | i | ===PING============================> | m | | e | <============================PONG=== |Has same time-stamp | | as received PING. | | ===ACK=============================> |Has same time-stamp | | | as received PONG \ / |________________________________________| and original PING.

9.2. Lagrq/Lagrp

LAGRQ->LAGRP Peer A Peer B ________________________________________ | | T | | i | ===LAGRQ===========================> | m | | e | <===========================LAGRP=== |Same time-stamp as | | received LAGRQ. | | ===ACK=============================> |Same time-stamp as | | | received LAGRP and \ / |________________________________________| original LAGRQ.
Top   ToC   RFC5456 - Page 89

9.3. Registration

Registration of an IAX Peer Registrant A Registrar B ________________________________________ | | T | ===REGREQ==========================> | i | | m | <=========================REGAUTH=== | e | | | ===REGREQ==========================> | | | | | | <==========================REGACK=== | \ | / | | \|/ | ===ACK=============================> | | | |________________________________________|

9.4. Registration Release

Registration Release Registrant A Registrar B ________________________________________ | | T | ===REGREL==========================> | i | | m | <=========================REGAUTH=== | e | | | ===REGREL==========================> | | | | | | <==========================REGACK=== | \ | / | | \|/ | ===ACK=============================> | | | |________________________________________|
Top   ToC   RFC5456 - Page 90

9.5. Call Path Optimization

IAX Transfer Peer L Peer C Peer R ________________________________________ | | | T | | | | <== TXREQ =====[*]== TXREQ =========> |C requests transfer i | | | | ========================== TXCNT ==> |L sends to R m | | | | <========================= TXACC ==== |R replies e | | |R sends Media | | | to L | | | | | | = TXREADY ====> | |L tells C 'ready' | | | | C stops media to L | | | | | | <== TXCNT =========================== |L sends to R | | | | | | === TXACC ===========================> |R replies \ / | | | | | <== TXREADY ====== |R tells C 'ready' | | | C stops media to R | | | | <== TXREL =====[*]== TXREL =========> |C Releases | | |________________________________________|
Top   ToC   RFC5456 - Page 91

9.6. IAX Media Call

Complete end-to-end IAX media exchange Peer A Peer B ________________________________________ | | | ====NEW============================> | T | <=========================AUTHREQ=== |If authentication | | specified. i | ====AUTHREP========================> | m | <==========================ACCEPT=== | e | ====ACK============================> | | | | | <=============Voice (Full Frame)=== | | | ====ACK===========================> | | | | | | <---------Voice Mini Frame (ring)-- | | | <---------Voice Mini Frame (ring)-- | | | | \ | / | <=========================RINGING=== | \|/ | ====ACK============================> | | | | <---------Voice Mini Frame (ring)-- | | <---------Voice Mini Frame (ring)-- | | | | <==========================ANSWER=== | | ====ACK============================> | | | | ====Voice (Full Frame)=============> | | <=============================ACK=== | | | | | | <-----------Voice Mini Frames------> | exchange occurs | <--- . ---> | | <--- . ---> | | <--- . ---> | | <-----------Voice Mini Frames------> | | | | | | ====Voice (Full Frame)=============> | (note 1) | <===ACK============================= | (note 2) | | (every 65536 ms) | <=============Voice (Full Frame)==== | (note 3) | ====ACK============================> | | | | |
Top   ToC   RFC5456 - Page 92
           |  <-----------Voice Mini Frames------>  |
           |  <---               .            --->  |
           |  <---               .            --->  |
           |  <---               .            --->  |
           |  <-----------Voice Mini Frames------>  |
           |                                        |
           |                                        |
           |  ====HANGUP=========================>  |  Either can hangup
           |  <=============================ACK===  |
           |________________________________________|


   Note 1: Mini Frames carry the low 16 bits of the peer's
           32-bit time-stamp.
   Note 2: Full frames resync the 32-bit time-stamp when the 16-bit
           time-stamp overflows.
   Note 3: Each side has its own 32-bit time-stamp so each side needs
           to sync at 16-bit overflow.
Top   ToC   RFC5456 - Page 93

9.7. IAX Media Call via an IAX Device

An IAX peer is not required to maintain a complete dialplan. In the event that a user wishes to dial from an IAX peer that does not switch its own calls, the following call flow diagram may represent the transaction: Peer A (IAX Device) Peer B (Dialplan Server) ________________________________________ | | | ====NEW============================> | T | <=========================AUTHREQ=== | If auth specified i | ====AUTHREP========================> | m | <==========================ACCEPT=== | e | ====ACK============================> | | | | ====DPREQ==========================> | (Note 1) | | <===========================DPREP=== | | | | | | ====DIAL===========================> | | | <========================PROGRESS=== | | | ====ACK============================> | \ | / | <==========================ANSWER=== | \|/ | ====ACK============================> | | | | ====Voice (Full Frame)=============> | | <=============================ACK=== | | <=============Voice (Full Frame)==== | | ====ACK============================> | | | | | | <-----------Voice Mini Frames------> | Media exchange | <--- . ---> | | <--- . ---> | | <--- . ---> | | <-----------Voice Mini Frames------> | | | | | | ====Voice (Full Frame)=============> | (note 2) | <===ACK============================= | (note 3) | | (every 65536 ms) | <=============Voice (Full Frame)==== | (Note 4) | ====ACK============================> | | | | | | <-----------Voice Mini Frames------> | | <--- . ---> |
Top   ToC   RFC5456 - Page 94
           |  <---               .            --->  |
           |  <---               .            --->  |
           |  <-----------Voice Mini Frames------>  |
           |                                        |
           |                                        |
           |  ====HANGUP=========================>  |  Either can hangup
           |  <=============================ACK===  |
           |________________________________________|

   Note 1: There will be multiple DPREQ/DPREPs per call unless
           dialed number is 1 digit long.
   Note 2: Mini Frames carry the low 16 bits of the peer's
           32-bit time-stamp.
   Note 3: Full Frames resync the 32-bit time-stamp when the 16 bit
           time-stamp overflows.
   Note 4: Each side has its own 32-bit time-stamp so each side needs
           to sync at 16-bit overflow.

10. Security Considerations

IAX is a binary protocol for setting up point-to-point call legs that include both media and signaling. As such, it is simpler to secure than other more general purpose VoIP protocols; however, security remains a difficult task and various aspects of the protocol must be examined to identify risks. IAX registration is an area that requires careful attention. Previous protocol versions supported cleartext passwords; this feature has been eliminated. The MD5 and RSA alternatives offer much higher security. Although not specified by the IAX protocol, some implementations limit the number of registrants per account to one. A subsequent registrant with the same credentials would overwrite the prior and receive the calls destined for that user. Theft of service is trivial once a malicious caller has the ability to authenticate. In addition, since distinct cause codes are returned to erroneous registration attempts, an attacker can distinguish between existent and nonexistent users in a registration system, thus resulting in a possible directory harvest attack. The IAX protocol protects against message replay by using a challenge response method. The IAX registrar or server challenges each call or registration with an arbitrary MD5 or RSA challenge. The response and subsequent authorization relies upon knowledge of a shared secret. Since the server typically chooses a challenges using a random-number-based technique, the challenge set is large, making replay highly unlikely.
Top   ToC   RFC5456 - Page 95
   Although operation in the following manner is not recommended, the
   IAX protocol does permit servers to forego the challenge process
   described above.  This open approach is inherently insecure and does
   nothing to prevent unauthorized usage.

   Call Encryption in IAX starts by utilizing static keys.  Once
   negotiated, the key may be changed for the remainder of the call.
   Once the initial key is compromised, all subsequent calls are subject
   to interception.  A more secure implementation would update the key
   frequently and as early as practical during each call.

   The IAX protocol is also susceptible to eavesdropping.  Call Detail,
   i.e., who is calling whom, is sent in unencrypted binary whether or
   not the call is to be encrypted.  Without encryption, call content,
   i.e., audio and video, may be easily intercepted.  However, this
   content is protected if the call is encrypted.

   Man-in-the-middle attacks are a threat to IAX if encryption is not
   used.  This form of attack permits message insertion, deletion, and
   modification such that a call may be redirected or the audio or video
   replaced in either or both directions for the complete or any portion
   of a call.  If encryption is used, the call is protected end to end.
   Note: an initial NEW message in an encrypted call is unencrypted and
   could be changed; however, this is limited to a denial-of-service
   (DoS) attack because subsequent messages containing the same address
   information are redelivered in an encrypted form.

   DoS attacks can take at least two forms in IAX.  One is simply
   overloading the peers with bogus requests.  A carefully implemented
   IAX peer would identify this situation and raise an alarm or take
   other protective action.

   Another form of DoS against an existing call is an engineered attack
   against an existing call.  Injecting media, causing excess processing
   by inserting out-of-order packets, and sending commands such as
   hangup or transfer.  These attacks require close monitoring of the
   binary channel to be successful as the message sequence numbers would
   need to be synchronized with the protocol exchange.

   Of course, providing lower-layer security with Datagram Transport
   Layer Security (DTLS) [RFC4347], or IPsec [RFC4301], would address
   many of these potential issues.

   Unicode [RFC3629] and stringprep [RFC3454] security considerations
   also apply.
Top   ToC   RFC5456 - Page 96

11. IANA Considerations

In order to facilitate the orderly extension of the IAX protocol, several IANA registries have been created. These registry requests are found in [RFC5457]. In addition, the "iax" URI scheme has been registered; see Section 5. Also, IAX has been assigned a well-known UDP port number (4569).

12. Implementation Notes

The original IAX implementation was in Asterisk, the open-source PBX, but [wikipedia] lists thirteen other publicly available implementations at the time of this writing. Some of these implementations used draft versions of this specification. Many others were developed using the Asterisk source code as the only specification. While this approach is definitive, it is very difficult to determine the protocol's higher-level logic and optimize it for the particular programming language or application environment. Interoperability of these implementations cannot be guaranteed. Aside from the trials and tribulations of reverse engineering the source code to create a new implementation, the key lessons learned involve the use of threads, support of international character sets, security, and improved controls to limit interference during DoS attacks. The current Asterisk implementation has a limited number of IAX worker threads and, as a result, its scalability is limited, but it can run on low end machines where threads may not be freely available. Improving the threading model will undoubtedly improve performance. Internationalization and localization are issues that were not originally addressed by most implementations. It was always on the IAX developers' road map, but never a priority. While creating this document, we formalized support for UTF-8 encoding to better support internationalization and localization. With regards to security, many IAX implementations permit cleartext authentication. This method is not secure and should not be used. Recently, some issues have been raised regarding server robustness when under a DoS attack. IAX servers that support unauthenticated requests can receive the equivalent of a SYN attack. To mitigate the impact of these attacks, various controls to limit the number of unauthenticated calls and the number of calls per user may be added
Top   ToC   RFC5456 - Page 97
   to the implementation.  Other approaches, such as transferring the
   call to another, more protected port or using IP rate limiting when
   excessive failures are detected, are also suggested.

   Lastly, given the open nature of the protocol and implementations, it
   is very easy to extend.  This situation makes Postel's Robustness
   Principle, "Be conservative in what you do, be liberal in what you
   accept from others", essential to any successful IAX implementation.

13. Acknowledgments

This work was supported by Internet Foundation Austria. The authors would like to thank Birgit Arkesteijn, Marc Blanchet, Mohamed Boucadair, Steve Kann, Olle Johansson, Alexander Mayrhofer, Tim Panton, and Peter Saint-Andre for their extensive review and technical input. We would also like to thank Jim Dalton, Christopher DeMarco, Frank Ellermann, Daniel Medeiros, Dimitri E. Prado, Leif Madson, and Tilghman Lesher for their support and suggestions.

14. References

14.1. Normative References

[AES] U.S. Department of Commerce/N.I.S.T., "FIPS-197, Announcing the Advanced Encryption Standard", November 2001. [E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [OSP] European Telecommunications Standards Institute, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization and usage exchange", November 2003. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, September 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Top   ToC   RFC5456 - Page 98
   [RFC3261]    Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
                A., Peterson, J., Sparks, R., Handley, M., and E.
                Schooler, "SIP: Session Initiation Protocol", RFC 3261,
                June 2002.

   [RFC3447]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                Standards (PKCS) #1: RSA Cryptography Specifications
                Version 2.1", RFC 3447, February 2003.

   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.

   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
                Profile for Internationalized Domain Names (IDN)",
                RFC 3491, March 2003.

   [RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
                Jacobson, "RTP: A Transport Protocol for Real-Time
                Applications", STD 64, RFC 3550, July 2003.

   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, November 2003.

   [RFC3986]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, January 2005.

   [RFC4347]    Rescorla, E. and N. Modadugu, "Datagram Transport Layer
                Security", RFC 4347, April 2006.

   [RFC4647]    Phillips, A. and M. Davis, "Matching of Language Tags",
                BCP 47, RFC 4647, September 2006.

   [RFC5234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5646]    Phillips, A., Ed., and M. Davis, Ed., "Tags for
                Identifying Languages", BCP 47, RFC 5646, September
                2009.

   [html401]    Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01
                Specification", World Wide Web Consortium
                Recommendation REC-html401-19991224, December 1999,
                <http://www.w3.org/TR/1999/REC-html401-19991224>.
Top   ToC   RFC5456 - Page 99

14.2. Informative References

[PKCS] RSA Laboratories, "PKCS #1 v2.0: RSA Cryptography Standard", October 1998. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003. [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006. [RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006. [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008. [RFC5457] Guy, E., "IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", RFC 5457, February 2010. [wikipedia] Wikipedia, "Inter-Asterisk eXchange", <http://en.wikipedia.org/wiki/IAX>.
Top   ToC   RFC5456 - Page 100

Authors' Addresses

Mark A. Spencer Digium, Inc. 445 Jan Davis Drive NW Huntsville, AL 35806 US Phone: +1 256 428 6000 EMail: markster@digium.com URI: http://www.digium.com/ Brian Capouch Saint Joseph's College PO Box 909 Rensselaer, IN 47978 US Phone: +1 219 866 6114 EMail: brianc@saintjoe.edu Ed Guy (editor) Truphone 12 Williams Rd Chatham, NJ 07928 US Phone: +1 973 437 4519 EMail: edguy@emcsw.com URI: http://www.truphone.com/ Frank Miller Cornfed Systems, LLC 3476 Dayton Street Denver, CO 80238 US Phone: +1 410 404-8790 EMail: mail@frankwmiller.net URI: http://www.sipuseragent.net
Top   ToC   RFC5456 - Page 101
   Kenneth C. Shumard
   3818 N Lakegrove Way
   Boise, ID  83713
   US

   Phone: +1 208 724 7801
   EMail: kshumard@gmail.com