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.