Yes, that would be another solution though that streches the
"real-timeness" of the information. On the other hand, one can optimize
the statistical information to offload some of the work gled has to do.
Can't say that will be a simple task. On the other hand, a store and
formard approach (as you suggest) is likely the simplest solution with the
forward part being encrypted. That should be relatively easy to do.
Andy
On Tue, 2 Sep 2014, Fabrizio Furano wrote:
> Hi Andy, Oliver, all,
>
> I totally understand the concerns about encrypting the DNs.
> What about considering a deployment scheme where the UDP packets remain in
> the site and
> just the collected information is forwarded to brokers through secure
> channels?
>
> One of the points that may be improved in the current scheme is the fact
> that UDP packets
> have to be sent to distant servers. The fact that very few get lost in the
> WAN was just
> a nice surprise. As far as I can remember, also the original XrdMon scheme
> was keeping them in the site.
> This would require a more careful deployment of GLED as a service, which in
> my view
> is a desirable thing.
>
> Cheers
> Fabrizio
>
> On 09/02/2014 09:08 AM, Andrew Hanushevsky wrote:
>> Hi Oliver,
>>
>> Totally understandable. Encrypting the dDN would require a substantial
>> infrastructure addition to maintain encryption keys. So,
>> it's easier to just not transmit the DN (a config option). The dashboard
>> doesn't care but other people would like to know who is
>> causing problems (if any). Typical case of conflicting requirements. As an
>> aside, wouldn't unencrypted DN's be available via the
>> public key portion of the infrastructure anyway? I suppose that doesn't
>> matter if this is a specific privacy issue but then we
>> shouldn't be transmitting DN's in an operational context in the first place
>> (encrypted or not).
>>
>> Andy
>>
>> On Mon, 1 Sep 2014, Oliver Keeble wrote:
>>
>>> From my discussion with Romain, transmission of the DN is fine as long as
>>> it's encrypted.
>>>
>>> Oliver.
>>>
>>> On 01/09/14 15:20, Julia Andreeva wrote:
>>>>
>>>> We do need user DN for monitoring and popularity applications.
>>>>
>>>> Cheers
>>>>
>>>> Julia
>>>>
>>>>
>>>> On Mon, 1 Sep 2014, Lukasz Janyst wrote:
>>>>
>>>>> AFAIK, most of dCache sites use xrootd proxies, so they are likely
>>>>> affected, so is EOS, but fstreams have not been configured for Castor.
>>>>>
>>>>> Is it sufficient that we encrypt the fstreams or do you want us not
>>>>> to send the DNs at all?
>>>>>
>>>>> Cheers,
>>>>> Lukasz
>>>>>
>>>>> On 09/01/2014 03:04 PM, Oliver Keeble wrote:
>>>>>>
>>>>>> This is not a DPM issue - it's the xrootd fstream which sends out this
>>>>>> information so standard xrootd installations will also be affected.
>>>>>> dCache may be different, I don't know if they implemented this
>>>>>> themselves or not.
>>>>>>
>>>>>> On 01/09/14 13:48, Andrea Manzi wrote:
>>>>>>> Hi Romain,
>>>>>>> do you know if the problem affects only DPM-xrootd or all xrootd
>>>>>>> deployments are affected ?
>>>>>>> thanks
>>>>>>> Andrea
>>>>>>>
>>>>>>> On 01 Sep 2014, at 11:41, Romain Wartel <[log in to unmask]
>>>>>>> <mailto:[log in to unmask]>> wrote:
>>>>>>>
>>>>>>>> Domenico, Matevz,
>>>>>>>>
>>>>>>>> Just to close the loop; Please find the information below. The EGI
>>>>>>>> CSIRT, as well as WLCG operations coordination are coordinating this
>>>>>>>> issue.
>>>>>>>> I expect you will be contacted "officially" by the EGI security
>>>>>>>> vulnerability group (SVG) with an advisory before wednesday with all
>>>>>>>> the details.
>>>>>>>>
>>>>>>>> Then we would need you to look into this asap and report back on what
>>>>>>>> corrective actions can be taken.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Romain.
>>>>>>>>
>>>>>>>>
>>>>>>>> Begin forwarded message:
>>>>>>>>
>>>>>>>>> *From: *Romain Wartel <[log in to unmask]
>>>>>>>>> <mailto:[log in to unmask]>>
>>>>>>>>> *Subject: **xrootd - user DN information*
>>>>>>>>> *Date: *1 Sep 2014 10:46:21 GMT+2
>>>>>>>>> *To: *Maria Alandes Pradillo <[log in to unmask]
>>>>>>>>> <mailto:[log in to unmask]>>, Oliver Keeble
>>>>>>>>> <[log in to unmask] <mailto:[log in to unmask]>>
>>>>>>>>>
>>>>>>>>> Maria, Oliver,
>>>>>>>>>
>>>>>>>>> Here is the information I have regarding the user DN usage for
>>>>>>>>> monitoring in xrootd.
>>>>>>>>>
>>>>>>>>> I think the correct Indico link is
>>>>>>>>> https://indico.cern.ch/event/197803/session/0/contribution/10/material/slides/0.pdf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Our policy on this topic is at
>>>>>>>>> https://edms.cern.ch/file/855382/5/JobAccountingDataPolicy-v1.0.pdf
>>>>>>>>>
>>>>>>>>> "Each site is responsible for sending its accounting records on a
>>>>>>>>> regular basis, e.g. daily, with at
>>>>>>>>> least user DNs encrypted in transport, to a central data base
>>>>>>>>> defined
>>>>>>>>> by the Grid. This database is
>>>>>>>>> located at an Accounting Data Centre (ADC). The location of the ADC
>>>>>>>>> needs to be chosen
>>>>>>>>> carefully according to data privacy laws. "
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Romain.
>>>>>>>>>
>>>>>>>>> Begin forwarded message:
>>>>>>>>>
>>>>>>>>>> *From: *Sven Gabriel <[log in to unmask] <mailto:[log in to unmask]>>
>>>>>>>>>> *Subject: **[Irtf] more atlas fun*
>>>>>>>>>> *Date: *1 Sep 2014 08:14:12 GMT+2
>>>>>>>>>> *To: *IRTF <[log in to unmask] <mailto:[log in to unmask]>>,
>>>>>>>>>> David
>>>>>>>>>> Groep <[log in to unmask] <mailto:[log in to unmask]>>
>>>>>>>>>> *Reply-To: *Incident Response Task Force <[log in to unmask]
>>>>>>>>>> <mailto:[log in to unmask]>>
>>>>>>>>>>
>>>>>>>>>> This is easy, .. here we have an violation of a couple of our
>>>>>>>>>> policies on how
>>>>>>>>>> th handle user privacy data.
>>>>>>>>>>
>>>>>>>>>> "....The xrootd monitoring infrastructure sends user DN information
>>>>>>>>>> and
>>>>>>>>>> all user actions in cleartext over UDP packets across to SLAC in
>>>>>>>>>> the
>>>>>>>>>> US for monitoring. They are even open about it: .."
>>>>>>>>>>
>>>>>>>>>> https://indico.cern.ch/event/197803/session/0/material/slides/0
>>>>>>>>>>
>>>>>>>>>> ... Mitigation can be done by blocking OUTBOUND UDP apckets on each
>>>>>>>>>> DPM xrootd host, in particular the headnode, but this is
>>>>>>>>>> obviously not
>>>>>>>>>> done by default.
>>>>>>>>>>
>>>>>>>>>> DROP udp -- anywhere anywhere udp spt:53193
>>>>>>>>>> DROP udp -- anywhere anywhere udp spt:55721
>>>>>>>>>> DROP udp -- anywhere atl-prod05.slac.stanford.edu
>>>>>>>>>> <http://atl-prod05.slac.stanford.edu/>
>>>>>>>>>> ...."
>>>>>>>>>>
>>>>>>>>>> Does IRTF wants to send out an advisory to all sites to apply the
>>>>>>>>>> same FW
>>>>>>>>>> rules?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Sven
>>>>>>>>>> --
>>>>>>>>>> ========
>>>>>>>>>> Sven Gabriel
>>>>>>>>>>
>>>>>>>>>> Nikhef, Dutch National Institute for Sub-atomic Physics
>>>>>>>>>> Group Computer Technology / Room: H1.59
>>>>>>>>>> Phone: +31 20 5925103
>>>>>>>>>> Science Park 105 / 1098 XG Amsterdam / The
>>>>>>>>>> Netherlands_______________________________________________
>>>>>>>>>> Irtf mailing list
>>>>>>>>>> [log in to unmask] <mailto:[log in to unmask]>
>>>>>>>>>> https://mailman.egi.eu/mailman/listinfo/irtf
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Romain Wartel
>>>>>>>> Security Officer
>>>>>>>> Worldwide LHC Computing Grid
>>>>>>>> CERN, IT Department
>>>>>>>> CH-1211 Geneva 23, Switzerland
>>>>>>>>
>>>>>>>> http://www.cern.ch/LCG
>>>>>>>> http://cern.ch/security
>>>>>>>> <[log in to unmask] <mailto:[log in to unmask]>>
>>>>>>>> <[log in to unmask] <mailto:[log in to unmask]>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Oliver Keeble Information Technology Department
>>> [log in to unmask] CERN
>>> +41 76 487 5965 CH-1211 Geneva 23
>>>
>>> ########################################################################
>>> Use REPLY-ALL to reply to list
>>>
>>> To unsubscribe from the XROOTD-DEV list, click the following link:
>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
>>>
>>
>> ########################################################################
>> Use REPLY-ALL to reply to list
>>
>> To unsubscribe from the XROOTD-DEV list, click the following link:
>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|