I2RS working group S. Hares Internet-Draft Huawei Intended status: Standards Track March 20, 2016 Expires: September 21, 2016 I2NSF Management Traffic Flow Requirement draft-hares-i2nsf-mgtflow-reqs-01.txt Abstract This document discuss the stresses on I2NSF management traffic during periods DDoS and network attacks, and how application layer tuning of I2NSF management traffic can improve the managementtraffic flow. 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 September 21, 2016. Copyright Notice Copyright (c) 2016 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 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. Hares Expires September 21, 2016 [Page 1] Internet-Draft I2NSF Mangement Flow March 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Stresses on traffic between I2NSF and vNSF/NSF . . . . . . . 2 2.1. DOTS (DDoS Open Threat Signaling) Management Traffic . . 3 2.2. MILE - Managed Incident Lightweight Exchange . . . . . . 4 3. Stresses on I2NSF controller to User traffic . . . . . . . . 4 4. I2NSF Management Traffic Flow Needs . . . . . . . . . . . . . 4 5. I2NSF Protocol with Session Layer Services . . . . . . . . . 5 6. Impact of I2NSF potential use of I2RS protocol . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Interface to the Network Security Function (I2NSF) Working Group is chartered with providing architecture and mechanisms to inject into and retrieve information from network security devices. The I2NSF problem statement ([I-D.ietf-i2nsf-problem-and-use-cases] indicates that service providers lack a standard management interface which preserves: o critical communications during DDoS attacks (DOTS), o allows hosts to continue even during the DDoS attacks, o aids reporting of these attacks the CERT (MILE), o and manages network connnectivity of devices out of compliance (SACM). This document describes the stress on I2NSF management traffic during DDoS and network attacks/incidents, and some mechanisms that help traffic flow during these periods. I2NSF considers two directions: I2NSF controller to NSF/vNSF, and I2NSF user to I2NSF controller. 2. Stresses on traffic between I2NSF and vNSF/NSF During periods of DDoS attacks, I2NSF management traffic may encounter high error rates, congestion, restricted bandwidth caused by DDoS related traffic (ICMP spams, transport protocol SYN attacks, port spams, and others.), or attacks on specific network machines. Message integrity may be compromised by attacks on the transport Hares Expires September 21, 2016 [Page 2] Internet-Draft I2NSF Mangement Flow March 2016 protocols, or by replay attacks on message sequence. However, during this same time period the I2NSF controller needs to send to NSFs/ vNSFs new filter policies or other configuration changes. IDS/IPS NSF functions may need to send I2NSF controller information to help detect the attack source or stop the attack. During DDOS attacks or network security incidents, the client programs may want to receive status information from the I2NSF controller. This communication will also be impacted by the high error rates, congestion, and restricted bandwidth caused by DDoS related traffic or network security attacks. This stress can be illustrated by examining two types of management traffic which need to be exchanged with the I2NSF controller: DDoS Open Threat Signaling (DOTS) traffic, and security incident (CERT) traffic reports. 2.1. DOTS (DDoS Open Threat Signaling) Management Traffic Sending information about DDoS threats occurs during periods where the DDoS is congesting the network or causing large packet losses. I2NSF controllers may receive requests from DOTS controllers to configure new network security functions (NSFs) or reconfigure existing security functions on vNSF or NSF devices. I2NSF controllers may need to receive specific events from vNSF/NSF devices, and receive traffic monitoring data and logs regarding network security incidents. The DOTS requirements for messages from devices with security functions (such as firewalls in routing devices) are specified in: [I-D.ietf-dots-requirements]. The following are DOTS descriptions of the resiliency needed by the management data: o Resilence (DOTS-G-003) in the face of severally constrained severely constrained network conditions imposed by the attack traffic. The protocol SHOULD be resilient, that is, continue operating despite message loss and out-of-order or redundant signal delivery, o Small message sizes (DOTS-G-005) to prevent fragmentation so that all of the message goes through in attack, o Message integrity (G-006) and Message level replay protection (G-007) must exist for data streams even during periods of attack, o Session-level Health monitoring (aka Heart beats) during attack (DOTS-OP-003), and Hares Expires September 21, 2016 [Page 3] Internet-Draft I2NSF Mangement Flow March 2016 o Abiilty to request/stop mitigation quickly (DOTS-OP-005) 2.2. MILE - Managed Incident Lightweight Exchange Reporting and managing security incident traffic is being investigated by the MILE working group. The MILE related protocols ([RFC5070], [I-D.ietf-mile-rfc5070-bis]) provide data formats for reporting network security incidents during time periods of network attack. Similar to DOTS, the data passed by these protocols requires resilience, message integrity, message level replay protection, and session-level health monitoring. During these attacks, the use of small message sizes may be necessary. 3. Stresses on I2NSF controller to User traffic The user application communicating with the network security controller uses the I2NSF protocol to: o give commands that direct the actions of the Network Security Controller during normal operation and during periods of security attack, o give commands to direct the creation of policy on the Network Security controller, or on the NSF or vNSF devices, o receive reports on the status of network security including DDoS attacks, outages, and devices operating outside the appropriate security software or actions, and o give commands to link the network security controller to additional resources (e.g. CERT for incident report or additional IDS/IPS services)/ The communication to perform security operations may encounter DDoS and network attack related outages, network congestion (bursts of congestion or time periods of congestion), and specific network attacks on messages protocols (E.g. TCP syn attacks, ICMP based attacks). 4. I2NSF Management Traffic Flow Needs The I2NSF communication needs to support application layer services that handle the transport layer's failure to support critical communication. These application services must provide the following to preserve the end-to-end communication between I2NSF controller to NSF/vNSF and between I2NSF controller and the user: o data flow resilence, Hares Expires September 21, 2016 [Page 4] Internet-Draft I2NSF Mangement Flow March 2016 o breaking the data traffic into appropriate sizes for pass through congestion (aka "chunking" the data) and re-assembly of data prior to handing to application, o message integrity and replay protection, Each I2NSF agent and I2NSF client needs to provide this support at the application level since security attacks often attack the tranport connections. This is true whether the communication is between the I2NSF Controller to vNSF/NSF device, or between the user's client device and the I2NSF controller. 5. I2NSF Protocol with Session Layer Services The diagram in figure 1 shows how a secure session service (SSE) at the application layer of the I2NSF protocol that could provide these +----------+ +----------------+ +-------+ |I2NSF User| tcp |I2NSF Controller| tcp | NSF | | SSE -|-----|SSE layer------|------SSE | | | | UDP | | | | | | |----------| | | | | | | | | | +----------+ +----------------+ +-------+ SSE outbound inbound +---------------------------------+ | | replay checks | +---------------------------------+ | Chunking | combining chunks | +--------------+------------------+ | integrity | integrity | | checks | checks | +--------------+------------------+ |transport pack| transport upack | | transport/net| transport/net | | congestion | congestion | | monitoring | monitoring | +--------------+------------------+ Figure 1 6. Impact of I2NSF potential use of I2RS protocol I2NSF protocol may want to consider extending the I2RS protocol [I-D.hares-i2rs-protocol-strawman] for communication to routers/ switches that have onboard security functions. The first version of Hares Expires September 21, 2016 [Page 5] Internet-Draft I2NSF Mangement Flow March 2016 the I2RS protocol will support communication by NETCONF [RFC6241] (with extensions), RESTCONF [I-D.ietf-netconf-restconf] (with extensions), and other protocols. The I2RS working group is seeking feedback on management traffic during network outages (security related or network connectivity related) in order to determine what protocols are needed beyond NETCONF and RESTCONF. This management traffic includes configuration, events, log information, alerts, traffic monitoring information, traffic statistics, and end-to-end performance information. I2NSF could help the I2RS working group determine the security management information needed to be passed to NSF or vNSF functions in routers. 7. IANA Considerations There are no IANA requirements for this requirementdocument. 8. Security Considerations TBD 9. Acknowledgements The following people have aided in the discussion o Russ White,and o Robert Moskowitz. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.hares-i2rs-dataflow-req] Hares, S., "I2RS Data Flow Requirements", draft-hares- i2rs-dataflow-req-01 (work in progress), March 2016. [I-D.hares-i2rs-protocol-strawman] Hares, S., "I2RS protocol strawman", draft-hares-i2rs- protocol-strawman-00 (work in progress), March 2016. Hares Expires September 21, 2016 [Page 6] Internet-Draft I2NSF Mangement Flow March 2016 [I-D.ietf-dots-requirements] Mortensen, A., Moskowitz, R., and T. Reddy, "DDoS Open Threat Signaling Requirements", draft-ietf-dots- requirements-00 (work in progress), October 2015. [I-D.ietf-i2nsf-problem-and-use-cases] Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. Jacquenet, "I2NSF Problem Statement and Use cases", draft- ietf-i2nsf-problem-and-use-cases-00 (work in progress), February 2016. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-13 (work in progress), February 2016. [I-D.ietf-mile-rfc5070-bis] Danyliw, R., "The Incident Object Description Exchange Format v2", draft-ietf-mile-rfc5070-bis-16 (work in progress), February 2016. [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-10 (work in progress), March 2016. [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, DOI 10.17487/RFC5070, December 2007, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . Author's Address Susan Hares Huawei Saline US Email: shares@ndzh.com Hares Expires September 21, 2016 [Page 7]