One document matched: draft-hares-i2rs-security-03.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-03" 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="2015" />
<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"></xref> </t>
</section>
<section title="Definitions" >
<t>This document utilizes the definitions found in the
following drafts: <xref target="RFC4949"></xref>, and <xref target="I-D.ietf-i2rs-architecture"></xref>
</t>
<t> Specifically, this document utilizes the following definitions:
<list style="hanging">
<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 as 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 afte
each system has been identified and validated by its peer system </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. </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 Scope+Access where scope
is the portion of the routing tree, and access is permissions to read or write (or both).
Figure 1 replicates <xref target="RFC4949" /> diagram on RBAC roles and assignments (page 254).
</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"></xref> 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 client's access to the I2RS agent's data (read/write). The I2RS
<xref target="I-D.ietf-i2rs-architecture"> </xref> 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>
</list> </t>
</section>
<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> 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) in order
to distribute or load 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 role.
The context of the I2RS client-agent communication is based on a role which
may/may not require message confidentiality, message integrity protection,
or replay attack protection.
</t>
<t> The rigorous definition of a role in RBAC-based security is
role is function associated with an activity (set of actions).
The set of actions in I2RS performs is limited are
read or write actions on a specific set of data
in the data model. Therefore, we can express:
<figure align="center">
<artwork>
Role = routing tree + Read/Write/Read-Write
</artwork>
</figure>
</t>
<t>
Role security for an agent involves pairing the identity to the role.
The data store can read information either by write or an event stream.
</t>
<t> Role security exists even if multiple transport connections are being used
between the I2RS client and I2RS agent as the <xref target="I-D.ietf-i2rs-architecture">I2RS architecture</xref> states.
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> 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 a specific identity that only associates
roles which only have Read access. This administrative design of identities and
roles could insure a "status-only" application did gain write access.
This administrative design is possible within I2RS architecture but not mandated.
</t>
<t>
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. </t>
</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>
<t>
The rules around what role is permitted to access and manipulate what
information, combined with encryption to protect the data in transit
is intended to help ensure that data of any level of sensitivity is
reasonably protected from being observed by those without permission
to view it. In that case 'those' can refer to either other roles,
sub-agents, or to attackers and assorted MITM monkeys.
</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>
<section title="Open Issues">
<t> The following are open issues for the I2RS WG to discuss:
<list style="hanging">
<t hangText="Unencrypted Message Exchanges"><vspace blankLines="1"/>
The I2RS Security discussion group believes that encrypting all the data messages
is the best approach for security. Some I2RS WG discussion has indicated a
desire for the the I2RS client-agent message exchanges to be unencrypted.
The discussion group needs the I2RS WG members to provide more detail
since a mixture of encrypted and unencrypted data will require more
complexity in the Information Model (IM) and Data Model (DM).
</t>
<t hangText="Transport requirements"><vspace blankLines="1"/>
The architecture provides the ability to have multiple transport
sessions providing protocol and data communication between the I2RS Agent
and the I2RS client. The discussion group proposed on mandatory secure transport.
Should there be one mandatory secure transport protocol or multiple
allowable protocols? </t>
<t hangText="Auditable Data Streams"><vspace blankLines="1"/>
Auditable data streams does not have a security consideration because
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>
</list>
</t>
</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:56 |