Skip to main content

Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
RFC 5656

Revision differences

Document history

Date By Action
2020-01-21
(System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-10-03
Cindy Morgan Notification list changed to jhutz@cmu.edu, jonathan@razzard.com from 3jg19@qlink.queensu.ca, jhutz@cmu.edu
2015-10-14
(System)
Notify list changed from jhutz@cmu.edu, douglas@stebila.ca, 3jg19@qlink.queensu.ca*  Collect information about the underlying network topology and
      network resources, and exports this to network nodes and/or a
      centralized controller as required.

  *  Create VTNs with the network resource and topology properties
      needed by the VPN+ services.

  *  Distribute the attributes of VTNs to network nodes which
      participate in the VTNs and/or the centralized controller.

  *  Map VPN+ services to an appropriate VTN.

  *  Compute and set up VTPs in each VTN to meet VPN+ service
      requirements.

  The collection of underlying network topology and resource
  information can be done using existing the IGP and Border Gateway
  Protocol - Link State (BGP-LS) [RFC7752] based mechanisms.  The
  creation of VTN and the distribution of VTN attributes may need
  further control protocol extensions.  The computation of VTPs based
  on the attributes and constraints of the VTN can be performed either
  by the headend node of the path or a centralized Path Computation
  Element (PCE) [RFC4655].

  There are two candidate control plane mechanisms for the setup of
  VTPs in the VTN: RSVP-TE and Segment Routing (SR).

  *  RSVP-TE [RFC3209] provides the signaling mechanism for
      establishing a TE-LSP in an MPLS network with end-to-end resource
      reservation.  This can be seen as an approach of providing a
      Virtual Transport Path (VTP) which could be used to bind the VPN
      to specific network resources allocated within the underlay, but
      there remain scalability concerns as mentioned in Section 5.2.2.

  *  The SR control plane [RFC8665] [RFC8667] [RFC9085] does not have
      the capability of signaling resource reservations along the path.
      On the other hand, the SR approach provides a potential way of
      binding the underlay network resource and the VTNs without
      requiring per-path state to be maintained in the network.  A
      centralized controller can perform resource planning and
      reservation for VTNs, and it needs to instruct the network nodes
      to ensure that resources are correctly allocated for the VTN.  The
      controller could provision the SR paths based on the mechanism in
      [RFC9256] to the headend nodes of the paths.

  According to the service requirements for connectivity, performance
  and isolation, one VPN+ service may be mapped a dedicated VTN, or a
  group of VPN+ services may be mapped to the same VTN.  The mapping of

Dong, et al.            Expires 29 January 2024              [Page 25]
Internet-Draft              VPN+ Framework                    July 2023

  VPN+ services to VTN can be achieved using existing control
  mechanisms with possible extensions, and it can be based on either
  the characteristics of the data packet or the attributes of the VPN
  service routes.

5.5.  Management Plane

  The management plane provides the interface between the VPN+ service
  provider and the customers for life-cycle management of the VPN+
  service (i.e., creation, modification, assurance/monitoring, and
  decommissioning).  It relies on a set of service data models for the
  description of the information and operations needed on the
  interface.

  As an example, in the context of 5G end-to-end network slicing
  [TS28530], the management of the transport network segment of the 5G
  end-to-end network slice can be realized with the management plane of
  VPN+. The 3GPP management system may provide the connectivity and
  performance related parameters as requirements to the management
  plane of the transport network.  It may also require the transport
  network to expose the capabilities and status of the network slice.
  Thus, an interface between the VPN+ management plane and the 5G
  network slice management system, and relevant service data models are
  needed for the coordination of 5G end-to-end network slice
  management.

  The management plane interface and data models for VPN+ services can
  be based on the service models described in Section 5.6.

  It is important that the management life-cycle supports in-place
  modification of VPN+ services.  That is, it should be possible to add
  and remove end points, as well as to change the requested
  characteristics of the service that is delivered.  The management
  system needs to be able to assess the revised VPN+ requests and
  determine whether they can be provided by the existing VTNs or
  whether changes must be made, and it will additionally need to
  determine whether those changes to the VTN are possible.  If not,
  then the customer's modification request may be rejected.

  When the modification of a VPN+ service is possible, the management
  system must make every effort to make the changes in a non-disruptive
  way.  That is, the modification of the VPN+ service or the underlying
  VTN must not perturbate traffic on the VPN+ service in a way that
  causes the service level to drop below the agreed levels.
  Furthermore, changes to one VPN+ service should not cause disruption
  to other VPN+ services.

Dong, et al.            Expires 29 January 2024              [Page 26]
Internet-Draft              VPN+ Framework                    July 2023

  The network operator for the underlay network (i.e., the provider of
  the VPN+ service) may delegate some operational aspects of the
  overlay VPN and the underlying VTN to the customer.  In this way, the
  VPN+ is presented to the customer as a virtual network, and the
  customer can choose how to use that network.  Some mechanisms in the
  operator's network is needed, so that a customer cannot exceed the
  capabilities of the virtual links and nodes, but can decide how to
  load traffic onto the network, for example, by assigning different
  metrics to the virtual links so that the customer can control how
  traffic is routed through the virtual network.  This approach
  requires a management system for the virtual network, but does not
  necessarily require any coordination between the management systems
  of the virtual network and the physical network, except that the
  virtual network management system might notice when the VTN is close
  to capacity or considerably under-used and automatically request
  changes in the service provided by the underlay network.

5.6.  Applicability of Service Data Models to VPN+

  This section describes the applicability of the existing and in-
  progress service data models to VPN+. [RFC8309] describes the scope
  and purpose of service models and shows where a service model might
  fit into an SDN based network management architecture.  New service
  models may also be introduced for some of the required management
  functions.

  Service data models are used to represent, monitor, and manage the
  virtual networks and services enabled by VPN+. The VPN customer
  service models (e.g., the Layer 3 VPN Service Model (L3SM) [RFC8299],
  the Layer 2 VPN Service Model (L2SM) [RFC8466]), or the ACTN Virtual
  Network (VN) model [I-D.ietf-teas-actn-vn-yang]) are service models
  which can provide the customer's view of the VPN+ service.  The
  Layer-3 VPN Network Model (L3NM) [RFC9182], the Layer-2 VPN network
  model (L2NM) [RFC9291] provide the operator's view of the managed
  infrastructure as a set of virtual networks and the associated
  resources.  The Service Attachment Points (SAPs) model [RFC9408]
  provides an abstract view of the service attachment points (SAPs) to
  various network services in the provider network, where VPN+ could be
  one of the service types.  Augmentation to these service models may
  be needed to provide the VPN+ services.  The NRP model
  [I-D.wdbsp-teas-nrp-yang] further provides the management of the NRP
  topology and resources both in the controller and in the network
  devices to instantiate the VTNs needed for the VPN+ services.

6.  Applicability in Network Slice Realization

  This section describes the applicability of VPN+ in network slice
  realization.

Dong, et al.            Expires 29 January 2024              [Page 27]
Internet-Draft              VPN+ Framework                    July 2023

  In order to provide IETF network slices to customers, a technology-
  agnostic network slice service model
  [I-D.ietf-teas-ietf-network-slice-nbi-yang] is needed for the
  customers to communicate the requirements of IETF network slices (end
  points, connectivity, SLOs, and SLEs).  These requirements may be
  realized using technology specified in this document to instruct the
  network to deliver a VPN+ service so as to meet the requirements of
  the IETF network slice customers.

6.1.  VTN Planning

  According to the network operators' network resource planning policy,
  or based on the requirements of one or a group of customers or
  services, a VTN may need to be created to meet the requirements of
  VPN+ services.  In the network slicing context, a VTN could be
  considered as an NRP used to support the IETF network slice services.
  One of the basic requirements for a VTN is to provide a set of
  dedicated network resources to avoid unexpected interference from
  other services in the same network.  Other possible requirements may
  include the required topology and connectivity, bandwidth, latency,
  reliability, etc.

  A centralized network controller can be responsible for calculating a
  subset of the underlay network topology (which is called a logical
  topology) to support the VTN requirement.  And on the network nodes
  and links within the logical topology, the set of network resources
  to be allocated to the VTN can also be determined by the controller.
  Normally such calculation needs to take the underlay network
  connectivity information and the available network resource
  information of the underlay network into consideration.  The network
  controller may also take the status of the existing VTNs into
  consideration in the planning and calculation of a new VTN.

6.2.  VTN Instantiation

  According to the result of the VTN planning, the network nodes and
  links involved in the logical topology of the VTN are instructed to
  allocated the required set of network resources for the VTN.  In the
  network slicing context, a VTN can be instantiated as an NRP.  One or
  multiple mechanisms as specified in section 5.1 can be used to
  partition the forwarding plane network resources and allocate
  different subsets of resources to different VTNs.  In addition, the
  data plane identifiers which are used to identify the set of network
  resources allocated to the VTN are also provisioned on the network
  nodes.  Depending on the data plane technologies used, the set of
  network resources of a VTN can be identified using e.g. either
  resource aware SR segments as specified in
  [I-D.ietf-spring-resource-aware-segments]

Dong, et al.            Expires 29 January 2024              [Page 28]
Internet-Draft              VPN+ Framework                    July 2023

  [I-D.ietf-spring-sr-for-enhanced-vpn], or a dedicated VTN resource ID
  as specified in [I-D.ietf-6man-enhanced-vpn-vtn-id] can be
  introduced.  The network nodes involved in a VTN may distribute the
  logical topology information, the VTN specific network resource
  information and the VTN resource identifiers using the control plane.
  Such information could be used by the controller and the network
  nodes to compute the TE or shortest paths within the VTN, and install
  the VTN specific forwarding entries to network nodes.

6.3.  VPN+ Service Provisioning

  According to the connectivity requirements of an IETF network slice
  service, an overlay VPN can be created using the existing or future
  multi-tenancy overlay technologies as described in Section 3.6.

  Then according to the SLO and SLE requirements of a network slice
  service, the overlay VPN is mapped to an appropriate VTN as the
  virtual underlay.  The integration of the overlay VPN and the
  underlay VTN together provide a VPN+ service which can meet the
  network slice service requirements.

6.4.  Network Slice Traffic Steering and Forwarding

  At the edge of the operator's network, traffic of IETF network slices
  can be classified based on the rules defined by the operator's
  policy, so that the traffic is treated as a specific VPN+ service,
  which is further mapped to an underlay VTN.  Packets belonging to the
  VPN+ service will be processed and forwarded by network nodes based
  the TE or shortest path forwarding entries and the set of network
  resources of the corresponding VTN.

7.  Scalability Considerations

  VPN+ provides performance guaranteed services in packet networks, but
  with the potential cost of introducing additional state into the
  network.  There are at least three ways that this additional state
  might be brought into the network:

  *  Introduce the complete state into the packet, as is done in SR.
      This allows the controller to specify the detailed series of
      forwarding and processing instructions for the packet as it
      transits the network.  The cost of this is an increase in the
      packet header size.  The cost is also that systems will have to
      provide VTN specific segments in case they are called upon by a
      service.  This is a type of latent state, and increases as the
      segments and resources that need to be exclusively available to
      VPN+ service are specified more precisely.

Dong, et al.            Expires 29 January 2024              [Page 29]
Internet-Draft              VPN+ Framework                    July 2023

  *  Introduce the state to the network.  This is normally done by
      creating a path using signaling such as RSVP-TE.  This could be
      extended to include any element that needs to be specified along
      the path, for example explicitly specifying queuing policy.  It is
      also possible to use other methods to introduce path state, such
      as via an SDN controller, or possibly by modifying a routing
      protocol.  With this approach there is state per path: per-path
      characteristic that needs to be maintained over the life of the
      path.  This is more network state than is needed using SR, but the
      packets are usually shorter.

  *  Provide a hybrid approach.  One example is based on using binding
      SIDs [RFC8402] to represent path fragments, and bind them together
      with SR.  Dynamic creation of a VPN service path using SR requires
      less state maintenance in the network core at the expense of
      larger packet headers.  The packet size can be lower if a form of
      loose source routing is used (using a few nodal SIDs), and it will
      be lower if no specific functions or resources on the routers are
      specified.

  Reducing the state in the network is important to VPN+, as it
  requires the overlay to be more closely integrated with the underlay
  than with conventional VPNs.  This tighter coupling would normally
  mean that more state needs to be created and maintained in the
  network, as the state about fine granularity processing would need to
  be loaded and maintained in the routers.  Aggregation is a well-
  established approach to reduce the amount of state and improve
  scaling, and VTN is considered as the network construct to aggregate
  the states of VPN+ services.  In addition, an SR approach allows much
  of the state to be spread amongst the network ingress nodes, and
  transiently carried in the packets as SIDs.

  The following subsections describe some of the scalability concerns
  that need to be considered.  Further discussion of the scalability
  considerations of the underlaying network construct of VPN+ can be
  found in [I-D.ietf-teas-nrp-scalability].

