 |
 |
Hi Alejandro, fine. And my point is (in your case), although it is some work for national eduroam admins in UK and Spain, they can enable what you need and want. Regards Miro ----- Original Message ----- From: "Alejandro Perez Mendez" <[log in to unmask]> To: "Miroslav Milinovic" <[log in to unmask]>; <[log in to unmask]> Cc: <[log in to unmask]> Sent: Wednesday, May 28, 2014 2:31 PM Subject: Re: [eduroam-ot] Problem with RADIUS attributes 164 and 165 (RFC 7055) > Hi Miroslav, > > my apologies, I probably was not clear enough in my mail. What you said is > exactly what I understood from Paul. My point was that, if one have a > situation as the one we have in the CLASSe project, where one institution > deploys a RP (e.g. at UMU in Spain), and other deploys an IdP (e.g. at > KENT in UK), the eduroam infrastructure "as is" will probably fail to > deliver Moonshot's attributes correctly, as packets will traverse top > level proxies. In that situation, as you said, one need to fallback to > Trust Router or another dynamic discovery method. > > I understand this does not affect to national traffic, nor specific > routing agreements between institutions. > Sorry if my mail created any confusion. That was not intended at all. > > Regards, > Alejandro > > El 28/05/14 14:20, Miroslav Milinovic escribió: >> Alejandro, >> >> IMO either I missunderstood you or your interpretation of the answer you >> got from eduroam OT is not 100% correct. >> I am not sure that Paul wrote that moonshot traffic is "unwanted" in >> eduroam infrastructure. >> >> The current position (decision) is (only) not to proxy the moonshot >> traffic at the eduroam top level RADIUS servers. >> >> National eduroam providers are free (and able) to permit/enable moonshot >> traffic nationally and internationally (via dynamic discovery methods). >> >> So, I repeat, we are not treating moonshot as unwanted in the eduroam >> infrastructure. >> >> I hope I clarified the matter. >> >> Kind regards >> >> Miroslav Milinovic (as European eduroam service task leader) >> >> ----- Original Message ----- From: "Alejandro Perez Mendez" <[log in to unmask]> >> To: <[log in to unmask]> >> Sent: Wednesday, May 28, 2014 1:59 PM >> Subject: Fwd: Re: [eduroam-ot] Problem with RADIUS attributes 164 and 165 >> (RFC 7055) >> >> >> FYI, eduroam AAA infrastructure does not (and will not) support Moonshot >> as is. They recommend using Trust Router or similar instead, to make P2P >> connections. >> >> Regards, >> Alejandro >> >> >> -------- Mensaje original -------- >> Asunto: Re: [eduroam-ot] Problem with RADIUS attributes 164 and 165 >> (RFC 7055) >> Fecha: Wed, 28 May 2014 12:45:36 +0200 >> De: Paul Dekkers <[log in to unmask]> >> Para: Alejandro Perez Mendez <[log in to unmask]>, [log in to unmask] >> CC: Gabriel López <[log in to unmask]>, Rafa Marin Lopez <[log in to unmask]>, José >> Manuel Macías <[log in to unmask]> >> >> >> >> Hi Alejandro, >> >> Hereby a reply to your request to enable Moonshot via the international >> eduroam proxy infrastructure: >> >> While it is our intention to provide a transparent RADIUS proxy >> infrastructure for eduroam purposes, that's not the case for Moonshot. >> We provide the service for eduroam, and that's what NRENs/NROs signed up >> for and signed the policies/compliance agreements for. So even if we >> have the correct dictionaries installed (we're now using the late 2013 >> versions), we consider the Moonshot requests as unexpected traffic on >> our proxy infrastructure. >> >> We've had discussions about this at TNC with the GeGC (Global eduroam >> Goverance Committee) and in the Geant eduroam steering group this >> morning, and decided to not permit Moonshot traffic across the >> international eduroam proxy infrastructure. (Whether a RADIUS service is >> used for more purposes within a country/region, that (and its filtering) >> is up to the NRO.) >> >> Moonshot is not just unexpected/unwanted traffic for some organizations, >> it's as I understand not the way Moonshot wants to deal with this >> traffic anyway: this is what the trust router is designed for. If >> implementing the trust router is not feasible at this time, making a >> direct RADIUS connection or using dynamic discovery (via NAPTR records >> in DNS and RadSec) would be a proper alternative, assuming that all >> parties involved agree. >> >> The added bonus in this approach is that there's a lot more trust in the >> attributes you receive. I understand the GSS-Acceptor-Realm-Name should >> match the realm from the originating site, but without a more direct >> connection this trust is relatively weak. >> >> We did consider making Moonshot routing as opt-in for the international >> eduroam infrastructure, but the amount of work is outblanced as this >> traffic would only be considered an intermediate solution until the >> trust router works well. >> >> I hope you understand this position and find alternative ways of >> interconnecting your Moonshot deployments; I'm interested in your >> feedback, >> >> Regards, >> Paul >> >> >> On 5-20-14 10:44, Alejandro Perez Mendez wrote: >>> Dear eduroam operations team, >>> >>> from the University of Murcia (UM) we are working in the GN3Plus project >>> (SA5 task). Specifically, we are working on the deployment of the >>> Moonshot technology over the eduroam RADIUS infrastructure. In this task >>> we are collaborating with the University of Kent and with RedIRIS. >>> >>> In particular, we are testing a connection between the UM and Kent, that >>> uses the actual eduroam's RADIUS infrastructure to convey the Moonshot >>> authentication process. This connection is established as follows: >>> >>> moonshot.um.es <-> UM <-> RedIRIS <-> ETLRs <-> Janet <-> Kent <-> >>> cs.kent.ac.uk >>> >>> However, we have having problems with the following attributes, recently >>> standardized in RFC 7055: >>> | GSS-Acceptor-Service-Name | 164 | user-or-service portion | >>> | | | of name | >>> | | | | >>> | GSS-Acceptor-Host-Name | 165 | host portion of name | >>> | | | | >>> | GSS-Acceptor-Service-Specifics | 166 | service-specifics | >>> | | | portion of name | >>> | | | | >>> | GSS-Acceptor-Realm-Name | 167 | Realm portion of name >>> >>> In particular, Moonshot includes attributes 164 and 165 on each >>> Access-Request packet it generates during the authentication process. >>> These attributes are therefore sent from UM to Kent but, at some point >>> of the path, they are wrongly transcoded as Vendor(26).Ascend(529).164 >>> and Vendor(26).Ascend(529).165. This seems to be happening since >>> historically Ascend used to use those codes illegally, and it seems that >>> some intermediate proxy is trying to "fix" them by moving them into the >>> correct namespace (i.e. as Vendor-Specific attributes). However, this is >>> a mistake, as these attributes have now a standard meaning, and should >>> not be mangled. >>> >>> Doing our research, we've checked that neither UM nor RedIRIS are doing >>> this transcoding. Kent has also verified that their organizational >>> server is not doing this transcoding either. And Janet claims they do >>> not touch these attributes. Hence, our guess is that this transcoding is >>> being done at some of the ETLRs. >>> >>> Could you check this out? This should be happening on each proxied >>> Access-Request packet that contains [log in to unmask] >>> If this transcoding is happening, I'd like to request you to disable it, >>> as this attributes have now been allocated by the IANA and are no longer >>> in the illegal space. >>> >>> Thanks and best regards, >>> Alejandro >>> >>> >>> >> >> >> >> > >