Skip to main content
Datatracker
δ
Groups
By area/parent
Apps & Realtime
General
Internet
Ops & Management
Routing
Security
Web and Internet Transport
IAB
IRTF
IETF LLC
RFC Editor
Other
Active AGs
Active Areas
Active Directorates
Active IAB Workshops
Active Programs
Active RAGs
Active Teams
New work
Chartering groups
BOFs
BOF Requests
Other groups
Concluded groups
Non-WG lists
Documents
Search
Recent I-Ds
I-D submission
IESG dashboard
RFC streams
IAB
IRTF
ISE
Editorial
Subseries
STD
BCP
FYI
Meetings
Agenda
Materials
Floor plan
Registration
Important dates
Request a session
Session requests
Upcoming meetings
Upcoming meetings
Past meetings
Past meetings
Meeting proceedings
Other
IPR disclosures
Liaison statements
IESG agenda
NomComs
Downref registry
Statistics
I-Ds/RFCs
Meetings
API Help
Release notes
Report a bug
User
Sign in
Password reset
Preferences
New account
Report a bug
Sign in
Javascript disabled?
Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.
Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
RFC 5656
Status
Email expansions
History
Revision differences
From revision
RFC 5656 (2009-12-14)
draft-green-secsh-ecc-09 (2009-08-28)
draft-green-secsh-ecc-08 (2009-06-05)
draft-green-secsh-ecc-07 (2009-04-26)
draft-green-secsh-ecc-06 (2009-04-13)
draft-green-secsh-ecc-05 (2008-12-02)
draft-green-secsh-ecc-04 (2008-11-17)
draft-green-secsh-ecc-03 (2008-10-01)
draft-green-secsh-ecc-02 (2007-10-15)
draft-green-secsh-ecc-01 (2006-10-19)
draft-green-secsh-ecc-00 (2006-10-06)
To revision
RFC 5656 (2009-12-14)
draft-green-secsh-ecc-09 (2009-08-28)
draft-green-secsh-ecc-08 (2009-06-05)
draft-green-secsh-ecc-07 (2009-04-26)
draft-green-secsh-ecc-06 (2009-04-13)
draft-green-secsh-ecc-05 (2008-12-02)
draft-green-secsh-ecc-04 (2008-11-17)
draft-green-secsh-ecc-03 (2008-10-01)
draft-green-secsh-ecc-02 (2007-10-15)
draft-green-secsh-ecc-01 (2006-10-19)
draft-green-secsh-ecc-00 (2006-10-06)
Diff format
Side-by-side
Before-after
Change bars
Inline
Document history
RFC 5656
draft-green-secsh-ecc
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 …
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