perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Hyojoon Kim writes:

 

For example, nothing is stopping me from running below from my machine, even if I don’t own and administer "albq-pt1.es.net” and "ameslab-pt1.es.net”. I get results right away. 

   $ pscheduler task trace --source albq-pt1.es.net --dest ameslab-pt1.es.net

Now assume I am an admin of albq-pt1.es.net or ameslab-pt1.es.net. How do I prevent some arbitrary person from initiating a perfSONAR test that uses my perfSONAR node? Is this even possible to prevent? Or maybe limiting this does not align with the philosophy of open and public perfSONAR?

 

As big as we are on openness, there are lots of reasons not to allow anyone to do anything, and pScheduler’s limit system supports a pretty wide range of ways to prevent it.  After the upcoming workshop on jq, I’m going to start work on one that covers the limit system.  We’ve added a lot of features to it over what BWCTL could do and have a couple more in the pipeline for 4.1.

 

In other words, I think “requester” above actually means "another perfSONAR node to run tests with”, not a person/node who is asking (or requesting) to run some test with my node and some other node. The documentation is not really clear about this, so I’m a unsure.

 

The clarity problem is a side effect of having the author of the software (me) write the documentation, but we’ll get that fixed.  You are looking in the right place, though.

 

“Requester” in pScheduler terms means the source of a task request from the perspective of the node that receives it.  This is a departure from BWCTL’s model, where local and third-party tests meant something different.  To pScheduler, everything is third-party, but some requests happen to originate from an address bound to an interface on the local system.

 

The trace task in your example is what pScheduler would term a single-participant test, meaning that the only system actually doing anything is albq-pt1, which just runs traceroute and collects the results.  (Since you didn’t specify the host you’re on, I’m going to call it joonps.)  From albq-pt1’s perspective, the requester is joonps, and if albq-pt1’s limits allow joonps to request a trace test, it will go forward.  Ameslab-pt1 doesn’t have any involvement in the test other than having a packet bounced off one of its interfaces; it wouldn’t know or care if it was pScheduler doing it or someone running traceroute at the command line.  (Like the rtt test, you can ask any pScheduler that will have you to do a trace to any host you want; there doesn’t have to be a pScheduler at the far end.)

 

If you were testing throughput instead of trace, that test would be multiple-participant, meaning there are two pSchedulers involved, one at each end to run the iperf2/iperf3/nuttcp client and server.  Albq-pt1 is what’s called the lead participant and is in charge of administrative duties that include arranging the test with all of the other participants.  (What you can read between the lines of that statement is that it’s possible to do n-participant tests with pScheduler, but nobody’s dreamed one up yet.)  Albq-pt1 still sees the requester as joonps, but it must ask ameslab-pt1 to set up a task and be the second participant.  Since pScheduler’s trust model is based on who’s doing the requesting, ameslab-pt1 sees the requester as albq-pt1 and its limits would make the go/no-go decision passed on that.  (It would also not know that joonps was the original requester.)  This leads to a transitive thing where ameslab-pt1’s trust of alb1-pt1 implies trust for joonps.  To put it another way ameslab-pt1’s thought process is, “I trust albq-pt1 enough to do a test with it, and if albq-pt1 trusts joonps enough to ask me for a test, that’s good enough for me.”

To get you started, I’ve created a gist containing limit configuration that allows the local system and hosts whose IPs reverse-resolve to something in a specific zone to run tests and rejects everything else.  You’ll find that here:  https://gist.github.com/mfeit-internet2/2189c4d2c2872bf04786b217886e9789.

 

--Mark