Important protocols and methods

The HSCN IP addressing policy is designed to future proof connectivity for health and social care in the longer term. With the advent of cloud technologies and internet enabled applications the NHS will inevitably move towards an internet centric approach. The adoption of Réseaux IP Européens (RIPE) assigned addresses throughout the core of the network, and a move towards the same for all endpoints, will support the eventual move to a cloud/internet based solution.

The HSCN IP addressing policy provides the flexibility to connect either with or without Network Address Translation (NAT). However, HSCN mandates the use of a public (RIPE assigned) address at the point of connection for all new sites, whilst migrated sites may maintain a legacy addressing scheme where there is a technical or business requirement to do so. To meet with this requirement, NAT will be configured at the end-site HSCN customer-premises equipment (CPE). This section provides detail on how NAT works and the importance of taking a co-ordinated approach to its deployment.

NAT is a mechanism that translates IP addresses within private, internal networks to another range of IP addresses for transport over an external network (such as the internet or HSCN). Incoming traffic is translated back for delivery within the inside network by the NAT technology.

NAT is a widely used technology that permits the manipulation of IP traffic. Further details can be found in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1631. In using NAT it may be necessary to consider the practicalities of logging, as well as source/destination access control policies, as NAT manipulates the headers of IP packets, and effectively breaks the end to end Transmission Control Protocol/Internet Protocol (TCP/IP) connection. If considering using NAT it is prudent to establish full logging and auditing policies beforehand, to ensure compliance with good practice guidelines for auditing the use of shared IP addresses.

NAT is a technology that is prevalent in Internet Protocol version 4 (IPv4) networks, where IPv4 public internet addresses are a limited resource. Because of the continuing expansion of the World Wide Web (WWW), and other internet based services demanding IPv4 addresses, it is no longer an option for organisations to obtain additional public IPv4 address space to interface public facing systems, and so NAT has become a necessity for many network designs.

NAT typically takes place at the boundary between an organisation's internal network and any external network gateway, and allows a multitude of private (RFC 1918) IP addresses to use a limited pool of public IP addresses, or a single address if necessary.

NHS organisations typically use NAT to interface between their local sites and the HSCN, whilst home workers may well use NAT within their local router to interface to their internet service provider (ISP).

There are many types of NAT offering many different benefits as well as limitations - the types of compatible applications or the levels of auditing that are applicable at the end service level, for example.

With NAT the border device, typically a router or firewall, uses stateful translation tables to map the private 'hidden' IP addresses to the single address (or pool) and then rewrites the outgoing IP packets on exit so that they appear to originate from the border device. In the reverse communications path responses are mapped back to the originating IP address using the rules (or 'state') stored in the translation tables. The translation table rules established in this fashion are flushed after a pre-determined period, unless new traffic refreshes their state.

The border device can contain two types of NAT table entries, dependent on the NAT method in use:

1. Dynamic entries - where multiple internal (private) IP addresses are translated in to a single external IP address, or a pool of external IP addresses
2. Static entries - where internal and external IP addresses are mapped one-to-one.

In large deployments the masking of unauthorised use of the network, using NAT, can be of serious concern. When faced with possible illegal activities external to the local source network, investigation and discovery of the originating machines within the network can be extremely difficult if detailed logs are not kept.

Port Address Translation

Port Address Translation (PAT), or Network Address Port Translation (NAPT) as it is also known, is a common form of IPv4 NAT. Also known as a 'hide NAT', PAT maps connections from many internal addresses to a single external IP address by using multiple ports that create and handle connections.

These connections are held in a state table to preserve and maintain this connectivity. Because of the design of the TCP/IP protocol, well known ports (0-1023) are not used, leaving ports 1024 to 65535 to be mapped against a single external IP address.

Whilst over 64000 connections could be mapped against a single IP address it is considered good practice not to exceed 40000. If this limit is regularly exceeded performance issues may be encountered, at which point the use of a second IP address, or pool of IP addresses, should be considered. It can sometimes be difficult to retrospectively build this into an existing solution; therefore it should be factored into the design from the outset.

As a result of this mapping process it is not possible for an external host to create a connection directly to an internal host because the end-to-end connection is effectively terminated at the border device.

Although in the first instance this can appear to be a limiting factor for the usefulness of PAT, this process also has its benefits. It provides a very simple yet effective method of protecting internal hosts from external attack at the network level.

Audit and administration considerations

PAT is often utilised in home environments or in large scale deployments.

From an administrative point of view PAT is the simplest to implement, only requiring the entry of a static rule to run effectively. Auditing, on the other hand, can generate large log files dependent on the level of information required and the amount of traffic passing through the border device.

Without these detailed logs it is very difficult to track individual connections made through PAT. In addition, restrictions at the destination service may be difficult to enforce.

Overview

Also known as 'One-to-One NAT' or 'Static NAT', full cone NAT creates a static entry on the NAT device. This maps a single internal IP address to a single external IP address. In a typical installation this process also directly maps all the ports on a one to one basis. As this form of translation is static the translating device maintains only basic connection information, because the translation is applied directly at the initiation of each connection, by matching the source and destination IP addresses.

Typically this form of NAT is utilised when connections are not only initiated from the private network, but also when connections need to be initiated into the private network - for example, for access to a specific system from an external network.

Fig. 1 provides an example of the translation undertaken by the border router when a user within a private network initiates a connection to a server on the internet.

In this scenario the ports are not illustrated as there is no port translation. Should the server initiate the connection to the user machine, the reverse of the connection process described above would be applicable.

Audit and administration considerations

This form of NAT can prove useful in cases when other forms of NAT may already be in use for the masking of multiple internal IP addresses, and where certain machines require external identification. This could be an audit requirement, or be part of an access enforcement policy by a service which restricts access by IP address.

