Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 4 Nov 2004 15:30:31 +0100

hi junghoon,  

> Hannes,
> 
> > 
> > when i read the draft i came accross the same questions. 
> > 
> > i like your pull (instead of the push approach). this might 
> also work 
> > nicely with <draft-ietf-mip6-auth-protocol-00.txt>.
> 
> Can you explain this point more concretely ?
you can bootstrap a number of security associations using the same approach.
hence, you might be able to bootstrap a security association which can be
used for protecting mip6 binding updates as described in
<draft-ietf-mip6-auth-protocol-00.txt> (instead of an ike/ipsec sa). 

i can draw a message flow if you want. 

> 
> > i wasn't sure how and when the MIPv6-AAA-Key is computed as well. 
> 
> I answered that question through my previous mail.
> For clarity,
> The AAA server and the MN maintains the key mapping table, 
> MIPv6-AAA-Key-Id vs. MIPv6-AAA-Key.
> When EAP authentication is succeeded, the MIPv6-AAA-Key and 
> its id. are stored to the key mapping table.
> The MIPv6-AAA-Key can be an AAA-Key or concatenation of the 
> AAA-Key' with AAA-Key'' if multiple session keys are derived 
> by the EAP authentication process. 
> The choice of which key to use to derive MIPv6 IKE PSK is 
> determined by the AAA home server. 
> The AAA home server notifies the MN which key to use by 
> sending the MIPv6-AAA-Key-Id.

i see. 

> 
> > a minor correction to your mail: the diameter application ships the 
> > parameters to the PAA (and not to the mobile node). this is 
> the reason 
> > why a pana protocol is required which carries the 
> parameters finally 
> > to the end host. this is probably the most important 
> difference with 
> > regard to the <draft-giaretta-mip6-authorization-eap> draft.
> 
> Right, I agree with you.
> 
> >   
> > ps: it might be good to reference an old draft 
> > <draft-le-aaa-diameter-mobileipv6-02.txt> which proposed 
> the same approach.
> > i also remember that julien published a draft with a 
> similar idea some 
> > time ago.
> 
> The previous draft-le-aaa-diameter-mobileipv6-03.txt is a 
> good reference for our work.
> In that draft, BU message is processed during the AAA auth. & 
> authorization phase.
> The BU message can be piggybacked to the AAA auth request 
> message or it can be produced on the AAA server. 
> In the draft-jee-mip6-bootstrap-aaa-00, BU is processed after 
> the AAA auth & authorization phase.
> This is because the BU MUST be protected by the IPsec SA 
> according to the RFC 3775.
> If the  draft-ietf-mip6-auth-protocol-00.txt is used, BU may 
> be piggybacked during the AAA auth& authorization phase if 
> the MN's CoA is configured.
> 
there are certainly differences but the main idea goes in the same
direction. 

ciao
hannes

> 
> Junghoon
> 
> 
> 
> > > -----Original Message-----
> > > From: Alper Yegin [mailto:[email-masked]]
> > > Sent: Dienstag, 02. November 2004 02:23
> > > To: [email-masked]
> > > Subject: [Mip6] Comments on jee-mip6-bootstrap-pana
> > > 
> > > Hello,
> > > 
> > > Here are some comments and questions on the 
> > > draft-jee-mip6-bootstrap-pana-00.txt.
> > > 
> > > - I see the new Diameter application has two functionalities. 
> > > Regarding the delivery of the bootstrapping information 
> to the MN, I 
> > > was wondering if we could get away with not defining new 
> commands, 
> > > but instead piggybacking on existing NAS application? The 
> > > bootstrapping information could be delivered to the NAS 
> as part of 
> > > the mobile's profile.
> > > 
> > > - The other functionality is the push of bootstrapping 
> information 
> > > from AAAh to HA. This is carried in serial with the (in 
> fact, in the 
> > > middle
> > > of) network access AAA. I think it could be done in parallel, or 
> > > even after the network access AAA. If you use a pull 
> model instead 
> > > of the push, this part gets aligned with the yegin-mip6-aaa-fwk.
> > > 
> > > - I didn't quite understand how the MN obtains/computes the 
> > > MIPv6-AAA-Key. It is only provided with the MIPv6-AAA-Key-Id, and 
> > > that's not sufficient to derive the key.
> > > 
> > > Thanks in advance.
> > > 
> > > Alper
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Mip6 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mip6
> > > 
> > 
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 4 Nov 2004 15:59:23 +0100

hi julien, 

> I think that one of the major issue with this approach 
> (defining a specific AAA application for Mobile IPv6) is that 
> all visited network MUST use this specific AAA application if 
> you want to bootstrapp Mobile IPv6. Thus, if  the visited 
> network uses Diameter-EAP or RADIUS-EAP, you can't bootstrapp 
> Mobile IPv6. This imply that all operators should deploy this 
> solution.
> 
> With our approach (draft-giaretta), the visited network does 
> not need to Mobile IPV6 aware.

thanks for pointing to this important issue. similarly,
draft-tschofenig-mip6-bootstrapping-pana does not require the visited
network to know anything about mobile ip.  

ciao
hannes
> 
> 
> --
> [email-masked]
>