Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate?

From: "David B. Nelson" <[email-masked]>
Date: Thu, 8 Jan 2009 10:58:47 -0500

Hi Hannes,

During the AAA Doctors lunch at IETF-73 you volunteered for the action item
of drafting some boilerplate / template text for the required Diameter
Considerations section of RADIUS I-Ds and RFCs.  How is that coming along?

Regards,

Dave

David B. Nelson
Chief Software Architect
Elbrys Networks, Inc.
75 Rochester Ave. Unit 3
Portsmouth, NH 03801
Voice: +1 603.570.2636
FAX: +1 603.766.0934
Skype: david_b_nelson

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 10 Jan 2009 16:02:43 +0200

Hi Dave, 

Thanks for the reminder. 

Based on the discussion we had with Pasi in context of the MIPv6 integrated
document I tried to figure out how far we are with the deployment of RADIUS
- Diameter translation agents. 

I got feedback, which I will try to summarize (as mentioned in my recent
DIME status update message).

Why does that activity relate to the issue of the boilerplate? We are
writing something in our documents with a certain model of interworking in
mind. For some reason, this interworking does not exist in today's
deployment (based on the feedback I received) and so far I haven't received
evidence that it will exist in the future. 

So, here is my thinking: 

* RADIUS and Diameter are different protocols with different deployment
stories. 

* The data types in RADIUS and Diameter are different. There is overlap but
RADIUS offers fewer data types than Diameter.

* The design considerations in Diameter are different to the one in RADIUS.
A big difference is the fact that Diameter has the concept of applications
and RADIUS doesn't have those (ignoring some tiny details). 

The above-mentioned aspect might lead to different designs in RADIUS and in
Diameter when considering the deployment environment and the available
protocol mechanisms. 

This makes translation more complex. Since there is very little translation
done (other with legacy systems) this does not really matter that much. 

This makes me believe that there should not be a requirement to write RADIUS
Diameter consideration sections in the document. 

If document authors want to include Diameter solution aspects into the same
document then they can obviously do that. This is a pure document management
task. However, they have to consider the entire range of Diameter design
considerations and this may lead to the need to define a Diameter
application and hence the previously short section might be rather long. 

In any case, a WGLC should be posted to the DIME mailing list if there are
Diameter considerations in the document. 

Does this make sense? Feedback from the DIME group? 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of David B. Nelson
>Sent: 08 January, 2009 17:59
>To: 'Tschofenig, Hannes (NSN - FI/Espoo)'
>Cc: [email-masked]
>Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate?
>
>Hi Hannes,
>
>During the AAA Doctors lunch at IETF-73 you volunteered for 
>the action item of drafting some boilerplate / template text 
>for the required Diameter Considerations section of RADIUS 
>I-Ds and RFCs.  How is that coming along?
>
>Regards,
>
>Dave
>
>David B. Nelson
>Chief Software Architect
>Elbrys Networks, Inc.
>75 Rochester Ave. Unit 3
>Portsmouth, NH 03801
>Voice: +1 603.570.2636
>FAX: +1 603.766.0934
>Skype: david_b_nelson
>
>

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 10 Jan 2009 09:17:58 -0500

Hi Hannes,

I've added RADEXT to the distribution, as well.

I agree, based on your summary of the state of the art of translation
gateways and the other issues you highlight, that the simple Diameter
Considerations text that we've been using, modeled after the assumptions of
the Diameter NAS Application (RFC 4005), is a bit misleading.

If the recommendation turns out to be that there should not be simplistic
RADIUS to Diameter interoperability, then I think there are two follow up
issues:

(1) Guidance on when Diameter clients and servers can and cannot use (or
re-use) RADIUS attributes in the legacy <255 ID space.

(2) A prohibition on Diameter documents defining and new AVPs in the legacy
<255 ID space.

I think there was an assumption that any attributes/AVPs in the legacy ID
space would be interchangeable, is a simple fashion.

Regards,

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Saturday, January 10, 2009 9:03 AM
To: 'David B. Nelson'; Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]; [email-masked]
Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter
compatibilityboilerplate?

Hi Dave, 

Thanks for the reminder. 

So, here is my thinking: 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 10 Jan 2009 16:30:13 +0200

Hi Dave, 

There isn't too much space left in the <255 ID space and hence that
consideration might not be too relevant in the future. 

I would not restrict the possibility to allocate RADIUS attributes (for
example from the extended attribute space) in a Diameter document or todo
Diameter AVP code allocation in a RADIUS document. 

The problem is that a more detailed investigation about this subject will
take some time. Do you have that time? 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Dave Nelson
>Sent: 10 January, 2009 16:18
>To: [email-masked]; [email-masked]; [email-masked]
>I agree, based on your summary of the state of the art of 
>translation gateways and the other issues you highlight, that 
>the simple Diameter Considerations text that we've been using, 
>modeled after the assumptions of the Diameter NAS Application 
>(RFC 4005), is a bit misleading.
>
>If the recommendation turns out to be that there should not be 
>simplistic RADIUS to Diameter interoperability, then I think 
>there are two follow up
>issues:
>
>I think there was an assumption that any attributes/AVPs in 
>the legacy ID space would be interchangeable, is a simple fashion.
>
>Regards,
>
>Dave
>
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Hannes Tschofenig
>Based on the discussion we had with Pasi in context of the 
>MIPv6 integrated document I tried to figure out how far we are 
>with the deployment of RADIUS
>I got feedback, which I will try to summarize (as mentioned in 
>my recent DIME status update message).
>
>Why does that activity relate to the issue of the boilerplate? 
>We are writing something in our documents with a certain model 
>of interworking in mind. For some reason, this interworking 
>does not exist in today's deployment (based on the feedback I 
>received) and so far I haven't received evidence that it will 
>exist in the future. 
>
>So, here is my thinking: 
>
>* RADIUS and Diameter are different protocols with different 
>deployment stories. 
>
>* The data types in RADIUS and Diameter are different. There 
>is overlap but RADIUS offers fewer data types than Diameter.
>
>A big difference is the fact that Diameter has the concept of 
>applications and RADIUS doesn't have those (ignoring some tiny 
>details). 
>
>The above-mentioned aspect might lead to different designs in 
>RADIUS and in Diameter when considering the deployment 
>environment and the available protocol mechanisms. 
>
>This makes translation more complex. Since there is very 
>little translation done (other with legacy systems) this does 
>not really matter that much. 
>
>This makes me believe that there should not be a requirement 
>to write RADIUS Diameter consideration sections in the document. 
>
>If document authors want to include Diameter solution aspects 
>into the same document then they can obviously do that. This 
>is a pure document management task. However, they have to 
>consider the entire range of Diameter design considerations 
>and this may lead to the need to define a Diameter application 
>and hence the previously short section might be rather long. 
>
>In any case, a WGLC should be posted to the DIME mailing list 
>if there are Diameter considerations in the document. 
>
>the action 
>>item of drafting some boilerplate / template text for the required 
>>Diameter Considerations section of RADIUS I-Ds and RFCs.  How is that 
>>coming along?
>
>
>DiME mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 10 Jan 2009 09:48:39 -0500

Hannes Tschofenig writes...
 
> There isn't too much space left in the <255 ID space and hence
> that consideration might not be too relevant in the future.

But it's another reason to restrict it right now -- to conserve such space
for RADIUS applications.  Unless, of course, the issues you've enumerated do
not apply in a specific use case, for example when no new Diameter
application is required and simple RADIUS data types suffice to the use
case.

> I would not restrict the possibility to allocate RADIUS attributes
> (for example from the extended attribute space) in a Diameter 
> document or todo Diameter AVP code allocation in a RADIUS document.

Well, RADIUS Extended Attributes is a different case to consider.  Given the
impedance mismatch between the Diameter AVP data model and the more
restricted RADIUS Extended Attribute data model, there are some serious
design issues.  For example, to share these EAs/APVs the Diameter solution
must be designed to fit within the RADIUS data model restrictions.

> The problem is that a more detailed investigation about this
> subject will take some time.

Correct.

> Do you have that time?

Probably not.  Nor do I have the required Diameter expertise.  That's why I
suggested a stop-gap "fix" in the form "just don't do that".  :-)