Subject: [ipfix] Re: IPFIX requirements - security

From: Juergen Quittek <[email-masked]>
Date: Mon, 02 Feb 2004 22:43:15 +0100

Stewart,

We changed the requirement for confidentiality from SHOULD to MUST in October.
It was based on a comment from Allison:

   "Requirements on the ipfix implementation - the document is long and
    I wonder if the working group really meant the protocol's confidentiality
    and anonymization features to be so optional -  SHOULD confidentiality,
    MAY anonymization. Just for implementation."

So far there was an agreement on this change on the mailing list as well as
at the last IPFIX session, where this particular issue was presented.
This does not mean, that we may not discuss the issue anymore, but so far,
we had an agreement.

I see the higher implementation effort, but I also see that most new devices
today implement IPsec anyway.  So, I would be fine with both ways.

Are there people on the mailing list who either agree or disagree?
Please speak up.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

--On 28.01.2004 11:44 Uhr +0000 Stewart Bryant wrote:

> I believe that the security requirements (below) which were
> enhanced by the IESG are an unreasonable burden on many
> implementations.
>
> 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.
>
> 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 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.
>
> 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.
>
> - 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: Tue, 03 Feb 2004 10:39:10 +0000

> today implement IPsec anyway.  So, I would be fine with both ways.

On the other hand we also talk about the performance issues of IPFIX,
and IPsec will mean either a lot of CPU cycles or hardware support.
Also to be of use in a reasonable timeframe, IPFIX has to work on
existing platforms.

Now I do not have any problem with requiring the system to provide
confidentially etc, it's just that the way that the requirement
is written, the protocol MUST support it, which constrains the
implementation choices.

- Stewart

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 03 Feb 2004 15:52:29 +0100

Dear all,

What shall we do with Stewart's issue?

The requirements draft is under IESG review.
Shall we call it back from there?

    Juergen