One document matched: draft-hares-i2rs-security-00.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 RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.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-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.clark-i2rs-traceability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-clarke-i2rs-traceability-00.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-00" ipr="trust200902">
<front>
<title abbrev="I2RS Security">I2RS Security Architecture</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Hickory Hill Consulting</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="Wesley George" initials="W" surname="George">
<organization>Time-Warner Cable</organization>
<address>
<email>wesley.george@twcable.com</email>
</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="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) [<xref target="I-D.ietf-i2rs-architecture" />]
provides read and write access to the information and state within the
routing process within routing elements. The I2RS client
interacts with one or more I2RS agents to collect information
from network routing systems. This security architecture expands on the
the security issues involved in the i2rs client - i2rs agent exchange
described in <xref target="I-D.ietf-i2rs-architecture" />. </t>
</section>
<section title="Definitions" >
<t>This document utilizes the definitions found the
following drafts: <xref target="RFC4949" />, and <xref target="I-D.ietf-i2rs-architecture" />.
</t>
<t> Specifically, this document utilize 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., establish 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 a user can designated that the
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 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
identified and validated. </t>
<t hangText="Mutual Suspicion"><vspace blankLines="1"/> <xref target="RFC4949" />
defines mutual suspicion as a state that exist 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 exercises a particular agent role. The negotiation is
over the client ability to exercise the agents role as a resource. Please refere to diagram 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 herein the system
entities that are identified and controlled are functional
positions in an organization or process. This document discusses the
roles and identities that allow read, write or read-write access to
I2RS agent functions. </t>
<t hangText="Role-based Access control"><vspace blankLines="1"/><xref target="RFC4949" /> describes
role-based access control as an identity-based access control herein the system
entities that are identified and controlled are functional
positions in an organization or process. This document discusses the
roles and identities that allow read, write or read-write access to
I2RS agent functions. </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" /> describes
a security audit trail as a chronological record of system activity 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.</t>
</list> </t>
</section>
<section title="Security Issues" >
<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.
</t>
<t> I2RS identity and functions diagram </t>
<t>
<figure>
<artwork>
inheritance
roll-up (?)
||
+-----------+ VV +--------------------------+
| I2RS | identity |I2RS Agent Roles |
| Agent | assignments |= Potential Read Scope |
|identities | | + Potential Write Scope |
+--V--------+ constraints +--------------------------+
| ^
I2RS | | (not in the I2RS protocol)
protocol | +==========+
| | |identity |
| ============|repository|
| |selection |
| +----------+
| Mutual |
| authorization |
| |
| V
| +-------------------+
|--| i2rs client |
| identities |
+-------------------+
Figure 1 - I2RS Role Based discussion
</artwork>
</figure>
</t>
<t> The I2RS figure is taken from the following Security Definition figure
on role hierarchy </t>
<t>
<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 | | <================> |
+-----------+ +---------------------+
</artwork>
</figure>
</t>
<section title="Security roles for the I2RS client-agent ">
<t>
Role is the Agent's Potential Read Scope plus the Potential write Scope.
The potential read scope is the Routing Attributes/variables
(for example BGP peer information) that an agent may potential read.
A notification or an event stream is a flow that an agent may potential read.
A write scope is something the client may write. Examples are
is a RIB entry or a PBR entry or protocol variables (BGP, LDP). </t>
<t></t>
<t>Question: Does role by client will lead to proliferation of clients? </t>
</section>
<section title="Transport requirements">
<t> The architecture provides the ability to have multiple transports
sessions providing protocol and data communication between the I2rs Agent
and the I2RS client. These transports can be TCP or secure (SCTP) or any form
of transport.</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> Are there concerns about opening the mandatory-to-implement
transport from either the Client or the Server side? </t>
<t> How would that work with a publication or subscription model? </t>
<t> Is a publishing broker feasible or does that cause security issues? </t>
</list> </t>
</section>
<section title="Auditable Data streams" >
<t> This section discusses how we can get data streams which have a security
audit trail (see definitions) for the I2RS Client to I2RS AGent interactions.
Agent audit trail could be the logging of what variables written by
which client (id of client) on behalf of reported application (ID).
Since the reported application id is not valid, all the audit stream states
is that the Client told the agent this is the application I'm acting for.
</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> Questions to be answered:
<list style="symbols">
<t> I2RS client to I2RS Agent is being able to audit a requirement for all I2RS agents or
an option? </t>
<t> What is scope of audit (full stream, partial stream, specific functions)? </t>
<t> Does the ability to audit mean the ability to verify? </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 read filtering and auditing? The last section in this document has a
read filtering example. Would some conditions such as auditing and read-filtering be not allowed
on the policy match?
</t>
</list> </t>
</section>
<section title="Encryption and Integrity" >
<t> Encryption is used to provide data privacy. The real question is do we need to
encrypt the data to retain its data.
<list style="symbols">
<t> I2RS Client to Agent: Is encryption a recommendation or requirement? </t>
<t> I2RS environment: Application to I2RS client: discuss encryption (pro/con) </t>
<t> I2RS environment: I2RS client to Routing System: discuss (pro/con) </t>
</list> </t>
<t> What is needed for integrity of the data </t>
</section>
<section title="stacked I2RS agents" >
<t> It is possible to have the following hierarchical scenario: </t>
<t> I2RS client---->I2RSAgent=I2RSclient---I2RSAGent(nodes) </t>
<t>Questions:
<list style="symbols">
<t> Does this scenario bring unique security issues? </t>
<t> Is this scenario outside the I2RS venue </t>
</list> </t>
</section>
</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</t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC2119;
&RFC4949;
&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.clark-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:08:58 |