[Mip6] Bootstrap DT Meeting minutes (IETF59)

[[e-mail]]

Bootstrapping Design Team Discussions: 
--------------------------------------
Date: March 7th, 2004 1130 AM to 1 PM (Seoul, Korea)

Meeting minutes courtesy of: Hannes Tschofenig (Thanks.)

Attendees: Jari Arkko, James Kempf, Alper Yegin, Kent Leung, Alpesh
Patel, Basavaraj Patil, Gopal Dometty, Hannes Tschofenig, Samita
Chakrabarti, Ryuji Wakikawa, Hiroyuki Ohnishi, Yoshihiro Ohba, Mayumi
Yanagiya 


Recently written draft: draft-kempf-mip6-bootstrap-00.txt

Discussions:
-------------

Should it be combined with AAA? 
It has to be generic enough? 

Scope of the problem: 
- you need to be able to setup the sa between mn<->ha
- you need to be configured with your home agent
- you need to be configured with your home address

Alper: assigning a home agent in the local domain (visited network)
Raj: outside the scope of the work 

Alternative security scheme is another work item which is somewhat similar. 

Definition of minimum scope: Define a mechanism to solve the problem
that exist today in the mobile ipv6 rfc: 
- we need to provide enough information to allow the setup of an IPsec
  SA setup in order to send a Binding Update between the MN and the CN   
- home address of the MN
- home agent address assigned to the MN

Do we need an IPsec SA? 
You need to establish spd entries.
You need things from different components (ipsec, mobile ip)

First define the bare minimum scope since it is a real deployment problem.

cdma2000: Dynamic HA assignment

There is some interest to get the HA in the visited network. This is a
more advanced scenario. 

How long is the information stored? 
You can re-bootstrap the procedure again. 

Providing a mechanism and how long the state is stored are separate issues. 

Currently we only define the one-time thing. 
Why don't we get the initial bootstrapping mechanism and then think
what is the difference to do it again? 

We just try to limit the scope. 

The state management issues need to be addressed later on. 

The bootstrapping procedure is fairly static. you have your nai@domain
and create the values.  

There is currently a way to discover a home agent using the
prefix. you at least need to know the prefix.  

The next issue is whether there is zero state. Creating everything
out of thin air is not possible.  

Would an NAI be sufficient? Is it needed to have some security? 
Agreement that some preliminary information needs to be in place in
order to bootstrap.

You need at least have some notion of a home network. 

First bootstrapping has to be in your home network. Disagreement with
this issue. A subscription with the home network needs to be
available.  

What is the security association? 
What is the relationship between AAA and bootstrapping? 

Jari Arkko: I have a claim: The only way we can reasonable do
     bootstrapping is through AAA.  
The second one is: Something like VPN security association. Those need
     AAA anyway.   

A shared secret is not a good idea. They typically don't have a sim card. 
They have something else. 

Jari Arkko: My claim is: The only reasonable approach where to use
     AAA.  

Can you use Kerberos? 

There have been attempts to use EAP in application. These failed. 

Regarding Kerberos, AAA or PK-based: How do we order the possible
	  trust relationships? 
The biggest set of trust relationships is within the AAA? 

We should make this very explicit. 

What is outside of scope? 

Do we want to solve the renumbering problem? it might fall out of the
solution. You might loose your current dynamically created state. When
you dynamically select a home agent and you do the renumbering then it
breaks for the current state.  

Is it feasible to prevent for the usage of renumbering or load balancing? 

This is what  I (James Kempf) want from the point of view from an ISP
provider.  

The current problem we currently have is that a human has to enter
some information (such as IPsec SAs). We don't need more reaons for
bootstrapping since it is in the charter.  

It should be compelling enough.

We will get the renumbering and load balancing anyway. 

We do not explicitly solve the problem of load balancing in the first
way. We don't want to mention it. Jari: We could mention it. Others:
We shouldn't.  

Why dynamic bootstrapping? Since we want to use some sort of
information (non topological information) and use it to create the
necessary information for mobile ip.  

What is with the aaa requirements document? 
If the bootstrapping is clear then we can look at the aaa requirements? 

I see a clear need to have an architecture document to show how to
setup it up. 

In pana we have a framework document. we could have something similar
with different scenarios.  
Most in the aaa document and how they set it up and not so much
requirements i have some different ideas using ieee 802.1x.

There are some requirmeents in the aaa document which we have to merge
in. we have to look at it - we can discuss it on the list.  

There may be additional requirements - we have to check. 
 
I am not sure about phase I scope. we can simplify if we have a NAI
and a security association with the AAA. that's a solution.  

These have to be standard mobile ip mechanisms not some which will be
in place in two years.  

What requirements document are you talking: we should go through the
mobile ip requirements documents and make sure that they are taken in
the account in Jari's document.  

Summary:
--------

Agreement on phases
problem scope:
- you need to be able to setup the sa between mn<->ha
- you need to be configured with your home agent
- you need to be configured with your home address

Existing trust relationship between mn and entity in the home network
(as specified in the base rfc) AAA assumed 
Look at the currently defined AAA requirements and bootstrapping
requirements we will work on a framework how bootstrapping works in
the presence of different scenarios.  
Exising security mechanisms from mobile ip (hopefully soon) rfc

Next steps: 
-----------

* find an editor (current document; alpesh): 
* find an editor (framework; alper)
* setup a separate mailing list. 
* we should have regular phone conferences (frequency is subject for
  discussion) 
* we should get this done by the end of April 04. 


_______________________________________________
Mip6 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip6