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

From: "Jeff Meyer" <[email-masked]>
Date: Wed, 21 Jan 2004 09:19:31 -0800

Sebastian,

  In the case of TLS, it would seem that both SCTP and TCP could make use of 
this.  Utillizing both client and server certificates would provide strong 
mutual authentication of both parties (exporter and collector) and allow for 
complete data privacty.

  For UDP, IPSec, or appropriate configuration of private LANs would seem to 
be the way to go.

  In either case, mechanisms for distributing public keys (TLS) or shared 
secrets (IPSec) may be cumbersome, but this is not a problem unique to 
IPFIX.  I'm not sure IPFIX needs to explicitly address how keys/secrets are 
configured into the systems.

-- Jeff

>From: Sebastian Zander <[email-masked]>
>To: [email-masked]
>CC: "[email-masked]'" <[email-masked]>
>Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
>Date: Wed, 21 Jan 2004 16:49:33 +0100
>
>Stewart Bryant wrote:
> >
> >
> > Sebastian Zander wrote:
> >
> >> 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
> >
> >
> > 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.
>
> >>
> >> Stewart Bryant wrote:
> >>
> >>>
> >>> 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
> >>
> >>
> >>
> >> 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 :)
>
>Than I would put the transport protocols in parenthesis. Who knows
>what other kinds of transport will be invented in the future... ;-)
>
> >
> >>> 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]
> >>>
> >
> > 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.
> >
> >>> 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.
> >>
> >>
> >>
> >> 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.
>
>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.
>
> >
> >>
> >>> Note that if the observer is a router, the "loopback address"
> >>> is almost certainly the address to use.
> >>
> >>
> >>
> >> what does that mean?
> >>
> >
> > One of the non-interface addresses (because if you use an interafce
> > address and the interface goes down, so does the session)
> >
> >>> 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.
> >>
> >>
> >>
> >> 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.
> >>
> >
> > 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.
> >
> >>
> >>> 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
> >>
> >>
> >>
> >> why is that?
> >
> >
> > So that there is no routing path from a user to the IPFIX pair.
> >
> >>
> >>> IPFIX messages over a dedicated network, message IPFIX message
> >>> loss induced by user traffic congestion is minimized. However
> >>
> >>
> >>
> >> minimized to 0 I guess.
> >
> >
> > 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.
>
>Now I am confused. Didn't you say that user traffic does not
>enter the separate network?
>
> >>
> >>> 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.
> >>
> >>
> >>
> >> Presuming complete physical security which may be easy or not
> >> so easy to achieve
> >
> >
> > But if you could it would. A pt-pt direct link is one example.
> >
> >>
> >>> 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
> >>
> >>
> >>
> >> which can be spoofed
> >
> >
> > exactly.
> >
> >>
> >>> 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]
> >>
> >>
> >>
> >> Wouldn't the IPFIX seq number be sufficient in case of UDP?
> >> 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.
>
>yes
>
> >>> 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.
> >>
> >>
> >>
> >> 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.
> >>
> >
> > I still think that it's worse with a congestion aware transport.
> > 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.
>
>
> >>> 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/
> >>>
> >>
> >>
> >
> >
> >
>
>
>--
>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
>
>
>
>
>
>
>--
>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/

_________________________________________________________________
Check out the coupons and bargains on MSN Offers! 
http://shopping.msn.com/softcontent/softcontent.aspx?scmId=1418

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