Subject: [ipfix-req] security considerations

From: Tanja Zseby <[email-masked]>
Date: Fri, 17 May 2002 16:46:15 +0200

Hi Benoit,

here comes the new security considerations section. I integrated 
comments from Sebastian and Carter.

Regards
Tanja

9. Security considerations

The future IPFIX protocol must be capable to transport data over the 
public Internet. Therefore it cannot be excluded that an attacker 
captures or modifies exchanged packets or inserts additional 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 data exchanged by the IPFIX protocol (e.g. IPFIX flow 
records) should be kept confidential between the involved parties 
(exporting process and colleting process). Observation of IPFIX flow 
records gives an attacker information about the active flows in the 
network, communication endpoints and traffic patterns. This information 
cannot 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
Because of the potential uses of IPFIX flow records in accounting and 
security applications, there are strong incentives to forge exported 
IPFIX  flow records (e.g. to save money or prevent the detection of an 
attack). This can be done either by altering 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 processes 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/

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 17 May 2002 11:02:04 -0400

Hey Tanja,
   I sent a rewriting of a part of the security considerations section.
This is the section that I suggested.

- 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.

I believe that it conveys your intention without suggesting that the
accounting application could possibly forge data.

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: Friday, May 17, 2002 10:46 AM
> To: Benoit Claise
> Cc: IPFIX Requirements
> Subject: [ipfix-req] security considerations
> 
> 
> Hi Benoit,
> 
> captures or modifies exchanged packets or inserts additional 
> packets. This document describes requirements for IP Flow 
> Information Export

---

From: Tanja Zseby <[email-masked]>
Date: Fri, 17 May 2002 17:10:08 +0200

Hi Carter,

in the new version I already tried to integrate your suggestion into the 
section.The sentence now is

"Because of the potential uses of IPFIX flow records in accounting and 
security applications, there are strong incentives to forge exported 
IPFIX flow records (e.g. to save money or prevent the detection of an 
attack)."

I think the last part of your suggestion is already covered in:

"In order to make the IPFIX protocol resistant against such attacks this 
document requires to ensure authenticity and integrity for the IPFIX 
data transfer."

Do you agree with this wording ?

Regards
Tanja

Carter Bullard wrote:

>Hey Tanja,
>   I sent a rewriting of a part of the security considerations
>section.  This is the section that I suggested.
>
>
>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.
>
>I believe that it conveys your intention without suggesting
>that the accounting application could possibly forge data.
>
>Carter
>
>Carter Bullard
>QoSient, LLC

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 24 May 2002 12:45:52 -0400

Hey Tanja,
   That's great!
Carter

> Sent: Tuesday, May 21, 2002 5:59 AM
> To: [email-masked]
> Cc: 'IPFIX Requirements'; Benoit Claise
> Subject: Re: FW: [ipfix-req] security considerations
> 
> 
> Hi Carter,
> 
> here my next try to integrate our text parts:
> 
> "IPFIX flow records are used in accounting and security 
> applications. This leads to strong incentives for attackers 
> to forge exported IPFIX flow records (e.g. to save money or 
> to prevent the detection of an attack). In order to make the 
> IPFIX protocol resistant against such attacks, source 
> authentication and integrity assurance must be provided for 
> IPFIX data. These requirements are covered in the security 
> requirements section of this document."
> 
> What do you think ?
> 
> Regards
> Tanja
> 
> 
> Carter Bullard wrote:
> 
> >Hey Tanja,
> >   The English suggests that the accounting and security 
> applications 
> >have the incentive to forge exported IPFIX records.  You may want to 
> >explicitly state who has the incentive to forge, this would clear up 
> >the ambiguity.
> >
> >   Authentication comes in many flavors, source, receiver, mutual, 
> >etc.... authentication.  There is no requirement in the charter to 
> >provide either receiver or mutual authentication between an IPFIX 
> >exporter and its consumer.  That is why my suggestion 
> specified source 
> >authentication.  You may want to consider being this specific.
> >
> >Carter
> >
> >Carter Bullard
> >QoSient, LLC
> >From: majordomo listserver [mailto:[email-masked]] On 
> >Behalf Of Tanja Zseby
> >Sent: Friday, May 17, 2002 11:10 AM
> >To: [email-masked]
> >Cc: 'Benoit Claise'; 'IPFIX Requirements'
> >Subject: Re: [ipfix-req] security considerations
> >
> >
> >Hi Carter,
> >
> >in the new version I already tried to integrate your suggestion into 
> >the section.The sentence now is
> >
> >"In order to make the IPFIX protocol resistant against such attacks 
> >this document requires to ensure authenticity and integrity for the 
> >IPFIX data transfer."
> >
> >Hey Tanja,   I sent a rewriting of a part of the security
> >considerationssection.  This is the section that I 
> suggested.- Forgery 
> >of IPFIX flow recordsBecause of the potential uses of IPFIX flow 
> >records inapplications such as accounting and security, there is 
> >astrong need to provide source authentication and 
> >integrityassurance/protection for IPFIX data.I believe that 
> it conveys 
> >your intention without suggestingthat the accounting 
> application could 
> >possibly forge data.CarterCarter BullardQoSient, LLC300 E. 
> 56th Street, Suite 18KNew
> >York, New York  [email-masked] +1 212 
> 588-9133Fax   +1 212
> >588-9134http://qosient.com
> >-----Original Message-----From: majordomo listserver 
> >[mailto:[email-masked]] On Behalf Of Tanja ZsebySent: 
> >Friday, May 17, 2002 10:46 AMTo: Benoit ClaiseCc: IPFIX
> >RequirementsSubject: [ipfix-req] security considerationsHi 
> Benoit,here 
> >comes the new security considerations section. I integrated comments 
> >from Sebastian and Carter.RegardsTanja9. Security considerationsThe 
> >future IPFIX protocol must be capable to transport data over 
> the public 
> >Internet. Therefore it cannot be excluded that an attacker 
> captures or 
> >modifies exchanged packets or inserts additional 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 dataThe content of 
> >data exchanged by the IPFIX protocol (e.g. IPFIX flow rec
> >ords) should be kept confidential between the involved parties 
> >achieved for instance by encryption.- Forgery of IPFIX flow 
> >recordsBecause of the potential uses of IPFIX flow records in 
> >accounting and security applications, there are strong incentives to 
> >forge exported IPFIX  flow records (e.g. to save money or 
> prevent the 
> >detection of an attack). This can be done either by altering 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) 
> >attacksDoS 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 processes 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-7153D-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
> >bodyUnsubscribe mailto:[email-masked] and say 
> "unsubscribe
> >ipfix" in message bodyArchive     http://ipfix.doit.wisc.edu/archive/
> >
> >
> >
> 
> -- 
> Dipl.-Ing. Tanja Zseby