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

From: "Avi Lior" <[email-masked]>
Date: Fri, 19 May 2006 14:51:51 -0400

Yoshi,

Please see inline.... 

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, May 18, 2006 5:47 PM
> To: Avi Lior
> Cc: Yoshihiro Ohba; Julien Bournelle; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
> 
> 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.

Yes. I realize that.  Also, I do agree about your assement of 3588.  We
need to fix that.

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

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

I have a problem with your recommendations.  Consider the case here I
have to support both standard EAP Application and HA based eap
application using two different Implementation.  One can support the EAP
Application the other supports the HA based Application.  How do I route
the message?  The application id is the same and the command is the
same.

Futhermore, assume we use the NAS-Port-Type and set it to HA-MIPv4-Port.
The EAP Application will not understand that value (since its new)..

Seems to me that as a minimum we need a new Application id here.  Do you
agree?

> Yoshihiro Ohba
> 
> > 
> > 
> > 
> > > -----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: Fri, 19 May 2006 17:40:49 -0400

Hi Avi,

> the message?  The application id is the same and the command is the

Your scenario rather creates another issue as Jari already mentioned:
why do you need different authentication servers for the same user?

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.

> The EAP Application will not understand that value (since its new)..

Julien asked similar question.  If an AVP is defined as "M" bit set
and the server supports the AVP, but the server does not understand
the value, then an error should be returned.  If the server
understands the value, it must process the AVP based on the rule
defined for the value.

> Seems to me that as a minimum we need a new Application id here.  Do you

I think we need to explore a bit more...

Yoshihiro Ohba