tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7921

Informational
Pages: 40
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: I2RS

An Architecture for the Interface to the Routing System

Part 1 of 2, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                          A. Atlas
Request for Comments: 7921                              Juniper Networks
Category: Informational                                       J. Halpern
ISSN: 2070-1721                                                 Ericsson
                                                                S. Hares
                                                                  Huawei
                                                                 D. Ward
                                                           Cisco Systems
                                                               T. Nadeau
                                                                 Brocade
                                                               June 2016


        An Architecture for the Interface to the Routing System

Abstract

   This document describes the IETF architecture for a standard,
   programmatic interface for state transfer in and out of the Internet
   routing system.  It describes the high-level architecture, the
   building blocks of this high-level architecture, and their
   interfaces, with particular focus on those to be standardized as part
   of the Interface to the Routing System (I2RS).

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7921.

[Page 2] 
Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
      1.1. Drivers for the I2RS Architecture ..........................5
      1.2. Architectural Overview .....................................6
   2. Terminology ....................................................11
   3. Key Architectural Properties ...................................13
      3.1. Simplicity ................................................13
      3.2. Extensibility .............................................14
      3.3. Model-Driven Programmatic Interfaces ......................14
   4. Security Considerations ........................................15
      4.1. Identity and Authentication ...............................17
      4.2. Authorization .............................................18
      4.3. Client Redundancy .........................................19
      4.4. I2RS in Personal Devices ..................................19
   5. Network Applications and I2RS Client ...........................19
      5.1. Example Network Application: Topology Manager .............20
   6. I2RS Agent Role and Functionality ..............................20
      6.1. Relationship to Its Routing Element .......................20
      6.2. I2RS State Storage ........................................21
           6.2.1. I2RS Agent Failure .................................21
           6.2.2. Starting and Ending ................................22
           6.2.3. Reversion ..........................................23
      6.3. Interactions with Local Configuration .....................23
           6.3.1. Examples of Local Configuration vs. I2RS
                  Ephemeral Configuration ............................24
      6.4. Routing Components and Associated I2RS Services ...........26
           6.4.1. Routing and Label Information Bases ................28
           6.4.2. IGPs, BGP, and Multicast Protocols .................28
           6.4.3. MPLS ...............................................29
           6.4.4. Policy and QoS Mechanisms ..........................29
           6.4.5. Information Modeling, Device Variation, and
                  Information Relationships ..........................29
                  6.4.5.1. Managing Variation: Object
                           Classes/Types and Inheritance .............29
                  6.4.5.2. Managing Variation: Optionality ...........30
                  6.4.5.3. Managing Variation: Templating ............31
                  6.4.5.4. Object Relationships ......................31
                           6.4.5.4.1. Initialization .................31
                           6.4.5.4.2. Correlation Identification .....32
                           6.4.5.4.3. Object References ..............32
                           6.4.5.4.4. Active References ..............32
   7. I2RS Client Agent Interface ....................................32
      7.1. One Control and Data Exchange Protocol ....................32
      7.2. Communication Channels ....................................33
      7.3. Capability Negotiation ....................................33
      7.4. Scope Policy Specifications ...............................34
      7.5. Connectivity ..............................................34

Top      ToC       Page 4 
      7.6. Notifications .............................................35
      7.7. Information Collection ....................................35
      7.8. Multi-headed Control ......................................36
      7.9. Transactions ..............................................36
   8. Operational and Manageability Considerations ...................37
   9. References .....................................................38
      9.1. Normative References ......................................38
      9.2. Informative References ....................................38
   Acknowledgements ..................................................39
   Authors' Addresses ................................................40

1.  Introduction

   Routers that form the Internet routing infrastructure maintain state
   at various layers of detail and function.  For example, a typical
   router maintains a Routing Information Base (RIB) and implements
   routing protocols such as OSPF, IS-IS, and BGP to exchange
   reachability information, topology information, protocol state, and
   other information about the state of the network with other routers.

   Routers convert all of this information into forwarding entries,
   which are then used to forward packets and flows between network
   elements.  The forwarding plane and the specified forwarding entries
   then contain active state information that describes the expected and
   observed operational behavior of the router and that is also needed
   by the network applications.  Network-oriented applications require
   easy access to this information to learn the network topology, to
   verify that programmed state is installed in the forwarding plane, to
   measure the behavior of various flows, routes or forwarding entries,
   as well as to understand the configured and active states of the
   router.  Network-oriented applications also require easy access to an
   interface, which will allow them to program and control state related
   to forwarding.

   This document sets out an architecture for a common, standards-based
   interface to this information.  This Interface to the Routing System
   (I2RS) facilitates control and observation of the routing-related
   state (for example, a Routing Element RIB manager's state), as well
   as enabling network-oriented applications to be built on top of
   today's routed networks.  The I2RS is a programmatic asynchronous
   interface for transferring state into and out of the Internet routing
   system.  This I2RS architecture recognizes that the routing system
   and a router's Operating System (OS) provide useful mechanisms that
   applications could harness to accomplish application-level goals.
   These network-oriented applications can leverage the I2RS
   programmatic interface to create new ways to combine retrieving
   Internet routing data, analyzing this data, and setting state within
   routers.

Top      ToC       Page 5 
   Fundamental to I2RS are clear data models that define the semantics
   of the information that can be written and read.  I2RS provides a way
   for applications to customize network behavior while leveraging the
   existing routing system as desired.  I2RS provides a framework for
   applications (including controller applications) to register and to
   request the appropriate information for each particular application.

   Although the I2RS architecture is general enough to support
   information and data models for a variety of data, and aspects of the
   I2RS solution may be useful in domains other than routing, I2RS and
   this document are specifically focused on an interface for routing
   data.

   Security is a concern for any new I2RS.  Section 4 provides an
   overview of the security considerations for the I2RS architecture.
   The detailed requirements for I2RS protocol security are contained in
   [I2RS-PROT-SEC], and the detailed security requirements for
   environment in which the I2RS protocol exists are contained in
   [I2RS-ENV-SEC].

1.1.  Drivers for the I2RS Architecture

   There are four key drivers that shape the I2RS architecture.  First
   is the need for an interface that is programmatic and asynchronous
   and that offers fast, interactive access for atomic operations.
   Second is the access to structured information and state that is
   frequently not directly configurable or modeled in existing
   implementations or configuration protocols.  Third is the ability to
   subscribe to structured, filterable event notifications from the
   router.  Fourth, the operation of I2RS is to be data-model-driven to
   facilitate extensibility and provide standard data models to be used
   by network applications.

   I2RS is described as an asynchronous programmatic interface, the key
   properties of which are described in Section 5 of [RFC7920].

   The I2RS architecture facilitates obtaining information from the
   router.  The I2RS architecture provides the ability to not only read
   specific information, but also to subscribe to targeted information
   streams, filtered events, and thresholded events.

   Such an interface also facilitates the injection of ephemeral state
   into the routing system.  Ephemeral state on a router is the state
   that does not survive the reboot of a routing device or the reboot of
   the software handling the I2RS software on a routing device.  A non-
   routing protocol or application could inject state into a routing
   element via the state-insertion functionality of I2RS and that state
   could then be distributed in a routing or signaling protocol and/or

Top      ToC       Page 6 
   be used locally (e.g., to program the co-located forwarding plane).
   I2RS will only permit modification of state that would be possible to
   modify via Local Configuration; no direct manipulation of protocol-
   internal, dynamically determined data is envisioned.

1.2.  Architectural Overview

   Figure 1 shows the basic architecture for I2RS between applications
   using I2RS, their associated I2RS clients, and I2RS agents.
   Applications access I2RS services through I2RS clients.  A single
   I2RS client can provide access to one or more applications.  This
   figure also shows the types of data models associated with the
   routing system (dynamic configuration, static configuration, Local
   Configuration, and routing and signaling configuration) that the I2RS
   agent data models may access or augment.

   Figure 1 is similar to Figure 1 in [RFC7920], but the figure in this
   document shows additional detail on how the applications utilize I2RS
   clients to interact with I2RS agents.  It also shows a logical view
   of the data models associated with the routing system rather than a
   functional view (RIB, Forwarding Information Base (FIB), topology,
   policy, routing/signaling protocols, etc.)

   In Figure 1, Clients A and B each provide access to a single
   application (Applications A and B, respectively), while Client P
   provides access to multiple applications.

   Applications can access I2RS services through local or remote
   clients.  A local client operates on the same physical box as the
   routing system.  In contrast, a remote client operates across the
   network.  In the figure, Applications A and B access I2RS services
   through 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 Figure 1,
   Clients B and P access I2RS agents 1 and 2.  Likewise, an I2RS agent
   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
   provides services to only Clients B and P.

   I2RS agents and clients communicate with one another using an
   asynchronous protocol.  Therefore, a single client can post multiple
   simultaneous requests, either to a single agent or to multiple
   agents.  Furthermore, an agent can process multiple requests, either
   from a single client or from multiple clients, simultaneously.

Top      ToC       Page 7 
   The I2RS agent provides read and write access to selected data on the
   routing element that are organized into I2RS services.  Section 4
   describes how access is mediated by authentication and access control
   mechanisms.  Figure 1 shows I2RS agents being able to write ephemeral
   static state (e.g., RIB entries) and to read from dynamic static
   (e.g., MPLS Label Switched Path Identifier (LSP-ID) or number of
   active BGP peers).

   In addition to read and write access, the I2RS agent allows clients
   to subscribe to different types of notifications about events
   affecting different object instances.  One example of a notification
   of such an event (which is unrelated to an object creation,
   modification or deletion) is when a next hop in the RIB is resolved
   in a way that allows it to be used by a RIB manager for installation
   in the forwarding plane as part of a particular route.  Please see
   Sections 7.6 and 7.7 for details.

   The scope of I2RS is to define the interactions between the I2RS
   agent and the I2RS client and the associated proper behavior of the
   I2RS agent and I2RS client.

Top      ToC       Page 8 
        ******************   *****************  *****************
        *  Application C *   * Application D *  * Application E *
        ******************   *****************  *****************
                 ^                  ^                   ^
                 |--------------|   |    |--------------|
                                |   |    |
                                v   v    v
                              ***************
                              *  Client P   *
                              ***************
                                   ^     ^
                                   |     |-------------------------|
         ***********************   |      ***********************  |
         *    Application A    *   |      *    Application B    *  |
         *                     *   |      *                     *  |
         *  +----------------+ *   |      *  +----------------+ *  |
         *  |   Client A     | *   |      *  |   Client B     | *  |
         *  +----------------+ *   |      *  +----------------+ *  |
         ******* ^ *************   |      ***** ^ ****** ^ ******  |
                 |                 |            |        |         |
                 |   |-------------|            |        |   |-----|
                 |   |   -----------------------|        |   |
                 |   |   |                               |   |
    ************ v * v * v *********   ***************** v * v ********
    *  +---------------------+     *   *  +---------------------+     *
    *  |     Agent 1         |     *   *  |    Agent 2          |     *
    *  +---------------------+     *   *  +---------------------+     *
    *     ^        ^  ^   ^        *   *     ^        ^  ^   ^        *
    *     |        |  |   |        *   *     |        |  |   |        *
    *     v        |  |   v        *   *     v        |  |   v        *
    * +---------+  |  | +--------+ *   * +---------+  |  | +--------+ *
    * | Routing |  |  | | Local  | *   * | Routing |  |  | | Local  | *
    * |   and   |  |  | | Config | *   * |   and   |  |  | | Config | *
    * |Signaling|  |  | +--------+ *   * |Signaling|  |  | +--------+ *
    * +---------+  |  |         ^  *   * +---------+  |  |         ^  *
    *    ^         |  |         |  *   *    ^         |  |         |  *
    *    |    |----|  |         |  *   *    |    |----|  |         |  *
    *    v    |       v         v  *   *    v    |       v         v  *
    *  +----------+ +------------+ *   *  +----------+ +------------+ *
    *  |  Dynamic | |   Static   | *   *  |  Dynamic | |   Static   | *
    *  |  System  | |   System   | *   *  |  System  | |   System   | *
    *  |  State   | |   State    | *   *  |  State   | |   State    | *
    *  +----------+ +------------+ *   *  +----------+ +------------+ *
    *                              *   *                              *
    *  Routing Element 1           *   *  Routing Element 2           *
    ********************************   ********************************

             Figure 1: Architecture of I2RS Clients and Agents

Top      ToC       Page 9 
   Routing Element:  A Routing Element implements some subset of the
      routing system.  It does not need to have a forwarding plane
      associated with it.  Examples of Routing Elements can include:

      *  A router with a forwarding plane and RIB Manager that runs
         IS-IS, OSPF, BGP, PIM, etc.,

      *  A BGP speaker acting as a Route Reflector,

      *  A Label Switching Router (LSR) that implements RSVP-TE,
         OSPF-TE, and the Path Computation Element (PCE) Communication
         Protocol (PCEP) and has a forwarding plane and associated RIB
         Manager, and

      *  A server that runs IS-IS, OSPF, and BGP and uses Forwarding and
         Control Element Separation (ForCES) to control a remote
         forwarding plane.

      A Routing Element may be locally managed, whether via command-line
      interface (CLI), SNMP, or the Network Configuration Protocol
      (NETCONF).

   Routing and Signaling:  This block represents that portion of the
      Routing Element that implements part of the Internet routing
      system.  It includes not merely standardized protocols (i.e.,
      IS-IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB
      Manager layer.

   Local Configuration:  The black box behavior for interactions between
      the ephemeral state that I2RS installs into the routing element;
      Local Configuration is defined by this document and the behaviors
      specified by the I2RS protocol.

   Dynamic System State:  An I2RS agent needs access to state on a
      routing element beyond what is contained in the routing subsystem.
      Such state may include various counters, statistics, flow data,
      and local events.  This is the subset of operational state that is
      needed by network applications based on I2RS that is not contained
      in the routing and signaling information.  How this information is
      provided to the I2RS agent is out of scope, but the standardized
      information and data models for what is exposed are part of I2RS.

   Static System State:  An I2RS agent needs access to static state on a
      routing element beyond what is contained in the routing subsystem.
      An example of such state is specifying queueing behavior for an
      interface or traffic.  How the I2RS agent modifies or obtains this
      information is out of scope, but the standardized information and
      data models for what is exposed are part of I2RS.

Top      ToC       Page 10 
   I2RS agent:  See the definition in Section 2.

   Application:  A network application that needs to observe the network
      or manipulate the network to achieve its service requirements.

   I2RS client:  See the definition in Section 2.

   As can be seen in Figure 1, an I2RS client can communicate with
   multiple I2RS agents.  Similarly, an I2RS agent may communicate with
   multiple I2RS clients -- whether to respond to their requests, to
   send notifications, etc.  Timely notifications are critical so that
   several simultaneously operating applications have up-to-date
   information on the state of the network.

   As can also be seen in Figure 1, an I2RS agent may communicate with
   multiple clients.  Each client may send the agent a variety of write
   operations.  In order to keep the protocol simple, two clients should
   not attempt to write (modify) the same piece of information on an
   I2RS agent.  This is considered an error.  However, such collisions
   may happen and Section 7.8 ("Multi-headed Control") describes how the
   I2RS agent resolves collision by first utilizing priority to resolve
   collisions and second by servicing the requests in a first-in, first-
   served basis.  The I2RS architecture includes this definition of
   behavior for this case simply for predictability, not because this is
   an intended result.  This predictability will simplify error handling
   and suppress oscillations.  If additional error cases beyond this
   simple treatment are required, these error cases should be resolved
   by the network applications and management systems.

   In contrast, although multiple I2RS clients may need to supply data
   into the same list (e.g., a prefix or filter list), this is not
   considered an error and must be correctly handled.  The nuances so
   that writers do not normally collide should be handled in the
   information models.

   The architectural goal for I2RS is that such errors should produce
   predictable behaviors and be reportable to interested clients.  The
   details of the associated policy is discussed in Section 7.8.  The
   same policy mechanism (simple priority per I2RS client) applies to
   interactions between the I2RS agent and the CLI/SNMP/NETCONF as
   described in Section 6.3.

   In addition, it must be noted that there may be indirect interactions
   between write operations.  A basic example of this is when two
   different but overlapping prefixes are written with different
   forwarding behavior.  Detection and avoidance of such interactions is
   outside the scope of the I2RS work and is left to agent design and
   implementation.

Top      ToC       Page 11 
2.  Terminology

   The following terminology is used in this document.

   agent or I2RS agent:   An I2RS agent provides the supported I2RS
      services from the local system's routing subsystems by interacting
      with the routing element to provide specified behavior.  The I2RS
      agent understands the I2RS protocol and can be contacted by I2RS
      clients.

   client or I2RS client:   A client implements the I2RS protocol, uses
      it to communicate with I2RS agents, and uses the I2RS services to
      accomplish a task.  It interacts with other elements of the
      policy, provisioning, and configuration system by means outside of
      the scope of the I2RS effort.  It interacts with the I2RS agents
      to collect information from the routing and forwarding system.
      Based on the information and the policy-oriented interactions, the
      I2RS client may also interact with I2RS agents to modify the state
      of their associated routing systems to achieve operational goals.
      An I2RS client can be seen as the part of an application that uses
      and supports I2RS and could be a software library.

   service or I2RS service:   For the purposes of I2RS, a service refers
      to a set of related state access functions together with the
      policies that control their usage.  The expectation is that a
      service will be represented by a data model.  For instance, 'RIB
      service' could be an example of a service that gives access to
      state held in a device's RIB.

   read scope:   The read scope of an I2RS client within an I2RS agent
      is the set of information that the I2RS client is authorized to
      read within the I2RS agent.  The read scope specifies the access
      restrictions to both see the existence of data and read the value
      of that data.

   notification scope:   The notification scope is the set of events and
      associated information that the I2RS client can request be pushed
      by the I2RS agent.  I2RS clients have the ability to register for
      specific events and information streams, but must be constrained
      by the access restrictions associated with their notification
      scope.

   write scope:   The write scope is the set of field values that the
      I2RS client is authorized to write (i.e., add, modify or delete).
      This access can restrict what data can be modified or created, and
      what specific value sets and ranges can be installed.

Top      ToC       Page 12 
   scope:   When unspecified as either read scope, write scope, or
      notification scope, the term "scope" applies to the read scope,
      write scope, and notification scope.

   resources:   A resource is an I2RS-specific use of memory, storage,
      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
      context of a particular agent may be constrained based upon the
      client's security role.  An example of such a resource could
      include the number of notifications registered for.  These are not
      protocol-specific resources or network-specific resources.

   role or security role:   A security role specifies the scope,
      resources, priorities, etc., that a client or agent has.  If an
      identity has multiple roles in the security system, the identity
      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.  State can be attributed to a particular identity.  It
      is possible for multiple communication channels to use the same
      identity; in that case, the assumption is that the associated
      client is coordinating such communication.

   identity and scope:   A single identity can be associated with
      multiple roles.  Each role has its own scope, and an identity
      associated with multiple roles can use the combined scope of all
      its roles.  More formally, each identity has:

      *  a read scope that is the logical OR of the read scopes
         associated with its roles,

      *  a write scope that is the logical OR of the write scopes
         associated with its roles, and

      *  a notification scope that is the logical OR of the notification
         scopes associated with its roles.

   secondary identity:   An I2RS client may supply a secondary opaque
      identifier for a secondary identity that is not interpreted by the
      I2RS agent.  An example of the use of the secondary opaque
      identifier is when the I2RS client is a go-between for multiple
      applications and it is necessary to track which application has
      requested a particular operation.

Top      ToC       Page 13 
   ephemeral data:   Ephemeral data is data that does not persist across
      a reboot (software or hardware) or a power on/off condition.
      Ephemeral data can be configured data or data recorded from
      operations of the router.  Ephemeral configuration data also has
      the property that a system cannot roll back to a previous
      ephemeral configuration state.

   group:   The NETCONF Access Control Model [RFC6536] uses the term
      "group" in terms of an administrative group that supports the
      well-established distinction between a root account and other
      types of less-privileged conceptual user accounts.  "Group" still
      refers to a single identity (e.g., root) that is shared by a group
      of users.

   routing system/subsystem:   A routing system or subsystem is a set of
      software and/or hardware that determines where packets are
      forwarded.  The I2RS agent is a component of a routing system.
      The term "packets" may be qualified to be layer 1 frames, layer 2
      frames, or layer 3 packets.  The phrase "Internet routing system"
      implies the packets that have IP as layer 3.  A routing
      "subsystem" indicates that the routing software/hardware is only
      the subsystem of another larger system.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Key Architectural Properties

   Several key architectural properties for the I2RS protocol are
   elucidated below (simplicity, extensibility, and model-driven
   programmatic interfaces).  However, some architectural properties
   such as performance and scaling are not described below because they
   are discussed in [RFC7920] and because they may vary based on the
   particular use cases.

3.1.  Simplicity

   There have been many efforts over the years to improve access to the
   information available to the routing and forwarding system.  Making
   such information visible and usable to network management and
   applications has many well-understood benefits.  There are two
   related challenges in doing so.  First, the quantity and diversity of
   information potentially available is very large.  Second, the
   variation both in the structure of the data and in the kinds of
   operations required tends to introduce protocol complexity.

Top      ToC       Page 14 
   While the types of operations contemplated here are complex in their
   nature, it is critical that I2RS be easily deployable and robust.
   Adding complexity beyond what is needed to satisfy well known and
   understood requirements would hinder the ease of implementation, the
   robustness of the protocol, and the deployability of the protocol.
   Overly complex data models tend to ossify information sets by
   attempting to describe and close off every possible option,
   complicating extensibility.

   Thus, one of the key aims for I2RS is to keep the protocol and
   modeling architecture simple.  So for each architectural component or
   aspect, we ask ourselves, "Do we need this complexity, or is the
   behavior merely nice to have?"  If we need the complexity, we should
   ask ourselves, "Is this the simplest way to provide this complexity
   in the I2RS external interface?"

3.2.  Extensibility

   Extensibility of the protocol and data model is very important.  In
   particular, given the necessary scope limitations of the initial
   work, it is critical that the initial design include strong support
   for extensibility.

   The scope of I2RS work is being designed in phases to provide
   deliverable and deployable results at every phase.  Each phase will
   have a specific set of requirements, and the I2RS protocol and data
   models will progress toward these requirements.  Therefore, it is
   clearly desirable for the I2RS data models to be easily and highly
   extensible to represent additional aspects of the network elements or
   network systems.  It should be easy to integrate data models from
   I2RS with other data.  This reinforces the criticality of designing
   the data models to be highly extensible, preferably in a regular and
   simple fashion.

   The I2RS Working Group is defining operations for the I2RS protocol.
   It would be optimistic to assume that more and different ones may not
   be needed when the scope of I2RS increases.  Thus, it is important to
   consider extensibility not only of the underlying services' data
   models, but also of the primitives and protocol operations.

3.3.  Model-Driven Programmatic Interfaces

   A critical component of I2RS is the standard information and data
   models with their associated semantics.  While many components of the
   routing system are standardized, associated data models for them are
   not yet available.  Instead, each router uses different information,
   different mechanisms, and different CLI, which makes a standard
   interface for use by applications extremely cumbersome to develop and

Top      ToC       Page 15 
   maintain.  Well-known data modeling languages exist and may be used
   for defining the data models for I2RS.

   There are several key benefits for I2RS in using model-driven
   architecture and protocol(s).  First, it allows for data-model-
   focused processing of management data that provides modular
   implementation in I2RS clients and I2RS agents.  The I2RS client only
   needs to implement the models the I2RS client is able to access.  The
   I2RS agent only needs to implement the data models the I2RS agent
   supports.

   Second, tools can automate checking and manipulating data; this is
   particularly valuable for both extensibility and for the ability to
   easily manipulate and check proprietary data models.

   The different services provided by I2RS can correspond to separate
   data models.  An I2RS agent may indicate which data models are
   supported.

   The purpose of the data model is to provide a definition of the
   information regarding the routing system that can be used in
   operational networks.  If 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

   This I2RS architecture describes interfaces that clearly require
   serious consideration of security.  As an architecture, I2RS has been
   designed to reuse existing protocols that carry network management
   information.  Two of the existing protocols that are being reused for
   the I2RS protocol version 1 are NETCONF [RFC6241] and RESTCONF
   [RESTCONF].  Additional protocols may be reused in future versions of
   the I2RS protocol.

   The I2RS protocol design process will be to specify additional
   requirements (including security) for the existing protocols in order
   in order to support the I2RS architecture.  After an existing
   protocol (e.g., NETCONF or RESTCONF) has been altered to fit the I2RS
   requirements, then it will be reviewed to determine if it meets these
   requirements.  During this review of changes to existing protocols to
   serve the I2RS architecture, an in-depth security review of the
   revised protocol should be done.

   Due to the reuse strategy of the I2RS architecture, this security
   section describes the assumed security environment for I2RS with
   additional details on a) identity and authentication, b)
   authorization, and c) client redundancy.  Each protocol proposed for

Top      ToC       Page 16 
   inclusion as an I2RS protocol will need to be evaluated for the
   security constraints of the protocol.  The detailed requirements for
   the I2RS protocol and the I2RS security environment will be defined
   within these global security environments.

   The I2RS protocol security requirements for I2RS protocol version 1
   are contained in [I2RS-PROT-SEC], and the global I2RS security
   environment requirements are contained [I2RS-ENV-SEC].

   First, here is a brief description of the assumed security
   environment for I2RS.  The I2RS agent associated with a Routing
   Element is a trusted part of that Routing Element.  For example, it
   may be part of a vendor-distributed signed software image for the
   entire Routing Element, or it may be a trusted signed application
   that an operator has installed.  The I2RS agent is assumed to have a
   separate authentication and authorization channel by which it can
   validate both the identity and permissions associated with an I2RS
   client.  To support numerous and speedy interactions between the I2RS
   agent and I2RS client, it is assumed that the I2RS agent can also
   cache that particular I2RS clients are trusted and their associated
   authorized scope.  This implies that the permission information may
   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
   can notify the I2RS agent of changes.

   Mutual authentication between the I2RS client and I2RS agent is
   required.  An I2RS client must be able to trust that the I2RS agent
   is attached to the relevant Routing Element so that write/modify
   operations are correctly applied and so that information received
   from the I2RS agent can be trusted by the I2RS client.

   An I2RS client is not automatically trustworthy.  Each I2RS client is
   associated with an identity with a set of scope limitations.
   Applications using an I2RS client should be aware that the scope
   limitations of an I2RS client are based on its identity (see
   Section 4.1) and the assigned role that the identity has.  A role
   sets specific authorization limits on the actions that an I2RS client
   can successfully request of an I2RS agent (see Section 4.2).  For
   example, one I2RS client may only be able to read a static route
   table, but another client may be able add an ephemeral route to the
   static route table.

   If the I2RS client is acting as a broker for multiple applications,
   then managing the security, authentication, and authorization for
   that communication is out of scope; nothing prevents the broker from
   using the I2RS protocol and a separate authentication and
   authorization channel from being used.  Regardless of the mechanism,
   an I2RS client that is acting as a broker is responsible for

