<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ward-i2rs-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ward-i2rs-framework.xml">
<!ENTITY I-D.amante-i2rs-topology-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.amante-i2rs-topology-use-cases.xml">
<!ENTITY I-D.atlas-i2rs-policy-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-i2rs-policy-framework.xml">
<!ENTITY I-D.atlas-i2rs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-i2rs-problem-statement.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-camwinget-i2rs-pubsub-sec-00" ipr="pre5378Trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters P-->

    
    <title abbrev="Using Pub-Sub in I2RS">
      Using the Publish-Subscribe Model in the Interface to the Routing System
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Ken Beck" initials="K.E." surname="Beck">
      <organization>Cisco Systems</organization>

      <address>
        <email>kebeck@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <!-- Reorder-->
        </postal>

        <email>ncamwing@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="David McGrew" initials="D.A." surname="McGrew">
      <organization>Cisco Systems</organization>

      <address>
        <email>mcgrew@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="July" year="2013"/>


    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. 

The publish/subscribe interaction sch- eme is receiving increasing
attention and is claimed to provide the loosely coupled form of
interaction required in such large scale settings. Subscribers have
the abil- ity to express their interest in an event, or a pattern of
events, and are subsequently notified of any event, generated by a
pub- lisher, which matches their registered in- terest.

-->

    <abstract>
      <t>In the Publish-Subscribe model, subscribers express their
      interest in an event, or a pattern of events, and are
      subsequently notified of any event generated by a publisher that
      matches their registered interest.  The model is well suited for
      communication in large-scale and loosely coupled distributed
      systems.  This document describes how the model fits into Interface
      to the Routing System (I2RS) and Software Defined Networking (SDN)
      architectures, and analyzes its advantages, its security
      requirements, and its use in providing security within I2RS.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <!--
      <t> In a topics-based publish-subscribe model, information can
      be exchanged through a set of predefined topics (or subjects) to
      scale the many-to-many distinct communication channels needed
      and reduces dependencies amongst the applications expecting to
      exchange such information <xref target="rti.white.paper"/>.
      </t>
      -->
      <t>
	This document describes the use of a publish-subscribe (or
	pub-sub) model to facilitate communication and authorized
	access for the different types of programmatic interfaces and
	types of applications that may be available in the I2RS and
	SDN architectures. It also analyzes the advantages in both
	scalability and security in its use within I2RS.  The security
	requirements of a pub-sub system are given special attention,
	to ensure that the system meets the requirements when it is
	used to provide security.
      </t>
    </section>

    <section anchor="pub-sub-background" title="Publish-Subscribe Models">
        <t>There are two classical publish-subscribe models: topic- or
        content-based       <xref target="manyfaces"/><xref target="pub.sub.evolution"/>. In a
        topic-based model, information is exchanged through a set of
        predefined "topics" or subjects; where a publisher is
        responsible for defining the classes of information to which a
        subscriber registers.  In a content-based model, information
        is only shared to a subscriber if the specific information
        matches the subscriber's criteria.</t>


	<t>
  In some important scenarios, a publish-subscribe model has
  significant advantages over a client-server model.  When a source
  generates data intermittently, a client-server model can be used by
  having the client poll the server.  But this method suffers from
  overhead in both processing and bandwidth, and it introduces a
  latency between the time the data is generated at the source, and
  the time that it is transported to the client.  In contrast, a
  publish-subscribe model avoids the extra processing, bandwidth, and
  latency by establishing a channel by which the source asynchronously
  communicates its data.
	</t>

	<section title="Terminology">

    <t><list style="symbols">
        <t>Publisher: defines an entry point or handle by which a
        protocol or programmatic interface and its capabilities such
        as its time delivery capabilities, protocol transport and
        security properties can be used.</t>
        <t>Subscriber: defines an interested routing element or
        application requiring access to a protocol or programmatic
        interface.</t>
        <t>Message Broker (MB): the authorization agent and broker
        used to manage the supported protocols and interfaces
        inclusive of their (access and transport) capabilities and
        manages the authorization of subscribers.</t>
        </list></t>

        </section>


    </section>
    <section anchor="pub-sub" title="An I2RS Publish-Subscribe Model">
        <t>Use cases and framework architectures for I2RS and SDN
        define the need for interfaces for acquiring information about
        the routing system as well as manipulating and controlling the
        topology and behavior of such routing system.  The uses cases and
        frameworks described in <xref
        target="I-D.amante-i2rs-topology-use-cases"/> and <xref
        target="I-D.ward-i2rs-framework" />, respectively, describe the
        need for interfaces with varying capabilities.  The
        characteristics of these capabilities include:</t>

      <t><list style="symbols">
          <t>Time delivery sensitivity: interfaces or operations to be
          executed in the I2RS may come with different time
          constraints.  Per section 3.5 of <xref
          target="I-D.ward-i2rs-framework" />, it is necessary in some
          cases to define when an operation is to be handled.  In
          particular, there are operations that initially require
          synchronization of state.</t>

          <t>Support for multiple protocols or implementation layers:
          it is expected that there would be more than a single
          mechanism defined to acquire, manipulate and control the
          routing system.</t>
          
          <t> Secure, authorized communications: as the application(s)
          control the behavior of the routing system, the application
          must be authorized to manipulate and control the routing
          system, and that system must check that the application has
          the appropriate authorizations.</t>
          
          <t> Support for a range of data delivery content: especially
          in interfaces where information (such as topology data or
          security monitoring or auditing data) is being conveyed, the
          size or amount of data to be transmitted can be very large.
          Conversely, interfaces that control routing may transmit 
          very short packets.  </t>
        </list> </t>
        
          <t> Given the different characteristics and presence of
          multi-protocol support, a publish-subscribe model can be
          used as a means to facilitate secure authorized
          communications. Publishers can define the characteristics
          and capabilities supported by the particular interface
          through the message broker from which subscribers can
          register.  Furthermore, as suggested by <xref
          target="I-D.amante-i2rs-topology-use-cases"/> and <xref
          target="I-D.atlas-i2rs-policy-framework" />, a "Policy
          manager" or "Policy Framework" is needed to ensure
          authorized communications. The message broker of a
          publish-subscribe model can behave as the authorizing agent
          and determine if a subscriber is authorized to register to
          specific subscriptions.  Similarly, the message broker can
          also decide whether a publisher is authorized to provide
          the protocols and interfaces it is attempting to
          publish. </t>
          
          <t> The use of the publish-subscribe pattern handles
          scalability issues especially given the many to many
          relationships.  It is expected that an application will
          establish connections to more than one interface; similarly,
          an interface will be communicating with many applications.
          Given the many to many expected communications, the need to
          manage the connections and its security properties can be
          diminished through the use of the publish-subscribe model.
          The publish-subscribe model reduces the number of
          relationships to [P+S] (where P are the number of publishers
          and S are the number of subscribers) versus the potential
          for having to manage P*S relationships. </t>
         
          <section anchor="broker" title="Role of the Message Broker">
              <t> In using the publish-subscribe model, there is a
              Message Broker that mediates between the publishers and
              subscribers. The Message Broker as the intermediary,
              allows publishers to post their information while
              allowing subscribers to register to the types of
              information it wants to receive.  As the intermediary,
              the Message Broker can also provide filtering
              capabilities to allow for a publisher to post its
              information once but filter according to what
              subscribers may be interested or is authorized to
              receive in a subset of what a publisher may post. </t>
                 <t>
