Subject: RE: [Dime] Defining a new Application for mip6-split ?

From: "Avi Lior" <[email-masked]>
Date: Wed, 24 May 2006 12:51:05 -0400

Hi Pasi, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, May 23, 2006 8:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Defining a new Application for mip6-split ?
> 
> Julien Bournelle wrote:
> 
> > one could advocate that in the NASREQ case, we are still 
> dealing with 
> > network access. And Service-Type or NAS-Port-TYpe help the 
> AAA server 
> > to know what kind of access it is. Here it is not network access 
> > service, it is Mobile IPv6 service.
> 
> I don't think so; Service-Type and other authorization AVPs 
> help the AAA server to know what is the service being 
> authorized. Given that NASREQ and Diameter are already 
> suitable for a wide range of services (from dial-up PPP, fax, 
> IAPP, normal IKEv2-based remote access VPNs to administrative 
> web interfaces, and so on), I don't think there's anything so 
> special in Mobile IPv6 that would set it apart from the other 
> Service-Types...

I can say that for that for every other application that has been done
such as MIPv4 and Credit Control.  Lets just do them all under NASREQ.
This will solve lots of problems and in particular the Application ID.

Either we use the Application ID to route commands to where they will be
processed correctly -- or drop this concept entirely.  I am okay either
way.

A mandatory attribute (a must understand attribute) that has a new
enumeration is in my mind is like adding a new attribute that must be
understood.  There is no wigle room here.  The command carrying that
attribute must reach the implementation that knows how to interpret the
attribute.  This is  because an implmentation that does not understand
Service-Type = X must return an error.

It is obvious that the rules in 3588 are not sufficient to describe when
to use a new Application ID or not.  And we should not have to have a
debate on this topic.

BTW if we do what you say then in networks where I have NASREQ
performing Network Access and now I want to roll out MIPv6 I would have
to upgrade all my old NASREQ deployed applications.  This is wrong.  I
should be able to add a MIPv6 compliant diameter application without
having to force upgrading my NASREQ applications.

> > > At least the RADIUS proxy implementations I know of can 
> route based 
> > > on any attribute...
> > 
> > I think avi is talking about routing in the Diameter server between 
> > the different applications (SIP/EAP/CC...) not in the network.
> > But I may be  wrong :)
> 
> Exactly how a particular AAA server implementation is divided 
> into modules, components, libraries, DLLs, and so on is not 
> traditionally standardized in IETF...
> 
> Best regards,
> Pasi
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Thu, 25 May 2006 12:32:44 +0300

Avi Lior wrote:
> It is obvious that the rules in 3588 are not sufficient to describe
> when to use a new Application ID or not.  And we should not have to
> have a debate on this topic.

Here I fully agree with you: the rules in 3588 are not clear enough.

In particular, there are so many different meanings for "mandatory
AVP" that I can't probably even list them all. But let's try:

1) An AVP that is mandatory according to the command's ABNF;
   a command without this AVP always results in DIAMETER_MISSING_AVP.

2) An AVP not in category 1, but the specification of the AVP
   says the 'M' bit MUST be set if the AVP is included, and thus
   the command has to be rejected if the recipient does not 
   understand this AVP; failure results in DIAMETER_AVP_UNSUPPORTED.

3) An AVP not in category 1 or 2, but the _sender_ of the command 
   requires the command to be rejected if the recipient does not 
   understand this AVP (and thus sets the 'M' bit); failure results 
   in DIAMETER_AVP_UNSUPPORTED.

4) An AVP not in categories 1..3, but the _recipient_ of the command 
   requires this AVP to be present; failure results in e.g. 
   DIAMETER_AUTHORIZATION_REJECTED or some other error code. 
   For example, an AAA server could reject all requests that 
   don't have NAS-Port-Type AVP with value "802.11".

5) A "Diameter usage guidelines document" for a particular usage 
   situation can specify that an implementation compliant
   with that document (in addition to relevant Diameter RFCs)
   must include some AVP in some particular command, even though
   the command AVP does not require it. This implies that the  
   recipient of the command can safely use a policy meant in 
   category 4.

   For example, 3GPP spec 29.234 specifies that when Diameter EAP
   application is used between a 3GPP WLAN-IW compliant 802.11 WLAN
   and 3G operator's AAA server, the Diameter-EAP-Request command must
   include the Calling-Station-Id AVP, and it must contain the STA's
   MAC address. (In RFC4072 the Calling-Station-Id AVP is optional,
   and there's no requirement that it contains an IEEE 802 MAC
   address).

6) Similarly, an usage guidelines document can specify that
   an implementation compliant with that document must understand
   some AVP in a particular message, and process it in a particular way.

   For example, the IRAP "Public WLAN Roaming Interface Specification"
   (which is for RADIUS, but a document with similar content for
   Diameter could be written) specifies that the WLAN AP must support 
   the Idle-Timeout attribute, and use its contents in a particular way 
   (disconnect uses if no IP packets for this time; L2 packets don't 
   count; this AVP overrides local settings).

   RFC4005 specifies only that the Idle-Timeout AVP must have the 'M'
   bit set, but not what exactly is required by an implementation that
   "understands" the AVP (presumably, a compliant implementation could
   have a local policy that explicitly overrides the received value,
   could have a fixed non-configurable value for this timer, or could
   use a different interpretation of what "idle" means).

The challenge is that there is no clear-cut definition when any of
items 3...6 require a new application ID and when they don't.  The
examples I've given are more on the "no new application ID" side, but
once we're talking about more than one AVP, it seems we're left with a
subjective judgement whether we are still "close enough" to the old
application or not.

For example, defining how to use Diameter between in a "remote access"
type IKEv2 usage (between IKEv2 VPN gateway/home agent and AAA server) 
could be done either as "Diameter usage guidelines for IKEv2 remote 
access" or "Diameter remote-access-IKEv2-EAP Application" (BTW, I 
consider it remote access no matter whether it supports mobility 
or not, and whether mobility is supported using MOBIKE or MIPv6).

Best regards,
Pasi