7.1.  Maximum Stack Depth of SR

  One of the challenges with SR is the stack depth that nodes are able
  to impose on packets [RFC8491].  This leads to a difficult balance
  between adding state to the network and minimizing stack depth, or
  minimizing state and increasing the stack depth.

Dong, et al.            Expires 29 January 2024              [Page 30]
Internet-Draft              VPN+ Framework                    July 2023

7.2.  RSVP-TE Scalability

  The established method of creating a resource allocated path through
  an MPLS network is to use the RSVP-TE protocol.  However, there have
  been concerns that this requires significant continuous state
  maintenance in the network.  Work to improve the scalability of RSVP-
  TE LSPs in the control plane can be found in [RFC8370].

  There is also concern at the scalability of the forwarder footprint
  of RSVP-TE as the number of paths through a label switching router
  (LSR) grows.  [RFC8577] addresses this by employing SR within a
  tunnel established by RSVP-TE.

7.3.  SDN Scaling

  The centralized approach of SDN requires state to be stored in the
  network, but does not have the overhead of also requiring control
  plane state to be maintained.  Each individual network node may need
  to maintain a communication channel with an SDN controller, but that
  compares favorably with the need for a control plane to maintain
  communication with all neighbors.

  However, SDN may transfer some of the scalability concerns from the
  network to a centralized controller.  In particular, there may be a
  heavy processing burden at the controller, and a heavy load in the
  network surrounding the controller.  A centralized controller may
  also present a single point of failure within the network.

8.  Manageability Considerations

  This section describes the considerations about the OAM and Telemetry
  mechanisms used to support the verification, monitoring and
  optimization of the characteristics and SLA fulfillment of the VPN+
  services.

8.1.  OAM Considerations

  The design of OAM for VPN+ services needs to consider the following
  requirements:

  *  Instrumentation of the underlay so that the network operator can
      be sure that the resources committed to a customer are operating
      correctly and delivering the required performance.

  *  Instrumentation of the overlay by the customer.  This is likely to
      be transparent to the network operator and to use existing
      methods.  Particular consideration needs to be given to the need
      to verify the various committed performance characteristics.

Dong, et al.            Expires 29 January 2024              [Page 31]
Internet-Draft              VPN+ Framework                    July 2023

  *  Instrumentation of the overlay by the service provider to
      proactively demonstrate that the committed performance is being
      delivered.  This needs to be done in a non-intrusive manner,
      particularly when the tenant is deploying a performance sensitive
      application.

  A study of OAM in SR networks is documented in [RFC8403].

8.2.  Telemetry Considerations

  Network visibility is essential for network operation.  Network
  telemetry has been considered as an ideal means to gain sufficient
  network visibility with better flexibility, scalability, accuracy,
  coverage, and performance than conventional OAM technologies.

  As defined in [RFC9232], the objective of Network Telemetry is to
  acquire network data remotely for network monitoring and operation.
  It is a general term for a large set of network visibility techniques
  and protocols.  Network telemetry addresses the current network
  operation issues and enables smooth evolution toward intent-driven
  autonomous networks.  Telemetry can be applied on the forwarding
  plane, the control plane, and the management plane in a network.

  How the telemetry mechanisms could be used or extended for the VPN+
  service is out of the scope of this document.

9.  Enhanced Resiliency

  Each VPN+ service has a life cycle, and may need modification during
  deployment as the needs of its tenant change.  This is discussed in
  Section 5.5.  Additionally, as the network evolves, there may need to
  perform garbage collection to consolidate resources into usable
  quanta.

Dong, et al.            Expires 29 January 2024              [Page 32]
Internet-Draft              VPN+ Framework                    July 2023

 
, draft-green-secsh-ecc@ietf.org to 3jg19@qlink.queensu.ca, jhutz@cmu.edu
2011-01-13
(System)
Posted related IPR disclosure: Certicom's Statement of IPR Related to RFC 4492, RFC 5289, RFC 5430, RFC 4754, RFC 4869, …
Posted related IPR disclosure: Certicom's Statement of IPR Related to RFC 4492, RFC 5289, RFC 5430, RFC 4754, RFC 4869, RFC 4109, RFC 5656, RFC 3278, RFC 5753, RFC 5754, RFC 5008, draft-igoe-secsh-suiteb-02
2010-01-04
Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-01-04
Cindy Morgan [Note]: 'RFC 5656' added by Cindy Morgan
2009-12-14
(System) RFC published