One document matched: draft-hares-i2rs-security-01.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4785.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY I-D.ietf-i2rs-problem SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.xml">
<!ENTITY I-D.keyupate-i2rs-bgp-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.keyupate-i2rs-bgp-usecases.xml">
<!ENTITY I-D.clarke-i2rs-traceability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-clarke-i2rs-traceability-02.xml">
<!ENTITY I-D.hares-i2rs-info-model-policy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-policy.xml">
<!ENTITY I-D.ji-i2rs-usecases-ccne-service SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ji-i2rs-usecases-ccne-service.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2rs-security-01" ipr="trust200902">
<front>
<title abbrev="I2RS Security">I2RS Security Considerations</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Scott Brim" initials="S" surname="Brim">
<organization>Consultant</organization>
<address>
<email>scott.brim@gmail.com</email>
</address>
</author>
<author fullname="Nancy Cam-Winget" initials="N" surname="Cam-Winget">
<organization>Cisco</organization>
<address>
<email>ncamwing@cisco.com</email>
</address>
</author>
<author fullname="Joel Halpern" initials="J." surname="Halpern">
<organization>Ericcson</organization>
<address>
<email>joel.halpern@ericsson.com</email>
</address>
</author>
<author fullname="DaCheng Zhang" initials="D" surname="Zhang">
<organization>Huawei</organization>
<address>
<email>zhangdacheng@huawei.com </email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Ahmed Abro" initials="A." surname="Abro">
<organization>Cisco</organization>
<address>
<email>aabro@cisco.com</email>
</address>
</author>
<author fullname="Salman Asadullah" initials="S." surname="Asadullah">
<organization>Cisco</organization>
<address>
<email>sasad@cisco.com</email>
</address>
</author>
<author fullname="Joel Halpern" initials="J." surname="Halpern">
<organization>Ericcson</organization>
<address>
<email>joel.halpern@ericsson.com</email>
</address>
</author>
<author fullname="Eric Yu" initials="E." surname="Yu">
<organization>Cisco</organization>
<address>
<email>eyu@cisco.com</email>
</address>
</author>
<date year="2014" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t> This presents an expansion of the security
architecture found in the i2rs architecture.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Interface to the Routing System (I2RS)
provides read and write access to the information and state within the
routing process and configuration process (as illustrated in the diagram in the architecture
document within routing elements. The I2RS client
<xref target="I-D.ietf-i2rs-architecture" />
interacts with one or more I2RS agents to collect information
from network routing systems. This security architecture expands on
the security issues involved in the I2RS protocol's message exchange
between the I2RS client and the I2RS agent which are
described in <xref target="I-D.ietf-i2rs-architecture" />. </t>
</section>
<section title="Definitions" >
<t>This document utilizes the definitions found in the
following drafts: <xref target="RFC4949" />, and <xref target="I-D.ietf-i2rs-architecture" />.
</t>
<t> Specifically, this document utilizes the following definitions:
<list style="hanging">
<t hangText="Access control"><vspace blankLines="1"/> <xref target="RFC4949" />
describes access control as: a) protection of system resources against unauthorized access,
b) process controlled by a security policy that permits access only by authorized entities
(users, programs, process, or others) according to that policy, c) preventing unauthorized
use of resource, d) using human controls to identify or admit properly authorized people to a
SCIF, and e) limitations on between subjects and objections in a system. I2RS focuses on role-based
access control (RBAC). </t>
<t hangText="Authentication"><vspace blankLines="1"/> <xref target="RFC4949" />
describes authentication as the process of verifying (i.e., establishing the truth of)
an attribute value claimed by or for a system entity or system resource. Authentication
has two steps: identify and verify. </t>
<t hangText="Data Confidentiality"><vspace blankLines="1"/> <xref target="RFC4949" />
describes data confidentiality has having two properties: a) data is not disclosed to
system entities unless they have been authorized to know, and b) data is not
disclosed to unauthorized individuals, entities or processes. The key point is that
confidentiality implies that the originator has the ability to authorize where the
information goes. Confidentiality is important for both read and write scope of the
data.</t>
<t hangText="Data confidentiality service"><vspace blankLines="1"/> <xref target="RFC4949" />
also describes data confidentiality service as a security service that protects data
against unauthorized disclosure. Please note that an operator can designate
all people are authorized to view a piece of data which would mean a data confidentiality service
would be essentially a null function. </t>
<t hangText="Data Privacy"><vspace blankLines="1"/> <xref target="RFC4949" /> describes
data privacy as a synonym for data confidentiality. This I2RS document will utilize
data privacy as a synonym for data confidentiality. </t>
<t hangText="Mutual Authentication"><vspace blankLines="1"/> <xref target="RFC4949" />
implies that mutual authentication exists between two interacting system
entities. Mutual authentication in I2RS implies that both sides move from
a state of mutual suspicion to mutually authenticated communication after having
been identified and validated. </t>
<t hangText="Mutual Suspicion"><vspace blankLines="1"/> <xref target="RFC4949" />
defines mutual suspicion as a state that exists between two interacting system entities
in which neither entity can trust the other to function correctly
with regard to some security requirement.</t>
<t hangText="Role"><vspace blankLines="1"/><xref target="RFC4949" /> describes
role as a job function or employment position to which people or other system entities may be assigned
in a system. In the I2RS interface, the I2RS agent roles relate to the roles that the I2RS client is
utilizing. In the I2RS interface, the I2RS client negotiation is over the client's ability
to access resources made available through the agent's particular role. Please refer to Figure 2 below.
Existing work includes IETF work in ABFAB and HTTP related SAML work.</t>
<t hangText="Role-based Access control"><vspace blankLines="1"/><xref target="RFC4949" /> describes
role-based access control as an identity-based access control wherein the system
entities that are identified and controlled are functional
positions in an organization or process. Within <xref target="RFC4949" /> five relationships
are discussed: 1) administrators to assign identities to roles, 2) administrators to
assign permissions to roles, 3) administrators to assign roles to roles,
4) users to select identities in sessions, and 5) users to select roles in sessions.
This document discusses I2RS use of Roles as Identities+Scope+Access where scope
is the portion of the routing tree, and access is permissions to read or write (or both).
Figure 1 below provides <xref target="RFC4949" /> the security view roles and assignments (page 254).
Figure 2 provides the same conceptual view of role-based access control applied to I2RS's
Combination of roles and identities that allow read, write, or read-write access to
I2RS agent functions. </t>
<t hangText="Role hierarchy or Permissions inheritance"><vspace blankLines="1"/><xref target="RFC4949" />
describes the hierarchy of roles and identities in role-based access control shown in Figure 1
and described above. I2RS will used role-based access control as defined above, and shown in Figure 2.</t>
<t hangText="Role certificate"><vspace blankLines="1"/><xref target="RFC4949" /> describes
a role certificate as an organizational certificate that is issued to a system entity that is a
member of the set of users that have identities that are assigned to the same role.</t>
<t hangText="Security audit trail"><vspace blankLines="1"/><xref target="RFC4949" /> (page 254) describes
a security audit trail as a chronological record of system activities that is sufficient
to enable the reconstruction and examination of the sequence
environments and activities surrounding or leading to an
operation, procedure, or event in a security-relevant transaction
from inception to final results. To apply this to the I2RS system, this implies that the
processes on the I2RS client-I2RS Agent protocol and related actions on the I2RS-Agent
can record a set of activity that will allow the reconstruction and examination of the sequence of
environments and activities around actions caused by the I2RS protocol data streams. </t>
<t hangText="I2RS integrity"><vspace blankLines="1" /> The data transfer as it is
transmitted between client and agent cannot be modified by unauthorized parties without detection.</t>
</list> </t>
<t>
The following diagram is a variation of the <xref target="RFC4949" /> diagram on role-based security,
and provides the context for the assumptions of security on the role-based work.
<figure>
<artwork>
(c) Permission Inheritance Assignments (i.e., Role Hierarchy)
[Constraints]
+=====+
| |
(a) Identity v v (b) Permission
+----------+ Assignments +-------+ Assignments +----------+
|Identities|<=============>| Roles |<=============>|Permissions|
+----------+ [Constraints] +-------+ [Constraints] +----------+
| | ^ ^
| | +-----------+ | | +---------------------+
| | | +-------+ | | | | Legend |
| +====>|Session|=====+ | | |
| | +-------+ | | | One-to-One |
| | ... | | | =================== |
| | +-------+ | | | |
+========>|Session|=========+ | One-to-Many |
(d) Identity | +-------+ | (e) Role | ==================> |
Selections | | Selections | |
[Constraints]| Access |[Constraints] | Many-to-Many |
| Sessions | | <================> |
+-----------+ +---------------------+
Figure 1 - Security definition of Role inheritance
</artwork>
</figure>
</t>
</section>
<section title="Security Issues" >
<t> The security for the I2RS protocol utilizes the role based access security for
the I2RS clients access to the I2RS agent's data (read/write). The I2RS
<xref target="I-D.ietf-i2rs-architecture" /> treats the agent's
notification stream or publication stream as a pre-authorized read. This security
consideration document examines the major points:
<list style="hanging">
<t hangText="I2RS roles and identities"><vspace blankLines="1"/> This section
looks at how I2RS roles and identities created by <xref target="I-D.ietf-i2rs-architecture" />,
how I2RS model derived from the security model of role-based access control matches
the <xref target="I-D.ietf-i2rs-architecture" />, and how Identities and roles get distributed?
</t>
<t hangText="Data Security"><vspace blankLines="1"/> The data security section looks at
incidents when the I2RS data stream will need confidentiality and message integrity,
transport security, how role-based access control of I2RS data impacts the I2RS Information Model
and Data Model design, and light weight clients who work without confidentiality.
</t>
<t hangText="Transport Requirements for Multiple data stream connections in I2RS"><vspace blankLines="1"/>
<xref target="I-D.ietf-i2rs-architecture" /> allows multiple data streams across one or more transports.
This section examines the security issues surrounding those streams.
</t>
</list>
</t>
<t>Subsequent sections will look how auditing, tracing and deployment scenarios impact the I2RS protocol.
</t>
<section title="Security roles and Identities for the I2RS client and I2RS Agent ">
<t> All I2RS clients and I2RS agents MUST have at least one unique identifier that uniquely identifies
each party. The I2RS protocol MUST utilize these identifiers for mutual identification of
the client and agent. An I2RS agent, upon receiving an I2RS message from a client, must
confirm that the client has a valid identity. The client, upon receiving an I2RS
message from an agent, must confirm the I2RS identity. </t>
<t> The distribution of security identity is taken up in the
section below. To provide context for that discussion let us look at
how I2RS roles are linked to that identity/identifier. </t>
<t>
<figure align="center">
<artwork>
Role = identity + routing tree + Read/Write/R-W
</artwork>
</figure>
</t>
<t>
Role security for an agent combines agent identity plus the potential read scope
plus the potential write scope. The potential read scope is the
routing attributes/variables within a data model
(for example BGP peer information) or a set of data models (RIB Data Mode and the BGP peer information)
that an agent may potential read. A notification or an event stream is considered
a set of read scope data sent via different methodology. A write scope is something the client
may write.
</t>
<t> Role security exists even if multiple transport connections are being used
between the I2RS client and I2RS agent (per <xref target="I-D.ietf-i2rs-architecture" />).
These transport message streams may start/stop without affecting the existence of the client/agent
data exchange. TCP supports a single stream of data. SCTP <xref target="RFC4960" /> provides
security for multiple streams plus end-to-end transport of data.
</t>
<t> (Editor: Additional WG discussion will need to focus on how different
deployments impact the transport layers, and the messages sizes (E.g. UDP's limited size).
Use case descriptions will guide this discussion.)</t>
<section title="I2RS Role-Based Access Control " >
<t>
Figure 2 show a model of the I2RS role-based access control environment.
This model is a variation of the <xref target="RFC4949" /> diagram on role-based security
shown in Figure 1. Portions of this model are outside the scope of the
I2RS protocol, but are part of the deployment environment of the I2RS protocol.
For example, the I2RS identity repository is a logical construct of an entity
that keeps all the identities. This logical entity may be implemented in deployments of
I2RS in many ways. One simple way is the administrator securely transferring a file
with identities and Roles to the client and agent. An automated way may be seen
within the security identity distribution protcools in the IETF (AAA, ABFAB, etc).
The important point is the Roles (Identity + Rib-portion + Scope (Read, Write, R/W) is
passed within the I2RS environment in an manner consistent to the logical constrains in this model.
</t>
<t>
<figure>
<artwork>
identity + Role
------- assignments (global)------
| Role assignments |
V V
+-----------+ +--------------------------+
| I2RS | identity |I2RS Agent Roles |
| Agent | assignments |= Potential Read Scope |
|identities | (or policy | + Potential Write Scope |
+--V--------+ constraints) +--------------------------+
| ^
I2RS | | (not in the I2RS protocol)
protocol | +==========+
| | |identity |
| ============|repository|
| |selection |
| +----------+
| Mutual |
| authorization |
| |
| V
| +-------------------+
|--| i2rs client |
| identities |
+-------------------+
Figure 2 - I2RS Role Based Access Model
</artwork>
</figure>
</t>
</section>
<section title="Identities" >
<t> This document suggests that identity distribution and the loading
of these identities into I2RS agent and I2RS Client occur outside the I2RS protocol.
The I2RS protocol SHOULD assume some mechanism (IETF or private) will distribute identities
and that the I2RS client/agent will load the identities prior to the I2RS protocol establishing a connection
between I2RS client and I2RS agent.
</t>
<t>
Each Identity will be linked (via internal policy) to one or more roles.
The context of the I2RS client-agent communication is based on an role which
may/may not require message confidentiality, message integrity protection,
or replay attack protection.
</t>
<t> I2RS clients may be used by multiple applications to configure routing
via I2RS agents, receive status reports, turn on the I2RS audit stream, or turn
on I2RS traceability. An I2RS client software could arrange to store
multiple secure identities and use the identity to insure that
the "Status-only" application process only uses
the client identity for status notification no matter what role that identity takes on.
Multiple identities provide some secondary level support for the
application-client, but may grow the number of identities. The multiple identities
per client could also be used for multiple levels of security for the data
passed between an I2RS client and agent as either: a) confidential,
b) authorized with message integrity protection, c) authorized without message integrity protection,
and or d) no protection. See the section below for
additional discussions on these options. </t>
<t> Editor's note: The WG needs to discuss the scaling properties of
the out of band establishment of identities (that is outside the I2RS protocol). </t>
</section>
</section>
<section title="I2RS Data Security" >
<t> I2RS data security involves determining of the I2RS client to I2RS agent data
transfer needs to be confidential, or have message integrity, or support an
end-to-end integrity (in the case of stacked clients). This section discuss the
consideration of I2RS data security. </t>
<t> It is assumed that all I2RS data security mechanisms used for protecting the I2RS packets needs
to be associated with proper key management solutions. A key management solution needs
to guarantee that only the entities having sufficient privileges can get the keys to
encrypt/decrypt the sensitive data. In addition, the key management mechanisms need
to be able to update the keys before they have lost sufficient security strengths,
without breaking the connection between the agents and clients.
</t>
<section title="Data Confidentiality Requirements">
<t> In a critical infrastructure, certain data within routing elements is
sensitive and R/W operations on such data must be controlled in order to protect
its confidentiality. For example, most carriers do not want a router's
configuration and data flow statistics known by hackers or their competitors.
While carriers may share peering information, most carriers do not share
configuration and traffic statistics. To achieve this, access control to sensitive
data needs to be provided, and the confidentiality protection on such data during
transportation needs to be enforced.
</t>
<t>
It is normal to protect the confidentiality of the sensitive data during transportation
by encrypting them. Encryption obscures the data transported on the wire and protects
them against eavesdropping attacks. Because the encryption itself cannot guarantee the
integrity or fresh of data being transported, in practice, confidentiality protection
is normally provided with integrity protection.
</t>
</section>
<section title="Message Integrity Requirements">
<t> An integrity protection mechanism for I2RS should be able to ensure 1) the data being
protected are not modified without detection during its transportation and 2) the data
is actually from where it is expected t come from 3) the data is not repeated from some
earlier interaction of the protocol. That is, when both confidentiality and integrity of
data is properly protected, it is possible to ensure that encrypted data are not modified
or replayed without detection.</t>
<t> As a part of integrity protection, the replay protection approaches provided for I2RS
must consider both online and offline attackers, and have sufficient capability to deal
with intra connection and inter-connection attacks. For instance, when using symmetric keys,
sequence numbers which increase monotonically could be useful to help in distinguishing the
replayed messages, under the assistance of signatures or MACs (dependent on what types of
keys are applied). In addition, in the cases where only offline attacker is considered,
random nonce could be effective.
</t>
</section>
<section title="End-to-End Data Integrity: Data or Transport" >
<t>The I2RS protocol is concerned with I2RS client-agent exchange.
End-to-end confidentiality requires at least transport layer security.
In a simple case of a I2RS Client to a single I2RS agent transfer, the
I2RS client puts the data in to the secure transport message and the
I2RS agent takes it out of the transport message. </t>
<t> In the case of a stacked client where the I2RS-client1 talks to a I2RS-agent1-I2RS-client2,
the data that transfers between the I2RS-agent-1 and I2RS-client-2 is
outside the scope of the I2RS protocol. However, it is critical
if this mechanism is used for fan-out of read/write commands to
agents that the end-to-end data has data integrity. </t>
<t> Editor question: Should I2RS have the optional capability to
support end-to-end data integrity? </t>
</section>
</section>
<section title="Role-Based Access Control of I2RS data" >
<t>I2RS protocol uses the I2RS Role (Identity + Access (Read, Write, or Read/Write) to
control access to the I2RS data. The impact of I2RS role-based security on I2RS data models is
that certain portions of an I2RS data models may require:
<list style="symbols">
<t> confidentiality - which requires a) mutual authentication, b) encryption, and c) message integrity protection with its associated
replay protection, </t>
<t> Message integrity protection - which requires mutual authentication, message integrity with replay protection, </t>
<t> mutual authentication only, or </t>
<t> no authentication.</t>
</list> </t>
<t>Therefore, creators of I2RS Information Models (IM) and I2RS Data Models (DM)
may want to consider the following factors:
<list style="symbols">
<t> Does the client using this data model care if the agent is valid? </t>
<t> Does the agent responding to this data model care if the client is valid?</t>
<t> Does the client-agent exchange require mutual authentication for all of the data model or some? </t>
<t> Does the client/agent care what operations are done? (secure communications) </t>
<t> Does the client and agent care about protection - either 1) confidentiality or 2) replay with integrity? </t>
<t> Are there other security issues unique to this Informational Model (IM) or Data Model (DM) </t>
</list> </t>
</section>
<section title="Impact of Data Confidentiality inclusion/exclusion in the I2RS Protocol" >
<t> Confidentiality of role implies the following: </t>
<t>
<list style="symbols">
<t> a requirement for confidentiality of I2RS routing tree scope (portion) in I2RS
client-agent communication; </t>
<t> I2RS client and I2RS agent mutually validate identities; and </t>
<t> encryption is supported in the I2RS protocol. </t>
</list> </t>
<t> Mutual validation of client and agent's identities means that both:
<list style="symbols">
<t> The I2RS client knows the I2RS agent has a valid identity, and that
the I2RS agent has agreed that the I2RS client has a valid identity; and </t>
<t> The I2RS agent knows that the I2RS client has a valid Identity, and the
the I2RS client has agreed that the I2RS agent has a valid identity. </t>
</list> </t>
<t>I2RS WG has indicated some I2RS client-agent message exchanges
will not need encrypt data to obscure the data. If this is so, then the
I2RS designers must understand if their data will be encrypted or sent without
encryption. Information Model (IM) and Data Model (DM) creators must discuss determine the following:
<list style="symbols">
<t> I2RS Client to Agent: Is encryption a recommendation or requirement? </t>
<t> If it is a recommendation, must the I2RS agent/client support encryption
but only use it for certain roles (portions of the tree with read/write scope)?
If there are multiple channels for transporting data, one role could be operating
without encryption on one part of the tree, and another role could be operating
with encryption on another part of the tree. </t>
<t> Does the Informational Model (IM) and Data Model (DM) make assumptions that
would allow security attacks using the unencrypted data?
</t>
</list> </t>
</section>
<section title="Transport requirements">
<t> The architecture provides the ability to have multiple transport
sessions providing protocol and data communication between the I2RS Agent
and the I2RS client. The document does not try to specify the protocols for securing I2RS packets,
but provides considersations in choosing a transport protocol.
These transports can be TCP or secure (SCTP) or a TLS based.
If we use TLS based transports, we can use TLS over UDP (DTLS)
or SSL with with TLS plus extensions.
</t>
<t> The following are questions to address regarding the transport:
<list style="symbols">
<t> Do we have mandatory-to-implement transport protocols? </t>
<t> Will the association of I2RS Roles with transport protocols need
to be configured in the I2RS client and I2RS agent?
</t>
<t> Do we allow the I2RS agent/client to automatically establish
transport sessions to publish statistics for notifications/subscriptions? </t>
<t> Is a publishing broker feasible or does that cause security issues? </t>
</list> </t>
</section>
</section>
<section title="Audit-able Data streams">
<t> This section discusses data streams which have a security
audit trail (see definitions) for the I2RS Client to I2RS Agent interactions.
The I2RS Discussion group suggested that audit data streams are:
<list style="symbols">
<t> a tracing of changes sent to a separate streams, and </t>
<t> a portion of the data selected by policy </t>
<t> turned on/off via I2RS protocol </t>
</list>
</t>
<t> I2RS is not inventing a new audit protocol as many protocols (syslog) are
available to be used. Verifying audit stream data is outside the I2RS protocol, but
those designing the IM and DMs with audit stream capability need to provide the
appropriate hooks such as: on/off action, data selection, and protocol (for example syslog)
that the I2RS Agent (or I2RS routing system) sends the audit data upon.
</t>
<t>
Agent audit trail could be the logging of what variables written by
which client (identified by client ID) on behalf of a reported application
(identified by the ID of the application). The audit stream turned on by the I2RS Agent
may need to pass both the client ID and the application ID to the audit stream.
</t>
<t>
Out of scope for this work is the ability to audit the application to I2RS-Client interfaces,
or the I2RS Agent to I2RS routing system. </t>
<t></t>
<t> Editor: Questions still to be answered:
<list style="symbols">
<t> Is support for audit stream a requirement for all I2RS agents or
an option dependent on the role which is dependent on the IM/DM (info and data models)? </t>
<t> How does the filtering of event data impact the audit process? For example
if BGP event changes are only taken from 50 out of 300 BGP peers, does this stop
any ability to audit the session? Or if the read filters only watch for key
prefixes to be received on a specific set of interfaces, does this stop the ability to audit?
</t>
<t> How do you handle filtering of reads/notifications by I2RS policy and auditing?
If the I2RS client asks to read a IM/DM tree portion via a Role but the
that read data requested of I2RS Agent is filtered before sending to client,
how is this handled in the auditing protocols? </t>
</list>
</t>
</section>
<section title="Impact of Traceability" >
<t> The draft <xref target="I-D.clarke-i2rs-traceability" /> provides an IM for the
following use cases:</t>
<t>
<list style="symbols">
<t> Automated event correlations, trend analysis, and anomaly detection </t>
<t> trace log storage</t>
<t> improved accounting of routing system transactions </t>
<t> Standardized structure data format for writing common tools </t>
<t> real-time monitoring and troubleshooting </t>
<t> enhanced network audit, management and forensic analysis capabilities </t>
</list> </t>
<t> The operational guidance in the traceability IM includes creation of an I2RS
log that is stored in a temporary storage, rotated, and retrieved via syslog, I2RS "snap-shot"
available as one bulk snapshot or subscription, and in a I2RS publish-subscribe stream. </t>
<t> The security issues of the traceability log data sent to syslog are equivalent to the
auditable data stream security issues covered in the previous section. The one-bulk snapshot
data model and publish/subscription model contain the same issues considered in the basic
read functions described above. The traceability log issues beyond this are implementation or
transport protocol issues regarding scale.
</t>
</section>
<section title="Deployment issues" >
<t> This section provides consideration for the deployment issues around stacked
I2RS clients. This section only has questions for now, and will be added to in future
drafts. </t>
<section title="Stacked I2RS Agent-Clients in Broker topologies" >
<t> The <xref target="I-D.ietf-i2rs-architecture" />
describes a broker function that can be used in the topology server use case.
The general concept for such a deployment would allows the following hierarchical scenario: </t>
<t>
<figure>
<artwork>
Broker
I 2RSclient1----I2RSagent1=I2RSclient2---I2RSagent2
|-----I2RSagent3
|-----I2RSagent4
|-----I2RSagent5
Figure 3
</artwork>
</figure>
</t>
<t> Editor: The implications of this deployment scenario will be added to this draft.
For now we have the following questions:
<list style="symbols">
<t> Does Stacked I2rs agent/client require end-to-end security? </t>
<t> Does this scenario bring unique security issues? </t>
<t> Is this scenario outside the I2RS venue? If </t>
<t> If it is scope, do we need to alter the diagrams within the
architecture document? If so, how would we re-write the diagrams. </t>
</list> </t>
</section>
</section>
<section anchor="Acks" title="Acknowledgement">
<t>The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric Yu,
Alia Atlas, and Jeff Haas for their
wonderful contributions to our discussion discussion.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>This is a document about security architecture beyond the consideration for I2RS.
Additional security definitions will be added in this section. </t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC2119;
&RFC4785;
&RFC4949;
&RFC4960;
&I-D.ietf-i2rs-problem;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.white-i2rs-use-case;
&I-D.keyupate-i2rs-bgp-usecases;
&I-D.clarke-i2rs-traceability;
&I-D.hares-i2rs-info-model-policy;
&I-D.ji-i2rs-usecases-ccne-service;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:07:32 |