Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 26 Nov 2008 11:29:22 +0100

I am copying AAA-Doctors who may be interested in commenting on this issue which is crossing the DIME and RADIUS borders. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, November 26, 2008 12:07 PM
> To: Romascanu, Dan (Dan); 
> [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: New version of draft-ietf-dime-mip6-integrated
> 
> 
> Folks,
> 
> Nothing in this thread so far has come to even close to 
> answering my main concern: specifying two similar solutions 
> (and translation between them) means more complexity and more 
> work. Why is this complexity and work needed?
> 
> So far, I have heard only explanations about how this 
> situation came to happen: somewhere down the line, two WGs 
> ended up taking on the work, and one of them (DIME) made 
> decisions that made sense locally (when considering only 
> Diameter aspects), and their draft came to IESG first. 
> Interestingly enough, the other WG (MEXT) has been working on 
> a RADIUS+Diameter solution (not a RADIUS-only solution!), and 
> if they had sent their document to IESG first, we probably 
> would not even consider publishing draft-ietf-dime-mip6-integrated. 
> 
> I want to repeat the last point, since it's quite important: 
> if the MEXT WG document (with a RADIUS+Diameter solution) 
> would already be in IESG evaluation stage, it's IMHO highly 
> unlikely that draft-ietf-dime-mip6-integrated would be 
> published at all (we would need *really* strong arguments why 
> two different solutions are needed in Diameter).
> 
> So far, it seems the only plausible reason for publishing 
> this document is that 3GPP needs it soon, and we're in a hurry.
> Is this really a good enough reason?
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: 25 November, 2008 15:42
> > To: Eronen Pasi (Nokia-NRC/Helsinki); 
> > [email-masked];
> > [email-masked]; [email-masked]
> > Cc: Tschofenig Hannes (NSN - FI/Espoo); [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Subject: RE: New version of draft-ietf-dime-mip6-integrated
> > 
> > See in-line. 
> > 
> > Dan
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Tuesday, November 25, 2008 3:29 PM
> > > To: [email-masked];
> > > [email-masked]; [email-masked]
> > > Cc: Romascanu, Dan (Dan); [email-masked]; 
> > > [email-masked]; [email-masked]; 
> > > [email-masked]; [email-masked]; 
> > > [email-masked]
> > > Subject: RE: New version of draft-ietf-dime-mip6-integrated
> > > 
> > > 
> > > Julien,
> > > 
> > > This document does not create a new Diameter application 
> -- it adds 
> > > couple of attributes to existing applications (NASREQ and 
> Diameter 
> > > EAP).
> > > 
> > > When doing so, we're faced with two choices: we can define the 
> > > attributes in the 0-255 range so that they require no new code on 
> > > translation agents (only at client and server); or we can pick 
> > > different numbers and require that the translation agents must be 
> > > updated to understand the new attributes.
> > > 
> > > The advantage of the latter approach is that if one lives 
> in a pure 
> > > Diameter universe, the design will be somewhat cleaner and nicer 
> > > (since you can use nice Diameter features).  The disadvantage is 
> > > that in non-pure-Diameter universe, the overall design 
> will be more 
> > > complex, and translation agents need to be updated.
> > 
> > The question is whether when writing a Diameter definitions 
> document 
> > using code values with equivalence in the RADIUS code space and 
> > avoiding things like grouped AVPs are major constraints. I 
> would say 
> > no, it's only nice to have when opportunities raise. After all we 
> > invented Diameter in order to create a more powerful and versatile 
> > protocol, not to continue to live within the constrains of RADIUS,
> > 
> > > 
> > > Do I understand you correctly that you believe that for this 
> > > particular use case, the advantages outweigh the 
> disadvantages? Is 
> > > this because of the design "cleanness", or because you believe 
> > > deployments will not need to translate between RADIUS and 
> Diameter 
> > > in this case?
> > > 
> > > (Note that if we would be defining a new Diameter 
> application, the 
> > > translation agent would always need new code
> > > -- so the question would be slightly different.)
> > > 
> > > Jouni: could you send some pointers to the AAA-doctors discussion?
> > > (I took a quick look at their mailing list archive, but couldn't 
> > > find anything about this document.)
> > 
> > Unless I am mistaken, these discussions referred here happened with 
> > the participation of some of the AAA Doctors in the DIME 
> meeting and 
> > in the AAA-Doctors lunch, but were not minuted in details.
> >  
> > > 
> > > Best regards,
> > > Pasi
> > > 
> > > > -----Original Message-----
> > > > From: ext [email-masked]
> > > > [mailto:[email-masked]]
> > > > Sent: 25 November, 2008 11:12
> > > > To: [email-masked]; [email-masked]
> > > > Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki);
> > > Tschofenig
> > > > Hannes (NSN - FI/Espoo); [email-masked]; 
> > > > [email-masked]; [email-masked]; 
> > > > [email-masked]; [email-masked]
> > > > Subject: RE: New version of draft-ietf-dime-mip6-integrated
> > > > 
> > > > Hi all,
> > > > 
> > > >  I just wanted to mention that I fully agree with Jouni on this.
> > > > 
> > > >  I don't understand this new requirement on using only
> > RADIUS space
> > > > attributes for Diameter Application and on not employ
> > grouped AVPs.
> > > > I see that as a limitation for Diameter development. 
> > > > 
> > > >  In my opinion, these new requirements should be discussed
> > > in related
> > > > IETF WGs before being applied. I don't really understand
> > > why they are
> > > > discussed here and have not been discussed for Diameter 
> NASREQ or 
> > > > Diameter EAP.
> > > > 
> > > >  Moreover, I don't see the need for interoperability
> > between Mobile
> > > > IPv4 and Mobile IPv6. I may miss something on this.
> > > > 
> > > >  Best Regards,
> > > > 
> > > >  Julien
> > > > 
> > > > > -----Message d'origine-----
> > > > > De : [email-masked] 
> > > > > [mailto:[email-masked]]
> > > > > Envoyé : lundi 24 novembre 2008 20:35 À : 
> > > [email-masked] Cc : 
> > > > > [email-masked]; [email-masked]; BOURNELLE Julien 
> > > > > RD-CORE-ISS; [email-masked]; 
> [email-masked]; 
> > > > > [email-masked]; [email-masked]; 
> > > > > [email-masked] Objet : RE: New version of 
> > > > > draft-ietf-dime-mip6-integrated
> > > > > 
> > > > > Hi Jari,
> > > > > 
> > > > > > I read further, and would like to recommend that we
> > change the
> > > > > > document to
> > > > > > 
> > > > > > - employ only RADIUS space attributes
> > > > > > - not employ grouped AVPs
> > > > > > - not reuse RFC4004 attribute, which has been defined for
> > > > MIP4 info
> > > > > 
> > > > > Honestly, I won't agree with this change. As far as I
> > know, there
> > > > > was discussion of this in Dime WG meeting and the 
> overwhelming 
> > > > > consensus was not to go for RADIUS path.. Same comment
> > came from
> > > > > AAA-doctors as well. (Hannes can correct me here if I got
> > > it wrong). 
> > > > > What I stated earlier about doing Diameter still has
> > not changed.
> > > > > 
> > > > > > As the document currently stands, it will create
> > > interoperability
> > > > > > problems between Diameter and RADIUS, and between
> > > Mobile IPv4 and
> > > > > > IPv6.
> > > > > 
> > > > > I don't follow the MIP4 vs IPv6 part.
> > > > > 
> > > > > > The design will not be entirely clean even if we do the
> > > > > above, but it
> > > > > > does remove the most significant problems. In particular,
> > > > > it will make
> > > > > > it possible for a Diameter-RADIUS proxy to send this
> > > information
> > > > > > without any extra code.
> > > > > >
> > > > > > I believe the above changes are fairly easily doable in
> > > > the current
> > > > > > document.
> > > > > > 
> > > > > > Jari
> > > > > 
> > > > > Cheers,
> > > > > 	Jouni
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 26 Nov 2008 11:36:31 +0100

(copying also AAA-Doctors)

The required changes are pretty obvious. However, the issue needs
discussion because the core of the disagreement seems to be about the
degree of compatibility between RADIUS and Diameter in a Diameter
solution. This has broader implications.

Dan

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, November 26, 2008 12:23 PM
> To: [email-masked]
> Cc: Romascanu, Dan (Dan); 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> Subject: Re: New version of draft-ietf-dime-mip6-integrated
> 
> Pasi, all,
> 
> answering my 
> > main concern: specifying two similar solutions (and translation 
> > between them) means more complexity and more work. Why is this 
> > complexity and work needed?
> >   
> 
> This is my question as well.
> 
> > So far, it seems the only plausible reason for publishing this 
> > document is that 3GPP needs it soon
>  From my perspective the changes needed are editorially 
> relatively small. We are using far more time on this thread 
> than we'd need for an actual change in the document.
> 
> Jari
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2008 08:33:08 -0800

As I understand it, the differences between the RADIUS and Diameter documents go back to 
RFC 2977, which specified the AAA requirements for Mobile IP.  These requirements were
then rolled up into RFC 2989, which included several requirements which could not be 
satisfied by RADIUS, including a number which were unique to Mobile IP (see Section 2.5). 

Given that the Diameter document relies on unique features of Diameter (such as grouping),
it seems unlikely that these two documents can be completely reconciled.  Also, making the
Diameter document dependent on its RADIUS equivalent could impose protracted delays,
particularly given the RADIUS protocol problems that have been pointed out (e.g. 
changes in the type of existing attributes, inappropriate use of "Authorization Only", etc.) .

So this may be a case where the end result does not appear very satisfactory, but a 
fully satisfactory solution is not possible.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Nov 2008 11:33:19 -0800

> > work. Why is this complexity and work needed?

Which complexity and work would that be?  Translation between RADIUS and
Diameter cannot be avoided, if that's the problem you see.

> > a RADIUS+Diameter solution (not a RADIUS-only solution!), 

Any work using RADIUS Attributes from the standard typespace may be
trivially claimed to be a "RADIUS+Diameter solution" if no translation other
than that specified in RFC 4005 & RFC 3588 is performed.  In fact, however,
draft-ietf-mip6-radius-06.txt (if that is what you are referring to)
requires further translation: "MIP6-HA and HOA-IPv6 must be translated
between their RADIUS representation of String to a Diameter Address format
which requires that the AddressType field be set to 2 for IP6 (IP version
6)".  Furthermore, a pretty good case could be made that the draft in
question is not only not a "RADIUS+Diameter solution", but not even a
"RADIUS-only solution" due to the novel semantics it assigns to the
Access-Accept message.
 
> > and

It didn't get to the IESG first because it's not ready for prime time.  I do
find it interesting that a Security Area Director is ready to approve a
document with such weak security properties, however.

> > two different solutions are needed in Diameter).

Very interesting.  I guess that the fact that RADIUS and Diameter are
different protocols is a pretty weak argument, then; it's a much better idea
to force otherwise Diameter-only systems to install RADIUS support.  

...

---

From: <[email-masked]>
Date: Thu, 27 Nov 2008 14:26:00 +0200

Bernard Aboba wrote:

> As I understand it, the differences between the RADIUS and Diameter
> documents go back to RFC 2977, which specified the AAA requirements
> for Mobile IP.  These requirements were then rolled up into RFC
> 2989, which included several requirements which could not be
> Given that the Diameter document relies on unique features of
> Diameter (such as grouping), it seems unlikely that these two
> documents can be completely reconciled.  Also, making the Diameter
> document dependent on its RADIUS equivalent could impose protracted
> delays, particularly given the RADIUS protocol problems that have
> been pointed out (e.g.  changes in the type of existing attributes,
> inappropriate use of "Authorization Only", etc.) .

Note that when it comes to the "integrated scenario" (NAS-AAA), the 
MEXT WG document does *not* describe a RADIUS-only solution; it describes 
a solution that works both in RADIUS and Diameter. 

The problems about "authorization only" etc. apply to the "split scenario" 
(HA-AAA), which is quite different (and will indeed require slightly
different approach in Diameter).

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Nov 2008 15:00:38 +0200

