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

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 19 May 2006 18:33:27 +0200

I agree with Jari also ;)

Year after year, we have the same discussion on this specific topic. And, as I said in previous discussions, as soon as the use of optional AVPs at the Diameter protocol level is  enough to fulfil service requirements, even if those optional AVPs are required at the service level - I said "service" and not "application", we should avoid resorting to systematically allocate a new application id while we reuse the same functionalities of an existing diameter application.

Lionel 

-----Message d'origine-----
De : Gerardo Giaretta [mailto:[email-masked]] 
Envoyé : vendredi 19 mai 2006 14:30
À : Jari Arkko
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Dime] Defining a new Application for mip6-split ?

I agree with Jari.

The most important thing we need for MIPv6 is that the AAA server understands that the authentication/authorization request is performed through Diameter EAP application but it is related to the mobility service and not to network access service. This is a clear requirement for an operator. But the presence of some optional AVPs may be sufficient to fulfill this requirement, imo.

--Gerardo

On 5/19/06, Jari Arkko <[email-masked]> wrote:
> I would prefer using the existing application, and adding optional 
> AVPs to carry information related to the IKEv2 (and possibly MIPv6) 
> service, and possibly some additional values for the NAS-Port-Type 
> field.
>
> One of the reasons why an existing application would be preferred is 
> that then a AAA server that does not care about the type of service 
> can be used without changes. Yet servers that do care can look at the 
> AVPs and make more detailed authorization decisions.
>
> RFC 3588 states that  "Creation of a new application should be viewed 
> as a last resort." and that "In order to justify allocation of a new 
> application identifier, Diameter applications MUST define one Command 
> Code, or add new mandatory AVPs to the ABNF." Note that mandatory AVPs 
> can be viewed in different ways, and that we should not be too strict 
> about them.
> For instance, Framed-Protocol is an optional AVP in RFCs 4005 and 
> 4072. Yet, you could argue that if you are doing PPP then you need to 
> use this attribute and set it to PPP. But that didn't make the 
> attribute mandatory.
> Do we have a similar situation for the IKEv2/MIPv6 attributes and 
> values? They are not necessary from the NASREQ/EAP perspective, but in 
> the specific context you need to use the attributes. In my mind, this 
> does not make the attributes mandatory from a Diameter application 
> point of view. If we start creating new applications for every 
> different situation, we'll have lots of applications and 
> interoperability problems. Its better to add new optional AVPs and 
> describe in text when they should be used. The only exception that I 
> see is security related AVPs that must be understood by the other side 
> or else the session should be terminated.
>
> See also
> http://www.arkko.com/publications/draft-arkko-radext-multi-service-dec
> isions-02.txt for related discussion about Service-Type, 
> NAS-Port-Type, and so on.
>
> --Jari
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>

_______________________________________________
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: "Avi Lior" <[email-masked]>
Date: Fri, 19 May 2006 15:02:15 -0400

Jari,

One more thing....(in addition to my previous reply to this email)

What you are suggesting really is  that I use the username as a sort of
application id.

Seems to me that that is backwards right?

We should use Application Ids to help route messages in diameter to
correct applications and correct application versions.

I will respond to other emails shortly.

Avi 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 2:39 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
> 
> Avi,
> 
> > If I have two EAP based application in my network, one that is 
> > handling pure EAP application, the other is extended to 
> handle the new 
> > behavior then I need a way to route the (same) command correctly.
> >
> Ah, but that is a new requirement. If you believe that you 
> need to route EAP authentication from a 802.11 AP differently 
> than from IKEv2/MIPv6, then you need one of these:
> 
> - Use different user/domain names for the users of
>   the different services.
> 
> - Point to different servers from the AP and SGW (but
>   this works less well if you have proxies and roaming).
> 
> - New application ID.
> 
> - Some weird form of Diameter and RADIUS source routing
>   based on what type of node sent the message.
> 
> However, it is far from clear to me why you would really need 
> to route the authentication differently *for the same user*. 
> Many authentication mechanisms can also have state, which 
> would imply that at the end they need to end up in the same 
> device anyhow. Can you expand on why you need to handle the 
> same users in different authentication servers?
> 
> --Jari
> 
>

---

From: <[email-masked]>
Date: Fri, 19 May 2006 21:00:41 +0200

Hi Avi, 

Some questions inline.

/Jouni

> See inline... 
> This is unacceptable.

Just for my clarification why would this (e.g. different
realms) be unacceptable?

> Good, cause this is unaccpetable.
>  
> > - New application ID.
> 
> I thought that that was what an application ID is for. No?
> 
> Good again.  This is unacceptable.
> 
> We want to use common user credentials.  That is a big plus.
>  
> See above.
> Can you please explain why we are not using Diamter Application Id the
> way they ought to be used?
> 
> > --Jari

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 22 May 2006 12:13:52 -0400

Hi Jari,

I wasn't talking about how these things can be deployed. They can all be
deployed on the same server.

Lots of emails, I am waiting for that summarization email that you are
so famous for.
 
Avi

> Sent: Sunday, May 21, 2006 6:06 AM
> To: Avi Lior
> Cc: [email-masked]; [email-masked]
> Avi Lior wrote:
> >In general, operators want to reduce the numbers of entities 
> they have 
> >to manage.  Having a different identity for each service is 
> the WRONG 
> >way to solve these problems.  We want to consolidate.
> >  
> >
> Indeed. But wouldn't consolidation also apply to deployment 
> of multiple authentication servers for the same credentials 
> albeit different service (SIP, 802.11, VPN, ...)? I would 
> assume that there are business and technical reasons to keep 
> the number of servers down...
> 
> --Jari
> 
>

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 22 May 2006 13:22:53 -0400

See below... 

> From: Santiago Zapata Hernandez [mailto:[email-masked]] 
> Sent: Monday, May 22, 2006 6:55 AM
> To: Julien Bournelle
> Cc: [email-masked]
> Hi, (sorry for sending it again, but I sent it in HTML mode by error. 
> Doing again in text mode).
> 
> Julien Bournelle escribió:
> > hi all,
> >
> > On Mon, May 22, 2006 at 11:03:58AM +0200, Santiago Zapata 
> Hernandez wrote:
> >   
> >> Hi all,
> >>
> >> After thinking in this issue, I'm agree about the identity 
> would be 
> >> different if we are in the scenario ASA <> MSA.
> >>     
> >
> >  I don't think we should assume that it is different 
> identity. In the  
> > Integrated scenario, we also use IKEv2-Diameter EAP and as 
> the HA is  
> > allocated by the AAA, we'll probably reuse the same 
> identity with same  
> > credentials. And if we do nothing, the AAA server may 
> "think" that it  
> > is performing Diameter EAP two times for network access.
> >
> >   
> I mean the same user (same credentials) but different user's 
> identifier
> (domain) because we are working (in split scenario) with 
> different domains. In integrated scenario the server could 
> detect that it is managing network access or mobility 
> authentication by having a look to user's identifier (another 
> sub-domain? or maybe by classifying the identifiers in the 
> server side?) My proposal is to use different users' 
> identifiers in order to distinguish (in the servers) between 
> the different EAP functionalities (Network access or Mobility).
> I don't see any problem by using different identifiers but 
> sharing the same credentials.
> My interest is in not creating a new application for each new 
> functionality to be deployed over Diameter-EAP.

Again using different identifiers may work in the split scenario but it also may not. And in general it is not a good idea to select applicatons based on identities.  It could be the situation that initially a given domain provided one service, but it could happen that in the future that domain would provide another service.  Now you will have the problem.  So lets design this properly.
 
> BR,
> Santiago
> >> In the other scenario (ASA = MSA), I think a new Application ID is 
> >> not the right solution, because we are managing the same kind of 
> >> functionality (EAP providing authentication/authorization).
> >>     
> >
> >  EAP is used for authentication. However, Authorization and 
> Accounting  
> > is different since in one case it is done for network 
> access while in  
> > the other case it's for mip6 service.
> >
> >  regards,
> >
> >  Julien
> >
> >   
> >> I propose to use virtual users for managing this scenarios.
> >>
> >> BR,
> >> Santiago
> >>
> >>
> >>
> >> Jari Arkko escribió:
> >>     
> >>> Santiago Zapata Hernandez wrote:
> >>>
> >>>  
> >>>       
> >>>> The idea of using different authentication servers is 
> coming from 
> >>>> the requirement of implementing a specific MIPv6 bootstrapping 
> >>>> split
> >>>> scenario: Access Service Authorizer (ASA) <> Mobility Service 
> >>>> Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02).
> >>>>    
> >>>>         
> >>> I have read the draft, but I do not see how it leads to the 
> >>> requirement that the same user identity needs to be routed in 
> >>> different ways for different applications. It seems that 
> the essence 
> >>> of the split scenario is that the access and mobility 
> services are 
> >>> independent, e.g., acquired from different providers with 
> different 
> >>> identities. Or from the same provider (as in when you are in your 
> >>> home network), but the services are provided in an independent 
> >>> fashion.
> >>>
> >>>  
> >>>       
> >>>> I think we should use the same application ID, but routing by:
> >>>> - having two different paths (Peers from different paths 
> would not 
> >>>> be interconnected).
> >>>> - some proxy should change route (is it RFC compliant?), 
> based in 
> >>>> the value of a (optional) AVP.
> >>>> - use different realms (changed by the HA, for example, 
> acting as a 
> >>>> proxy). I don't understand why it would not be possible 
> (HA could 
> >>>> change this realm, and boostrapping server could restore 
> it (if it 
> >>>> is required)).
> >>>>    
> >>>>         
> >>> Avi's new Application ID may be a better approach than these, 
> >>> because its directly supported by by Diameter as is. (If 
> different 
> >>> routing is
> >>> needed.)
> >>>
> >>> --Jari
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>

---

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

Juliena and others

See inline... 

> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Tuesday, May 23, 2006 9:24 AM
> To: [email-masked]
> Cc: [email-masked]
> Hi pasi,
> On Tue, May 23, 2006 at 03:00:07PM +0300, [email-masked] wrote:
> > 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...
> > 
> > > > 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...
> 
>  yep I know that. I was just saying that the App-Id field may 
> be used by  the Base Protocol to select the right Application 
> in a Diameter server.

Why "May"?  It is the primary method for doing that.  We should have a
very good reason why we shouldn't use the Application ID.

> > Best regards,
> > Pasi

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 25 May 2006 19:52:07 -0400

Pasi,

Thank you for the list...we need to make sure we capture it somewhere.

Please see inline... 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, May 25, 2006 5:33 AM
> To: Avi Lior
> Cc: [email-masked]
> Subject: RE: [Dime] Defining a new Application for mip6-split ?
> 
> 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.

We call this MANDATORY TO INCLUDE.

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

We call this MANDATORY TO UNDERSTAND.

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

So I don't think that there is a difference between Usage Guidelines and
new Application in the sense that both require code changes.  Therefore,
each new Usage Guideline (even for an existing application) requires
that the command be routed to the correct server.  (You can have
multiple Servers on the same machine)

Application ID is supposed to be that mechansim. Yes there is some text
that says that other things can be used for routing.

As some folks told me, the Application ID was suppose to capture
applications versions as well.  After all it is 32 bit number.

So to re-iterate...i need to make sure the commands reach the correct
implementation where they will be handled correctly.  This needs to be
done without requiring me to upgrade all my servers just because I want
to implment new functionality in some places.

Here is a thought: if we are worried about Application ID explosion
perhaps we can divide the Application ID into two parts:

Part one can be the Application ID; and
Part two can be a version or revision part for a given application.

As we create new "Usage Guidelines" for a given application can
increment the revision part.  As we create new Applications we assign
new Applications Ids.