Subject: [ipfix] [Fwd: Re: IPFIX protcol draft security section]

From: Stewart Bryant <[email-masked]>
Date: Mon, 19 Jan 2004 16:14:47 +0000

I did some work on the security section written
by Mark Fulmer for the IPFIX protocol draft.

We can take the bit about transport pathology out
if it is too controversial, but it occured to me, as
I was thinking this out, that congestion is not
the only consideration when it comes to IPFIX
transport.

- Stewart

Security Section
----------------

Because IPFIX can be used to collect billing information and
network forensics, confusing or blinding IPFIX must be seen
as a prime objective during a sophisticated network attack.

If an attacker is in a position to inject false messages into
an IPFIX message stream this will allow them to send forged
flow records, options, or templates.  Forged templates may
impair the collectors ability to process any further flow records.
Forged flow records would have a direct effect on the application
using the flows, for example a billing system may generate
incorrect billing information.  Forged options may be able to
alter the meaning of flow records, for example if the sample
rate is changed.

The IPFIX messages themselves may contain information of value
to an attacker, and thus care must be taken to confine their
visibility to authorized users.

The IPFIX protocol runs over any IETF specified transport protocol
and hence the messages sent to the collector by the observer
may be secured using IPsec. However this does not address all of
the security issues in an IPsec deployment.

IPsec Profile
-------------

To secure messages between the observer and the collector
an IPFIX implementation MAY use IPsec. To ensure inter-working
between observers and collectors from different vendors,
the following IPsec profile MUST be supported. This profile
is derived from [USEIPSEC]

Selectors
---------

IPFIX runs between manually configured pairs of hosts on
the following transport ports (TBD).  The appropriate
selector would be the IPFIX collector for that port only.
Note that if the observer is a router, the "loopback address"
is almost certainly the address to use.

Mode
----

IPsec MUST be run in transport mode, and MAY use either the
Authentication Header (AH) [RFC2402] or the Security Protocol
(ESP) [RFC2406] depending on the perceived level of threat
to the IPSEC message content. The information being communicated
may be confidential, in which case ESP MUST used. If ESP is
used, the sender's IP address MUST be checked against the
IP address asserted in the key management exchange.

The AH MUST be supported by an IPFIX implementation of IPsec.

Key Management
--------------

In most network, manual key management will be sufficient,
and reduces the complexity of the observer, albeit at a
cost of greater configuration complexity. Manual key management
MUST be supported. If a replay attack is considered likely,
an automated key management the IKE key managent system SHOULD
be used.

Security Policy
---------------
Connections should be accepted only from the designated peer.

Authentication
--------------
Given the number of IPFIX capable routers likely to be
deployed by a large ISPs, it is likely that shared key
mechanisms are inadequate.  Consequently, where an automated
key management system is used, certificate-based IKE SHOULD
be supported.  Whatever scheme is used, it must tie back to a
source IP address in some fashion.

Availability
------------
It is accepted that IPsec will not be universally available
in IPFIX observers, and that where it is available, there may
be issues of throughput, which may itself raise security
issues. In such circumstances the other security measures
described in this draft provide some threat mitigation.

Network Architecture
--------------------

Ideally messages from the IPFIX observer to the IPFIX collector
should travel over a dedicated network such as a dedicated
point to point link. In all cases, useful protection is gained
by allocating observer and collector IP addresses from ranges
that are excluded from use for user traffic. By sending the
IPFIX messages over a dedicated network, message IPFIX message
loss induced by user traffic congestion is minimized. However
an attacker may trigger the generation of excessive IPFIX
messages, and to avoid information loss during such an attack
the IPFIX network must be adequately sized.

The use of a dedicated network also prevents the IPFIX
messages from being inspected by an attacker.

When IPsec is not an option
---------------------------
When IPsec is not an option, perhaps due to performance issues,
but some level of protection against an insertion attack is
required, it is recommended that a 64 bit cookie [L2TPv3] be
included as a mandatory element within all messages.

[Note if we follow this approach, we will need to do some work
on the protocol itself - SB]

Without IPsec the IPFIX collector has no means to authenticate
an exporter other than the exporters Source IP address. Where
large numbers of observers, proxies and collectors are used
in a network, it may be tempting for the administrator to
not impose source IP address restrictions, this leaves the
collector open to reception of invalid flows. The use
praxes using an open collector is therefore to be deprecated.

Transport Issues
----------------

Some IPFIX security issues are dependent on the transport.
For example with UDP unsolicited messages may be received
and not detected, with a modern implementation of TCP with
good ISN randomization [XXX-REFERENCE] or SCTP these types
of attacks are much more difficult without an attacker
with access to snoop the packet flow.
[XXX-SCTP-BLIND-SPOOFING-REFERENCE]

