﻿<?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|&lt;=============&gt;| Roles |&lt;=============&gt;|Permissions|
      +----------+ [Constraints] +-------+ [Constraints] +----------+
           |   |                   ^   ^
           |   |   +-----------+   |   |       +---------------------+
           |   |   | +-------+ |   |   |       |       Legend        |
           |   +====&gt;|Session|=====+   |       |                     |
           |       | +-------+ |       |       |     One-to-One      |
           |       |    ...    |       |       | =================== |
           |       | +-------+ |       |       |                     |
           +========&gt;|Session|=========+       |     One-to-Many     |
      (d) Identity | +-------+ |  (e) Role     | ==================&gt; |
       Selections  |           | Selections    |                     |
      [Constraints]|  Access   |[Constraints]  |    Many-to-Many     |
                   | Sessions  |               | &lt;================&gt;  |
                   +-----------+               +---------------------+
				
				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>
