Re: [Dime] Defining a new Application for mip6-split ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dime] Defining a new Application for mip6-split ?
Hi,
On Thu, May 18, 2006 at 05:47:26PM -0400, Yoshihiro Ohba wrote:
> On Thu, May 18, 2006 at 04:40:25PM -0400, Avi Lior wrote:
> > 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?
>
> 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.
>
> >
> > 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?
>
> 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.
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.
>
> Yoshihiro Ohba
>
> >
> >
> >
> > > -----Original Message-----
> > > From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> > > Sent: Thursday, May 18, 2006 1:52 PM
> > > To: Avi Lior
> > > Cc: Julien Bournelle; Pasi.Eronen at nokia.com;
> > > hannes.tschofenig at gmx.net; dime at ietf.org
> > > 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:julien.bournelle at int-evry.fr]
> > > > > Sent: Thursday, May 18, 2006 7:06 AM
> > > > > To: Pasi.Eronen at nokia.com
> > > > > Cc: hannes.tschofenig at gmx.net; dime at ietf.org
> > > > > Subject: Re: [Dime] Defining a new Application for mip6-split ?
> > > > >
> > > > > Hi Pasi,
> > > > >
> > > > > On Thu, May 18, 2006 at 02:45:00PM +0300,
> > > Pasi.Eronen at nokia.com 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:julien.bournelle at int-evry.fr]
> > > > > > > Sent: 18 May, 2006 11:42
> > > > > > > To: dime at ietf.org
> > > > > > > Cc: hannes.tschofenig at gmx.net
> > > > > > > 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
> > > > > > > DiME at ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > > > >
> > > > >
> > > > > --
> > > > > julien.bournelle at int-evry.fr
> > > > >
> > > > > _______________________________________________
> > > > > DiME mailing list
> > > > > DiME at ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > >
> > > >
> > > > _______________________________________________
> > > > DiME mailing list
> > > > DiME at ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/dime
> > > >
> > > >
> > >
> >
> >
--
julien.bournelle at int-evry.fr
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.