If undertaking auditing at the service endpoint, this form of NAT provides a direct mapping of an external IP address to an internal IP address, which can be linked in case of investigation. The discovery of the internal address, together with its associated machine and user, is dependent on the source organisation's disclosure of this information.

Overview

Restricted cone NAT is very similar to full cone NAT in its operation but distinguishes itself by not allowing incoming connections, unless the private machine (internal to the network) has previously initiated a connection to the external destination address.

Enhancements to restricted cone NAT can create a port restricted cone NAT. This can also be utilised in enforcing policy by using the port to restrict access.

Audit and administration considerations

This form of NAT has similar issues as full cone NAT. However with the addition of port restricted cone NAT, further security measures at the service end can be utilised to restrict connections to individual ports.

Overview

Also known as 'bi-directional NAT', symmetric NAT uses a rule that directs each request from the same internal IP address and port to a specific destination IP address and port to be mapped to a unique external source IP address and port. If the internal IP and port is utilised to connect to a different destination IP and port, a different mapping is used.

Only an external host that receives a packet from an internal host can send a packet back.

Please note that there are some problems associated with symmetric NAT that may cause issues with User Datagram Protocol (UDP) traffic and the combination of IPv4 and IPv6 network traffic.

With symmetric NAT, the NAT mapping refers specifically to the connection between the local host address and port number and the destination address and port number and a binding of the local address and port to a public-side address and port. Any attempt to change any one of these fields requires a different NAT binding. This is the most restrictive form of NAT behaviour under UDP, and it has been observed that this form of NAT behaviour is becoming quite rare, because it prevents the operation of all forms of applications that undertake referral and handover.

Fig. 2 gives an example of a request from an internal IP address and port to a specific destination IP address and port mapped to a unique external source IP address and port.

Owing to the nature of the packet manipulation carried out by NAT, there are several issues with attempting to pass Internet Protocol Security (IPSec) virtual private network (VPN) traffic across devices that perform NAT functions. VPN tunnels gain protection through authentication headers, and use checksums to validate the encapsulated traffic. The NAT packet manipulation alters the checksum of the packet therefore rendering any protection invalid.

In these cases technologies such as NAT Traversal (NAT-T) can be utilised. This uses UDP traffic along with the VPN traffic, thus allowing the creation of a VPN across the NAT device.

NAT Traversal (NAT-T)

IPSec VPN users can run into trouble when traversing a NAT-ing device, such as a firewall or router, because:

1. The TCP/UDP header within an IPSec Encapsulated Security Payload (ESP) packet is encrypted, preventing the mapping of ports by the NAT-ing device.
2. NAT changes the IP and TCP/UDP headers carried within IP packets, invalidating IPSec's integrity check.

VPN Pass-through, usually found in home routers that support PAT, addresses issue '1' (above) by NAT-ing encrypted packets without mapping ports inside the TCP/IP payload. However VPN Pass-through is not a standard, and behaviour varies between vendors' products.

NAT Traversal (NAT-T) refers to a series of Internet Engineering Task Force (IETF) drafts that fix issue '2' (above) by wrapping encrypted IPSec packets inside a clear text UDP wrapper. Any NAT-ing device can translate both the source IP address and source UDP port of the clear text wrapper without changing any part of the encrypted IPSec packet carried inside.

It is essential though that the devices at both ends of the IPSec tunnel support the same version of NAT-T, be able to detect when to use NAT-T, and keep the NAT mapping alive for the lifetime of the tunnel.

Fig. 3 below provides an example of IPSec NAT Traversal

NHS Digital appreciates that the use of NAT comes with advantages and disadvantages. This section outlines some of the recognised drawbacks that can accompany the deployment of NAT.

NAT enhances the level of security

The use of NAT is sometimes seen to enhance, the level of security within a network. This is due to the NAT technology 'hiding' the internal addressing scheme of the organisation behind either a single or a series of separate IP addresses that differ to the internal scheme.

This can also be seen as a drawback where NAT may provide a false sense of security resulting in the overall level of security being lowered. There can be a danger of assuming all security threats are external, leading to practices that make internal breaches much easier. With a secured firewall at the network perimeter, the contribution of NAT to the overall security model is negligible.

IPSec (IP Security)

IPSec is a set of protocols developed to support packet level authentication and encryption at the transport layer. The technology depends on end-to-end consistency of the IP addresses in the IP headers. NAT presents a significant obstacle to IPSec technology, as the IP address header is changed when traversing a NAT environment. Application layer security techniques, such as SSL, that do not depend on an IP address can function correctly in the presence of NAT.

Application Level Gateway (ALG)

An Application Level Gateway (also known as Application Layer Gateway) is usually employed between application peers when an intervening protocol or device (in this case NAT) prevents direct connectivity. The purpose of the ALG is to simulate direct connectivity. The IETF RFC2663 relating to NAT Terminology provides a definition of ALG in section 2.9.

The following lists a number of protocols that may require the aid of an ALG to traverse a NAT environment.

• FTP (File Transfer Protocol)
• DNS (Domain Name System/Service)
• RealAudio (de-facto standard for streaming data over the World Wide Web)
• H.323 (multimedia conferencing protocol, which includes voice, video, and data conferencing, for use over packet-switched networks)
• SMTP (Simple Mail Transfer Protocol)
• Telnet (terminal emulation)
• RSVP (Resource Reservation Set-up Protocol)
• SNMP (Simple Network Management Protocol)

ALG's are vendor specific, and are not normally developed to generically fit environments outside the particular vendor's product range. It is recommended that these issues should be discussed with the hardware vendor prior to any purchase or implementation involving NAT.