GCNet Reference Architecture Document (RAD)

1. Introduction

1.1 SSC Mandate

Shared Services Canada has a mandate to ensure the most efficient use of information technology in the Canadian Federal Government. This will be done through the consolidation and standardization of many redundant departmental IT operations and assets into a consolidate enterprise IT operation.

“Shared Services Canada (SSC) was created to modernize how the federal government manages its information technology (IT) infrastructure in order to better support the delivery of programs and services to Canadians. Our department has launched a new and innovative approach to deliver a technology platform for a 21st Century Public Service –one that is modern, reliable, secure and cost-effective”.^{Footnote 1}

More specifically, SSC’s objectives are to maintain quality operations, reduce costs, and transform the way IT is done in the GC.

Ensuring the continuation of activities

Shared Services Canada is focusing on the Government of Canada Network (GCNet) to reduce redundancy and improve efficiencies; specifically, the focus is on the transformation of many separate GC networks into a standard cohesive single network. This standardized and consolidated network will be referred to as GCNet. The vision for GCNet is to consolidate many separate GC departmental networks as well as converge specialized networks for voice, video and data into a single international logical network for the GC in an effort to lower costs, increase service quality and reduce security risk.

1.2 Purpose and Scope

The purpose of this Reference Architecture Document (RAD) is to provide a high-level service model of the GCNet, including a description of its capabilities, and a depiction and description of its target architecture. The GCNet is broken down into its component services. The capabilities of each service will be further described in a separate Service Definition Document (SDD), and the architecture of each will be further described in a separate Technical Architecture Document (TAD), including security and privacy controls.

1.3 Context

1.3.1 SSC Mission

In the context of service excellence, innovation and value for money, SSC is mandated to maintain and improve the delivery of IT infrastructure services while simultaneously renewing the GC’s IT infrastructure. SSC is bringing a true enterprise perspective to GC IT infrastructure, not just to improve service but also to eliminate duplication and cut costs. An important aspect of that work is the development of enterprise-wide service standards, formerly established and maintained by each of the 43 partner organizations for their own environment, and now being developed collaboratively for the GC.

In collaboration with its partners, and through the counsel provided by industry, SSC is identifying the IT infrastructure requirements of the government as an enterprise and applying best practices to address its operational challenges and meet the GC’s modernization targets. Building a more secure and robust foundation for modern government operations is also strengthening our ability to protect the information of Canadians.

1.3.2 Current GC Network Environment

Across the federal government today, there are more than 3,000 overlapping and uncoordinated electronic networks within and between departments and agencies, and hundreds of telecommunications networks that provide voice and data services to over 300,000 users.

Many government buildings house several departments and agencies. However, each department and agency is using and maintaining a network unto itself, instead of using one network per building, For example, Place du Portage in the National Capital Region, the Dominion Building in Prince Edward Island, Canada Place in Alberta, and the Guy Favreau Complex in Quebec all have several departments and several different networks. The Guy Favreau Complex has nine separate networks.

Through rationalization, consolidation and standardization the GC can save money and reduce its network maintenance burden. As we consolidate and renew our data centres (DCs), we will also rationalize and streamline the networks that link our DCs together. This will lead to further efficiencies. Having an organized, coordinated system of electronic networks also lays the foundation to help improve security.

1.3.3 SSC Vision

SSC’s vision for the GCNet is an integrated telecommunications network designed and built to support GC operations from coast to coast and internationally. Inherent GCNet design features will include the flexibility to accommodate community, hybrid and public clouds.

1.3.4 Telecommunications Transformation Program

The Telecommunications Transformation Program (TTP) is responsible for the transformation, planning and sourcing of telecommunications services for the GC, as well as the strategies for delivering those services. The TTP objective is to centralize their administration; rationalize service delivery to achieve greater efficiencies, reduce costs and minimize risks; and improve security and service quality. In support of these responsibilities, the TTP further fosters strategic relationships with central agencies and SSC’s partners, in part to develop policies, standards and guidance for network service management and delivery.

1.3.5 Strategic Business Outcomes

The TTP is providing the opportunity to achieve the following strategic business outcomes:

Savings – Transformation, consolidation and standardization of telecommunications services will realize material and ongoing cost savings through economies of scale and avoidance of future costs. These savings will be reinvested in the transformation activities.

Service – Transformation, consolidation and standardization of telecommunications services will better enable the delivery of government services to Canadians by improving availability, scalability and agility of IT infrastructure services. Better services mean responsiveness to business demands and improved client satisfaction. Outcomes will be measured realizing increases in capacity and speed, improved response times, and reductions in service calls and service outages.

Security – Transformation, consolidation and standardization of telecommunications services will provide a technology infrastructure and environment to meet program needs, enable enhanced cyber security, and strengthen Canada’s national security. Outcomes will be measured by realizing a reduction in vulnerabilities, security breaches, and improved audit findings.

1.3.6 Cyber and IT Security Transformation Programs

The Cyber and IT Security (CITS) Program is responsible for the development of plans and designs for cyber and IT security services for the GC IT infrastructure, including up to Secret infrastructure, within SSC’s mandate.

