Subject: [Mip6] Draft version of WG (from IETF62) meeting minutes

From: [email-masked]
Date: Tue, 5 Apr 2005 14:51:34 -0500

Minutes of MIP6 WG meeting
--------------------------

IETF62
Minneapolis, MN USA
Monday, March 7th 2005, 1930-2200

Chairs: Basavaraj Patil and Gopal Dometty

Minutes provided by: Suresh Krishnan

Agenda bashing
==============
Alper: wants to change the order of item 4 and 5 since framework needs to be 
covered before the solutions. Patil: Thinks the order is fine as 4 is very 
specific and will not be affected by the choice of the framework

Document  Status
================
Raj presenting

* Authentication protocol and MN Identity options drafts completed WGLC.
Security ADs have raised DISCUSSes 
IDs to be revised to clarify the motivation (why do we need these?)
3gpp2 has a critical dependency (already past deadlines)

* Preconfigured kbm draft is awaiting AD review and feedback

* RO security was reviewed by Elywn. Gabriel and Pekka to do the fixes

* Lots of comments about bootstrapping in the ML

* CN IPSEC draft needs WF review before going to WGLC

* IKEv2 ipsec needs reviews from ikev2 experts

Extension to Sockets API for Mobile IPv6
========================================
samita presenting

No major issues left, just editorial ones. New ID to be issued to fix WGLC  
issues working with cairs and ADs

AD evaluation comments pointed out that a clearer applicability statement 
is needed.and a switch is required on the socket apis to do source address 
selection. say CoA vs HoA

Needs implementation info to make progress maybe from HUT or WIDE). 
Implementors need to contact chairs/authors

Targeted for INFORMATIONAL

miv6 operation with ikev2
=========================
Vijay presenting

A whole bunch of requirements have been relaxed 
-> Support for Peer Authorization database, HoA configuration and EAP changed 
to MAY
-> Clarified that there is no need to use public key mechanism to authenticate 
HA if the chosen eap method already is mutual.

Open Issues:

SA for the BU is not created until the first CREATE_CHILD_SA (requires 3 rtt rather than 2rtt)

SPD entries and dynamically allocated HoA (SPD uses HoA)
3 options
  -> update SPD when the HoA changes
  -> reinstall policy entries when the HoA changes
  -> use a name in SPD and have name point to HoA

Jee wants a clarification about use of preshared keys as the method. Jari talks
about adding a reference to a draft Hannes and Pasi have written about not 
needing to use PK when EAP mutual authentication is used.He also mentions that
the draft has no home currently. Vijay will add the reference

mip6 AAA framework
==================
Alper presenting

The goal of the draft is to identify various frameworks where AAA is used 
for mip6 service and agree on one or more to standardize

Alper talks about 4 different frameworks and the characteristics of each

Framework 4
===========

Jee  is concerened about preconfiguring the HA address and thinks dynamic 
assignment of HA is very important. Alper will talk about it later.

Framework 2
===========

Vijay wants to know how DHCP server know which domain the MN belongs to?
Alper thinks that it is immaterial. Will use DHCP ID to correlate

Vidya wants to know what happens if the NAS and HA do not belong to the same 
domain as the NAS shares SA only with AAA-L(visited)? Greg thinks that this can
work transparently as there is a transitive trust rel between AAA-L and AAA-H
Raj has the same view as Greg. Gopal wants to add info about AAA-H and AAA-L.

Framework 3
===========

Jari wants to know how MN can know CoA and HA before initiating the procedure.
Greg thinks that there is no need to know as the AAA can do the BU
James wants to know how the AAA server can know where the prefix is.Greg thinks
that it will come from the NAS. Alper thinks that this framework is workeable 
but complex.

There are three requirements for a solution to fulfill. HA discovery, HoA 
discovery, and MN-HA key generation

Hannes and Alper talk about how these frameworks can be mix-n-matched 
to satisfy these requirements

Jari is concerened about the impact caused on network since the goal is to 
reuse the exisiting AAA relationship. Client software, DHCP and NAS need to be 
updated to implement these solution.

Summary:
Framework4: requires new aaa-mip6 application
Framework1: requires confirmation from ip conf sec bof
Framework2: needs new AAA attributes and PANA/DHCP options (*3gpp2 prefers this approach)
Framework3: Very complex and may not be justifiable

Alper wants direction from the WG to know which way to go. Gopal wants people 
to read the drafts and discuss on the ML

MIP6 Bootstrapping
james kempf presenting
=====================

Tries to address situations where loose trust between serving network access 
provider and Mobility Service Provider(MSP).e.g. enterprise networks, 
hotspots (As most of them use Credit Cards to authorize and not AAA), and for 
infrastructureless deployments very well)

John thinks that UAM (universal access method) is popular now but there are 
still backend AAA networks. He also thinks that 802.1x means more and more 
RADIUS as UAM does not work on small devices. James believes that CC based 
authentication is not going away and we need to support it. Jari thinks that
this method does not fit a mobility scenario since the CC based authentication
is used maily for wireless nodes in hostpots (usually immobile).

The basic idea is for the MN to ask for DNS SRV records a to get the HA address
Then IKEv2 is used to extablish MN-HA keying. Replay protection provided by 
Message identity code in DNS (RFC1035) and data integrity and origin auth 
provided by DNSSEC.

Alper wants to know how the HA will authenticate the MN. James thinks it will
be preprovisioned credentials like EAP username/password, preshared keyz etc.
Alper is concerned about sharing the HA address with external networks. 
James is not worried even though DNS has no authentication. He also clarifies
that this is meant to be used in the absence of RADIUS 
Raj is worried about DNS caching HA address. Thomas is also concerned. 

Hannes wants to decouple the two problems addressed in the draft 1) use IKEv2
for bootstrapping and 2) use DNS for discovery. He also suggests the 
possiblity of using multi hop PANA

James wants to use DNS TSIG (RFC2845) for protecting HA addresses. Thomas
thinks that nobody needs this. James thinks that if addresses are hard to get
it makes DoS harder. Thomas thinks that James is very unclear. He wants to know
what is really being protected. MN from bogus DNS replies or the DNS server 
from bogus DNS requests? James says both scenarios are protected againt.
Samita clarifies that DNSSEC is not deault and is optinal. 
Raj thinks this makes DOS attacks easier Thomas disagrees and states that he
likes this solution. This is nice and simple instead of the other complex 
solutions. He likens publishing the HA address to Wells Fargo advertising its
1-800 Number.

Goals for AAA-HA interface:
==========================
Gerardo presenting

The document describes design goals and requirements on interface between 
AAA and the HA. The purpose of the document is to allow matching  goals and 
frameworks. 

Raj wants to know if the draft should become a wg item in its current form?

James supports the document but wants to wait for the output of the 
Bootstrapping Design Team(BSDT) to proceed further. Vijay disagrees (he does 
not want to wait). Alper wants to choose framework before doing this as he
thinks that we cannot choose anything other than Framework with this. 

Gopal wants to know if the goals are related mainly to bootstrapping.
Gerardo says there are other goals like accounting. Patil and Gopal think that
it is a good idea to do this independently as there are other goals.

<Notes by Samita>
Location privacy 
================
Rajeev presenting 

koodli-mip6

Intro- specific scope for MIPv6
HOa - visible in all packets the MN uses it home or visited network
COA - visible at visited networks

Problem

Hoa COA could be profiled for activity
COA reveals roaming of a mobile node node when HoA is used

Profile:
 -can use privacy ext, to IPv6 (rfc3041)
- Can introduce additional MIP6 signalling ( when coa changes )

Profiling problem

Using 3041 introduces DNS and IPSec considerations

DNS , IPsec (rekeying for change in Hoa)

Roaming problem
 - reverse tunnel data packets (to solve COA problem)

Privacy Label Computation
Don't send HoA in the BU in the clear - use in label
Label should be computable without the knowledge of HoA

Mobopts will discuss this initially and similar other proposals.
It will be adopted by MIpv6 wg.
</Notes by Samita>

ipv4 traversal for mip6 protocols
=================================
Vijay presenting

This is useful if the MN lands on v4 only network.
The MN registers ipv4 address as CoA using a new mobility option
and can setup all types of tunnels. 6 over 4, ESP, UDP etc. use same 
mechanism for mip6 and nemo

Is there interest to do this in the wg?

Gopal thinks that we should discuss this for the next IETF. Greg thinks that 
it looks interesting. He thinks we should have a bar bof.(Not just looking to get to the bar, he says)

Raj wants to know if the wg should work on location privacy:
(CONSENSUS CALL)
yes? about 30 hands
no? no hands
(CONSENSUS IN FAVOR)

Next steps for WG
=================
Gopal presenting

-> Address AD/IESG comments on auth option

-> Bootstrapping solution
solution ID by next IETF. 
Close design team shortly after next IETF
last call and IESG by IETF64

-> mip6 transition issues
Gopal wants an ID to document transition issues
Vijay thinks it is a bad idea to write an all encompassing problem statement.
Raj and Gopal agree with Vijay. Thomas thinks that this problem has been 
around for long and v6 v4 transition issues should be documented by someone 
who ACTUALLY has a problem. Otherwise we will have a huge problem space
Gopal wants to define the problem space to be as narrow as possible. Thomas 
wants to agree on the scope of the problem before solving it

->work with mobopts to define and suggest privacy solutions
->propose revision to milestones

Rajeev wants to know the timeline for the mobopts work. Gopal mentions that
it should be done before the next IETF.

mobile firewalls
================
Qiu presenting

The idea is for the HA to control the activities of the MN in a visited
network.

Raj wants to know if this is applicable only with HMIP. Qiu says it is. He also
mentions that it is a scenario to illustrate out a general scheme.

PF_KEY between mipv6 and ipsec
==============================
Shinta presenting

MIP6 uses IPSEC to protect signalling messages. SA pairs need to be established
and tunnel mode SAs need to be updated when the CoA changes. MIP6 may not have
direct access to the SADB.
Defines a new PF_KEY message called MIGRATE
PF_KEY MIGRATE requires update of SAD and SPD
This has already been implemented

Vijay thinks this is very good work. Hannes has worked on a similar document 
which is more generic and wants a slot to talk about it

(OUT OF TIME)
Raj mentions a draft from James/Vijay about HA unavailable message which is 
sent when a HA is going down. It needs to be discussed in the ML
(END OF MEETING)

People referenced in minutes
============================
Basavaraj Patil (Raj)
Gabriel Montenegro (Gabriel)
Pekka Nikander (Pekka)
Elwyn Davies (Elwyn)
Vijay Devarapalli (Vijay)
Junghoon Jee (Jee)
Jari Arkko (Jari)
Hannes Tschofenning (Hannes)
Pasi Eronen (Pasi)
Alper Yegin (Alper)
Vidya Narayanan (Vidya)
Greg Daley (Greg)
James Kempf (James)
John Loughney (John)
Thomas Narten (Thomas)
Gerardo Giaretta (Gerardo)
Rajeev Koodli (Rajeev)
Gopal Dommetty (Gopal)
Qiu Ying (Qiu)
Shinta Sugimoto (Shinta)

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