7.0.0 documentation

docs/about_releases.mdx

@@ -36,8 +36,9 @@ However, issues resolved in `4.3.12`, which was released on 3/12/2021 are not ad
 
 ## General Availability 
 
-| Version | Initial GA Version | First Release Shipping Date | Latest GA Version | End of Engineering support | End of Support |
-| -- | -- | -- | -- | -- | -- |
+| Version | Initial GA Version | First Release Shipping Date | Latest GA Version | End of Software Engineering support | End of Support |
+| --| -- | -- | -- | -- | -- |
+| Release 7.0 | [7.0.0](release_notes_128t_7.0.md#release-700-63r1) | April 30, 2025| [7.0.0](release_notes_128t_7.0.md#release-700-63r1) | January 30, 2026 | June 30, 2026 |
 | Release 6.3 | [6.3.0](release_notes_128t_6.3.md#release-630-107r1) | September 30, 2024 | [6.3.4-r2](release_notes_128t_6.3.md#release-634-7r2) | March 26, 2026 | September 26, 2026 |
 | Release 6.2 | [6.2.0](release_notes_128t_6.2.md#release-620-39r1) | November 16, 2023 | [6.2.8-lts](release_notes_128t_6.2.md#release-628-10-lts) | September 6, 2026 | March 6, 2027 |
 | Release 6.1 | [6.1.0](release_notes_128t_6.1.md#release-610-55r1) | April 14, 2023 | [6.1.13-lts](release_notes_128t_6.1.md#release-6113-7-lts) | July 14, 2025 | January 14, 2026 |

docs/app_policy_hit_count.md

@@ -0,0 +1,177 @@
+---
+title: Application Policy Hit Count
+sidebar_label: Application Policy Hit Count
+---
+
+Application Policy Hit Count (APHC) provides insight into the routing policies being referenced to direct traffic in your network operations; it reports which policies are being referenced ("hit") and how. These values are presented as metrics tracked per service, per tenant; where each tenant service combination could be "hit" in one of the following ways.
+
+| Count  | Description |
+| ---- | ----------- |
+| Allowed | The session was allowed and created successfully. |
+| Failed | The session could not be created. |
+| Denied due to Access Policy | The packet was denied because an access policy explicitly disallows access. |
+| Denied due to URL Filtering | The session was created but was blocked once app classification was completed. |
+| Denied due to Local Service Definition | The session was allowed on another ingress router, but is denied here based on the rules of this router (relates to hierarchical services). |
+
+## How Does It Work?
+
+Application Policy Hit Count is enabled by default, tracking counts for all observed service and tenant combinations, including the `access policy denied` counters.
+
+The system maintains the current value in memory and will not provide a historical time series of the data. To prevent excessive consumption of memory resources, the device periodically removes combinations that are no longer being observed. Inactive tenant service combinations remain in the system for 30 to 60 minutes before being removed.
+
+## Configuration
+
+Counter configuration is flexible and can be enabled or disabled on individual routers, or across the whole authority. Counters can be configured to persist the policy hit count metrics, allowing them to be viewed as a time-series graph. The following configuration snippets show how each configure each option. 
+
+### Disable APHC for the Authority
+
+```
+configure
+  authority
+    metrics
+      application-policy-hit-count-tracking
+        enabled false
+      exit
+    exit
+  exit
+exit
+```
+
+### Disable APHC for the Router
+
+```
+configure
+  authority
+    router <router>
+      system
+        metrics
+          application-policy-hit-count-tracking disabled
+        exit
+      exit
+    exit
+  exit
+exit
+```
+
+### Disable APHC for the Authority but Enable for a Specific Router
+
+```
+configure
+  authority
+    metrics
+      application-policy-hit-count-tracking
+        enabled false
+      exit
+    exit
+    router <router>
+      system
+        metrics
+          application-policy-hit-count-tracking enabled
+        exit
+      exit
+    exit
+  exit
+exit
+```
+
+### Clear Expiring Counts
+
+The cleanup of expired counters runs automatically every 30 minutes. However, in some situations it may be necessary to manually clear hit count entries. In this situation the following command is available:.
+
+`clear application-policy-hit-counts [force] [node <node>] {router <router> | resource-group <resource-group>}`
+
+This command manually triggers the cleanup process. The execution does not change or prevent the scheduled cleanup run. However, executing the command twice will move cleanup forward by an hour and fully clear the policy hit count metrics.
+
+## Persist APHC Metrics
+
+Persistence can be configured using a metrics profile as described in the SSR Documentation. The example below show how to persist all hit count types for a specific service and tenant combination, using the `short` retention policy. It is a best practice to always use the shortest retention policy that satisfies your requirements.
+
+There are typically a significant number of APHC metrics active on a system. If persistence is necessary, select a small number of service tenant combinations to be persisted. Careless selection may overwhelm the stats infrastructure resulting in resource shortages.
+
+The following configurations are examples only; they should not be directly copied into another environment. Service, tenant, and router names must be replaced.
+
+### Authority Configuration
+
+```
+configure
+  authority
+    metrics-profile internet-policy-hit-counts
+      name internet-policy-hit-counts
+      metric /stats/application-policy-hit-count/allowed
+        id /stats/application-policy-hit-count/allowed
+        description "Allowed Hit Count"
+      exit
+      metric /stats/application-policy-hit-count/failed
+        id /stats/application-policy-hit-count/failed
+        description "Failed Hit Count"
+      exit
+      metric /stats/application-policy-hit-count/deny/policy-table
+        id /stats/application-policy-hit-count/deny/policy-table
+        description "Denied for Explicit Access Policy Hit Count"
+      exit
+      metric /stats/application-policy-hit-count/deny/local-service
+        id /stats/application-policy-hit-count/deny/local-service
+        description "Denied After Ingress Router Allowed Hit Count"
+      exit
+      metric /stats/application-policy-hit-count/deny/url-filtering
+        id /stats/application-policy-hit-count/deny/url-filtering
+        description "Denied For URL Filtering Hit count"
+      exit
+      filter service
+        parameter service
+        value internet
+      exit
+      filter tenant
+        parameter tenant
+        value engineering
+      exit
+    exit
+  exit
+exit
+```
+
+
+### Router Configuration
+
+```
+configure
+  authority
+    router <router>
+      name <router>
+      system
+        metrics
+          profile internet-policy-hit-counts
+            name internet-policy-hit-counts
+            retention short
+          exit
+        exit
+      exit
+    exit
+  exit
+exit
+```
+
+## Stats Output
+
+The hit count metrics can be accessed via the PCLI as shown. They provide a combination of services and tenants and show how traffic is allowed or blocked. In the example shown, we also see failures due to improperly configured services.
+
+```
+admin@westB.T207_West# show stats application-policy-hit-count node westA
+Wed 2025-01-08 18:59:28 UTC
+✔ Retrieving statistics...
+
+Highway Manager application policy hit count Stats
+--------------------------------------------------
+
+========= ======= ================= ================== =======
+ Metric    Node    Tenant            Service            Value
+========= ======= ================= ================== =======
+ allowed   westA   <global>          lan2-service           1
+           westA   red               lan2-service           1
+           westA   red               lan2-service         326
+ deleted   westA   <global>          lan2-service           1
+ failed    westA   <invalidTenant>   <UnknownService>      11
+           westA   red               <UnknownService>    5841
+
+Completed in 0.06 seconds
+```

docs/cert_based_sec_encrpt.md

@@ -0,0 +1,196 @@
+---
+title: Certificate-based Security Encryption
+sidebar_label: Certificate-based Security Encryption
+---
+
+Security is a critical component of SD-WAN products in today’s world. The effectiveness of any security strategy relies on the strength of the security algorithm and how related information is exchanged between participants.
+
+The SSR uses a Public Key Infrastructure (PKI) to validate the installed certificates and the authenticity of devices within the network, as well as a peer-to-peer security key exchange between SSRs. The result is a design that creates maximum scale, avoids mid-network re-encryption, and provides the ability to rotate keys as required.
+
+## Certificate Management 
+
+Certificate management is performed from the CLI using the commands and parameters provided in Configuration Commands and Parameters. The Certificate Signing Request Workflow is interactive, asking the user what they would like placed in the CSR. The following three validity checks take place upon importing a certificate:
+
+- Ensure that there is no private key accompanying the certificate. On 100 and 1000 series platforms the private key is parsed and validated against the matching private key on disk.
+
+- Parse the certificate and then validate it (dates/roles/other restrictions, etc.).
+
+- Check the certificate against the known revoked certificates (CRL).
+
+If the above three checks pass, then the private key and certificate are accepted and imported
+
+Long-lived Certificates are issued to every Juniper manufactured router by the Juniper Networks Certificate Authority. Use of the rekey feature requires that a certificate be provided during installation. The base certificate can be replaced during initial software installation, however all routers in a single authority MUST have certificates issued by the same certificate hierarchy. Otherwise, replacing a certificate may be done during a maintenance window.
+
+### Certificate Security
+
+The Certificate Revocation List (CRL) Manager handles the discovery, fetching, and periodic updates to CRLs. From this process a list of all known revoked certificates from all CRL sources is created, and the master list is published to disk.
+
+The following are some details of certificate security.
+
+- The Trusted Platform Module (TPM) stores the private key of the base certificate. The certificate and any keys are not included in any configuration.
+
+- Periodic revocation checks of the base certificate are performed based on the configuration defaults or user configured timelines. 
+
+- When rekeying is enabled on a newly initialized router that does NOT have a valid, signed certificate, an alarm is generated. A valid certificate must be obtained from a Certificate Authority before valid secure communication can take place. When a valid certificate is present, the router will create an elliptic-curve public/private key pair (see [RFC8422]). 
+
+- Contained within the SVR certificate is a router identifier, which must match the identifier of the router in the peer configuration. This router identifier is a UUID and guaranteed to be unique per node, even across RMAs.
+
+- The public key is used to create an X.509 certificate signing request (CSR) with the common name field set to the router's UUID. A certificate signing request is initiated through a secure connection to a configured Certificate Authority (CA). The CA digitally signs the CSR and returns it to the requesting router. Certificates and Public Keys are stored locally on each router in PEM format defined by RFC7468. 
+
+## Certificate Revocation List
+
+Managing the Certificate Revocation List (CRL) includes the discovery, fetching, and periodic updates to CRLs using the configuration commands and parameters provided in Configuration Commands and Parameters. These parameters generate a list of all known valid and revoked certificates from all CRL sources and saves this information to disk. The CRL configuration parameters include:
+
+**There does not seem to be any commands directly associated with creating a CRL other than certificate-revocation url and polling-interval. If there are others, please provide pointers.**
+
+## Installing Certificates
+
+Installing a trusted CA certificate on the SSR uses the existing functionality as described in [Adding a Trusted Certificate](howto_trusted_ca_certificate.md).
+
+## Replace or Revoke a Certificate
+
+When a certificate is revoked, expired, or invalid, the SSR generates an alarm. Based upon the SSR configuration, it will either `fail-soft` (the default behavior) or `fail-hard`.
+
+Soft failure results in a notification that the certificate is no longer valid and that appropriate action must be taken. 
+
+Hard failure results in the same notification, as well as the removal of all peering relationships. This stops the device from participating in SVR.
+
+The following sections describe the procedures for replacing and revoking certificates.
+
+### Expiring Certificate
+
+Expiring certificates will generate the following alarms.
+
+If a certificate expires within a month, a minor alarm is generated. 
+If a certificate expires within a week, a major alarm is generated. 
+If a certificate is expired or otherwise invalid, a critical alarm is generated. 
+
+When a router's certificate is about to expire or needs to be replaced, a new certificate can be added to the system using the [installation procedure](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/howto_trusted_ca_certificate). Once the new certificate file has been loaded into the system, an event is triggered to restart the peer authentication procedure again.
+
+### Compromised Certificate
+
+In the case of a compromised system or certificate, the certificate will be revoked. 
+
+The router periodically checks the Certificate Revocation List (CRL) from existing certificate authority servers for any revocations, according to the interval defined in the configuration. If a revocation has taken place, the router takes the action defined in the configuration (fail-soft or fail-hard). 
+
+## Peer Authentication
+
+Peer validation is done whenever a new certificate is added, or peer configuration has changed. When a certificate is received from a peer on multiple peer paths, a cached validation response is used. Validation is accomplished by verifying the routerID of its peer matches that of the certificate.
+
+The public key is sent by both routers on both pathways, but only needs to be validated one time for each router peer.
+
+When receiving a certificate from a peer router and performing validation, the receiving router must extract the peer router's public key and save it. This is used for validating the authenticity of any subsequent Peer Key/Rekey requests.
+
+## High Availability
+
+Each node of an HA pair manages its own unique certificate - certificates are not shared between nodes. Each node manages its own unique connection to its peers.
+
+When two nodes are configured as a redundant pair, each of the keys need to be exchanged between nodes. This is done to avoid rekeying on flow migration due to node failures. Keys can be safely exchanged between nodes as the HA sync interfaces are connected point to point over a SSH connection.
+
+## Configuration
+
+config certificate-revocation 
+ - url    blah.bla.com
+ - polling interval 
+	- Frequency to fetch CRL
+	- units: hours
+	- range: 1-168 
+	- default: 24
+ - backoff- interval: delay in seconds to apply to the polling-interval
+	- units: seconds
+	- type: uint32
+	- default: ?
+
+Peer Certificate Validation
+
+config peer-validation 
+	- validate peering connections on this router
+	- values: true/false
+	- default: false
+
+
+## Troubleshooting
+
+Use the following information to help troublshoot certificate events or issues.
+
+### PCLI commands
+
+- `show certificate` - Show basic certificate information
+- `show certificate detail` - Show all OpenSSL details about the certificate
+- `show certificate crl` - Show basic information about the CRL (including source)
+
+### Audit Events/Logging
+
+Audit events and logs are generated for the following events:
+
+- Generate CSR
+
+```
+=======================================================================================================================================================
+ 2025-03-19T20:50:35.173Z Generated certificate signing request.
+=======================================================================================================================================================
+ Type:               system.generate_csr
+ Node:               test-1
+ Description:        Generated CSR for: TestCertificate
+ Json Event Detail:  {"name":"TestCertificate","common_name":"example.com","country_name":"US","state_province_name":"California","locality_name":"San
+ Francisco","organization_name":"ExampleOrg","organizational_unit_name":"IT","email_address":"admin@example.com","validity_period_days":365}
+ Permitted:          True
+```
+
+- Import Certificate
+```
+======================================================================================================================================================================================================
+ 2025-03-26T21:22:43.108Z Ingested a certificate.
+======================================================================================================================================================================================================
+ Type:               system.ingest_certificate
+ Node:               test-1
+ Description:        Ingested certificate: TestCertificate
+ Json Event Detail:  {"purpose":"TLS Web Client
+ Authentication","common_name":"example.com","crl_urls":["http://10.27.34.42/crlfile.crl"],"certificate_authority":"N/A","fingerprint":"6D:C7:8E:48:4F:55:63:D9:AB:70:66:CD:29:4E:1C:37:CF:89:17:B0"}
+ Permitted:          True
+```
+
+- Peer Certificate Validation
+
+(Need example)
+
+- CRL Update
+```
+========================================================================================================================================================================================================
+ 2025-03-07T20:59:50.736Z Updated certificate revocation list files.
+========================================================================================================================================================================================================
+ Type:               system.crl_update
+ Node:               t158-dut1.CONDUCTOR
+ Description:        Updated CRL for issuer: endpoint
+ Json Event Detail:  {"forced":false,"last_updated":"Oct 17 16:33:11 2024 GMT","next_update":"Oct 27 15:33:10 2024
+ GMT","crl_url":"http://10.27.39.143/testCrl.pem","size":14162,"total_entries":279,"added_entries":0,"removed_entries":0,"success":true,"certificate_authority":"/C=US/O=Google Trust Services/CN=WR2"}
+ Permitted:          True
+```
+
+### Show Stats Commands 
+
+#### Event Counters
+
+`show stats security CSR success` 
+`show stats security CSR failure` 
+`show stats security certificate import success` 
+`show stats security certificate import failure` 
+`show stats security CRL fetch success` 
+`show stats security CRL fetch failure` 
+`show stats security CRL ingestion success` 
+`show stats security CRL ingestion failure `
+
+#### Certificate Event Counters
+
+`show stats security certificate expired` 
+`show stats security certificate invalid` 
+`show stats security certificate revoked` 
+
+#### Peer Certificate Event Counters
+
+`show stats security peer certificate expired` 
+`show stats security peer certificate invalid` 
+`show stats security peer certificate revoked` 
+
+
+