What he said.

jari

[email-masked] wrote:
> Glen Zorn wrote:
>> Which complexity and work would that be?  Translation between RADIUS
>> and Diameter cannot be avoided, if that's the problem you see.
>>     
>
> We're clearly not on the same page here. Let me try to explain why I
> believe why this is unnecessary complexity and work:
>
> Consider another draft that has been discussed in RADEXT:
> draft-aboba-radext-wlan. It would be possible to write a new
> Internet-Draft that would define Diameter AVPs (in >255 range,
> possibly using grouped AVPs and other Diameter-only features) for
> exactly the same purpose.
>
> I am claiming this would be a very bad idea, because it would mean
> more complexity and more work, and with little benefits.
>
> When you're defining attributes for use in existing messages (no new
> Diameter application or anything), IMHO it should be done in the 0-255
> range, even if that means Diameter features like grouping need to be
> avoided.
>
> If I understand your position right, you're saying it would be OK to
> have two different numbers for e.g. the Allowed-Called-Station-Id
> attribute? 
>
>   
>> trivially claimed to be a "RADIUS+Diameter solution" if no
>> translation other than that specified in RFC 4005 & RFC 3588 is
>> performed.
>>     
>
> Yes. And I think such solutions often make sense.
>
>   
>> In fact, however, draft-ietf-mip6-radius-06.txt (if that is what you
>> are referring to) requires further translation: "MIP6-HA and
>> HOA-IPv6 must be translated between their RADIUS representation of
>> String to a Diameter Address format which requires that the
>> AddressType field be set to 2 for IP6 (IP version 6)".
>>     
>
> That's a bad design choice in mip6-radius-06 that could be easily
> fixed. If it used the same approach as was used for e.g.
> Framed-IP-Address, no translation (beyond copying) would be needed.
>
>   
>> Furthermore, a pretty good case could be made that the draft in
>> question is not only not a "RADIUS+Diameter solution", but not even
>> a "RADIUS-only solution" due to the novel semantics it assigns to
>> the Access-Accept message.
>>     
>
> The "novel semantics" probably refer to the "split scenario" (which
> is indeed more complex, and could be in a separate document).
>
>   
>>> and if they had sent their document to IESG first, we probably
>> It didn't get to the IESG first because it's not ready for prime
>> time.  I do find it interesting that a Security Area Director is
>> ready to approve a document with such weak security properties,
>> however.
>>     
>
> The "weak security properties" refer to the "split scenario".  The
> "integrated scenario" are ready for prime time, and are delayed only
> by editorial decision to keep them in the same text file.
>
> Best regards,
> Pasi
>
>
>

---

From: <[email-masked]>
Date: Thu, 27 Nov 2008 14:55:20 +0200

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 27 Nov 2008 14:17:28 +0100

Dear all,

 Thanks for your clarifications, I think I better understand
your concern now. You are true
that we are not defining a new Diameter application here and
that finally we just add AVPs to Diameter EAP/NASREQ. In particular
the MIP6-Agent-Info AVP of Type Grouped. From my point of view,
this AVP makes sense from a Diameter point of view and I'm not
really confortable to split it to ease Diameter/RADIUS translation.

 First, I'm not sure that the most common deployment case will have
to translate between RADIUS-MIP6 and Diameter MIP6 integrated. As
you know, 3GPP does not use RADIUS MIP6. It would be interesting
to see if someone has a valid scenario.

 Second, Diameter NASREQ/EAP already have some Grouped AVPs. So
the translation agent already have to cope with this. 

 SO, I think that your comment is really valid and that we could
probably add a recommandation somewhere in RFC3588Bis but I'm not
sure that this could be a MUST.

 Regards,

 Julien

> De : Jari Arkko [mailto:[email-masked]] 
> Envoyé : jeudi 27 novembre 2008 14:01
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; BOURNELLE 
> Julien RD-CORE-ISS; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Objet : Re: [AAA-DOCTORS] New version of 
> situation came 
> >>> to happen: somewhere down the line, two WGs ended up 
> taking on the 
> >>> work, and one of them (DIME) made decisions that made 
> sense locally 
> >>> (when considering only Diameter aspects), and their draft came to 
> >>> IESG first.
> >>> Interestingly enough, the other WG (MEXT) has been working on a 
> >>> RADIUS+Diameter solution (not a RADIUS-only solution!),
> >>>       
> > The "novel semantics" probably refer to the "split 
> scenario" (which is 
> > indeed more complex, and could be in a separate document).
> >
> >   
> >>> and if they had sent their document to IESG first, we 
> probably would 
> >>> not even consider publishing draft-ietf-dime-mip6-integrated.
> >>>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 27 Nov 2008 11:54:44 -0800

Pasi Eronen said:

"Consider another draft that has been discussed in RADEXT:

avoided."

While the issue that you've raised is a valid one, I would suggest that
considerably more work needs to be done by the DIME and RADEXT WGs in order
to address some of the impediments and determine how and when this
principle can be applied:

a. Given the remaining RADIUS attribute space, we do not presently 
have enough remaining attributes to make allocation of Diameter
AVPs in the 0-255 range the default.

b. Currently the Diameter/RADIUS gateway (RFC 4005) has no means
for supporting the translation of RADIUS Extended Attributes to
Diameter.  This is because Diameter currently does not have the
ability to handle VSAs that are not in the RFC 2865 recommended
format (which the RADIUS extended attributes are not).  
Fixing this seems important since it would not only provide
many more attributes, but it would also enable limited grouping
support in RADIUS.  However, this work (RFC4005bis) is not
currently chartered.  Dave Mitton described this issue several
years ago in this document:
http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt

c. Issues in the interpretation of the mandatory bit, application
ID allocations, etc. need to be ironed out within RFC 3588bis. 

d. The Diameter Design Guidelines document would need
to provide guidance about when this strategy could be used. 
There are probably quite a few situations in which, RADIUS
attribute availability aside, allocation of RADIUS attributes
would neither be possible nor desirable.  This includes situations
where Diameter AVP types are used that are not available in
RADIUS;  where the application being extended makes heavy use
of Diameter-specific features;  where it is undesirable for
Diameter AVPs to conform to the RADIUS Design guidelines. 

In short, if the IESG believes that this issue is important,
then it should charter the work needed to address the problem.
The items above cannot be resolved by filing a DISCUSS; they
need to handled within the DIME and RADEXT WGs.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Nov 2008 23:05:08 +0200

I agree that these are issues, but:

Isn't point a moot in this case, given that both RADIUS and Diameter 
specifications are already being done for this? I.e., no matter what we 
decide, RADIUS attribute numbers are going to be burned.

Similarly, point b is an important issue, but applies only to 
specifications that would actually use the extended numbers. I was not 
aware of their use in this case.

Finally, point c about application identifiers does not appear to be 
relevant for extensions that involve only attributes and AVPs.

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 27 Nov 2008 13:59:10 -0800

This issue has been raised in two cases that I'm aware of, the other being the Diameter QoS
application.  
 
While it would seem to make sense to rationalize the RADIUS and Diameter MIPv6 documents
to some extent, I'm not clear that this would imply allocating *all* of the attributes in both
documents within the 0-255 space.   If this policy were carried out for all pending AAA
documents, it would be likely to result in exhaustion of the RADIUS attribute
space within the next 12 months. This would serve no useful purpose. 
 
To address exhaustion issues, the RADIUS Design Guidelines document recommends that the 
RADIUS VSA space be used as an alternative.   This could either involve allocation from within 
the Extended Attribute or SDO VSA spaces.  Therefore it is not necessarily true that standard 
RADIUS attributes would or should be burned by the MIPv6 RADIUS document, although that 
would be the case if the attributes were to be allocated in the 0-255 Diameter AVP range.   

> Date: Thu, 27 Nov 2008 23:05:08 +0200> From: [email-masked]> To: [email-masked]> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]> Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated> > I agree that these are issues, but:> > Isn't point a moot in this case, given that both RADIUS and Diameter > specifications are already being done for this? I.e., no matter what we > decide, RADIUS attribute numbers are going to be burned.> > Similarly, point b is an important issue, but applies only to > specifications that would actually use the extended numbers. I was not > aware of their use in this case.> > Finally, point c about application identifiers does not appear to be > relevant for extensions that involve only attributes and AVPs.> > Jari> > > Bernard Aboba wrote:> > Pasi Eronen said:> >> > "Consider another draft that has been discussed in RADEXT:> > draft-aboba-radext-wlan. It would be possible to write a new> > Internet-Draft that would define Diameter AVPs (in >255 range,> > possibly using grouped AVPs and other Diameter-only features) for> > exactly the same purpose.> >> > I am claiming this would be a very bad idea, because it would mean> > more complexity and more work, and with little benefits.> >> > When you're defining attributes for use in existing messages (no new> > Diameter application or anything), IMHO it should be done in the 0-255> > range, even if that means Diameter features like grouping need to be> > avoided."> >> > While the issue that you've raised is a valid one, I would suggest that> > considerably more work needs to be done by the DIME and RADEXT WGs in order> > to address some of the impediments and determine how and when this> > principle can be applied:> >> > a. Given the remaining RADIUS attribute space, we do not presently > > have enough remaining attributes to make allocation of Diameter> > AVPs in the 0-255 range the default.> >> > b. Currently the Diameter/RADIUS gateway (RFC 4005) has no means> > for supporting the translation of RADIUS Extended Attributes to> > Diameter. This is because Diameter currently does not have the> > ability to handle VSAs that are not in the RFC 2865 recommended> > format (which the RADIUS extended attributes are not). > > Fixing this seems important since it would not only provide> > many more attributes, but it would also enable limited grouping> > support in RADIUS. However, this work (RFC4005bis) is not> > currently chartered. Dave Mitton described this issue several> > years ago in this document:> > http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt> >> > c. Issues in the interpretation of the mandatory bit, application> > ID allocations, etc. need to be ironed out within RFC 3588bis. > >> > d. The Diameter Design Guidelines document would need> > to provide guidance about when this strategy could be used. > > There are probably quite a few situations in which, RADIUS> > attribute availability aside, allocation of RADIUS attributes> > would neither be possible nor desirable. This includes situations> > where Diameter AVP types are used that are not available in> > RADIUS; where the application being extended makes heavy use> > of Diameter-specific features; where it is undesirable for> > Diameter AVPs to conform to the RADIUS Design guidelines. > >> > In short, if the IESG believes that this issue is important,> > then it should charter the work needed to address the problem.> > The items above cannot be resolved by filing a DISCUSS; they> > need to handled within the DIME and RADEXT WGs. > >> >> >> > >