One document matched: draft-moskowitz-firstmile-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-netconf-yang-push 
  SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-push.xml">
<!ENTITY I-D.ietf-netconf-yang-library 
   SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-library.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-moskowitz-firstmile-00.txt" ipr="trust200902">

<front>
<title abbrev="first MILE">Security alerts over the first MILE</title>

	<author fullname="Robert Moskowitz" initials="R." surname="Moskowitz" >
	<organization>HTT Consulting</organization>
	<address>
	<postal> 
	  <street> </street>
	  <city>Oak Park</city>
	  <region>MI</region>
	  <code>48237</code> 
	  </postal>
	<email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Susan Hares" initials="S." surname="Hares">
	<organization>Huawei</organization>
	<address>
	<postal> 
	  <street>7453 Hickory Hill</street>
	  <city>Saline</city>
	  <region>MI</region>
	  <code>48176</code>
	  <country>USA</country>
	</postal>
	<email>shares@ndzh.com</email>
	</address>
	</author>
	<author fullname="Liang Xia" initials="L." surname="Xia">
	<organization>Huawei</organization>
	<address>
	  <postal>
		<street>No. 101, Software Avenue, Yuhuatai District</street>
		<city>Nanjing</city>
		<country>China</country>
	  </postal>
	<email>Frank.xialiang@huawei.com</email>
	</address>
	</author>
<date year="2016" />
   <area>Security Area</area>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
<abstract>
<t>
	This document describes a pub/sub styled protocol to send security 
	alerts to a security monitor that can feed into MILE and other 
	management platforms. It uses data structures from NETCONF, MILE, 
	and IPFIX to manage the reporting and report security alerts.
</t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
	This document proposes a set of protocols to automate the reporting 
	of security alerts to the various monitoring systems.  The intent 
	is primarily to automate the input of security events to the MILE 
	environment (RID <xref target="RFC6545" /> and IODEF <xref 
	target="I-D.ietf-mile-rfc5070-bis" />).  Any authorized 
	monitoring system can subscribe to any of the security alerts 
	reports.
</t>
<t>
	An Internet security defense device first registers with a security 
	alert monitoring system.  At this point the content and protocol 
	used has not been identified. Since such a registration is normally 
	at 'quiet time', the registration does not occur during a network 
	congested time and can use some HTTPS-based service.  At this time 
	both systems exchange their X.509 identifiers to be used for the 
	sub/pub security and identification.
</t>
<t>
	Once a defense device is registered, the monitoring system can 
	subscribe to it for those alerts in needs to receive.  The 
	subscription protocol should use NETCONF <xref target="RFC6536" /> 
	with the publication/subscription push service <xref 
	target="I-D.ietf-netconf-yang-push"></xref>. If the system needs a 
	"pull" service, the NETCONF and I2RS subscription service could be 
	expanded to support a pull service. 
</t>	
<t>
	Any secure NETCONF transport that this pub/sub service support can 
	be used.
</t>
<t>
	The defense device publishes security alerts to subscribed monitors 
	using IODEF or IPFIX <xref target="RFC7011" /> data structures.  
	The protocol(s) for these reports are discussed within this 
	document.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
	<section title="Requirements Terminology">
	<t>
		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
		"OPTIONAL" in this document are to be interpreted as described 
		in <xref target="RFC2119">RFC 2119</xref>.
	</t>
	</section>
</section>
<section anchor="prob-space" title="Problem Space">
<t>
	At the time of developing this document, there is no IETF defined 
	set of standardized security alert messages and protocols. 
	Administrators of systems which provide MILE service currently use 
	"cut-and-past" where they cut selected messages from proprietary 
	monitoring systems and past these messages into their MILE 
	environment. The intent here is to standardize and automate this 
	process.  It is recognized that many of these alerts are too 
	detailed to be actionable.  Some implementations of the alert 
	monitor will include analytic tools to select the actionable 
	information from the alerts. Alerts which are too detailed to be 
	actionable or alerts which include analytical tools are outside of 
	any standardizing process.
