Bringup Sequence of Events

User Input Required for the ZTP Automatic Authentication Process

The automatic validation and authentication of Viptela devices that occurs during the bringup process can happen only if the vSmart controllers and the vBond orchestrators know the serial and chassis numbers of the devices that are permitted in the network. Let's first define these two terms:

• Serial number—​Each Viptela device has a serial number, which is a 40-byte number that is included in the device's certificate. For the vBond orchestrator and the vSmart controller, the certificate can be provided by Symantec or by an enterprise root CA. For the vEdge routers, the certificate is provided in the hardware's trusted board ID chip.
• Chassis number—In addition to a serial number, each vEdge router is identified by a chassis number. Because the vEdge router is the only Viptela-manufactured hardware, it is the only Viptela device that has a chassis number. There is a one-to-one mapping between a vEdge router's serial number and its chassis number.

The vSmart controllers and vBond orchestrators learn the serial and chassis numbers during the initial configuration of these devices:

• vSmart authorized serial numbers—The vManage NMS learns the serial numbers for all the vSmart controllers that are allowed to be in the network while it is creating a CSR and installing the signed certificate. You download these serial numbers to the vBond orchestrator, and the vBond orchestrator pushes them to the vSmart controller during the automatic authentication process.
• vEdge authorized serial number file—This file contains the serial and chassis numbers of all the vEdge routers that are allowed to be in the network. You upload this file to the vBond orchestrator and vSmart controllers.

In addition to the device serial and chassis numbers, the automatic validation and authentication procedure depends on having each device configured with the same organization name. You configure this name on the vManage NMS, and it is included in the configuration file on all devices. The organization name must be identical on all the devices that belong to a single organization (the name is case-sensitive). The organization name is also included in the certificate for each device, which is created either by Viptela or by an enterprise root CA.

Authentication between the vSmart Controller and the vBond Orchestrator

From a functional point of view, the first two devices on the Viptela overlay network that validate and authenticate each other are the vSmart controller and the vBond orchestrator. This process is initiated by the vSmart controller.

When the vSmart controller comes up, it initiates a connection to the vBond orchestrator, which is how the vBond orchestrator learns about the vSmart controller. These two devices then automatically begin a two-way authentication process—the vSmart controller authenticates itself with the vBond orchestrator, and the vBond orchestrator authenticates itself with the vSmart controller. The two-way handshaking between the two devices during the authentication process occurs in parallel. However, for clarity, the figure here, which is a high-level representation of the authentication steps, illustrates the handshaking sequentially. If the authentication handshaking succeeds, a permanent DTLS communication channel is established between the vSmart and vBond devices. If any one of the authentication steps fails, the device noting the failure tears down the connection between the two devices, and the authentication attempt terminates.

The vSmart controller knows how to reach the vBond orchestrator, because one of the parameters that you provision when you configure it is the IP address or DNS name of the vBond orchestrator. The vBond orchestrator is primed to respond to requests from the vSmart controller because:

• It knows that its role is to be the authentication system, because you included this information in the vBond configuration.
• You downloaded the vSmart authorized serial numbers from the vManage NMS to the vBond orchestrator.

If the vBond orchestrator has not yet started when the vSmart controller initiates the authentication process, the vSmart controller periodically attempts to initiate a connection until it is successful.

Below is a more detailed step-by-step description of how the automatic authentication occurs between the vSmart controller and the vBond orchestrator.

To initiate a session between the vSmart controller and the vBond orchestrator, the vSmart controller initiates an encrypted DTLS connection to the vBond orchestrator. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots.

Over this encrypted channel, the vSmart controller and the vBond orchestrator authenticate each other. Each device authenticates the other in parallel. For our discussion, let's start with the vSmart controller authentication of the vBond orchestrator:

1. The vBond orchestrator sends its trusted root CA signed certificate to the vSmart controller.
2. The vBond orchestrator sends the vEdge authorized serial number file to the vSmart controller.
3. The vSmart controller uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the vSmart controller. If the two organization names match, the vSmart controller knows that the organization of the vBond orchestrator is proper. If they do not match, the vSmart controller tears down the DTLS connection.
4. The vSmart controller uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vSmart controller knows that the certificate itself is valid. If the signature is incorrect, the vSmart controller tears down the DTLS connection.

After performing these two checks, the vSmart authentication of the vBond orchestrator is complete.

In the other direction, the vBond orchestrator​ authenticates the vSmart controller:

1. The vSmart controller sends its trusted root CA signed certificate to the vBond orchestrator.
2. The vBond orchestrator uses its chain of trust to extract the vSmart controller's serial number from the certificate. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, the vBond orchestrator tears down the DTLS connection.
3. The vBond orchestrator uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the vBond orchestrator. If the two organization names match, the vBond orchestrator knows that the organization of the vSmart controller is proper. If they do not match, the vBond orchestrator tears down the DTLS connection.
4. The vBond orchestrator uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vBond orchestrator knows that the certificate itself is valid. If the signature is incorrect, the vBond orchestrator tears down the DTLS connection.

After performing these three checks, the vBond authentication of the vSmart controller is complete.

After the bidirectional authentication completes between the two devices, the DTLS connection between the vBond orchestrator and the vSmart controller transitions from being a temporary connection to being a permanent connection, and the two devices establish an OMP session over the connection.

In a domain that has multiple vSmart controllers for redundancy, this process repeats between each pair of vSmart and vBond devices. In coordination with the vBond orchestrator, the vSmart controllers learn about each other and they synchronize their route information. It is recommended that you connect the different vSmart controllers to the WAN network through different NAT devices for higher availability.

A vBond orchestrator has only as many permanent DTLS connections as the number of vSmart controllers in the network topology. These DTLS connections are part of the network's control plane; no data traffic flows over them. After all the vSmart controllers have registered themselves with the vBond orchestrator, the vBond orchestrator and the vSmart controllers are ready to validate and authenticate the vEdge routers in the Viptela network.

Authentication between vSmart Controllers

In a domain with multiple vSmart controllers, the controllers must authenticate each other so that they can establish a full mesh of permanent DTLS connection between themselves for synchronizing OMP routes. A vSmart controller learns the IP address of the other vSmart controllers from the vBond orchestrator.

A vSmart controller learns about the possibility of other vSmart controllers being present on the network during the authentication handshaking with the vBond orchestrator, when it receives a copy of the vSmart authorized serial number file. If this file has more than one serial number, it indicates that the network may, at some point, have multiple vSmart controllers.

As one vSmart controller authenticates with a vBond orchestrator, the vBond orchestrator sends the vSmart controller the IP address of other vSmart controllers it has authenticated with. If the vBond orchestrator later learns of another vSmart controller, it sends that controller's address to the other already authenticated vSmart controllers.

Then, the vSmart controllers perform the steps below to authenticate each other. Again, each device authenticates the other in parallel, but for clarity, we describe the process sequentially.

1. vSmart1 initiates an encrypted DTLS connection to vSmart2 and sends its trusted root CA signed certificate to vSmart2.
2. vSmart2 uses its chain of trust to extract the vSmart1's serial number. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, vSmart2 tears down the DTLS connection.
3. vSmart2 uses its chain of trust to extract the organization name from the certificate and compares it to the locally configured organization name. If the two organization names match, vSmart2 knows that the organization of vSmart1 is proper. If they do not match, vSmart2 tears down the DTLS connection.
4. vSmart2 uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, vSmart2 knows that the certificate itself is valid. If the signature is incorrect, vSmart2 tears down the DTLS connection.

After performing these three checks, vSmart2​ authentication of vSmart1 is complete.

Now, vSmart1 authenticates vSmart2, performing the same steps as above.

1. First, vSmart2 sends its trusted root CA signed certificate to vSmart1.
2. vSmart1 uses its chain of trust to extract the vSmart2's serial number. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, vSmart1 tears down the DTLS connection.
3. vSmart1 uses its chain of trust to extract the organization name from the certificate and compares it to the locally configured organization name. If the two organization names match, vSmart2 knows that the organization of vSmart2 is proper. If they do not match, vSmart1 tears down the DTLS connection.
4. vSmart1 uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, vSmart2 knows that the certificate itself is valid. If the signature is incorrect, vSmart1 tears down the DTLS connection.

After performing these three checks, vSmart1​ authentication of vSmart2 is complete, and the temporary DTLS connection between the two devices becomes permanent.

After all the vSmart controllers have registered themselves with the vBond orchestrator, the vBond orchestrator and the vSmart controllers are ready to validate and authenticate the vEdge routers in the Viptela network.

Authentication between the vBond Orchestrator and a vEdge Router

When you deploy a vEdge router in the network, it first needs to do two things:

• Establish a secure connection with the vManage NMS so that it can receive its full configuration.
• Establish a secure connection with the vSmart controller can begin participating in the Viptela overlay network.

So, when a vEdge device comes up, how does it automatically discover the vManage NMS and vSmart controller and establish connections with them? It does so with help from the vBond orchestrator. The initial configuration on the vEdge router contains the vBond system’s IP address (or DNS name). Using this information, the vEdge router establishes a DTLS connection with the vBond orchestrator, and the two devices authenticate each other to confirm that they are valid Viptela devices. Again, this authentication is a two-way process that happens automatically. When the authentication completes successfully, the vBond orchestrator sends the vEdge router the IP addresses of the vManage NMS and the vSmart controller. Then, the vEdge router tears down its connection with the vBond orchestrator and begins establishing secure DTLS connections with the othe two devices.

After you boot vEdge routers and manually perform the initial configuration, they automatically start looking for their vBond orchestrator. The vBond orchestrator and vSmart controllers are able to recognize and authenticate the vEdge routers in part because you have installed the vEdge authorized device list file on both these devices.

After you boot a vEdge router, you manually perform the initial configuration, at a minimum setting the IP address of DNS name of the vBond orchestrator. The vEdge router uses this address information to reach the vBond orchestrator. The vBond orchestrator is primed to respond to requests from a vEdge router because:

• It knows that its role is to be the authentication system, because you included this information in the initial vBond configuration.
• As part of the initial configuration, you installed the vEdge authorized serial number file on the vBond orchestrator.

If the vBond orchestrator has not yet started when a vEdge router initiates the authentication process, the vEdge router periodically attempts to initiate a connection until the attempt succeeds.

Below is a more detailed step-by-step description of how the automatic authentication occurs between the vBond orchestrator and a vEdge router.

First, the vEdge router initiates an encrypted DTLS connection to the public IP address of the vBond orchestrator. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots. The vBond orchestrator receives the vEdge router's original interface address and uses the outer IP address in the received packet to determine whether the vEdge router is behind a NAT. If it is, the vBond orchestrator creates a mapping of the vEdge router's public IP address and port to its private IP address.

Over this encrypted DTLS channel, the vEdge router and the vBond orchestrator proceed to authenticate each other. As with other device authentication, the vEdge router and vBond orchestrator authenticate each other in parallel. We start our discussion by describing how the vEdge router authenticates the vBond orchestrator:

1. The vBond orchestrator sends its trusted root CA signed certificate to the vEdge router.​
2. The vEdge router uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the router itself. If the two organization names match, the vEdge routers knows that the organization of the vBond orchestrator is proper. If they do not match, the vEdge router tears down the DTLS connection.
3. The vEdge router uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vEdge router knows that the certificate itself is valid. If the signature is incorrect, the vEdge router tears down the DTLS connection.

After performing these two checks, the vEdge router knows that the vBond orchestrator is valid, and its authentication of the vBond orchestrator is complete.

In the opposite direction, the vBond orchestrator authenticates the vEdge router:

1. The vBond orchestrator sends a challenge to the vEdge router. The challenge is a 256-bit random value.
2. The vEdge router sends a response to the challenge that includes the following:
   • vEdge serial number
   • vEdge chassis number
   • vEdge board ID certificate
   • 256-bit random value signed by the vEdge router's private key
3. The vBond orchestrator compares the serial and chassis numbers to the list in its vEdge authorized device list file. The numbers must match one of the number pairs in the file. If there is no match, the vBond orchestrator tears down the DTLS connection.
4. The vBond orchestrator checks that the signing of the 256-bit random value is proper. It does this using the vEdge router's public key, which it extracts from the router's board ID certificate. If the signing is not correct, the vBond orchestrator tears down the DTLS connection.
5. The vBond orchestrator uses the root CA chain from the vEdge routers board ID certificate to validate that the board ID certificate is itself valid. If the certificate is not valid, the vBond orchestrator tears down the DTLS connection.

After performing these three checks, the vBond orchestrator knows that vEdge router is valid, and its authentication of the router is complete.

When the two-way authentication succeeds, the vBond orchestrator performs the final step of its orchestration, sending messages to the vEdge router and the vSmart controller in parallel. To the vEdge router, the vBond orchestrator sends the following:

• The IP addresses of the vSmart controllers in the network so that the vEdge router can initiate connections to them. The address can be public IP addresses, or for the controllers that are behind a NAT gateway, the addresses are a list of the public and private IP addresses and port numbers. If the vEdge router is behind a NAT gateway, the vBond orchestrator requests that the vEdge router initiate a session with the vSmart controller.
• Serial numbers of the vSmart controllers that are authorized to be in the network.

To the vSmart controller, the vBond orchestrator sends the following:

• A message announcing the new vEdge router in the domain.
• If the vEdge router is behind a NAT gateway, the vBond orchestrator sends a request to the vSmart controller to initiate a session with the vEdge router.

Then, the vEdge router tears down the DTLS connection with the vBond orchestrator​.

Authentication between the vEdge Router and the vManage NMS

After the vEdge router and vBond orchestrator have authenticated each other, the vEdge router receives its full configuration over a DTLS connection with the vManage NMS:

1. The vEdge router establishes a DTLS connection with the vManage NMS.
2. The vManage server sends the configuration file to the vEdge router.
3. When the vEdge router receives the configuration file and activates its full configuration.
4. The vEdge router starts advertising prefixes to the vSmart controller.

If you are not using a vManage NMS, you can log in to the vEdge router and either manually load its configuration file or manually configure the router.

Below is a more detailed step-by-step description of how the automatic authentication occurs between a vEdge router and a vManage NMS.

First, the vEdge router initiates an encrypted DTLS connection to the IP address of the vManage NMS. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots. The vManage NMS receives the vEdge router's original interface address and uses the outer IP address in the received packet to determine whether the vEdge router is behind a NAT. If it is, the vManage NMS creates a mapping of the vEdge router's public IP address and port to its private IP address.

Over this encrypted DTLS channel, the vEdge router and vManage NMS proceed to authenticate each other. As with other device authentication, the vEdge router and vManage NMS authenticate each other in parallel. We start our discussion by describing how the vEdge router authenticates the vManage NMS:

1. The vManage NMS sends its trusted root CA signed certificate to the vEdge router.​
2. The vEdge router uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the router itself. If the two organization names match, the vEdge routers knows that the organization of the vManage NMS is proper. If they do not match, the vEdge router tears down the DTLS connection.
3. The vEdge router uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vEdge router knows that the certificate itself is valid. If the signature is incorrect, the vEdge router tears down the DTLS connection.

After performing these two checks, the vEdge router knows that the vManage NMS is valid, and its authentication of the vManage NMS is complete.

In the opposite direction, the vManage NMS authenticates the vEdge router:

1. The vManage NMS sends a challenge to the vEdge router. The challenge is a 256-bit random value.
2. The vEdge router sends a response to the challenge that includes the following:
   • vEdge serial number
   • vEdge chassis number
   • vEdge board ID certificate (for a hardware vEdge router) or the signed certification (for a vEdge Cloud router)
   • 256-bit random value signed by the vEdge router's private key
3. The vManage NMS compares the serial and chassis numbers to the list in its vEdge authorized device list file. The numbers must match one of the number pairs in the file. If there is no match, the vManage NMS tears down the DTLS connection.
4. The vManage NMS checks that the signing of the 256-bit random value is proper. It does this using the vEdge router's public key, which it extracts from the router's board ID certificate. If the signing is not correct, the vManage NMS tears down the DTLS connection.
5. The vManage NMS uses the root CA chain from the vEdge routers board ID certificate to validate that the board ID certificate is itself valid. If the certificate is not valid, the vManage NMS tears down the DTLS connection.

After performing these three checks, the vManage NMS knows that vEdge router is valid, and its authentication of the router is complete.

When the two-way authentication succeeds, the vManage server sends the configuration file to the vEdge router. When the vEdge router receives the configuration file, it activates its full configuration and starts advertising prefixes to the vSmart controller.

Authentication between the vSmart Controller and the vEdge Router

