An open discussion list for topics related to the eduGAIN interfederation service.

[Chris Phillips <Chris.Phillips AT canarie.ca>]

This thread has some^H^H^H^H a lot of interesting things:

1. This technique appears to be not an n by m problem but an N by M by #
of instances of these tools problem and that is to say, not very scalable
and brute force like.

It's like every one who has a phone number calling every other phone
number to see if it works.
Every day. 

I get the desire to survey what's working and what doesn't and very much
support the eduGAIN CC in it's current form.
It's a good litmus test to poll a few URLs and provides a thumbnail view
with sufficient accuracy for now.

What's not sufficient about it (besides 'it's not exhaustive!')?


2.Are there cases of other internet scale components that do this? I'm
skeptical that there are and they probably don¹t do it for a reason.

If we look at other things like DNS servers, routers, web servers, TOR, or
other internet components or protocols, this behaviour/assessment doesn't
really manifest itself there -- does it? Why not and why would we pursue
that if other internet scale components don't have this?
If they do, I would like to hear the success stories please.


3. Has anyone thought about how this will be interpreted as malicious
traffic for nefarious purposes OR cases of unintended consequences if you
attempt to poll all sites working at all IdPs?

Case in point: When HeartBleed occurred, the notion of polling for such an
exposure was risky and borderline, if not 'illegal' in some jurisdictions.
 Help me understand why probing functioning Sps around the globe in all
IdPs doesn't tread in this area or get ensnared in this problem.

Another datapoint is another tool that can do some interesting things --
Ripe Atlas probes.  There's a reason that they have limited functionality.
It's not that it's technically not possible to do more, it very much is
possible to do a LOT more, but policy wise not prudent to have a device
that could result in highly improper data being retrieved and in turn
cause an unaware operator grief.

There are jurisdictions that have severe consequences for just visiting
sites. Demonstrating that very probability could be 'very bad'.
(Remember, there is no such thing as not making a mistake in configuration
-- they happen, this means they happen on the global stage and not just
locally.)

4. How sustainable is doing this, including the curation and data storage
over time?  

Storage and compute is free right? ;)

5. Privacy and security considerations.

There's a difference between 'does this look healthy' and posting an
entire medical chart on something.  How would one manage this?


I really like the ECC (as well as the eduGAIN validations tools at
technical.edugain.org) and how both have evolved to add value to our
operations. I really can't operate in a global context without them.  Hats
off to creators and sustainers of the tools and really appreciate that
they are there. If this type activity is being seriously contemplated, I
hope we can have some dialogue on the above points before leaping into the
unknown waters because it's not just a technical feasibility question.

C



On 2017-03-03, 6:50 AM, "Leif Johansson" <leifj AT sunet.se> wrote:

>
>> this and adapt ECCS. As you say, this would however mean that each IdP
>> currently would be hammered more than a thousand requests per day
>
>good!
>
>> because m=1466 as of today :-) I know at lesat from our Danish
>> colleagues that this might ruin their statistics if not handles
>>properly.
>> 
>
>just add an extension to the authnrequest saying this is a probe
>
>> Another option could be that the ECCS REST/JSON API is extended to check
>> a particular IdP-SP combination and return the check results.
>> 
>
>this would introduce too much delay for the applications I've been
>thinking about - its more important that the API returns quickly
>then that the test is 100% fresh IMO
>
>> 
>> @Marco (ECCS lead developer): Feel free to add/comment on what you think
>> of this.
>> 
>> Best Regards
>> Lukas
>> 
>> [1] https://technical.edugain.org/eccs/
>>     https://wiki.edugain.org/EduGAIN_Connectivity_Check
>> 
>

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