RE: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03?

[Madjid Nakhjiri <mnakhjiri at huawei.com>]

Hi Julien,

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle at gmail.com] 
Sent: Friday, November 17, 2006 8:00 AM
To: Madjid Nakhjiri
Cc: Gerardo Giaretta; Gopal Dommety (gdommety); Kent Leung (kleung);
mip6 at ietf.org; dime at ietf.org
Subject: Re: [Dime] RE: [Mip6] Should we add the requirements that arise
from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03?

Hi madjid, all,

On 11/15/06, Madjid Nakhjiri <mnakhjiri at huawei.com> wrote:
> Hi Gerardo,
>
>
> If you remember, the first time people asked this question, I said we
should
> simply be careful about rubber stamping the Dime drafts as supporting
4285.
> Unless the HA-AAA goal doc includes specific requirements on supporting
> 4285, we should refrain from making the promise that Dime draft do too.
> If we design something based on a requirement that excludes support for
> 4285, then the solution has no obligation to support it either.

 can't we have requirements for 4285 in aaa-ha-goals and have separate
AAA solutions for IPsec and 4285 case ?

Madjid>>Absolutely, especially if the requirement for 4285 support is not
MUST, and from Raj that seems to be the case. However, the 4285 experts
should add a few words about what these requirements are. 

>
> I am going to reiterate all my points.
> 1) "AAA goal/requirement document" means requirements for both RADIUS and
> Diameter. Unless you want to change the name, we need to realize that this
> document can
> a) create requirements that RADIUS cannot meet and hence rule out RADIUS
for
> MIP6 support (some of the current goals related to key transport fit that
> category)

 what do you propose ?

Madjid>>I am proposing to the remove the goal that requires secure key
transport (I had a discussion on that with Gerarado already, I believe it
was called a general goal) and just leave the note in the security
consideration section. That way, RADIUS is not ruled out unintentionally.

> b) create requirement for all AAA functionality, i.e both requirements on
> AAA functionality within HA and on AAA protocol. This means if an HA works
> according to 4285, then the document needs to include requirement for
> supporting 4285 as well. Dime drafts can come and state whether they
fulfill
> all requirements, including 4285 requirements. We already have two dime
> drafts for two different designs.
>
> Currently, the document seemed to be treated as "requirement for Dime
> bootstrapping drafts". Is that the intention? The answer seems to be yes
> from your email. So the HA-AAA goals is not a generic requirement goal for
> MIP6. The current HA-AAA goals document should specifically state that it
is
> the requirements for Diameter EAP based solutions and not for 4285 to
clear
> all the issues above.

 this was not the intention.

Madjid>> seems to be the outcome:)

>
> Personally I think support for 4285 is a lot simpler than people think,
and
> might not require much more than some AVPs and look similar to 4004 for
MIP4
> support in case of CCOA, but I have not done a detail analysis. If that is
> true all 4285 needs in way of requirements is probably being allowed to
have
> some new AVPs (or possibly same as those used in MIP4).
>
> The problem of excluding these from HA-AAA goal is that you may need a new
> Diameter MIP6 App ID for 4285, if the AVPs are brand new?

 For the Diameter case, I think we may need another application to
support 4285. But i don't think that the problem of the mip6 WG. I
think we could have some requirements for 4285 in aaa-ha-goals and
then it's up to related AAA groups to deal with that.

Madjid>>Again, I feel that only AVPs are needed, but I am not sure. We
(people who want 4285) need to look closely and see whether these AVPs can
be supported by 4004 or by the future RFCs supporting IKEv2 solutions. If it
turns out we need mandatory AVPs that cannot be supported by these RFCs that
we need a new Diameter application. And yes, all this means the work is to
be done in Dime, if there is enough interest. 

Regards,

Madjid

 regards,

 Julien

>
> Hope THIS clarifies some more :)
>
> Regards,
>
> Madjid
>
> -----Original Message-----
> From: Gerardo Giaretta [mailto:gerardo.giaretta at gmail.com]
> Sent: Tuesday, November 14, 2006 3:31 PM
> To: Madjid Nakhjiri
> Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety);
> mip6 at ietf.org
> Subject: Re: [Mip6] Should we add the requirements that arise from RFC
> 4285inthe draft-ietf-mip6-aaa-ha-goals-03?
>
> Current work in DIME WG is based on rfc3775/3776 and on the IPsec
> bootstrapping solution. This has lead so far to a re-use of rfc4072
> for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR
> re-use for the session management.
>
> This means that in case rfc4285 is used, the Diameter application we
> are designing cannot be used. The session management and authorization
> part can be kept the same, but there would be a need to specify how
> the HA authenticates the BUs in case of dynamic keying (something
> similar to MIP4 approach).
>
> So the question is: should the AAA requirements doc (and consequently
> the DIME solution - but this is a question for DIME WG) list also that
> the HA-AAA communication may be able to bootstrap and authenticate
> rfc4285 security associations?
>
> I hope this clarifies.
>
> --Gerardo
>
> On 11/14/06, Madjid Nakhjiri <mnakhjiri at huawei.com> wrote:
> > Personally, I suspect that 4285 support simply needs a bunch of
> attributes.
> > I suggest people propose a couple of requirements related to 4285
support
> > and after that we could easily see if those can be added to the current
> set
> > of goals. Once we did that we can simply say the HA-AAAH support 4285.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Kent Leung (kleung) [mailto:kleung at cisco.com]
> > Sent: Tuesday, November 14, 2006 12:08 PM
> > To: Vijay Devarapalli; Gopal Dommety (gdommety)
> > Cc: mip6 at ietf.org
> > Subject: RE: [Mip6] Should we add the requirements that arise from RFC
> > 4285inthe draft-ietf-mip6-aaa-ha-goals-03?
> >
> >
> > My vote is YES.
> >
> > I assume this question is intended for HA-AAA interface support for RFC
> > 4285.  But it would be definitely nice to have standards-based AAA
> > attributes for bootstrapping in terms of completeness.
> >
> > Kent
> >
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:vijay.devarapalli at azairenet.com]
> > Sent: Tuesday, November 14, 2006 10:26 AM
> > To: Gopal Dommety (gdommety)
> > Cc: mip6 at ietf.org
> > Subject: Re: [Mip6] Should we add the requirements that arise from RFC
> > 4285in the draft-ietf-mip6-aaa-ha-goals-03?
> >
> > Gopal,
> >
> > lets step back a bit. what is the point of adding of 4285-specific
> > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic
> > 4285 operation where the HA-AAAH interface is used for MN
> > authentication? or does it include bootstrapping for 4285 too?
> >
> > will the requirements be added to
> > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in
> > one place with no binding to develop any solutions yet?
> >
> > other bootstrapping related questions, do we want to standardize
> > bootstrapping solutions for 4285 too? has the DIME WG agreed to
> > developing solutions for 4285-based MIP6 operation?
> >
> > Vijay
> >
> > Gopal Dommety (gdommety) wrote:
> > > Hello All,
> > >
> > >     Wanted to get the MIP6 Working groups preference on whether we
> > > should we add the requirements that arise from RFC 4285 in the
> > > draft-ietf-mip6-aaa-ha-goals-03
> > >
> > > We would like to hear the Working Groups opinion of the following
> > question:
> > >
> > > Should we add the requirements that arise from RFC 4285 in the
> > > draft-ietf-mip6-aaa-ha-goals-03?
> > >
> > >  Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there
> > > were
> > > 14 people for "yes" and 5 for "No".
> > >
> > > Cheers,
> > > Gopal and Raj
> > >
> > >
> > > ----------------------------------------------------------------------
> > > --
> > >
> > > _______________________________________________
> > > Mip6 mailing list
> > > Mip6 at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6 at ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6 at ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6 at ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
>
>
>
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>



_______________________________________________
Mip6 mailing list
Mip6 at ietf.org
https://www1.ietf.org/mailman/listinfo/mip6