Subject: [ipfix] RE: IPFIX requirements - security

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 30 Jan 2004 16:54:53 +0100

Stewart, inline

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: woensdag 28 januari 2004 12:45
> To: Juergen Quittek; [email-masked]; allison mankin
> Cc: [email-masked]
> Subject: IPFIX requirements - security
> 
> 
> I believe that the security requirements (below) which were
> enhanced by the IESG are an unreasonable burden on many
> implementations.
> 
Unreasonable for the IMPLEMENTATIONs?

Note that the requirements are mainly stsated such that 
the protocol MUST support. So that means you MUST implement
if you want to claim compliance. 

Of course someone who deploys it can choose to not use the
security features of the protocol but instead use dedicated
(and protected) links. 

> The new requirements lack a measure of appropriateness which
> needs to be incorporated in the definition.
> 
> For example there is no point in providing greater
> confidentiality in the IPFIX protocol than exists at the
> observation point itself.
> 
Is that true?
If the observation point is in a secure place, and the flow is
going to another secure place via a secure link, but you export 
the data via an unsecure path to some collector, than that seems
incorrect to me.

> There is no point in providing a level of integrity or
> authenticity that exceeds the requirements of the collecting
> application.
> 
> Setting the baseline for operation over the public Internet
> leads to the inevitable conclusion that IPFIX MUST be run
> over IPsec, but that is absurd in situations where the
> network design precludes the possibility of data leakage
> (for example where the IPFIX traffic is carried over a
> private management network).
> 
The fact that the protocol spec and conformant implementations
support/rpvide-for a way of secure transmission does not mean that
deployment needs to utilize those functions if they have made
sure that the (dedicated) links over which the exported data travels
are (physically) secure.

> The net result of setting the bar at this level will be
> either late and unnecessarily costly deployment of IPFIX,
> or (more likely) the widespread deployment of non-compliant
> IPFIX, thereby bringing the RFC into disrepute.
> 
I hope other people can speak up on this too, eitehr agreeing
or dis-agreeing with you. 

> Section 6.3.3 should therefore be reworded to something
> of the following form:
> 
> IPFIX data transferred from an exporting process to a
> collecting process MUST NOT degrade the confidentiality of
> the packet flows at the observation point.
> 
> The method of transferring IPFIX data from the exporting
> process to the collecting process MUST provide the level
> of data integrity required by the collecting application.
> 
> The authenticity of IPFIX data transferred from an exporting
> process to a collecting process MUST be sufficient to meet
> the application needs at the collector.
> 
I do not agree with the above.

Bert
> - Stewart
> 
> 
> Original text for reference:
> 
> ====================
> 
> 6.3.3.  Security
> 
>     Confidentiality of IPFIX data transferred from an 
> exporting process
>     to a collecting process MUST be ensured.
> 
>     Integrity of IPFIX data transferred from an exporting process to a
>     collecting process MUST be ensured.
> 
>     Authenticity of IPFIX data transferred from an exporting 
> process to a
>     collecting process MUST be ensured.
> 
> =====================
> 
> 10.  Security Considerations
> 
>     An IPFIX protocol must be capable of transporting data over the
>     public Internet.  Therefore it cannot be excluded that an attacker
>     captures or modifies packets or inserts additional packets.
> 

--
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: Stewart Bryant <[email-masked]>
Date: Fri, 30 Jan 2004 17:36:50 +0000

Bert

 >the data via an unsecure path to some collector, than that seems

But in that case the path has degraded the confidentially
of the observation point, and my point stands. I am concerned
with why you assert that we need to improve it.

> I do not agree with the above.

I am sure that you do not support the converse, but you have
not justified the requirement to do better.

- Stewart