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