huawei se2900 session border ... -...

HUAWEI SE2900 Session Border Controller V300R002

Technical White Paper for NAT Traversal

Issue 01

Date 2016-01-15

HUAWEI TECHNOLOGIES CO., LTD.

Issue 01 (2016-01-15) Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.

i

Copyright © Huawei Technologies Co., Ltd. 2016. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior

written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective

holders.

Notice

The purchased products, services and features are stipulated by the contract made between Huawei and

the customer. All or part of the products, services and features described in this document may not be

within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,

information, and recommendations in this document are provided "AS IS" without warranties, guarantees or

representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the

preparation of this document to ensure accuracy of the contents, but all statements, information, and

recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

Bantian, Longgang

Shenzhen 518129

People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

http://www.huawei.com/

mailto:[email protected]

HUAWEI SE2900 Session Border Controller

Technical White Paper for NAT Traversal About This Document



ii

About This Document

Author

Prepared by Song Xin Date 2013-11-30

Reviewed by Date

Reviewed by Date

Granted by Date

Change History

Date Version Description Author

2015-03-31 1.00 Completed the initial draft. Song Xin


Technical White Paper for NAT Traversal Contents



iii

Contents

About This Document .................................................................................................................... ii

Overview ............................................................................................................................................ 2

Origin of NAT Traversal ........................................................................................................................................ 2

NAT Type ............................................................................................................................................................... 3

Addressing NAT Traversal Problems by the Proxy Mechanism ............................................ 4

Proxy Mechanism Overview .................................................................................................................................. 4

Location of the SE2900 on the Network ................................................................................................................ 5

Signaling NAT Traversal ........................................................................................................................................ 5

Registration Process ......................................................................................................................................... 6

Signaling NAT Keepalive ................................................................................................................................ 7

Media NAT Traversal ............................................................................................................................................. 8

Comparison Between Traversal Technologies ......................................................................... 13

ALG Technology .................................................................................................................................................. 13

STUN Technology ................................................................................................................................................ 14

MIDCOM Technology ......................................................................................................................................... 15

Protocol Modification .......................................................................................................................................... 16

Traversal Technology Comparison ....................................................................................................................... 16



1


SE2900 V300R002

Keywords:

NAT

Abstract:

Abbreviations:

Abbreviations Full Name

ALG Application Level Gateway

NAT Network Address Translation

STUN Simple Traversal of UDP through NAT


Technical White Paper for NAT Traversal 0Overview



2

Overview

Origin of NAT Traversal NAT technology was developed to alleviate IPv4 address exhaustion. The early IPv4 system

aimed to enable each IP network element to have a globally reachable IP address. If so, all

network elements can communicate with each other using IP addresses. As IP networks keep

expanding, the available IP addresses become exhausted. NAT technology can mitigate this

problem during the IPv4-to-IPv6 transition which provides larger address space.

Unlike traditional gateways that connect various networks, NAT devices can be regarded as

special gateways that connect private and public IP networks. NAT devices connect private

and public networks by translating IP addresses. The source IP address contained in an IP

packet from a private network is a private address. After the IP packet passes through a NAT

device, its source IP address is translated into a routable public address. In addition, the NAT

device create an address binding relationship covering the private source address, public

source address, and public destination address. In this way, the response packet from the

public network can be routed to the source element on the private network.

Although NAT technology can mitigate IP address exhaustion, the technology brings about

the following problems:

Most of the existing protocols are incompatible with NAT technology. IP addresses can

be translated by NAT devices at the network and transport layers but cannot be translated

at the application layer. As a result, IP addresses contained in the application-layer

protocol are still private addresses and response packets sent based on these IP addresses

cannot be routed to the source network elements.

NAT devices bind the private source address, public source address, and public

destination address together only for IP packets sent from a private network to a public

network. Public network entities cannot proactively connect to private network entities

before the binding relationship is created.

Each address mapping entry generated on a NAT device has a lifecycle. If no packets

matching an entry are received before the lifecycle expires, the NAT device deletes the

entry. This makes public network entities unable to connect to the intended private

network entities after the lifecycle expires.

