Subject: [Mip4] IETF-62 Draft Minutes.

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 04 Apr 2005 18:24:05 +0200

Below you'll find draft minutes from the Minneapolis MIP4 meeting.
Please read and comment.  Deadline for turning these in is this
Friday, so we won't be able to act on comments received after that.

A big thank to the three minute takers, Jayshree Bharatia, Espen
Klovning and Will Ivancic - I don't think we've had such detailed
and complete minutes ever before!

A html version of the minutes are available here:

  http://mip4.org/ietf62/minutes.html

	Henrik

========================================================================
MIP4 WG  Minutes (Thursday, March 10, 2005, 1645-1745)
========================================================================

1. Preliminaries:					    	  Chairs
------------------------------------------------------------------------
   Slides: http://tools.ietf.org/wg/mip4/ietf/62/mip4-agenda.ppt

   Minute takers: Espen Klovning, Jayshree Bharatia, Will Ivancic

   Henrik: Pete McCann could not be here so I am on my own here. 

   Henrik had not received slides from Vikas Goel and therefore dropped
   his presentation of draft-goel-mip4-encapext-00.txt

   Vikas asked whether he could to add the presentation to the agenda.
   Henrik allocated a slot at the end of the agenda.

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

  +---------------------------------------------+-----------------------+
  |draft					|status			|
  +=============================================+=======================+
  |draft-ietf-mip4-dynamic-assignment-03	|Waiting for AD Writeup	|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-faerr-00			|Waiting for Chair	|
  |						|Writeup		|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-reg-tunnel-00		|AD Evaluation		|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-rfc2006bis-01		|Reviewer needed for	|
  |						|MIP-centric review of 	|
  | Comments: 					|			|
  |						|			|
  | Henrik: This is the third WG meeting where I|			|
  | have asked for volunteers to do MIB review, |			|
  | but we still don't have anyone.		|			|
  |						|			|
  | Kent: We should try to leverage the MIPv6	|			|
  | MIB resource. The MIPv6 MIB draft went	|			|
  | through quickly				|			|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-rfc3012bis-03		|Waiting for Chair 	|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-rfc3344bis-01		|One remaining issue	|
  |						|			|
  | Comments:					|			|
  |						|			|
  | Henrik: There is one remaining issue with	|			|
  | 3344. It is the same as last time. The	|			|
  | discussion is going on but no consensus yet.|			|
  | I hope to manage that now.			|			|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-aaa-key-06			|Published as RFC 3957	|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-experimental-messages-02	|RFC Ed Queue::Awaiting	|
  |						|processing and publ.	|	
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-vpn-problem-statement-03	|RFC Ed Queue::Awaiting	|
  |						|processing and publ.	|	
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-lowlatency-handoffs-v4	|AD Evaluation::AD	|
  |						|Followup		|
  | Comments:					|			|
  |						|			|
  | Thomas Narten: There is a nominal dependence|			|
  | on the regional tunneling draft that is	|			|
  | holding up the low latency draft.		|			|
  +---------------------------------------------+-----------------------+
  |draft-ietf-mip4-vpn-problem-solution-01	|Review needed		|
  |						|			|
  | Comments:					|			|
  |						|			|
  | Henrik: I have one reviewer for the VPN	|			|
  | solution draft lined up but more are needed.|			|
  +---------------------------------------------+-----------------------+

