7.0.0 documentation #837
7.0.0 documentation #837
Conversation
… one for posterity and because I accidentally committed it...
| sidebars-label: SVR Zero Trust Network Architecture | ||
| --- | ||
|
|
||
| Security is a critical component of SD-WAN products in today’s market. The SSR (Session Smart Router) offers several means of ensuring the integrity of data transmitted through the router, such as encrypting application payload content, encrypting SVR (Secure Vector Routing) metadata and authentication for metadata. |
There was a problem hiding this comment.
Might be good to provide a link to an overview of SSR: about_128t
or
https://www.juniper.net/us/en/products/routers/session-smart-router.html
or
https://www.juniper.net/us/en/the-feed/topics/sd-wan/juniper-ai-driven-sd-wan-and-session-smart-networking-explainer.html
|
|
||
| Security is a critical component of SD-WAN products in today’s market. The SSR (Session Smart Router) offers several means of ensuring the integrity of data transmitted through the router, such as encrypting application payload content, encrypting SVR (Secure Vector Routing) metadata and authentication for metadata. | ||
|
|
||
| As an example, let's look at the needs of a financial institution. They have to keep transaction traffic secure. If it is not kept secure, the results are catastrophic for both the instution and the individual/companies whose transaction gets hijacked. SSR technology uses SVR to create a Zero Trust Network Architecture (ZTNA), allowing you to configure unparalelled security without the increased packet size, fragmentation, and increased transaction time common with IPSec. This design creates maximum scale, avoids mid-network re-encryption, and provides the ability to rotate keys as required. |
There was a problem hiding this comment.
I don't understand this statement: "and increased transaction time common with IPSec".
Are you trying to say SVR does not have the increased transaction time that is typically associated with IPSec?
There was a problem hiding this comment.
yes, I'm trying to point out that SVR v2 does not have the added weight of IPSec. I'm going to add a link to the SVR savings doc that calls out the differences.
|
|
||
| As an example, let's look at the needs of a financial institution. They have to keep transaction traffic secure. If it is not kept secure, the results are catastrophic for both the instution and the individual/companies whose transaction gets hijacked. SSR technology uses SVR to create a Zero Trust Network Architecture (ZTNA), allowing you to configure unparalelled security without the increased packet size, fragmentation, and increased transaction time common with IPSec. This design creates maximum scale, avoids mid-network re-encryption, and provides the ability to rotate keys as required. | ||
|
|
||
| In a newly deployed network, SVR ZTNA is more secure than the default security implementation of SVR, and far more secure than IPSec. SVR ZTNA affords you the best security strength not only because of the encryption key exchange, but through its ability to perform key rotations. |
There was a problem hiding this comment.
but through its ability to perform key rotations, for any network topology.
|
|
||
| Key rotation provides a high level of transport security. Configuring this feature creates a specific interval for the router to generate a new security key/payload key and distribute it across the network (or session?). | ||
|
|
||
| The security rekeying mechanism (key rotation) is configured on the conductor, at the Authority level, and requires that all routers and conductors are running the same version of software that supports this feature. Any SSR running an older version of software that does not support this functionality will cause traffic to fail between those peers. In these cases, events will be generated when peering fails to establish. |
There was a problem hiding this comment.
Remove these two sentences from How It Works: "Any SSR running an older version of software that does not support this functionality will cause traffic to fail between those peers. In these cases, events will be generated when peering fails to establish."
And put them in a Requirements section, or caveats, etc.
|
|
||
| The security rekeying mechanism (key rotation) is configured on the conductor, at the Authority level, and requires that all routers and conductors are running the same version of software that supports this feature. Any SSR running an older version of software that does not support this functionality will cause traffic to fail between those peers. In these cases, events will be generated when peering fails to establish. | ||
|
|
||
| The Security Key Manager is enabled by setting `enhanced-security-key-management` to `true`. The leader node then generates a local metadata key, which includes the following data: |
There was a problem hiding this comment.
There is no leader mode. Each peer sends the same mutual data to each other.
|
|
||
| The leader node sends this and other information to the peer node(s), which stores the metadata key that allows the peer to encrypt and decrypt messages. | ||
|
|
||
| This allows peer authentication, and the dynamic key generation and exchange provides the encryption of Secure Vector Routing (SVR) traffic. Routers generate their own keys based on X.509 certificates for encrypting metadata (metadata keys) and distribute them to their peers by BFD metadata. Sessions are encrypted using payload keys generated on demand, encrypted, and distributed to the peer by SVR. |
There was a problem hiding this comment.
I would insert a diagram here - the one I sent you from the PDF that outlines each of the keys, but make it more customer-friendly.
| sidebars-label: SVR Zero Trust Network Architecture | ||
| --- | ||
|
|
||
| Security is a critical component of SD-WAN products in today’s market. The SSR (Session Smart Router) offers several means of ensuring the integrity of data transmitted through the router, such as encrypting application payload content, encrypting SVR (Secure Vector Routing) metadata and authentication for metadata. |
There was a problem hiding this comment.
Need an Introduced in Version table.
| authority | ||
| enhanced-security-key-management true | ||
| ``` | ||
| And configure a `peering-common-name` on each router. This enables SVR and key rotation between all associated routers, and provides excellent security. |
There was a problem hiding this comment.
You need to explain that the peering-common-name is the identity of the peer router, as would be defined within the Certificate that is installed on the device (this should also match for self-signed certificates).
This would also be a good place to describe how to identify the peering common name.
| peering-common-name second-fake-alias-3 | ||
| location usa | ||
| inter-node-security internal | ||
| ``` |
There was a problem hiding this comment.
Need a troubleshooting section with output examples, plus alarms.
You also need to cover fail-soft and fail-hard.
Creating the pr for tracking. Not ready for review.