|
Hi, As suggested in -- 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. |