vpn david newson

Overview of Hub & Spoke and Related N3 Services: 

Overview of Hub & Spoke and Related N3 Services Dave Newson, N3SP Technical Team Doc Ref ID: N3-XXX-XXX-XXX Version No: Status: Issue Date: 8th February 2006

Overview: 

Overview Brief overview of N3 Hub & Spoke 1:1 operation Hub & Spoke 1:many Remote access services QoS

Slide3: 

CPE Aggregator (Primary) Primary Secondary MPLS Core ISDN Access AS ISDN N3 PoP #1 N3 PoP #2 Aggregator (Backup) NASP/LSP DC c 50 sites 57 N3 PoPs 14,000 end-customer sites N3 Network

Background: 

Background BMA directive that all Patient Identifiable Data (PID) must be encrypted over a WAN Applies to a secure MPLS-based WAN - N3 ‘National Applications’ have application-layer encryption - not considered part of the original N3 contract Many surgeries run legacy systems with PID c1000 ‘hub’ surgeries have ‘spoke’ surgeries which require access to data on the ‘hub’ site

2 Approaches For Encryption: 

2 Approaches For Encryption SSL (TLS) - application layer encryption. Easier to work with NAT Strong application dependency IPSec - network layer encryption Encryption at network layer Oblivious to application type May not work with NAT (e.g. Microsoft state it is incompatible)

N3 Main & Branch: 

N3 Main & Branch Use 3DES IPSec (168 bit encryption) IPSec tunnel from N3SP hardware on main-site to branch-site IPSec client not required on end-user PC

Two Distinct Solutions: 

Two Distinct Solutions 1) For sites with a single branch site off the main site (around 80+% of the total) - IPSec tunnel between existing CPE routers = Catalogue Service N3-12-2 2) For sites with >1 branch site off the main site (<20% of the total) - new hardware (Nortel Contivity 1050) on main site - encrypted tunnels from branch site CPE router to Contivity on main site

N3-12-2: 

N3-12-2 Design agreed to be between N3-2-12 at main site (private circuit), with N3-2-10 (DSL) at branch site However, many main sites rolled out with N3-2-11. Have to make solution work irrespective of underlying Catalogue Services.

N3-12-2 has …..: 

N3-12-2 has ….. No new CPE Uses underlying CPE Of main site and branch site It requires additional configuration on existing routers

N3-12-2 (slide 2): 

N3-12-2 (slide 2) Other Catalogue Services must already be provisioned process Consists of applying IPSec configuration on both routers to form tunnel Route appropriate traffic via the IPSec tunnel All other traffic uses standard link

ADSL Limitation: 

ADSL Limitation ADSL has capped upstream throughput, irrespective of downstream bit-rate ADSL on main site limits upstream throughput (288 kb/s). This bandwidth must be shared with National Applications, Internet, e-mail etc. This may affect customer experience, but has been raised to Authority (i.e. SLAs have been softened) Hence - recommendation that Catalogue Service with private circuit used at site with servers

Compatible Site types: 

Compatible Site types Service designed for Catalogue Services: N3-2-3, N3-2-4, N3-2-12, N3-2-13, N3-3-2 and N3-3-3 -private circuits as primary at hub site. N3 advises customers to consider and check their primary circuit utilisation: N3-2-1, N3-2-2, N3-2-10, N3-2-11, N3-2-18 and N3-2-19. i.e. ADSL used for the primary circuit. Also compatible with:-N3-2-5, N3-2-14 and N3-3-4. i.e. Catalogue Services with a 10 Mb/s Ethernet as primary connection.

Incompatible Site Types: 

Incompatible Site Types Two limits. 1) Must not have ADSL at hub-site 2) To protect router can’t have 100 Mb/s accesses On hub-site, N3-2-12, - 13 and -14

Public Key Infrastructure (PKI)IKE Authentication Architecture: 

Public Key Infrastructure (PKI) IKE Authentication Architecture Use Verisign-based certificates If Verisign trust me and Verisign trust you, then I can trust you Provides daily certificate revocation list If router stolen don’t accept the certificate Encryption keys changed on a daily basis

So Who Does What? …...: 

So Who Does What? …...

Roles In Commissioning: 

Roles In Commissioning

Type 1 - Main/branch inter-site link: 

Type 1 - Main/branch inter-site link Main & branch site connected via existing leased line

Type 2 Healthnet branch solutions: 

Type 2 Healthnet branch solutions Inter-site link from serial card on Healthnet router - put on hold

Type 3 - Undeclared Connection: 

Type 3 - Undeclared Connection As type 2, but customer has added own cards to Healthnet router

Type 4 NHSnet connection to branch site: 

Type 4 NHSnet connection to branch site Currently no connection exists between main & branch Migrate branch to N3, then add VPN if requested

Application Issues: 

Application Issues CfH accept that the VPN is a ‘secure transport’ service End-user likely to require LAN reconfiguration This is not remit of N3SP Need to engage LAN support team - before moving to N3 ‘main & branch’ Likely need for IP addressing

Application Issues (2): 

Application Issues (2) Microsoft say ‘IPSec incompatible with NAT’ N3SP strongly recommend re-addressing But will support NAT at main site can’t guarantee that every application will work

Windows Networking - WINS: 

Windows Networking - WINS Windows networking uses broadcasts on ports 137 and 138 to resolve host-names On bridged network broadcasts sent to all hosts Microsoft introduced WINS to solve on routed network WINS is process which runs on Microsoft server (doesn’t need dedicated server) Maps names to network addresses

Windows Networking (2): 

Windows Networking (2) Also possible to input static mappings into each PC - edit ‘LMHOSTS’ file Works, but limited scalability Document produced summarising this Needs to be thought through before order placed Definitely before order delivered

SLAs: 

SLAs In QoS model (wait until later in talk), Main & Branch treated as Default class traffic Prioritised lower than National Applications traffic

Main & Branch 2:5: 

Main & Branch 2:5 Similar concept for ‘main & branch 1:1’ But for cases with more sites Deploy Nortel Contivity 1050 on main site PC-based architecture, size of hardback book, throughput of 10 Mb/s IPSec Licence of 1-5 and 6-30 tunnels

Main & Branch 2:5: 

Main & Branch 2:5 Conceptually similar to 1:1 Hub site load put onto separate device Plugged into second LAN port IPSec tunnel from main site Nortel Contivity to Cisco router on branch site Application issues (eg WINS) identical **ADSL uplink speed is even more acute** If an issue with a single branch site Compounded with multiple branch sites Must have private circuit on site with servers

Main & Branch 2:5: 

Main & Branch 2:5

Main & Branch 2:5: 

Main & Branch 2:5 Pilot sites now been deployed

Summary of Main & Branch: 

Summary of Main & Branch Main & Branch 1:1 uses an IPSec tunnel between existing Catalogue Services Main & Branch 2:5 introduces Nortel hardware on main site Discussed config of the VPN and fault-finding. Fault-finding is likely to evolve with experience of migrating clinical applications

Main & Branch …..: 

Main & Branch ….. Encryption puts high CPU load on router Currently not supported on 100 Mb/s circuits to protect routers Main & Branch designed for GP community Few GPs will have 100 Mb/s access! N3SP recognise customer demand for transfer of PID in more scenarios Info available on help guides on CRM

Remote Access Solutions: 

Remote Access Solutions

Technical Details: 

Technical Details IPSec tunnel from end-user PC to central infrastructure Nortel Contivity solution. Software client, hardware in core RADIUS + SecurID token for authentication Load balancing - connect to virtual IP address Traffic is decrypted into N3

Technical Details (2): 

Technical Details (2) ISP must support IPSec (some block this on ‘consumer’ products) Recommend Ethernet-based solution (otherwise client issues) IP addresses allocated pool per NHS ‘entity’ Users may have different IP addresses each time they connect Ranges allow firewall changes to be made

Remote Access: 

Remote Access

Moving Forward: 

Moving Forward Deliver according to requirements agreed with CfH Doesn’t solve the problem of getting PID to a remote user Doesn’t solve the problem of getting PID to a roving user Looking at ways to use existing infrastructure to extend IPSec tunnel onto a customer site

Moving Forward (2): 

Moving Forward (2) Effectively making remote access one of the tunnels on a ‘main & branch’ Discussed in Jonathan Hyde’s talk

Quality of Service: 

Quality of Service

Why Do We Need QoS?: 

Why Do We Need QoS? Internet has limited control of bandwidth All applications fight for available b/w Greedy applications will steal all bandwidth short round trip time VoIP/video - UDP No guarantees for critical applications Sporadic performance A set of tools to give better bandwidth utilisation Not a panacea - doesn’t invent bandwidth!

What is Quality of Service (QoS)?: 

What is Quality of Service (QoS)? Ability of a network to service applications efficiently without affecting its functions or performance All about guaranteeing performance in case of congestion Points of congestion Access (to & from network) – bandwidth in LAN and core typically larger than access Core – usually adequately dimensioned but congestion can occur in case of unexpected traffic patterns and core failures E.g. 10/100 Mbps Ethernet LAN connecting to 2 Mbps WAN link

QoS (2): 

QoS (2) QoS guarantees performance by prioritising applications on network performance requirements in case of congestion Performance or priority levels are called Classes of Service

What is DiffServ?: 

What is DiffServ? Architecture for scalable service differentiation in IP networks Uses first 6 bits in Type of Service (TOS) field in IP header 6 “Classes of Service” with recommended DSCP values defined Expedited Forwarding (EF) class for VoIP 4 Assured Forwarding (AF1..AF4) classes for guaranteed data Default class (DE) for best effort data Low drop probability (AFx1) Medium drop probability (AFx2) High drop probability (AFx3) Does not define end-to-end services; can be different for each implementation DiffServ Code Points (DSCP) ‘Per Hop Behaviours’ (PHBs) IETF standard

DiffServ: 

DiffServ Three priority levels within each AF class

N3 DSCP 6-CoS Overview: 

N3 DSCP 6-CoS Overview N3 Class of Service model based on Differential Services (DiffServ) standards Provides 6 Classes of Service for customer applications and separate class for management traffic

N3 QoS Levels: 

N3 QoS Levels The 6 classes:- VoIP class Multimedia class for real-time video applications Transactional National Applications Transactional Community Applications Bulk data transfer (eg PACS) Default class

N3 DSCP 6-CoS Model: 

N3 DSCP 6-CoS Model Voice Assured Data 4 Assured Data 1 Assured Data 2 Standard Data DiffServ PHB: EF DiffServ PHB: AF1 DiffServ PHB: AF2 DiffServ PHB: AF4 DiffServ PHB: DE ‘Toll quality’ Voice over IP applications Mission-critical data applications E.g. National Applications Standard data applications E.g. Mail, Web, FTP PACS, Community applications, multimedia Multimedia Assured Data 3 DiffServ PHB: AF3

Slide47: 

In contract Out of contract Future Use

Any Questions?: 

Any Questions?

Slide49: 

Document Details: Version History: Distribution List: