Guidance

Network principles

Published 7 July 2015

Government networks form a platform that enables the delivery of digital services. Good network design should create a user experience that the network is transparent, resilient and ubiquitous, with the right balance of quality, speed, security, control and cost.

These principles help designers deliver this experience for their users when designing networks across government. Note that these are principles, not a set of rules that must be arbitrarily followed. Designers can deviate from them where there is good justification.

When we refer to users, we mean government end-users - individuals who consume a service, not those purchasing or provisioning it. The diagram below presents the context for these principles.

This diagram shows the various networks to which government users could be connecting.

Principle 1: Understand the user need

Understand your basic network requirements

Different networks have very different characteristics. In the diagram we see - at one end of the range - some users accessing services over the highest capacity fixed networks, with others remotely accessing services over a limited-bandwidth mobile link.

Know:

• what business services your users depend on
• what network services they rely on to access them

Document your needs across different networks for:

• bandwidth
• availability
• resilience
• class of service (CoS)
• quality of service (QoS)
• price

Design networks for a roaming user base

Government is increasingly distributed, with people from your department working from home or in other government buildings. This use case should be at the heart of network design. Designing ‘on net’ solutions which only work in your own premises will limit staff mobility and be at odds with your own corporate policies.

The user perception should be that the network is transparent, resilient and ubiquitous.

Design services to be accessed wider than your own department

Design services that can be accessed by a wider user base. This may be other government departments and also corporate partners. Develop tools that can be accessed without extra client software and that can be accessed from other government buildings. This will mean making it possible to access the service from the internet, the PSN or other shared government networks.

Design for organisations who share a site to share the site’s network

Multi-tenanting of government buildings is increasing. Understand the basic network requirements for all the different organisations within a site to encourage sharing of networks at that site. Understand who can supply the network at the best price per location and have an equitable process for sharing the cost.

Consider mobile data (3G,4G) as an alternative data transport mechanism

Historically, mobile connectivity has provided a limited set of functionality. This is now changing and there may be use cases where a 4G service could meet user needs, either as a primary or backup service.

Be able to support your users

Have the skills and tools to diagnose who or what is causing a fault or poor performance.

Check the actual performance and availability that you’re getting. Be prepared for when your service is degraded or overloaded. Plan your business resilience around this. Don’t buy unnecessary service guarantees as a substitute.

Principle 2: Use services to protect your data, don’t rely on the network

Understand the threat

Know:

• who is managing your networks
• what organisations and jurisdictions have access to your data
• who you are sharing your network with
• whether you have adequate data in transit protection

This principle is similar to knowing how separation is achieved in any multi-tenanted cloud services you may consume.

Develop a clear strategy for your security. Security and controls should be directly informed by threat and designed to support your wider risk management approach.

Although modern security products offer a wide range of options, these should not be enabled indiscriminately. Controls can have a negative impact on performance and create unnecessary bottlenecks. There should be a clear reason for enabling or disabling each option.

Design protection of services as near to the service as possible

The use of routing as a mechanism for security has greatly increased the complexity of government networks and significantly reduced flexibility. Instead, use:

• access control mechanisms as close to the service boundary as possible
• clear technical mechanisms and business processes for those that may wish to access your services
• access control tools that are straightforward to review and change, such as firewall rules and access control lists, without impacting the characteristics of the network

Publish routes by default

Secure your devices and services using the cloud security principles. Where your networks face external networks such as PSN, publish the widest set of network routing information possible, while also ensuring that related resources are grouped together so that they can all be reached by making simple configuration changes. This will ensure that other departments can easily connect to services that are made available.

Encrypt without compromising performance

Implement encryption at the most optimal point for performance and cost. Application encryption is better optimised, needs less infrastructure and is easier for the user to verify than network encryption. This is particularly true for bandwidth-intensive peer-to-peer communications such as voice and video. Application encryption could also be extended to protect communications with individual citizens on public networks if needed.

Protect your networks

Have the skills and tools to know what your networks are doing, so that you can spot when activity on the network changes without a reasonable explanation. Check:

• how each of the networks you use protects itself
• what threats are addressed
• how your networks defend against them

When connecting to a network, implement controls in your own environment to protect the networks you use. Apply any controls that are required by your network providers. Connections to PSN should be PSN compliant.

Layer your security

Ensure that you:

• don’t rely on any single component to protect your data
• use security tools as well as native functionality
• consider where logging and alerting can offer a more effective (or complementary) mitigation over rigid or inhibitive controls

Principle 3: Design for interworking and flexibility

Use open standards

Data networks carry a wide variety of network traffic. When choosing services, ensure that they use published standards. There are a number of proprietary standards and approaches in the network layer and unless you have a specific specialist requirement an industry standard should be used.

Maximise use of commoditised services

You should:

• make it easy to change to meet your changing needs
• buy what you need, when you need it
• choose networks separately from other services, using providers’ standard commercial terms and conditions
• minimise your own WAN estate - share infrastructure where you can

Consolidate use of data networks and migrate to IP based technologies

Almost all current technologies rely on data networking. Where possible, all services should be reachable from different networks and so use the same network services, as opposed to specific networks for specific purposes. This significantly reduces costs and makes it much easier to share services with others.

Where non IP-based technologies such as PBX telephony services are used, migrate to a more modern alternative based on IP networking as soon as is practical.

Designing for resilience aside, you should avoid solutions that force your organisation to maintain direct connections to more than one network.

Publish DNS names

Publish DNS records as widely as possible. This enables the widest range of people find a service and avoids restrictions based on knowledge of its name. Avoid restricting access to DNS records as a security mechanism. Knowledge of a service’s domain name or IP address is not the same as being able to access the service.

Remove technical barriers to cross-government access

There is increasing demand for access from across government to physical assets (for example environmental monitoring equipment) originally deployed by individual government organisations. While access control should be enforced, work to eliminate any unnecessary technical constraints that hinder the sharing of such assets. You should:

• consider the wider access of devices that you own by other government organisations
• use IPv6 in specifications and deployments where possible
• restrict the use of NAT as a security tool and instead use alternative access control mechanisms where at all possible

Tools such as NAT have been used historically due to a limit of address spaces and to enable private IP networks to be created. While this is common practice, it significantly increases complexity when connecting services together.

Join up to provide resilience

Consider how working with other government departments could consolidate networks and enhance resilience. If another department building is nearby, consider how you could work together, either to remove the need for circuits or to provide resilience.