The CITS program has three service areas: cyber security, IT security and GC Secret Infrastructure (GCSI). The TTP has a number of dependencies on the CITS Transformation Program. Some dependencies are mentioned in this document such as perimeter security and Identity, Credential and Access Management (ICAM). Future elements of the GC CITS Program, such as the identification of GC Enterprise Security Controls and the GC Enterprise Threat Assessment, will need to be considered over time. Similarly, as part of the GC Integrated Risk Management framework, key activities within the Enterprise IT Security Risk Management process such as the security categorization of GCNet services, and the identification and validation of security controls to be included within the architecture, will take place as part of the development of the TADs. Achieving adequate integration with the above programs and initiatives will help protect GCNet against threats that could cause injury to GC business services, and will facilitate risk response to a variety of threats, including hostile cyber attacks, natural disasters, structural failures and human errors (both intentional and unintentional).

2. GCNet Service Description

The GCNet is a network that meets the following high level requirements:

• REQ_GCNet_1. Provides valid GC users located anywhere in the world with controlled access to the GC network. Once connected to the GC network, users have access to data centre hosted GC applications and information, as well as to those hosted on external networks (e.g. Internet, Business Partners), to which they have access rights. Access to the network is granted based on the successful authentication of registered GC users, as well as other policy rules such as proper configuration of a user’s device (e.g. personal firewall and virus scanner) and location (i.e. connection point), and the user’s role-based profile.
  
• REQ_GCNET_2. Supports the delivery of high availability applications and information across multiple DCs.
  
• REQ_GCNET_3. Supports real-time peer to peer communications between users such as IP telephony and video conferencing.
  
• REQ_GCNET_4. Where viable, supports the transfer of traffic with different performance requirements including applications with a low tolerance to latency, jitter and/or dropped packets.
  
• REQ_GCNET_5. Supports roaming of users within GC buildings. Supports connectivity of vehicles via radio access (e.g. RCMP squad cars).
  
• REQ_GCNET_6. Supports secure access by users working at home or on the road (i.e. via Secure Remote Access [SRA]).
  
• REQ_GCNET_7. Supports access to and provision of certain GC information and applications by Trusted Partners, Business and the public.
  
• REQ_GCNET_8. Supports the creation of separate networks (i.e. security domains) to meet varying security (e.g. designated, classified) and transitioning requirements. The GCNet services will be designed with safeguards to handle Protected A information, and the use of GCNet services for information of higher injury will require additional safeguards commensurate with injury level. As such, security controls required to protect information of a higher sensitivity level (e.g. encryption) are the responsibility of end points (e.g. storage system, servers, PCs) and/or applications.
  
• REQ_GCNET_9. Supports the creation of multiple network security zones within a security domain (e.g. Public Access Zone [PAZ]) to the Internet).
  
• REQ_GCNET_10. Supports the deployment of end points through automated IP address delivery (i.e. Dynamic Host Configuration Protocol [DHCP]) and the delivery of network time (i.e. Network Time Protocol [NTP]).
  
• REQ_GCNET_11. Supports the management of the network by providing comprehensive network administration and management capabilities, as well as name to address mapping (Domain Name System [DNS]), and a common time source for all GC network components (i.e. NTP).

3. Target Architecture

The target architecture is depicted in Figure 1. The diagram illustrates that GCNet provides connectivity within GC office buildings and DCs, as well as between office buildings and DCs. It also depicts how remote GC users and sites, and non-GCNet networks can connect to GCNet.

Once authenticated, GC users in GC office buildings can connect to the GCNet either through wired or wireless (Wifi) connections. Similarly, authenticated users in authorized vehicles can connect to GCNet via radio access.

Remote users who have access to the Internet, whether through public hotspots, home Wifi, or 3G/4G cellular data networks, can securely tunnel through the Internet to GCNet (i.e. SRA). Remote GC branch offices can connect to GCNet through a similar capability.

The public can access public-facing GC websites through a controlled connection between the Internet and GCNet. This same capability allows GC users controlled access to public Internet websites.

Data Centres are inter-connected such that GC applications can be deployed across more than one DC in order to achieve higher availability and/or performance.

The networks of trusted partners can access GCNet directly through controlled connections. Examples of trusted trading partners include other levels of government, and GC application and service providers (e.g. Email Transformation Initiative [ETI] for email), as well as organization (i.e. businesses) with a mandate to provide to the GC, or consume from the GC, significant information.

Finally, the GCNet can be partitioned into multiple physical and logical networks (e.g. the green and blue logical networks depicted) in order to support significantly different security profiles (e.g. designated versus classified networks), or functionality (e.g. management of end points and network elements versus user and client data), and to support the transition from the current state to the target architecture.

Figure 1: GCNet Target Architecture

4. GCNet Services

Section 3 described and depicted the GCNet as a single logical construct. This section decomposes the GCNet into its major functional service components. It classifies service components in terms of whether they are external (i.e. can be ordered by clients), or internal (i.e. for SSC use only in support of external services). It defines any interdependencies between the various internal and external services, as well as dependencies on foundational standards and services provided by other SSC service programs (e.g. ICAM).

4.1 Functional Decomposition of GCNet

The component services of GCNet, as well as the relationship (i.e. interfaces) between those services, are illustrated in Figure 2. Each of the component services is described below. It should be noted that these functional components are logical in nature, and not meant to imply any implementation constraints on the GCNet. For instance, the Inter-Building Network (IBN), depicted as one component, need not be constrained to a single service provider’s network.

Figure 2: GCNet Functional Decomposition

4.1.1 Wired Intra-Building Network (C1)

The Wired Intra-Building Network (WIBN) provides user devices with wired connections to the network and/or wired connections between network elements (e.g. switches and routers). The WIBN supports peer to peer communications (e.g. voice, video) between endpoints within a building, provides endpoints access to local services (e.g. print, VoIP local survivability gateway), and provides access to the IBN service (i.e. C3). It supports the transfer of traffic with varying Quality of Service (QoS) requirements, as well as providing support for multicast applications. It supports the creation of multiple virtual private networks to meet varying security needs, as well as the transitioning from current to the target state.

4.1.2 Wifi (C2)

Wifi provides user devices with wireless access to the WIBN (C1). Wifi supports peer to peer communications (e.g. voice, video) between endpoints within a building, provides endpoints access to local services (e.g. print, VoIP local survivability gateway). It supports the transfer of traffic with varying QoS requirements. It supports the creation of multiple virtual private networks to meet varying security needs, as well as transitioning from current to end-state.

4.1.3 Inter-Building Network (C3)

The IBN service provides national and inter-national inter-building connectivity to all buildings where the GC is a tenant. It supports the transfer of traffic with varying QoS requirements, as well as providing support for multicast applications. It supports the creation of multiple virtual private networks to meet varying security needs, as well as transitioning from current to end state. The IBN can support both wired and wireless access including satellite, 3G/4G cellular and mobile radio connections.

4.1.4 Intra-Data Centre Network (C4)

The Intra-Data Centre Network (DCN) provides connectivity to servers and storage in highly virtualized compute and storage environments. It supports the transfer of traffic with varying QoS requirements, as well as providing support for multicast applications. It supports the creation of multiple virtual private networks to meet varying security and performance needs, as well as transitioning from current to end state.

4.1.5 Inter-Data Centre Network (C5)

The Inter-DCN allows the extension of network services such as (but not limited to) layer 2 VLANs and layer 3 subnets across multiple DCs in support of high availability services for applications and information (e.g. server clustering, synchronous replication, real-time migration of workloads). It must provide low latency transfer between DC pairs in order to meet the requirements of such applications.

4.1.6 Network Partitioning (NP)

Network Partitioning is not a component of the GCNet per se, but rather it is an important capability of the Intra-Building Network components (C1 and C2), the IBN component (C3), the Intra-DCN (C4) component and the Inter-DCN component (C5). In the case of C1/C2 and C4, these partitions can be either physical (i.e. separate wiring and access points/ switches/routers) or virtual (i.e. Security Identifier [SID]/VLAN or Virtual Routing and Forwarding [VRF] based), whereas for C3 and C5 it would be virtual only (i.e. VRF based or separate wavelengths or lambdas).

Network partitions can be used to separate traffic whose content is significantly different in purpose (e.g. end-point and network element management traffic versus user/client application traffic), or security sensitivity (e.g. designated versus classified data), thereby creating different security domains.^{Footnote 3} Network partitions will also be used to further separate different security domains into network security zones as defined by the Communication Security Establishment Canada (CSEC).^{Footnote 4}

Figure 3 illustrates three logical networks configured on the GCNet (i.e. GCNet components C1 and C2 plus C3 and C4). Logical Networks 1 and 3 are meant for user/client traffic, whereas Logical Network 2 is reserved for the SSC IT management purposes. Each of the depicted logical networks corresponds to a separate security domain. The SSC IT management network (i.e. Logical Network 2) extends to office buildings for the management of network elements depicted here by a router and switch icon.

Figure 3: Partitioning the Network into Security Domains

Network partitioning, at least for DCN and Inter-DCN network components, will be required to support the application security profile based containment concept included in the Data Centre Reference Architecture Document.^{Footnote 5} Three configurations are specified that result in the utilization of shared physical infrastructure, with an additional configuration reserved for departments that can justify the need of a dedicated physical infrastructure. These options are:

1. Shared Virtual Platform/Shared Containment Model: (Default) Deploy departments’ and agencies’ workloads on shared virtual platforms and consolidate workloads within shared containment areas (i.e. shared security domain);
2. Dedicated Virtual Platform/Shared Containment Model: For instances where departments’ workloads cannot (should not) be deployed within the same virtual platform but can still reside within a shared containment area (i.e. shared security domain), a dedicated virtual platform would be created;
3. Dedicated Virtual Platform/Dedicated Containment Model: For instances where departments’ and agencies’ workloads cannot (should not) be deployed within the same containment area, a dedicated virtual platform/dedicated containment area would be created; and
4. Dedicated Physical Platform/Dedicated Containment Model: For departments and agencies that have specific security requirements that cannot be addressed by either of the above shared physical models, a separate and dedicated physical infrastructure will be used.