NAT traversal includes four modes: static NAT, STUN, ALG, and proxy. For details about

differences between these NAT traversal modes, see chapter 0"Comparison Between Traversal

Technologies."

This document describes the NAT traversal in proxy mode based on the SE2900.


Technical White Paper for NAT Traversal 0Overview



3

NAT Type NAT is classified into the following types based on address mapping behaviors on NAT

devices:

Full cone NAT

Restricted cone NAT

Port restricted cone NAT

Symmetric NAT

Sample addresses used in the following NAT type descriptions are as follows:

Private address 192.168.0.37:6060

Public address 202.96.0.1:5060 translated by NAT devices

Public address 203.1.1.1:7060

Full cone NAT: After a NAT mapping is established between 192.168.0.37:6060 and

202.96.0.1:5060, the NAT device forwards all public network IP packets destined for

202.96.0.1:5060 to 192.168.0.37:6060. All static NAT mappings configured on the NAT

device are full cone NAT mappings.

Restricted cone NAT: The NAT device sends IP packets with the source address of 203.1.1.1

and destination address of 202.96.0.1:5060 to the network element at 192.168.0.37:6060 only

if the NAT device sets up a dynamic NAT mapping between 192.168.0.37:6060 and

202.96.0.1:5060 and the private network entity at 192.18.0.37:6060 sends packets to the

public network entity at 203.1.1.1:7060 through the NAT device. In the lifecycle of a NAT

mapping, IP packets using the same private address as the source address use the same NAT

mapping when passing through NAT devices. Therefore, the source address of all IP packets

from 192.168.0.37:6060 is translated into 202.96.0.1:5060, regardless of their destination

addresses.

Port restricted cone NAT: This NAT type is similar to restricted cone NAT and has the

restriction on port numbers. Only IP packets from 203.1.1.1:7060 are matched the NAT

mapping.

Symmetric NAT: Public ports selected for NAT mappings vary with destination addresses of

IP packets. If IP packets from 192.168.0.37:6060 are sent to different destination addresses,

NAT devices set up different mappings for the IP packets. Like port restricted cone NAT,

symmetric NAT defines that a private address must proactively send IP packets to a public

address before these IP packets are matched the NAT mapping.

Currently, most of the NAT devices support port restricted cone NAT.



0Addressing NAT Traversal Problems by the Proxy

Mechanism



4

Addressing NAT Traversal Problems by the Proxy Mechanism

Proxy Mechanism Overview An SE2900 functions as a proxy to address NAT traversal problems. It directionally transmits

signaling or media streams in proxy mode that has no specific requirement for NAT devices.

Carriers do not need to replace NAT devices on the live network. The SE2900 re-specifies a

destination address and port for a signaling or RTP stream from a private or public address to

help achieve address translation between various network domains, including address

translation between private and public networks. This technically ensures that signaling or

media streams can traverse NAT devices.

The SE2900 is a logical function entity and provides two functions: SIP signaling proxy and

media proxy.

SIP signaling proxy: For users, the SE2900 can be regarded as part of an IMS or NGN

network. Registration and call messages from IMS or NGN network users are sent to the

SE2900. The SE2900 processes these messages and forwards them to the core CSCF or

softswitch. For the core CSCF and softswitch, the SE2900 can be regarded as a user. The core

CSCF or softswitch sends call requests to the SE2900. The SE2900 processes these messages

and forwards them to callees. The SE2900 processes and analyzes the signaling to obtain

address change and bandwidth requirement information about calls and determine whether the

media streams pass through the SE2900 based on the network resource usage. This helps to

protect networks, prevent bandwidth theft, and achieve NAT traversal.

Media proxy: All RTP media streams pass through the SE2900. The SE2900 processes and

forwards media streams to enable communications between internal and external users. The

SE2900 checks whether the packets are valid and specifies a forwarding policy for the media

streams based on the signaling processing results. The forwarding policy covers packet

filtering, QoS, and address translation. The SE2900 specifies IP addresses and ports for

internal and external users to receive RTP media streams to correctly forward the media

streams and ensure QoS and security.




Mechanism



5

Location of the SE2900 on the Network

图1-1 Location of the SE2900 on an IMS network

