ADVPN design and implementation

Juniper Networking Technologies

DAY ONE: ADVPN DESIGN AND
IMPLEMENTATION

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, configurations, and troubleshooting samples.

By Mark Barrett, Dale Shaw, and Scott McKinnon


DAY ONE: ADVPN DESIGN AND IMPLEMENTATION

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 application traffic latency. What is needed is an approach that takes the simplified provisioning 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 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 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-tospoke VPN tunnels.
This Day One book will tell you why and show you how, while providing sample implementations to investigate in your lab.

IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:
nn Gain an appreciation of the main issues surrounding the integration of encryption technology
into networking products.
nn Understand the need for a standards-based approach to solving network integration issues.

nn Understand Juniper’s AutoDiscovery VPN (ADVPN) solution.
nn Learn how to incorporate the ADVPN feature into a design.
nn Explore the detailed steps required to implement and tune ADVPN in your network.
nn Take architectural blueprint designs as a base template to be tailored for your specific scenario.

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
ISBN 978-1941441169

9 781941 441169

51800


Juniper Networking Technologies

Day One: ADVPN Design and
Implementation

By Mark Barrett, Dale Shaw, and Scott McKinnon

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


iv

© 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.

About the Authors

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

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.

ISBN: 978-1-936779-16-9 (print)
Printed in the USA by Vervante Corporation.
ISBN: 978-1-936779-17-6 (ebook)
Version History: v1, September 2015
2 3 4 5 6 7 8 9 10
This book is available in a variety of formats at:
/>
Mark Barrett

Mark Barrett has been working in the networking
industry for 28 years. He has been through many
networking technology transitions (both protocols and
transmission techniques) from his part time University
jobs, to IBM, Cisco, and the Australian Federal Police, to
his current position as a Juniper Networks Systems
Engineer. No matter the technology, Mark has maintained a keen interest in high speed networking LAN and
WAN technologies and, in particular, how they need to
be secured.


v

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.


vi

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 />„„ 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 administrative functions of the Junos operating system, including the ability to
work with operational commands and to read, understand, and change
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 integration of encryption technology into networking products.
„„ 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 algorithms, 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.


viii

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 cornerstone 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:
„„ Configuration
„„ Tuning
„„ Service Management
„„ Blueprints
„„ Automation
„„ Futures


Chapter 1
Why ADVPN?

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: />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.
„„ Gateway-to-Gateway
„„ Endpoint-to-Endpoint
„„ Endpoint-to-Gateway


10

Day One: ADVPN Design and Implementation

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 encapsulating them in a new IP layer, forming new addressing between the
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 gateways.




Figure 1.2

Chapter 1: Why ADVPN ?

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 sync of 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.

11


12

Day One: ADVPN Design and Implementation

Current Approaches to the Point-to-Point Problem
Vendors have evolved two main approaches to Use Case One: fullymeshed, 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 computationally, 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 ?

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

13

14

Day One: ADVPN Design and Implementation

The Solution
What is needed today is an approach that takes the simplified provisioning of hub-and-spoke with the low application latency of fullymeshed.

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 forwarding 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.

Summary
Table 1.2 compares ADVPN with the fully-meshed and hub-and-spoke

approaches and evaluates them for desirability. As you can see,
ADVPN is simple to provision with low application latency, making it
highly desirable.
Table 1.2

Provisioning

Comparing All Approaches
Fully-Meshed

Hub-and-Spoke

ADVPN

Complex

Simple

Simple


Chapter 2
A Standards-based Approach

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-sathyanarayanipsecme-advpn-03.
MORE? The draft RFC containing the solution is located here as it temporarily awaits publication as an informational RFC: />html/draft-sathyanarayan-ipsecme-advpn.


16

Day One: ADVPN Design and Implementation

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 deployment operating in a fully-meshed environment covering:
„„ Gateways-to-Gateways
„„ Clients-to-Gateways
„„ Clients-to-Clients
And 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

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.

17

18

Day One: ADVPN Design and Implementation

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

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 (connections are made between organizations 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.

19


20

Day One: ADVPN Design and Implementation

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.


Chapter 3
ADVPN Key Concepts

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 relationships 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.


22

Day One: ADVPN Design and Implementation

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.

Identity Management
The nature of ADVPN means new relationships are created on an
as-needed basis. How can each SRX trust that the dynamic peer SRX is
a node it is willing to form a relationship with? The number of potential
relationships is a n*(n-1)/2 function. As n grows beyond even a relatively small number, the relationship count starts to become very large.
Fortunately, this problem was solved long ago using Public Key Infrastructure (PKI). The draft response to RFC 7018 includes a Pre-Shared
Keys (PSK) scenario, but PSK is not implemented in the first instance of
ADVPN capabilities in the SRX. This is due to the additional infrastructure that would be required to make such a solution work (while
avoiding the undesirable approach of using a single PSK for the entire
network, making the implementation inherently unsecure). For this
reason, Identity Management in the SRX implementation requires the
use of PKI.

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

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.
Capability Exchange

As part of the initial IKEv2 exchange, ADVPN-capable SRXs advertise
their ADVPN capabilities. The messages format is as follows:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !C!  RESERVED   !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Protocol ID  !   SPI Size    ! ADVPN Supported Message Type  !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Capabilities ...                                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 capabilities 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)}

23


24

Day One: ADVPN Design and Implementation

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 information element, there is complete flexibility in how to identify the partner.
The ADVPN_INFO information element provides specific information
related to the shortcut:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !C!  RESERVED   !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                        SHORTCUT Identifier                    !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            Lifetime                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! R | Reserved  |  PSK Length   |          Peer Port            !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~               Pre-Shared Key (variable length)                ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~              Peer Description (variable length)               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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 shortcut request.
                    1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !C!  RESERVED   !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol ID  !   SPI Size    !  ADVPN Status Message Type    !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        SHORTCUT Identifier                    !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !F|C|E|    Reserved             |            RCODE              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                           Timeout                             !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields corresponding to the first four octets are defined (as described) in RFC 5996; the remaining fields are defined as follows:
„„ 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 SHORTCUT no longer exists.
„„ 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

25