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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 4 Nov 2004 11:11:01 +0100

hi alper, 

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

i wasn't sure how and when the MIPv6-AAA-Key is computed as well. 

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

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

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 4 Nov 2004 21:52:00 +0900

Hannes,

> with <draft-ietf-mip6-auth-protocol-00.txt>. 

Can you explain this point more concretely ?

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

> <draft-giaretta-mip6-authorization-eap> draft.

Right, I agree with you.

> i also remember that julien published a draft with a similar idea some time

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.

Junghoon

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 4 Nov 2004 14:19:57 +0100

hi,

 just a little comment inline,

> BU may be piggybacked during the AAA auth& authorization phase if the MN's CoA is configured.

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.

-- 
[email-masked]

---

From: "Junghoon Jee" <[email-masked]>
Date: Mon, 8 Nov 2004 08:58:54 -0500

Hello, Julien.

> [email-masked]

Right. With my approach(draft-jee), a specific new Diameter Application is required to bootstrap
mobile nodes. In my opinion, there are pros. & cons. in using a new Diameter Application or not.
New Diameter Mobile IPv6 Bootstrapping Application(draft-jee) supports the HA assignment in the
Visited network. If you use a previous Diameter EAP or RADIUS EAP, you cannnot assign
a HA in the visited domain. Some of modification or adding are required.     
The HA assignment in the visited domain is a requirement item in the previous I-D(draft-le-aaa-mipv6-requirements-03.txt). 
This point is specified in the section 5.5 of that I-D.

i think we should consider the HA assignment in the visited domain not only in the home domain.

Junghoon