Hi,
As suggested in Dallas, I’ve described some of the tradeoffs between the two solutions described in draft-rbradfor-ccamp-confidential-segment-00.txt.
-- Rich
The Confidential Path Segment (CPS) ID provides two very different but equally valid solutions, the Path Key Subobject (PKS) solution and the Private Route Subobject (PRS) solution. This note examines a number of the advantages and disadvantages of each solution.
In short: The PKS solution allows a PCE to hide the CPS for an AS by saving it in a database and replacing it with a key in the ERO. During the LSP setup, the ingress LSR for that AS must query the PCE for an expansion.
The PRS solution allows a CPS for an AS to be hidden by encrypting it, which may be done by a PCE or by the Head-End LSR. During the LSP setup, the ingress LSR for that AS must use a decryption key to obtain the expansion (implying an earlier exchange or configuration).
The major differences between the mechanisms involve (1) additional control messages, (2) performance issues expanding those objects, (3) the addition of state to the PCE, (4) the solution scope (i.e. applicability to various topologies of each solution.), and (5) the size of objects added to existing messages.
(1) Additional Control Message Overhead:
The PKS solution requires a mechanism to expand the Path Key upon receipt of the LSP setup request. Since the PCE which calculated the Path Key might not reside in the entry boundary LSR, the LSR must request the expansion from the PCE, requiring an additional message exchange before LSP setup can proceed. The Path Encryption solution does not require this extra exchange between the PCE and the ingress node for every LSP. Rather, the decryption key needs to be exchanged only when it is changed. The result is additional delay during every LSP setup for the PKS solution but no additional delay for the PRS solution.
(2) PCE and LSR Performance:
The PKS solution must maintain a (temporary) database of keys adding overhead to the PCE. The PRS solution requires the encryption of the CPS in the PCE and decryption of the CPS in the LSR, which could be CPU intensive. Note that in case of a burst of requests, encryption of large number of CPS may have an impact on the PCE response time.
(3) Addition of State in the PCE:
The PKS solution requires the addition of path-specific state and maintenance of a database in the PCE. The PRS solution requires no additional state.
(4) Solution Scope:
The PKS and PRS solutions both work well in conjunction with a PCE to encode and decode the CPS. However the PKS provides no direct solution without a PCE. This prevents the PKS solution for working in the case where A's network straddles B's network and where A wants to use an ERO for a segment of the LSP across the intervening network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS even if the path (and therefore the returned RRO) crosses multiple boundaries. Finally, a PRS solution could be adapted to return actual failure locations in PERRs and/or PATHTEARs, while keeping the failure location confidential from LSRs without a decryption key. Currently privacy of this source is maintained by returning the address of border nodes, which can be very misleading.
(5) Message Object Overhead:
The PKS solution provides a very compact key or token to identify a path segment, which generally allows for smaller EROs to be returned by the PCE and to be requested in the resulting PATH message. A PRS which contains a CPS must generally be at least as large as the unencrypted PATH through the AS and may be significantly larger if it is desirable to hide the number of hops within the network from external view by padding the PRS. The result is potentially larger PATH (and PCEP) messages for the PRS solution.
Please note that the tradeoffs listed here are for the current I-D. Some of the shortcomings of each approach could be mitigated by implementation-specific optimizations. For example, a PCE could choose to signal the CPS expansion to the entry boundary LSR, shifting the burden of maintaining the PKS state to the LSR and eliminating the performance hit during LSP setup. A similar exchange could be performed for the PRS case, eliminating the need for a separate key exchange. These examples of extensions are beyond the scope of the ID, but might be useful when weighing the pros and cons of the two solutions.