Subject: [ipfix] protocol security section

From: Mark Fullmer <[email-masked]>
Date: Sun, 11 Jan 2004 22:40:26 -0500

This is a rough draft of a security section.  I'd like to be able to
enumerate the attack scenarios better but this requires we get the
UDP/no UDP directive and relating issues behind us.  I think at least
all the issues are here.

I'm also leaning towards a simple authentication (plain text password
for example) option available in the protocol so that a collector can
at least have some idea who its talking to without requiring IPSec.

---

The IPFIX protocol provides no means to secure messages between the
exporter and collector, or a mechanism to provide for mutual
authentication.  IPSec MAY be used for message authentication and or
encryption, but this may not address all the security issues present
in an IPFIX deployment.

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]

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 exportering process 
reset,
or an attacker injecting false messages.

An attacker may be in a position to inject false messages into an IPFIX
message stream.  This type of attack may require the ability to sniff
packets on the network segment connecting the exporter and collector, or
in the case of UDP knowing the collector IP address and port the IPFIX
process is bound to may be sufficient.  Injecting false messages will 
allow
the attacker 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.

Packet flooding or other Denial of Service techniques may be used to 
cripple
the collectors ability to receive and/or process incoming IPFIX 
messages.

A collector has no means to authenticate an exporter other than the
exporters Source IP address.  It is common for a single exporter to
process flow records for multiple collectors, and therefore the 
collector
administrator may not impose source IP address restrictions, leaving
the collector open to reception of invalid flows.

Another type of attack involves using an IPFIX exporter to amplify
packet flows.  For example one 40 byte IP datagram may generate
a single 48 byte flow.  When this IP datagram transverses multiple
routers exporting flows its impact on the network may be amplified
depending on the location of the collector(s).

For exmple if an attacker (A) sends 1000 40 byte packets to destination
(D) which each generate one flow and R1..R4 are configured to export
flows to C, the link to C will experience at least 4x the traffic the
attacker is generating.  The link from R2 to R3 would need to carry both
the outbound attack and the IPFIX messages from R4 and R3.

       R1-----R2------R3------R4
       |       |              |
       A       C              D

--
mark

--
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: Mon, 12 Jan 2004 10:38:03 +0000

Mark

I have some worries about this section.

IPFIX is just another application that runs over IP
via an IETF defined transport, and as such it should
punt the issues to an IETF common solution. That
solution is IPsec, and if IPsec is inadequate the
matter should be addressed by the IPsec WG.

The standard response to that is that IPsec is too
heavyweight, but again we should be looking for a
common solution rather than a roll-your-own for each
application that needs security, but feels that IPsec
is too heavyweight.

I have some more comments in-line.

> at least have some idea who its talking to without requiring IPSec.

In <draft-ietf-l2tpext-l2tp-base-11.txt> which also has issues with
IPsec being too heavy weight, it is proposed that blind insertion
attacks be addressed through the use of a 64 bit cookie (a 64 bit
randomly chosen password common to each end) is used. I am not sure
whether this is going to be blessed by the IESG, but it would make
sense is we used exactly the same approach and exactly the same
argument (ie import their data plane security text). That way
either both get accepted, or a common work item addresses the shortfall.

Of course another solution to this is to call up L2TPv3 as a lightweight
transport protocol with counter insertion protection.

> encryption, but this may not address all the security issues present

An alternative wording is something of the form:

The IPFIX is an application that can be run over a number of IETF defined
transport protocols. It introduces no new risks to the network and
is subject exactly the same risks of attack as any other application.

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

But these are just the standard UDP risks.

> packet reception, duplicate packet reception, an exportering process reset,
> process is bound to may be sufficient.  Injecting false messages will allow
> the attacker to send forged flow records, options, or templates.  

So this is where an L2TPv3 style cookie would help.

> Forged
> records.  Forged flow records would have a direct effect on the application

We only send a small number of templates, but there are the most vulnerable
part of the system. Perhaps we should using IPsec to secure the templates
even in instances when we cannot afford to secure the flow records.

> the collectors ability to receive and/or process incoming IPFIX messages.
> 

Isn't this just standard?

> process flow records for multiple collectors, and therefore the collector

Don't you mean single collector multi-exporter?

>       R1-----R2------R3------R4

We need to include some text addressing this. The solutions that
I can see are either a congestion aware IPFIX transport or a separate
collector network. But the former has its own risks:

There is a further risk that is not covered in this section. An attacker
can force the IPFIX transport into congestion discard as a cover for
their own activities. This is an interesting risk, because the IESG
insistence that we must use a congestion aware transport creates
a risk that IPFIX might be blinded to certain types of attack.

- Stewart

---

From: Mark Fullmer <[email-masked]>
Date: Mon, 12 Jan 2004 23:51:49 -0500

> either both get accepted, or a common work item addresses the 

How does the collector know the cookie is valid?

--
mark

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Jan 2004 11:42:51 +0000

> How does the collector know the cookie is valid?

In the L2TPv3 case, they are either reconfigured at both ends, or
signalled at session startup.

We could clearly preconfigure them, or we could exchange them over
a secure channel along with the template.

Stewart

---

From: Mark Fullmer <[email-masked]>
Date: Mon, 19 Jan 2004 15:18:28 -0500

I'm not sure a preconfigured cookie is anything more than a password....

If a random cookie were to be signaled over a TCP or SCTP connection,
for example with templates and options, then use UDP with a cookie in
the IPFIX message for the flow data this would mitigate blind insertion
attacks when using UDP as the transport.  This requires that we use TCP
or SCTP as the control channel when using UDP, which happens to address
a number of other issues at the same time.

--
mark

---

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

> I'm not sure a preconfigured cookie is anything more than a password....

It's not, and the only reason that I propose it is because

a) A number is more likely to be ransom that a text password
b) There is another IETF WG that is closer to finishing than we are
    that is going to make the argument to the IESG, and it seems
    better to use them as presidence.

> a number of other issues at the same time.

Puting it in the template is the best way to send it across, and
I agree that there are merits in sending the template over SCTP or
TCP, but I don't think that it MUST use SCTP/TCP.

Stewart

---

From: Mark Fullmer <[email-masked]>
Date: Tue, 20 Jan 2004 12:04:31 -0500

Okay.  I'm in favor of a pre-configured cookie.

The random cookie for UDP would solve a different
problem that should probably be handled on its own.

In a nutshell we probably need a random session ID
added if UDP is used on its own.

--
mark