Subject: [ipfix] Proposal for collector IEs

From: Juergen Quittek <[email-masked]>
Date: Mon, 29 May 2006 21:56:48 +0200

Dear all,

I have a request for five new information elements:

  collectorIPv4Address
  collectorIPv6Address
  collectorProtocolVersion   (IPFIX=10,NFv9=9,NFv5=5,...)
  collectorTransportProtocol (TCP,UDP,SCTP,...)
  collectorTransportPort

Obviously, any collector will have this information
when receiving a record, but when storing collected
data in a big database, then we are storing also the
collector that received the records.  And then there
is the question which format to use for storing this
information.  It seems to be a good choice to store
the collector information in the same format as the
exporter information.  Therefore, I suggest adding
them to our information model.

At the same time, a need for these IEs occurred at
another place.  While working on a path-coupled
configuration of meters, see
draft-fessi-nsis-m-nslp-framework-02.txt
draft-dressler-nsis-metering-nslp-03.txt,
we are looking for a way to configure IPFIX meters.
And before defining completely new data structures
for this we consider using IPFIX messages with
templates and option records for configuring them.
These could be the same messages that are used
by IPFIX devices for reporting their configuration
to collectors.  The only thing that is missing is
the collector information.

Below you will find the full specification of the
proposed IEs.

Any comments?

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

5.2.3.  collectorIPv4Address

   Description:
      An IPv4 address to which the Exporting Process sends Flow
      information.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 333
   Status: current

5.2.4.  collectorIPv6Address

   Description:
      An IPv6 address to which the Exporting Process sends Flow
      information.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 334
   Status: current

5.2.5.  collectorProtocolVersion

   Description:
      The protocol version used by the Exporting Process for sending
      Flow information.  For IPFIX, the value of the Version Number
      field in the message header is 10.  For NetFlow version 9, the
      value of the Version Number field in the message header is 9.
   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 335
   Status: current
   Reference: See [I-D.ietf-ipfix-protocol] for the definition of the
      IPFIX Message header.  See RFC 3954 [RFC3954] or the definition of
      the NetFlow version 9 Message header.

5.2.6.  collectorTransportProtocol

   Description:
      The value of the protocol number in the IP packet header.  The
      protocol number identifies the IP packet payload type.  Protocol
      numbers are defined in the IANA Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.
   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 4
   Status: current
   Reference:
      See RFC 791 [RFC0791] for the specification of the IPv4 protocol
      field.  See RFC 2460 [RFC2460] for the specification of the IPv6
      protocol field.  See the list of protocol numbers assigned by IANA
      at http://www.iana.org/assignments/protocol-numbers.

5.2.7.  collectorTransportPort

   Description:
      The destination port identifier to which in the the Exporting
      Process sends Flow information.  For the transport protocols UDP,
      TCP and SCTP this is the destination port number.  This field MAY
      also be used for future transport protocols that have 16 bit
      source port identifiers.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 336
   Status: current
   Reference:
      See RFC 768 [RFC0768] for the definition of the UDP source port
      field.  See RFC 793 [RFC0793] for the definition of the TCP source
      port field.  See RFC 2960 [RFC2960] for the definition of SCTP.
      Additional information on defined UDP and TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

--
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: Paul Aitken <[email-masked]>
Date: Mon, 29 May 2006 21:19:40 +0100

Juergen,

> I have a request for five new information elements:

I approve, except for one point:

If the collectorIPv6Address is a link-local address, then it may need to 
be further qualified with an interface. The same is true for the 
exporterIPv6Address IE, and for private IPv4 addresses.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 29 May 2006 22:33:15 +0200

Paul,

Do I get you right, that you ask for one more IE
called collectorEgressInterface containing an ifIndex
value?

Thanks,

    Juergen

--On 29.05.2006 21:19 Uhr +0100 Paul Aitken wrote:

> If the collectorIPv6Address is a link-local address, then it may need to be further qualified with an interface. The same is true for the exporterIPv6Address IE, and for private IPv4 addresses.
>
> --
> Paul Aitken

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 29 May 2006 22:58:11 +0200

Paul,

--On 29.05.2006 21:44 Uhr +0100 Paul Aitken wrote:

> Yes, I think it would be useful for the cases I described.

