[Mip4] DRAFT Minutes from MIP4 meeting in Washington

Henrik Levkowetz <henrik@levkowetz.com> Wed, 08 December 2004 20:36 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01893 for <mip4-web-archive@ietf.org>; Wed, 8 Dec 2004 15:36:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc8eo-0006wp-Lx for mip4-web-archive@ietf.org; Wed, 08 Dec 2004 15:43:31 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc8M3-0003hF-ES; Wed, 08 Dec 2004 15:24:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc8By-0005mI-Rh for mip4@megatron.ietf.org; Wed, 08 Dec 2004 15:13:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29832 for <mip4@ietf.org>; Wed, 8 Dec 2004 15:13:40 -0500 (EST)
Received: from av9-2-sn4.m-sp.skanova.net ([81.228.10.107]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc8Io-0006Wa-2F for mip4@ietf.org; Wed, 08 Dec 2004 15:20:46 -0500
Received: by av9-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id CF360380F1; Wed, 8 Dec 2004 21:13:05 +0100 (CET)
Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av9-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id B80B537E5E for <mip4@ietf.org>; Wed, 8 Dec 2004 21:13:05 +0100 (CET)
Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8DF7E37E60 for <mip4@ietf.org>; Wed, 8 Dec 2004 21:13:05 +0100 (CET)
Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1Cc8BN-00087C-5G for mip4@ietf.org; Wed, 08 Dec 2004 21:13:05 +0100
Message-ID: <41B76050.8080709@levkowetz.com>
Date: Wed, 08 Dec 2004 21:13:04 +0100
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mip4@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad
Content-Transfer-Encoding: 7bit
Subject: [Mip4] DRAFT Minutes from MIP4 meeting in Washington
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb
Content-Transfer-Encoding: 7bit

Below are the minutes from the MIP4 WG meeting in Washington.

Please read and respond with comments and corrections.

The minutes are also available here in three different formats:

    http://www.mip4.org/ietf61/minutes.pyht
    http://www.mip4.org/ietf61/minutes.html
    http://www.mip4.org/ietf61/minutes.txt


	Henrik



========================================================================
MIP4 WG  Minutes (Thursday, November 11, 2004, 1300-1500)
========================================================================



1. Preliminaries:                                                 Chairs
------------------------------------------------------------------------
  (slides: http://www.mip4.org/ietf61/mip4-agenda.ppt )

  Minute taker: Eva Gustafsson

  Charlie's presentation regarding 3344bis issues has been moved up,
  as he has a plane to catch.  No other comments on the agenda.  


2. Document Status:                                               Chairs
------------------------------------------------------------------------

  ==============================================  ======================
  draft                                           status
  ==============================================  ======================
  draft-ietf-mip4-aaa-nai-03                      RFC Published
  draft-ietf-mip4-aaa-key-06                      RFC Ed Queue
  draft-ietf-mobileip-lowlatency-handoffs-v4-09   AD Evaluation :: AD Followup
  draft-ietf-mip4-vpn-problem-statement-03        RFC Ed Queue
  draft-ietf-mip4-rfc3012bis-02                   Almost ready to be sent to IESG
  draft-ietf-mobileip-reg-tunnel-09               Draft with new boilerplate, then IESG
  draft-ietf-mip4-dynamic-assignment-03           Publication Requested
  draft-ietf-mip4-experimental-messages-02        RFC Ed Queue
  draft-ietf-mip4-rfc2006bis-01                   Review needed
  draft-ietf-mobileip-vpn-problem-solution-03     Editing needed
  draft-ietf-mip4-rfc3344bis-01                   ID exists
  draft-mip4-faerr-00.txt                         In WG last call
  ==============================================  ======================


3. 3012bis - summary of recent issues, status, next steps:   Pete McCann
------------------------------------------------------------------------
  draft-ietf-mip4-rfc3012bis-02.txt

  Issue:

    3012bis, issue raised with HMAC_CHAP_SPI, proposed solution to
    delete HMAC_CHAP_SPI from text, i.e. no longer supported. 


  Comments:

    None.


4. Resolving outstanding issues for 3344bis, and next steps:  Charlie P.
------------------------------------------------------------------------
  ( slides: http://www.mip4.org/ietf61/rfc3344bis.ppt )

  Issue:

    Issue 45 remains unsolved - what to do if deregistration message
    fails due to broken foreign-home authentication extension. New
    revision specifies that FA MUST NOT apply foreign-home
    authentication extension to MN's deregistration request.


  Comments:

    Kent Leung: 
	Thought we had different agreement on mailing list.

    Pete McCann: 
	Agreed that if FA-HA authentication failed, extension must be
	discarded. (?)

    Hesham Soliman: 
	If anything added on top, needs to be authenticated to
	avoid man-in-the-middle attack.

    Pete: 
	If extension is there, it needs to be respected.

    Discussion...

    Question by someone on different issue...

    Pete: 
	Need to take this discussion to the list again.

    Henrik Levkowetz & Pete: 
        Ok to only do this when care-of address was that of another FA,
	not the FA transmitting this to you? Check lifetime zero, other
	care-of address, FA would leave on authentication extension? 

    Kent: 
	Need to think this over...

    Pete: 
	Exception on FA not to put this on, on HA not to discard.

    Q: 
	Simultaneous bindings?

    Charlie Perkins: 
	Don't see connection with simultaneous bindings.


  Resolution:

    Action item: Charlie will write this down and send to list


5. Co-editor for draft:                                           Henrik
------------------------------------------------------------------------
  draft-ietf-mobileip-vpn-problem-solution-03.txt

  We still need a co-editor to help Sami Vaarala with this.  Those interested,
  please approach chairs after meeting.


6. Faerr document - last call status                         Pete McCann
------------------------------------------------------------------------

  Issue:

    Last call ended Friday, Nov 5th . One comment received: what does
    MN do if receives unauthenticated FA extension?


  Comments:

    Henrik: 
	Since this message only goes on link local between FA and MN, 
	should not be too troublesome to leave as is. TTL check in this
	message?  Think so.

    Kent: 
	Resolution of wording done in WG? Yes. Should get FA error on
	MN.  Case of MN-FA link being compromised minimal. Need text
	about MN-HA connection.

    Pete: 
	Need text describing that FA does if it sees this from FA. Should
	deregister. Be careful; not authenticated.

    Kent: 
	Either go "MAY", or do the ping test first.

    Charlie: 
	Make sure HA does not deliver erroneous message, right?

    Pete: 
	No guarantee that message actually came from HA.

    Charlie: 
	If you get FA error, calls for suspicion, wait a little longer
	for successful registration reply, otherwise do something about
	it.

    Henrik: 
	Thinks this is overengineering it. Why dance around this
	particular one? Just take it for what it is and act on it.
	Assume link between MN and FA is safe.


7. Take up route optimization for MIPv4?:                    Pete McCann
------------------------------------------------------------------------

  Issue:

    Old problem. Do we want to take this up in the WG?

    Earlier statement that there is considerable work to get acceptable
    security.

    Would like to see some real-world deployment. Which are the
    customers, what is the security model, assumptions?

  Comments:

    Hesham: 
	You got the right question. Also, first question should be "what
	do you mean by route optimization?". If it's the same as for
	MIP6, if we apply same security requirements, will be a
	challenge. Old draft, signaling between FAs would be useful,
	more useful than full-fledged route optimization.

    Pete: 
	Would like to keep signaling orthogonal to existing signaling.

    Vijay: 
	Think we should do this, not to have all traffic go through HA.
	Nokia would like this.

    Pete: 
	What link layers? Carrier?

    Vijay: 
	For all environments...

    Pete: 
	We need to pin down what environments need this.

    Alexandru Petrescu: 
	Certain type of route optimization is useful. Is there common
	idea what this leads to and what solutions we want to work on?

    Pete: 
	Old draft (Perkins, Johnson), also MIP6 type of solution.

    Hesham: 
	We run and deploy MIP4, see no need for route optimization.
	Whatever we see for MIP6 will be deployed. To enable service,
	not needed.  For efficient mobility, FA-FA signaling needed.

    James Kempf: 
	We don't deploy MIP (4 or 6). Agree with Hesham; we don't 
	need route optimization now.

    Hesham: 
	Low-latency handoffs helpful. Experience says most efficient
	solution would be low-latency stuff plus hierarchical stuff. We
	effectively get route optimization with this.

    Kent: 
	Get real customers to come forward so that we can nail down
	requirements for this.

    Pete: 
	Please post studies etc. on mailing list. Also, doing this in
	our WG requires discussion with ADs to put it on charter.

    Pete: 
	We need some more support for foreign agent error to move
	forward.


  Resolution:

    Humming inconclusive.


8. Questions about MIPv4/MIPv6 - IPv4/IPv6 transitions:           Henrik
------------------------------------------------------------------------

  Issue:

    MIP4/MIP6 combinations. New mailing list created:
    miptrans@ops.ietf.org <mailto:miptrans@ops.ietf.org>.

    draft-larsson-v6ops-mip-scenarios-00.txt ...  describing scenarios
    evolved. Will be submitted as individual submission, as there is
    currently no WG where it belongs. If you have interest in this area,
    read draft and comment.

    To do MIP4 work in this space, we need clear statement of scenario
    and environment where you need your solution to be applied, clear
    statement of which combinations (from draft-larsson...) will be
    addressed, and definition of problem (why does this need to be
    done?).

    We need to know why we are doing it and how it will apply.


  Comments:

    Alexandru: 
	First time I see draft-larsson...

    Henrik: 
	Submitted recently, mentioned it because we want people to look 
	at it and comment.

    Alexandru: 
	Example: MIP6 MN transmitting to IPv4 network?

    Henrik: 
	Yes, this scenario is one of many mentioned in this draft. Would
	belong in MIP6 WG or possibly in new transition WG.


9. Adapting MIPv6 Fast Handover for MIP4:                Charlie Perkins
------------------------------------------------------------------------

  Issue:

    FMIPv4 motivation and design ideas, implementation benchmarks.
    Available for anyone to work on - will not push this.


  Comments:

    Pete: 
	Could you post something about similarities with low-latency on
	the draft? We need discussion with ADs if we want this back on
	the charter.

    Charlie: 
	Only two factors: performance and simplicity.

    Kent: 
	Curious on the numbers. Is there a further breakdown on those 
	numbers...?

    Charlie: 
	Numbers due to advertising model.

    Hesham: 
	This is basically fast handoff for MIP6, low-latency. Hard to
	find difference enough for so significant difference in
	performance.

    Charlie: 
	We wanted answers as fast as possible.

    Henrik: 
	Very interesting. First two values I recognize from client I 
	used to work on. Would like to see as experimental.

    James: 
	Agree with Henrik. We have a paper where we did extensive
	comparison. We also did something similar to this; worked very
	well on WLAN.

    Henrik: 
	Can you send pointer to paper to the list.

    James: 
	Will do as soon as it is published.

    Hesham: 
	Would be really good to see just email on difference between
	this and low-latency.  



-- 
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/