ADVPN design and implementation

Peruse the complete library at www.juniper.net/books.Published by Juniper Networks Books Neither the fully-meshed nor hub-and-spoke approaches to IPsec VPNs are optimal for modern netwo

Juniper Networking Technologies

Using the AutoDiscovery VPN protocol

is a new and different approach to solving

real-world IPsec encryption problems

Get ahead of the curve and into the lab

with this workbook full of overviews,

con-figurations, and troubleshooting samples

By Mark Barrett, Dale Shaw, and Scott McKinnon

IMPLEMENTATION

Juniper Networks Books are singularly focused on network productivity and efficiency Peruse the complete library at www.juniper.net/books.

Published by Juniper Networks Books

Neither the fully-meshed nor hub-and-spoke approaches to IPsec VPNs are optimal for modern network deployments where customers demand both the ease of provisioning encrypted overlay security services and the optimum flow of traffic to minimize ap- plication traffic latency What is needed is an approach that takes the simplified provi- sioning of hub-and-spoke with the low application latency of fully-meshed.

Spokes should have the capability to temporary build tunnels between each other on

an on-demand basis to create the most efficient forwarding path, so if a particular flow

is required, the spokes build dynamic tunnels between themselves for that cation and then clear the tunnel when idle In this way the fully-meshed approach is available to the network without the overhead of configuring all the necessary com- munication paths The hub takes care of the task of identifying whether dynamic con-

communi-nections are required The SRX Series employs a feature called AutoVPN to deliver this

capability, which has been shipping since Junos 12.1X44 Now AutoVPN deployments can use the Auto Discovery VPN (ADVPN) protocol to dynamically establish spoke-to- spoke VPN tunnels.

This Day One book will tell you why and show you how, while providing sample mentations to investigate in your lab.

imple-ISBN 978-1941441169

9 781941 441169

5 1 8 0 0

IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:

n Gain an appreciation of the main issues surrounding the integration of encryption technology into networking products.

n Understand the need for a standards-based approach to solving network integration issues.

n Understand Juniper’s AutoDiscovery VPN (ADVPN) solution.

n Learn how to incorporate the ADVPN feature into a design.

n Explore the detailed steps required to implement and tune ADVPN in your network.

n Take architectural blueprint designs as a base template to be tailored for your specific scenario.

By Mark Barrett, Dale Shaw, and Scott McKinnon

Day One: ADVPN Design and

Implementation

Chapter 1: Why ADVPN ? 9

Chapter 2: A Standards-based Approach 15

Chapter 3: ADVPN Key Concepts 21

Chapter 4: Key Configuration Steps 27

Chapter 5: Tuning Considerations for ADVPN 35

Chapter 6: Management and Day-to-Day Operations 53

Chapter 7: Using Junos Automation to Help Manage ADVPN Environments 61

Chapter 8: Troubleshooting ADVPN 67

Chapter 9: Architectural Blueprints 79

Appendices 113

Juniper Networking Technologies

© 2015 by Juniper Networks, Inc All rights reserved

Juniper Networks, Junos, Steel-Belted Radius,

NetScreen, and ScreenOS are registered trademarks of

Juniper Networks, Inc in the United States and other

countries The Juniper Networks Logo, the Junos logo,

and JunosE are trademarks of Juniper Networks, Inc All

other trademarks, service marks, registered trademarks,

or registered service marks are the property of their

respective owners Juniper Networks assumes no

responsibility for any inaccuracies in this document

Juniper Networks reserves the right to change, modify,

transfer, or otherwise revise this publication without

notice.

Published by Juniper Networks Books

Authors: Mark Barrett, Dale Shaw, and Scott McKinnon

Technical Reviewers: Johan Andersson, Anubhav Garg,

Bill Shelton

Editor in Chief: Patrick Ames

Copyeditor and Proofer: Nancy Koerbel

Illustrator: Karen Joice

J-Net Community Manager: Julie Wider

be secured.

To the rest of the author team, thank you for your persistence as we all have busy day jobs that often turned into our night jobs as well, to get the book completed To the engineering team (Praveen Sathyanarayan, Anubhav Gar, Suresh Melam and, Rajendra Kandukuri) putting up with field SEs pestering and challenging to go the extra mile for the first release of ADVPN through the alpha and beta phases To our review team (Bill Shelton, Gavin Thirlwall, Johan Andersson) for making sure what we wrote would be useful to people in the field To our editing support team, Nancy Koerbel sorry for the Australian English and Karen Joice thanks for turning our diagrams into something nice And finally Patrick Ames, giving us the confidence to start the project, keeping the relatively big author team on track, and cracking the whip when we all needed a push.

About the Authors (continued)

Dale Shaw

Dale Shaw is a Systems Engineer in the Australian Federal

Government team at Juniper Networks He has worked

for Juniper Networks in Canberra since the beginning of

2014, helping government enterprises to design, build and

manage secure IP networks Prior to Juniper Networks,

Dale spent seven years working for Alphawest and Optus

Business as a solutions designer and architect In these

roles Dale helped design, deploy and operate large scale IP

networks carrying voice, video and data over IPsec VPNs

Dale holds a number of industry certifications such as

JNCIP-ENT, JNCIP-SEC, and CCIE R&S (#24464).

I’d like to thank my co-authors, Mark Barrett and Scott

McKinnon, for making this project happen Patrick Ames

has been an excellent “cat herder” and Nancy Koerbel a

cold and clinical assassin of all of the British English we

handed over (just kidding, Nancy, you applied a generous

quantity of polish!) Praveen Sathyanarayan is not only

the chief designer of ADVPN itself but also provided a lot

of invaluable technical information and review along the

way thanks Praveen! Thanks also to Bill Shelton and

Gavin Thirlwall, from the Juniper US federal and UK

government teams, respectively, for providing inputs

specific to their geographic contexts, and to Johan

Andersson and Anubhav Garg for their inputs and

reviews Last but certainly not least, I would like to thank

my wife, Katie, and my two kids, for tolerating all of my

nerdy (often late night) pursuits

Scott McKinnon

Scott McKinnon is a Senior Product Manager in the Juniper Networks Security and Switching Product Team (SSPT) within the Juniper Design and Innovation (JDI) group Scott has been working with IPsec and related encryption technologies for over 15 years, and has experience in post-sales and pre-sales, as well as product management He has contributed to the development of the ADVPN capability and related technologies, like GDoI, from initial customer requirements through product specification and into customer trials and release

He holds an MBA in Technology Management from the Open University (UK), as well as a BEng(Hons) in Engineering from Glasgow Caledonian University(UK) Scott manages Juniper's public sector accreditation program, where many of the ADVPN requirements originated He is based in Sunnyvale, California.

Scott would like to acknowledge the contributions of John Veizades and Steve Hanna to the initial stages of what became ADVPN and to applaud the design and execution

by the Juniper JDI Engineering Team of Suresh Melam, Praveen Sathyanarayan, Anubhav Garg, Vineeth Kisara, Rajendra Kandukuri, and Jinesh Doshi Thanks to the main authors, Mark and Dale, and to our reviewers Bill Shelton, Gavin Thirlwall, and Johan Andersson, and editors Patrick, Nancy, and Karen.

Welcome to Day One

This book is part of a growing library of Day One books, produced and

published by Juniper Networks Books

Day One books were conceived to help you get just the information that

you need on day one The series covers Junos OS and Juniper Networks networking essentials with straightforward explanations, step-by-step instructions, and practical examples that are easy to follow

The Day One library also includes a slightly larger and longer suite of

This Week books, whose concepts and test bed examples are more

similar to a weeklong seminar

You can obtain either series, in multiple formats:

„ Download a free PDF edition at http://www.juniper.net/dayone

„ Get the ebook edition for iPhones and iPads from the iTunes Store Search for Juniper Networks Books

„ Get the ebook edition for any device that runs the Kindle app (Android, Kindle, iPad, PC, or Mac) by opening your device’s Kindle app and going to the Kindle Store

„ Purchase the paper edition at either Vervante Corporation (www.vervante.com) for between $12-$28, depending on page length

„ Note that Nook, iPad, and various Android apps can also view PDF files

What You Need to Know Before Reading This Book

Before reading this book, you should be familiar with the basic trative functions of the Junos operating system, including the ability to work with operational commands and to read, understand, and change

adminis-Junos configurations There are several books in the Day One library on

learning Junos, at www.juniper.net/dayone.This book assumes that you, the reader, know:

„ Basic IP networking design and operation

„ Basic IPsec protocol implementation

„ Basic Junos OS CLI procedures

„ Basic SRX concepts and principles

vii

After Reading This Book, You’ll Be Able To

„ Gain an appreciation of the main issues surrounding the tion of encryption technology into networking products

integra-„ Understand the need for a standards-based approach to solving network integration issues

„ Understand Juniper’s AutoDiscovery VPN (ADVPN) solution

„ Learn how to incorporate the ADVPN feature into a customer design

„ Explore the detailed steps required to implement and tune ADVPN

in the customer network

„ Apply architectural blueprint designs as a base template to be tailored for your specific customer scenario

Preface

IP Security, or more simply IPsec, is the Internet Engineering Task Force (IETF’s) standard for securing the network layer in IP systems, covering both IPv4 and IPv6 IPsec was originally defined by the IETF in 1998 and since then has been defined as an optional element for IPv4 and a mandatory element for IPv6 IPsec has gone through a number of iterations over the years and many additional RFCs have been defined to augment the main elements of the protocol with new encryption algo-rithms, authentication functions, and modes of operation

While IPsec has been around for awhile, implementing such a protection suite in IP networks remains a challenge Network devices such as routers and firewalls require the protocol to be integrated into their operating systems to assert security policy The security capabilities of IPsec must be deployed in network topologies that are evolving to support the demands of ever-newer applications and services, and the protocol must coexist with dynamic routing protocols in order to maintain efficient forwarding of traffic in the event of disruption These conflicting challenges have resulted in unfortunate compromises being made between ease-of-design, deployment, ongoing management, and securing the application traffic efficiently within a service oriented network model Until now

Juniper Networks SRX Series of security gateway devices are a range

of network products designed to integrate security, routing, and switching in a single Junos OS platform IPsec is therefore a corner-stone of any such platform

Scope of Book

This Day One book attempts to cover the following ADVPN concepts,

and was written in such a way that you can follow along in your own lab:

This chapter details the main approaches taken by several vendors of IPsec VPN technologies to produce, from the respective IETF RFCs, meaningful solutions for customers to deploy in order to solve real world encryption problems It provides a basic summary of the relevant RFCs, the approaches that have emerged for deployment, and the issues with these approaches, and sets out the requirements for a new and different approach that is fulfilled by ADVPN.

The IETF IKEv2 Peer-to-Peer Model

RFC 7296 is the specification for the Internet Key Exchange (IKE)

protocol, currently designated as version 2, (IKEv2) RFC 7296 replaces RFCs 4306 and 5996, which in turn replaced the IKEv1 RFCs, 2407, 2408, and 2409 specifications RFC 7296 defines a control plane protocol to be used by IPsec peers to establish the services, cryptographic algorithms, and the keys necessary for each

to maintain the correct state

MORE? RFC 7296 can be read here: https://tools.ietf.org/html/rfc7296

RFC 7296 also defines a basic model whereby a system consisting of protected subnets, tunnel endpoints, and IPsec tunnels can be established for the purpose of protecting traffic in transit across untrusted networks, giving rise to three main use cases

In addition, tunnels can be established in one of two modes: tunnel or

transport Tunnel mode is when the security gateways or protected

endpoints provide security services to the datagrams by fully lating them in a new IP layer, forming new addressing between the

encapsu-peers Transport mode is when only the payload of the IP packet is

protected and no additional IP layer is required

Use Case One

In this first use case, or Security Gateway-to-Security Gateway, peers protect traffic on behalf of connected subnets via an IP overlay model

using tunnel mode IPsec, as detailed in Figure 1.1

Figure 1.1 Security Gateway-to-Security Gateway IPsec VPNs

NOTE Use Case One is the typical “secure router” model and it is the focus of

this book The other two use cases are included in this chapter to provide a complete discussion

Use Case Two

In this use case Endpoint-to-Endpoint peers protect traffic with their

own addresses without an IP overlay model using transport mode IPsec

as detailed in Figure 1.2 This is the typical “secure host” model and is out of scope for this book because it does not involve security gate-ways

Chapter 1: Why ADVPN ? 11

Figure 1.2 Endpoint-to-Endpoint IPsec VPNs

Use Case Three

In Use Case Three, Endpoint-to-Security-Gateway peers protect traffic from the host to the network via an IP overlay model using tunnel mode IPsec as detailed in Figure 1.3 This is the typical “remote access model” and again is out of scope for this book because it does not solely involve security gateways

Figure 1.3 Endpoint-to-Security Gateway IPsec VPNs

The Point-to-Point Model

The goal of IKEv2 is therefore to provide a dynamic means of creating state between peers for the purpose of protecting traffic from a single source of IP datagrams to a single syncof IP datagrams Furthermore,

when employing the tunnel mode approach, IKEv2 implies that an

overlay routing model is introduced Irrespective of which mode is employed, each peer must create a point-to-point tunnel over a transit network, causing network designers and administrators problems

Current Approaches to the Point-to-Point Problem

Vendors have evolved two main approaches to Use Case One:

fully-meshed, and hub-and-spoke to handle the point-to-point scenario.

Fully-Meshed IPsec VPNs

Fully-meshed VPNs occur when each member of the VPN domain has

a set of tunnels defined to each and every other member of the VPN domain This arrangement is highly desirable from a traffic flow perspective because all the nodes can encrypt traffic to each other in the most efficient manner However, this approach comes at a cost – complexity and manageability – because the number of tunnels to be configured and activated on a given node in a fully-meshed network is

equal to n-1 and n2-1 For example, a 100-node network would require 9,999 tunnels to be provisioned If n is large, then computa-

tionally, expensive nodes need to be deployed and managed to make the mesh work, thus increasing both the capital and operational costs associated with the network Figure 1.4 details such a fully-meshed network arrangement with eight peers

Figure 1.4 Fully-Meshed IPsec VPNs

Hub-and-Spoke VPNs

To resolve the complexity and cost issues associated with fully-meshed VPNs, hub-and-spoke VPNs have emerged The principle here is that all non-hub nodes, designated as spokes, create a single connection to a hub device Traffic is then routed to all other spokes within the

Chapter 1: Why ADVPN ? 13

domain, via the common hub Now configuration tasks are simpler and the active tunnel count on a per-node basis is significantly lower, meaning more cost-effective nodes can be deployed and managed

As with the fully-meshed approach, there are drawbacks: the hub requires configuration changes each and every time a node is added or removed from the VPN domain and application latency is increased Also, all traffic must first leave the source node, traverse the transit network to the hub, and then return to the sink node in a non-direct and sub-optimal manner

Figure 1.5 Hub-and-Spoke IPsec VPNs

A New Approach

Neither the fully-meshed nor hub-and-spoke approaches are optimal for modern network deployments where customers demand both the ease of provisioning encrypted overlay security services and the optimum flow of traffic to minimize application traffic latency Table 1.1 summarizes these approaches and evaluates their ability to meet the requirements

Table 1.1 Comparison of VPN Approaches

Fully-Meshed Hub-and-Spoke Provisioning Complex Simple

Application Latency Low High

The Solution

What is needed today is an approach that takes the simplified sioning of hub-and-spoke with the low application latency of fully-meshed

provi-Making the Hub Zero Touch

The hub device should be zero-touch once deployed, so that adding and removing nodes in the VPN domain do not affect the operation of the network Thus network administrators can design, provision, and manage the network more effectively, reducing cost and risk to high availability

The SRX Series employs a feature called AutoVPN to deliver this

capability, which has been shipping since Junos 12.1X44

Making the Spoke-to-Spoke Connections Dynamic

Spokes should have the capability to temporary build tunnels between themselves on an on-demand basis to create the most efficient forward-ing path, so if a particular flow is required, the spokes build dynamic tunnels between themselves for that communication and then clear the tunnel when idle In this way the fully-meshed approach is available to the network without the overhead of configuring all the necessary communication paths The hub takes care of the task of identifying whether dynamic connections are required

The SRX provides this capability by extending the AutoVPN feature to include support for this type of behavior with the new ADVPN feature

Table 1.2 Comparing All Approaches

Fully-Meshed Hub-and-Spoke ADVPN Provisioning Complex Simple Simple

There are a number of proprietary solutions that have been created

by network vendors to solve the integration of IPsec into networks, examples include:

„ Juniper: NetScreen Auto-Connect VPN (AC-VPN)

„ Cisco: Dynamic Multipoint VPN (DMVPN)

„ HP: Dynamic VPN (DVPN)Juniper believes in open standards and has collaborated with industry players to create a document outlining the requirements This document was subsequently published as RFC 7018 and was adopted by the IETF IPsec Maintenance and Extensions (IPSECME) Working Group as the problem statement and requirements for Auto Discovery VPN Juniper and others then created a solution to the

problem that was circulated as a draft RFC:

draft-sathyanarayan-ipsecme-advpn-03.

MORE? The draft RFC containing the solution is located here as it

temporar-ily awaits publication as an informational RFC: http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn

Chapter 2

A Standards-based Approach

RFC 7018 Summary

RFC 7018 defines the problem space in terms of use cases and the RFC

7018 Problem Statement The use case is a large-scale IPsec ment operating in a fully-meshed environment covering:

deploy-„ Gateways-to-Gateways

„ Clients-to-Gateways

„ Clients-to-ClientsAnd the main problems to solve are:

„ Configuration Complexity

„ Device-Level IPsec Tunnel Management

RFC 7018 Problem Statement: Use Case One

Use Case One involves an endpoint-to-endpoint VPN with direct, fast, efficient connections for geographically local peers and with latency, bandwidth, and costs concerns for secure voice and video, all with trusted authentication as illustrated in Figure 2.1

Figure 2.1 Endpoint-to-Endpoint Use Case

Chapter 2: A Standards-based Approach 17

RFC 7018 Problem Statement: Use Case Two

Use Case Two is a gateway-to-gateway VPN, where:

„ Multi-media application support is inefficient in a star topology

„ There is a need to allow for cross-organization/domain support

„ Where the gateway may have dynamic addresses

„ Traffic forwarding policy is required

„ Layer 3 VPNs are within IPsec tunnels

„ Additional peer authentication is required as shown in Figure 2.2

Figure 2.2 Gateway- to-Gateway Use Case

RFC 7018 Problem Statement: Use Case Three

Use Case Three is an endpoint-to-gateway VPN that determines the most appropriate gateway on the network and provides a seamless connection to the most appropriate gateway on network This is illustrated in Figure 2.3

Figure 2.3 Endpoint-to-Gateway Use Case

Inadequacy of Existing Solutions

The following items were identified as concerns with existing large-scale VPN solutions for deployment:

„ Exhaustive configurations are needed

„ It does not scale

„ Cannot easily work across organization boundaries

„ Limited to capabilities of smallest domain member

„ Star topology (also known as hub-and-spoke)

„ Issues with dynamic addressing

„ Concentrates load on hub devices

„ Existing proprietary approaches

„ No interoperability between Juniper Networks AC-VPN, Cisco DMVPN, or HP DVPN

Chapter 2: A Standards-based Approach 19

Gateway and Endpoint Requirements

These are the gateway and endpoint requirements coming out of the committee:

„ Minimize hub configuration changes when gateways/clients added

to VPN

„ No configuration changes required on peers for direct connection

„ Support for routing protocols

„ Direct communication for full-mesh and dynamic full-mesh only

„ A compromised peer must not affect the security of unrelated peers

„ Gateways to support seamless handoff of sessions to clients

„ Gateways to support seamless handoff of sessions to gateways

„ Gateway and client support for NAT scenarios

„ New IPsec SAS reportable and manageable

„ Support for a federated model across operator boundaries

(connec-tions are made between organiza(connec-tions with different administrative boundaries yet require integrated communications)

„ Support for full-mesh, partial-mesh, and star topologies

„ Scale for multicast support

„ Support for easy monitoring, logging, and reporting

„ Support for Layer 3 VPNs over IPsec tunnels

„ Support of per-peer class of service in star and full-mesh topologies

„ Hub cannot be a single point of failure

Solution Status

Several competing solutions to the ADVPN problem statement were submitted to the IETF IPsec IPSECME Work Group for consideration

No agreement was ultimately reached on which solution to take forward

as the formal IETF standard, leaving the various teams of authors the option to publish as Informational RFCs

This is the intended path that Juniper and co-authors from Check Point, Orange (France Telecom), and the European Center for Information and Communication Technologies (EICT) intend to take

However, in the name of full disclosure, the current document is not an IETF-approved Standards Track RFC

Future ADVPN Developments

There are some major developments planned for the ADVPN feature

in the near future that will make it even more open and scalable.The current implementation of ADVPN uses OSPF to propagate routes throughout the ADVPN domain The employment of a dynamic routing protocol is important in the overall usability of the feature as the resulting routes can be used to select traffic for protection by the IPsec protocol This greatly simplifies adds, moves, and changes to the network as these modifications can occur without reference to the IPsec parameters – providing a high degree of flexibility

Dynamic routing in the SRX IPsec context does suffer from two major downsides – a proprietary implementation over point-to-multipoint interfaces and scalability issues when the number of nodes grows very large

The proprietary implementation issue is because the SRX utilizes a

proprietary payload called Next-Hop Tunnel Binding (NHTB) to

propagate interface information between SRX devices, and this is required to run OSPF over the point-to-multipoint interface The result is that third party support is not possible when ADVPN is used with OSPF

The scalability issue is because the SRX uses OSPF for the initial propagation of routes from spoke to hub (and vice versa), as well as for the preferential selection of the spoke-to-spoke routes In this context, the scalability of the solution is effectively the scalability of the OSPF protocol The solution has been qualified at 512 nodes per ADVPN domain If there are requirements for larger scale, then an alternative

to OSPF needs to be utilized

To address both the proprietary implementation issue and the scaling issue, the Junos ADVPN will be enhanced to support traffic selectors as the means of prefix propagation Traffic selectors are proposed by the peer on the control connection (from spoke to hub) and accepted into

the route table via a feature called auto route insertion, or ARI When

shortcuts are required between spokes, the hub will provide the traffic selectors to ADVPN partners and they will instantiate that these are routes to prefer the spoke-to-spoke route over the already established spoke-to-hub route

Finally, note that the Junos AutoVPN feature currently supports IPv4 addressing AutoVPN will be enhanced to support IPv6 and this will include the ADVPN capability in a future release

The majority of ADVPN operations are in the control plane Data plane functions such as tunnels, encryption algorithms, and how packets are encrypted and decrypted on the Juniper SRX platform in the same way they have been for many years now The additional ADVPN control plane concepts can be narrowed down to three items:

„ Shortcut Suggester

„ Shortcut Partner

„ Identity Management

Shortcut Suggester

The role of the suggester SRX, as the names implies, is to tell its peers

of a potential peer-to-peer relationship that can be formed, so the suggester does not need to be involved in a flow The message sent from the suggester to the partner is called a shortcut exchange How

does this work? A suggester is looking at transit flows – where the

flow has an ingress IPsec tunnel and an egress IPsec tunnel and both

IPsec tunnels have formed with ADVPN-capable peers It should be noted the suggester is only looking at flows that transit the SRX itself – the SRX has no concept of the rest of the network topology This becomes an important factor in network design, something that is covered a little later in this book Once the suggester tells its peers of the potential peer-to-peer relationship via the shortcut exchange, and receives acknowledgement of the exchange, the function of the suggester is complete

NOTE For a shortcut to be initiated, the suggester needs to have peer

rela-tionships with the partner nodes Hence a suggester is likely to be a core/ hub node in the network In many network scenarios, the Suggester SRX will have a peer relationship with all Partner SRXs

Chapter 3

ADVPN Key Concepts

Shortcut Partner

The role of the Partner SRX is to listen for short exchange messages that are sent from the suggester Based on the Partner SRX’s local policy, it will decide whether to take any action on this message Assuming local policy is met, the partner will take the information contained in the message and form an IKE association, then an IPsec association to the other partner peer, as outlined in the shortcut message The partner function continues to monitor any shortcut tunnels being created by this method, and by policy, will tear down a tunnel when it is no longer needed

NOTE A partner is likely to be at the edge of the network, with static IKE/IPsec

security associations to at least one suggester node in the network

A Functioning Solution – Dividing the Problem in Two

Having outlined the major concepts of ADVPN, how does it come together? As described in the draft response to RFC 7018, ADVPN is solving the problem of how to signal in an auto discovery environment, while keeping the environment as simple and dynamic as possible

It soon became obvious that signaling was one key piece of the solution But to have a functional network once new paths are established, the SRX needs an ability to be able to use those paths The authors of the draft response to RFC 7018 felt that this problem should be solved using

traditional routing protocols or explicit traffic selector definition and hence be covered by other RFCs In this Day One book, both are

covered

Chapter 3: ADVPN Key Concepts 23

IKEv2 for Signaling

As IPsec implementations have matured, the need to rectify problems in the first implementation of IKE became pressing The original IKE protocol was very chatty in nature, had no standard way of handling NAT traversal, and could not support EAP as an authentication method, among other limitations IKEv2 was created to solve such deficiencies Most modern communication protocols are designed so they are extensible, allowing for additions to be made without a wholesale change in the protocol, which is the same for IKEv2 ADVPN takes advantage of IKEv2’s extensibility

The capabilities can include a shortcut suggester and a shortcut partner

It is important to note that during the IKE capabilities exchange, if the SRX does not advertise ADVPN capability, no additional ADVPN message processing will take place This ensures interoperability between ADVPN and non-ADVPN capable nodes, as non-ADVPN nodes will not be expecting to receive ADVPN messages Other capa-bilities outlined in the RFC standard (Trusted Suggester, and fully qualified domain name [FQDN] resolver) are not implemented in the first phase of ADVPN

Shortcut Exchange

Once a suggester node has decided there is a peer-to-peer relationship that can be formed to optimize the network, the partner peer is informed

via a shortcut message When this exchange is initiated, the partner acts

as a RFC 5996 responder The format of the exchange is as follows:

HDR, SK {IDa, ADVPN_INFO, IDi, IDr[, TSi][, TSr][, VID]} >

<== HDR, SK {N(ADVPN_STATUS)}

The suggester expects that the shortcut request sent to the Partner will

be acknowledged

IDa is a specific ADPVN informational element that contains the IP

address or FQDN of the peer gateway While the address information could have been derived from the underlying streams, this would not have allowed for sending the FQDN By having this specific informa-tion element, there is complete flexibility in how to identify the partner The ADVPN_INFO information element provides specific information related to the shortcut:

The key information sent to the partners includes:

1 Lifetime: Length of time for which the security association should

be established

2 Peer Port: Used to indicate that the peer node you will be talking

to is behind a NAT device, and what port should be used to establish communications

3 Role: What the peer will do on receiving this shortcut message The suggester decides one peer should initiate the shortcut connection, and the other peer should respond to the connection The initiator is responsible for starting the IKEv2 session, while the responder waits for the initiator to establish the connection

4 Pre-Shared Key: A mechanism to distribute pre-shared keys to each of the peers As mentioned earlier in the first implementation of ADVPN on SRX, this option is not available

5 Peer Description: This is used for logging and debugging purposes

Chapter 3: ADVPN Key Concepts 25

The IDi (IKE Initiator) and IDr (IKE responder) and TSi (traffic selector initiator) and TSr (traffic selector responder) parameters are

the same as what would be used in a non-ADPVN IKEv2 exchange

Finally, once the data element has been sent, a status message from the partner is used to ascertain what the partner has done with the short-cut request

de-„ Protocol ID (1 octet) must be zero, as specified in RFC 5996.

„ SPI Size (1 octet) must be zero, in conformance with RFC 5996.

„ ADVPN Status Message Type (2 octets) SHORTCUT Identifier - the 32-bit field from the SHORTCUT_INFO notification

„ F (1 bit) - Fatal Set if this notification means that the CUT no longer exists

SHORT-„ C (1 bit) - Critical Set if the peer must understand this RCODE,

or else delete the shortcut if the F bit is not set

„ E (1 bit) - Error Indicates an error condition (rather than a policy change)

„ RCODE (2 octets) - a 16-bit result code field described below

„ Timeout - this 32-bit field indicates the maximum number of seconds that the shortcut service is not available by the peer

There are two possible RCODES that are sent in the status message:

Value Description

0 SHORTCUT_ACK

3 TEMPORARILY_DISABLING_SHORTCUT

Note that only a subset of messages has been implemented from the draft standard If the partner accepts the shortcut suggestion, an RCODE of 0 will be returned If the partner rejects the shortcut suggestion, an RCODE

of 3 will be returned

Traditional Routing for Reachability

Once the SRX has created new network paths by acting on shortcut tions, the SRX needs a mechanism to use these new paths Two possible solutions (without deploying any new proprietary mechanisms) are:

sugges-„ Use an existing routing protocol, or

„ Use IPsec traffic selectors

In the first phase of SRX ADVPN deployment, using an existing routing protocol, such as OSPF, is required Naturally, the first concern is the scalability of the solution, and in subsequent chapters of this book scalabil-ity will be addressed by specific OSPF mechanisms that can be used to aid in scale or by network design to scale out the solution One advantage of using OSPF is its neighbor discovery mechanism, which will aid in the simplification of configuration

NOTE In subsequent releases of SRX ADVPN, it will be possible to configure

traffic selectors on each of the IKE gateway definitions During IKE change, the traffic selectors are exchanged, and, using reverse route injec-tion (effectively inserting static routes automatically), reachability informa-tion is updated

ex-Summary

ADVPN is an extension to the IPsec control plane made possible by the extensibility of IKEv2 SRX gateways can take on the role of a suggester, that is, they can create shortcut suggestions to hint at new IPsec tunnels to optimize traffic flow SRX gateways can take on the role of partners, which

is to listen out for shortcut suggestions and create a new IPsec tunnel, assuming local policy is met Identity in an ADVPN network is solved using PKI Network reachability will be managed using the OSPF routing proto-col

Now that the architecture of ADVPN has been covered and how it works from a protocol perspective, Chapter 4 will cover the key configuration steps

ADVPN builds on the configuration of a previous phase of SRX

AutoVPN functionality – Zero Touch Hub The seven configuration

2 Create the IKE proposal to use certificates, authentication, and encryption as per your organization’s security policy, or choose one of the predefined phase 1 proposal-sets

3 Create the IKE policy/policies that bind the proposal and local certificates

4 Create the IKE gateway definition where all the specific ADVPN configuration work gets done

5 Create the IPsec proposal or decide which predefined phase 2 proposal set to use

6 Create the IPsec policy linking to the IPsec proposal or proposal set

7 Create the IPsec VPN binding the IPsec policy and respective IKE gateway definition

Chapter 4

Key Configuration Steps

The proposal and policy configurations for both the suggester and partner should be very similar What differences there are, are in the configuration center on the IKE gateway and the IPsec VPN defini-tions As you will read in the subsequent sections of this chapter, enabling ADVPN is straightforward if the requisite configuration is already in place.

Let’s start the real work of this book by working through the ration of a suggester and partner Because AutoVPN Zero Touch Hub configurations are a relatively new Juniper configuration concept, an overview of what they require is covered as well

configu-Suggester Configuration

Let’s start with an IKE proposal and policy:

policy ikepol-advpn { certificate { local-certificate srx550-1;

} proposal-set suiteb-gcm-256;

}

You can see that in this example a local certificate srx550-1 has been created and the built-in proposal-set suiteb-gcm-256 has been referenced The certificate generated must be capable of being used with the ciphers selected Hence certificate srx550-1 is an Elliptic Curve (ECDSA) certificate with a size of 384 bits, using SHA384 as a hash

Now let’s look at the IKE gateway definition:

gateway hub-gw { ike-policy ikepol-advpn;

dynamic { distinguished-name { wildcard ST=ACT,O=Juniper;

} ike-user-type group-ike-id;

} local-identity distinguished-name;

external-interface ge-0/0/0.0;

advpn { partner { disable;

} } version v2-only;

}

Chapter 4: Key Configuration Steps 29

Here the IKE gateway definition binds the policy to gateway, and the next stanza is the dynamic hierarchy This configuration was first introduced with AutoVPN Zero Touch Hub in Junos 12.1X44, allowing the SRX to accept dynamic neighbors, and in this case, it’s looking for a wildcard match in the certificate subject line of ST=ACT,O=Juniper of the IKE peer The local-identity that is used is the certificate name as bound by the IKE policy The external-interface is the interface the SRX will listen

on for incoming IKE requests Up to this point, the configuration is exactly as per a Zero Touch Hub configuration Finally, the ADVPN configuration is set and the Partner function is disabled – this signals that the suggester function is enabled The configuration ends with the IKEv2-only designation that must be used for ADVPN operation

Once the IKE configuration is complete, let’s turn to the IPsec tion First, create the policies:

configura-policy standard { proposal-set suiteb-gcm-256;

}

Now let’s build the VPN definition for this particular gateway, which is

no different than any other SRX IPsec configuration:

vpn advpn { bind-interface st0.0;

ike { gateway hub-gw;

ipsec-policy standard;

}

This process can be repeated for additional suggester functions if you are running routing instances in the SRX to create separate WAN domains that function completely independently of each other It’s particularly useful when separation functions need to be stronger than simply routing instance separation – a common requirement for security conscious customers In order to follow best practices, different certificates should

be created for each routing instance and the subject should be distinct so accidental misconfiguration does not join the two security domains An example of this architecture is discussed in more detail in Chapter 9,

Architectural Blueprints.

Partner Configuration

Let’s look at the IKE proposal and policy:

policy ikepol-advpn { certificate { local-certificate srx550-2;

} proposal-set suiteb-gcm-256;

}

It’s exactly the same as at the suggester end, though the certificate, of course, is created for this particular SRX Now let’s look at the IKE gateway definition:

gateway advpn-hub { ike-policy ikepol-advpn;

} partner { connection-limit 10;

idle-time 60;

idle-threshold 10;

} } version v2-only;

ST=ACT,O=Juniper The external interface is the interface from which the IKE sessions will be sourced So far, this is a standard IKE gateway configuration using certificates The ADVPN partner definition is next Because this is an ADVPN partner configuration, the ADVPN suggester function needs to be explicitly disabled

Chapter 4: Key Configuration Steps 31

Under the partner stanza, there are three possible options These options control how many outbound shortcut security associations to allow from the SRX, and the traffic characteristics that control when shortcut security associations are torn down

NOTE All three options have defaults and if you are happy with these defaults

there is no need to configure them

The connection limit imposes a limit on how many shortcuts this partner will be a part of The use case for this parameter is to limit the number of sessions in line with the number of sessions a particular SRX model can sustain – a topic covered in Chapter 5

This configuration parameter can also be used as a protection nism; a potential vulnerability of any dynamic VPN solution is a Denial of Service (DoS) attack launched by inserting traffic into the network with the malicious intention of overwhelming the control plane In terms of traffic volume this style of attack can be very low in nature, but by the nature of the traffic flows, wide spread ADVPN shortcut suggestions could be triggered Even with SRX separation of control plane and data plane, which in many instances negates the effects of such an attack, it is still a security threat that customers should guard against Fortunately, the SRX has many other features that can be used to allow or deny traffic and implicitly allow or deny traffic that may create ADPVN shortcut suggestions; this will be covered in Chapter 5

mecha-Back to the configuration, the idle parameters allow tunnels to be torn down when they are not servicing traffic, either with an absolute idle timer (no traffic for a given number of seconds), or when traffic falls below a specified packets per second (pps) threshold

Now let’s build the VPN definition for this particular gateway This is

no different than any SRX IPsec configuration:

policy standard { proposal-set suiteb-gcm-256;

} vpn spoke { bind-interface st0.0;

ike { gateway advpn-hub;

ipsec-policy standard;

} establish-tunnels immediately;

}

It is possible to configure a single SRX with both the suggester and partner configuration In the first release of ADVPN in Junos

12.3X48, this can only be configured when using separate IKE

gate-way definitions, and when doing this, traffic will need to flow through this node from an IPsec perspective when crossing from the suggester configuration to the partner configuration and vice versa

NOTE Attempting to configure both ADVPN suggester and partner functions

on the same IKE gateway will result in a commit error.

NOTE In subsequent releases of Junos for the SRX, the ADVPN suggester and

partner functions will be able to operate on the same IKE gateway definition, allowing for many possible cross domain examples (as outlined in the draft response to RFC 7018) to be implemented

Routing Protocols

The first implementations of ADVPN will require the configuration of dynamic protocols in order to use the additional paths that are created once the Partner SRXs have established a shortcut tunnel The sup-ported protocol is OSPF Subsequent releases of ADVPN are planned

to use a traffic selector configuration Depending on your perspective,

if you want the most automatic and least configuration effort able, then choosing a dynamic routing protocol is the preferred path.Take a step back for a moment The problem to solve is how to configure a routing protocol where interfaces are dynamic and can appear or disappear at any stage If you think about it, that problem is very similar to backup scenarios from network designs in years past The same principles used then are readily used again today and the routing protocol needs to be able to cater to these dynamic characteris-tics

avail-For an OSPF configuration, this is achieved by tailoring the istics of the st0.0 interface, an example shown here:

ospf { area 0.0.0.0 { interface st0.0 { interface-type p2mp;

demand-circuit;

dynamic-neighbors;

} } }

Chapter 4: Key Configuration Steps 33

There are three key configuration stanzas in an ADVPN environment

in OSPF

„ The first is to set the interface type to Point-to-Multipoint (p2mp) From the IPsec interface perspective st0.0 is a single interface that will have a number of tunnels associated with it, all with their own IPsec security association Next Hop Tunnel Binding in this environment will identify the IP address at the other end of the protected tunnel This IP address will be used to create an OSPF adjacency with the remote SRX

„ The second stanza sets the interface to operate in demand-circuit

mode, as defined in RFC 1793 This changes OSPF keep-alive behavior for the IPsec interface Once the OSPF database synchronization is complete, OSPF Hello packets and OSPF Link State Advertisement (LSA) packets are suppressed To ensure LSAs do not time out in these environments, they are advertised with the DoNotAge bit set LSAs and OSPF Hellos are then only

sent when there is a topology change What constitutes a change

in topology in an ADVPN environment? Simply the creation and

tear down of dynamic IPsec tunnels in response to shortcut suggestions being sent, or the partner deciding that the connec-tion is no longer required Additional methods for speeding up network convergence are discussed later in this book

„ Finally, in the third stanza, the dynamic-neighbors keyword is required This informs OSPF that it should expect to see neigh-bor adjacencies come and go as the ADVPN suggester and partner functions communicate on the st0 interface

Summary

ADVPN configuration builds on existing SRX IPsec configuration For users converting from an existing AutoVPN configuration, the addi-tions are minimal ADVPN functions of suggester or partner are defined in the IKE gateway stanzas of configuration OSPF configura-tion will require some tuning to cater to the dynamic nature of AD-VPN with tunnels being added and removed from the network

As simple as the ADVPN configuration is, Chapter 5 will cover the tuning considerations of deploying ADVPN – like all network designs there are a multitude of factors to consider

From the smallest branch office device to the largest core/data center SRX Series, the SRX family has considerable capabilities The AD-VPN feature is supported on all SRX platforms as partner roles Support for the branch SRX came in 12.3X48-D10, while support for the HE SRX will be introduced in Junos 12.3X48-D20 The ADVPN Suggester function is only supported on the SRX240 and above models (due to the extra control plane processing that is required for the function to operate successfully).

Choosing the SRX Series Model

Deciding which device is appropriate, from a scaling point of view, needs to be considered from two perspectives

First it’s necessary to consider the number of sessions the SRX is required to peer with For the suggester function, this decision should

be straightforward, as the first cut calculation should be the total number of partner nodes in the network For the partner function, you should calculate using the number of traffic flows in the network – for instance, if ADVPN is being deployed over an existing network and applications flows are not changing, then this information could be derived from J-Flow records If the use case is to enable voice RTP packets as the dominant shortcut traffic type, the base information should be available from your organization’s voice team, in terms of the number of site-to-site calls The calculation becomes more interest-ing in relation to how the tunnels operate in the data network imple-mentation, and this is discussed in a later section of this chapter

Chapter 5

Tuning Considerations for ADVPN

Table 5.1 below shows the supported number of tunnels for each SRX model when acting in suggester or partner roles.

Table 5.1 Choosing a SRX Series Device for ADVPN

SRX Platforms Partner Suggester

* Supported from Junos 12.3X48-D20

Second, it’s necessary to think about the encryption throughput required for the device Like any IPsec implementation, it is important

to understand the traffic profile - that is, the distribution of the size of packets and the total number of packets per second to be processed Transitioning from a hierarchical design or a partial-mesh design, you should observe that the SRX devices at the aggregation points in your network have the IPsec processing load removed from them once ADVPN is deployed

Implementing ADVPN at the same time as making significant changes

to applications running on the network (often the case in business transformation projects) should be approached cautiously For example, a new implementation of VoIP in a WAN will dramatically change the mix of packet sizes in the network A single G.711 voice stream, using standard 20ms voice payload with RTP encoding, adds fifty packets per second in each direction, and each IP packet’s length is

200 bytes before IPsec encapsulation Careful planning is advised to ensure the appropriate SRX device is chosen to match the required throughput

Table 5.2 contains the IPsec encryption/decryption capabilities for each model when measured with the IMIX traffic profile

Chapter 5: Tuning Considerations for ADVPN 37

Table 5.2 IPsec Capabilities for SRX Series Devices as Measured With an IMIX Traffic Profile

Note that the throughput rates listed in Table 5.2 do not take into consideration the performance impact of other enabled features If additional services are enabled on these platforms, the throughput numbers can reduce as additional service processing takes away from the encryption/decryption performance

Another point to make about Table 5.2 is that there are two models of SPCs for the SRX5000 platform For the original (first generation) SPC, there are two SPUs on each card For the second generation SPC, there are four SPUs on each card, and each SPU is approximately twice as powerful as a first generation SPU The numbers quoted in Table 5.2 are per SPU Also note that on SRX1000, SRX3000, and SRX5000 plat-forms, the first SPU is used for the Central Point (CP) housekeeping function; this will reduce the encryption/decryption capability of the SPU that is performing the CP function

IP Addressing

From a reachability point of view, ADVPN essentially flattens the network The effect of ADVPN is to put all other nodes, and hence branch offices or locations, one hop away from one another It may seem that addressing schemes, which are often based on hierarchy or geogra-phy to achieve easy address summarization, don’t matter as much in these environments But IP addressing schemes are still valid in an ADVPN domain, it’s just that how you go about carving up the address space should be thought of a little differently

The concept of application reachability makes sense from a supernetting point of view For example, an enterprise has five data processing sites, and the branch offices are allowed to send and receive any application type from the data processing sites – a very permissive model However the branch sites can only send and receive voice traffic and CIFS traffic directly to other branch sites – a fairly restrictive model IP address allocation based on application flows makes rule generation and mainte-nance simple All partner sites are represented by one supernet, and all processing sites are represented by another supernet

IGP Metrics

Fine-tuning of OSPF metrics is required in an ADVPN environment to ensure that traffic flows through a suggester node when the IPsec tunnel

is not a shortcut peer This is important for two reasons The first is that

additional shortcut tunnels cannot be created if the traffic does not flow through a SRX with the suggester function enabled The second is that partner nodes may not be sized either by SRX capacity, or bandwidth, or both, to that site to perform any transit IPsec functions

To illustrate this point, let’s take the following simple network of one suggester and three partner SRX nodes

Figure 5.1 Topology of Fine-tuning OSPF Example

By default, the cost of a st0 interface is 1 Each partner has a control

tunnel to the suggester As traffic flows, Partner 1 and Partner 2 have

created a shortcut tunnel between each other, and Partner 2 and Partner 3 have created a shortcut tunnel between each other The problem arises if traffic from Partner 1 starts to flow to Partner 3 From Partner 1’s

Chapter 5: Tuning Considerations for ADVPN 39

perspective, there are two paths available, P1-S-P3 and P1-P2-P3

With default OSPF costs, each path is equal and it would be legitimate for Partner 1 to choose the path P1-P2-P3 The same would also be true for Partner 3, and it would also be legitimate to choose the path P3-P2-P1

OSPF costs need to be differentiated by suggester and partner, and potentially suggester-to-suggester, if multiple suggester nodes are provisioned in the network

Using the example in Figure 5.1, network paths that go through a ner node must have a higher cost than network paths that go through a suggester This forces traffic to go via a suggested path where there isn’t a direct shortcut Using the example in Figure 5.1, the OSPF cost

part-of the st0 interface on each partner is configured to be 2 The OSPF cost for network path P1-S-P3 is now 3 and the OSPF cost for network path P1-P2-P3 is now 4 Traffic now flows through the suggester, and assuming policy is met, a shortcut is built directory from Partner 1 to Partner 3

Many ADPVN deployments have multiple suggester nodes sioned to provide high availability To keep the network as simple as possible and to help with management and troubleshooting, a sug-

provi-gester should be designated as the primary sugprovi-gester Other sugprovi-gesters assume the role of secondary and tertiary suggesters, if that level of

availability is called for

To illustrate the multiple-suggester concept, let’s take the example shown in Figure 5.2 of two suggesters and three partner SRX nodes

Figure 5.2 Use Case for Multiple Suggesters

You can see that in terms of the metrics there are two formulas in play The partner SRX nodes’ metric must be higher than either of the sug-gester nodes The primary suggester node’s metric must be lower than the secondary suggester node It sounds pretty simple that Suggester 1, as the designated primary suggester, is configured with a metric of 1,

Suggester 2 as the secondary suggester is configured with a metric of 2, and the partner SRXs are all configured with a value of 3 The paths available, with their associated metrics, from Partner 1 to Partner 3, would then be:

„ P1-S1-P3 = 4

„ P1-S2-P3 = 5

„ P1-P2-P3 = 6These metrics work, but they don’t take into account operational or maintenance needs in case mistakes or other events happen during change windows For example, let’s say Suggester 1 requires mainte-nance and needs to be taken offline To minimize the disruption to the rest of the network, the st.0 OSPF metric is changed from 1 to 3 at the first step of the maintenance window This effectively promotes Sug-gester 2 to the role of the primary suggester as that SRX will have the lowest metric The network converges by active signaling rather than a box simply disappearing from the OSPF domain, so now:

„ P1-S1-P3 = 6

„ P1-S2-P3 = 5

„ P1-P2-P3 = 6Now, let’s say just by chance that Suggester 2 has had a loss of WAN connectivity before Suggester 1’s maintenance takes the SRX offline This now leads to the following metrics being active in the network:

„ P1-S1-P3 = 6

„ P1-P2-P3 = 6

As discussed earlier, this can lead to some undesirable results To work around the problem, a gap between suggester metrics and partner metrics can be reserved for maintenance Reworking this example, the primary suggester gets a value of 1, the secondary suggester gets a value of 2, the metric 3 is reserved, and the partner SRXs have a metric value of 4 In steady state, this leads to the following metrics per the last example:

„ P1-S1-P3 = 5

„ P1-S2-P3 = 6

„ P1-P2-P3 = 8