example assumes that the middlebox is a traditional NAPT. Figure 6
shows the exploration of the first policy rule. In reply to a Policy
Rule Status (PRS) transaction, the middlebox always returns the
following list of parameters:
- policy rule owner
- group identifier
- policy rule action (reserve or enable)
- protocol type
- port range
- direction
- internal IP address
- internal port number
- external address
- external port number
- middlebox inside IP address
- middlebox inside port number
- middlebox outside IP address
- middlebox outside port number
- IP address versions (not printed)
- middlebox service (not printed)
- inside and outside interface (optional, not printed)
agent middlebox
| PRS PID1 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 RESERVE UDP 1 "" |
| ANY ANY ANY ANY |
| ANY ANY IPADR_OUT PORT_OUT1 |
| |
Figure 6: Status report for an outside reservation
The ’ANY’ parameter printed in Figure 6 is used as a placeholder in
policy rules status replies for policy reserve rules. The policy
rule with PID1 is a policy reserve rule for UDP traffic at the
outside of the middlebox. Since this is a reserve rule, direction is
empty. As there is no internal or external address involved yet,
these four fields are wildcarded in the reply. The same holds for
the inside middlebox address and port number. The only address
information given by the reply is the reserved outside IP address of
the middlebox (IPADDR_OUT) and the corresponding port number
(PORT_OUT1). Note that IPADR_OUT and PORT_OUT1 may not be
wildcarded, as the reserve action does not support this.
Applying PRS to PID2 (Figure 7) shows that the second policy rule is
a policy enable rule for inbound UDP packets. The internal
destination is fixed concerning IP address, protocol, and port
number, but for the external source, the port number is wildcarded.
The outside IP address and port number of the middlebox are what the
external sender needs to use as destination in the original packet it
sends. At the middlebox, the destination address is replaced with
the internal address of the final receiver. During address
translation, the source IP address and the source port numbers of the
packets remain unchanged. This is indicated by the inside address,
which is identical to the external address.
agent middlebox
| PRS PID2 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 IN |
| IPADR_INT PORT_INT1 IPADR_EXT ANY |
| IPADR_EXT ANY IPADR_OUT PORT_OUT2 |
| |
Figure 7: Status report for enabled inbound packets
For traditional NATs, the identity of the inside IP address and port
number with the external IP address and port number always holds
(A1=A3 in Figure 3). For a pure firewall, the outside IP address and
port number are always identical with the internal IP address and
port number (A0=A2 in Figure 3).
agent middlebox
| PRS PID3 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE UDP 1 OUT |
| IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 |
| IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 |
| |
Figure 8: Status report for enabled outbound packets
Figure 8 shows enabled outbound UDP communication between the same
host. Here all port numbers are known. Since again A1=A3, the
internal sender uses the external IP address and port number as
destination in the original packets. At the firewall, the internal
source IP address and port number are replaced by the shown outside
IP address and port number of the middlebox.
agent middlebox
| PRS PID4 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ENABLE TCP 1 BI |
| IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 |
| IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 |
| |
Figure 9: Status report for bi-directional TCP traffic
Finally, Figure 9 shows the status report for enabled bi-directional
TCP traffic. Note that, still, A1=A3. For outbound packets, only
the source IP address and port number are replaced at the middlebox,
and for inbound packets, only the destination IP address and port
number are replaced.
4.2. Enabling a SIP-Signaled Call
This elaborated transaction usage example shows the interaction
between a SIP proxy and a middlebox. The middlebox itself is a
traditional Network Address and Port Translator (NAPT), and two SIP
user agents communicate with each other via the SIP proxy and NAPT,
as shown in Figure 10. The MIDCOM agent is co-located with the SIP
proxy, and the MIDCOM server is at the middlebox. Thus, the MIDCOM
protocol runs between the SIP proxy and middlebox.
+-------------+
| SIP Proxy |
| for domain ++++
| example.com | +
+-------------+ +
^ ^ +
Private | | + Public Network
Network | | +
+----------+ | | +----+------+ +----------------+
| SIP User |<-+ +->| Middlebox |<------->| SIP User Agent |
| Agent A |<#######>| NAPT |<#######>| B@example.org |
+----------+ +-----------+ +----------------+
<--> SIP Signaling
<##> RTP Traffic
++++ MIDCOM protocol
Figure 10: Example of a SIP Scenario
For the sequence charts below, we make these assumptions:
- The NAPT is statically configured to forward SIP signaling from
the outside to the SIP proxy server -- i.e., traffic to the
NAPT’s external IP address and port 5060 is forwarded to the
internal SIP proxy.
- The SIP user agent A, located inside the private network, is
registered at the SIP proxy with its private IP address.
- User A knows the general SIP URL of user B. The URL is
B@example.org. However, the concrete URL of the SIP User Agent
B, which user B currently uses, is not known.
- The RTP paths are configured, but not the RTCP paths.
- The middlebox and the SIP server share an established MIDCOM
session.
- Some parameters are omitted, such as the request identifier
(RID).
Furthermore, the following abbreviations are used:
- IP_AI: Internal IP address of user agent A
- P_AI: Internal port number of user agent A to receive RTP data
- P_AE: External mapped port number of user agent A
- IP_AE: External IP address of the middlebox
- IP_B: IP address of user agent B
- P_B: Port number of user agent B to receive RTP data
- GID: Group identifier
- PID: Policy rule identifier
The abbreviations of the MIDCOM transactions can be found in the
particular section headings.
In our example, user A tries to call user B. The user agent A sends
an INVITE SIP message to the SIP proxy server (see Figure 10). The
SDP part of the particular SIP message relevant for the middlebox
configuration is shown in the sequence chart as follows:
SDP: m=..P_AI..
c=IP_AI
where the m tag is the media tag that contains the receiving UDP port
number, and the c tag contains the IP address of the terminal
receiving the media stream.
The INVITE message forwarded to user agent B must contain a public IP
address and a port number to which user agent B can send its RTP
media stream. The SIP proxy requests a policy enable rule at the
middlebox with a PER request with the wildcarded IP address and port
number of user agent B. As neither the IP address nor port numbers
of user agent B are known at this point, the address of user agent B
must be wildcarded. The wildcarded IP address and port number
enables the ’early media’ capability but results in some insecurity,
as any outside host can reach user agent A on the enabled port number
through the middlebox.
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| INIVTE | | |
| B@example.org | | |
| SDP:m=..P_AI.. | | |
| c=IP_AI | | |
|--------------->| | |
| | | |
| | PER PID1 UDP 1 EVEN IN | |
| | IP_AI P_AI ANY ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 ANY ANY | |
| | IP_AE P_AE1 300s | |
Figure 11: PER with wildcard address and port number
A successful PER reply, as shown in Figure 11, results in an NAT
binding at the middlebox. This binding enables UDP traffic from any
host outside user agent A’s private network to reach user agent A.
So user agent B could start sending traffic immediately after
receiving the INVITE message, as could any other host -- even hosts
that are not intended to participate, such as any malicious host.
If the middlebox does not support or does not permit IP address
wildcarding for security reasons, the PER request will be rejected
with an appropriate failure reason, like ’IP wildcarding not
supported’. Nevertheless, the SIP proxy server needs an outside IP
address and port number at the middlebox (the NAPT) in order to
forward the SIP INVITE message.
If the IP address of user agent B is still not known (it will be sent
by user agent B in the SIP reply message) and IP address wildcarding
is not permitted, the SIP proxy server uses the PRR transaction.
By using the PRR request, the SIP proxy requests an outside IP
address and port number (see Figure 12) without already establishing
a NAT binding or pin hole. The PRR request contains the service
parameter ’tw’ -- i.e., the MIDCOM agent chooses the default value.
In this configuration, with NAPT and without a twice NAT, only an
outside address is reserved. In the SDP payload of the INVITE
message, the SIP proxy server replaces the IP address and port number
of user agent A with the reserved IP address and port from PRR reply
(see Figure 12). The SIP INVITE message is forwarded to user agent B
with a modified SDP body containing the outside address and port
number, to which user agent B will send its RTP media stream.
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
...PER in Figure 11 has failed, continuing with PRR ...
| | | |
| |PRR tw v4 v4 A UDP 1 EVEN 300s| |
| |*****************************>| |
| |<*****************************| |
| | PRR OK PID1 GID1 EMPTY | |
| | IP_AE/P_AE 300s | |
| | | |
| | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE |
| |-------------------------------------------->|
| |<--------------------------------------------|
| | 200 OK SDP:m=..P_B.. c=IP_B |
Figure 12: Address reservation with PRR transaction
This SIP ’200 OK’ reply contains the IP address and port number at
which user agent B will receive a media stream. The IP address is
assumed to be equal to the IP address from which user agent B will
send its media stream.
Now, the SIP proxy server has sufficient information for establishing
the complete NAT binding with a policy enable rule (PER) transaction,
i.e., the UDP/RTP data of the call can flow from user agent B to user
agent A. The PER transaction references the reservation by passing
the PID of the PRR (PID1).
For the opposite direction, UDP/RTP data from user agent A to B has
to be enabled also. This is done by a second PER transaction with
all the necessary parameters (see Figure 13). The request message
contains the group identifier (GID1) the middlebox has assigned in
the first PER transaction. Therefore, both policy rules have become
members of the same group. After having enabled both UDP/RTP
streams, the SIP proxy can forward the ’200 OK’ SIP message to user
agent A to indicate that the telephone call can start.
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| | PER PID1 UDP 1 SAME IN | |
| | IP_AI P_AI IP_B ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 IP_B ANY | |
| | IP_AE P_AE1 300s | |
| | | |
...media stream from user agent B to A enabled...
| | | |
| | PER GID1 UDP 1 SAME OUT | |
| | IP_AI ANY IP_B P_B 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID2 IP_B P_B | |
| | IP_AE P_AE2 300s | |
| | | |
...media streams from both directions enabled...
| | | |
| 200 OK | | |
|<---------------| | |
| SDP:m=..P_B.. | | |
| c=IP_B | | |
Figure 13: Policy rule establishment for UDP flows
User agent B decides to terminate the call and sends its ’BYE’ SIP
message to user agent A. The SIP proxy forwards all SIP messages and
terminates the group afterwards, using a group lifetime change (GLC)
transaction with a requested remaining lifetime of 0 seconds (see
Figure 14). Termination of the group includes terminating all member
policy rules.
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| BYE | BYE |
|<---------------|<--------------------------------------------|
| | | |
| 200 OK | 200 OK |
|--------------->|-------------------------------------------->|
| | | |
| | GLC GID1 0s | |
| |*****************************>| |