Requirements for dedicated infrastructure need to be supported by a business case and approved by the appropriate governance bodies.

4.1.7 Perimeter Defence (C6)

Perimeter Defence (PD) consists of firewall functionality that allows network partitions (i.e. security domains and security zones) to be interconnected in a controlled (i.e. secure) manner. This is illustrated in Figure 4 where network partitioning is used to create two security domains (i.e. Domain A and C), each with its own security profile, as well as security zones within each domain to separate the web (Operational Zone [OZ] or Public Access Zone [PAZ]), application (Application Restricted Zone [APRZ)) and data (Data Restricted Zone [DRZ]) tiers of the three tier applications hosted in each domain. Perimeter defence, depicted by the firewall icon, allows these separate domains and zones to be interconnected securely as required, with data transfer between partitions controlled by appropriate security policy.

Figure 4: Perimeter Defence

4.1.8 Secure Remote Access (C7)

Secure Remote Access (SRA) allows remote users and GC sites to connect to GCNet through non-secure networks like the Internet. Secure Remote Access gateways are deployed at GC DCs, from which SRA client software, either persistent or non-persistent, is deployed to user devices requiring connectivity. In the case of connectivity for a site rather than individual users, an SRA gateway must also be deployed at the remote site.

4.1.9 Network Access Control (C8)

Network Access Control (NAC) allows connectivity to the network to be controlled not only through authentication of registered users, but also based on other user or device characteristics, such as:

1. the user’s role based profile,
2. whether or not the device is recently patched,
3. the existence and status of a local firewall and virus scanner, and
4. the location of the user.

Although NAC is depicted as a centralized function in Figure 2 (i.e. at a data centre), it is actually distributed. The policy is administered centrally but it is enforced locally at the connection point (e.g. by a switch within the Intra-Building Network).

4.1.10 Network Management and Monitoring (C9)

Network Management and Monitoring provides all of the functions that are required for the Network Management staff to:

1. monitor and report on the utilization and performance of the network;
2. do capacity planning and provisioning of the network accordingly;
3. detect the source of performance degradation, failures and security incidents, and effect changes to mitigate or resolve such issues;
4. manage change and control the configuration of the network; and
5. generate billing information based on per client or per user utilization.

4.1.11 Network Time (C10)

Network Time (aka NTP) is a service that ensures that network connected devices are synchronized to a common time source. This is critical in detecting and reporting on performance and security issues. NTP is delivered both to internal elements of the GCNet as well as to end devices (e.g. user devices, servers) that connect to the network. Although NTP is depicted as a centralized function (i.e. at a data centre), it will likely need to be distributed for performance reasons.

4.1.12 Dynamic Host Control (C11)

Dynamic Host Control (DHCP) is a GCNet provided service that dynamically assigns IP addresses and other network related information (e.g. location of DNS servers) to GC user devices when they connect to the network. This service facilitates the deployment of user end devices, as well as their mobility by precluding the need to provision these addresses manually in each device. Although DHCP is depicted as a centralized function in Figure 2, it can be distributed for performance reasons. In such a case, the address space is administered centrally but addresses are distributed locally at the connection point (e.g. by a switch/router within the Intra-Building Network). The DHCP service must support both IPv4 and IPv6 for the GC.

4.1.13 GCNet DNS Zone (C12)

A GCNet DNS Zone is required to support the management of GCNet elements (e.g. routers, switches) based on names recognizable by operations staff rather than the less user friendly IP addresses assigned to the network elements. This DNS zone is limited to supporting the management of the GCNet. DNS zones that support application level URLs are outside the scope of the GCNet service. The GCNet DNS Zone will either be configured as its own root, or be a zone of the GC DNS service (i.e. gc.ca). The former will make the names private to GCNet, whereas the later makes the names visible on the Internet.

GCNet DNS Zone (C12) will use the same technology as DNS zones that support application level GC URLs (i.e. one DNS technology in SSC).

4.1.14 External Network Connectivity (C13)

External Network Connectivity (ENC) is a service that provides peering with an external network. Examples include peering with the Internet and with the networks of trusted partners. Trusted partners consist of other levels of government, as well as companies that provide services on the GC’s behalf (i.e. outsourced services), and can also consist of businesses that either consume GC information or provide information to the GC. Examples of outsourced services that would be provided on a partner’s network include Common Email Service (i.e. ETI) and GC Shared Travel Service. External Network Connectivity provides both physical connectivity, as well as the exchange of routing information to enable communications between the GCNet and the external networks.

4.2 Foundational Services and Standards

The GCNet is dependent on certain foundational services and standards that are not considered part of the GCNet service itself. These are described in this section.

4.2.1 SSC Service Desk

The SSC Service Desk is a help desk that users and/or client representatives contact if they experience difficulty with SSC services. The SSC Service Desk performs triage on reported problems, soliciting the involvement of GCNet third and fourth level support as required to resolve GCNet service-related issues.

4.2.2 SSC Service Portal

The SSC Service Portal is a website that allows authorized and registered client department representatives to:

1. order SSC provided services;
2. obtain information regarding the fulfillment status of a client order;
3. obtain information regarding the level of utilization of a service by the client; and
4. obtain information on the performance achieved by the service in relationship to its stated service level objectives.

Some GCNet services will be provisioned directly from the SSC Service Portal (e.g. registering departmental users to the network service), whereas others will be requested from the SSC Service Portal but will require background provisioning processes to complete (e.g. doubling the bandwidth capacity at a site).

4.2.3 Identity, Credential and Access Management

Identity, Credential and Access Management (ICAM) is a foundational service for SSC. It supports the creation and management of user identities, the creation and management of credentials at multiple levels of assurance, as well as the authorities related to logical access to GCNet services (e.g. connectivity) and elements (e.g. switches and routers). It provides a single identity with many attributes, linked to two to three credentials, controlling access to many resources.^{Footnote 6}

4.2.4 Internet Protocol Registry and Internet Protocol Addressing Plan

The IP registry is a foundational service that consists of a centralized database that tracks the allocation of blocks of IP addresses to GCNet sub-networks (e.g. DHCP pool associated with a particular office building), as well as to devices when those devices are allocated addresses statically (i.e. manually configured) rather than dynamically (i.e. DHCP delivered). The IP Registry should integrate with other IP management tools such as DNS and DHCP to avoid needless repetitive manual entries.

The IP Addressing Plan is a foundational standard that defines how the GC IP address space will be allocated to regions and sites within the scope of GCnet. It also defines how portions of the GC IP address space can be allocated to non-GCNet networks (i.e. either transitioning to GCNet in time or to address classified requirements). The IP Registry and IP Addressing Plan must support both IPv4 and IPv6 addresses for the GC.

4.2.5 Network Name Registry and Network Naming Plan

The Network Name Registry is a foundational service that consists of a centralized database that tracks the allocation of names to network entities. These names are mapped to IP addresses within DNS to allow operations staff to manage network elements by name rather than by their IP address. The Network Name Registry should integrate with other IP management tools such as DNS and DHCP to avoid needless repetitive manual entries.

The Network Naming Plan defines the syntax standard for network element names, allowing characteristics such as site location and device type to be ascertained from a given network element’s name.

4.2.6 Information Protection Centre

The Information Protection Centre (IPC) is a foundational service for SSC. The IPC will receive all GCNet security events, analyzing them and correlating diverse events to identify comprehensive threats. The IPC will direct the action required to mitigate significant threats and notify GC lead security agencies and law enforcements agencies as required.

4.3 Requirements Traceability

The following Table provides traceability between the service requirements (i.e. functional capabilities) defined in Section 2 and the GCNet services defined in Section 4.

Table 1 : Requirements Traceability

GCNet Service Component	Service Requirement
	1 Controlled Access	2 High Availability	3 Peer to Peer Communications	4 Varying Quality Service	5 Roaming	6 Secure Remote Access by Users	7 External Network Access	8 Separate Logical Networks	9 Multiple Security Zones	10 End Point Deployment Support	11 Network Management Support
Wired Intra-Building (C1)	✔		✔	✔
Wifi (C2)	✔		✔	✔	✔
Inter-Building (C3)	✔		✔	✔
DCN (C4)	✔			✔
Inter-DCN (C5)		✔		✔
Network Partitioning								✔
Perimeter Defence (C6)	✔						✔		✔
SRA (C7)	✔					✔
Network Access Control (C8)	✔
Network Management and Monitoring (C9)											✔
NTP (C10)										✔	✔
DHCP (C11)										✔
DNS (C12)											✔
External Network Connectivity (C13)	✔						✔

4.4 Service Categories

This section categorizes the various GCNet services and dependency into external services (i.e. services that can be ordered by clients), internal services (i.e. for SSC use only) or foundational services and standards. The latter category includes services that are outside of the scope of GCNet and standards upon which the proper provisioning or operations of the GCNet depends.

You will note that the Inter-Building Network (IBN) (C3) is listed as both an external and internal service. That is because it can be ordered by client departments, and can also be used by SSC in support of network management for instance (i.e. by extending the logical network outside of the DC). The Dynamic Host Configuration Protocol and NTP are shown as internal services, even though they will be consumed by clients, because they will be bundled as part of other network services (e.g. WIBN, DCN) and not orderable separately by clients.

4.5 Service Dependencies

The inter-dependencies between the internal and external GCNet services, as well as their dependence on foundational services and standards are described in this section and summarized in Table 3.

4.5.1 Wired Intra-Building Network (C1)

The WIBN service (C1) is dependent on the following other services:

1. NAC (C8) for access control,
2. Network Management and Monitoring for management of the network (C9),
3. NTP (C10) as the time source for all network elements (e.g. routers and switches),
4. SSC Service Desk for client reported problems,
5. SSC Service Portal for clients to register users to the service, and
6. IP Registry for IP addresses for network elements (e.g. routers and switches).

4.5.2 Wifi (C2)

The Wifi service (C2) is dependent on the following other services:

1. The Wired Intra-Building Service (C1) for inter-connecting the Wifi elements (e.g. wireless access points), and connecting the Wifi service to the Inter-Building Network (C3) service;
2. NAC (C8) for access control;
3. Network Management and Monitoring for management of the network (C9);
4. NTP (C10) as a time source for all network elements (e.g. wireless access points);
5. SSC Service Desk for client reported problems;
6. SSC Service Portal for clients to register users to the service; and
7. IP Registry for IP addresses for network elements (e.g. wireless access points).

4.5.3 Inter-Building Network (C3)

The IBN service (C3) is dependent on the following other services:

1. Network Management and Monitoring for management of the network (C9);
2. NTP (C10) as a time source for all network elements (e.g. routers and switches);
3. SSC Service Portal for clients to order the service;
4. SSC Service Desk for client reported problems; and
5. IP Registry for IP addresses for network elements (e.g. routers and switches).

4.5.4 Intra-Data Centre Network (C4)

The Intra-DCN service (C4) is dependent on the following other services:

1. Network Management and Monitoring for management of the network (C9),
2. NTP (C10) as a time source for all network elements (e.g. routers and switches), and
3. IP Registry for IP addresses for network elements (e.g. routers and switches).

4.5.5 Inter-Data Centre Network (C5)

The Inter-DCN service (C5) is dependent on the following other services:

1. Network Management and Monitoring for management of the network (C9);
2. NTP (C10) as a time source for all network elements (e.g. routers and switches); and
3. IP Registry for IP addresses for network elements (e.g. routers and switches).

4.5.6 Network Partitioning (NP)

Network Partitioning is a capability required in the following other services:

1. the WIBN service (C1),
2. the Wifi service (C2),
3. the IBN service (C3),
4. the Intra-DCN service (C4), and
5. the Inter-DCN service (C5).

4.5.7 Perimeter Defence (C6)

The PD service (C6) is used in conjunction with the Intra-DCN service (C4) to securely inter-connect security domains and zones.

4.5.8 Secure Remote Access (C7)

The Secure Remote Access (SRA) service (C7) is dependent on the following other services:

1. Intra-Data Centre service (C4) to connect centralized SRA gates to the GCNet;
2. WIBN (C1) service to connect remote branch office SRA gates to the GCNet;
3. External Network Connectivity service (C13) to connect users and remote branch offices to the GCNet; and
4. Network Access Control (C8) and ICAM to control user access.

4.5.9 Network Access Control (C8)

The Network Access Control (NAC) service (C8) is dependent on the following other services:

1. Intra-DCN (C4) service to connect the centralized NAC component to the GCNet;
2. NTP (C10) as a time source, and
3. Identity, Credential and Access Management (ICAM) service to issue (and revoke) user identity credentials and to authenticate users based on those credentials.

4.5.10 Network Management and Monitoring (C9)

The Network Management and Monitoring service (C9) is dependent on the following other services and foundational standards:

1. Network Partitioning capability of the WIBN service (C1), the Wifi service (C2), the IBN service (C3) and the Intra-DCN service (C4), in conjunction with PD service (C6) to create the SSC IT Management Security Domain and related network security zones;
2. NTP (C10) to synchronize the Network Management and Monitoring components to a common time source;
3. GCNet DNS Zone service (C12) to map network element names to their corresponding IP addresses, allowing these elements to be managed by name rather than by address;
4. ICAM to authenticate network management operations staff and to limit their authorities to their assigned roles;
5. IP Registry to record addresses assigned to network elements;
6. IP Addressing Plan to determine appropriate address ranges for addressing network elements;
7. Network Name Registry to record names assigned to network elements; and
8. Network Naming Plan to determine appropriate names for naming network elements.

4.5.11 Network Time (C10)

The NTP service (C10) is dependent on the following other services:

1. Intra-DCN (C4) service to connect the centralized NTP components to the GCNet;
2. DHCP (C11) for advertising the location (i.e. IP address) of NTP server(s);
3. Intra-DCN (C4) service to provide time to DC hosted servers;
4. Wired Intra-Building Network (WIBN) service (C1) if the NTP service is distributed (i.e. time is delivered locally at each building);
5. Inter-DCN (C5) to support NTP survivability; and
6. WIBN (C1) and Wifi (C2) to provide time to user end devices.

4.5.12 Dynamic Host Control (C11)

Dynamic Host Configuration Protocol service (C11) is dependent on the following other services:

1. Intra-DCN (C4) service to connect the centralized DHCP components to the GCNet;
2. WIBN service (C1) if the DHCP service is distributed (i.e. the IP addresses for the building are delivered locally by a WIBN switch);
3. Inter-DCN (C5) to support DHCP survivability;
4. IP Registry for recording the address blocks assigned for DHCP delivery; and
5. IP Addressing Plan for determining appropriate address blocks for DHCP delivery at various sites.

4.5.13 GCNet DNS Zone (C12)