3. Resolving one outstanding issues for 3344bis:	      Charlie P.
------------------------------------------------------------------------
   draft-ietf-mip4-rfc3344bis-01

   Slides: http://tools.ietf.org/wg/mip4/ietf/62/fa-ha-sa-selectors.pdf

   This issue revolves around what selectors (e.g., Reg. Request
   CoA and HA address) should be used to select the SA (security
   association) used to calculate FA-HA Authorization-enabling
   extensions.

   Issue: Selector for the HA-FA Security Association. 

   * When the MN sends a de-register request to a foreign agent with the
     intention of de-registering its earlier binding it had with a
     different foreign agent, the behavior of FA in RFC3344 is to reject
     such request with invalid care-of address error. However, the HA
     considerations allows such requests. The scenario is not handled
     consistently at both HA and FA ends.

   * Also, if the foreign agent is allowed to forward such requests,
     there is no explanation as how the home agent should locate the
     security associations for that FA and validate the FHAE.

   * This issue was also discussed in IETF-61. The following are the
     selector fields: 
     - Source IP address
     - Destination IP address
     - Care-of address
     - Home address
     - Lifetime field (or the bit which says that it is zero or not)
     - The D bit (to determine whether coa is co-located).

   It was mentioned that CoA and HoA usage may be problematic because
   there will not be correct security association in those cases.

   Comments:

      Kent Leung: 

	Agreement was that we are not considering NAT scenario (out of
	scope for RFC3344). Also, SA (indexed by the source IP address)
	would solve the problem. This source address will always be
	known by the HA. 

      Henrik:
	 Referred to as a,d here.

      Kent:
	 Agreed to go with that approach. Just gone use IP src to index
	 cover all the case. It been awhile.  

      Henrik: 
	 It would be nice to find a solution for the non-NAT case. We
	 will have to revisit NAT case too. We must be aware of that
	 now.  Permitting COA MN to send directly.  

      Kent: 
	 It was brought up but it is breaking some processing rules. It
	 is the R bit case right. We will not be able to go over this
	 now. We should start from our email discussion.   

      Henrik: 
	 We have no known starting point.

      Kent: 
	 We are probably too tired to discuss it 

      Charlie: 
	 I did run out of steam.. We were at equilibrium

      ...

      Kent: 
	I do not mind any good approach. We have not found it yet.

      Henrik: 
	What is your view of the status?

      Kent: 
	What I stated earlier was the status.

      Henrik:
	We need a known starting point. I had hoped we had come to a
	point where we could agree. 

      Kent:
	I can summarize how far we have come.

   Resolution:
      Action item: 

	Kent to summarize how far this communication has gone. The
	working group will consider this as a new starting point. Note
	that there was no resolution offered on this issue. There will
	be further discussion on the mailing list.  

4. Generic Strings:					    Alpesh Patel
------------------------------------------------------------------------
   draft-sastry-mip4-string-extension-00.txt

   Slides: http://tools.ietf.org/wg/mip4/ietf/62/genericstring.pdf

   This document specifies an extension to carry a text string in the
   Registration Reply messaged, with the purpose of having the text
   string displayed on the Mobile Node user interface.

   Alpesh presented the draft that stems from customer requests during
   deployment. 

   - This draft defines a new skippable extension for use by HA and FA
     in registration request. Note that both FA and HA can add this
     extension in to the same registration request. 

   - A new subtype defines two values indicating who adds this
     extension.  If this extension is added by the HA, it must be present
     before MHAE. 
   
   - In case of authentication failure, error is returned. The text
     field of the extension can be displayed on MN's user interface. The
     MN may throttle the message.

   Comments:

      Espen Klovning: 

	The mechanism is OK but I do not like the reference to user
	interface.  The MN might not have a user interface. It could
	write the string to a log. Tone down the reference to user
	display. It is up to the MN to decide what to to with the
	information.

      Avi Lior: 

	I like the draft. In case of AAA, user doesn't know the detail.
	Although it is not clear how to indicate whether the string
	should go to the user or not.

      Kent: 

	I agree with Espen. It is up to the MN to decide what to to with
	the strings.

      Xxx: 

	This can be appended by both nodes in the same message. If FA
	adds this extension, it can't be authenticated (which is
	optional).

      Henrik: 

	This is within the scope of this WG but will require a charter
	update.

   Resolution:

      Enough interest (humming) to make this a WG item

      Action:
        Charter update will be proposed by the chair for this work.

5. Host Configuration Extensions:		     	      Kent Leung
------------------------------------------------------------------------
   draft-leung-mip4-host-config-vse-00.txt

   Slides: http://tools.ietf.org/wg/mip4/ietf/62/hostconfig.pdf

   This document describes the extensions used to provide the base host
   configuration in the Registration Request and Reply messages.

   Kent presented:

   - The MN needs additional configuration to setup MIP interface. This
     is from the deployment perspective. Current host configuration is
     insufficient. 

   - Defines NVSEs in the registration Request used by HA to include
     DHCP in response.  Host configuration types includes HA prefix, DHCP
     server, DNS server, DHCP client ID, default Gateway, DNS suffix and
     config URL. 

   - The informational status is asked at this time by the author.
     Again, this will go as vendor specific option.  

   Action:

      It wasn't very clear whether WG should take this document as a WG
      item or not.  Although 6 people volunteered to support this draft
      if it is taken as a WG item.