Signaling

Media

Access

network

Access

network

NAT/

Firewall

NAT/

Firewall

SE2900

Core

network

The SE2900 that serves as a proxy is deployed at the edge or aggregation layer of an IP

network and acts as a signaling and media aggregation point.

Signaling NAT Traversal Enabling an INVITE request to reach the intended user behind an NAT device is the major

problem to be resolved in signaling NAT traversal. The problem can be resolved by

completing the registration process to set up an address mapping on the NAT device for

sending messages. The SE2900 or user keeps the NAT channel alive by sending packets

periodically.




Mechanism



6

Registration Process

图1-2 Registration process when the SE2900 acts as a proxy

The registration process is as follows:

1. A UE sends a REGISTER request to the NAT device. The source IP address contained in

the REGISTER packet header and the contact address contained in the payload are both

the private address/port (Aa) of the UE.

2. The NAT device executes the following operations:

− Allocates a public address/port (Nn) to the UE.

− Generates a mapping between Aa and Nn.

− Translates Aa in the packet header into Nn.

− Forwards the REGISTER request to the SE2900.

3. The SE2900 receives the REGISTER request and executes the following operations: -

Allocates a public signaling address/port (Dd).

− Translates the address contained in the REGISTER packet header and payload.

− Records the mapping between Nn/Cc and Dd/Ee.

− Sends the REGISTER request to the P-CSCF or softswitch to which the UE belongs.

4. The P-CSCF or softswitch authenticates the UE and sends a response packet to the

SE2900.

5. The SE2900 receives the response packet and executes the following operations:

− Modifies the address contained in the packet header and payload according to the

address mapping.

− Forwards the response packet to the NAT device.

6. The NAT device translates the IP address contain in the response packet into Aa and

forwards the packet to the UE.




Mechanism



7

Signaling NAT Keepalive

After the registration process, a signaling channel between the SE2900 and UE is formed. The

address mapping established on the NAT device, however, has an aging period. The address

mapping will be deleted if the NAT device does not receive packets from the UE or SE2900

before the aging period expires. Therefore, the SE2900 or UE must send keepalive packets to

the NAT device to update NAT entries and prevent the address mapping from getting aged.

The SE2900 can send following packets to keep the address mapping alive:

Hello packets

The SE2900 sends a Hello packet (UDP packet) to the UE within a period of time. The

format of the Hello packets can be customized.

SIP Re-REGISTER packets

After the SE2900 receives a response packet from the core network, the SE2900 changes

the Expires header or parameter to make the UE quickly send a REGISTER request to

update the address mapping entry.

STUN packets

If a NAT device is deployed between the SE2900 and the UE, the UE periodically sends

STUN requests to the NAT device to keep the corresponding address mapping entries on

the NAT device alive. SIP keepalive using STUN requests applies to SIP over UDP in the

A-SBC scenario.

PING/PONG packets

PING and PONG messages are transmitted between the UE and SE2900 to keep a TCP

connection alive. If a NAT device is deployed between the SE2900 and the UE, the

exchanges of the PING and PONG packets also keep corresponding address mapping

entries on the NAT device alive. SIP keepalive using PING/PONG packets applies to SIP

over TCP in the A-SBC scenario.

表 1-1 shows the differences between the four types of packets.

表1-1 Differences between sending the four types of packets

Category Sending Hello Packets

Sending SIP Re-REGISTER Packets

Sending STUN Packets

Sending PING/PONG Packets

Remarks

Flexibility Flexible Not flexible Flexible Flexible The format of the

Hello packets can be

customized.

Impact on

SE2900

performance

Lightly

impacted

Greatly

impacted

Lightly

impacted

Lightly impacted The SE2900 needs

to transcode the SIP

Re-REGISTER

packets. This affects

SE2900

performance.




Mechanism



8

Media NAT Traversal Media streams are transmitted over an IMS or NGN network using RTP. RTP is carried over

UDP. The IP addresses and ports used for the RTP media streams are negotiated using the

signaling messages sent for establishing calls.

The following signaling protocols can be used to establish calls: SIP, H.323, H.248, and

MGCP. These protocols use the SDP information of the caller and callee to negotiate the