</t>
<t>
	Many of the needed alerts are scattered throughout the various 
	standards like IPFIX and IODEF, but are not collected together as 
	recognized security alerts that should be aggregated into a 
	reporting framework.
</t>
</section>
<section anchor="firstMILE" title="The first mile of security alerts">
<t>
	There are three components to the first MILE process
	<list style="symbols">
		<t>Register</t>
		<t>Subscribe</t>
		<t>Publish</t>
	</list>
</t>
<section title="Register">
<t>
	An Internet security defense device first registers with a security 
	alert monitoring system.  This is typically done at the time the 
	device is installed, but may occur later as the device is 
	registered to more monitoring systems.  There is no theoretical 
	limit on the number of monitors a device is registered to.  The 
	limit within a system are practical limits based on internal limits 
	within the device.
</t>
<t>
	Most monitors will be commercial and the registration will be based 
	on existing business relationships.  One such example is the ISP's 
	security monitor.  It is possible that a CERT may accept direct 
	registration without a business relationship.  However this may 
	require more study to ensure that this will not introduce potential 
	attacks of false reporting to CERTs.
</t>
<t>
	The actual content of the registration has not been determined.  
	Minimally it needs to include
	<list style="symbols">
		<t>Identifiers (e.g. X.509 certificates)</t>
		<t>Reports available from device (i.e. what to subscribe to)</t>
		<t>Subscription protocols(s)</t>
		<t>Publication protocols(s)</t>
	</list>
	A device can alter any of its registered information at any time as 
	well as cancel a registration.
</t>
</section>
<section title="Subscribe">
<t>
	Once a defense device is registered, the monitoring system can 
	subscribe to it for those alerts in needs to receive.  This is 
	typically done via NETCONF, but is controlled by what the device 
	registered as supported subscript protocols.
</t>
<t>
	A monitor can subscribe or unsubscribe for reports at any time.  
	With the first subscription, a secure communication transport will 
	be enabled from the device to the monitor.  See <xref 
	target="Publish" /> for more on the this secure transport.
</t>
</section>
<section anchor="Publish" title="Publish">
<t>
	The defense device publishes security alerts to subscribed 
	monitors. The reports will be sent over the subscribed protocol 
	using the subscribed data model, either IODEF or IPFIX.
</t>
<t>
	Since these alerts may be reported during an attack that degrades 
	communications, many of the DOTS requirements <xref 
	target="I-D.ietf-dots-requirements" /> apply here.  One that 
	doesn't is the bi-directional requirement.  Even so, the same 
	security and transport design used for DOTS should be used here.
</t>
<t>
	
</t>
</section>
</section>
<section title="first MILE data model">
<t>
	The data model will support the constraints of the NETCONF 
	publication/subscription model <xref 
	target="I-D.ietf-netconf-yang-push"></xref>, and the NETCONF module 
	library function <xref 
	target="I-D.ietf-netconf-yang-library"></xref> which indicates 
	pub/sub support within a model. If the MILE service which to 
	utilize non-persistent (aka ephemeral) data that disappears on 
	reboot, the netconf publication/subscription model will support 
	non-persistent configuration. 
</t>
<t>	Work on the data model is an open item. 
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
	No IANA considerations exist for this document at this time.
</t>
</section>
<section title="Security Considerations">
<t>
	An attacker that can disable first MILE may be able to attack a 
	device at will as those monitoring it expect these attacks to show 
	up on their monitor. As such each part of the firstMILE system will 
	need the complete security services that are defined or referenced 
	here.
</t>
</section>
<section title="Contributors">
<t>
	TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
	&I-D.ietf-netconf-yang-push;
	&I-D.ietf-netconf-yang-library;
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.6536.xml"?>
	<?rfc include="reference.RFC.6545.xml"?>
	<?rfc include="reference.RFC.7011.xml"?>
	<?rfc include="reference.I-D.ietf-mile-rfc5070-bis.xml"?>
	<?rfc include="reference.I-D.ietf-dots-requirements.xml"?>
</references>
</back>
</rfc>