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