draft-ietf-sacm-requirements-12.txt   draft-ietf-sacm-requirements-13.txt 
SACM N. Cam-Winget SACM N. Cam-Winget
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Lorenzin Intended status: Informational L. Lorenzin
Expires: July 25, 2016 Pulse Secure Expires: September 18, 2016 Pulse Secure
January 22, 2016 March 17, 2016
Security Automation and Continuous Monitoring (SACM) Requirements Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-12 draft-ietf-sacm-requirements-13
Abstract Abstract
This document defines the scope and set of requirements for the This document defines the scope and set of requirements for the
Secure Automation and Continuous Monitoring (SACM) architecture, data Secure Automation and Continuous Monitoring (SACM) architecture, data
model and transport protocols. The requirements and scope are based model and transport protocols. The requirements and scope are based
on the agreed upon use cases. on the agreed upon use cases.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2016. This Internet-Draft will expire on September 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 31 skipping to change at page 4, line 31
2.1. Requirements for SACM 2.1. Requirements for SACM
Many deployment scenarios can be instantiated to address the above Many deployment scenarios can be instantiated to address the above
tasks and use cases defined in [RFC7632]. To ensure tasks and use cases defined in [RFC7632]. To ensure
interoperability, scalability, and flexibility in any of these interoperability, scalability, and flexibility in any of these
deployments, the following requirements are defined for proposed SACM deployments, the following requirements are defined for proposed SACM
standards: standards:
G-001 Solution Extensibility: The information model, data models, G-001 Solution Extensibility: The information model, data models,
protocols, and transports defined by SACM MUST be designed to allow protocols, and transports defined by SACM MUST be designed to allow
support for future (SACM) extensions. SACM SHOULD allow support for future (SACM) extensions. SACM MUST allow
implementations to use their own extensions; either proprietary data implementations to use their own extensions; either proprietary data
models, protocols or extensions to SACM data models or protocols models, protocols or extensions to SACM data models or protocols
could be used though they are not considered to be SACM compliant. could be used though they are not considered to be SACM compliant.
1. The information model and programmatic interfaces (see G-012 for 1. The information model and programmatic interfaces (see G-012 for
one example) MUST support the ability to add new operations one example) MUST support the ability to add new operations
while maintaining backwards compatibility. SACM-defined while maintaining backwards compatibility. SACM-defined
transport protocols MUST have extensibility to allow them to transport protocols MUST have extensibility to allow them to
transport operations that are defined in the future. transport operations that are defined in the future.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
protocol standard SHOULD include a section on scalability protocol standard SHOULD include a section on scalability
considerations that addresses the number of endpoints and amount of considerations that addresses the number of endpoints and amount of
information to which it can reasonably be expected to scale. information to which it can reasonably be expected to scale.
Scalability must be addressed to support: Scalability must be addressed to support:
* Large datagrams: It is possible that the size of posture * Large datagrams: It is possible that the size of posture
assessment information can vary from a single assessment that is assessment information can vary from a single assessment that is
small in size to a very large datagram or a very large set of small in size to a very large datagram or a very large set of
assessments (up to multiple gigabytes in size). assessments (up to multiple gigabytes in size).
* Large number of datagrams per second: A deployment may involve
many rapid or simultaneous events that require processing,
generating many datagrams per second.
* Large number of providers and consumers: A deployment may consist * Large number of providers and consumers: A deployment may consist
of a very large number of endpoints requesting and/or producing of a very large number of endpoints requesting and/or producing
posture assessment information. posture assessment information.
* Large number of target endpoints: A deployment may be managing * Large number of target endpoints: A deployment may be managing
information of a very large number of target endpoints. information of a very large number of target endpoints.
G-004 Versatility: The data model, protocols, and transports MUST be G-004 Versatility: The data model, protocols, and transports MUST be
suitably specified to enable implementations to fit into different suitably specified to enable implementations to fit into different
deployment models and scenarios, including considerations for deployment models and scenarios, including considerations for
skipping to change at page 6, line 48 skipping to change at page 7, line 5
G-011 Push and Pull Access: Three methods of data access MUST be G-011 Push and Pull Access: Three methods of data access MUST be
supported: a Pull model, a solicited Push model, and an unsolicited supported: a Pull model, a solicited Push model, and an unsolicited
Push models. All of the methods of data access MUST support the Push models. All of the methods of data access MUST support the
ability for the initiator to filter the set of posture assessment ability for the initiator to filter the set of posture assessment
information to be delivered. Additionally, the provider of the information to be delivered. Additionally, the provider of the
information MUST be able to filter the set of posture assessment information MUST be able to filter the set of posture assessment
information based on the permissions of the recipient. This information based on the permissions of the recipient. This
requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5.
G-012 Device Interface: The interfaces by which SACM components G-012 SACM Component Interface: The interfaces by which SACM
communicate to share endpoint posture information MUST be well components communicate to share endpoint posture information MUST be
defined. That is, the interface defines the data model, SACM well defined. That is, the interface defines the data model, SACM
transport protocols, and network transport protocols to enable SACM transport protocols, and network transport protocols to enable SACM
components to communicate. components to communicate.
G-013 Endpoint Location and Network Topology: The SACM architecture G-013 Endpoint Location and Network Topology: The SACM architecture
and interfaces MUST allow for the target endpoint (network) location and interfaces MUST allow for the target endpoint (network) location
and network topology to be modeled and understood. Where and network topology to be modeled and understood. Where
appropriate, the data model and the interfaces SHOULD allow for appropriate, the data model and the interfaces SHOULD allow for
discovery of the target endpoint location or network topology or discovery of the target endpoint location or network topology or
both. both.
skipping to change at page 14, line 35 skipping to change at page 14, line 35
that enables and disables confidentiality in deployments. that enables and disables confidentiality in deployments.
Protection for data at rest is not in scope for transport protocols. Protection for data at rest is not in scope for transport protocols.
Data protection MAY be used for both privacy and non-privacy Data protection MAY be used for both privacy and non-privacy
scenarios. scenarios.
T-004 Transport Protection: SACM transport protocols MUST be capable T-004 Transport Protection: SACM transport protocols MUST be capable
of supporting mutual authentication and replay protection. of supporting mutual authentication and replay protection.
T-005 Transport Reliability: SACM transport protocols MUST provide T-005 Transport Reliability: SACM transport protocols MUST provide
reliable delivery of data. This includes the ability to perform reliable delivery of data. This includes the ability to perform
fragmentation and reassembly, and to detect replays. fragmentation and reassembly, and to detect replays. The SACM
transport may take advantage of reliability features in the network
transport; however, the network transport may be unreliable (e.g.
UDP), in which case the SACM transport running over the unreliable
network transport is responsible for ensuring reliability (i.e. by
provisions such as confirmations and re-transmits).
T-006 Transport Layer Requirements: Each SACM transport protocol T-006 Transport Layer Requirements: Each SACM transport protocol
MUST clearly specify the transport layer requirements it needs to MUST clearly specify the transport layer requirements it needs to
operate correctly. Examples of items that may need to be specified operate correctly. Examples of items that may need to be specified
include connectivity requirements, replay requirements, data link include connectivity requirements, replay requirements, data link
encryption requirements, and/or channel binding requirements. These encryption requirements, and/or channel binding requirements. These
requirements are needed in order for deployments to be done requirements are needed in order for deployments to be done
correctly. For example, a proxy server between UDP and TCP can correctly. For example, a proxy server between UDP and TCP can
provide a connection that correctly fulfills the connectivity and provide a connection that correctly fulfills the connectivity and
replay requirements as well as data link requirements (through the replay requirements as well as data link requirements (through the
 End of changes. 7 change blocks. 
9 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/