perfSONAR User Q&A and Other Discussion

[Jason Zurawski <>]

Hi Ralph;

Please note that this discussion began in March, with much time for the 
community to weigh in on matters:

  https://lists.internet2.edu/sympa/arc/performance-wg/2013-03/msg00000.html

While I am sure I will not convince you that this is the 100% correct 
approach, be aware that first and foremost the measurement tools must be 
useful to end users and operators.  This is all in response to feedback that 
points to interoperability problems and a lack of guidance on the proper way 
to configure basic test infrastructure.  The approach must be weighed in 
terms of usability and functionality.  The document is not an endorsement of 
firewalls, or even a hard requirement that everyone must follow.  It does 
note that for an interoperable experience that benefits the community (for 
those that use firewalls, and for those that do not) we need to speak the 
same language with regards to configuration.  

If you have further commentary on this matters, the performance working group 
()
 is the proper venue to continue the discussion.  

Thanks;

-jason

On Jul 1, 2013, at 7:35 AM, "Niederberger, Ralph" 
<>
 wrote:

> Dear Jason
> 
> From a security point of view this " NTAC Performance Working Group's
> Firewall document" is a horrific scene.
> 
> Since several years security experts are discussing the implementation of
> GridFTP using peripheral (not well known) ports. 
> The recommendation to open up to 5000 Ports only because Firewall security
> issues have not been thought
> about in the design phase really does not reflect security risk
> minimization. The same will apply to perfSONAR tools also if used in this
> way.
> 
> Why are we starting to do the same with network performance tools.  
> 
> There should be no problem to change iperf doing multithreading. This should
> be discussed with the developers.
> This would allow that a service is listening on port 5001, and only on this
> port, 
> though tests are done by others in parallel already. Since parallel testing
> of one interface does not make real sense, 
> the server spawning processes could handle scheduling of tests. Since
> spawning of processes is done before measurements start, 
> this will not degrade measurement throughput.
> 
> Firewalls look into quadrupels (sourceip, sourceport, destip, destport) so
> allowing access from 
> everywhere (sourceip, variablesourceport) to destip (iperfserver) port 5001
> is always unique. 
> A new request from sourceip will use a different variablesourceport and so
> firewalls can distinguish between those two sessions.
> You do not need port ranges for the iperf servers. 
> Also UDP traffic, being not session based by design, is handled by nearly
> all state of the art firewalls as virtual sessions, taking into account
> those quadrupels. 
> 
> Of course this would need reprogramming of iperf servers, nuttcp servers,
> ... , but having security in mind, this makes much more sense than opening a
> lot of ports within a firewall.
> Moreover most of the time no service on the iperf server is using those
> ports, because the iperf server would only be started on higher ports if
> several
> parallel tests have been launched. This mostly not used ports allow local
> users of the iperf servers to start services using those ports, 
> making firewall policies useless . 
> 
> My2Cents and best regards
> 
> Ralph
> 
> -----Ursprüngliche Nachricht-----
> Von: 
> 
> [mailto:]
>  Im Auftrag von Jason Zurawski
> Gesendet: Freitag, 28. Juni 2013 21:39
> An: perf-node-users Users; perfsonar-user; perfsonar-ps-users;
> 
> Cc: 
> 
> Betreff: [perfsonar-user] Updated Firewall Document
> 
> All;
> 
> The latest release of the pS Performance Toolkit featured some of the steps
> recommended in the NTAC Performance Working Group's Firewall document, found
> here:
> 
>  http://psps.perfsonar.net/toolkit/firewalls.html
> 
> After some time testing around the community, we found a weakness that needs
> to be corrected.  We had originally targeted 200 ports to be made available
> for OWAMP testing, and configured the daemon to use the ones recommended.
> We have found that some sites are testing to a large number of sites, as
> well as being tested to by a large number of external parties, and are
> quickly exhausting the 200 available ports.  To combat this we updated the
> recommendation to be much larger (1200 ports) in the online documentation
> found above, and in the FAQ:
> 
>  http://psps.perfsonar.net/toolkit/FAQs.html#Q6
> 
> We will also be making an update to the OWAMPD RPM in the coming weeks that
> will fix this issue.  For now if anyone sees that owamp tests are failing
> you can make a manual change to /etc/owampd/owamd.conf and alter the
> 'testports' variable.  We apologize for any inconvenience this may cause.  
> 
> Thanks, and let us know if there are any questions;
> 
> -jason