 |
 |
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