media addresses and ports for the caller and callee.

When the signaling carrying SDP information passes through the NAT device, the NAT

device converts only the IP, TCP, and UDP packet headers, and not the IP address and port.

The media address obtained by a callee is the private address and port a caller. As a result, the

callee cannot use the private address to access the caller on the private network.

Deploying a media proxy on the network is an effective way to implement media NAT

traversal. The media proxy translates private media addresses and ports into public addresses

and ports during E2E media negotiation.

The SE2900 provides the media proxy function to support media NAT traversal without the

need to upgrade the NAT devices on the live network. The SE2900-based media NAT

traversal can be divided into two stages: signaling negotiation and media latching.

Signaling negotiation stage, at which media address mappings are set up by SDP negotiation




Mechanism



9

Before a caller and callee make a call, they must send signaling packets to negotiate a channel

for transmitting media streams. The SE2900 executes the following operations at the signaling

negotiation stage:

7. Obtains the caller and callee IP address and port for receiving media streams according

to SDP information contained in the signaling packets.

8. Allocates the access- and core-side media addresses and ports to the caller and callee.

9. Creates address mapping entry (192.168.1.2:2008, 20.1.3.8:7003)<->(10.10.3.5:5007,

20.1.5.9:9000) for media sessions. All media streams will pass through the SE2900 but

only the media streams matching media session entries on the SE2900 will be forwarded.

Media transmission stage, at which the IP addresses for media packets are learned and

translated

The media transmission stage can be further divided into three sub stages: pre-media-latching,

media latching, and post-media-latching.

Pre-media-latching sub stage

Because UE1 with the IP address of 192.168.1.2 has not sent media packets to the SE2900,

the media address mapping between the UE1 and SE2900 is not generated on the NAT device.

As a result, the NAT device discards all media packets destined for UE1.




Mechanism



10

Media latching sub stage

UE1 sends the first media packet to the SE2900. After the first media packet passes through

the NAT device, the NAT device creates an address mapping between 192.168.1.2:3008 and

20.1.2.3:8028. The SE2900 receives the media packet processed by the NAT device and

executes the following operations:

1. Learns the transport-layer address and port (20.1.2.3:8028) contained in the media

packet.

2. Updates the address mapping entry (20.1.2.3:8028, 20.1.3.8:7003)<->(10.10.3.5:5007,

20.1.5.9:9000) for media sessions.




Mechanism



11

Post-media-latching sub stage

The SE2900 queries the updated address mapping entry (20.1.2.3:8028,

20.1.3.8:7003)<->(10.10.3.5:5007, 20.1.5.9:9000) after it receives media packets destined for

UE1 and forwards the media packets to 20.1.2.3:8028. The NAT device queries the address

mapping entry (192.168.1.2:3008)<->(20.1.2.3:8028) and forwards the media packets to UE1.




Mechanism



12

The disadvantage of the preceding media NAT traversal solution is that, in some cases, the UE

receives but does not send media packets. For example, if the stream mode in the SDP

information contained in the signaling packets from the caller is sendonly, the stream mode

negotiated for the callee can only be recvonly. To prevent this problem, the SE2900 changes

the stream mode for the caller to sendrecv before it forwards the caller's SDP information to

the callee. By doing this, the stream mode negotiated for the callee can be sendrecv or

sendonly.


Technical White Paper for NAT Traversal 0Comparison Between Traversal Technologies



13

Comparison Between Traversal Technologies

At present, the following traversal technologies are available: ALG, STUN, MIDCOM,

protocol modification, and proxy.

ALG Technology NAT and NAPT are applicable only to IP addresses in IP packet headers and port information

in TCP/UDP packet headers. The data part of packets using special protocols may contain IP

address or port information that cannot be fully translated by the NAT device. This may cause

problems.

For example, an FTP server using a private address may need to send its IP address to a PC on

the public network to establish a session between them. The private address is in the data part

of the IP packet and cannot be translated by the NAT device. Once the PC receives and uses

this private address, the FTP server becomes unreachable for the PC.

The ALG technology can be used to resolve such a problem. The ALG is a proxy for