The GCNet DNS Zone (DNS) service (C12) is dependent on the following other services:

1. Intra-DCN (C4) service to connect the GCNet DNS Zone servers to the GCNet;
2. Inter-DCN (C5) to support DNS survivability; and
3. DHCP to advertise the location (i.e. IP address) of the GCNet DNS Zone server(s) to end systems.

If the GCNet DNS Zone (C12) is not configured as its own root, it will be dependent on the following others services:

4. GC DNS service (i.egc.ca); and
5. External Network Connectivity (ENC) (C13) service for connectivity to the DNS root servers on the Internet.

4.5.14 External Network Connectivity (C13)

The ENC service (C13) is dependent on the following other services:

1. Network Partitioning capability of the Intra-DCN (C4) service, plus the PD service to create a PAZ in order to securely connect the GCNet to the external networks;
2. SSC Service Desk for client reported problems;
3. IP Registry for determining the address ranges that will need to be advertised to the external networks.

4.5.15 SSC Service Desk

The SSC Service Desk is dependent on the following other services:

1. Intra-DCN (C4) service to connect the SSC Service Desk to the GCNet, if the Service Desk is hosted within a GC Data Centre; or
2. External Network Connectivity (C13) service to connect the SSC Service Desk to the GCNet, if the Service Desk is outsourced.

4.5.16 SSC Service Portal

The SSC Service Portal is dependent on the following other services:

1. Intra-DCN (C4) service to connect the SSC Service Portal to the GCNet; if the Service Portal is hosted within a GC Data Centre; or
2. External Network Connectivity (C13) service to connect the SSC Service Portal to the GCNet, if the Service Portal is outsourced.

4.5.17 Identity, Credential and Access Management

The ICAM service is dependent on the following other services:

1. Intra-DCN (C4) service to connect ICAM to the GCNet; or
2. External Network Connectivity (C13) service to connect ICAM to the GCNet, if ICAM is outsourced.

4.5.18 IP Registry and IP Addressing Plan

The IP Registry is dependent on the existence of an IP Addressing Plan that provides guidance on how the IPv6 and IPv4 address space is to be organized and allocated to GCNet network elements, regions, sites, and data centres. It is also dependent on the DCN service (C4) for connectivity to the GCNet.

The IP Addressing Plan has no dependencies on other services.

4.5.19 Network Name Registry and Network Naming Plan

The GCNet Network Name Registry is dependent on the existence of a GCNet Network Naming Plan that provides guidance on how the name space is to be organized and allocated to GCNet network elements. It is also dependent on the DCN service (C4) for connectivity to the GCNet.

The Network Naming Plan has no dependencies on other services.

4.5.20 Information Protection Centre

The IPC service is dependent on the following other services:

1. Intra-DCN (C4) service to connect the IPC to the GCNet;
2. All GCNet external and internal services for detecting and reporting security events; and
3. The IP and Network Name Registries to determine the location of end points and network elements that are reporting security events.

Table 3: Service Dependencies - Part 1

GCNet External and Internal Services plus Foundational Services and Standards	WIBN (C1)	Wifi (C2)	Inter-Bldg (C3)	DCN (C4)	Inter-DCN (C5)	Network Partitioning	Perimeter Def (C6)	SRA (C7)	NAC (C8)	Network Mgmt (C9)	NTP (C10)
WIBN (C1)									✔	✔	✔
Wifi (C2)	✔								✔	✔	✔
Inter-Building (C3)										✔	✔
DCN (C4)										✔	✔
Inter-DCN (C5)										✔	✔
Network Partitioning	✔	✔	✔	✔	✔
Perimeter Defence (C6)				✔
SRA (C7)	✔			✔					✔
NAC (C8)				✔							✔
Network Management (C9)	✔	✔	✔	✔		✔	✔				✔
NTP (C10)	✔1	✔		✔	✔
DHCP (C11)	✔1			✔	✔
DNS (C12)				✔	✔
External Networks (C13)				✔			✔
SSC Service Desk				✔
SSC Service Portal				✔
ICAM				✔	✔
IP Registry				✔
IP Addressing Plan
Network Name Registry				✔
Network Naming Plan
IPC	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔

Note: ¹ If the service is distributed rather than centralized.

Table 3: Service Dependencies - Part 2

GCNet External and Internal Services plus Foundational Services and Standards	DHCP (C11)	DNS (C12)	External Network (C13)	SSC Service Desk	SSC Service Portal	ICAM	IP Registry	IP Addressing Plan	Network Name Registry	Network Naming Plan	IPC
WIBN (C1)				✔	✔		✔
Wifi (C2)				✔	✔		✔
Inter-Building (C3)				✔	✔		✔
DCN (C4)				✔			✔
Inter-DCN (C5)							✔
Network Partitioning
Perimeter Defence (C6)
SRA (C7)			✔			✔
NAC (C8)						✔
Network Management (C9)		✔				✔	✔	✔	✔	✔
NTP (C10)	✔
DHCP (C11)							✔	✔
DNS (C12)	✔		✔
External Networks (C13)				✔			✔
SSC Service Desk			✔2
SSC Service Portal			✔2
ICAM			✔2
IP Registry								✔
IP Addressing Plan
Network Name Registry										✔
Network Naming Plan
IPC							✔		✔

Note: ² If the service is outsourced.

5. Challenges

This section highlights the challenges that SSC will likely face in the development, deployment or operations of the GCNet. It is assumed that the GCNet program and any projects defined for the delivery of GCNet services will include a full risk management assessment that would validate or dismiss the following.

Moving from one (or more) network(s) per department or agency (current state) to one (or a few) logical network(s) for the GC (target state) will be very challenging from a logistics, technology and security point of view.

From a logistical point of view, transitioning departmental end users and applications to a single logical network will require the re-addressing of hundreds of thousands of GC endpoints and thousands of applications. Another challenge will be acquiring “as-built” documentation for all networks that need to be migrated in order to understand the requirements of what is being transitioned. This goes beyond location of sites and current bandwidth consumption, to specifics such as the need for satellite links, QoS support, multicast support, etc.

There are strong dependencies on components that have either limited or no existing developments yet within the GC (e.g. NAC and ICAM). Also there are likely very few if any deployments by industry on the scale required for the GC.

Currently network partitioning (i.e. one network per department) has been used as a security control to limit who could even attempt to log into an application. Other security controls (e.g. NAC and ICAM and possibly permissions management) will need to be deployed within the infrastructure to ensure that residual risk is maintained at an acceptable level.

The above-stated challenges are amplified by the fact that SSC is a newly formed and therefore still evolving organization with limited resources and inexperienced in this magnitude of change.

Partner organizations will request assurance that security and privacy components are incorporated into the design phase. Monitoring will be required to ensure that security and privacy are addressed when changes to technologies or new threat agents are active.

6. Recommendations

This section recommends high-level actions that should be considered to address the challenges identified in Section 5. It is assumed that the GCNet program and any projects defined for the delivery of GCNet services will include a full risk management assessment that would define appropriate action to mitigate any significant risks.

It is recommended that a phased development and deployment of GCNet be considered as a means to reduce financial, technological, security, privacy and organizational risk to acceptable levels.

Phase 1 could see the consolidation of GC departments and agencies to fewer physical networks, consistent with network equipment evergreening cycles and network service contract expirations. This will allow SSC to achieve committed cost saving targets early on. Phase 1 would also see the development and testing of the target architecture and design in SSC. Identity, Credential and Access management integration with NAC would be tested, as well as any other new security controls introduced to mitigate the loss of departmentally separate networks. The scalability of security controls, including NAC and ICAM would be a focus of this phase.

Phase 2 could see the deployment of the end-state solution and the transitioning of a few smaller departmental networks and applications to the target state to further reduce the risks to the transition.

Finally, Phase 3 could see a large-scale move of the remaining departmental networks to the target state over a manageable period of time. Departments and agencies could be migrated according to their equipment evergreening or outsource contract expiration cycles (i.e. opportunity based).

The timeframes involved with each Phase could vary from one GCNet service to another, depending on both opportunity for change and estimated risk. For instance, given that data centre consolidation will result in a green field implementation, Phase 1 (i.e. perhaps with the exception of the testing of new capabilities prior to their introduction into production on a full scale) and Phase 2 could be limited or skipped completely.

7. Glossary

The following table defines terms that may not be familiar to the intended audience of the GCNet RAD.

Term	Description
APRZ	Application Restricted Zone: Network security zone appropriate for hosting business critical applications.
CSEC	Communications Security Establishment Canada: An agency of the Department of National Defence, that is responsible for the development of security standards and guidance related to computer networks.
DRZ	Data Restricted Zone: Network security zone appropriate for hosting business critical information. Also known as Database Restricted Zone or DBRZ.
External Service	A service that a client department can order from SSC (i.e. in the SSC Service Catalogue).
GC User	A user affiliated with a department whose is either a mandatory (i.e. SSC partner department) or optional GCNet client (i.e. other government department).
ICAM	Identity, Credential, Access Management: Supports the creation and management of user identities, the creation and management of credentials at multiple levels of assurance, as well as the authorities related to logical access to services and applications.
Internal Service	An SSC service that is not available for order by client departments. Internal Services are used exclusively by SSC in support of the provision, operations or management of External Services, or are bundled as part of another external service.
OZ	Operations Zone: Network security zone appropriate for hosting end user devices (e.g. desktops, laptops, tablets), and internal (GC) facing web tier servers.
PAZ	Public Access Zone: Network security zone appropriate for hosting external (Internet) facing web tier servers, proxy servers, secure remote access gateways, external DNS servers, and external mail relays.
Public Hot Spot	A public location, such as a coffee shop, airport, hotel, or building lobby that provides Wifi based Internet access to their clientele.
QoS	Quality of Service: the performance requirements of a given application in terms of its sensitivity to end-to-end latency, latency variation (i.e. jitter) and packet loss.
SSC	Shared Services Canada: A department of the GC responsible for IT infrastructure for 43 major GC departments, as well as an optional service provider for the remaining GC departments.