One document matched: draft-camwinget-i2rs-pubsub-sec-00.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:18 |