translating IP addresses contained in the packets with a certain application protocol. It

interacts with the NAT device to establish the state, uses the NAT state information to modify

the specific data encapsulated in the data part of IP packets, and implements other necessary

works to make the application protocol run across different ranges.

Use an ICMP packet for which the destination is unreachable as an example. The data part of

this packet contains the packet A's header that causes the error. Before the NAT device

forwards packet A, the NAT device has translated the IP address contained in packet A.

Therefore, the source address contained in packet A is not the real IP address of the PC on the

private network. If the ICMP ALG function is enabled, the ALG interworks with the NAT

device before the NAT device forwards the ICMP packet. The ALG opens the ICMP packet

and translates the address in packet's A header of the data part. The translated address is

presented as the real address of the PC on the private network. The NAT device forwards the

ICMP packet after the ALG completes other necessary works.

The H.323 ALG, SIP ALG, MGCP ALG, H.248 ALG functions must be implemented for the

following protocols: H.323, SIP, MGCP, and H.248.





14

图 1-3 shows a typical networking scenario in which ALG technology is applied.

图1-3 Typical NAT ALG networking diagram

L2Intranet of

Corporation

Provider Network

Firewall/NAT

Softswitch

SoftPhone

L2Intranet of

Corporation

Firewall/NAT

IAD

Register Response

Register Request

NAT with ALG

Function

NAT with ALG

Function

STUN Technology STUN consists of two parts: the STUN client deployed on the private network and the STUN

server deployed on the public network. The UE must support the STUN client function. The

STUN server can be integrated into a component of the corresponding application device,

such as a softswitch on the NGN, or function as an independent device.

图 1-4 shows a typical networking scenario in which STUN technology is applied.

图1-4 Typical STUN networking diagram

L2Intranet of

Corporation

Provider Network

Firewall/NAT

STUN Server

Softswitch

Binding Request

Binding Response

STUN Client SoftPhone

L2Intranet of

Corporation

Firewall/NAT

STUN Client IAD

Register Response

Register Request





15

STUN technology is simple traversal of UDP through a NAT device. The STUN client uses

UDP to send a STUN request to the STUN server. After the STUN server receives the request,

it generates a response message that carries information about the source port in the request,

that is, the corresponding public port of the STUN client on the NAT device. The NAT device

then forwards the response message to the STUN client. The STUN client obtains its public

address on the NAT device based on the response message, adds this public address to the

UDP load of the later call protocol, and notifies the remote end that the local RTP receiving

address and port are those in the front of the NAT device. The NAT mapping entry for media

streams has been established on the NAT device using the STUN protocol. The media streams

can successfully traverse the NAT device.

The STUN protocol supports NAT traversal without the need to change existing NAT devices

or firewalls on the live network. A large number of NAT devices and firewalls on the live

network do not support VoIP services. To resolve this problem using MIDCOM or NAT ALG

technology, the NAT devices and firewalls must be replaced. Replacing all these devices is

difficult. STUN technology, however, can resolve the problem without the need to replace all

the existing NAT devices and firewalls. In addition, STUN technology can be used on a

network where multiple NAT devices are connected in series. On the contrary, MIDCOM

technology cannot effectively control multi-level NAT devices. For details, see section

0"MIDCOM Technology."

The disadvantage of STUN technology is that the NGN UE must support the STUN client

function. STUN technology does not support H.323 or traversal of TCP connections. In

addition, STUN technology does not support firewall traversal for NGN services or

symmetric NAT traversal. On an enterprise network that requires high security, symmetric

NAT is usually deployed at the egress node.

MIDCOM Technology MIDCOM technology includes two parts: MIDCOM agent and Middlebox. The MIDCOM

agent instructs the Middlebox to establish NAT mapping entries. Generally, the Middlebox is

integrated into a NAT device or firewall. A softswitch, proxy server, or UE can act as the

MIDCOM agent.

图 1-5 shows a typical networking scenario in which MIDCOM technology is applied.

图1-5 Typical MIDCOM networking diagram

L2Intranet of

Corporation

Provider Network

Firewall/NAT/MIDBOX

MIDCOM Agent

Softswitch

SoftPhone

L2Intranet of

