Internet Engineering Task Force K. Beck
Internet-Draft N. Cam-Winget
Intended status: Informational D. McGrew
Expires: January 12, 2014 Cisco Systems
July 11, 2013
Using the Publish-Subscribe Model in the Interface to the Routing System
draft-camwinget-i2rs-pubsub-sec-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Beck, et al. Expires January 12, 2014 [Page 1]
Internet-Draft Using Pub-Sub in I2RS July 2013
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Beck, et al. Expires January 12, 2014 [Page 2]
Internet-Draft Using Pub-Sub in I2RS July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Publish-Subscribe Models . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. An I2RS Publish-Subscribe Model . . . . . . . . . . . . . . . 5
3.1. Role of the Message Broker . . . . . . . . . . . . . . . . 6
4. Proposed Taxonomy based on Use Cases . . . . . . . . . . . . . 6
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Beck, et al. Expires January 12, 2014 [Page 3]
Internet-Draft Using Pub-Sub in I2RS July 2013
1. Introduction
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.
2. Publish-Subscribe Models
There are two classical publish-subscribe models: topic- or content-
based [manyfaces][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.
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.
2.1. Terminology
o 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.
o Subscriber: defines an interested routing element or application
requiring access to a protocol or programmatic interface.
o 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.
Beck, et al. Expires January 12, 2014 [Page 4]
Internet-Draft Using Pub-Sub in I2RS July 2013
3. An I2RS Publish-Subscribe Model
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 [I-D.amante-i2rs-topology-use-cases] and
[I-D.ward-i2rs-framework], respectively, describe the need for
interfaces with varying capabilities. The characteristics of these
capabilities include:
o Time delivery sensitivity: interfaces or operations to be executed
in the I2RS may come with different time constraints. Per section
3.5 of [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.
o 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.
o 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.
o 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.
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
[I-D.amante-i2rs-topology-use-cases] and
[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.
Beck, et al. Expires January 12, 2014 [Page 5]
Internet-Draft Using Pub-Sub in I2RS July 2013
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.
3.1. Role of the Message Broker
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.
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).
4. Proposed Taxonomy based on Use Cases
Suggested architectures of the I2RS system contains I2RS Clients
[I-D.amante-i2rs-topology-use-cases]
[I-D.atlas-i2rs-problem-statement] (also called Commissioners
[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.
Beck, et al. Expires January 12, 2014 [Page 6]
Internet-Draft Using Pub-Sub in I2RS July 2013
A suggestive network architecture diagram from [I-D.atlas-i2rs-
problem-statement] below:
Beck, et al. Expires January 12, 2014 [Page 7]
Internet-Draft Using Pub-Sub in I2RS July 2013
+***************+ +***************+ +***************+
* 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
Beck, et al. Expires January 12, 2014 [Page 8]
Internet-Draft Using Pub-Sub in I2RS July 2013
I2RS Architectural Model
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.
As suggested, the standards used would be publish-subscribed as a new
layer to improve the overall system scalability and facilitate
operations such as:
o 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.
o 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.
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:
Application
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.
Router
The network element that supports the I2RS interface acts as a
northbound API. This may include an I2RS Agent or Server.
Beck, et al. Expires January 12, 2014 [Page 9]
Internet-Draft Using Pub-Sub in I2RS July 2013
Areas where publish-subscribe can be deployed to satisfy stated
requirements and use cases:
Asynchronous Router to application notifications
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.
Many to Many
[I-D.amante-i2rs-topology-use-cases] and
[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.
Topology
[I-D.amante-i2rs-topology-use-cases] and
[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
Beck, et al. Expires January 12, 2014 [Page 10]
Internet-Draft Using Pub-Sub in I2RS July 2013
network topology as well as an asynchronous method to learn
the changes and updates to that topology as they occur.
RIB Updates
[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.
Policy Management
[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.
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:
BGP Error Notifications. Notification of Routing Events.
BGP Protocol Statistics. Routing agents could publish BGP errors,
other BGP events and BGP statistics on the router.
Tracing Dropped BGP Routes. Routers can publish learning of BGP
routes which would enable applications the monitor the propagation
of routes through the AS.
5. Security Requirements
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.
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
Beck, et al. Expires January 12, 2014 [Page 11]
Internet-Draft Using Pub-Sub in I2RS July 2013
many subscribers to a topic, and there may be more than one publisher
on a topic as well.
Published data requires the following protections, which are stated
in terms of a specific topic:
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.
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.
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.
Confidentiality: it should not be possible for any entity other
than a subscriber to read the messages.
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.
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
Beck, et al. Expires January 12, 2014 [Page 12]
Internet-Draft Using Pub-Sub in I2RS July 2013
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.
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.
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).
Security requirements using the publish-subscribe model include:
o 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.
Beck, et al. Expires January 12, 2014 [Page 13]
Internet-Draft Using Pub-Sub in I2RS July 2013
o 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).
o 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.
o 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.
o REQ5: The I2RS interface's communication channel must provide
confidentiality and message authentication.
o 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.
o 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.
o 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.
6. Security Considerations
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 Section 5 defines the
security requirements to address appropriate control access, privacy
and authenticity.
Beck, et al. Expires January 12, 2014 [Page 14]
Internet-Draft Using Pub-Sub in I2RS July 2013
7. IANA Considerations
This memo includes no request to IANA.
8. Acknowledgements
The authors thank Allan Thomson and Anthony Grieco for valuable
review and comments on this draft.
9. References
9.1. Normative References
[I-D.amante-i2rs-topology-use-cases]
Amante, S., Medved, J., Previdi, S., and T. Nadeau,
"Topology API Use Cases",
draft-amante-i2rs-topology-use-cases-00 (work in
progress), February 2013.
[I-D.atlas-i2rs-policy-framework]
Atlas, A., Hares, S., and J. Halpern, "A Policy Framework
for the Interface to the Routing System",
draft-atlas-i2rs-policy-framework-00 (work in progress),
February 2013.
[I-D.atlas-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement",
draft-atlas-i2rs-problem-statement-00 (work in progress),
February 2013.
[I-D.ward-i2rs-framework]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Framework", draft-ward-i2rs-framework-00
(work in progress), February 2013.
9.2. Informative References
[manyfaces]
Eugster, P., Felber, P., Guerraoui, R., and A-M.
Kermarrec, "The many faces of publish/subscribe",
ACM Computing Surveys, Volume 35, Issue 2, pages 114-131,
2003.
[pub.sub.evolution]
Schiper, A., "The Evolution of Publish/Subscribe
Beck, et al. Expires January 12, 2014 [Page 15]
Internet-Draft Using Pub-Sub in I2RS July 2013
Communication Systems", Springer Volume 2584 of Lecture
Notes in Computer Science, pages 137-141, 2003.
Authors' Addresses
Ken Beck
Cisco Systems
Email: kebeck@cisco.com
Nancy Cam-Winget
Cisco Systems
Email: ncamwing@cisco.com
David McGrew
Cisco Systems
Email: mcgrew@cisco.com
Beck, et al. Expires January 12, 2014 [Page 16]