One document matched: draft-behringer-anima-reference-model-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<rfc ipr="trust200902" docName="draft-behringer-anima-reference-model-00" category="info">
<front>
<title abbrev="AN Reference Model">A Reference Model for Autonomic Networking</title>
<author role="editor" fullname="Michael H. Behringer" initials="M.H." surname="Behringer">
<organization>Cisco</organization>
<address>
<email>mbehring@cisco.com</email>
</address>
</author>
<author surname="Carpenter" initials="B. E." fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"/>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region/>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Toerless Eckert" initials="T." surname="Eckert">
<organization>Cisco</organization>
<address>
<email>eckert@cisco.com</email>
</address>
</author>
<date day="17" month="October" year="2014"/>
<area>Operations and Management</area>
<workgroup>ANIMA</workgroup>
<abstract>
<t>
This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The document "Autonomic Networking - Definitions and Design Goals" <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/> explains the fundamental concepts behind Autonomic Networking, and defines the relevant terms in this space. In section 5 it describes a high level reference model. This document defines this reference model with more detail, to allow for functional and protocol specifications to be developed in an architecturally consistent, non-overlapping manner.
</t>
<t>As discussed in <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/>, the goal of this work is not to focus exclusively on fully autonomic nodes or networks. In reality, most networks will run with some autonomic functions, while the rest of the network is traditionally managed. This reference model allows for this hybrid approach.
</t>
</section>
<!-- intro -->
<section anchor="network" title="The Network View">
<t>This section describes the various elements in a network with autonomic functions, and how these entities work together, on a high level. Subsequent sections explain the detailed inside view for each of the autonomic network elements, as well as the network functions (or interfaces) between those elements. </t>
<t>Autonomic entities include:
<list style="symbols">
<t>Network elements: A network element can be a fully or partially autonomic node. It runs autonomic functions, and interacts with other autonomic nodes. </t>
<t>Registrar: Security is a fundamental requirement in an autonomic network. For nodes and services to securely interact without the need to provision shared secrets, a trust infrastructure must be in place. The registrar is the trust anchor in an autonomic domain. </t>
<t>MASA: The MASA is service for devices of a particular vendor. It can validate the identity of devices that are to be used in an autonomic domain, assert which device is owned by which domain, etc. </t>
</list></t>
</section>
<!-- network -->
<section anchor="nodes" title="Entities in an Autonomic Network">
<t>This section describes all the elements in an autonomic network, their function, internal organisation and architecture. In the network view in <xref target="network"/>, this section describes the "boxes". The following sections describes how those boxes interact, and the necessary means to do so (addressing, routing, etc).
</t>
<section anchor="element" title="The Network Element">
<t>This section describes an autonomic network element and its internal architecture. The reference model explained in <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/> shows the sources of information that an autonomic service agent can leverage: Self-knowledge, network knowledge (through discovery), Intent, and feedback loops. Fundamentally, there are two levels inside an autonomic node: the level of autonomic service agents, which uses the functions of the autonomic networking infrastructure. <xref target="ref_model"/> illustrates this concept.
</t>
<t>
<vspace blankLines='100' />
<figure anchor='ref_model'>
<artwork>
+------------------------------------------------------------+
| |
| +-----------+ +------------+ +------------+ |
| | Autonomic | | Autonomic | | Autonomic | |
| | Service | | Service | | Service | |
| | Agent 1 | | Agent 2 | | Agent 3 | |
| +-----------+ +------------+ +------------+ |
| ^ ^ ^ |
| | | | |
| V V V |
|------------------------------------------------------------|
| Autonomic Networking Infrastructure |
| - Data structures (ex: certificates, peer information) |
| - discovery, negotiation and synchronisation functions |
| - intent distribution |
| - aggregated reporting and feedback loops |
| - routing |
|------------------------------------------------------------|
| Standard Operating System Functions |
+------------------------------------------------------------+
</artwork>
</figure>
</t>
<t>The Autonomic Networking Infrastructure (lower part of <xref target="ref_model"/>) contains node specific data structures, for example trust information about itself and its peers, as well as a generic set of functions, independent of a particular usage. This infrastructure should be generic, and support a variety of Autonomic Service Agents (upper part of <xref target="ref_model"/>). The Autonomic Control Plane is the summary of all interactions of the Autonomic Networking Infrastructure with other nodes and services.</t>
<t>The use cases of "Autonomics" such as self-management, self-optimisation, etc, are implemented as Autonomic Service Agents. They use the services and data structures of the underlying autonomic networking infrastructure. The underlying Autonomic Networking Infrastructure should itself be self-managing. </t>
</section>
<!-- element -->
<section anchor="registrar" title="The Registrar Element">
<t>This section describes the registrar function in an autonomic network. It explains the tasks of a registrar element, and how registrars are placed in a network, redundancy between several, etc. [tbc]</t>
</section>
<!-- registrar -->
<section anchor="masa" title="The MASA">
<t>tbc</t>
</section>
<!-- masa -->
</section>
<!-- nodes -->
<section anchor="naming" title="Naming">
<t>Inside a domain, each autonomic device needs a domain specific identifier. [tbc]</t>
</section>
<!-- naming -->
<section anchor="addressing" title="Addressing">
<t>tbc</t>
</section>
<!-- addressing -->
<section anchor="trust" title="Trust Infrastructure">
<t>Autonomic nodes have direct interactions between themselves, which must be secured. Since an autonomic network does not rely on configuration, it is not an option to configure for example pre-shared keys. A trust infrastructure such as a PKI infrastructure must be in place. This section describes the principles of this trust infrastructure. </t>
<t>A completely autonomic way to automatically and securely deploy such a trust infrastructure is to set up a trust anchor for the domain, and then use an approach as in the document "Bootstrapping Key Infrastructures" <xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/>.</t>
</section>
<!-- trust -->
<section anchor="acp" title="Autonomic Control Plane">
<t>This section describes how autonomic nodes interact. In the network view in <xref target="network"/> this section describes the "lines" and "arrows" between nodes. The summary of autonomic interactions forms the "Autonomic Control Plane". This control plane can be either implemented in the global routing table of a node, such as IGPs in today's networks; or it can be provided as an overlay network, as described in <xref target="I-D.behringer-autonomic-control-plane"/>. This section describes the function of the autonomic control plane, independent of its implementation. </t>
<section anchor="discovery" title="Discovery">
<t>Traditionally, most of the information a node requires is provided through configuration or northbound interfaces. An autonomic function should only minimally rely on such northbound interfaces, therefore it needs to discover resources in the network. This section describes various discovery functions in an autonomic network.</t>
<t>Discovering nodes and their properties: A core function to establish an autonomic domain is the discovery of autonomic nodes, primarily adjacent nodes. This may either leverage existing neigbhour discovery mechanisms, or new mechanisms.</t>
<t>Discovering services: Network services such as AAA should also be discovered and not configured. Service discovery is required for such tasks. An autonomic network can either leverage existing service discovery functions, or build a new approach.</t>
</section>
<!-- discovery -->
<section anchor="negotiation" title="Negotiation and Synchronisation">
<t>Autonomic nodes must negotiate and/or synchronise parameters, etc. The document "A Generic Discovery and Negotiation Protocol for Autonomic Networking" <xref target="I-D.carpenter-anima-gdn-protocol"/> explains requirements for negotiation and synchronisation in an autonomic network, and a protocol for this purpose. </t>
</section>
<!-- negotiation -->
<section anchor="intent-distri" title="Intent Distribution">
<t>The distribution of intent is also a function of the Autonomic Control Plane. Various methods can be used to distribute intent across an autonomic domain. </t>
</section>
<!-- intent-distri -->
<section anchor="reporting" title="Reporting">
<t>An autonomic network offers through the autonomic control plane the possibility to aggregate information inside the network, before sending it to the admin of the network. While this can be seen or implemented as a specific form of negotiation, the use case is different and therefore mentioned here explicitly. </t>
</section>
<!-- reporting -->
<section anchor="feedback" title="Feedback Loops">
<t>Feedback loops are required in an autonomic network to allow administrator intervention, while maintaining a default behaviour. Through a feedback loop an administrator can be prompted with a default action, and has the possibility to acknowledge or override the proposed default action.</t>
</section>
<!-- reporting -->
<section anchor="routing" title="Routing">
<t>All autonomic nodes in a domain must be able to communicate with each other, and with autonomic nodes outside their own domain. Therefore, an Autonomic Control Plane relies on a routing function. </t>
</section>
<!-- routing -->
</section>
<!-- acp -->
<section anchor="hybrid" title="Hybrid Approach with Non-Autonomic Functions">
<t>This section explains how autonomic functions can co-exist with non-autonomic functions, and how a potential overlap is managed. (tbc)</t>
</section>
<!-- hybrid -->
<section anchor="security" title="Security Considerations">
<section title="Threat Analysis">
<t>This is a preliminary outline of a threat analysis, to be expanded and made more specific as the various Autonomic Networking specifications evolve.</t>
<t>Since AN will hand over responsibility for network configuration from humans or centrally established management systems to fully distributed devices, the threat environment is also fully distributed. On the one hand, that means there is no single point of failure to act as an attractive target for bad actors. On the other hand, it means that potentially a single misbehaving autonomic device could launch a widespread attack, by misusing the distributed AN mechanisms. For example, a resource exhaustion attack could be launched by a single device requesting large amounts of that resource from all its peers, on behalf of a non-existent traffic load.
Alternatively it could simply send false information to its peers, for example by announcing resource exhaustion when this was not the case.
If security properties are managed autonomically, a misbehaving device could attempt a distributed attack by requesting all its peers to reduce security protections in some way. In general, since autonomic devices run without supervision, almost any kind of undesirable management action could in theory by attempted by a misbehaving device. </t>
<t>If it is possible for an unauthorised device to act as an autonomic device, or for a malicious third party to inject messages appearing to come from an autonomic device, all these same risks would apply. </t>
<t>If AN messages can be observed by a third party, they might reveal valuable information about network configuration, security precautions in use, individual users, and their traffic patterns. If encrypted, AN messages might still reveal some information via traffic analysis, but this would be quite limited (for example, this would be highly unlikely to reveal any specific information about user traffic). AN messages are liable to be exposed to third parties on any unprotected Layer 2 link, and to insider attacks even on protected Layer 2 links. </t>
</section>
</section>
<!-- security -->
<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA. </t>
</section>
<!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>tbc</t>
</section>
<!-- ack -->
<section anchor="changes" title="Change log [RFC Editor: Please remove]">
<t>
<list>
<t>00: Initial version.</t>
</list>
</t>
</section>
<!-- changes -->
</middle>
<back>
<references title="References">
<?rfc include="reference.I-D.pritikin-bootstrapping-keyinfrastructures.xml"?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>
<?rfc include="reference.I-D.behringer-autonomic-control-plane.xml"?>
<?rfc include="reference.I-D.carpenter-anima-gdn-protocol.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 02:59:11 |