Subject: [ipfix-req] IPFIX security considerations for requirements document

From: "Carter Bullard" <[email-masked]>
Date: Wed, 8 May 2002 10:55:30 -0400

Hey Tanja,
   Can I make a suggestion on wording for the section on Forgery?  It
may see like a minor thing, but I think its important.

> - Forgery of IPFIX flow records
> Especially for applications like accounting or intrusion
> detection there are strong incentives (e.g. to save money
> or prevent the detection of an attack) to forge exported
> IPFIX  flow records. This can be done either by altering
> data (flow records) on the path or by injecting 
> forged flow records that pretend to be originated by
> the original exporting process.

I know what you're after, but it kinda sounds like there
is an incentive for the accounting or intrusion detection system to
forge records.  How's this as an alternative?

- Forgery of IPFIX flow records
Because of the potential uses of IPFIX flow records in applications such
as accounting and security, there is a strong need to provide source
authentication and integrity assurance/protection for IPFIX data.

Hope this helps,

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> -----Original Message-----
> From: majordomo listserver
> [mailto:[email-masked]] On Behalf Of Tanja Zseby
> Sent: Wednesday, May 08, 2002 10:19 AM
> To: Jürgen Quittek
> Cc: Benoit Claise; Sebastian Zander; Georg Carle; K.C. 
> Norseth; IPFIX Requirements
> Subject: [ipfix-req] IPFIX security considerations for 
> requirements document
> 
> 
> Hi Jürgen and others,
> 
> attached you can find the re-worked security considerations
> section for 
> the IPFIX requirements draft. 
> If you think there are additional threads that needs to be covered or 
> have further comments, send them to me via email. We also can discuss 
> this in our next teleconfernce (May 17).
> 
> Regards
> Tanja
> 
> Security considerations
> 
> The future IPFIX protocol must be capable to transport data over the
> public Internet. Therefore it cannot be excluded that an attacker can 
> gain access to the network and capture exchanged packets.
> This document describes requirements for IP Flow Information Export 
> (IPFIX). It therefore also states the required security 
> features for a 
> future IPFIX protocol. Like other requirements, the security 
> requirements differ for the considered applications. The incentive to 
> modify collected data for accounting or intrusion detection 
> for instance 
> is usually higher than the incentive to change data collected for 
> traffic profiling. Therefore the required security features in this 
> document are listed per application in the appendix.
> The suggestion of concrete solutions for achieving the 
> required security 
> properties
> will be part of the IPFIX architecture and protocol 
> description and is 
> out of scope of this document. Furthermore, methods for remote 
> configuration of the IPFIX processes are out of scope for IPFIX. 
> Therefore, threads that are caused by data exchange for remote 
> configuration are not considered here.
> 
> The following potential security hazards for an IPFIX protocol can be
> identified:
> 
> - Disclosure of IP flow information data
> The content of IPFIX flow records should be kept confidential between
> the involved parties (exporting process and colleting 
> process) user and 
> provider). Observation of IPFIX  flow records gives an attacker 
> information about the active flows in the network, communication 
> endpoints and traffic patterns. This information can not only 
> be used to 
> spy out user behavior but also to plan and conceal future attacks. 
> Therefore the requirements document recommends to ensure the 
> confidentiality of the transferred data. This can be achieved for 
> instance by encryption.
> 
> - Forgery of IPFIX flow records
> Especially for applications like accounting or intrusion
> detection there 
> are strong incentives (e.g. to save money or prevent the 
> detection of an 
> attack) to forge exported IPFIX  flow records. This can be 
> done either 
> by altering data (flow records) on the path or by injecting 
> forged flow 
> records that pretend to be originated by the original 
> exporting process. 
> In order to make the IPFIX protocol resistant against such 
> attacks this 
> document requires to ensure authenticity and integrity for the IPFIX 
> data transfer.
> Special caution is required if security applications rely on 
> IPFIX data 
> With forged flow records it is possible to trick on security 
> applications. It is for instance possible to pretend that a 
> DoS attack 
> happens without even launching a real attack.
> 
> - Denial of Service (DoS) attacks
> DoS attacks on routers or other middleboxes that have the
> IPFIX protocol 
> implemented would also affect the IPFIX protocol and impair 
> the sending 
> of IPFIX records. Nevertheless, since such hazards are not induced 
> specifically by the IPFIX protocol the prevention of such 
> attacks is out 
> of scope of this document.
> 
> Nevertheless IPFIX itself also causes potential hazards for
> DoS attacks. 
> All process that expect the reception of traffic can be 
> target of a DoS 
> attack. With the IPFIX exporting process this is only the case if it 
> supports the pull mode (which can be an optional feature of 
> the future 
> IPFIX protocol according to this document). The collecting process 
> always expects data and therefore can be flooded by forged 
> flow records.
> 
> 
> -- 
> Dipl.-Ing. Tanja Zseby			    	      	
> FhI FOKUS/Global Networking			Email: 
> [email-masked]	
> Kaiserin-Augusta-Allee 31				Phone: 
> +49-30-3463-7153
> D-10589 Berlin, Germany				Fax:   
> +49-30-3463-8153
> --------------------------------------------------------------
> ------------------------
> "Living on earth is expensive but it includes a free trip 
> around the sun." (Anonymous)
> --------------------------------------------------------------
> ------------------------
> 
> 
> 
> 
> --
> Help        mailto:[email-masked] and say "help" 
> in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/