Subject: Re: [ipfix-protocol] Re: draft-leinen-ipfix-tcp-00.txt

From: Benoit Claise <[email-masked]>
Date: Sun, 01 Aug 2004 16:47:19 +0200

Hi Simon,

Thanks for your draft. I read it and I have one concern regarding the 
directionality:
   "The IPFIX collector initiates a TCP connection to the exporter. 

I think that we should stick to the plan that the Exporter initiates the 
connection
Let me give you a few arguments

- For UDP, we've got no other choice that to configure the collector IP 
address and UDP port on the collector
   Why be different for a different protocol? Also, as you pointed out 
in the draft, the SCTP section was created with that notion in mind.

- When IPFIX is configured, we must struggled to loose a minimum amount 
of flow records.
   A backup connection will always be configured from the exporter: the 
exporter must be the one to quickly switch over to a new collector.
   How would the failed collector communicate to the backup collector to 
setup a new TCP connection to the exporter?
   You wrote "In the default configuration, a collector MUST NOT attempt 
to establish a connection more frequently than once per minute."
   We would be loosing a lot of flow records during that one minute 
period. Again, from a transport protocol point of view, the exporter is 
the best guy to minimize the number of lost flow records.

- I'm afraid that, if we've got an opened TCP port on all the routers, 
assigned by IANA,  that port will be the center of all the attention 
for  hackers, because a connection to that port could be basically mean 
that all flow records will be sent through the TCP connection. So 
someone would know everything about your network!
I see that you addressed this:  
    "It SHOULD be possible to
   configure this in terms of strong identities such as IKE [6]
   public-key certificates or pre-shared keys.  An exporter SHOULD
   detect and log unauthorized connection attempts."
However, isn't it like an extra burden while we could simply say: the 
exporter initiates the connection once the metering process is 
configured, whatever the way (SNMPSet, CLI, you name it, anyway it is 
out of the scope of this WG)
Note: Isn't it the same for the IANA port on the collector, you may ask? 
Well, the collector are better protected. On the top of that, an attack 
on the TCP port of the collector would block the receival of flow 
records, but the attacker would not know anything the flow records...

- We might want to configure different aggregations to export to 
different collectors. We might want to configure different reliability 
to different collectors
   Those are somehow linked to the templates/aggregations configuration 
on the exporter, and as the remote configuration from the collector to 
exporter is out of scope.

-  You wrote "The IPFIX collector initiates a TCP connection to the 
exporter.  By
   default, the exporter listens for connections on TCP port XXXX (to be
   assigned by IANA).  It MUST be possible to configure the exporter to
   listen on a different TCP port."
Does it mean that, by default, only one TCP connection can be 
established to the exporter?
Or you would switch to another port

I've some other minor points to discuss.
1. You wrote:
"When an exporter has no more data to send, it SHOULD close the TCP 
connection normally.
I think the behavior is that  the connection should remain up until 
configured otherwise.

2. Ideally, to insert into the protocol draft, we should have a 
somehow-similar structure as SCTP and UDP, i.e.
    TCP......................................................15
       Congestion Avoidance...................................15
       Reliability............................................15
       MTU....................................................15
       Exporting Process......................................15
           Association...........................................15
           Source ID.............................................16
           Stream................................................16
           Template..............................................17
       Collecting Process.....................................17
       Failover...............................................17

3.
   "When an exporter finds that the rate at which flow records should be
   exported is consistently higher than the rate at which TCP permits to
   send, it SHOULD adapt the metering process so that it generates a
   lower amount of data, for example by increasing the sampling
   interval, or by increasing the amount of aggregation.  If it does
   this, the exporter SHOULD periodically attempt to switch back to the
   original metering configuration when congestion subsides."
Is this proper to TCP? Or should we have a combined section for SCTP as 
well?
Then which type of sampling: packet sampling or flow sampling?
Are we going to overlap with PSAMP?
To avoid to have to specify all in details and to overlap with PSAMP, I 
would write a combined section something like:
.... should consider .... instead of SHOULD.

Regards, Benoit.

>I just posted a first cut at an IPFIX-over-TCP draft, hopefully in
>time before the cutoff.  It's short, please have a look at it.
>Section 2 is a list of open issues that I came up with. Feel free to
>discuss these and other issues here!
>  
>

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