In the I2RS and Software Defined Networking (SDN) use case, the Message
Broker (MB) can establish the authorizations of both publishers and
subscribers.  When a publisher registers with the MB, the publisher
and MB authenticate each other and the MB authorizes the publisher as
being authoritative for a particular topic (or if the MB is not
authorized, its registration is rejected).  When a subscriber
registers with the MB, the subscriber and MB authenticate, and the MB
authorizes the subscriber to receive the topic (or its registration is
rejected).
		 </t>
		 
              </section>

    </section>
      
    <section anchor="taxonomy" title="Proposed Taxonomy based on Use Cases">
       <t> Suggested architectures of the I2RS system contains I2RS
       Clients <xref target="I-D.amante-i2rs-topology-use-cases"/>
       <xref target="I-D.atlas-i2rs-problem-statement"/> (also called
       Commissioners <xref target="I-D.atlas-i2rs-policy-framework"/>)
       at the application level, I2RS Agents at the network level with
       the I2RS protocol as the interface between the two. The specific
       details and nature of the Clients or Commissioners and Agents
       require more investigation.  This discussion assumes little
       about them and focuses on the I2RS Protocol and how the
       publish-subscribe model can address many of the stated
       requirements and use cases, and bring additional benefits such
       as scalability and security. </t>
        
        <t> A suggestive network architecture diagram from
        [I-D.atlas-i2rs-problem-statement] below:</t>
        
        <figure title="I2RS Architectural Model">
            <artwork><![CDATA[
 +***************+   +***************+   +***************+ 
 *  Application  *   *  Application  *   *  Application  *
 +***************+   +***************+   +***************+
         ^                   ^                  ^
         *                   *                  *
         *                   *   ****************
         *                   *   *
         v                   v   v
 +---------------+   +---------------+
 |  I2RS Client   |   |  I2RS Client   |
 +--------------+   +---------------+
           ^                   ^
           |________________   |
                            |  |  <== I2RS Protocol
                            |  |
 ...........................|..|..................................
 .                          v  v                                 .
 . +*************+     +---------------+      +****************+ .
 . *    Policy   *     |               |      *   Routing  &   * .
 . *   Database  *<***>|  I2RS Agent   |<****>*   Signaling    * .
 . +*************+     |               |      *   Protocols    * .
 .                     +---------------+      +****************+ .
 .                        ^   ^     ^                  ^         .
 . +*************+        *   *     *                  *         .
 . *  Topology   *        *   *     *                  *         .
 . *  Database   *<*******+   *     *                  v         .
 . +*************+            *     *         +****************+ .
 .                            *     +********>*  RIB Manager   * .
 .                            *               +****************+ .
 .                            *                        ^         .
 .                            v                        *         .
 .                 +*******************+               *         .
 .                 * Subscription &    *               *         .
 .                 * Configuration     *               v         .
 .                 * Templates for     *      +****************+ .
 .                 * Measurements,     *      *  FIB Manager   * .
 .                 * Events, QoS, etc. *      *  & Data Plane  * .
 .                 +*******************+      +****************+ .
 .................................................................
                
 <-->  interfaces inside the scope of I2RS
 +--+  objects inside the scope of I2RS
            
 <**>  interfaces NOT within the scope of I2RS
 +**+  objects NOT within the scope of I2RS
            
        ....  boundary of a router participating in the I2RS
            ]]></artwork>
        </figure>
        <t>The I2RS Agent communicates with the network platform on
        which it resides presumably largely with a platform specific
        interface, i.e. CLI or REST, and with existing protocols where
        appropriate.  There are opportunities to facilitate the
        publish-subscribe model within the network platform also.
        Here the applicability would most likely be to new areas of
        functionality where no existing broadly adopted standards are
        used; additionally where such existing standards might be
        extended by adoption of publish-subscribe .  It is unlikely
        the standards themselves would be modified but rather
        publish-subscribed might be layered on top to better
        facilitate sharing of state maintained by such standards. </t>
        <t> As suggested, the standards used would be
        publish-subscribed as a new layer to improve the overall
        system scalability and facilitate operations such as: </t>
       <t> <list style="symbols">
            <t>Discovery: to address the many versions of interfaces
            and protocols supported, a discovery mechanism may be
            introduced by which I2RS Agents register as publishers or
            subscribers. As a publisher, an interface, schema or
            protocol may be "advertised" with its capabilities such as
            the supported versions, security and data transport
            properties.</t>
            <t>Security: it is imperative that I2RS Agents be
            authenticated and authorized to employ the different
            interfaces and protocols.  To address the many-to-many
            relationships, the use of a publish-subscribe model as a
            new layer on top helps address the security requirements
            in a scalable manner as well.</t>
            </list>
        </t>
        <t>Taxonomy is still being developed for I2RS and there is
        inconsistent terminology being used to date.  The terminology
        used here and its relationship to terminologies of others is
        as follows:</t>
        <t><list hangIndent="1" style="hanging">
            <t><list hangIndent="3" style="hanging">
            <t hangText="Application"> <vspace blankLines="1"/> I2RS
            application that uses the I2RS interface to interact with
            the routing system.  This may include a Client which
            actually implements the application side of the I2RS
            interface.  This has also been called the
            Commissioner.</t>
            
           <t hangText="Router"><vspace blankLines="1"/> The network
           element that supports the I2RS interface acts as a
           northbound API.  This may include an I2RS Agent or Server.
           Areas where publish-subscribe can be deployed to satisfy
           stated requirements and use cases: <vspace blankLines="1"
           /><list hangIndent="0">

            <t hangText="Asynchronous Router to application
            notifications"><vspace blankLines="1"/> In the
            publish-subscribe model, routers register as publishers of
            notifications and applications interested in receiving
            notifications register as subscribers. The I2RS Agent in
            the router need only publish a notification to
            publish-subscribe and is unburdened from maintaining
            which, if any, application is interested in the
            notification. Similarly, the application need only express
            interest in receiving notifications and is unburdened from
            monitoring about routers.  The publish-subscribe mechanism
            handles the asynchronous notification connecting router
            notifications with interested applications. Note that an
            application can also act as a publisher and an I2RS agent
            can act as a subscriber.</t>
            

            <t hangText="Many to Many"><vspace blankLines="1"/> <xref
            target="I-D.amante-i2rs-topology-use-cases"/> and <xref
            target="I-D.ward-i2rs-framework"/> both discuss the need
            for the I2RS interface to support multiple applications
            interfacing with multiple routers and the required
            capability of each application to be made aware of changes
            made by another.  With publish-subscribe routers register
            to publish change notifications, applications register to
            receive change notifications and the publish-subscribe
            mechanism handles the change notifications connecting
            router notifications with interested applications.</t>
            
            <t hangText="Topology"><vspace blankLines="1"/> <xref
            target="I-D.amante-i2rs-topology-use-cases"/> and <xref
            target="I-D.ward-i2rs-framework"/> discuss the requirement
            for applications to monitor network topology and changes
            to the topology whether made by devices appearing or
            disappearing due device reboot or failure, modifications
            by other applications or by some other autonomic mechanism
            and the limitations of existing protocols to satisfy this
            requirement.  Here, device agents, applications and other
            entities modifying topology would register as publishers
            of topology info, with publish-subscribe handling
            distributing change notifications to interested
            applications.  This particular use case highlights the need
            for an initial synchronization to enable a subscriber to learn the
            current network topology as well as an asynchronous 
	    method to learn the changes and updates to that
            topology as they occur.</t>

	    <!--
            <t>REQ7: Both asynchronous and synchronous communications
            are required to handle use cases as those highlighted by
            the network topology monitoring.  As such, both a
            synchronization as well as the potential to do a
            synchronous update SHOULD be supported in addition to the
            asynchronous communications to handle updates.
	    </t>
	    -->

            
            <t hangText="RIB Updates"><vspace blankLines="1"/> <xref
            target="I-D.ward-i2rs-framework"/> and others describe the
            need for router RIB updates to be available to I2RS
            applications.  This is another case where routers can
            register as publishers of RIB changes with
            publish-subscribe handling the distribution of these
            changes to interested applications.</t>
            
            <t hangText="Policy Management"><vspace blankLines="1"/>
            <xref target="I-D.atlas-i2rs-policy-framework"/> discusses
            the need for applications to monitor policy changes,
            including those made by other applications.  This would be
            a subset of the Many to Many publish-subscribe case.</t>
               </list></t>
            </list></t>
            </list></t>
            <t>
            Other cases which it is clear would be well handled by
            publish-subscribed include Events and Configuration
            Changes.
            
            Use cases from [I-D.keyupate-i2rs-bgp-usecases] would include:</t>
        <t><list>
	  <t> 
	    BGP Error Notifications.  Notification of Routing Events.
	  </t>
	  <t> 
	    BGP Protocol Statistics.  Routing agents could publish
            BGP errors, other BGP events and BGP statistics on the
            router.
	    </t>
            <t>
	    Tracing Dropped BGP Routes.  Routers can publish learning
	    of BGP routes which would enable applications the monitor
	    the propagation of routes through the AS.
	    </t>
            </list></t>
        </section>
 <!--      </t> </section> 
    </section>
    </section>
   -->

       

      
    <section anchor="Sec-reqmts" title="Security Requirements">
        <t>This section describes security requirements as needed to
        sustain an I2RS or SDN.  These requirements are based on the
        use cases defining the need for multiple protocol (using
        multiple layers) that need to act at different time
        sensitivities.  It is expected that applications will need to
        gain appropriate authorization to use one or more of these
        protocols within an I2RS or SDN.  
	</t>
	  <t>
	    In access control models, it is common to describe access
	    control on data in terms of the entities that are
	    permitted to read that data, and the entities that are
	    permitted to write that data.  These models naturally
	    apply to a publish-subscribe model: a subscriber to a
	    topic is authorized to read data on that topic, and a
	    publisher is authorized to write data on it.  In a pub-sub
	    model, there may be many subscribers to a topic, and there
	    may be more than one publisher on a topic as well.
	  </t>
	  <t>
	    Published data requires the following protections, which 
	    are stated in terms of a specific topic:
	    <list>
	      <t>
		Authentication: it must not be possible for any entity
		other than the publisher to create a message that a
		subscriber will accept as authentic.  It must not be
		possible for one subscriber to create messages that
		are accepted by the other subscribers to the same
		topic.  When there are multiple publishers on a
		particular topic, it must be possible for the
		subscribers to authenticate the actual publisher of
		each message.
	      </t>
	      <t>
	Anti-replay: if a subscriber receives the same exact message twice
	(e.g. because an attacker has copied and then re-injected the
	message), it must be detectable, and the subscriber must reject the
	replayed message.
	      </t>
	      <t>
		Ordering: it must not be possible for any entity to
		re-order the authentic messages in such a way that the
		subscriber would accept the messages in a sequence
		other than the one intended by the publisher.  If
		there are multiple publishers and the system does not
		ensure that they are delivered in a particular order,
		then subscribers (and the applications that use them)
		must not rely on any particular ordering.
	      </t>
	      <t>
		Confidentiality: it should not be possible for any entity other than a
		subscriber to read the messages.
	      </t>
	    </list>
		Authenticity, anti-replay, and ordering are required, because those
		protections are essential to prevent the manipulation of the routing
		system.  Confidentiality may not always be necessary, but it is
		strongly recommended that it be available within the pub-sub system.
		Anti-replay and ordering can be easily achieved whenever
		authentication is available, through the use of sequence numbers
		and/or timestamps.
	  </t>
	  <t>
	    There are different cryptographic techniques that can be used to
	    provide the security services outlined above.  One method is to use
	    pairwise communications security, such as TLS or IPsec, between each
	    subscriber and the MB and between each publisher and the MB (in the
	    case that all communication goes through the MB).  Mutual
	    authentication between the MB and the publishers and subscribers is
	    required.  The minimum configuration that is necessary is that each
	    publisher, and each subscriber, be configured with the information
	    needed to authenticate the MB.  Because each communication channel is
	    separately protected, all of the needed security services are provided
	    and separation is enforced between different publishers and
	    subscribers.  The advantage of this method is its simplicity.  It does
	    have disadvantages when there are many subscribers and/or publishers:
	    cryptographic operations will need to be performed for each
	    subscriber, and if the MB is compromised, then the security of the
	    entire system is compromised.  If the MB functionality is distributed
	    to multiple nodes in the network, that may help scalability, but at
	    the expense of security, since it creates additional points in the
	    system whose compromise will undermine its security.
	  </t>
	  <t>
	    In some cases the communication may go directly between a publisher
	    and a subscriber, instead of through the MB.  Those cases have similar
	    advantages and disadvantages.  In these cases, the MB must provide the
	    subscribers and publishers with the information that they need to
	    authenticate each other, and to check the authorizations of the other
	    side of the secure communications channel.  This authentication and
	    authorization information can be provided by the MB on a per-session
	    basis, or it could be persistent across multiple sessions.  If the
	    data can persist for a long time, then it is important to have a
	    method by which the MB can revoke the authorizations.
	  </t>
	  <t>
	    Another method is to use cryptography on the messages themselves.
	    Digital signatures can be used to provide authentication of each
	    message, in which each publisher has a private key, and each
	    subscriber has the corresponding public key.  Confidentiality can be
	    provided using a group key that is shared by each publisher and the
	    set of corresponding subscribers.  This method has the advantage that
	    cryptographic operations need only be done once on each method, thus
	    enabling the system to scale well when there are large numbers of
	    subscribers.  It also reduces the number of keys used, and the amount
	    of session state that needs to be maintained by the MB (or by the
	    publishers, in the case of direct communication).  The compromise of
	    the MB does not directly compromise the entire system in this case
	    (though if the MB is authoritative regarding which public keys should
	    be trusted, an attacker who compromises it can always perpetrate a
	    man-in-the-middle attack).
	  </t>

	  <!--
NOTE: the MB should not really be authoritative; we should allow that function to be performed by another entity that can act something like a CA or a group key managemer.  
	<t>
	The requirements are listed based on the notion of using a
	publish-subscribe model whereby a:</t>
-->

        <t>Security requirements using the publish-subscribe
        model include:</t>
        <t><list style="symbols">
            <t>REQ1: Mutual authentication between the Publishers and
            the Message Broker, and the Subscribers and the Message
            Broker, is REQUIRED. Authentication to the Message Broker
            MUST be established as the minimum to determine
            authorization as either a publisher or subscriber.</t>
            <t>REQ2: A Message Broker must exist to determine whether
            the routing element or application is authorized to access
            the particular protocol or interface (e.g. whether it is
            allowed to publish or subscribe).</t>
            <t>REQ3: A Publisher SHOULD define the security properties
            of its protocol or program interface (e.g. how its messages
	    are secured, using TLS for instance).  Its
            transport SHOULD provide confidentiality and MUST provide message authentication.</t>
            <t>REQ4: A Publisher SHOULD
	    describe the latency with which it can deliver messages, 
	    and a Subscriber SHOULD verify that the latency is acceptable.
	    This is needed to protect applications from attacks that 
	    block the timely delivery of critical information.
	    </t>
            <t>REQ5: The I2RS interface's communication channel must
            provide confidentiality and message authentication.</t>
            <t>REQ6: When there are multiple subscribers, it should be
            possible to provide cryptographic authentication in such a
            way that no subscriber can pose as a publisher for which
            it subscribed.</t>
            <t>REQ7: Versioning MUST be supported.  Backwards
            compatibility of interfaces greatly simplifies the system,
            but cannot always be expected.  Version negotiation SHOULD
            be provided, and can be facilitated through the
            publish-subscribe layer as the Message Broker must account
            for the existence of multiple versions of interfaces and
            protocols.</t>
	    <t>
	      REQ8: A discovery mechanism, when used, must be secured.
	      At a minimum, it must be possible to configure an
	      element with information that enables it to authenticate
	      the provider of the discovery service, or the discovered
	      data, and reject data from untrusted sources.  A
	      discovery service SHOULD have the ability to
	      authenticate its clients and choose to withhold
	      information from a client based on its authorizations.
	    </t>
            </list></t>
        
    </section>
    


    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="Security" title="Security Considerations">
	<t> As the interfaces and frameworks being defined within I2RS
	and SDN are purposed to inform, manipulate and control
	topology or behavior of a routing system they must be secured
	through proper authentication and authorization.  Section
	<xref target="Sec-reqmts" /> defines the security requirements
	to address appropriate control access, privacy and
	authenticity.</t>
	
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

          </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors thank Allan Thomson and Anthony Grieco for valuable review and comments on this draft.</t>


    </section>


  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      <!--
      &RFC2119;
      <reference anchor="rti.white.paper">
          <front>
              <title>Towards a publish/subscribe control architecture for precision assembly with the Data Distribution Service</title>
              <author initials="M" surname="Ryll"> </author>
              <date year="2008"/>
              </front>
          <seriesInfo name="Springer" value="IPAS, volume 260 of IFIP, pages 359-369"/>
          </reference>