An attacker may take advantage of the pathology of the
transport protocol or its common implementations to
mount and attack on IPFIX. This might be either as
an assault on IPFIX in its own right or intended to
blind IPFIX to prevent the recording of network forensics
as part of another attack.

Under conditions where the attacker saturated IPFIX, for
example by  initiating the generating enormous numbers
of short lived flows, the behavior of the IPFIX transport
would determine the amount of evidence that was recorded.

If the transport were UDP, then under network overload
conditions IPFIX would reduce to a form or sampled Netflow.
This means that the attacked could never be quite sure
that IPFIX was blinded, and that they may hence be leaving
forensics.

If the transport were TCP, then the flow to the collector
would back off due to congestion discard and eventually stall
blinding the IPFIX system. An attack could then proceed
without further observation. The extent and duration of the
blindness would depend on the detail of the TCP implementation.

SCTP-PR will have a different pathology under such a
saturation attack. Stale data at the head of the queue will
get flushed giving some visibility of the attack.

Whilst the use of a congestion aware transport protocol is
highly desirable to protect the network from overload by
excessive IPFIX traffic, this is exactly wrong behavior
when IPFIX is being to diagnose a DoS attack, or an attack
proceeding under cover of a DoS attack. Under these circumstance
you want the IPFIX transport needs to be congestion neutral
(as is UDP), or congestion aggressive.

Logging an IPFIX Attack
-----------------------

IPFIX has a sequence number which increases with each message.  A
collector may detect out of sequence, dropped, or duplicate messages
by tracking the sequence number.  A collector SHOULD provide a logging
mechanism for tracking out of sequence messages.  Such out of sequence
messages may be due to congestion on the network link between the
exporter and collector, collector resource exhaustion where it can not
process the messages at their arrival rate, exporter resource exhaustion
where it can not transmit messages at their creation rate, out of order
packet reception, duplicate packet reception, an exporting process reset,
or an attacker injecting false messages.

Refs to be cleaned up
---------------------

[USEIPSEC] draft-bellovin-useipsec-02.txt
[L2TPv3] draft-ietf-l2tpext-l2tp-base-11.txt

--
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: Sebastian Zander <[email-masked]>
Date: Mon, 19 Jan 2004 18:33:16 +0100

Some comments. First some general and the rest interspersed.

- "Observer" should be changed to exporter (or exporting process)
- We could/should add the use of TLS

> the only consideration when it comes to IPFIX

The IPFIX protocol runs over IP and ...

> the security issues in an IPsec deployment.

selector would be exporter collector pairs and port number

> is almost certainly the address to use.

what does that mean?

> The AH MUST be supported by an IPFIX implementation of IPsec.

MAY either use AH or AH+ESP. AH MUST be used if authentication
is required. ESP must be used if confidentiality is required.
If somebody requires confidentiality and don't needs IP header
auth then only ESP could be used but I think this not the usual
case.

> Key Management

why is that?

> loss induced by user traffic congestion is minimized. However

minimized to 0 I guess.

> messages from being inspected by an attacker.

Presuming complete physical security which may be easy or not
so easy to achieve

> When IPsec is not an option

which can be spoofed

> praxes using an open collector is therefore to be deprecated.

Wouldn't the IPFIX seq number be sufficient in case of UDP?
Maybe it would need proper randomization...

> (as is UDP), or congestion aggressive.

But on the other hand if UDP is used an attacker might be able to
saturate the separate network and therefore potentially blinding
more than one observation point.

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 19 Jan 2004 23:00:49 +0000

> - We could/should add the use of TLS

TLS?

> The IPFIX protocol runs over IP and ...

I was assuming that all IETF specified transports ran over IP.
The only thing that is likely to change this is TCP/MPLS, but
that is not on any WG agendas that I am aware of :)

>> the security issues in an IPsec deployment.

In useipsec the example is a BGP entity on a router, so what
we have here is a lightly edited version of the example.
I would that that IPFIX is quite a close cousin of Steve's
example.

> selector would be exporter collector pairs and port number

I think that the selection occurs at the server end of the
client server pair, so only one IP address is needed. Does
the exporter normally collect the collector of visa verse?
So it is only one IP address and one port.

>> is almost certainly the address to use.

One of the non-interface addresses (because if you use an interafce
address and the interface goes down, so does the session)

> auth then only ESP could be used but I think this not the usual

Again I copied the BGP example, and I would have thought that this
was exactly correct. It's a bit late here, but I will double check
in the morning agains Steve's text.

>> that are excluded from use for user traffic. By sending the

So that there is no routing path from a user to the IPFIX pair.

>> loss induced by user traffic congestion is minimized. However

No, you could get congestion during an attack on th IPFIX
network depending on the type of attack, it's indensity,
and the capacity of the ipfix network. Now you would expect
it to be zero, but I don't think that you can guarantee it
and therefore should not say so in a security section.

> Presuming complete physical security which may be easy or not

But if you could it would. A pt-pt direct link is one example.

>> an exporter other than the exporters Source IP address. Where

exactly.
> Maybe it would need proper randomization...

It's only 32 bits, see Mark Townsley's L2TP discussion on the
issues of such small sequence spaces. Which remind's me I think
we need some discussion on the sequence number recovery protocol
and its risks.

> more than one observation point.

I still think that it's worse with a congestion aware transport.
If you saturate that network, they all start to back off.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 20 Jan 2004 18:32:08 +0000

Mark Fullmer wrote:

> 
> On Jan 19, 2004, at 6:00 PM, Stewart Bryant wrote:
> 
>>
>>
>> Sebastian Zander wrote:
>>
> The problem is more fundamental than this.  How does a collector
> know what would be the ISN?  How does a collector know the difference
> between a new linecard being inserted, thus a new observation domain ID
> (also called Source ID in the draft) with a new sequence number space and
> an attacker picking a random Source ID and spoofing in forged flow data.
> 
> A pre-configured cookie shared by the collector and exporter addresses
> these issues unless the attacker knows the cookie.

We are actually in violent agreement here, a pre-configured
cookie is what we are both advocating (it is how it works in
one of the L2TPv3 modes),  however it is still vulnerable to sniffing.

Stewart

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 21 Jan 2004 16:49:33 +0100

>> - We could/should add the use of TLS

Transport Layer Security (rfc 2246). But I would have to read it
myself to find out how/if ipfix can be used with it.

 > that is not on any WG agendas that I am aware of :)

Than I would put the transport protocols in parenthesis. Who knows
what other kinds of transport will be invented in the future... ;-)

 > So it is only one IP address and one port.

AFAIK you need a selector on both ends.
I think in the general case you need pairs (see [USEIPSEC])
because each exporter collector pair can be a different SA
and there is a n to n relationship between exporters and
collectors (see arch draft). But it selector may be a wildcard.

 > and therefore should not say so in a security section.

Now I am confused. Didn't you say that user traffic does not
enter the separate network?

 > we need some discussion on the sequence number recovery protocol

yes

 > If you saturate that network, they all start to back off.

But if you have a separate network for ipfix traffic in case of udp
a user might be able to saturate this network by creating a large
number of small flows in probe(s) under attack. In case of tcp the
ipfix traffic from the probes under attack would have to back-off
which leaves some bandwidth for other probes.

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 21 Jan 2004 17:06:30 +0100

>>> we need some discussion on the sequence number recovery protocol

TCP sequence number is also 32 bits. So I don't see the difference
between UDP and TCP (assuming a proper ipfix seq number).

 >> these issues unless the attacker knows the cookie.

I don't think the big problem is to know the ISN because that's exactly the
same problem of knowing the cookie ;-). The problem is the small space (32bit)
and how the sequence number handling is done (what is the allowed window etc.).

 > one of the L2TPv3 modes),  however it is still vulnerable to sniffing.

I agree that the cookie is better than the sequence number. But from a security
viewpoint it is a potentially dangerous solution IMO. Not only because of sniffing
which makes the cookie completly useless. Also because if the cookie is pre-configured
it is static and will probably never change. This gives attackers a long time for
trying to discover it. Furthermore I would expect that people use the same cookie for
all their exporters and collectors because they don't want to manually set up
and maintain lots of cookies. So you have different points which can be attacked and
if the attackers suceeds at one point the secret cookie for all is exposed. Even worse
it could happen that there will be a default cookie setup in a software or hardware
product which the admin "forgets" to change. Actually in the old days systems where
delivered with a default root password... At least these threads must be discussed
in the draft together with recommendations to mitigate them.

I thought about a different proposal: have a secret. Than a crypto hash over the exporter id,
collector id, time and secret can be put into the packet. This way you have something
like a session key which can be changed from time to time and the master key (the
secret) never gets exposed. The collector has to compute the session key only
when it changes, otherwise it just compares the actual value with the last one.
This way you have 1) a number of different keys and if one is discovered only one
exporter-collector connection is affected, 2) a new key can be produced without changing
the master secret for all. If the exporter id is not publicly known even the knowledge of
the secret would not enable an attacker to produce a proper session key (assuming the
exporter id is not easily guessable). Still vulnerable to sniffing.

Actually I am not really convinced of having something like a cookie at all because
either you run ipfix in your "secure" network: no sniffing and spoofing can be prevented
by proper ingress filtering (what you pointed out before). Otherwise use IPSec or TLS.

Cheers,

Sebastian