Would this specification be fine?

5.2.5.  collectorInterface

   Description:
      The index of the IP interface where the Exporting Process sends
      Flow information.  The value matches the value of managed object
      'ifIndex' as defined in RFC 2863 [RFC2863].  Note that ifIndex
      values are not assigned statically to an interface.  Interfaces
      may be renumbered every time the device's management system is re-
      initialized.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 335
   Status: current
   Reference: See RFC 2863 [RFC2863] for the definition of the ifIndex
      object.

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Mon, 29 May 2006 21:44:09 +0100

Juergen,

---

From: Paul Aitken <[email-masked]>
Date: Mon, 29 May 2006 22:10:02 +0100

Juergen,

> Would this specification be fine?

Very good - except that I object to the "RFC 2863 [RFC2863]" style 
because the "[RFC2863]" style has already been used extensively through 
the IPFIX docs and is far more readable.

Thanks.

---

From: Lutz Mark <[email-masked]>
Date: Tue, 30 May 2006 09:36:14 +0200

Hi Juergen,

 > I have a request for five new information elements:

good idea.

I think there is a typo in reference text.

Regards,
Lutz

 >     field.  See RFC 793 [RFC0793] for the definition of the TCP source

See RFC 768 [RFC0768] for the definition of the UDP _destination_ port
field.  See RFC 793 [RFC0793] for the definition of the TCP _destination_

---

From: Paul Aitken <[email-masked]>
Date: Tue, 30 May 2006 09:43:21 +0100

Juergen,

> we are looking for a way to configure IPFIX meters.

I woke up during the night because I realised that you don't have any 
way to *unconfigure* a meter. The elements above are enough to create 
and perhaps to change a meter, but not enough to delete a meter.

So I propose that collectorProtocolVersion of 0 be defined to mean "no 
export protocol", with the special effect of deconfiguring any exporter 
matching the other given IEs in the same message.

Further, the less specific the message is, the more exporters may be 
deconfigured.

eg, { collectorProtocolVersion = 0,
       collectorIPv4Address = 192.168.1.1,
       collectorTransportPort = 1234 }

would deconfigure all exporters sending to port 1234 at address 192.168.1.1.

  { collectorProtocolVersion = 0,
    collectorTransportProtocol = SCTP }

would deconfigure all exporters using SCTP.

And in the extreme case,

  { collectorProtocolVersion = 0 }

would deconfigure all exporters.

Obviously there are security implications of a third party being able to 
configure new export destinations (eg, to snoop on traffic) and 
deconfigure existing ones (eg, to prevent billing).

Cheers.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 May 2006 11:27:30 +0200

Juergen,

Considering the comments given on the mailing list already, this is a 
nice idea.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 30 May 2006 12:21:20 +0200

Lutz,

> field.  See RFC 793 [RFC0793] for the definition of the TCP _destination_

Fixed.

Thanks you,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 30 May 2006 12:29:52 +0200

Paul,

--On 30.05.2006 9:43 Uhr +0100 Paul Aitken wrote:

> I woke up during the night because I realised that
> you don't have any way to *unconfigure* a meter.
> The elements above are enough to create and perhaps
> to change a meter, but not enough to delete a meter.

I hope you will sleep better tonight :-)

> So I propose that collectorProtocolVersion of 0 be defined
> to mean "no export protocol", with the special effect of
> deconfiguring any exporter matching the other given IEs in
> the same message.
>
> Further, the less specific the message is, the more exporters
> may be deconfigured.
>
> Obviously there are security implications of a third party being able
> to configure new export destinations (eg, to snoop on traffic) and

I am not sure we want to document all of this in the IE specification.
Would the following be fine with you or would you like to see
more details?

5.2.6.  collectorProtocolVersion

   Description:
      The protocol version used by the Exporting Process for sending
      Flow information.  For IPFIX, the value of the Version Number
      field in the message header is 10.  For NetFlow version 9, the
      value of the Version Number field in the message header is 9.  A
      value of 0 indicates that no export protocol is in use.
   Abstract Data Type: unsigned8
   Data Type Semantics: identifier

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Tue, 30 May 2006 11:56:34 +0100

Juergen,

> I hope you will sleep better tonight :-)

