draft-ietf-i2rs-architecture-11.txt   draft-ietf-i2rs-architecture-12.txt 
Network Working Group A. Atlas Network Working Group A. Atlas
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational J. Halpern Intended status: Informational J. Halpern
Expires: June 18, 2016 Ericsson Expires: June 25, 2016 Ericsson
S. Hares S. Hares
Huawei Huawei
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
December 16, 2015 December 23, 2015
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-11 draft-ietf-i2rs-architecture-12
Abstract Abstract
This document describes the IETF architecture for a standard, This document describes the IETF architecture for a standard,
programmatic interface for state transfer in and out of the Internet programmatic interface for state transfer in and out of the Internet
routing system. It describes the basic architecture, the components, routing system. It describes the basic architecture, the components,
and their interfaces with particular focus on those to be and their interfaces with particular focus on those to be
standardized as part of the Interface to Routing System (I2RS). standardized as part of the Interface to Routing System (I2RS).
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 18, 2016. This Internet-Draft will expire on June 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Key Architectural Properties . . . . . . . . . . . . . . . . 11 3. Key Architectural Properties . . . . . . . . . . . . . . . . 11
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 12 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Identity and Authentication . . . . . . . . . . . . . . . 14 4.1. Identity and Authentication . . . . . . . . . . . . . . . 15
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 15 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 16
5. Network Applications and I2RS Client . . . . . . . . . . . . 16 5. Network Applications and I2RS Client . . . . . . . . . . . . 16
5.1. Example Network Application: Topology Manager . . . . . . 16 5.1. Example Network Application: Topology Manager . . . . . . 17
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 17 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 17
6.1. Relationship to its Routing Element . . . . . . . . . . . 17 6.1. Relationship to its Routing Element . . . . . . . . . . . 17
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 17 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 18
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 18 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 18
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 19 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 19
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 19 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Interactions with Local Configuration . . . . . . . . . . 19 6.3. Interactions with Local Configuration . . . . . . . . . . 20
6.4. Routing Components and Associated I2RS Services . . . . . 20 6.4. Routing Components and Associated I2RS Services . . . . . 20
6.4.1. Routing and Label Information Bases . . . . . . . . . 21 6.4.1. Routing and Label Information Bases . . . . . . . . . 21
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 22 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 22
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 23 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 23 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 23
6.4.5. Information Modeling, Device Variation, and 6.4.5. Information Modeling, Device Variation, and
Information Relationships . . . . . . . . . . . . . . 23 Information Relationships . . . . . . . . . . . . . . 23
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 23 Inheritance . . . . . . . . . . . . . . . . . . . 23
6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24
skipping to change at page 3, line 48 skipping to change at page 3, line 48
router. router.
This document sets out an architecture for a common, standards-based This document sets out an architecture for a common, standards-based
interface to this information. This Interface to the Routing System interface to this information. This Interface to the Routing System
(I2RS) facilitates control and observation of the routing-related (I2RS) facilitates control and observation of the routing-related
state (for example, a Routing Element RIB manager's state), as well state (for example, a Routing Element RIB manager's state), as well
as enabling network-oriented applications to be built on top of as enabling network-oriented applications to be built on top of
today's routed networks. The I2RS is a programmatic asynchronous today's routed networks. The I2RS is a programmatic asynchronous
interface for transferring state into and out of the internet routing interface for transferring state into and out of the internet routing
system. This I2RS architecture recognizes that the routing system system. This I2RS architecture recognizes that the routing system
and a router's OS provide useful mechanisms that applications could and a router's Operating System (OS) provide useful mechanisms that
harness to accomplish application-level goals. These network- applications could harness to accomplish application-level goals.
oriented applications can leverage the I2RS programmatic interface to These network-oriented applications can leverage the I2RS
create new ways of combining retrieval of internet routing data, programmatic interface to create new ways of combining retrieval of
analyzing this data, setting state within routers. internet routing data, analyzing this data, setting state within
routers.
Fundamental to the I2RS are clear data models that define the Fundamental to the I2RS are clear data models that define the
semantics of the information that can be written and read. The I2RS semantics of the information that can be written and read. The I2RS
provides a framework for registering and for requesting the provides a framework for registering and for requesting the
appropriate information for each particular application. The I2RS appropriate information for each particular application. The I2RS
provides a way for applications to customize network behavior while provides a way for applications to customize network behavior while
leveraging the existing routing system as desired. leveraging the existing routing system as desired.
Although the I2RS architecture is general enough to support Although the I2RS architecture is general enough to support
information and data models for a variety of data, and aspects of the information and data models for a variety of data, and aspects of the
skipping to change at page 4, line 43 skipping to change at page 4, line 43
I2RS is described as an asynchronous programmatic interface, the key I2RS is described as an asynchronous programmatic interface, the key
properties of which are described in Section 5 of properties of which are described in Section 5 of
[I-D.ietf-i2rs-problem-statement]. [I-D.ietf-i2rs-problem-statement].
The I2RS architecture facilitates obtaining information from the The I2RS architecture facilitates obtaining information from the
router. The I2RS architecture provides the ability to not only read router. The I2RS architecture provides the ability to not only read
specific information, but also to subscribe to targeted information specific information, but also to subscribe to targeted information
streams, filtered events, and thresholded events. streams, filtered events, and thresholded events.
Such an interface also facilitates the injection of ephemeral state Such an interface also facilitates the injection of ephemeral state
into the routing system. A non-routing protocol or application could into the routing system. Ephemeral state on a router is the state
inject state into a routing element via the state-insertion which does not survive a the reboot of a routing device or the reboot
functionality of the I2RS and that state could then be distributed in of the software handling the I2RS software on a routing device. A
a routing or signaling protocol and/or be used locally (e.g. to non-routing protocol or application could inject state into a routing
program the co-located forwarding plane). I2RS will only permit element via the state-insertion functionality of the I2RS and that
modification of state that would be safe, conceptually, to modify via state could then be distributed in a routing or signaling protocol
local configuration; no direct manipulation of protocol-internal and/or be used locally (e.g. to program the co-located forwarding
dynamically determined data is envisioned. plane). I2RS will only permit modification of state that would be
safe, conceptually, to modify via local configuration; no direct
manipulation of protocol-internal dynamically determined data is
envisioned.
1.2. Architectural Overview 1.2. Architectural Overview
Figure 1 shows the basic architecture for I2RS between applications Figure 1 shows the basic architecture for I2RS between applications
using I2RS, their associated I2RS Clients, and I2RS Agents. using I2RS, their associated I2RS Clients, and I2RS Agents.
Applications access I2RS services through I2RS clients. A single Applications access I2RS services through I2RS clients. A single
client can provide access to one or more applications. In the client can provide access to one or more applications. This figure
figure, Clients A and B each provide access to a single application also shows the types of data models associated with the routing
(application A and B respectively), while Client P provides access to system (dynamic configuration, static configuration, local
multiple applications. configuration, and routing and signaling configuration) which the
I2RS Agent data models may access or augment.
Figure 1 is similar to the figure 1 found in the
[I-D.ietf-i2rs-problem-statement], but this figure shows additional
detail on how the applications utilize I2RS clients to interact with
I2RS Agents. Figure 1 also shows a logical view of the data models
associated with the routing system rather than a functional view
(RIB, FIB, topology, policy, routing/signaling protocols, etc.)
In figure 1, Clients A and B each provide access to a single
application (application A and B respectively), while Client P
provides access to multiple applications.
Applications can access I2RS services through local or remote Applications can access I2RS services through local or remote
clients. In the figure, Applications A and B access I2RS services clients. A local client operates on the same physical box as routing
through local clients, while Applications C, D and E access I2RS system. In contrast, a remote client operates across the network.
services through a remote client. The details of how applications In the figure, Applications A and B access I2RS services through
communicate with a remote client is out of scope for I2RS. local clients, while Applications C, D and E access I2RS services
through a remote client. The details of how applications communicate
with a remote client is out of scope for I2RS.
An I2RS Client can access one or more I2RS agents. In the figure 1, An I2RS Client can access one or more I2RS agents. In the figure 1,
Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent
can provide service to one or more clients. In the figure, I2RS can provide service to one or more clients. In this figure, I2RS
Agent 1 provides services to Clients A, B and P while Agent 2 Agent 1 provides services to Clients A, B and P while Agent 2
provides services to only Clients B and P. provides services to only Clients B and P.
I2RS agents and clients communicate with one another using an I2RS agents and clients communicate with one another using an
asynchronous protocol. Therefore, a single client can post multiple asynchronous protocol. Therefore, a single client can post multiple
simultaneous requests, either to a single agent or to multiple simultaneous requests, either to a single agent or to multiple
agents. Furthermore, an agent can process multiple requests, either agents. Furthermore, an agent can process multiple requests, either
from a single client or from multiple clients, simultaneously. from a single client or from multiple clients, simultaneously.
The I2RS agent provides read and write access to selected data on the The I2RS agent provides read and write access to selected data on the
routing element that are organized into I2RS Services. Section 4 routing element that are organized into I2RS Services. Section 4
describes how access is mediated by authentication and access control describes how access is mediated by authentication and access control
mechanisms. Figure 1 shows I2RS agents being able to write ephemeral mechanisms. Figure 1 shows I2RS agents being able to write ephemeral
static state (e.g. RIB entries), and to read from dynamic static static state (e.g. RIB entries), and to read from dynamic static
(e.g. MPLS LSP-ID or number of active BGP peers). (e.g. MPLS LSP-ID or number of active BGP peers). In addition, the
In addition to read and write access, the I2RS agent allows clients In addition to read and write access, the I2RS agent allows clients
to subscribe to different types of notifications about events to subscribe to different types of notifications about events
affecting different object instances. One example of a notification affecting different object instances. One example of a notification
of such an event (which is unrelated to an object creation, of such an event (which is unrelated to an object creation,
modification or deletion) is when a next-hop in the RIB is resolved modification or deletion) is when a next-hop in the RIB is resolved
enough to be used by a RIB manager for installation in the forwarding enough to be used by a RIB manager for installation in the forwarding
plane as part of a particular route. Please see Section 7.6 and plane as part of a particular route. Please see Section 7.6 and
Section 7.7 for details. Section 7.7 for details.
skipping to change at page 7, line 30 skipping to change at page 7, line 48
A Routing Element may be locally managed, whether via CLI, SNMP, A Routing Element may be locally managed, whether via CLI, SNMP,
or NETCONF. or NETCONF.
Routing and Signaling: This block represents that portion of the Routing and Signaling: This block represents that portion of the
Routing Element that implements part of the internet routing Routing Element that implements part of the internet routing
system. It includes not merely standardized protocols (i.e. IS- system. It includes not merely standardized protocols (i.e. IS-
IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager
layer. layer.
Local Configuration: A Routing Element will provide the ability to Local Configuration: is the black box behavior for interactions
configure and manage it. The Local Configuration is defined in between the ephemeral state that I2RS installs into the routing
this architecture as the configuration parameters associated with element; and this Local Configuration is defined by this document
a routing system. The Local Configuration may be read, written, and the behaviors specified by the I2RS protocol.
or changed via a combination of CLI, NETCONF, SNMP and other
protocols. The black box behavior for interactions between the
ephemeral state that I2RS installs into the routing element and
the Local Configuration must be defined in I2RS data models.
Dynamic System State: An I2RS agent needs access to state on a Dynamic System State: An I2RS agent needs access to state on a
routing element beyond what is contained in the routing subsystem. routing element beyond what is contained in the routing subsystem.
Such state may include various counters, statistics, flow data, Such state may include various counters, statistics, flow data,
and local events. This is the subset of operational state that is and local events. This is the subset of operational state that is
needed by network applications based on I2RS that is not contained needed by network applications based on I2RS that is not contained
in the routing and signaling information. How this information is in the routing and signaling information. How this information is
provided to the I2RS agent is out of scope, but the standardized provided to the I2RS agent is out of scope, but the standardized
information and data models for what is exposed are part of I2RS. information and data models for what is exposed are part of I2RS.
skipping to change at page 10, line 23 skipping to change at page 10, line 38
resources: A resource is an I2RS-specific use of memory, storage, resources: A resource is an I2RS-specific use of memory, storage,
or execution that a client may consume due to its I2RS operations. or execution that a client may consume due to its I2RS operations.
The amount of each such resource that a client may consume in the The amount of each such resource that a client may consume in the
context of a particular agent may be constrained based upon the context of a particular agent may be constrained based upon the
client's security role. An example of such a resource could client's security role. An example of such a resource could
include the number of notifications registered for. These are not include the number of notifications registered for. These are not
protocol-specific resources or network-specific resources. protocol-specific resources or network-specific resources.
role or security role: A security role specifies the scope, role or security role: A security role specifies the scope,
resources, priorities, etc. that a client or agent has. Multiple resources, priorities, etc. that a client or agent has. If a
identities may use the same security role. A single identity may identity has multiple roles in the security system, the identity
have may have multiple roles. is permitted to perform any operations any of those roles permit.
Multiple identities may use the same security role.
identity: A client is associated with exactly one specific identity: A client is associated with exactly one specific
identity. State can be attributed to a particular identity. It identity. State can be attributed to a particular identity. It
is possible for multiple communication channels to use the same is possible for multiple communication channels to use the same
identity; in that case, the assumption is that the associated identity; in that case, the assumption is that the associated
client is coordinating such communication. client is coordinating such communication.
Identity and scope: A single identity can be associated with Identity and scope: A single identity can be associated with
multiple roles. Each role has its own scope and an identity multiple roles. Each role has its own scope and an identity
associated with multiple roles can use the combined scope of all associated with multiple roles can use the combined scope of all
skipping to change at page 11, line 5 skipping to change at page 11, line 22
a notification-scope that is the logical OR of the a notification-scope that is the logical OR of the
notification-scopes associated with its roles. notification-scopes associated with its roles.
secondary identity: An I2RS Client may supply a secondary opaque secondary identity: An I2RS Client may supply a secondary opaque
identity that is not interpreted by the I2RS Agent. An example identity that is not interpreted by the I2RS Agent. An example
use is when the I2RS Client is a go-between for multiple use is when the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has applications and it is necessary to track which application has
requested a particular operation. requested a particular operation.
Groups: NETCONF Network Access [RFC6536] refers uses the term group Groups: NETCONF Network Access [RFC6536] uses the term group in
in terms of an Administrative group which supports support the terms of an Administrative group which supports the well-
well-established distinction between a root account and other established distinction between a root account and other types of
types of less-privileged conceptual user accounts. Group still less-privileged conceptual user accounts. Group still refers to a
refers to a single identity (e.g. root) which is shared by a group single identity (e.g. root) which is shared by a group of users.
of users.
3. Key Architectural Properties 3. Key Architectural Properties
Several key architectural properties for the I2RS protocol are Several key architectural properties for the I2RS protocol are
elucidated below (simplicity, extensibility, and model-driven elucidated below (simplicity, extensibility, and model-driven
programmatic interfaces). However, some architecture principles such programmatic interfaces). However, some architecture properties such
as performance and scaling are not described below because they are as performance and scaling are not described below because they are
discussed in [I-D.ietf-i2rs-problem-statement] and because the discussed in [I-D.ietf-i2rs-problem-statement], may may vary based on
performance and scaling requires varies based on the particular use- the particular use-cases.
cases.
3.1. Simplicity 3.1. Simplicity
There have been many efforts over the years to improve the access to There have been many efforts over the years to improve the access to
the information available to the routing and forwarding system. the information available to the routing and forwarding system.
Making such information visible and usable to network management and Making such information visible and usable to network management and
applications has many well-understood benefits. There are two applications has many well-understood benefits. There are two
related challenges in doing so. First, the quantity and diversity of related challenges in doing so. First, the quantity and diversity of
information potentially available is very large. Second, the information potentially available is very large. Second, the
variation both in the structure of the data and in the kinds of variation both in the structure of the data and in the kinds of
skipping to change at page 11, line 49 skipping to change at page 12, line 16
attempting to describe and close off every possible option, attempting to describe and close off every possible option,
complicating extensibility. complicating extensibility.
Thus, one of the key aims for I2RS is the keep the protocol and Thus, one of the key aims for I2RS is the keep the protocol and
modeling architecture simple. So for each architectural component or modeling architecture simple. So for each architectural component or
aspect, we ask ourselves "do we need this complexity, or is the aspect, we ask ourselves "do we need this complexity, or is the
behavior merely nice to have?" Protocol parsimony is clearly a goal. behavior merely nice to have?" Protocol parsimony is clearly a goal.
3.2. Extensibility 3.2. Extensibility
Naturally, extensibility of the protocol and data model is very Extensibility of the protocol and data model is very important. In
important. In particular, given the necessary scope limitations of particular, given the necessary scope limitations of the initial
the initial work, it is critical that the initial design include work, it is critical that the initial design include strong support
strong support for extensibility. for extensibility.
The scope of the I2RS work is being restricted in the interests of The scope of the I2RS work is being restricted in the interests of
achieving a deliverable and deployable result. The I2RS Working achieving a deliverable and deployable result. The I2RS Working
Group is modeling only a subset of the data of interest. It is Group is modeling only a subset of the data of interest. It is
clearly desirable for the data models defined in the I2RS to be clearly desirable for the data models defined in the I2RS to be
useful in more general settings. It should be easy to integrate data useful in more general settings. It should be easy to integrate data
models from the I2RS with other data. Other work should be able to models from the I2RS with other data. Other work should be able to
easily extend it to represent additional aspects of the network easily extend it to represent additional aspects of the network
elements or network systems. This reinforces the criticality of elements or network systems. This reinforces the criticality of
designing the data models to be highly extensible, preferably in a designing the data models to be highly extensible, preferably in a
skipping to change at page 12, line 46 skipping to change at page 13, line 14
understood. Second, tools can automate checking and manipulating understood. Second, tools can automate checking and manipulating
data; this is particularly valuable for both extensibility and for data; this is particularly valuable for both extensibility and for
the ability to easily manipulate and check proprietary data-models. the ability to easily manipulate and check proprietary data-models.
The different services provided by I2RS can correspond to separate The different services provided by I2RS can correspond to separate
data-models. An I2RS agent may indicate which data-models are data-models. An I2RS agent may indicate which data-models are
supported. supported.
The purpose of the data model is to provide an definition of the The purpose of the data model is to provide an definition of the
information regarding the routing system that can be used in information regarding the routing system that can be used in
operational networks. In some cases, the I2RS Working group may operational networks. If routing information is being modeled for
define an information model for a set of routing information in order the first time, a logical information model may be standardized prior
to define in general terms the information for a data model. If to creating the data model.
routing information is being modeled for the first time, a logical
information model may be standardized prior to creating the data
model.
4. Security Considerations 4. Security Considerations
This I2RS architecture describes interfaces that clearly require This I2RS architecture describes interfaces that clearly require
serious consideration of security. As an architecture, I2RS has been serious consideration of security. As an architecture, I2RS has been
designed to re-utilize existing protocols that carry network designed to re-utilize existing protocols that carry network
management information. Two of existing protocol which the I2RS WG management information. Two of the existing protocols which the
has selected to attempt to re-use are NETCONF [RFC6241] and RESTCONF which may be re-used are NETCONF [RFC6241] and RESTCONF
[I-D.ietf-netconf-restconf]. The I2RS protocol design process is to [I-D.ietf-netconf-restconf]. The I2RS protocol design process will
specify additional requirements which will include security for an be to specify additional requirements including security for these
existing protocol in order to support the I2RS architecture. After existing protocol in order to support the I2RS architecture. After
an existing protocol, e.g. NETCONF or RESTCONF, has been alter to an existing protocol, (e.g. NETCONF or RESTCONF) has been altered to
fit the I2RS requirements, then this protocol will be reviewed to fit the I2RS requirements, then it will be reviewed to determine if
determine if it meets the I2RS security requirements. it meets the I2RS security requirements.
Due to the re-use strategy of the I2RS architecture, this security Due to the re-use strategy of the I2RS architecture, this security
section describes the assumed security environment for I2RS with section describes the assumed security environment for I2RS with
additional detail on: a) identity and authentication, b) additional details on: a) identity and authentication, b)
authorization, and c) client redundancy. Each protocol proposed for authorization, and c) client redundancy. Each protocol proposed for
inclusions as an I2RS protocol will need to be evaluated for the inclusion as an I2RS protocol will need to be evaluated for the
security constraints of the protocol. The detailed requirements for security constraints of the protocol. The detailed requirements for
the I2RS protocol and the I2RS security environment will be defined the I2RS protocol and the I2RS security environment will be defined
within these gloal security environments. within these global security environments.
First, here is a brief description of the assumed security First, here is a brief description of the assumed security
environment for I2RS. The I2RS Agent associated with a Routing environment for I2RS. The I2RS Agent associated with a Routing
Element is a trusted part of that Routing Element. For example, it Element is a trusted part of that Routing Element. For example, it
may be part of a vendor-distributed signed software image for the may be part of a vendor-distributed signed software image for the
entire Routing Element or it may be trusted signed application that entire Routing Element or it may be trusted signed application that
an operator has installed. The I2RS Agent is assumed to have a an operator has installed. The I2RS Agent is assumed to have a
separate authentication and authorization channel by which it can separate authentication and authorization channel by which it can
validate both the identity and permissions associated with an I2RS validate both the identity and permissions associated with an I2RS
Client. To support numerous and speedy interactions between the I2RS Client. To support numerous and speedy interactions between the I2RS
skipping to change at page 13, line 50 skipping to change at page 14, line 15
be old either in a pull model until the I2RS Agent re-requests it, or be old either in a pull model until the I2RS Agent re-requests it, or
in a push model until the authentication and authorization channel in a push model until the authentication and authorization channel
can notify the I2RS Agent of changes. can notify the I2RS Agent of changes.
Mutual authentication between the I2RS Client and I2RS Agent is Mutual authentication between the I2RS Client and I2RS Agent is
required. An I2RS Client must be able to trust that the I2RS Agent required. An I2RS Client must be able to trust that the I2RS Agent
is attached to the relevant Routing Element so that write/modify is attached to the relevant Routing Element so that write/modify
operations are correctly applied and so that information received operations are correctly applied and so that information received
from the I2RS Agent can be trusted by the I2RS Client. from the I2RS Agent can be trusted by the I2RS Client.
An I2RS Client is not automatically trustworthy. It has identity An I2RS Client is not automatically trustworthy. Each I2RS Client is
information and applications using that I2RS Client should be aware associated with identity with a set of scope limitations.
of the scope limitations of that I2RS Client. If the I2RS Client is Applications using the I2RSS should be aware of the scope limitations
acting as a broker for multiple applications, managing the security, of that I2RS Client. If the I2RS Client is acting as a broker for
authentication and authorization for that communication is out of multiple applications, then managing the security, authentication and
scope; nothing prevents I2RS and a separate authentication and authorization for that communication is out of scope; nothing
authorization channel from being used. Regardless of mechanism, an prevents the broker from using I2RS protocol and a separate
I2RS Client that is acting as a broker is responsible for determining authentication and authorization channel from being used. Regardless
that applications using it are trusted and permitted to make the of mechanism, an I2RS Client that is acting as a broker is
particular requests. responsible for determining that applications using it are trusted
and permitted to make the particular requests.
Different levels of integrity, confidentiality, and replay protection Different levels of integrity, confidentiality, and replay protection
are relevant for different aspects of I2RS. The primary are relevant for different aspects of I2RS. The primary
communication channel that is used for client authentication and then communication channel that is used for client authentication and then
used by the client to write data requires integrity, confidentiality used by the client to write data requires integrity, confidentiality
and replay protection. Appropriate selection of a default required and replay protection. Appropriate selection of a default required
transport protocol is the preferred way of meeting these transport protocol is the preferred way of meeting these
requirements. requirements.
Other communications via I2RS may not require integrity, Other communications via I2RS may not require integrity,
confidentiality, and replay protection. For instance, if an I2RS confidentiality, and replay protection. For instance, if an I2RS
Client subscribes to an information stream of prefix announcements Client subscribes to an information stream of prefix announcements
from OSPF, those may require integrity but probably not from OSPF, those may require integrity but probably not
confidentiality or replay protection. Similarly, an information confidentiality or replay protection. Similarly, an information
stream of interface statistics may not even require guaranteed stream of interface statistics may not even require guaranteed
delivery. In Section 7.2, more reasoning for multiple communication delivery. In Section 7.2, additional login regarding multiple
channels is provided. From the security perspective, it is critical communication channels and their use is provided. From the security
to realize that an I2RS Agent may open a new communication channel perspective, it is critical to realize that an I2RS Agent may open a
based upon information provided by an I2RS Client (as described in new communication channel based upon information provided by an I2RS
Section 7.2). For example, a I2RS client may request notifications Client (as described in Section 7.2). For example, an I2RS client
of certain events and the agent will open a communication channel to may request notifications of certain events and the agent will open a
report such events. Therefore, to avoid an indirect attack, such a communication channel to report such events. Therefore, to avoid an
request must be done in the context of an authenticated and indirect attack, such a request must be done in the context of an
authorized client whose communications cannot have been altered. authenticated and authorized client whose communications cannot have
been altered.
4.1. Identity and Authentication 4.1. Identity and Authentication
As discussed above, all control exchanges between the I2RS client and As discussed above, all control exchanges between the I2RS client and
agent should be authenticated and integrity protected (such that the agent should be authenticated and integrity protected (such that the
contents cannot be changed without detection). Further, manipulation contents cannot be changed without detection). Further, manipulation
of the system must be accurately attributable. In an ideal of the system must be accurately attributable. In an ideal
architecture, even information collection and notification should be architecture, even information collection and notification should be
protected; this may be subject to engineering tradeoffs during the protected; this may be subject to engineering tradeoffs during the
design. design.
skipping to change at page 15, line 11 skipping to change at page 15, line 28
identifier that can be provided by the I2RS client to the I2RS agent identifier that can be provided by the I2RS client to the I2RS agent
for purposes of tracking attribution of operations to support for purposes of tracking attribution of operations to support
functionality such as troubleshooting and logging of network changes. functionality such as troubleshooting and logging of network changes.
4.2. Authorization 4.2. Authorization
All operations using I2RS, both observation and manipulation, should All operations using I2RS, both observation and manipulation, should
be subject to appropriate authorization controls. Such authorization be subject to appropriate authorization controls. Such authorization
is based on the identity and assigned role of the I2RS client is based on the identity and assigned role of the I2RS client
performing the operations and the I2RS agent in the network element. performing the operations and the I2RS agent in the network element.
Multiple Identities may use the same role. An identity may utilize Multiple Identities may use the same role(s). As noted in the
several roles. For example, an I2RS client identity may use an MPLS- definition of the identity and role above, if multiple roles are
Monitor role to have a read-scope that includes created MPLS LSPs and associated with an identity then the identity is authorized to
also use a Troubleshooting role to have write access to trigger perform any operation authorized by any of its roles.
active OAM such as LSP-ping.
I2RS Agents, in performing information collection and manipulation, I2RS Agents, in performing information collection and manipulation,
will be acting on behalf of the I2RS clients. As such, each will be acting on behalf of the I2RS clients. As such, each
operation authorization will be based on the lower of the two operation authorization will be based on the lower of the two
permissions of the agent itself and of the authenticated client. The permissions of the agent itself and of the authenticated client. The
mechanism by which this authorization is applied within the device is mechanism by which this authorization is applied within the device is
outside of the scope of I2RS. outside of the scope of I2RS.
The appropriate or necessary level of granularity for scope can The appropriate or necessary level of granularity for scope can
depend upon the particular I2RS Service and the implementation's depend upon the particular I2RS Service and the implementation's
granularity. An approach to a similar access control problem is granularity. An approach to a similar access control problem is
defined in the NetConf Access Control Model (NACM) [RFC6536]; it defined in the NetConf Access Control Model (NACM) [RFC6536]; it
allows arbitrary access to be specified for a data node instance allows arbitrary access to be specified for a data node instance
identifier while defining meaningful manipulable defaults. The identifier while defining meaningful manipulable defaults. The
identity within NACM [RFC6536] can be specify as either a user name identity within NACM [RFC6536] can be specify as either a user name
or a group user name (e.g. Root), and this name is linked a scope or a group user name (e.g. Root), and this name is linked a scope
policy that contained in a set of access control rules. Similarly, policy that is contained in a set of access control rules.
it is expected the I2RS identity links to one role which has a scope Similarly, it is expected the I2RS identity links to one role which
policy specified by a set of access control rules. This scope policy has a scope policy specified by a set of access control rules. This
is can be provided via Local Configuration, exposed as an I2RS scope policy can be provided via Local Configuration, exposed as an
Service for manipulation by authorized clients, or via some other I2RS Service for manipulation by authorized clients, or via some
method (e.g. AAA service) other method (e.g. AAA service)
When an I2RS client is authenticated, its identity is provided to the When an I2RS client is authenticated, its identity is provided to the
I2RS Agent, and this identity links to a role which links to the I2RS Agent, and this identity links to a role which links to the
scope policy. Multiple identities may belong to the same role; for scope policy. Multiple identities may belong to the same role; for
example, such a role might be an Internal-Routes-Monitor that allows example, such a role might be an Internal-Routes-Monitor that allows
reading of the portion of the I2RS RIB associated with IP prefixes reading of the portion of the I2RS RIB associated with IP prefixes
used for internal device addresses in the AS." used for internal device addresses in the AS."
4.3. Client Redundancy 4.3. Client Redundancy
skipping to change at page 23, line 34 skipping to change at page 23, line 34
By taking advantage of extensibility and sub-classing, information By taking advantage of extensibility and sub-classing, information
models can specify use of a basic model that can be replaced by a models can specify use of a basic model that can be replaced by a
more detailed model. more detailed model.
6.4.5. Information Modeling, Device Variation, and Information 6.4.5. Information Modeling, Device Variation, and Information
Relationships Relationships
I2RS depends heavily on information models of the relevant aspects of I2RS depends heavily on information models of the relevant aspects of
the Routing Elements to be manipulated. These models drive the data the Routing Elements to be manipulated. These models drive the data
models and protocol operations for I2RS. It is important that these models and protocol operations for I2RS. It is important that these
informational models deal well with a wide variety of actual information models deal well with a wide variety of actual
implementations of Routing Elements, as seen between different implementations of Routing Elements, as seen between different
products and different vendors. There are three ways that I2RS products and different vendors. There are three ways that I2RS
information models can address these variations: class or type information models can address these variations: class or type
inheritance, optional features, and templating. inheritance, optional features, and templating.
6.4.5.1. Managing Variation: Object Classes/Types and Inheritance 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance
Information modelled by I2RS from a Routing Element can be described Information modelled by I2RS from a Routing Element can be described
in terms of classes or types or object. Different valid inheritance in terms of classes or types or object. Different valid inheritance
definitions can apply. What is appropriate for I2RS to use is not definitions can apply. What is appropriate for I2RS to use is not
skipping to change at page 24, line 49 skipping to change at page 24, line 49
values are set by client and what responses or actions are required values are set by client and what responses or actions are required
by the agent. It is important to indicate what is required or by the agent. It is important to indicate what is required or
optional in client values and agent responses/actions. optional in client values and agent responses/actions.
6.4.5.3. Managing Variation: Templating 6.4.5.3. Managing Variation: Templating
A template is a collection of information to address a problem; it A template is a collection of information to address a problem; it
cuts across the notions of class and object instances. A template cuts across the notions of class and object instances. A template
provides a set of defined values for a set of information fields and provides a set of defined values for a set of information fields and
can specify a set of values that must be provided to complete the can specify a set of values that must be provided to complete the
template. Further, a flexible template scheme may that some of the template. Further, a flexible template scheme may allow some of the
defined values can be over-written. defined values can be over-written.
For instance, assigning traffic to a particular service class might For instance, assigning traffic to a particular service class might
be done by specifying a template Queueing with a parameter to be done by specifying a template Queueing with a parameter to
indicate Gold, Silver, or Best Effort. The details of how that is indicate Gold, Silver, or Best Effort. The details of how that is
carried out are not modeled. This does assume that the necessary carried out are not modeled. This does assume that the necessary
templates are made available on the Routing Element via some templates are made available on the Routing Element via some
mechanism other than I2RS. The idea is that by providing suitable mechanism other than I2RS. The idea is that by providing suitable
templates for tasks that need to be accomplished, with templates templates for tasks that need to be accomplished, with templates
implemented differently for different kinds of Routing Elements, the implemented differently for different kinds of Routing Elements, the
skipping to change at page 25, line 51 skipping to change at page 25, line 51
in the semantic description of the default object. in the semantic description of the default object.
6.4.5.4.2. Correlation Identification 6.4.5.4.2. Correlation Identification
Often, it suffices to indicate in one object that it is related to a Often, it suffices to indicate in one object that it is related to a
second object, without having a strong binding between the two. So second object, without having a strong binding between the two. So
an Identifier is used to represent the relationship. This can be an Identifier is used to represent the relationship. This can be
used to allow for late binding, or a weak binding that does not even used to allow for late binding, or a weak binding that does not even
need to exist. A policy name in an object might indicate that if a need to exist. A policy name in an object might indicate that if a
policy by that name exists, it is to be applied under some policy by that name exists, it is to be applied under some
circumstance. In modeling this is often represented by the type of circumstance. In modeling, this is often represented by the type of
the value. the value.
6.4.5.4.3. Object References 6.4.5.4.3. Object References
Sometimes the relationship between objects is stronger. A valid ARP Sometimes the relationship between objects is stronger. A valid ARP
entry has to point to the active interface over which it was derived. entry has to point to the active interface over which it was derived.
This is the classic meaning of an object reference in programming. This is the classic meaning of an object reference in programming.
It can be used for relationships like containment or dependence. It can be used for relationships like containment or dependence.
This is usually represented by an explicit modeling link. This is usually represented by an explicit modeling link.
skipping to change at page 26, line 52 skipping to change at page 26, line 52
support suitable congestion control mechanisms. The transports support suitable congestion control mechanisms. The transports
chosen should be operator and implementor friendly to ease adoption. chosen should be operator and implementor friendly to ease adoption.
7.2. Communication Channels 7.2. Communication Channels
Multiple communication channels and multiple types of communication Multiple communication channels and multiple types of communication
channels are required. There may be a range of requirements (e.g. channels are required. There may be a range of requirements (e.g.
confidentiality, reliability), and to support the scaling there may confidentiality, reliability), and to support the scaling there may
need to be channels originating from multiple sub-components of a need to be channels originating from multiple sub-components of a
routing element and/or to multiple parts of an I2RS client. All such routing element and/or to multiple parts of an I2RS client. All such
communication channels will use the same higher level protocol. Use communication channels will use the same higher level I2RS protocol.
of additional channels for communication will be coordinated between
the I2RS client and the I2RS agent.
I2RS protocol communication can be delivered in-band via the routing The use of additional channels for communication will be coordinated
between the I2RS client and the I2RS agent using this protocol.
I2RS protocol communication may be delivered in-band via the routing
system's data plane. I2RS protocol communication might be delivered system's data plane. I2RS protocol communication might be delivered
out-of-band via a management interface. Depending on what operations out-of-band via a management interface. Depending on what operations
are requested, it is possible for the I2RS protocol communication to are requested, it is possible for the I2RS protocol communication to
cause the in-band communication channels to stop working; this could cause the in-band communication channels to stop working; this could
cause the I2RS agent to become unreachable across that communication cause the I2RS agent to become unreachable across that communication
channel. channel.
7.3. Capability Negotiation 7.3. Capability Negotiation
The support for different protocol capabilities and I2RS Services The support for different protocol capabilities and I2RS Services
skipping to change at page 30, line 50 skipping to change at page 30, line 50
when there is no dependency across the operation, or where the when there is no dependency across the operation, or where the
client would prefer to sort out the effect of errors on its own. client would prefer to sort out the effect of errors on its own.
In the interest of robustness and clarity of protocol state, the In the interest of robustness and clarity of protocol state, the
protocol will include an explicit reply to modification or write protocol will include an explicit reply to modification or write
operations even when they fully succeed. operations even when they fully succeed.
8. Operational and Manageability Considerations 8. Operational and Manageability Considerations
In order to facilitate troubleshooting of routing elements In order to facilitate troubleshooting of routing elements
implementing I2RS agents, those routing elements should provide for a implementing I2RS agents, the routing elements should provide for a
mechanism to show actively provisioned I2RS state and other I2RS mechanism to show actively provisioned I2RS state and other I2RS
Agent internal information. Note that this information may contain Agent internal information. Note that this information may contain
highly sensitive material subject to the Security Considerations of highly sensitive material subject to the Security Considerations of
any data models implemented by that Agent and thus must be protected any data models implemented by that Agent and thus must be protected
according to those considerations. Preferably, this mechanism should according to those considerations. Preferably, this mechanism should
use a different privileged means other than simply connecting as an use a different privileged means other than simply connecting as an
I2RS client to learn the data. Using a different mechanism should I2RS client to learn the data. Using a different mechanism should
improve traceability and failure management. improve traceability and failure management.
Manageability plays a key aspect in I2RS. Some initial examples Manageability plays a key aspect in I2RS. Some initial examples
skipping to change at page 31, line 49 skipping to change at page 31, line 49
This document includes no request to IANA. This document includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
Significant portions of this draft came from draft-ward-i2rs- Significant portions of this draft came from draft-ward-i2rs-
framework-00 and draft-atlas-i2rs-policy-framework-00. framework-00 and draft-atlas-i2rs-policy-framework-00.
The authors would like to thank Nitin Bahadur, Shane Amante, Ed The authors would like to thank Nitin Bahadur, Shane Amante, Ed
Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott
Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk, Brim, Thomas Narten, Dean Bogdanovic, Tom Petch, Robert Raszuk,
Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin
Wu, Ahmed Abro, Salman Asadullah, and Eric Yu. for their suggestions Wu, Ahmed Abro, Salman Asadullah, Eric Yu, and Deborah Brungard for
and review. their suggestions and review.
11. Informative References 11. Informative References
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-06 (work in progress), January 2015. problem-statement-08 (work in progress), December 2015.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13 Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015. (work in progress), October 2015.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-09 (work in Protocol", draft-ietf-netconf-restconf-09 (work in
 End of changes. 41 change blocks. 
116 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/