The last step in the automatic authentication process is for the vSmart controller and the vEdge router to authenticate each other. In this step, the vSmart controller performs authentication to ensure that the vEdge router belongs in its network, and the vEdge router also authenticates the vSmart controller. When the authentication completes, the DTLS connection between the two devices becomes permanent, and the vSmart controller establishes an OMP peering session running over the DTLS connection. Then, the vEdge router starts sending data traffic over the Viptela overlay network.

Below is a more detailed step-by-step description of how the automatic authentication occurs between the vSmart controller and a vEdge router.

To initiate a session between a vSmart controller and a vEdge router, one of the two devices initiates an encrypted DTLS connection to the other. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots.

The authentication between a vSmart controller and a vEdge router is a two-way process that occurs in parallel. Let's start our discussion with how a vSmart controller authenticates a vEdge router:

1. The vSmart controller sends a challenge to the vEdge router. The challenge is a 256-bit random value.
2. The vEdge router sends a response to the challenge that includes the following:
   • vEdge serial number
   • vEdge chassis number
   • vEdge board ID certificate
   • 256-bit random value signed by the vEdge router's private key
3. The vSmart controller compares the serial and chassis numbers to the list in its vEdge authorized device list file. The numbers must match one of the number pairs in the file. If there is no match, the vSmart controller tears down the DTLS connection.
4. The vSmart controller checks that the signing of the 256-bit random value is proper. It does this using the vEdge router's public key, which it extracts from the router's board ID certificate. If the signing is not correct, the vSmart controller tears down the DTLS connection.
5. The vSmart controller uses the root CA chain from the vEdge routers board ID certificate to validate that the board ID certificate is itself valid. If the certificate is not valid, the vSmart controller tears down the DTLS connection.
6. The vSmart controller compares the response with the original challenge. If the response matches the challenge that the vBond orchestrator issued, authentication between the two devices occurs. Otherwise, the vSmart controller tears down the DTLS connection.

After performing these three checks, the vSmart controller knows that vEdge router is valid, and its authentication of the router is complete.

In the other direction, the vEdge router authenticates the vSmart controller:

1. The vSmart controller sends its trusted root CA signed certificate to the vEdge router.
2. The vEdge router uses its chain of trust to extract the vSmart controller's serial number from the certificate. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, the vEdge router tears down the DTLS connection.
3. The Edge router uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the vEdge router. If the two organization names match, the vEdge router knows that the organization of the vSmart controller is proper. If they do not match, the vEdge router tears down the DTLS connection.
4. The vEdge router uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vEdge router knows that the certificate itself is valid. If the signature is incorrect, the vEdge router tears down the DTLS connection.

After performing these three checks, the vEdge authentication of the vSmart controller is complete. The DTLS connection used for authentication now becomes a permanent (non-transient) connection, and the two devices establish an OMP session over it that is used to exchange control plane traffic.

This authentication procedure repeats for each vSmart controller and each vEdge router that you introduce into the overlay network.

Each vEdge router in the network must connect to at least one vSmart controller. That is, a DTLS connection must be successfully established between each vEdge router and one vSmart controller. The Viptela network has the notion of a domain. Within a domain, it is recommended that you have multiple vSmart controllers for redundancy. Then each vEdge router can connect to more than one vSmart controller.

Over the OMP session, a vEdge router relays various control plane–​related information to the vSmart controller so that the vSmart controller can learn the network topology:

• The vEdge router advertises the service-side prefixes and routes that it has learned from its local static and dynamic (BGP and OSPF) routing protocols.
• Each vEdge router has a transport address, called a TLOC, or transport location, which is the address of the interface that connects to the WAN transport network (such as the Internet) or to the NAT gateway that connects to the WAN transport. Once the DTLS connection comes up between the vEdge router and the vSmart controller, OMP registers the TLOCs with the vSmart controller.
• The vEdge router advertises the IP addresses of any services that are located on its service-side network, such as firewalls and intrusion detection devices.

The vSmart controller installs these OMP routes in its routing database and advertises them to the other vEdge routers in the Viptela overlay network. The vSmart controller also updates the vEdge router with the OMP route information that it learns from other vEdge routers in the network. The vSmart controller can apply inbound policy on received routes and prefixes before installing them into its routing table, and it can apply outbound policy before advertising routes from its routing table.