Hopefully! In this case I woke with the idea clearly in my mind at 
1.25am - which was only 20 minutes after I got to sleep...

> I am not sure we want to document all of this in the IE specification.

Sure - but the clear definition of protocol version zero is a necessary 
prerequisite for all of the above.

I'd expect the information above to appear in some new draft(s) which 
discuss the configuration of IPFIX exporters, since configuration isn't 
something that any of the IPFIX drafts discuss today.

> Would the following be fine with you or would you like to see

Please see below.

>   Data Type Semantics: identifier

First it discusses the "protocol version", but suddenly switches to "the 
value of the Version Number field".

So I would propose:

        The protocol version used by the Exporting Process for sending
        Flow information, ie the value of the Version Number field in
        the message header.

        The protocol version is 10 for IPFIX and 9 for NetFlow version 9.
        A value of 0 indicates that no export protocol is in use.

Thanks.

---

From: Lutz Mark <[email-masked]>
Date: Tue, 30 May 2006 13:08:58 +0200

> matching the other given IEs in the same message.

an alternative solution would be to assign a life-time
to the metering session and to set the life-time to zero
to unconfigure the metering.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 30 May 2006 13:39:04 +0200

Paul,

--On 30.05.2006 11:56 Uhr +0100 Paul Aitken wrote:

> Hopefully! In this case I woke with the idea clearly in my mind at 1.25am - which was only 20 minutes after I got to sleep...
>
>
> First it discusses the "protocol version", but suddenly switches to "the value of the Version Number field".
>
> So I would propose:
>

Fine.

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Tue, 30 May 2006 12:45:06 +0100

Lutz,

> to unconfigure the metering.

It's not good to have two different ways of doing things.

So I propose that setting the collectorProtocolVersion to 0 disables the 
exporter but does not remove it. ie, it's effectively in a standby state.

A report including collectorProtocolVersion = 0 indicates an exporter 
that exists (ie, has been configured) but is not operational.

(Re-)configuring the exporter with a lifetime of zero would be the 
correct way to deconfigure it, ie to completely remove the configuration.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 May 2006 14:04:20 +0200

Dear all,

We could debate what is the best to (un)configure an IPFIX device but, 
as there is no draft specifying it, I'm not sure it makes sense for now.
However, I like to approach to have "A value of 0 indicates that no 
export protocol is in use." in the collectorProtocolVersion I.E. 
description, just in case... a potential future draft specifying the 
configuration would make use of it.

Regards, Benoit.
> So I propose that setting the collectorProtocolVersion to 0 disables 
> the exporter but does not remove it. ie, it's effectively in a standby 
> state.
>

---

From: Sven Anderson <[email-masked]>
Date: Tue, 30 May 2006 17:54:06 +0200

Hi Jürgen,

see inline.

>      The destination port identifier to which in the the Exporting
                                                ^^^^^^
This should be removed, right?

>      TCP and SCTP this is the destination port number.  This field MAY

[...]

>      The index of the IP interface where the Exporting Process sends
                                     ^^^^^
>      Flow information.  The value matches the value of managed object

Is this clear? This is the interface on the Collector's side, right? Then
I  suggest "to which", like in the other sections. Else, it sounds as if
the interface on the Exporter's side is meant.

Cheers,

Sven

-- 
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany

---

From: Paul Aitken <[email-masked]>
Date: Tue, 30 May 2006 19:15:01 +0100

Sven,

> the interface on the Exporter's side is meant.

It's the exporter's interface, because if the collectorIPv6Address is a 
IPv6 link-local address or the collectorIPv4Address is a private IPv4 
address, then it won't be possible to tell which interface should be (or 
is being) used without further qualification.

It doesn't make any sense to configure which interface on the collector 
should be used, since the exporter probably has very little (if any) 
control over that because it depends on how traffic is routed through 
the network.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 31 May 2006 00:53:55 +0200

Hi Sven,

Thanks for checking.

Fixed.

> Is this clear? This is the interface on the Collector's side, right?

No, it's the exporter's side.

> Then I  suggest "to which", like in the other sections. Else, it
> sounds as if  the interface on the Exporter's side is meant.

This is meant indeed. Do you think we need to make more clear that
it is meant as it sounds?

Thanks,

    Juergen