[Mip6] IETF59: Minutes of MIP6 WG meeting

Basavaraj.Patil@nokia.com Fri, 02 April 2004 21:57 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04618 for <mip6-archive@odin.ietf.org>; Fri, 2 Apr 2004 16:57:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WfL-0001IT-TU for mip6-archive@odin.ietf.org; Fri, 02 Apr 2004 16:57:32 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LvVPI004974 for mip6-archive@odin.ietf.org; Fri, 2 Apr 2004 16:57:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WfL-0001I9-3V for mip6-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:57:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04524 for <mip6-web-archive@ietf.org>; Fri, 2 Apr 2004 16:57:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WfJ-0002Xk-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:57:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WbR-0001hs-00 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:53:30 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wa8-0001Ld-04 for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:09 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WYP-00085U-LY for mip6-web-archive@ietf.org; Fri, 02 Apr 2004 16:50:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WY7-0006FW-Ds; Fri, 02 Apr 2004 16:50:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VUT-0006ja-J5 for mip6@optimus.ietf.org; Fri, 02 Apr 2004 15:42:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27798 for <mip6@ietf.org>; Fri, 2 Apr 2004 15:42:11 -0500 (EST)
From: Basavaraj.Patil@nokia.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9VUS-0003hl-00 for mip6@ietf.org; Fri, 02 Apr 2004 15:42:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9VTW-0003af-00 for mip6@ietf.org; Fri, 02 Apr 2004 15:41:15 -0500
Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B9VSr-0003TK-00 for mip6@ietf.org; Fri, 02 Apr 2004 15:40:33 -0500
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32KeS303713 for <mip6@ietf.org>; Fri, 2 Apr 2004 23:40:28 +0300 (EET DST)
X-Scanned: Fri, 2 Apr 2004 23:40:12 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i32KeCWn012729 for <mip6@ietf.org>; Fri, 2 Apr 2004 23:40:12 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 009mcRib; Fri, 02 Apr 2004 23:40:12 EEST
Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i32Ke4s09315 for <mip6@ietf.org>; Fri, 2 Apr 2004 23:40:05 +0300 (EET DST)
Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Apr 2004 14:40:04 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 02 Apr 2004 14:40:03 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF44024DC028@daebe007.americas.nokia.com>
Thread-Topic: IETF59: Minutes of MIP6 WG meeting
Thread-Index: AcQY8qwiLauGrxc4TZiErYV8oumSqQ==
To: mip6@ietf.org
X-OriginalArrivalTime: 02 Apr 2004 20:40:04.0694 (UTC) FILETIME=[AD9A4F60:01C418F2]
Content-Transfer-Encoding: quoted-printable
Subject: [Mip6] IETF59: Minutes of MIP6 WG meeting
Sender: mip6-admin@ietf.org
Errors-To: mip6-admin@ietf.org
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Id: <mip6.ietf.org>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59
----------------------------------------------------------

Meeting notes courtesy of: Behcet Sarikaya and Glenn Keeni 
(Thank you). 

Monday, March 1 at 1300-1500
CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com>
        Gopal Dommety <gdommety@cisco.com>


1. Agenda, Bluesheets, Note takers
**********************************

- Some reshuffling of the agenda posted for the WG meeting earlier
  based on prioritization of work items.
- Added Charles Perkins' I-D draft-perkins-mip6-precfgKbm-00.txt to
  the agenda

2. WG Docs status update
************************
Basavaraj Patil

- Base Mobile IPv6 specification moving forward after having been
  stuck with IANA for a long time. Thanks to Jari Arkko for his
  efforts to get the IANA issue resolved. The I-D is headed now to the
  RFC editors queue.

- Revision 01 of the MIB document for MIP6 completed. Intent is to go
  to WG last call mid-April after one more revision. There is also a
  demo of the current MIB implementation by Glenn Keeni for anyone who
  would like to see it.

- The API I-D has received some comments on the list and also
  discussed at Connectathon. Will go to WG LC with the next revision. 

- MIPv6 test suites are at the URL shown in the slides

Gabriel: Has there been a WG LC on Pekka Nikander's I-D
	 <draft-nikander-mobileip-v6-ro-sec-02>?
Raj: Do not remember. But will check and follow up. The intent is to
	 publish this as an informational I-D.

3. Bootstrapping Problem
************************
Presenter: James Kempf <draft-kempf-mip6-bootstrap-00.txt >

- What is dymanic bootstraping? Two things: Dynamically allocating HA
  and Home network prefix discovery, and dynamically setting up an
  IPsec SA between MN and HA.  
  Benefits. Enables wider address assignment choices, Better
  configuration and, Load balancing.

Hesham: Dynamic HA discovery does load balancing, not necessarily
	dynamic HA assignment using AAA.  
James: Agree. AAA based approach supports new business models, allows
	nonsubscriber based access.  
Raj: Bootstrapping should be independent of AAA infrastructure. 
Jari: But we do need something for bootstrapping.
James: One alternative is AAA.
Charlie: Why not use DHCP like mechanism that we have here at the
	IETF-59 venue. Why require AAA? 
Hesham: Should not mandate AAA.
James: Current spec is based on manual keying or IKEv1 SA establishment. 

Francis: Disagreement with statement on statically assigned addresses
	in the slides. But ofcourse it just makes life easier.
	Mobile node does not get the information if the device is
	switched off. [ E.g. renumbering information]. Old info needs
	to be maintained. 
Hesham: The same is applicable in the case MN is un-reachable.
James: Benefits include reduced RTT and others.
       Current support for pushing prefix changes to dormant MNs has
	drawbacks. 
TJ: This problem has been discussed. Renumbering should be kept for
	sometime, dormant mobile has to bootstrap after it wakes up. 
Raj: Bootstrapping not a solution for the renumbering problem.
James: Prefix problem needs to be solved.
James: HA discovery uses ICMP and some ISPs disable ICMP.
Four bootstrapping scenarios. Out of four 2,3 and 4 are of interest.
Conclusion. Dynamic bootstrapping is useful. Current IPsec SA
	mechanism does not allow dynamic bootstrapping.
Greg: Option 2, 3, 4 is of primary scope
James: Disagrees
Greg: Which security assocs we will we use? What are the scenarios being
       considered for bootstrapping? 
Raj: There is a design team that is working on the bootstrapping
	problem. Scenarios and scope will be further clarified
	therein. 

4. HA reliability problem statement
***********************************
Presenter: Ryuji Wakikawa <draft-jfaizan-mipv6-ha-reliability-01.txt>

- HA failure. Home link failure. Failure detection, how an MN detects
  failure. Current base spec is not clear. Service
  interruption. Recovery? Who initiates recovery. IPsec SA
  assoc. establishment. Correct ordering, if HA changes, new HA does
  not know the order.  
- HA reliability is in current milestones, we need a problem
  statement. 

Deng Hui: Round robin load balancing can be used, i.e. redundancy is
     built into the HA machine. Also reliability can be accomplished
     by having a multi-blade server type of machine as the HA.
Gopal. Reliability solution should be built into the
     protocol. Hardware solutions are another approach to reliability.
Raj. Reliability is a WG charter item. Once we have consensus on the
     problem statement and scope we will move to solutions. 
     The problem statement I-D will be made a WG item after obtaining
     consensus on the WG ML. 


5. Dual stack Mobile IPv6
*************************
Presenter: Hesham Soliman <draft-soliman-v4v6-mipv4-00.txt> 

- Problem has been discussed in I-D: draft-tsirtsis-dsmip-problem-02.txt
  and the discussion today is one possible solution
- Problem: MIPv4 and mipv6, IPv4 and IPv6 coexist. If MN uses MIP on
  a dual stack machine and moves. MN needs to have both. Optimisation
  overhead. When both mipv4/v6 are used handover signaling, RO signaling
  needs optimization. Fast handover/LMM signaling. 
- Proposed solution. Allow each protocol to manage mobility, mipv4 to
  handle both v4/v6 HoAs to bind to an IPv4 CoA. 
  Draft is about mipv6 as migration tool. Use tunneling to carry ipv4
  and ipv6 traffic over the same mipv6 tunnel. Extensions needed to do
  this. The details are in the draft. One binding update that binds both
  v4/v6 CoA. Also IPsec SAs.  

James: Have you implemented? 
Hesham: no.
James. It sounds complicated. IPv6 stack deals with v4
       addresses. 
Hesham: Not really.
Pascal: What happens if there are NATs? 
Hesham: We do not deal with NAT traversal.
Greg: Are we talking of static or dynamic allocations, Dynamic
      allocation of MIpv4 and static allocations for MIPv6 ? 
Hesham: Bind the HoAV(4 or,6) to my CoAV(6 or V4). (Dual is not MIPv6
	or MIPv4 it is IPv4 or IPv6) 
XYZ: Mipv6 node makes 6to4 address, would'nt that be easier? 
Hesham. We do not assume that the visited network will provide anything,
	e.g. 6to4 relay.  Create dualstack bindings in mipv6. we need
	extensions to mipv6. 
XYZ: NTT runs IPv6 worldwide network. MIPv6 HA can have tunnel server,
     v6/v4 tunnel, MN in IPv4 network. Tunnel server is known and
     exists, why not use it?  
Henrik: Mipv4/v6 to setup these tunnels makes sense. There are
	commercial deployments.  
Raj: There is a bar bof tonight at 10pm to discuss this topic further.
Pascal: Which mobility solution to use?
Raj: We need one mobility solution. It will be mipv4 or mipv6. So this
     draft is saying use only mipv6.  
Pascal: Why IETF is proposing two mobility solutions?
Raj: You have a solution for IPv4 and another one for IPv6. Its upto
     you which one you implement/deploy.


6. Issues with firewalls
************************
Presenter: Franck Le <draft-le-mip6-firewalls-00.txt>

- Issues listed in presentation.

James: Generic problem with firewalls and ESP. Solution is nsis. 
Jari: Is problem nat or firewall? The solution depends on what. There
      is nat traversal for IPsec. 
Frank: Issue is with firewalls. Its the reachability aspect.
Hesham: How come you assume BU and BAck will go thru?
Franck: We assume creating state in the firewall. Without using ESP. I
	am assuming ESP issue is resolved some other way.  

Raj: Problems described here applies to GPRS/UMTS networks as well because
     GGSN has packet filters similar to firewalls. Xiabao Chen has an
     I-D that discusses these issues. The I-D is:
     draft-chen-mip6-gprs-00.txt 
     Franck's draft and Xiabao's drafts are informational documents
     that are useful from MIP6 deployment perspective.. 

Question to WG: Firewall issues: Do they need to be documented? Maybe
	 advanced as informational RFC? Go back to ML and discuss. 


7. NAI Option
*************
Presenter: Kent Leung <draft-patel-mipv6-nai-option-01.txt>

James: There is a shared secret key between the HA and MN. We need to
       have a design team and do things bottom-up instead of
       pieces. This relates to the bootStrap option. Approximately 3
       persons have read the draft. 
Kent: Yes some issues are related to bootstrapping. 
Raj:  The proposal is to use NAI 
Kent: There is infrastructure that utilizes NAI. 
Alper: There are other identifiers, like FQDN, opaque names. 
Raj: AAA mechanisms deployed today indicate that NAI is a good option. 
Charlie: NAI in mipv4 is good because IPv4 addresses were not unique,
       but in MIPv6 they are unique. Why not use network prefix? Why
       shouldn't we take a network address and use it as an
       identifier?


8. Authentication Option for MIP6
*********************************
Presenter: Kent Leung <draft-patel-mipv6-auth-protocol-01.txt>

-  MN-HA authentication function, using NAI for identifying MN. AAA
   servers identify clients using NAI. Some mipv6 modifications are
   proposed.  

Raj: Alternate key mechanisms should not weaken security. BU is
     secured by somethingelse not by ipsec.  
James:  Key distribution. IKE for key distribution. Draft should talk
     about a specific key distribution.  
Raj:  This draft assumes shared keys but their distribution is not an issue
     for this draft.  
Gopal: Alternative authentication should talk about key distribution?
Alper: We should not require additional signaling on MIPv6 that does
     not exist. 
Charlie: Base MIPv4 replay protection. We can have better key
     distribution schemes as time goes on. So requiring key
     distribution may not be a bad idea. Key distribution can be
     handled later and or orthogonally.

9. AAA Problem Statement
************************
Presenter: Hiroyuki Ohnishi <draft-ohnishi-mip6-aaa-problem-statement-00.txt>

Raj: Integration of MIPv6 with AAA. Additionally AAA can be used for
     bootstrapping. The AAA WG decided that it is upto mipv6 WG to
     determine if a MIP6 AAA App is needed.  
Hesham: It does not look like an integration.
John: Another WG like AAA can get work from MIPv6 WG if mipv6 wants
     it. MSAAA can be done in MIPv6 and then diameter mipv6
     application  can be done at AAA WG. 
Jari: Deployments that have AAA and MIPv6 requiring new things at link
     and netwoprk layer like on 802.11 networks we need to be
     careful. 
Raj: This should be an option.
Pete: Differentiate access authentication and the use of mipv6.
Charlie: Why not use the AAA solution for MIPv4 for MIPv6 also?
Raj: Not directly mappable. Since there does not exist the FA.

10. Binding Update Backhauling      
******************************
Presenter: Wasim Haddad <draft-haddad-mipv6-bub-01.txt>

- Bub reduces signalling. BUBC message is used to agree on bub
  mode. 

Eric. In the case where the RR test is done the first time: The first
      time is it secure? Man in the middle attacks can be done. Bub has this
      problem, maybe it is  more secure but not any more secure.  
Raj. But Security relies on the esp tunnel between HA and MN. 
Jari. This is already done in the base spec.
Raj. Not enough time to discuss further.
    The proposal here is an enhancement to Route Optimization when
      two end-points are  mobile. Does this I-D address any security issue
      that is inherent within the the current RR scheme?

11. Optimizing Mobile IPv6 
**************************
Presenter: Wasim Haddad <draft-haddad-mipv6-omipv6-01.txt>

Jari: Defining optimization is great. DF RR is good, man in the middle
      will have only a limited term effect. OMIPv6 might increase the
      times of effect. 
      Jari feels that there are issues with such an approach. 
Erik. Agrees with Jari. Latency optimizations are OK but it should
      like compromise security. Completely getting rid of coti/cot
      messages not a good idea.  

Attendee: Bub and omipv6 looks same, what is the difference?
Haddad. Bub is for one end point. And it has bubc message.


---------------------------------------------------------

With time running out, Raj provided pointers to Charles Perkins' I-D
about RO with preconfigured keys. Discussion of this will be taken up
on the list.

Gopal summarized next steps for the WG.




_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www.ietf.org/mailman/listinfo/mip6