perfSONAR Announcements

[Jason Zurawski <>]

All;

Many of you know that the pS Performance Toolkit team is preparing to release 
version 3.3 of the software very soon.  Looking back, the first release of 
this product was made in 2008.  5 years of experience has delivered a stable 
and well adopted system, now used around the world, and we have the community 
to thank for their commentary and patience as a part of that process.  

One blind spot that exists, both in our software and other measurement 
products in general, is the ability to work with security infrastructure in a 
seamless manner.  As many know, security infrastructure such as IDSs, 
Firewalls, and other mechanisms meant to control the traffic patterns of 
networks, rely on a priori knowledge of the communication pattern.  For 
instance using 'well known' ports makes it easier to white-list traffic, and 
increases the chances for success in performing measurement through a secured 
environment since it can be identified as being harmless.  The traditional 
stance of tool makers has been to allow for the fungible use of ports - any 
will do, and steps were never taken to mandate operation to specific numbers 
or ranges.

Working closely with the NTAC Performance Working Group, this next release of 
toolkit software features a new approach: an attempt to migrate all of the 
major measurement tools (e.g. BWCTL, OWAMP, NDT, NPAD, Pinger, Traceroute, 
Reverse CGIs, and some others) to use a set of fixed ports for communication. 
 We hope this will have two major impacts:

- Well known ports will make it easier for sites that are using firewalls to 
specify the requirements of measurement on the host itself, and all network 
devices in the middle

- Sites that are not using firewalls will be able to test to firewalled sites 
(as well as firewalled sites testing to them) and be guaranteed of success.  
Previous attempts in this space could have involved sites choosing different 
'ranges' for their tools, and the tools did not effectively negotiate on a 
strategy that would lead to working measurement.  

To facilitate this new approach, we have taken a couple of steps to educate 
everyone:

- A document (attached, and available online here: 
http://psps.perfsonar.net/toolkit/20130416-Firewall-PerfWG.pdf) explains the 
known problems, our solution, and the list of ports and tool changes

- The pS Performance Toolkit is now including a stub iptables file that can 
be used by sites that wish to implement host level filtering.  In our basic 
testing we have noticed that iptables did not have a severe impact on 
measurement traffic, but we still believe turning this feature on is a site 
level decision.  

We do want to make one peripheral point clear: this new approach is not an 
endorsement for the use of firewalls in front of the measurement 
infrastructure.  As the perfSONAR project has noted in the past - measurement 
of the network is best done without other devices impacting performance.  We 
are however cognizant that not all sites have adopted Science DMZ principals 
as of yet, or may have other restrictions in place that necessitates the use 
of security infrastructure for protection of resources.  Sometimes seeing the 
performance through a firewall can be a positive thing, especially if you are 
emulating the experience that end users would see - the data provided from 
perfSONAR can be a powerful motivating factor to share with network and 
campus administration.  

As always, we welcome questions and comments on this issue to any of the 
relevant mailing lists.  

Thanks;

-jason

Attachment: 20130416-Firewall-PerfWG.pdf
Description: 20130416-Firewall-PerfWG.pdf