Customer Edge Switching: A Security Framework for 5G 211
private network to connect to public networks sharing a single public IP address.
However, unlike NAT, RGW allows unilateral initiation of inbound connections from
public networks towards private hosts via Circular Pool of Public Addresses (CPPA)
[14]. The CPPA algorithm is activated on an inbound DNS query for FQDN of the host/
service in the private domain, and offers a scalable NAT traversal solution [14] that has
advantages over the classical NAT traversal. RGW allows an inbound connection in
three different ways:
1) a general purpose connection is served by CPPA upon an incoming DNS query for
(a) FQDN of the host or (b) service FQDN of the service running on the host;
2) incoming HTTP(S) traffic, e.g. towards www.host‐a.rgw; is handled by a reverse
HTTP proxy; and
3) via inbound mapping on public IP addresses similar to traditional port forwarding
in NATs.
Figure 9.5 illustrates the CPPA algorithm and shows how RGW accepts connection
initiated from Internet hosts towards hosts or services in the private realm:
1) DNS: Upon receiving a DNS query for FQDN of a served domain, CPPA temporarily
allocates (i.e. ~2 sec), an available address from its pool of public IP addresses and
replies with a DNS response carrying the allocated address, and a TTL = 0 to avoid
caching. Correspondingly, it creates a temporary half‐connection state in RGW. The
half‐connection state applies endpoint‐independent filtering [15] relative to the client.
The state (H:iP H , R X :oP H , P protocol , T Tout ) is unique and includes the IP address and port
of the private host (H:iP H ), the IP address and port on the public side of the RGW
(R X :oP H ), the protocol (P protocol ), and the lifetime of the entry (T Tout ). The TTL = 0 of
DNS response allows control over the address assignment, e.g. taking out addresses
that are under attack, and can offer advantages over static port forwarding in NATs.
2) Data: Upon receiving a new flow matching the half‐connection state, RGW upgrades
the half‐state to a full connection state and returns the corresponding public address
to the circular pool for future use. The inbound packet is forwarded to the private
host and subsequent data packets are admitted as a part of the ongoing flow.
Private hosts
(Tcp22,R1,A,2sec)
Data: (B:TCP393) > (H2:oH2)
Data: (B:TCP393) > (H2:oH2)
Data: (A:TCP22) > (H1:oH1)
Data: (A:TCP22) > (H1:oH1)
Data Payload: (R1:TCP22) < (H1:oH1)
DNS Q (A): b.foo
DNS R (A): b.foo @ R2
DNS Q (A): ssh.a.foo
DNS R (A): ssh.a.foo @ R1
DNS R (A): tcp400.a.foo @ R1
DNS Q (A): tcp400.a.foo
Data Payload: (R1:TCP22) < (H1:oH1)
Data Payload: (R2:TCP393) < (H2:oH2)
Data Payload: (R2:TCP393) < (H2:oH2)
(Tcp400,R1,A,2sec)
(*,R2,A,2sec)
Public
Internet
private
realm
RGW
DNS Servers Internet hosts
Figure 9.5 RGW serving the connections from the legacy Internet.
private network to connect to public networks sharing a single public IP address.
However, unlike NAT, RGW allows unilateral initiation of inbound connections from
public networks towards private hosts via Circular Pool of Public Addresses (CPPA)
[14]. The CPPA algorithm is activated on an inbound DNS query for FQDN of the host/
service in the private domain, and offers a scalable NAT traversal solution [14] that has
advantages over the classical NAT traversal. RGW allows an inbound connection in
three different ways:
1) a general purpose connection is served by CPPA upon an incoming DNS query for
(a) FQDN of the host or (b) service FQDN of the service running on the host;
2) incoming HTTP(S) traffic, e.g. towards www.host‐a.rgw; is handled by a reverse
HTTP proxy; and
3) via inbound mapping on public IP addresses similar to traditional port forwarding
in NATs.
Figure 9.5 illustrates the CPPA algorithm and shows how RGW accepts connection
initiated from Internet hosts towards hosts or services in the private realm:
1) DNS: Upon receiving a DNS query for FQDN of a served domain, CPPA temporarily
allocates (i.e. ~2 sec), an available address from its pool of public IP addresses and
replies with a DNS response carrying the allocated address, and a TTL = 0 to avoid
caching. Correspondingly, it creates a temporary half‐connection state in RGW. The
half‐connection state applies endpoint‐independent filtering [15] relative to the client.
The state (H:iP H , R X :oP H , P protocol , T Tout ) is unique and includes the IP address and port
of the private host (H:iP H ), the IP address and port on the public side of the RGW
(R X :oP H ), the protocol (P protocol ), and the lifetime of the entry (T Tout ). The TTL = 0 of
DNS response allows control over the address assignment, e.g. taking out addresses
that are under attack, and can offer advantages over static port forwarding in NATs.
2) Data: Upon receiving a new flow matching the half‐connection state, RGW upgrades
the half‐state to a full connection state and returns the corresponding public address
to the circular pool for future use. The inbound packet is forwarded to the private
host and subsequent data packets are admitted as a part of the ongoing flow.
Private hosts
(Tcp22,R1,A,2sec)
Data: (B:TCP393) > (H2:oH2)
Data: (B:TCP393) > (H2:oH2)
Data: (A:TCP22) > (H1:oH1)
Data: (A:TCP22) > (H1:oH1)
Data Payload: (R1:TCP22) < (H1:oH1)
DNS Q (A): b.foo
DNS R (A): b.foo @ R2
DNS Q (A): ssh.a.foo
DNS R (A): ssh.a.foo @ R1
DNS R (A): tcp400.a.foo @ R1
DNS Q (A): tcp400.a.foo
Data Payload: (R1:TCP22) < (H1:oH1)
Data Payload: (R2:TCP393) < (H2:oH2)
Data Payload: (R2:TCP393) < (H2:oH2)
(Tcp400,R1,A,2sec)
(*,R2,A,2sec)
Public
Internet
private
realm
RGW
DNS Servers Internet hosts
Figure 9.5 RGW serving the connections from the legacy Internet.