One document matched: draft-hares-i2nsf-mgtflow-reqs-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2330.xml">
<!ENTITY RFC3176 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3176.xml">
<!ENTITY RFC5070 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5070.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC7011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7011.xml">
<!ENTITY RFC7312 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7312.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.hares-i2rs-protocol-strawman SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-protocol-strawman.xml">
<!ENTITY I-D.ietf-i2rs-protocol-security-requirements 
            SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-protocol-security-requirements.xml">
<!ENTITY I-D.ietf-dots-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dots-requirements.xml">
<!ENTITY I-D.ietf-mile-rfc5070-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mile-rfc5070-bis.xml">
<!ENTITY I-D.ietf-i2nsf-problem-and-use-cases
    SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2nsf-problem-and-use-cases.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.hares-i2rs-dataflow-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-dataflow-req.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2nsf-mgtflow-reqs-01.txt"  ipr="trust200902">
  <front>
    <title abbrev="I2NSF Mangement Flow ">I2NSF Management Traffic Flow Requirement</title>

	<author fullname="Susan Hares" initials="S." surname="Hares">
	<organization> Huawei </organization>
	<address>
	  <postal>
	   <street></street>
	    <city>Saline</city>
		<country>US</country>
	  </postal>
	 <email>shares@ndzh.com </email>
	</address>
	</author>
	 
    <date year="2016" />
    <area>Routing Area</area>
    <workgroup>I2RS working group</workgroup>
    <keyword>RFC</keyword>
    <keyword>Request for Comments</keyword>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>I2RS</keyword>
    <abstract>
      <t>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.  
   </t>
	 </abstract>
  </front>
 <middle>
<section anchor="intro" title="Introduction">
   <t>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 (<xref target="I-D.ietf-i2nsf-problem-and-use-cases"></xref>
   indicates that service providers lack a standard management interface    
   which preserves:</t>
   <t>
   <list style="symbols">
   <t>critical communications during DDoS attacks (DOTS), </t>
   <t> allows hosts to continue even during the DDoS attacks, </t>
   <t>aids reporting of these attacks the CERT (MILE), 
   </t>
   <t> and manages network connnectivity of devices out of compliance (SACM).</t>
   </list>
   </t>
   <t>
   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. 
   </t>
   </section> 
   <section title="Stresses on traffic between I2NSF and vNSF/NSF"> 
   <t>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 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. 
   </t>
   <t>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.  
   </t>
   <t>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. 
   </t>
   <section title="DOTS (DDoS Open Threat Signaling) Management Traffic">
<t>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. 
</t>
<t>
The DOTS requirements for messages from devices
with security functions (such as firewalls in routing devices)
are specified in: <xref target="I-D.ietf-dots-requirements"></xref>.
The following are DOTS descriptions of the resiliency needed
by the management data: </t>
<t><list style="symbols">
<t>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,
 </t>
 <t>Small message sizes (DOTS-G-005) to prevent fragmentation so that
 all of the message goes through in attack, </t>
 <t>Message integrity (G-006) and Message level replay protection (G-007)
must exist for data streams even during periods of attack, 
</t>
 <t>Session-level Health monitoring (aka Heart beats) during 
attack (DOTS-OP-003), and </t>
<t>Abiilty to request/stop mitigation quickly (DOTS-OP-005)</t>
</list>
</t>
</section>
<section title="MILE - Managed Incident Lightweight Exchange ">
<t>Reporting and managing security incident traffic is being 
investigated by the MILE working group.  The MILE related 
protocols (<xref target="RFC5070"></xref>,  
<xref target="I-D.ietf-mile-rfc5070-bis"></xref>) 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.  
</t>
</section> 
</section> 
<section title="Stresses on I2NSF controller to User traffic">
<t>
The user application communicating with the network security controller 
uses the I2NSF protocol to: 
<list style="symbols">
<t>give commands that direct the actions of the Network Security Controller
during normal operation and during periods of security attack,</t>
<t>give commands to direct the creation of policy on the Network Security controller, or
on the NSF or vNSF devices, </t>
<t>receive reports on the status of network security including DDoS attacks, 
outages, and devices operating outside the appropriate security software or 
actions, and </t>
<t>give commands to link the network security controller to additional 
resources (e.g. CERT for incident report or additional IDS/IPS services)/</t>
</list>
</t>
<t>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).
</t>
</section>
<section title="I2NSF Management Traffic Flow Needs">
<t> 
 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: 
<list style="symbols">
<t>data flow resilence, 
</t>
<t>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, 
</t>
<t>message integrity and replay protection, 
</t>
</list>
</t>
<t>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. 
</t>
</section> 
<section title="I2NSF Protocol with Session Layer Services">
<t>
The diagram in figure 1 shows how a secure session service (SSE)
at the application layer of the I2NSF protocol that
could provide these 
<figure>
<artwork>
 +----------+     +----------------+     +-------+
 |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 
	
</artwork>
</figure>
</t>
</section>
<section title="Impact of I2NSF potential use of I2RS protocol">
<t>
I2NSF protocol may want to consider extending the I2RS protocol
<xref target="I-D.hares-i2rs-protocol-strawman"></xref>
for communication to routers/switches that have onboard security functions. 
The first version of the I2RS protocol will support communication 
by NETCONF <xref target="RFC6241"></xref> (with extensions), RESTCONF 
<xref target="I-D.ietf-netconf-restconf"></xref> (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. 
</t>
</section>

<section anchor="IANA" title="IANA Considerations">
      <t>There are no IANA requirements for this 
	   requirementdocument.</t>
    </section>
 <section title="Security Considerations">
      <t>TBD 
	  </t>
    </section>
<section anchor="Acknowledgements" title="Acknowledgements">
	<t>
    The following people have aided in the discussion 
	    <list style="symbols">
	    <t>Russ White,and </t>
		<t>Robert Moskowitz.</t>
	    </list>
	</t>
</section>
</middle>
  <back>
    <references title="Normative References">
      &RFC2119;
	</references>
    <references title="Informative References">
	  &RFC5070;
	  &RFC6241;
	 &I-D.ietf-i2rs-architecture;
	 &I-D.hares-i2rs-protocol-strawman;
 	 &I-D.hares-i2rs-dataflow-req;
 	 &I-D.ietf-netconf-restconf;
	 &I-D.ietf-dots-requirements;
	 &I-D.ietf-i2nsf-problem-and-use-cases;
	 &I-D.ietf-mile-rfc5070-bis;
    </references>
  </back>
</rfc>