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

From: "Avi Lior" <[email-masked]>
Date: Thu, 18 May 2006 16:40:25 -0400

Hi Yoshi,
 
Based on your repsonse we don't have to create a new application id.  So
how do I express that Service-Type (or NAS-Port-Type) is required?

So do I create a new ABNF for the DER and DEA commands in the
EAP-Application to show that these attributes are required now?

Under what context do I put this new ABNF? I don't have a new
Application ID nor do I have a new Command?

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, May 18, 2006 1:52 PM
> To: Avi Lior
> Cc: Julien Bournelle; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
> 
> On Thu, May 18, 2006 at 10:10:26AM -0400, Avi Lior wrote:
> > 
> > The problem is that neither Service-Type or Port-Type is 
> mandatory.  
> > 
> > O fcourse, if we need to make it mandatory we need to create an new 
> > Application.
> 
> If those AVPs are defined in an existing application, we 
> don't need to create a new application just because the AVPs 
> that appear in "optional" portion of the ABNF of the existing 
> application need to appear in "required" portion.
> 
> Yoshihiro Ohba
> 
> 
> > 
> > Also, if we add a new enumeration to either Port-Type or 
> Service-Type 
> > wouldn't we have to create a new Application.
> > 
> > BTW, this has been an issue even in RADIUS.  How does the AAA know 
> > this its authenticating for Mobile IP. Traditionaly it 
> would know that 
> > NAS-IP or NAS-Identifier is coming from an HA.  But that 
> doesn't scale at all.
> > 
> > I was trying to decide whether Service-Type or Port-Type is the 
> > correct way to go.  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....
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Julien Bournelle [mailto:[email-masked]]
> > > Sent: Thursday, May 18, 2006 7:06 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: [Dime] Defining a new Application for mip6-split ?
> > > 
> > > Hi Pasi,
> > > 
> > > On Thu, May 18, 2006 at 02:45:00PM +0300, 
> [email-masked] wrote:
> > > > Hi Julien,
> > > > 
> > > > There's nothing in RFC 4072 that would limit its use to,
> > > say, PPP or
> > > > 802.1X -- it works for IKEv2 as well (which can be considered a 
> > > > special kind of network access, where the "link" is a
> > > tunnel over IP).
> > > 
> > >  I'm not saying that we can't use IKEv2 with Diameter EAP. I had 
> > > just a  doubt due to the fact that in our case, we're 
> doing AAA for 
> > > the mip6  service and not for network access.
> > > (So I wanted to know opinion from  the group before starting to 
> > > write)
> > > 
> > > > The details (MIP6 or 802.11 WLAN or something else) can be
> > > sent to the
> > > > AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs.
> > > 
> > >  ok. I forgot the Service-Type AVP which seems to be what we need.
> > > 
> > >  thanks,
> > > 
> > >  Best regards,
> > > 
> > >  Julien
> > > 
> > > > 
> > > > Best regards,
> > > > Pasi
> > > > 
> > > > > -----Original Message-----
> > > > > From: ext Julien Bournelle 
> [mailto:[email-masked]]
> > > > > Sent: 18 May, 2006 11:42
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: [Dime] Defining a new Application for mip6-split ?
> > > > > 
> > > > > Hi all,
> > > > > 
> > > > >  we're in the process of updating/writing the document 
> > > > > describing use of  Diameter for the Mobile IPv6 split 
> scenario.
> > > > > 
> > > > >  In the split scenario, the Mobile Node (MN) uses IKEv2
> > > with the HA
> > > > > to  setup IPsec SAs. This exchange is also used by the HA to 
> > > > > authenticate  the MN using EAP. The HA may rely on a
> > > AAA/EAP server
> > > > > for this. So we  have the following scheme:
> > > > > 
> > > > >  MN <-- IKEv2-EAP --> HA <--------> AAA
> > > > > 
> > > > >  A priori Diameter EAP (RFC 4072) can be used between 
> HA and AAA. 
> > > > > 
> > > > >  The problem is that Diameter EAP is normally used 
> for Network 
> > > > > Access  authentication.
> > > > > 
> > > > >  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.
> > > > > 
> > > > >  For the above reason, it seems that we should define a
> > > new Diameter
> > > > > Application. However, in the same time, the messages 
> defined in 
> > > > > Diameter EAP could be reused.
> > > > > 
> > > > >  So I'd like to hear opinions concerning this issue.
> > > > > 
> > > > >  Thanks,
> > > > > 
> > > > > 
> > > > >  - Julien B.
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > DiME mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > > 
> > > 
> > > --
> > > julien.bournelle at int-evry.fr
> > > 
> > > _______________________________________________
> > > 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: Yoshihiro Ohba <[email-masked]>
Date: Thu, 18 May 2006 17:47:26 -0400

> how do I express that Service-Type (or NAS-Port-Type) is required?

My response was based on my reading of RFC 3588.  On the other hand,
RFC 3588 does not describe how to deal with the situation.

> Application ID nor do I have a new Command?

I think defining a revised ABNF to supersede the existing ABNF for an
existing message is NOT a good idea, since it affects existing
Diameter message parser implementations.  Rather than that, I'd
suggest keeping the current ABNF for DER and DEA as it is, and define
additional processing rules for the AVPs that are defined as optional
but required only by a specific service in a new standard track RFC.
I mean, the message parser does not reject the message even when those
AVPs are missing (because it is defined as optional in the ABNF), but
the implementation of the service-specific Diameter EAP application
must rejects the message if the AVPs are missing or do not contain
information required by the service.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 May 2006 11:17:52 +0300

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-decisions-02.txt
for related discussion about Service-Type, NAS-Port-Type,
and so on.

--Jari

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 19 May 2006 11:46:06 +0200

Hi,

> information required by the service.

 so you mean that, if we take mip6-split scenario, I could just add a
 sentence saying that the HA MUST/SHOULD add the NAS-Port-Type AVP (TBD
 for mip6-split) and that the AAA server MUST/SHOULD check if this AVP is
 present ?

 But what happens if the HA put the AVP and the AAA does not check it ?
 If the AAA server is not compliant with this, it may still continue to
 "think" that it's an authentication for network access. 

 Julien B.

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Fri, 19 May 2006 14:30:04 +0200

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