Corporation

Firewall/NAT/MIDBOX

IAD





16

The MIDCOM agent, not the Middlebox, identifies application services. According to the

MIDCOM architecture, more services can be supported by upgrading the MIDCOM agent

without modifying basic Middlebox features. This makes MIDCOM technology outperform

NAT ALG technology.

In NGN service applications, the Middlebox function can be implemented on a NAT device or

firewall. The softswitch, MIDCOM agent, identifies the IP voice and video protocols such as

H.323, SIP, MGCP, and H.248, and controls the NAT device and firewall. Therefore,

MIDCOM can be a solution for NGN services to traverse the NAT device and firewall.

MIDCOM technology supports control packet and media stream encryption and is secure.

Protocol Modification

Current multimedia application protocols cannot traverse a NAT device or firewall.

Modifying the protocols can address this problem.

Protocols such as H.323, SIP, MGCP, and H.248, however, cannot be modified for the

traversal because technology for tackling this issue is being developed. It is not described in

this document.

Traversal Technology Comparison

表1-2 Traversal technology comparison

Technology Type

ALG STUN MIDCOM Protocol Modification

Proxy

Location Edge of a private

or public

network

Any location Any location Any location Any location

Requirements

for the

Existing NAT

Devices and

Firewalls

The existing

NAT devices

and firewalls

must be replaced

or upgraded to

support ALG

technology.

Symmetric NAT

is not supported.

The existing NAT

devices and

firewalls must be

replaced or

upgraded to

support the

Middlebox

function.

Changing the

existing NAT

devices and

firewalls is not

required.

Changing the

existing NAT

devices and

firewalls is not

required.

Multi-level

NAT

The NAT device

at each level

must support

ALG

technology.

No NAT device

at any level is

the symmetric

NAT device.

The Middlebox or

ALG function

must be

supported.

Supported Supported

Impact on the

Live Network

Routes need to

be added.

No impact Routes need to be

added.

No impact No impact





17

Technology Type

ALG STUN MIDCOM Protocol Modification

Proxy

Requirements

for UEs

No specific

requirements

UEs must

support the

STUN client

function.

No specific

requirements (The

MIDCOM agent

function can be

implemented on

the server.)

Protocol

modification

A UE uses the

same port to

send and

receive

streams.

Requirements

for the Server

No specific

requirements

No specific

requirements

The server must

support the

MIDCOM agent

function.

Protocols must

be modified.

No specific

requirements

Deployment location: If proxy technology is used, a proxy device can be deployed at the edge

or aggregation layer of the IP network in overlay network mode. If ALG technology is used,

the device implementing ALG technology must be deployed at the private network's egress to

the public network. If STUN, MIDCOM, or protocol modification technology is used, the

device implementing the technology can also be deployed at any location on the IP network.

Requirements for the existing NAT devices and firewalls: If proxy or protocol modification

technology is used, the existing NAT devices and firewalls do not need to be modified or

upgraded. If ALG, STUN, or MIDCOM technology is used, the existing NAT devices and

firewall must support the technology. If they do not support the technology, they must be

upgraded.

Multi-level NAT: If proxy technology is used, multi-level NAT is supported and all the NAT

devices do not need to be upgraded or modified. If ALG, STUN, or MIDCOM technology is

used, the NAT devices and firewall at all levels must support the ALG, STUN, or MIDCOM

function. The NAT device that does not support the ALG, STUN, or MIDCOM function must

be upgraded. If protocol modification technology is used, the server and UE must support the

corresponding functions and multi-level NAT.

Impact on the live network: If proxy, STUN, or protocol modification technology is used, the

live network is not impacted, and the live network topology and routes remain unchanged. If

ALG or MIDCOM technology is used, routes must be added.

Requirements for UEs: Proxy, ALG, and MIDCOM technologies have no requirements for

UEs. STUN and protocol modification technologies require UEs to provide specific functions.

UEs that do not provide specific functions must be upgraded.

Requirements for the server: Proxy, ALG, and STUN technologies have no requirements for

the server. MIDCOM and protocol modification technologies require the server to support

specific functions.

huawei se2900 session border ... -...

Documents