Network Address Translation (NAT) – Good Practice Guideline
Programme
NPFIT
Document Record ID Key
Sub-Prog /
Project
Infrastructure
Security
NPFIT-FNT-TO-IG-GPG-0011.06
Prog. Director
Chris Wilber
Status
Approved
Owner
James Wood
Version
2.0
Author
Mike Farrell
Version Date
04/01/2010
Network Address Translation (NAT)
Good Practice Guideline
© Crown Copyright 2010
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
Amendment History:
Version
Date
Amendment History
0.1
First draft for comment
0.2
03/01/2006
Updated formatting
0.3
26/01/2006
Additions
0.4
10/03/2005
Technical Author
1.0
31/03/2006
Approved
1.1
06/11/2009
Document refreshed
1.2
13/11/2009
Incorporating changes suggested by the Infrastructure Security Team
1.3
25/11/2009
Incorporating further change suggested by the Infrastructure Security
Team
1.4
30/11/2009
Incorporating changes suggested by Matt Ballinger
2.0
04/01/2010
Approved for Issue, incorporating minor changes suggested by Head of
IT Security
Forecast Changes:
Anticipated Change
When
Annual Review
Jan 2011
Reviewers:
This document must be reviewed by the following:
Name
Signature
Title / Responsibility
Date
Infrastructure
Security Team
Version
1.1
Matt Ballinger
Junior Project Manager Technology Office
1.3
Approvals:
This document must be approved by the following:
Name
Signature
James Wood
Title / Responsibility
Head of IT Security
Date
Version
2.0
Distribution:
NHS Connecting for Health Infrastructure Security Website
http://nww.connectingforhealth.nhs.uk/infrasec/gpg
© Crown Copyright 2010
Page 2 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
Document Status:
This is a controlled document.
Whilst this document may be printed, the electronic version maintained in FileCM is
the controlled copy. Any printed copies of the document are not controlled.
Related Documents:
These documents will provide additional information.
Ref no
Doc Reference Number
Title
Version
1
NPFIT-SHR-QMS-PRP-0015
Glossary of Terms Consolidated.doc
Latest
2
NPFIT-FNT-TO-INFR-SEC-0001
Glossary of Security Terms
Latest
Glossary of Terms:
List any new terms created in this document. Mail the NPO Quality Manager to have
these included in the master glossary above [1].
Term
Acronym
© Crown Copyright 2010
Definition
Page 3 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
Contents
1
2
About this Document ...........................................................................................5
1.1
Purpose .........................................................................................................5
1.2
Audience .......................................................................................................5
1.3
Content ..........................................................................................................5
1.4
Disclaimer......................................................................................................6
Introduction..........................................................................................................7
2.1
Background ...................................................................................................7
3
Network Address Translation ..............................................................................8
4
Port Address Translation (PAT).........................................................................10
5
6
7
4.1
Overview .....................................................................................................10
4.2
Audit and Administration Considerations .....................................................10
Full Cone NAT ...................................................................................................11
5.1
Overview .....................................................................................................11
5.2
Audit and Administration Considerations .....................................................12
Restricted Cone NAT.........................................................................................13
6.1
Overview .....................................................................................................13
6.2
Audit and Administration Considerations .....................................................13
Symmetric NAT .................................................................................................14
7.1
8
NAT with Virtual Private Networks (VPNs) ........................................................15
8.1
9
Overview .....................................................................................................14
NAT Traversal (NAT-T) ...............................................................................15
IPv6 ...................................................................................................................17
9.1
Overview .....................................................................................................17
9.2
IPv4 to IPv6 Transition ................................................................................17
Appendix A. N3 IP Address Space .........................................................................19
© Crown Copyright 2010
Page 4 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
1 About this Document
1.1 Purpose
The purpose of this guide is to address the major challenges associated with
Network Address Translation (NAT), the various forms of NAT and the advantages
and disadvantages of each type.
The following information covers all environments anticipated to interact with the
NHS Care Records Service (NCRS). This document contains guidance for New NHS
Network (N3) connected systems and networks, in conformance with the Information
Governance Statement of Compliance (IGSoC).
The information contained in this document should be used as an informed
assessment of NAT. However it is the sole responsibility of network owners to
ensure that any network solutions that they deploy are sufficiently secure to fully
satisfy their own risk assessment.
1.2 Audience
This document has been written for readers who have a good level of experience
and familiarity with local and wide area networks.
1.3 Content
This document comprises this following sections / topics: •
Introduction and Background
•
Network Address Translation
•
Port Address Translation
•
Full Cone NAT
•
Restricted Cone NAT
•
Symmetric NAT
•
NAT with Virtual Private Networks, and NAT Traversal (NAT-T)
•
IPv6
•
Appendix A. N3 IP Address Space
© Crown Copyright 2010
Page 5 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
1.4 Disclaimer
Reference to any specific commercial product, process or service by trade name,
trademark manufacturer, or otherwise, does not constitute or imply its endorsement,
recommendation, or favouring by National Health Service Connecting for Health
(NHS CFH). The views and opinions of authors expressed within this document shall
not be used for advertising or product endorsement purposes.
Any party relying on or using any information contained in this document and/or
relying on or using any system implemented based upon information contained in
this document should do so only after performing a risk assessment. It is important
to note that a risk assessment is a prerequisite for the design of effective security
countermeasures. A correctly completed risk assessment enables an NHS
organisation to demonstrate that a methodical process has been undertaken which
can adequately describe the rationale behind any decisions made. Risk
assessments should include the potential impact to live services of implementing
changes.
This means that changes implemented following this guidance are done so at the
implementers’ risk. Misuse or inappropriate use of this information can only be the
responsibility of the implementer.
© Crown Copyright 2010
Page 6 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
2 Introduction
The following information provides a knowledge-based framework that will help
maintain good practice values within any NHS organisation.
The reader will find good practice guidance for the use of NAT within their
organisational network infrastructure. This includes: • What NAT is, plus the advantages and disadvantages of its use.
• The impact on auditing and security of using NAT.
2.1 Background
Network Address Translation is a widely used technology that permits the
manipulation of IP traffic. Further details can be found in Request for Comments
(RFC) 1631. 1
For instance, NAT can both reduce costs and provide an organisation with a central
point of communication by ‘hiding’ a number of internal machines behind a single
public Internet Protocol (IP) address. The masking of internal network resources
from an external network, such as the Internet, is also an important security feature
NAT may also prove useful if it becomes necessary to restrict traffic flows to
individual machines, while still allowing the majority of connected machines with a
shared IP address to access the external network.
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.
1
http://www.faqs.org/rfcs/rfc1631.html
© Crown Copyright 2010
Page 7 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
3 Network Address Translation
Network Address Translation 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 without a significant need, and so NAT has become a necessity for
many network designs.
Network Address Translation 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)2 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
N3 network, whilst home workers may well use NAT within their local router to
interface to their Internet Service Provider (ISP). The main security benefit in this
case being that any number of local devices can be hidden from the Internet.
There are many types of NAT offering many different benefits as well as limitations.
I.e. the types of compatible applications or the levels of auditing that are applicable
at the end service level.
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: • Dynamic entries - where multiple internal (private) IP addresses are translated
into a single external IP address, or a pool of external IP addresses.
• Static Entries – where internal and external IP addresses are mapped one-toone.
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.
2
http://www.faqs.org/rfcs/rfc1918.html
© Crown Copyright 2010
Page 8 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
Notwithstanding future legislation, local policy should determine the minimum
retention period for NAT logs, balancing the imperatives of: Too long = significant storage overhead.
Too short = logs may expire before an incident can be investigated
The Home Office’s voluntary code of practice (Retention of Communications
3
Data
Under Part 11: Anti-Terrorism, Crime & Security Act 2001) 3 provides a
valuable reference. It suggests a maximum retention period of 12 months but
does not prejudice longer periods
3
http://www.opsi.gov.uk/si/si2003/draft/5b.pdf
© Crown Copyright 2010
Page 9 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
4 Port Address Translation (PAT)
4.1 Overview
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 (01023) 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. If
correctly configured the border device can remove all traces of information from the
initiated connection, thereby restricting the amount of information disclosed to any
malicious user external to the network.
4.2 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.
© Crown Copyright 2010
Page 10 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
5 Full Cone NAT
5.1 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. E.g. 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.
(1) A packet is created with
the following information
Src Address: 192.168.0.10
Dest Address: 212.45.65.89
(5) The response is
received
(2) The router performs the
translation to:
Src Address: 230.98.78.65
Dest Address: 212.45.65.89
(4) The router performs the
translation to:
Src Address: 212.45.65.89
Dest Address: 192.168.0.10
User Machine
192.168.0.10
NAT Router
192.168.0.1
230.98.78.65
(3) The server responds
with a packet:
Src Address: 212.45.65.89
Dest Address: 230.98.78.65
Server on Internet
212.45.65.89
Fig. 1: Outbound NAT.
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
© Crown Copyright 2010
Page 11 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
5.2 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.
© Crown Copyright 2010
Page 12 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
6 Restricted Cone NAT
6.1 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.
6.2 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.
© Crown Copyright 2010
Page 13 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
7 Symmetric NAT
7.1 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.
© Crown Copyright 2010
Page 14 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
8 NAT with Virtual Private Networks (VPNs)
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.
8.1 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 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 4 that fix 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 2 below provides an example of IPSec NAT Traversal
4
http://www.faqs.org/rfcs/rfc3715.html, http://www.faqs.org/rfcs/rfc3947.html and http://www.faqs.org/rfcs/rfc3948.html
© Crown Copyright 2010
Page 15 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
Fig 2 Example of IPSec NAT Traversal
© Crown Copyright 2010
Page 16 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
9 IPv6
9.1 Overview
IPv6 is designated as the successor to IPv4, with the main driving force for its design
being the expected depletion of the IPv4 public address space.
Where IPv4 uses 32 bit addresses IPv6 uses 128 bits, resulting in an immensely
larger address space than IPv4 (around 79 Octillion times the IPv4 address space),
with the IPv6 subnet size standardised at 64 bits.
This expanded address space eliminates the primary need for network address
translation (NAT), from the network design point of view, as increased flexibility in IP
address allocation and routing is provided by IPv6.
As well as increased IP address space IPv6 provides several key benefits over IPv4,
including: •
Simpler packet headers. IPv6 specifies a new packet format, designed to
minimise packet-header processing.
•
IPv6 provides better capabilities to support auto-configuration, such as
Dynamic Host Configuration Protocol (DHCP), multicasting, traffic engineering,
and zero configuration (Zeroconf) 5 networking.
•
Mandatory IPsec support. IPsec was originally developed for IPv6.
9.2 IPv4 to IPv6 Transition
Because of the large number of IPv4 deployments throughout the world it is likely
that the two protocols will co-exist for a number of years, if not decades. Many
systems now support dual-stack TCP/IP functions and can communicate in IPv4
and/or IPv6.
The three main transition techniques envisaged are as follows: -
5
•
Dual-stack network, where hosts and routers implement both IPv4 and IPv6
protocols. This enables the network to support both IPv4 and IPv6 services
and applications.
•
Tunnelling, this enables the interconnection of IP clouds. For instance,
separate IPv6 networks can be interconnected through a native IPv4 network
by means of a tunnel. IPv6 packets would be encapsulated by a border router
before transportation across the IPv4 network, and decapsulated at the border
of the receiving IPv6 network. Tunnels could also be used to interconnect
remaining IPv4 clouds through the IPv6 infrastructure.
http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Zeroconf
© Crown Copyright 2010
Page 17 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
•
30/11/2009 / Approved/ 2.0
A translation mechanism, required where it is necessary for an IPv6 only host
has to communicate with an IPv4 host. Like tunnelling techniques translation
can be implemented in border routers and hosts.
From the security point of view the main benefit of NAT, whether it be in an IPv4 or
IPv6 environment, is the concealment of private computing and network
infrastructure from an external network, such as the Internet. It should be noted that
currently IPv6 does not adequately support NAT, although there has been
discussion within the IETF around it. 6
6
http://ietfreport.isoc.org/idref/draft-iab-ipv6-nat/
© Crown Copyright 2010
Page 18 of 19
Network Address Translation (NAT) – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0011.06
30/11/2009 / Approved/ 2.0
Appendix A. N3 IP Address Space
N3 is an IPv4 wide area network which primarily routes RFC1918 7 IP addresses
allocated to NHS and 3rd Party sites. This address space is controlled by the N3
Service Provider (N3SP) and comprises: • The class A private address range (10.0.0.0 to 10.255.255.255)
• The class B private address range (172.17.0.0 to 172.31.255.255)
NB:
The Class C private address range (192.168.0.0 - 192.168.255.255) is not
routable across the N3 network. It is recommended for internal Local Area
Network (LAN) use.
Information on current N3 IP network addressing policy can be found at: http://www.n3.nhs.uk/TechnicalInformation/N3IPnetworkaddressing.cfm
7
http://www.faqs.org/rfcs/rfc1918.html
© Crown Copyright 2010
Page 19 of 19