perfSONAR User Q&A and Other Discussion

["Niederberger, Ralph" <>]

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature