Subject: [IPFIX] exporterIPv4Address and exporterIPv6Address question

From: Andrew Feren <[email-masked]>
Date: Fri, 07 Dec 2012 12:31:15 -0500

Hi all,

So I wanted to recommend the following IEs to someone, but then I wasn't 
sure if their usage quite fit with the description.
130 	exporterIPv4Address 	ipv4Address 	identifier 	current 	

The IPv4 address used by the Exporting Process. This is used by the 
Collector to identify the Exporter in cases where the identity of the 
Exporter may have been obscured by the use of a proxy.

131 	exporterIPv6Address 	ipv6Address 	identifier 	current 	

The IPv6 address used by the Exporting Process. This is used by the 
Collector to identify the Exporter in cases where the identity of the 
Exporter may have been obscured by the use of a proxy.

The short question is does the "exporter" in question necessarily have 
to be exporting IPFIX originally (or for that matter even be exporting)?

What if I poll a bunch of SNMP and export that information as IPFIX to a 
collector?  The polled devices are not necessarily exporters, but this 
seems to be the most appropriate IE.  I don't see a situation where this 
would cause a problem, but maybe I am missing something.

SNMP is just one example.  Could be any source other than IPFIX. sFlow 
to PSAMP gateway, information gathered with WMI, etc.

If this usage makes sense can we maybe add some text to the description?

If not is there a better IE or should I propose one?

Thanks,
-Andrew

---

From: Paul Aitken <[email-masked]>
Date: Fri, 07 Dec 2012 19:19:17 +0000

Andrew,

> So I wanted to recommend the following IEs to someone, but then I 
> wasn't sure if their usage quite fit with the description.

Well these are IPFIX Information Elements in the IPFIX Information 
Model... If the other context adopts the IPFIX infomodel, then I don't 
see why not.

> What if I poll a bunch of SNMP and export that information as IPFIX to 
> a collector?  The polled devices are not necessarily exporters, but 
> this seems to be the most appropriate IE.  I don't see a situation 
> where this would cause a problem, but maybe I am missing something.

In this case it seems that you'd want to report the addresses of the 
polled devices, ie the source(s) of the SNMP information, rather than 
the exporter's address. Anyway the exporter's address will be visible to 
the collector (unless it's NAT'd).

So perhaps "sourceIPv4Address" would be appropriate? And we need to 
improve the definition for cases where packets aren't being observed, eg 
the exporting device is sending reports or alarms, or is being SNMP polled.

P.

> SNMP is just one example.  Could be any source other than IPFIX.  
> sFlow to PSAMP gateway, information gathered with WMI, etc.
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Fri, 07 Dec 2012 14:49:30 -0500

Paul,

> Andrew,

[ snip ]
>> What if I poll a bunch of SNMP and export that information as IPFIX 
>> to a collector?  The polled devices are not necessarily exporters, 
>> but this seems to be the most appropriate IE.  I don't see a 
>> situation where this would cause a problem, but maybe I am missing 
>> something.
>
> the exporter's address. Anyway the exporter's address will be visible 
> to the collector (unless it's NAT'd).
>
> improve the definition for cases where packets aren't being observed, 
> eg the exporting device is sending reports or alarms, or is being SNMP 
> polled.

OK, what about this hypothetical example.

Firewall reports via SNMP  firewall events, and the IP address(es) involved.

An agent polls that device to send this information (via IPFIX) to a 
collector for reporting.

My original thinking was that you might send

exporterIPv4Address, sourceIPv4Address, destinationIPv4Address, 
firewallEvent

This seems equivalent to what you would get if (instead of polling) my 
hypothetical agent was a proxy for the same information being sent via 
IPFIX from my hypothetical device.

Using sourceIPv4Address in place of exporterIPv4Address doesn't seem 
like the right choice here.

-Andrew

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Dec 2012 21:45:00 +0100

On Fri, Dec 07, 2012 at 07:19:17PM +0000, Paul Aitken wrote:
> polled devices, ie the source(s) of the SNMP information, rather
> than the exporter's address. Anyway the exporter's address will be
> visible to the collector (unless it's NAT'd).
> 

According to SNMP's architectural model, data is scoped by the agent's
snmpEngineID. Transport address may be plentiful and change more or
less arbitrarily. Yes, I know that many manager implementations still
do prefer dealing with IP addresses - but architecturally, the
snmpEngineID is the correct application layer identifier for an SNMP
agent.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>