-->


<!-- 
     &I-D.narten-iana-considerations-rfc2434bis;
-->
      &I-D.ward-i2rs-framework;
      &I-D.amante-i2rs-topology-use-cases;
      &I-D.atlas-i2rs-policy-framework;
      &I-D.atlas-i2rs-problem-statement;

        
    </references>
        
    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <!--
      &RFC2629;
-->


      <reference anchor="manyfaces">
          <front>
              <title>The many faces of publish/subscribe</title>
              <author initials="P" surname="Eugster"> </author>
              <author initials="P" surname="Felber"> </author>
              <author initials="R" surname="Guerraoui"> </author>
              <author initials="A-M" surname="Kermarrec"> </author>
              <date year="2003"/>
              </front>
          <seriesInfo name="ACM" value="Computing Surveys, Volume 35, Issue 2, pages 114-131"/>
          </reference>
	  
        <reference anchor="pub.sub.evolution">
            <front>
                <title>The Evolution of Publish/Subscribe Communication Systems</title>
                <author initials="A" surname="Schiper"> </author>
                <date year="2003"/>
            </front>
            <seriesInfo name="Springer" value="Volume 2584 of Lecture Notes in Computer Science, pages 137-141"/>
        </reference>

<!--
&RFC3552;
-->

    </references>



    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                      v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                      other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                      Modified comments around figure to reflect non-implementation of
                      figure indent control.  Put in reference using anchor="DOMINATION".
                      Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                      added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                      images. Removed meta-characters from comments (causes problems).  -->
  </back>
</rfc>