6. Questions about MIPv4/MIPv6 - IPv4/IPv6 transitions:	          Chairs
------------------------------------------------------------------------

   Henrik: 

      There are currently 4 proposed solution drafts for MIPv4/MIPv6
      transition. One for MIPv4 and three for MIPv6.  The drafts
      describes different alternatives. It is not clear where this work
      belongs to at this time. Non of the solution are complete. I think
      we should start by producing a problem statement.

   Show of hands indicated little interest in the WG for taking the
   transition issue up as a WG item.

   Comments:

      Thomas: 

	Surprised over the lack WG interest. Charter WG to have clear
	idea.  Current deployments of MIP4 that wants to go to IPv6.  

      Vijay: 

	There are two distinct scenarios. One for MIPv6. How to reach
	IPv6 over IPv4 network. One for MIPv4 on how to move into IPv6
	network.

      Kent: 

	Too many access network with IPv4. That is the reason for the
	interest in MIPv6.

      Thomas : 
   
	Good. It fits better in the MIPv6 group.

   Action:
	None

6A. Questions about regional registration and AD feedback:	  Chairs 
------------------------------------------------------------------------
   draft-ietf-mip4-reg-tunnel-00.txt

   Henrik: 

      There is a small issue on how to handle AD review feedback.
      Charlie?

   Charlie: 

      We will be able to answer all issue that has been raised by the
      ADs.  We should have a new draft shortly after the beginning of
      June.

7. RADIUS attributes for Mobile-IP v4:		     	 Madjid Nakhjiri
------------------------------------------------------------------------
   draft-nakhjiri-radius-mip4-00.txt
   
   Slides: http://tools.ietf.org/wg/mip4/ietf/62/radius_mip4.pdf

   This document defines the RADIUS attributes that provide support for
   Mobile IPv4 operations such as key management and authentication
   services during a mobile node's registration process. 

   Madjid presented the draft. 

   - This draft is relevant to MIP-AAA interaction. A receipt of the
     registration request results in to the authentication and creation of
     new security association.  There is no document detailing this
     information from the AAA perspective. All current documents are
     written w.r.t. MIP.  Two cases are considered, co-located and FA-based
     CoA. 

   - Can't do Radius extension unless this WG endorse this work. Hence
     Liaison is needed from MIP4 to RADEXT WG. 

   - Want to make sure that MIP functionality is verified by this
     working group.

   Comments:
      Alpesh: 

	We have due to deployment requirements made vendor specific
	solutions that do the same. There is interest for this.

      Kent: 

	There is definitely deployment interest.

      Avi Lior: 

	We have to review the semantics of the attributes. View whether
	RADIUS protocol is violated.  Perhaps WG item.  Primarily, ask
	Radius to review it.

      Henrik: 

	When I worked on MIPv4 deployments, we did our own. Having a
	standardised set will be good.  This will be a WG item for
	RADEXT. They need to know how we evaluate this, though.

      Thomas: 

	It defines new attributes. Then the right home is the RADEXT WG.
	It does not matter. Both WG must be happy with the solution.

      Alpesh: 

	We need to think about 3012bis in this. Only MD5 is supported in
	3012bis. RADIUS have limitations. There are no mechanisms to use
	HMAC or SHA1, and MD5 is being deprecated in RADIUS group.

      Charlie: 

	This should be standardized in RADEXT working group similar to
	what has been done for DIAMETER.

      Kent: 

	Agree with Avi. We have to look at the semantics of fields. It
	should be decided by MIP experts. After consensus we should go
	through RADEXT WG to get approval.

   Action:

      Humming indicated that the WG should invest energy in this
      document.  Although the decision on where it will land as a wg
      item is still open.

8. Known bugs in 3519:				     	  Sri Gundavelli
------------------------------------------------------------------------
   RFC 3519

   Slides: http://tools.ietf.org/wg/mip4/ietf/62/3519-bis.pdf

   Experience with RFC 3519 and discussions around rfc3344bis has
   brought to light some weaknesses of RFC 3519 which may warrant
   starting work on a revision of this.  This presentation will give a
   summary of these issues.

   Sri presented a few issues/problems with RFC3519 that have been
   detected during implementation and deployment.

   - The motivation for this draft is to present different issues which
     are related to RFC3519 and found from the implementation.

   - Issue 44: According to RFC3344, the FA is required to send a
     registration request with the source address of the outgoing
     interface. This conflicts with RFC3519 where the FA is required to
     set the source address of the registration request to its CoA.

   - Issue 45: HA dependency on the source address for the NAT detection
     logic.

   - Issue 3(?): Keep-alive message. This has no protection. This is
     causes inconvenience. 

   - Issue 4: Usage of ICMP echo packet format for the keep-alive
     message and the associated issue. Protocol package, the context
     should be maintained (either MIP subsystem or something else)

   - Issue 5: Overloading the MIP port 434 for control and data messages
     and the implementation issues. Need to identify whether this is a
     data or control packet. This is just a UDP package and goes all the
     way to the application layer.

   - Issue 6: FA doesn't have any role for request but the reply is not
     the same.  It may be of different version which may cause problem.

   Comments:
      Henrik: 

	I am fine with all the issues except the one where the port
	number can be done in kernel. No bis issue. Another protocol.

      Alpesh: 

	The problem with 3519 is that the same channel is used for both
	signaling and data

      Espen: 

	This is an router/hardware performance issue that is less
	relevant for client implementations.

   Action:

      Suggest to make 3519bis an WG item. Henrik will serve as editor
      and got commitment from 5-6 people to contribute to this draft.

9. Encapsulation extension:			     	      Vikas Goel
------------------------------------------------------------------------
   draft-goel-mip4-encapext-00.txt

   This drafts describes an extension which allows the Home Agent to
   specify, in the Registration Reply, the kind of encapsulation types it
   supports.

   Vikas presented a draft to address a scalability issue with tunnel
   endpoints in the where the HA should force the MN to use a specific
   tunnel encapsulation.

   Comments: 

      Espen: 

	This will not work as long as the M and G bits are not mandatory
	in RFC 3344.

      Vikas: 

	You have to set up three tunnels for each HA. It will not scale.

      Kent: 

	This is not necessary. The RRQ can not indicate more than one
	tunneling method.

      Espen: 

	Yes, you can.

      Sri:

	What is the original intent? There is no way for the HA to know
	what to use. Deployment scenario should be well understood.

      Xxx: 

	HA just reacts on what is selected by the MN. But if it is
	different from what HA wants, there may be a need of supporting
	two encapsulation choices.  

      Henrik: 

	Don't see a clear need. This makes sense only if HA supports
	either G or M.  It doesn't make sense if HA supports both.
	Generally clients are not deployed which are incompatible with
	HA. This doesn't seem like a real issue since num of choices are
	few only. 

      Henrik: 

	Encapsulation offer goes in a registration request and the
	selection of the encapsulation is received in the registration
	reply. Hence there may not be any need of having multiple
	tunnels.

      Kent: 

	The proposed solution may not work properly.

      Henrik: 

	RFC 3344 is not very clear but the general trend is that HA
	selects the capability sent in the registration request
	(appendix of RFC3344 indicates this way). 

      Xxx: 

	Vendor specific extension may be the solution. 

      Henrik: 

	I read the specification before the meeting and it says you can.
	It is not very clear in the specification, though, so it seems
	that this is an new issue for 3344bis

   Action:

      It was determined that RFC3344 needs to have further clarity on
      encapsulation information negotiation. And, hence, there may not
      be any problem which need to be solved by this draft.

*Henrik: We are done.*

-- 
Mip4 mailing list: [email-masked]
    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/

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 04 Apr 2005 18:01:44 -0700

hi Henrik,

couple of comments.

> 6. Questions about MIPv4/MIPv6 - IPv4/IPv6 transitions:	          Chairs

what I said goes something like this.

There are two distinct scenarios that folks are interested in. There
are people who want to deploy MIPv6. If a MIPv6 MN ends up an IPv4
only access network, it needs to be able to reach the IPv6 network.
And then there are people who have deployed MIPv4 currently. They
would like to move to MIPv6.

> 	Good. It fits better in the MIPv6 group.

Thomas said lot more. I dont remember now. I think he said the first
scenario fits in the MIPv6 wg. Thomas?

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 06 Apr 2005 00:51:46 +0200

> hi Henrik,
[...]
> would like to move to MIPv6.

I prefer to summarise a bit, so the minutes don't get too long - would
this represent your point fairly? :

	There are two distinct scenarios of interest, One for a MIPv6
	node to reach the IPv6 network over IPv4, and the other for
	people who currently have MIPv4 deployed but would like to move
	to MIPv6.

> scenario fits in the MIPv6 wg. Thomas?

Ok.  I don't remember more details myself.

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Apr 2005 15:14:13 +0200

> Ok.  I don't remember more details myself.

It's recorded! Download the 46Mb mp3 of the mip4 iet62 session at:
http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf62/ietf62-ch6-thur-noon.mp3

Thomas' double intervention on this particular topic is between
4:30:05 - 4:31:04 and
4:32:18 - 4:32:28

Alex