Subject: [AAA-WG]: Identities in RADIUS translation

From: <[email-masked]>
Date: Tue, 30 Sep 2003 11:24:53 +0300

Identities in RADIUS translation
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: September 30, 2003
Reference: 
Document: NASREQ 13b
Comment type: T
Priority: 1
Section: 9.1-9.3
Rationale/Explanation of issue:

While digging the Route-Record issue, I found several possible
problems in RADIUS translation (NASREQ -13b), related to
handling of Origin-Host/Realm and Destination-Host/Real AVPs...

1. Section 9.1 says that:

      "If the Diameter Command-Code is set to AA-Answer and the
      Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the
      gateway must send a RADIUS Access-Challenge with the
      Diameter Session-Id and the Origin-Host AVPs encapsulated
      in the RADIUS State attribute, with the prefix
      "Diameter/". This is necessary in order to ensure that the
      Translation Agent that will receive the subsequent RADIUS
      Access-Request will have access to the Session Identifier,
      and be able to set the Destination-Host to the correct
      value. 

   Since both Session-Id and Origin-Host are placed into a
   single State attribute (only one is allowed), they probably
   need to be separated somehow. Can we assume that Origin-Host 
   doesn't contain any "/" characters? (likely to be true, although
   in theory FQDN can contain just about anything)

   (A minor note: since only one State attribute is
   allowed in RADIUS, this breaks if the AA-Answer already contains
   a State AVP. But since the State AVP should be used only
   by translation agents, this should occur only if we 
   have multiple translation steps.)

2. The State attribute above stores the value needed for 
   Destination-Host, but what about Destination-Realm? Currently
   it's taken from the User-Name attribute... and if the 
   Origin-Realm in AA-Answer is always guaranteed to be the same 
   as the Destination-Realm in AA-Request, then it should work.
   But is this guaranteed? 

   (If it isn't, maybe we need to store the realm in State
   attribute as well?)

3. Earlier Section 9.1 also says that

      "If the RADIUS request contained a State attribute, and
      the prefix of the data is "Diameter/", the data following
      the prefix contains the Diameter Session-Id. If no such
      attributes are present, and the RADIUS command is an
      Access-Request, a new Session-Id is created. The
      Session-Id is included in the Session-Id AVP.

   This isn't in sync with the text above... the State attribute
   can also contain the value for Destination-Host.

4. Also in Section 9.1:

      "The Diameter Origin-Host and Origin-Realm AVPs MUST be
      created and added using the information from an FQDN
      corresponding to the NAS-IP-Address attribute (preferred
      if available), and/or the NAS-Identifier attribute. (Note
      that the RADIUS NAS-Identifier is not required to be an
      FQDN)"

   This text clearly suggests that Origin-Host should contain 
   the NAS identity, while the text in Section 9.3 says it 
   should be the translation agent's own identity.

   The former seems IMHO more logical (and when forwarding a
   RADIUS response to Diameter AA-Answer, the Origin-Host there
   is the RADIUS server/proxy identity, not translation
   agent)... but maybe there are some problems with this
   approach?

   A related issue: If this is the NAS identity (e.g. resolved
   from NAS-IP-Address), how is the Origin-Realm chosen?
   Do we use the translation agent's own realm or what?

5. Just after the text quoted above (also in 9.1)

      "The AAA protocol specified in the identity would be
      set to "RADIUS"."

   Origin-Host/Origin-Realm have type DiameterIdentity, not
   DiameterURI, so they don't have a protocol field. Just
   delete this sentence.

6. Section 9.2 says that (when translating a RADIUS response
   to Diameter AA-Answer)

      "The response's Origin-Host information is created from
      the FQDN of the source IP address of the RADIUS message."

   What about Origin-Realm? Do we use the translation agent's
   own realm?

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 30 Sep 2003 19:23:33 +0300

>    in theory FQDN can contain just about anything)

If fqdn has a "/", then that node would work pretty badly as a
http server. Unfortunately, I was unable to find the RFC that
defines FQDNs, to check if there's some truly illegal char,
such as '\0'.

>    have multiple translation steps.)

Theoretically, you could append the contents of the original state avp
to the data needed by the translation agent.

>    as the Destination-Realm in AA-Request, then it should work.

I am not sure. The spec does not say. What if there are multiple
realms served by one home server?

>    (If it isn't, maybe we need to store the realm in State

That would seem prudent. Other opinions?

>    can also contain the value for Destination-Host.

Yes.

>    The former seems IMHO more logical (and when forwarding a

Agreed.

>    DiameterURI, so they don't have a protocol field. Just

Ok.

--Jari