Top      ToC       Page 17 
   determining that applications using it are trusted and permitted to
   make the particular requests.

   Different levels of integrity, confidentiality, and replay protection
   are relevant for different aspects of I2RS.  The primary
   communication channel that is used for client authentication and then
   used by the client to write data requires integrity, confidentiality
   and replay protection.  Appropriate selection of a default required
   transport protocol is the preferred way of meeting these
   requirements.

   Other communications via I2RS may not require integrity,
   confidentiality, and replay protection.  For instance, if an I2RS
   client subscribes to an information stream of prefix announcements
   from OSPF, those may require integrity but probably not
   confidentiality or replay protection.  Similarly, an information
   stream of interface statistics may not even require guaranteed
   delivery.  In Section 7.2, additional logins regarding multiple
   communication channels and their use is provided.  From the security
   perspective, it is critical to realize that an I2RS agent may open a
   new communication channel based upon information provided by an I2RS
   client (as described in Section 7.2).  For example, an I2RS client
   may request notifications of certain events, and the agent will open
   a communication channel to report such events.  Therefore, to avoid
   an indirect attack, such a request must be done in the context of an
   authenticated and authorized client whose communications cannot have
   been altered.

4.1.  Identity and Authentication

   As discussed above, all control exchanges between the I2RS client and
   agent should be authenticated and integrity-protected (such that the
   contents cannot be changed without detection).  Further, manipulation
   of the system must be accurately attributable.  In an ideal
   architecture, even information collection and notification should be
   protected; this may be subject to engineering trade-offs during the
   design.

   I2RS clients may be operating on behalf of other applications.  While
   those applications' identities are not needed for authentication or
   authorization, each application should have a unique opaque
   identifier that can be provided by the I2RS client to the I2RS agent
   for purposes of tracking attribution of operations to an application
   identifier (and from that to the application's identity).  This
   tracking of operations to an application supports I2RS functionality
   for tracing actions (to aid troubleshooting in routers) and logging
   of network changes.

Top      ToC       Page 18 
4.2.  Authorization

   All operations using I2RS, both observation and manipulation, should
   be subject to appropriate authorization controls.  Such authorization
   is based on the identity and assigned role of the I2RS client
   performing the operations and the I2RS agent in the network element.
   Multiple identities may use the same role(s).  As noted in the
   definitions of "identity" and "role" above, if multiple roles are
   associated with an identity then the identity is authorized to
   perform any operation authorized by any of its roles.

   I2RS agents, in performing information collection and manipulation,
   will be acting on behalf of the I2RS clients.  As such, each
   operation authorization will be based on the lower of the two
   permissions of the agent itself and of the authenticated client.  The
   mechanism by which this authorization is applied within the device is
   outside of the scope of I2RS.

   The appropriate or necessary level of granularity for scope can
   depend upon the particular I2RS service and the implementation's
   granularity.  An approach to a similar access control problem is
   defined in the NETCONF Access Control Model (NACM) [RFC6536]; it
   allows arbitrary access to be specified for a data node instance
   identifier while defining meaningful manipulable defaults.  The
   identity within NACM [RFC6536] can be specified as either a user name
   or a group user name (e.g., Root), and this name is linked a scope
   policy that is contained in a set of access control rules.
   Similarly, it is expected the I2RS identity links to one role that
   has a scope policy specified by a set of access control rules.  This
   scope policy can be provided via Local Configuration, exposed as an
   I2RS service for manipulation by authorized clients, or via some
   other method (e.g., Authentication, Authorization, and Accounting
   (AAA) service)

   While the I2RS agent allows access based on the I2RS client's scope
   policy, this does not mean the access is required to arrive on a
   particular transport connection or from a particular I2RS client by
   the I2RS architecture.  The operator-applied scope policy may or may
   not restrict the transport connection or the identities that can
   access a local I2RS agent.

   When an I2RS client is authenticated, its identity is provided to the
   I2RS agent, and this identity links to a role that links to the scope
   policy.  Multiple identities may belong to the same role; for
   example, such a role might be an Internal-Routes-Monitor that allows
   reading of the portion of the I2RS RIB associated with IP prefixes
   used for internal device addresses in the AS.

Top      ToC       Page 19 
4.3.  Client Redundancy

   I2RS must support client redundancy.  At the simplest, this can be
   handled by having a primary and a backup network application that
   both use the same client identity and can successfully authenticate
   as such.  Since I2RS does not require a continuous transport
   connection and supports multiple transport sessions, this can provide
   some basic redundancy.  However, it does not address the need for
   troubleshooting and logging of network changes to be informed about
   which network application is actually active.  At a minimum, basic
   transport information about each connection and time can be logged
   with the identity.

4.4.  I2RS in Personal Devices

   If an I2RS agent or I2RS client is tightly correlated with a person
   (such as if an I2RS agent is running on someone's phone to control
   tethering), then this usage can raise privacy issues, over and above
   the security issues that normally need to be handled in I2RS.  One
   example of an I2RS interaction that could raise privacy issues is if
   the I2RS interaction enabled easier location tracking of a person's
   phone.  The I2RS protocol and data models should consider if privacy
   issues can arise when clients or agents are used for such use cases.

5.  Network Applications and I2RS Client

   I2RS is expected to be used by network-oriented applications in
   different architectures.  While the interface between a network-
   oriented application and the I2RS client is outside the scope of
   I2RS, considering the different architectures is important to
   sufficiently specify I2RS.

   In the simplest architecture of direct access, a network-oriented
   application has an I2RS client as a library or driver for
   communication with routing elements.

   In the broker architecture, multiple network-oriented applications
   communicate in an unspecified fashion to a broker application that
   contains an I2RS client.  That broker application requires additional
   functionality for authentication and authorization of the network-
   oriented applications; such functionality is out of scope for I2RS,
   but similar considerations to those described in Section 4.2 do
   apply.  As discussed in Section 4.1, the broker I2RS client should
   determine distinct opaque identifiers for each network-oriented
   application that is using it.  The broker I2RS client can pass along
   the appropriate value as a secondary identifier, which can be used
   for tracking attribution of operations.

Top      ToC       Page 20 
   In a third architecture, a routing element or network-oriented
   application that uses an I2RS client to access services on a
   different routing element may also contain an I2RS agent to provide
   services to other network-oriented applications.  However, where the
   needed information and data models for those services differs from
   that of a conventional routing element, those models are, at least
   initially, out of scope for I2RS.  The following section describes an
   example of such a network application.

5.1.  Example Network Application: Topology Manager

   A Topology Manager includes an I2RS client that uses the I2RS data
   models and protocol to collect information about the state of the
   network by communicating directly with one or more I2RS agents.  From
   these I2RS agents, the Topology Manager collects routing
   configuration and operational data, such as interface and Label
   Switched Path (LSP) information.  In addition, the Topology Manager
   may collect link-state data in several ways -- via I2RS models, by
   peering with BGP-LS [RFC7752], or by listening into the IGP.

   The set of functionality and collected information that is the
   Topology Manager may be embedded as a component of a larger
   application, such as a path computation application.  As a stand-
   alone application, the Topology Manager could be useful to other
   network applications by providing a coherent picture of the network
   state accessible via another interface.  That interface might use the
   same I2RS protocol and could provide a topology service using
   extensions to the I2RS data models.



(page 20 continued on part 2)

Next RFC Part