Transport Protocol Selection

The PeerEdge Orchestrator supports UDP, TCP, and TLS v1.2 as transport protocols for SIP signaling. The PeerEdge Orchestrator supports RTP and SRTP protocols for media sessions. Both RTP and SRTP use UDP as the transport protocol.

 Transport protocols provide essential services to voice applications, including: 

• Multiplexing  Assign port numbers to each application, which enables the IP network to carry thousands of application messages between hosts simultaneously.

• Reliable message delivery  The receiver verifies the transmission of each packet using a checksum to ensure contents are not corrupted. The receiver acknowledges the verified packet or requests retransmission of the corrupted packet. If the transmitter doesn’t receive an acknowledgment, it assumes the packet is lost and retransmits it. The transport layer also ensures packets arrive in sequence by inserting a sequence number.

• Flow control  The receiver uses a transmission window value to provide feedback to the sender about buffer space to avoid buffer overruns and underruns.

• Congestion management  When multiple losses occur, the transport layer implements a back-off algorithm that allows congestion to clear before resuming transmission. 

Recommendations

If any portion of the end-to-end network transport is considered unsecure (i.e. direct Internet), then 46 Labs recommends using TLS.

If the end-to-end network transport is already secure (i.e. SD-WAN, MPLS, IPsec tunnels), then 46 Labs recommends using UDP. If any customer networking devices in the SIP signaling path between the customer SBCs/PBXs and the PeerEdge Orchestrator do not properly handle UDP message fragmentation and assembly, then 46 Labs recommends TCP.

The PeerEdge Orchestrator supports the following cipher suites, signature hashing algorithms and crypto media suites.

TLS supported cipher suites

Signature Hashing Algorithms supported 

Crypto Media Suites Supported

Example Cipher Suite breakdown

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS - identifies the cipher suite as a Transport Layer Security (TLS) cipher suite

ECDCHE  - used for key exchange (Elliptic Curve Diffie-Hellman Ephemeral is this example)

RSA - used for authentication (the server presents an RSA certificate for TLS handshake signing (Rivest-Shamir-Adleman public-key cryptographic algorithm in this example))

AES_256_GCM - the symmetric encryption algorithm (Advanced Encryption Standard (AES) with a 256-bit key in Galois/Counter Mode (GCM) in this example)

SHA384 - the message authentication (MAC) algorithm (Secure Hash Algorithm with a 384-bit (48-byte) digest)

Example Secure Hash Algorithm breakdown

ecdsa_secp521r1_sha512

ecdsa - the public key signature algorithm the provide authentication and integrity (not encryption) (Elliptic Curve Digital Signature Algorithm is this example)

secp521r1 - a standard NIST elliptic curve over a 521-bit prime field

SHA512 - the message authentication (MAC) algorithm (Secure Hash Algorithm with a 512-bit (64-byte) digest) 

Example Crypto Media Suite breakdown

AEAD_AES_256_GCM

AEAD - provides confidentiality and integrity (Authenticated Encryption with Associated Data in this example)

AES - symmetric block cipher that provided encryption (Advanced Encryption Standard in this example)

256 - the encryption key size

GCM - GCM in AEAD mode encrypts data and authenticates both the data and any associated unencrypted input (AAD) (Galois/Counter Mode in this example)

Note: The selection of cipher suites and signature hashing algorithms is limited by the cryptographic signature algorithm RSA (Rivest-Shamir-Adleman) or ECDSA (Elliptic Curve Digital Signature Algorithm) of the TLS certificate.  For example, a certificate with an RSA signature algorithm would not support the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite.