Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs."NAS-Port-Type AVP/Service-Type": Summary

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Aug 2006 11:36:23 +0200

Hi Jouni,

~snip~

> For an operator being able to separate normal access and MIP service is
> a desirable feature. However, imho that also falls to general operator
> subscription policies. I.e. whether the operator wants to allow access
> with and without specific service (such as MIP) or not. In the
> integrated
> scenario the MN cannot assume that all access networks support
> bootstrapping
> anyway so the AAA server needs to be prepared for both cases.

So, what is the conclusion. Do we need to have mandatory attributes?

Ciao
Hannes

> Cheers,
> 	Jouni

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

---

From: <[email-masked]>
Date: Mon, 21 Aug 2006 11:03:54 +0200

Hannes, Julien, 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 20. elokuuta 2006 11:03
> To: Julien Bournelle
> Cc: [email-masked]
> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application 
> ID" vs."NAS-Port-Type AVP/Service-Type": Summary
> 
> Hi Julien,
> 
> 
> Julien Bournelle schrieb:
> > Hi hannes,
> > 
> >  thanks for this clarifying mail.
> > 
> > 
> > On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> >> Hi all,
> >>
> >> I went through the discussion again and noticed that we 
> haven't reached 
> >> a conclusion.
> >>
> >> Here is my impression:
> >>
> >> * RFC 3588 leaves a question regarding the extensibility open.
> >>   This needs to be captured in the revision of the base 
> specification.
> >>
> >> * The main issue seems to be
> >>
> >>   - Do we want to route 'Diameter EAP' message and 
> 'Diameter Mobile 
> >> IPv6 Bootstrapping' messages differently?
> > 
> >  I tend to think that it is safer to assume that some operators may
> >  desire that.
> > 
> >>     If we want to route them differently then we need to define 
> >> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> >>
> >>   - The AAA server differentiates ordinary network access 
> and MIPv6 
> >> bootstrapping functionality (with respect to authorization and 
> >> accounting). In order to do so it must understand the Service-Type 
> >> and/or NAS-Port-Type AVPs and the defined values.
> >>
> >>     Is this a problem?
> > 
> >  Not sure to understand this problem. For me, if we have 
> the App-Id we
> >  don't need Service-Type nor NAS-Port Type.
> >  IF we don't have the App-ID, yes we need to define new values.
> > 
> >  Maybe i missed the problem you raised.
> 
> This item is only relevant if you use the Service-Type / 
> NAS-Port Type 
> approach. The problem raised in the mailing list discussion was 
> regarding the type of authorization performed by the AAA 
> server. If the 
> AAA server understands the new values then everything is fine. If it 
> does not understand them then the authorization decision would be 
> treated as a normal network access scenario. Is this desirable?

Cheers,
	Jouni

> 
> 
> 
> Ciao
> Hannes
> 
> > 
> >  regards,
> > 
> >  Julien
> 
> Ciao
> Hannes
> 
> 
> > 
> >>   - There are problems with proxies and newly defined Diameter 
> >> Application IDs. Every
> >> proxy on the path needs new code to handle the new 
> application, while
> >> just adding an extra AVP or new Service-Type value does not hurt.
> >>
> >>     Is this an issue for us?
> >>
> >> Ciao
> >> Hannes
> >>
> >> PS: Here is copy-and-paste version of some discussion 
> snippets to allow 
> >> others to catch-up.
> >>
> >> Julien starts the discussion with a question about Application IDs.
> >>
> >> Pasi suggests to consider Service-Type and/or 
> NAS-Port-Type AVPs as 
> >> well.... the problem starts.
> >>
> >> Avi states that the problem is that neither Service-Type 
> or Port-Type is 
> >> mandatory.
> >> "
> >> Service Type seems to be the correct way but in RADIUS and
> >> Diameter service-type also can be authenticate-only or 
> authorize-only.
> >> So what if the HA wanted to authenticate-only or 
> authorize-only for the
> >> MIP service?  I would lose the ability to also indicate 
> that this is an
> >> HA.
> >>
> >> So Port-Type seems to be the way to go....
> >> "
> >>
> >> Jari jumps in:
> >> "
> >> 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.
> >> "
> >>
> >> Avi responds:
> >> "
> >> Mandatory does not mean required in the Command.  It means 
> that it must
> >> be understood by the receiver.  We need to clarify that.
> >> "
> >>
> >> Gerardo and Lionel agree with Jari.
> >>
> >>
> >>
> >> Avi writes:
> >> "
> >> 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.
> >> "
> >>
> >> Jari writes:
> >> "
> >> 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?
> >> "
> >>
> >> Avi to Jari:
> >>
> >> "
> >> BTW in the context of the original question raised, the 
> attribute(s)
> >> will not be optional. Here is the snippet:
> >>
> >>>>>>  In our case, the AAA server must perform AAA 
> functionality for the
> >>>>>> Mobile IPv6 service. The AAA server must know that it has to
> >>>>>> authorize the mip6 service and the accounting 
> (ASR/ASA) is also for
> >>>>>>  mip6 and not for network access.
> >> If the Diameter message comes from the HA then the HA MUST 
> include the
> >> NAS-Port-type attribute. So the command ABNF is being 
> changed. Also the
> >> behavior is being changed of the Server.  It MUST 
> recognize the (new)
> >> value of the NAS-Port-Type.
> >> "
> >>
> >>
> >> Yoshi says:
> >> "
> >> If what is important is service-specific routing (I am not 
> convinced
> >> with it yet), I'd suggest defining a new authorization-only
> >> application used only for carrying service-specific attributes
> >> (analogous to NASREQ usage in RFC 4072).  The downside is that it
> >> needs another message roundtrip than carrying the attributes in
> >> DER/DEA.
> >> "
> >>
> >>
> >> Julien wrote:
> >> "
> >>>> I don't think it's clean to require use of different
> >>>> users'identifiers in order to distinguish which services is
> >>>> provided. For me, it looks like a 'hack'.
> >> " and Pasi responded:
> >> "
> >> I fully agree -- but having separate user identifiers should not be
> >> necessary. If, for example, an operator wants to perform different
> >> authorizations for WiFi and WiMAX (e.g., some users can access only
> >> WiFi but not WiMAX), that's simple to do: just check Service-Type,
> >> NAS-Port-Type, and other relevant authorization AVPs.  There's
> >> absolutely no need to create a new Diameter application.
> >>
> >> If the AAA server is really strict about WiFi vs. WiMAX 
> separation, it
> >> can have a policy that requires the NAS-Port-Type AVP to be present
> >> (if the request does not contain it, access is denied). 
> Although this
> >> in some sense make NAS-Port-Type AVP "mandatory", it's not 
> "mandatory"
> >> in the sense that would require a new Diameter application.
> >>
> >> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think 
> there are
> >> any significant differences from Diameter point-of-view. 
> There's a box
> >> providing some service; authentication works with EAP; 
> authorization
> >> AVPs indicate what exactly is being authorized. What's missing is
> >> a document describing how the different authorization AVPs are
> >> used in this particular situation; sort of like RFC 3580 
> (IEEE 802.1X
> >> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> >>
> >> One important reason NOT to create new applications: proxies. Every
> >> proxy on the path needs new code to handle the new 
> application, while
> >> just adding an extra AVP or new Service-Type value doesn't.
> >> "
> >>
> >> John agrees with Pasi.
> >>
> >> Avi writes:
> >> "
> >> 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.
> >> "
> >>
> >>

---

From: <[email-masked]>
Date: Mon, 21 Aug 2006 16:10:39 +0300

Hi all,

>> regarding the type of authorization performed by the AAA server. If 
>> the AAA server understands the new values then everything is 
>fine. If 
>> it does not understand them then the authorization decision would be 
>For an operator being able to separate normal access and MIP 
>service is a desirable feature. However, imho that also falls 
>to general operator subscription policies. I.e. whether the 
>operator wants to allow access with and without specific 
>service (such as MIP) or not. In the integrated scenario the 
>MN cannot assume that all access networks support 
>bootstrapping anyway so the AAA server needs to be prepared 
>for both cases.

Out of curiousity, are there any networks doing this? I assume in
3GPP2 networks where MIPv4 is deployed, MIPv4 access isn't an extra,
billable service.

John