From mip4-bounces@ietf.org Thu Dec 01 09:13:38 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhpBp-0007CK-Tk; Thu, 01 Dec 2005 09:13:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpBn-00078v-LP
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 09:13:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25001
	for <mip4@ietf.org>; Thu, 1 Dec 2005 09:12:48 -0500 (EST)
Received: from smtp5.clb.oleane.net ([213.56.31.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpWH-0006z8-RK
	for mip4@ietf.org; Thu, 01 Dec 2005 09:34:46 -0500
Received: from Pavillonquatre ([194.3.133.88]) (authenticated)
	by smtp5.clb.oleane.net with ESMTP id jB1EDEA7007612
	for <mip4@ietf.org>; Thu, 1 Dec 2005 15:13:25 +0100
Message-Id: <200512011413.jB1EDEA7007612@smtp5.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <mip4@ietf.org>
Date: Thu, 1 Dec 2005 15:12:52 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX2gVD+Lsssj0tsT46qK5ClTfD15Q==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Subject: [Mip4] Wireless/WiFi Convergence Conference - Call for Papers 
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>
Content-Type: multipart/mixed; boundary="===============1463274433=="
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1463274433==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_013D_01C5F689.B3081150"

This is a multi-part message in MIME format.

------=_NextPart_000_013D_01C5F689.B3081150
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The Wireless/WiFi Convergence Conference will be held in Paris on May 16 to
May 19, 2006

 

http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006cfp.htm

 

It is still time to submit proposals. Organizers are looking for UMA papers.

 


------=_NextPart_000_013D_01C5F689.B3081150
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The <strong><b><font face=3DArial><span
style=3D'font-family:Arial'>Wireless/WiFi Convergence =
Conference</span></font></b></strong>
will be held in <st1:place w:st=3D"on"><st1:City w:st=3D"on"><span =
class=3Dstyle24>Paris</span></st1:City></st1:place><span
class=3Dstyle24> on May 16 to May 19, 2006</span></span></font><font =
size=3D2><span
lang=3DEN-GB style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><a
href=3D"http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006=
cfp.htm">http://www.upperside.fr/wirelessconvergence2006/wwconvergence200=
6cfp.htm</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is still time to submit proposals. =
Organizers are
looking for UMA papers.</span></font><font size=3D2><span lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_013D_01C5F689.B3081150--



--===============1463274433==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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/

--===============1463274433==--





From mip4-bounces@ietf.org Thu Dec 01 15:50:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhvOK-0000cw-C8; Thu, 01 Dec 2005 15:50:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhvNW-00009F-UC; Thu, 01 Dec 2005 15:50:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25918;
	Thu, 1 Dec 2005 15:49:18 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ehvi1-00084V-35; Thu, 01 Dec 2005 16:11:18 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EhvNR-0006cE-V5; Thu, 01 Dec 2005 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EhvNR-0006cE-V5@newodin.ietf.org>
Date: Thu, 01 Dec 2005 15:50:01 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: mip4@ietf.org
Subject: [Mip4] I-D ACTION:draft-ietf-mip4-reg-tunnel-01.txt 
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IPv4 Working Group of the IETF.

	Title		: Mobile IPv4 Regional Registration
	Author(s)	: E. Gustafsson, et al.
	Filename	: draft-ietf-mip4-reg-tunnel-01.txt
	Pages		: 34
	Date		: 2005-12-1
	
Using Mobile IP, a mobile node registers with its home agent each
   time it changes care-of address.  This document describes a new kind
   of "regional registrations", i.e. registrations local to the visited
   domain.  The regional registrations are performed via a new network
   entity called a Gateway Foreign Agent (GFA) and introduce a layer of
   hierarchy in the visited domain.  Regional registrations reduce the
   number of signaling messages to the home network, and reduce the
   signaling delay when a mobile node moves from one foreign agent to
   another within the same visited domain.  This document is an optional
   extension to the Mobile IPv4 protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-reg-tunnel-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mip4-reg-tunnel-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mip4-reg-tunnel-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-12-1121333.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mip4-reg-tunnel-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-mip4-reg-tunnel-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-12-1121333.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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/

--NextPart--




From mip4-bounces@ietf.org Thu Dec 01 17:46:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhxCL-00044b-Ko; Thu, 01 Dec 2005 17:46:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxCK-000442-HW
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 17:46:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27157
	for <mip4@ietf.org>; Thu, 1 Dec 2005 17:45:53 -0500 (EST)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhxWs-0001Xn-GD
	for mip4@ietf.org; Thu, 01 Dec 2005 18:07:55 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id jB1MkGL15651; Thu, 1 Dec 2005 17:46:16 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Thu, 1 Dec 2005 16:46:15 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0CE617A6@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX2E25CxbifUvQcTzq/9N9k1ghurwAsvp7Q
From: "Jayshree Bharatia" <jayshree@nortel.com>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>,
	<Madjid.Nakhjiri@motorola.com>, <vijayd@iprg.nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: quoted-printable
Cc: mccap@lucent.com, mip4@ietf.org, henrik@levkowetz.com,
	itijibox-mip4@yahoo.com
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

Hi all,

I am not sure how to proceed toward supporting co-located CoA mode in
RFC3012bis. RFC3012 doesn't have any details on this and it was a
working assumption that this draft is not applicable for co-located CoA
mode.

Later in the process of updating RFC3012bis, there was a discussion that
we shouldn't be limiting use of MN-AAA extension for co-located CoA
mode. Anyway, we need to come up with some agreement now. The following
is the summary of the discussion:
- Kent and Madjid think that having clarification that there is no
challenge included in the MN-AAA extension for co-located CoA mode is
good. Although, there is no need of indicating what type of value is
used for replay protection. Although, Vijay likes to see this to be
clarified.
- Charlie suggest removing support of co-located CoA mode.

Hence, I have three options:
1. Remove the paragraph which discusses co-located CoA support (last
paragraph of section 3.1)
2. Make changes to indicate that there is no challenge included in the
MN-CoA extension for co-located CoA mode.
3. Include changes proposed by Vijay in earlier email.

Please send me reply suggesting which option you prefer.

Regards,
Jayshree

-----Original Message-----
From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of
Charles E. Perkins
Sent: Wednesday, November 30, 2005 7:05 PM
To: Kent Leung (kleung)
Cc: mip4@ietf.org; itijibox-mip4@yahoo.com
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt



Hello folks,

I do not believe the document should support co-located CoA mode.  The
point is to enable some mechanism for use by the foreign agent.  There
is no need for a mobile node to use the challenge.  No additional replay
protection is afforded.

I would prefer for the use of the extension to be
prohibited whenever the 'D' bit is set.

Even when a foreign agent is sending 'R' bit advertisements, there isn't
any significant functionality gained.

Perhaps it's technically feasible to have the challenge in
such situations, but (i) it is wasteful and (ii) I would not like to see
it become considered a mandatory part of any mobile node implementation
where co-located care-of addresses are used, for whatever reason.

Regards,
Charlie P.

PS. Please excuse if I have overlooked some e-mail about this.


Kent Leung (kleung) wrote:

>On this particular topic, I don't understand what is missing in the=20
>details to support the CCoA mode?  Since the draft covers MN-AAA=20
>authentication with NAS in between, I would like to see both FA (CoA)=20
>and HA (CCoA) modes supported.  Where else would we be able to cover=20
>just the CCoA for MN-AAA authentication if not in this draft?
>
>Kent
>
>
> =20
>
>>not at this late stage. its fine as it is. however, I have
>>one comment on the support for co-located CoA mode. the draft=20
>>claims it supports it but there really isnt enough detail.=20
>>IMO, it should be clarified that only FA mode is described in=20
>>the draft.
>>
>>   =20
>>
>
> =20
>



--=20
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/


-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 18:04:27 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhxTX-0006ZD-6c; Thu, 01 Dec 2005 18:04:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxTV-0006TL-Rm
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 18:04:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28958
	for <mip4@ietf.org>; Thu, 1 Dec 2005 18:03:39 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ehxo4-0002Dd-1d
	for mip4@ietf.org; Thu, 01 Dec 2005 18:25:41 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 01 Dec 2005 15:04:16 -0800
X-IronPort-AV: i="3.99,203,1131350400"; 
	d="scan'208"; a="372925462:sNHT48086050"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB1N49eU001713;
	Thu, 1 Dec 2005 15:04:12 -0800 (PST)
Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 1 Dec 2005 15:04:05 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Thu, 1 Dec 2005 15:04:04 -0800
Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX2E25CxbifUvQcTzq/9N9k1ghurwAsvp7QAADXKbA=
From: "Kent Leung \(kleung\)" <kleung@cisco.com>
To: "Jayshree Bharatia" <jayshree@nortel.com>,
	"Charles E. Perkins" <charliep@iprg.nokia.com>,
	<Madjid.Nakhjiri@motorola.com>, <vijayd@iprg.nokia.com>
X-OriginalArrivalTime: 01 Dec 2005 23:04:05.0300 (UTC)
	FILETIME=[86F62740:01C5F6CB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: quoted-printable
Cc: mccap@lucent.com, mip4@ietf.org, henrik@levkowetz.com,
	itijibox-mip4@yahoo.com
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

I vote for #2.  The reason is that that RFC 3012 is addressing two
functions, as stated in previous emails (initiated by Gabe's review and
comment to split this draft).

1) FA challenge/authentication and MN-FA replay protection. =20

2) Generalized authentication (e.g. MN-AAA), which is independent if the
NAS is FA or HA.

I would like to keep this in one draft, which means both functions
should be covered fully (i.e. including CCoA mode).  I believe that
Vijay was OK with this except he wanted to explicitly state that replay
protection is using nonce/timestamp.  But I don't see a need since this
is fundamental function of Mobile IP itself.

Kent

> -----Original Message-----
> From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
> Sent: Thursday, December 01, 2005 2:46 PM
> To: Charles E. Perkins; Kent Leung (kleung);=20
> Madjid.Nakhjiri@motorola.com; vijayd@iprg.nokia.com
> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com; mccap@lucent.com;=20
> henrik@levkowetz.com
> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
>=20
> Hi all,
>=20
> I am not sure how to proceed toward supporting co-located CoA=20
> mode in RFC3012bis. RFC3012 doesn't have any details on this=20
> and it was a working assumption that this draft is not=20
> applicable for co-located CoA mode.
>=20
> Later in the process of updating RFC3012bis, there was a=20
> discussion that we shouldn't be limiting use of MN-AAA=20
> extension for co-located CoA mode. Anyway, we need to come up=20
> with some agreement now. The following is the summary of the=20
> discussion:
> - Kent and Madjid think that having clarification that there=20
> is no challenge included in the MN-AAA extension for=20
> co-located CoA mode is good. Although, there is no need of=20
> indicating what type of value is used for replay protection.=20
> Although, Vijay likes to see this to be clarified.
> - Charlie suggest removing support of co-located CoA mode.
>=20
> Hence, I have three options:
> 1. Remove the paragraph which discusses co-located CoA=20
> support (last paragraph of section 3.1) 2. Make changes to=20
> indicate that there is no challenge included in the MN-CoA=20
> extension for co-located CoA mode.
> 3. Include changes proposed by Vijay in earlier email.
>=20
> Please send me reply suggesting which option you prefer.
>=20
> Regards,
> Jayshree
>=20
> -----Original Message-----
> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20
> Behalf Of Charles E. Perkins
> Sent: Wednesday, November 30, 2005 7:05 PM
> To: Kent Leung (kleung)
> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com
> Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
>=20
>=20
>=20
> Hello folks,
>=20
> I do not believe the document should support co-located CoA=20
> mode.  The point is to enable some mechanism for use by the=20
> foreign agent.  There is no need for a mobile node to use the=20
> challenge.  No additional replay protection is afforded.
>=20
> I would prefer for the use of the extension to be prohibited=20
> whenever the 'D' bit is set.
>=20
> Even when a foreign agent is sending 'R' bit advertisements,=20
> there isn't any significant functionality gained.
>=20
> Perhaps it's technically feasible to have the challenge in=20
> such situations, but (i) it is wasteful and (ii) I would not=20
> like to see it become considered a mandatory part of any=20
> mobile node implementation where co-located care-of addresses=20
> are used, for whatever reason.
>=20
> Regards,
> Charlie P.
>=20
> PS. Please excuse if I have overlooked some e-mail about this.
>=20
>=20
> Kent Leung (kleung) wrote:
>=20
> >On this particular topic, I don't understand what is missing in the=20
> >details to support the CCoA mode?  Since the draft covers MN-AAA=20
> >authentication with NAS in between, I would like to see both=20
> FA (CoA)=20
> >and HA (CCoA) modes supported.  Where else would we be able to cover=20
> >just the CCoA for MN-AAA authentication if not in this draft?
> >
> >Kent
> >
> >
> > =20
> >
> >>not at this late stage. its fine as it is. however, I have=20
> one comment=20
> >>on the support for co-located CoA mode. the draft claims it=20
> supports=20
> >>it but there really isnt enough detail.
> >>IMO, it should be clarified that only FA mode is described in the=20
> >>draft.
> >>
> >>   =20
> >>
> >
> > =20
> >
>=20
>=20
>=20
> --
> 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/
>=20

-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 20:55:13 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei08n-0004Ne-30; Thu, 01 Dec 2005 20:55:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei08l-0004NT-J1
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 20:55:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17341
	for <mip4@ietf.org>; Thu, 1 Dec 2005 20:54:24 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0TL-0000Of-HA
	for mip4@ietf.org; Thu, 01 Dec 2005 21:16:28 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB21KO616269;
	Thu, 1 Dec 2005 17:20:24 -0800
X-mProtect: <200512020120> Nokia Silicon Valley Messaging Protection
Received: from es-nira-26-125.europe.nokia.com (10.162.26.125,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdEbAMmg; Thu, 01 Dec 2005 17:20:21 PST
Message-ID: <438FA95E.5000906@iprg.nokia.com>
Date: Thu, 01 Dec 2005 17:54:38 -0800
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center, Mtn. View
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kent Leung (kleung)" <kleung@cisco.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com>
In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org
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


Hello Kent,

What if the draft allows the Generalized Authentication
extension for mobile nodes with CCoA, but does not allow
the challenge extension?  I don't see what's wrong with this,
since the draft is "about" a foreign agent protocol.

Then, enabling the Generalized Authentication extension
for co-located CoA just amounts to reasonable practice,
not refocussing the document on colocated CoA.


Regards,
Charlie P.




Kent Leung (kleung) wrote:

>I vote for #2.  The reason is that that RFC 3012 is addressing two
>functions, as stated in previous emails (initiated by Gabe's review and
>comment to split this draft).
>
>1) FA challenge/authentication and MN-FA replay protection.  
>
>2) Generalized authentication (e.g. MN-AAA), which is independent if the
>NAS is FA or HA.
>
>I would like to keep this in one draft, which means both functions
>should be covered fully (i.e. including CCoA mode).  I believe that
>Vijay was OK with this except he wanted to explicitly state that replay
>protection is using nonce/timestamp.  But I don't see a need since this
>is fundamental function of Mobile IP itself.
>
>Kent
>  
>



-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 20:55:37 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei09B-0004i4-J1; Thu, 01 Dec 2005 20:55:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei09A-0004hL-2H
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 20:55:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17362
	for <mip4@ietf.org>; Thu, 1 Dec 2005 20:54:48 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0Tj-0000P7-O2
	for mip4@ietf.org; Thu, 01 Dec 2005 21:16:53 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB1NgID12986;
	Thu, 1 Dec 2005 15:42:18 -0800
X-mProtect: <200512012342> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14168.americas.nokia.com (172.18.141.68,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdOpcg6F; Thu, 01 Dec 2005 15:11:13 PST
Message-ID: <438F8A43.4030002@iprg.nokia.com>
Date: Thu, 01 Dec 2005 15:41:55 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kent Leung (kleung)" <kleung@cisco.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com>
In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: Madjid.Nakhjiri@motorola.com, mccap@lucent.com,
	Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>,
	henrik@levkowetz.com, itijibox-mip4@yahoo.com
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

Kent Leung (kleung) wrote:
> I vote for #2.  The reason is that that RFC 3012 is addressing two
> functions, as stated in previous emails (initiated by Gabe's review and
> comment to split this draft).
> 
> 1) FA challenge/authentication and MN-FA replay protection.  
> 
> 2) Generalized authentication (e.g. MN-AAA), which is independent if the
> NAS is FA or HA.
> 
> I would like to keep this in one draft, which means both functions
> should be covered fully (i.e. including CCoA mode). 

okay until this far.

> I believe that
> Vijay was OK with this except he wanted to explicitly state that replay
> protection is using nonce/timestamp.  But I don't see a need since this
> is fundamental function of Mobile IP itself.

it is needed because 3012 leaves things incomplete without
this. if you notice in my changes I did reference RFC 3344
when I spoke about replay protection in the co-located CoA
mode. I didnt propose a new mechanism.

Vijay


-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 20:57:19 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei0Ap-0006A8-Q5; Thu, 01 Dec 2005 20:57:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0Ao-0006A3-IS
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 20:57:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17509
	for <mip4@ietf.org>; Thu, 1 Dec 2005 20:56:30 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0VO-0000TD-5I
	for mip4@ietf.org; Thu, 01 Dec 2005 21:18:35 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB1NdLg11583;
	Thu, 1 Dec 2005 15:39:21 -0800
X-mProtect: <200512012339> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14168.americas.nokia.com (172.18.141.68,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdsCDcVT; Thu, 01 Dec 2005 15:08:47 PST
Message-ID: <438F89AF.4030609@iprg.nokia.com>
Date: Thu, 01 Dec 2005 15:39:27 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jayshree Bharatia <jayshree@nortel.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <E3F9D87C63E2774390FE67C924EC99BB0CE617A6@zrc2hxm1.corp.nortel.com>
In-Reply-To: <E3F9D87C63E2774390FE67C924EC99BB0CE617A6@zrc2hxm1.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: Madjid.Nakhjiri@motorola.com, mccap@lucent.com, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>, henrik@levkowetz.com,
	itijibox-mip4@yahoo.com
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

Jayshree Bharatia wrote:
> Hi all,
> 
> I am not sure how to proceed toward supporting co-located CoA mode in
> RFC3012bis. RFC3012 doesn't have any details on this and it was a
> working assumption that this draft is not applicable for co-located CoA
> mode.
> 
> Later in the process of updating RFC3012bis, there was a discussion that
> we shouldn't be limiting use of MN-AAA extension for co-located CoA
> mode. Anyway, we need to come up with some agreement now. The following
> is the summary of the discussion:
> - Kent and Madjid think that having clarification that there is no
> challenge included in the MN-AAA extension for co-located CoA mode is
> good. Although, there is no need of indicating what type of value is
> used for replay protection. Although, Vijay likes to see this to be
> clarified.
> - Charlie suggest removing support of co-located CoA mode.
> 
> Hence, I have three options:
> 1. Remove the paragraph which discusses co-located CoA support (last
> paragraph of section 3.1)
> 2. Make changes to indicate that there is no challenge included in the
> MN-CoA extension for co-located CoA mode.
> 3. Include changes proposed by Vijay in earlier email.

the changes I proposed include 2. the changes I suggested
do the following

- clarify that the MN MUST NOT include the challenge extension
- clarify that in the absence of the FA, there is no challenge
generated by the network.
- clarify that in the absence of a challenge, replay protection
is provided by the identification field.

Vijay


-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 21:13:21 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei0QL-0002oT-Rg; Thu, 01 Dec 2005 21:13:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0QK-0002oL-NC
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:13:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18790
	for <mip4@ietf.org>; Thu, 1 Dec 2005 21:12:32 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ei0ku-0000v3-83
	for mip4@ietf.org; Thu, 01 Dec 2005 21:34:37 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 01 Dec 2005 18:13:09 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB22CWe0019693;
	Thu, 1 Dec 2005 18:13:04 -0800 (PST)
Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 1 Dec 2005 18:13:02 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Thu, 1 Dec 2005 18:13:01 -0800
Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014B20@xmb-sjc-235.amer.cisco.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX2423Zt3knx2nZTTGVko45elB9PgAAZJVQ
From: "Kent Leung \(kleung\)" <kleung@cisco.com>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
X-OriginalArrivalTime: 02 Dec 2005 02:13:02.0812 (UTC)
	FILETIME=[ECA531C0:01C5F6E5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org
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

Hi Charlie.  Comments below.

>=20
> What if the draft allows the Generalized Authentication=20
> extension for mobile nodes with CCoA, but does not allow the=20
> challenge extension?  I don't see what's wrong with this,=20
> since the draft is "about" a foreign agent protocol.
>=20

But that means the Generalized Authentication is split into 2 separate
drafts (this one for FA CoA mode and a new draft for CCoA mode).  BTW, I
think this was proposed in the thread but not warmly received.


> Then, enabling the Generalized Authentication extension for=20
> co-located CoA just amounts to reasonable practice, not=20
> refocussing the document on colocated CoA.
>=20

I don't think adding a couple of sentences to specify that MFCE is not
needed in CCoA mode is refocussing this draft.

Kent


-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 21:18:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei0V2-0004X5-BE; Thu, 01 Dec 2005 21:18:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0V1-0004X0-99
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:18:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20025
	for <mip4@ietf.org>; Thu, 1 Dec 2005 21:17:23 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0pc-0001Lz-0f
	for mip4@ietf.org; Thu, 01 Dec 2005 21:39:28 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB21hOU30300;
	Thu, 1 Dec 2005 17:43:24 -0800
X-mProtect: <200512020143> Nokia Silicon Valley Messaging Protection
Received: from es-nira-26-125.europe.nokia.com (10.162.26.125,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdac1Ala; Thu, 01 Dec 2005 17:43:23 PST
Message-ID: <438FAEC3.4040306@iprg.nokia.com>
Date: Thu, 01 Dec 2005 18:17:39 -0800
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center, Mtn. View
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kent Leung (kleung)" <kleung@cisco.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <2979E38DD6FC6544B789C8DAD7BAFC5201014B20@xmb-sjc-235.amer.cisco.com>
In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014B20@xmb-sjc-235.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org
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

Kent Leung (kleung) wrote:

>>What if the draft allows the Generalized Authentication 
>>extension for mobile nodes with CCoA, but does not allow the 
>>challenge extension?  I don't see what's wrong with this, 
>>since the draft is "about" a foreign agent protocol.
>>
>>    
>>
>
>But that means the Generalized Authentication is split into 2 separate
>drafts (this one for FA CoA mode and a new draft for CCoA mode).  BTW, I
>think this was proposed in the thread but not warmly received.
>  
>
No, I think it's fine if the same draft mentions that the extension is
legitimate for use by mobile nodes with co-located CoA.

>I don't think adding a couple of sentences to specify that MFCE is not
>needed in CCoA mode is refocussing this draft.
>  
>
This is fine with me.  I guess you inferred that I am against mentioning
co-located CoA in this draft.  I am not against that, and I did not mean
to imply that.    I am only against specifying a way to use the challenge
extension with co-located CoA.

Regards,
Charlie P.



-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 21:29:53 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei0gL-0001KL-DG; Thu, 01 Dec 2005 21:29:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0gJ-0001Ih-1h
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:29:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23500
	for <mip4@ietf.org>; Thu, 1 Dec 2005 21:29:03 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ei10s-0002bn-8m
	for mip4@ietf.org; Thu, 01 Dec 2005 21:51:08 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-2.cisco.com with ESMTP; 01 Dec 2005 18:29:38 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB22SnwF011651;
	Thu, 1 Dec 2005 18:29:29 -0800 (PST)
Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 1 Dec 2005 18:28:46 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Thu, 1 Dec 2005 18:28:45 -0800
Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2A@xmb-sjc-235.amer.cisco.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX2474EawJ9IaZRSZaNRHzQ4GLcowAAlIwg
From: "Kent Leung \(kleung\)" <kleung@cisco.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Jayshree Bharatia" <jayshree@nortel.com>
X-OriginalArrivalTime: 02 Dec 2005 02:28:46.0955 (UTC)
	FILETIME=[1F65FBB0:01C5F6E8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: quoted-printable
Cc: Madjid.Nakhjiri@motorola.com, mccap@lucent.com, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>,
	henrik@levkowetz.com, itijibox-mip4@yahoo.com
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

Hi Vijay.
=20
> the changes I proposed include 2. the changes I suggested do=20
> the following
>=20
> - clarify that the MN MUST NOT include the challenge extension
> - clarify that in the absence of the FA, there is no=20
> challenge generated by the network.

Also, MN sets the challenge value to zero in the MN-AAA authenticator
computation. =20

> - clarify that in the absence of a challenge, replay=20
> protection is provided by the identification field.
>=20

I don't think this is necessary, but doesn't matter too much to me
either.

Kent

-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 21:30:39 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei0h5-0001kH-4F; Thu, 01 Dec 2005 21:30:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0h4-0001kC-1d
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:30:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23738
	for <mip4@ietf.org>; Thu, 1 Dec 2005 21:29:50 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei11d-0002h3-2c
	for mip4@ietf.org; Thu, 01 Dec 2005 21:51:55 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 01 Dec 2005 18:30:26 -0800
X-IronPort-AV: i="3.99,203,1131350400"; 
	d="scan'208"; a="236357549:sNHT27951236"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jB22TTcZ011404;
	Thu, 1 Dec 2005 18:30:24 -0800 (PST)
Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 1 Dec 2005 18:30:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Thu, 1 Dec 2005 18:30:00 -0800
Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2B@xmb-sjc-235.amer.cisco.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX25qy8aHzGeaU3SUKaOwOk7hLK7AAAXtMg
From: "Kent Leung \(kleung\)" <kleung@cisco.com>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
X-OriginalArrivalTime: 02 Dec 2005 02:30:01.0271 (UTC)
	FILETIME=[4BB1B470:01C5F6E8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: quoted-printable
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org
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

Oh, OK then. :)  We're in agreement that MFCE is not needed in CCoA
mode.

Kent

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]=20
> Sent: Thursday, December 01, 2005 6:18 PM
> To: Kent Leung (kleung)
> Cc: Jayshree Bharatia; mip4@ietf.org
> Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
>=20
> Kent Leung (kleung) wrote:
>=20
> >>What if the draft allows the Generalized Authentication=20
> extension for=20
> >>mobile nodes with CCoA, but does not allow the challenge=20
> extension?  I=20
> >>don't see what's wrong with this, since the draft is=20
> "about" a foreign=20
> >>agent protocol.
> >>
> >>   =20
> >>
> >
> >But that means the Generalized Authentication is split into=20
> 2 separate=20
> >drafts (this one for FA CoA mode and a new draft for CCoA=20
> mode).  BTW,=20
> >I think this was proposed in the thread but not warmly received.
> > =20
> >
> No, I think it's fine if the same draft mentions that the=20
> extension is legitimate for use by mobile nodes with co-located CoA.
>=20
> >I don't think adding a couple of sentences to specify that=20
> MFCE is not=20
> >needed in CCoA mode is refocussing this draft.
> > =20
> >
> This is fine with me.  I guess you inferred that I am against=20
> mentioning co-located CoA in this draft.  I am not against=20
> that, and I did not mean
> to imply that.    I am only against specifying a way to use=20
> the challenge
> extension with co-located CoA.
>=20
> Regards,
> Charlie P.
>=20

-- 
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/



From mip4-bounces@ietf.org Thu Dec 01 21:58:27 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei17z-0001Uq-6F; Thu, 01 Dec 2005 21:58:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei17w-0001Qv-P9
	for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:58:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28461
	for <mip4@ietf.org>; Thu, 1 Dec 2005 21:57:36 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei1SW-0004NO-Nu
	for mip4@ietf.org; Thu, 01 Dec 2005 22:19:42 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB22NaM21711;
	Thu, 1 Dec 2005 18:23:36 -0800
X-mProtect: <200512020223> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14168.americas.nokia.com (172.18.141.68,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdYoEaOh; Thu, 01 Dec 2005 18:23:34 PST
Message-ID: <438FB834.5030102@iprg.nokia.com>
Date: Thu, 01 Dec 2005 18:57:56 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kent Leung (kleung)" <kleung@cisco.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2A@xmb-sjc-235.amer.cisco.com>
In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2A@xmb-sjc-235.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>
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

Kent Leung (kleung) wrote:
> Hi Vijay.
>  
> 
>>the changes I proposed include 2. the changes I suggested do 
>>the following
>>
>>- clarify that the MN MUST NOT include the challenge extension
>>- clarify that in the absence of the FA, there is no 
>>challenge generated by the network.
> 
> 
> Also, MN sets the challenge value to zero in the MN-AAA authenticator
> computation.  

hmm.. how about the MN does not use any challenge value
(whether 0 or anything else)? it calculates the MN-AAA
authenticator without any challenge field. one the basic
clarifications that is needed is that there is no
challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay 
>>protection is provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me
> either.

well, folks inside Nokia who implement mobile nodes were
very confused by RFC 3012. it would be good to make this
explicit.

Vijay


-- 
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/



From mip4-bounces@ietf.org Fri Dec 02 01:18:16 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei4FM-0006wu-Rv; Fri, 02 Dec 2005 01:18:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4FL-0006wp-7W
	for mip4@megatron.ietf.org; Fri, 02 Dec 2005 01:18:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11899
	for <mip4@ietf.org>; Fri, 2 Dec 2005 01:17:28 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei4Zx-0001E1-Il
	for mip4@ietf.org; Fri, 02 Dec 2005 01:39:34 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 01 Dec 2005 22:18:06 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB26Hv77020799;
	Thu, 1 Dec 2005 22:18:02 -0800 (PST)
Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 1 Dec 2005 22:18:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Thu, 1 Dec 2005 22:17:59 -0800
Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014BBB@xmb-sjc-235.amer.cisco.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27EIopXqetqffRXqfU5TQdgBLXwAElxIg
From: "Kent Leung \(kleung\)" <kleung@cisco.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>
X-OriginalArrivalTime: 02 Dec 2005 06:18:01.0148 (UTC)
	FILETIME=[258947C0:01C5F708]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: quoted-printable
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>
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

The MN and RADIUS client (HA) needs to follow the rules for CHAP
authentication.

Section 3.1:

   If the SPI value is
   chosen as CHAP_SPI (see Section 9), then the mobile node specifies
   CHAP-style authentication [RFC1994] using MD5 [RFC1321].


Section 8:

   To compute the authenticator, apply MD5 [RFC1321] computed on the
   following data, in the order shown:

      High-order byte from Challenge || Key ||
      MD5(Preceding Mobile IP data ||
      Type, Subtype (if present), Length, SPI) ||
      Least-order 237 bytes from Challenge=20

When there is no MFCE, then HA needs to set the "Challenge" to 0 with
length of 1 (minimally) to populate the RADIUS CHAP-Password attribute
properly.  The CHAP ID is expected to be one byte for authenticator
computation.

So there is no need for MFCE because MN-FA replay protect is unnecessary
in CCoA mode, but the challenge value (i.e. zero) is still required to
properly perform CHAP authentication.

Did I miss your pt?

Kent


> >=20
> > Also, MN sets the challenge value to zero in the MN-AAA=20
> authenticator=20
> > computation.
>=20
> hmm.. how about the MN does not use any challenge value=20
> (whether 0 or anything else)? it calculates the MN-AAA=20
> authenticator without any challenge field. one the basic=20
> clarifications that is needed is that there is no challenge=20
> to use when there is no FA.
>=20

-- 
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/



From mip4-bounces@ietf.org Fri Dec 02 11:02:06 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EiDMM-00076L-Hp; Fri, 02 Dec 2005 11:02:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EiDMK-00075Y-LK
	for mip4@megatron.ietf.org; Fri, 02 Dec 2005 11:02:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10531
	for <mip4@ietf.org>; Fri, 2 Dec 2005 11:01:15 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiDh2-0004EY-Jz
	for mip4@ietf.org; Fri, 02 Dec 2005 11:23:28 -0500
Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id
	jB2G1nD4006503; Fri, 2 Dec 2005 10:01:49 -0600 (CST)
Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com
	(8.11.7p1+Sun/EMS-1.5 sol2)
	id jB2G1mx21247; Fri, 2 Dec 2005 10:01:48 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17296.28651.260505.760532@gargle.gargle.HOWL>
Date: Fri, 2 Dec 2005 10:01:47 -0600
From: Pete McCann <mccap@lucent.com>
To: "Kent Leung \(kleung\)" <kleung@cisco.com>
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com>
References: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com>
X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Content-Transfer-Encoding: 7bit
Cc: Madjid.Nakhjiri@motorola.com, Jayshree Bharatia <jayshree@nortel.com>,
	mip4@ietf.org, "Charles E. Perkins" <charliep@iprg.nokia.com>,
	vijayd@iprg.nokia.com, henrik@levkowetz.com, itijibox-mip4@yahoo.com
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


Chair hat off, I think there is clearly value in using MN-AAA
authenticator even in co-located mode, especially if one is trying to
bootstrap an HA for which no security association exists yet.  I
support Kent's and Vijay's suggested changes.

-Pete

Kent Leung \(kleung\) writes:
 > I vote for #2.  The reason is that that RFC 3012 is addressing two
 > functions, as stated in previous emails (initiated by Gabe's review and
 > comment to split this draft).
 > 
 > 1) FA challenge/authentication and MN-FA replay protection.  
 > 
 > 2) Generalized authentication (e.g. MN-AAA), which is independent if the
 > NAS is FA or HA.
 > 
 > I would like to keep this in one draft, which means both functions
 > should be covered fully (i.e. including CCoA mode).  I believe that
 > Vijay was OK with this except he wanted to explicitly state that replay
 > protection is using nonce/timestamp.  But I don't see a need since this
 > is fundamental function of Mobile IP itself.
 > 
 > Kent
 > 
 > > -----Original Message-----
 > > From: Jayshree Bharatia [mailto:jayshree@nortel.com] 
 > > Sent: Thursday, December 01, 2005 2:46 PM
 > > To: Charles E. Perkins; Kent Leung (kleung); 
 > > Madjid.Nakhjiri@motorola.com; vijayd@iprg.nokia.com
 > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com; mccap@lucent.com; 
 > > henrik@levkowetz.com
 > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
 > > 
 > > Hi all,
 > > 
 > > I am not sure how to proceed toward supporting co-located CoA 
 > > mode in RFC3012bis. RFC3012 doesn't have any details on this 
 > > and it was a working assumption that this draft is not 
 > > applicable for co-located CoA mode.
 > > 
 > > Later in the process of updating RFC3012bis, there was a 
 > > discussion that we shouldn't be limiting use of MN-AAA 
 > > extension for co-located CoA mode. Anyway, we need to come up 
 > > with some agreement now. The following is the summary of the 
 > > discussion:
 > > - Kent and Madjid think that having clarification that there 
 > > is no challenge included in the MN-AAA extension for 
 > > co-located CoA mode is good. Although, there is no need of 
 > > indicating what type of value is used for replay protection. 
 > > Although, Vijay likes to see this to be clarified.
 > > - Charlie suggest removing support of co-located CoA mode.
 > > 
 > > Hence, I have three options:
 > > 1. Remove the paragraph which discusses co-located CoA 
 > > support (last paragraph of section 3.1) 2. Make changes to 
 > > indicate that there is no challenge included in the MN-CoA 
 > > extension for co-located CoA mode.
 > > 3. Include changes proposed by Vijay in earlier email.
 > > 
 > > Please send me reply suggesting which option you prefer.
 > > 
 > > Regards,
 > > Jayshree
 > > 
 > > -----Original Message-----
 > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On 
 > > Behalf Of Charles E. Perkins
 > > Sent: Wednesday, November 30, 2005 7:05 PM
 > > To: Kent Leung (kleung)
 > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com
 > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
 > > 
 > > 
 > > 
 > > Hello folks,
 > > 
 > > I do not believe the document should support co-located CoA 
 > > mode.  The point is to enable some mechanism for use by the 
 > > foreign agent.  There is no need for a mobile node to use the 
 > > challenge.  No additional replay protection is afforded.
 > > 
 > > I would prefer for the use of the extension to be prohibited 
 > > whenever the 'D' bit is set.
 > > 
 > > Even when a foreign agent is sending 'R' bit advertisements, 
 > > there isn't any significant functionality gained.
 > > 
 > > Perhaps it's technically feasible to have the challenge in 
 > > such situations, but (i) it is wasteful and (ii) I would not 
 > > like to see it become considered a mandatory part of any 
 > > mobile node implementation where co-located care-of addresses 
 > > are used, for whatever reason.
 > > 
 > > Regards,
 > > Charlie P.
 > > 
 > > PS. Please excuse if I have overlooked some e-mail about this.
 > > 
 > > 
 > > Kent Leung (kleung) wrote:
 > > 
 > > >On this particular topic, I don't understand what is missing in the 
 > > >details to support the CCoA mode?  Since the draft covers MN-AAA 
 > > >authentication with NAS in between, I would like to see both 
 > > FA (CoA) 
 > > >and HA (CCoA) modes supported.  Where else would we be able to cover 
 > > >just the CCoA for MN-AAA authentication if not in this draft?
 > > >
 > > >Kent
 > > >
 > > >
 > > >  
 > > >
 > > >>not at this late stage. its fine as it is. however, I have 
 > > one comment 
 > > >>on the support for co-located CoA mode. the draft claims it 
 > > supports 
 > > >>it but there really isnt enough detail.
 > > >>IMO, it should be clarified that only FA mode is described in the 
 > > >>draft.
 > > >>
 > > >>    
 > > >>
 > > >
 > > >  
 > > >
 > > 
 > > 
 > > 
 > > --
 > > 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/
 > > 


-- 
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/



From mip4-bounces@ietf.org Fri Dec 02 12:18:39 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EiET6-0006WA-P8; Fri, 02 Dec 2005 12:13:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EiET4-0006UH-NP
	for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:13:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18788
	for <mip4@ietf.org>; Fri, 2 Dec 2005 12:12:19 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEnl-0006ml-SZ
	for mip4@ietf.org; Fri, 02 Dec 2005 12:34:30 -0500
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB2HPl3J022285
	for <mip4@ietf.org>; Fri, 2 Dec 2005 10:25:47 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB2HOQRK004961
	for <mip4@ietf.org>; Fri, 2 Dec 2005 11:24:26 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Fri, 2 Dec 2005 12:12:33 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479C54E4E@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX3Wd17JcalLaBUSSS/qozi3JhIVAACXqxQ
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Pete McCann" <mccap@lucent.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Content-Transfer-Encoding: quoted-printable
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>,
	vijayd@iprg.nokia.com, henrik@levkowetz.com, itijibox-mip4@yahoo.com
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

Yes, I agree. Otherwise not sure how we can do 3957 and 4004?
Given that the fix we proposed (replace the challenge value with 0 in
the authenticator calculation for direct RRQ), I think this RFC will get
a much bigger applicability with a small change.

Madjid=20

-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]=20
Sent: Friday, December 02, 2005 10:02 AM
To: Kent Leung (kleung)
Cc: Jayshree Bharatia; Charles E. Perkins; Nakhjiri Madjid-MNAKHJI1;
vijayd@iprg.nokia.com; mip4@ietf.org; itijibox-mip4@yahoo.com;
henrik@levkowetz.com
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Chair hat off, I think there is clearly value in using MN-AAA
authenticator even in co-located mode, especially if one is trying to
bootstrap an HA for which no security association exists yet.  I support
Kent's and Vijay's suggested changes.

-Pete

Kent Leung \(kleung\) writes:
 > I vote for #2.  The reason is that that RFC 3012 is addressing two  >
functions, as stated in previous emails (initiated by Gabe's review and
> comment to split this draft).
 >
 > 1) FA challenge/authentication and MN-FA replay protection. =20
 >
 > 2) Generalized authentication (e.g. MN-AAA), which is independent if
the  > NAS is FA or HA.
 >
 > I would like to keep this in one draft, which means both functions  >
should be covered fully (i.e. including CCoA mode).  I believe that  >
Vijay was OK with this except he wanted to explicitly state that replay
> protection is using nonce/timestamp.  But I don't see a need since
this  > is fundamental function of Mobile IP itself.
 >
 > Kent
 >
 > > -----Original Message-----
 > > From: Jayshree Bharatia [mailto:jayshree@nortel.com]  > > Sent:
Thursday, December 01, 2005 2:46 PM  > > To: Charles E. Perkins; Kent
Leung (kleung);  > > Madjid.Nakhjiri@motorola.com; vijayd@iprg.nokia.com
> > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com; mccap@lucent.com;  > >
henrik@levkowetz.com  > > Subject: RE: [Mip4] review:
draft-ietf-mip4-rfc3012bis-04.txt  > >  > > Hi all,  > >  > > I am not
sure how to proceed toward supporting co-located CoA  > > mode in
RFC3012bis. RFC3012 doesn't have any details on this  > > and it was a
working assumption that this draft is not  > > applicable for co-located
CoA mode.
 > >
 > > Later in the process of updating RFC3012bis, there was a  > >
discussion that we shouldn't be limiting use of MN-AAA  > > extension
for co-located CoA mode. Anyway, we need to come up  > > with some
agreement now. The following is the summary of the  > > discussion:
 > > - Kent and Madjid think that having clarification that there  > >
is no challenge included in the MN-AAA extension for  > > co-located CoA
mode is good. Although, there is no need of  > > indicating what type of
value is used for replay protection.=20
 > > Although, Vijay likes to see this to be clarified.
 > > - Charlie suggest removing support of co-located CoA mode.
 > >
 > > Hence, I have three options:
 > > 1. Remove the paragraph which discusses co-located CoA  > > support
(last paragraph of section 3.1) 2. Make changes to  > > indicate that
there is no challenge included in the MN-CoA  > > extension for
co-located CoA mode.
 > > 3. Include changes proposed by Vijay in earlier email.
 > >
 > > Please send me reply suggesting which option you prefer.
 > >
 > > Regards,
 > > Jayshree
 > >
 > > -----Original Message-----
 > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On  > >
Behalf Of Charles E. Perkins  > > Sent: Wednesday, November 30, 2005
7:05 PM  > > To: Kent Leung (kleung)  > > Cc: mip4@ietf.org;
itijibox-mip4@yahoo.com  > > Subject: Re: [Mip4] review:
draft-ietf-mip4-rfc3012bis-04.txt  > >  > >  > >  > > Hello folks,  > >
> > I do not believe the document should support co-located CoA  > >
mode.  The point is to enable some mechanism for use by the  > > foreign
agent.  There is no need for a mobile node to use the  > > challenge.
No additional replay protection is afforded.
 > >
 > > I would prefer for the use of the extension to be prohibited  > >
whenever the 'D' bit is set.
 > >
 > > Even when a foreign agent is sending 'R' bit advertisements,  > >
there isn't any significant functionality gained.
 > >
 > > Perhaps it's technically feasible to have the challenge in  > >
such situations, but (i) it is wasteful and (ii) I would not  > > like
to see it become considered a mandatory part of any  > > mobile node
implementation where co-located care-of addresses  > > are used, for
whatever reason.
 > >
 > > Regards,
 > > Charlie P.
 > >
 > > PS. Please excuse if I have overlooked some e-mail about this.
 > >
 > >
 > > Kent Leung (kleung) wrote:
 > >
 > > >On this particular topic, I don't understand what is missing in
the  > > >details to support the CCoA mode?  Since the draft covers
MN-AAA  > > >authentication with NAS in between, I would like to see
both  > > FA (CoA)  > > >and HA (CCoA) modes supported.  Where else
would we be able to cover  > > >just the CCoA for MN-AAA authentication
if not in this draft?
 > > >
 > > >Kent
 > > >
 > > >
 > > >
 > > >
 > > >>not at this late stage. its fine as it is. however, I have  > >
one comment  > > >>on the support for co-located CoA mode. the draft
claims it  > > supports  > > >>it but there really isnt enough detail.
 > > >>IMO, it should be clarified that only FA mode is described in the
> > >>draft.
 > > >>
 > > >>   =20
 > > >>
 > > >
 > > >
 > > >
 > >
 > >
 > >
 > > --
 > > 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/  > >=20


-- 
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/



From mip4-bounces@ietf.org Fri Dec 02 12:20:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EiEae-000192-7b; Fri, 02 Dec 2005 12:20:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEac-00018T-KI
	for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:20:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20481
	for <mip4@ietf.org>; Fri, 2 Dec 2005 12:20:07 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEvJ-0007PI-1e
	for mip4@ietf.org; Fri, 02 Dec 2005 12:42:19 -0500
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB2HXjkH023638
	for <mip4@ietf.org>; Fri, 2 Dec 2005 10:33:45 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id jB2HUgI9017855
	for <mip4@ietf.org>; Fri, 2 Dec 2005 11:30:42 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Fri, 2 Dec 2005 12:20:31 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479C54E58@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX2471MnExlPyePROW74Ap5pNY4EAAgI/cQ
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Jayshree Bharatia" <jayshree@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: quoted-printable
Cc: mccap@lucent.com, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>, henrik@levkowetz.com,
	itijibox-mip4@yahoo.com
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

I think the first 2 changes are pretty harmless. Even the third
probably, as long as we clarify that the challenge is only provided to
protect the foreign network, so in direct RRQ, you do not need the
challenge, not that ID field and challenge are two alternative replay
protections. ID protects HA, challenge protects FA..

Also the other change needed is the clarification of use of MN-AAA AE in
case of direct RRQ (challenge is absent).

Madjid

the changes I proposed include 2. the changes I suggested do the
following

- clarify that the MN MUST NOT include the challenge extension
- clarify that in the absence of the FA, there is no challenge generated
by the network.
- clarify that in the absence of a challenge, replay protection is
provided by the identification field.

Vijay


-- 
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/



From mip4-bounces@ietf.org Fri Dec 02 12:24:28 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EiEe3-0003gO-Py; Fri, 02 Dec 2005 12:24:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEe1-0003bh-En
	for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:24:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21203
	for <mip4@ietf.org>; Fri, 2 Dec 2005 12:23:37 -0500 (EST)
Received: from motgate7.mot.com ([129.188.136.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEyi-0007Zd-9D
	for mip4@ietf.org; Fri, 02 Dec 2005 12:45:49 -0500
Received: from az33exr01.mot.com ([10.64.251.231])
	by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id jB2Hn5tB001822
	for <mip4@ietf.org>; Fri, 2 Dec 2005 10:49:06 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id jB2HckQa019164
	for <mip4@ietf.org>; Fri, 2 Dec 2005 11:38:47 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Fri, 2 Dec 2005 12:24:00 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479C54E5F@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX25PfkkxdQ4p9iRn6yF1P8v7I46wAf+mSg
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: quoted-printable
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org
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

The point really is that a generalized extension is defined only for one
case, leaving treatment of CCOA underspecified. And yes, whether the
challenge extension is not allowed, or it includes 0s (pretty useless)
or whatever else needs to be specified somewhere.

Madjid

-----Original Message-----
From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of
Charles E. Perkins
Sent: Thursday, December 01, 2005 7:55 PM
To: Kent Leung (kleung)
Cc: Jayshree Bharatia; mip4@ietf.org
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Hello Kent,

What if the draft allows the Generalized Authentication extension for
mobile nodes with CCoA, but does not allow the challenge extension?  I
don't see what's wrong with this, since the draft is "about" a foreign
agent protocol.

Then, enabling the Generalized Authentication extension for co-located
CoA just amounts to reasonable practice, not refocussing the document on
colocated CoA.


Regards,
Charlie P.




Kent Leung (kleung) wrote:

>I vote for #2.  The reason is that that RFC 3012 is addressing two=20
>functions, as stated in previous emails (initiated by Gabe's review and

>comment to split this draft).
>
>1) FA challenge/authentication and MN-FA replay protection. =20
>
>2) Generalized authentication (e.g. MN-AAA), which is independent if=20
>the NAS is FA or HA.
>
>I would like to keep this in one draft, which means both functions=20
>should be covered fully (i.e. including CCoA mode).  I believe that=20
>Vijay was OK with this except he wanted to explicitly state that replay

>protection is using nonce/timestamp.  But I don't see a need since this

>is fundamental function of Mobile IP itself.
>
>Kent
> =20
>



--
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/

-- 
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/



From mip4-bounces@ietf.org Fri Dec 02 12:31:13 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EiEkb-0003gF-3M; Fri, 02 Dec 2005 12:31:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEkY-0003bV-Th
	for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:31:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22078
	for <mip4@ietf.org>; Fri, 2 Dec 2005 12:30:23 -0500 (EST)
Received: from motgate3.mot.com ([144.189.100.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiF5C-0007p5-AS
	for mip4@ietf.org; Fri, 02 Dec 2005 12:52:35 -0500
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
	by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id jB2Hm8lh020603
	for <mip4@ietf.org>; Fri, 2 Dec 2005 10:48:08 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jB2HdfS9014223
	for <mip4@ietf.org>; Fri, 2 Dec 2005 11:39:41 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Fri, 2 Dec 2005 12:30:40 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479C54E65@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8g
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>
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

Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :)
I believe 4004  for Diameter missed the problem with MN-AAA AE for
direct RRQs.
We tried to cover it in RADIUS-MIP draft, but I don't think that is the
right place for it. We suggested zero based on Charlie's initial
suggestion to make implementation of CoA and CCoA less complex, you have
the same field, you just enter zero when no value is available.

Madjid



> Also, MN sets the challenge value to zero in the MN-AAA authenticator=20
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay protection is=20
>>provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me=20
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay


--
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/

-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 13:58:44 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjLXw-00081r-KE; Mon, 05 Dec 2005 13:58:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLXu-00081l-Jv
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 13:58:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27073
	for <mip4@ietf.org>; Mon, 5 Dec 2005 13:57:51 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.ca.nortel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjLtE-0004u6-UA
	for mip4@ietf.org; Mon, 05 Dec 2005 14:20:45 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	jB5It6w19027
	for <mip4@ietf.org>; Mon, 5 Dec 2005 13:55:07 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Mon, 5 Dec 2005 12:58:19 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0CECB13C@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcW+f6H/b15Nd7TURcGqSZis+o4t5Q7QAmeA
From: "Jayshree Bharatia" <jayshree@nortel.com>
To: <itijibox-mip4@yahoo.com>
X-Spam-Score: 2.0 (++)
X-Scan-Signature: edafdfdf1a7c40feead31b1909b66c9e
Content-Transfer-Encoding: quoted-printable
Cc: mip4@ietf.org
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

Hi Gabriel,

My apology for not responding you earlier. I thought I took care of your
comments. Anyway, I have updated document with many of your comments.
Although, I have some clarification questions for few which are included
inline.

Thanks,
Jayshree=20

-----Original Message-----
From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of
gabriel montenegro
Sent: Wednesday, September 21, 2005 2:36 AM
To: mip4@ietf.org
Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


I reviewed this document. I feel it is not quite RFC quality, being a
bit confusing and verbose/repetitive in sections. A big issue=20
I have is that it is really two different things bunched together:
=09
- Challenge/Response extention
- Generalized Authentication Extension

They really should be two documents, specially cuz this is a revision,
the proper=20
opportunity to make such changes.
[JB] Based on earlier email from Henrik, I would think that WG decision
is not to split this draft at this time. So I haven't addressed this
comment.

I'm also wondering about the use of MD5 throughout. Given recent
developments, some folks (not unanimously, though) are already calling
for the deprecation of SHA-1, and here we are recommending MD5 for a
proposed standard? If this is what's being used today, then this could
be published as a historical or informational RFC,=20
If the intent is to fix a few bugs in rfc 3012, perhaps the errata page
is enough. But the use of MD5 should be reviewed by the security ADs.
CHAP should also be avoided, due to its vulnerability to dictionary
attacks. For example, EAP advices against its usage (see rfc3748 section
7.6). Even more explicitly, the EAP requirements for wireless usage call
for mandatory resistance to dictionary attacks:
http://www.faqs.org/rfcs/rfc4017.html, section 2.2.

This comment applies to 3344bis as well.
[JB] I am fine with having a review with security Ads on this topic.=20

Nit: saw "processing for" in several places. Shouldn't it be "processing
of"?=20
[JB] Done

Other comments interspersed below.

>=20
>=20
>=20
> Network Working Group                                 Charles E.
Perkins
> Internet-Draft                                     Nokia Research
Center
> Expires: December 19, 2005                                Pat R.
Calhoun
>                                                     Black Storm
Networks
>                                                       Jayshree.
Bharatia
>                                                          Nortel
Networks
>                                                            June 17,
> 2005

Please update the author contact information now, instead of waiting for
AUTH48.

...
> Abstract
>=20
...

>    Furthermore, this document updates RFC3344 by including new
>    authentication extension called the Mobile-AAA Authentication
>    extension.  This new extension is provided so that a mobile node
can
>    supply credentials for authorization using commonly available AAA
>    infrastructure elements.  This Authorization-enabling extension MAY
>    co-exist in the same Registration Request with Authentication
>    extensions defined for Mobile IP Registration by RFC3344.  This
>    document obsoletes RFC3012.

This should be a separate document.       =20

[JB] Should be covered by my earlier comment on WG decision of not
splitting the document.=20
...

> 1.  Introduction
>=20
>    Mobile IP defines the Mobile-Foreign Authentication extension to
>    allow a mobile node to authenticate itself to a foreign agent.
> Such

It can provide *mutual* authentication, right? Suggest making it
explicit here precisely because this extension differs in that it is
unilateral. It does not aid the MN in establishing legitimacy of the FA;
only the opposite is true.=20

[JB] MN-FA Authentication extension is defined by RFC3344 so I am not
sure adding clarification on that extension is necessary here. I would
think that purpose of having MN-AAA is clearly defined. If you have any
specific text change, please let me know and I will update the document.

>    authentication mechanisms are mostly external to the principal
>    operation of Mobile IP, since the foreign agent can easily route
>    packets to and from a mobile node whether or not the mobile node is
>    reporting a legitimately owned home address to the foreign agent.
>    Unfortunately, that extension does not provide the foreign agent
any
>    direct guarantee that the protocol is protected from replays, and
>    does not allow for the use of CHAP [RFC1994] for authenticating

See above comments on CHAP. Shouldn't be a motivation for a new PS
document.=20

[JB] As indicated in my earlier comment, I am ok with further review by
security ADs. ...
> 2.  Mobile IP Agent Advertisement Challenge Extension

The organization of this section (describing a format), followed by the
next section on operation, followed by other sections (4 and 5) on
packet formats is very confusing. Suggest having all the packet formats
bunched together, following each other.=20
Also suggest preceding them by some section on overview of operation
(perhaps section 3 itself.

...
[JB] I would rather not do restructuring at this stage, unless others
are having same issue and see value in doing so.
>=20
>    The Challenge extension, illustrated in Figure 1, is inserted in
the
>    Agent Advertisements by the foreign agent, in order to communicate
a
>    previously unused challenge value that can be used by the mobile
node
>    to compute an authentication for its next registration request
>    message.  The challenge is selected by the foreign agent to provide
>    local assurance that the mobile node is not replaying any earlier
>    registration request.  Eastlake, et al.  [RFC1750] provides more
>    information on generating pseudo-random numbers suitable for use as
>    values for the challenge.

Perhaps clarify that the transport of these is unicast.
[JB]Can you clarify your comment further? As mentioned in the draft,
Agent Advertisement can be multicast or unicast.=20

> 2.1  Handling of Solicited Agent Advertisements
...
>    advertised Challenges.  It must instead re-use the most recent of
the
>    CHALLENGE_WINDOW Advertisement Challenge values.

This is the first time this is mentioned, and it is not explained. It is

mentioned several times afterwards, but is never really explained until
the appendices. Explanation or at least a reference to the proper
section should accompany the first reference.=20

[JB] Done (provided reference of section 9)

> 3.  Operation
>=20
>    This section describes modifications to the Mobile IP registration
>    process [RFC3344] which may occur after the foreign agent issues a
>    Mobile IP Agent Advertisement containing the Challenge on its local

Given that Agent Advertisements can be multicast, I'd clarify here that
these are unicast.

...
[JB] This is true that Agent Advertisements can be multicast or unicast.
In section 2, we have explicit description on handling challenges in
case of multicast and unicast. So I am not sure why we need to mention
here that Agent Advertisement is going to be unicast only.

> 3.2  Foreign Agent Processing for Registration Requests

Perhaps s/for/of/ =20
E.g., 3344 uses "processing of" but never "processing for"
[JB] Done
>=20
>    Upon receipt of the Registration Request, if the foreign agent has
>    issued a Challenge as part of its Agent Advertisements, and it does

s/and it/and if it/
[JB] Done
...

>    unless the Registration Reply has already been
>    received from the home agent.  In this case the foreign agent MUST
>    preserve the value of the Code field set by the home agent and MUST
>    put its own rejection code only in the Status field of the FA Error
>    extension (defined in [FAERR]).

The above does not belong here, but in the next section (3.3) on
handling Registration Replies. [JB] Done s/code only in/code in/ [JB]
Done ...
>    with Code value FA_BAD_AAA_AUTH.  If the Mobile-AAA Authentication
>    Extension is present in the Registration Request, the foreign agent
>    MUST NOT remove the Mobile-AAA Authentication Extension and the
>    Mobile-Foreign Challenge Extension from the Registration Request.

s/Request./Request, before forwarding to the Home Agent./
[JB] Done

>    Appendix C provides an example of an action that could be taken by
a
>    foreign agent.
>=20
>    In the event that the Challenge extension is authenticated through
>    the Mobile-Foreign Authentication extension and the Mobile-AAA
>    Authentication extension is not present, the foreign agent MAY
remove
>    the Challenge Extension from the Registration Request without
>    disturbing the authentication value computed by the mobile node for
>    use by the AAA or the home agent.

Sometimes "Challenge extension" and sometimes "Challenge Extension"
Please double-check throughout to make sure capitalization is
consistent.=20

[JB] Done (changed to "Challenge extension"]

"use by the AAA" is confusing as it was just said that this case has no=20
AAA, so perhaps clarifying text could be added:

s/home agent./home agent, the former because it is not present, the
latter because its calculation does not include the Challenge Extension.

Or one could reword, of course...
[JB] I have reworded the above paragraph as:
"In the event that the Challenge extension is authenticated through the
Mobile-Foreign Authentication extension and the Mobile-AAA
Authentication extension is not present, the foreign agent MAY remove
the Challenge extension from the Registration Request without disturbing
the authentication value used for the computation."

...

>    If the foreign agent does not remove the Challenge extension, then
>    the foreign agent SHOULD store the Challenge value as part of the

notice the should here. But what if it's not stored? See below.

>    pending registration request list [RFC3344].  Also, if the
>    Registration Reply coming from the home agent does not include the
>    Challenge Extension, the foreign agent SHOULD NOT reject the
>    Registration Request message.  If the Challenge Extension is
present
>    in the Registration Reply, it MUST be the same Challenge value that
>    was included in the Registration Request.  If the Challenge value
>    differs in the Registration Reply received from the home agent, the
>    foreign agent MUST insert an FA Error extension with Status value
>    HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile
node
>    (see Section 10).

The above section does not belong here but in the next section on
Registration Replies. Mixing section contents like this makes things
very confusing.=20

[JB] Done

Above, notice the MUST be the same Challenge value. But if the value was
not stored (as allowed by the SHOULD above), then what happens? The
error recovery and error status value above does not take that into
account.

[JB] I am ok with your suggestion but I haven't made this change yet. I
need input from others with respect to backward compatibility if
"should" changes to "must".
=20
>    If the foreign agent does remove the Challenge extension and
>    applicable authentication from the Registration Request message,
then
>    it SHOULD insert the Identification field from the Registration

s/insert/store/
[JB] Done

>    Request message along with its record-keeping information about the

s/along with/as part of/
[JB] Done

>    particular mobile node in order to protect against replays.
>=20
> 3.3  Foreign Agent Processing for Registration Replies

s/for/of/
[JB] Done
...
>    If the foreign agent receives a Registration Reply with the Code
>    value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node.

Presumably, regardless of code value, the Reg Reply must be relayed,
yes? If so, why is this here? Suggest deleting the above as it is=20
redundant. In general, there seems to be a lot of repetition. One reads
them carefully expecting there to be an exception to a rule, but there
is none, so it's just tiring.

[JB] I have reworded as below to reflect that the error received in the
Registration Reply from the HA is relayed to the MN in the Registration
Reply. "If the foreign agent receives a Registration Reply with the Code
value HA_BAD_AAA_AUTH, the Registration Reply with this Code value MUST
be relayed to the mobile node."

> 3.4  Home Agent Processing for the Challenge Extensions
...

>    The home agent MAY receive a Registration Request with the
> Mobile-AAA

s/MAY/may/
JB] Done

Does not seem prescriptive but merely describing an eventuality, so I
don't think we need rfc 2026 language here.

> 3.5  Mobile Node Processing for Registration Replies
...
>    UNKNOWN_CHALLENGE: This error code is received by the mobile node
in
>    the case where the mobile node has moved to a new foreign agent
> that

s/in the case where the mobile node/if it/
[JB] As a part of Jari's comments, this text is removed.

>    MISSING_CHALLENGE: A mobile node that does not include a Challenge
>    when the Mobile-Foreign Authentication extension is present may
>    receive a MISSING_CHALLENGE error.  In this case, the mobile node
>    SHOULD send a Challenge extension containing an unused challenge in
>    the next Registration Request.
>=20
>    BAD_AUTHENTICATION: This error is sent by the foreign agent if the
>    Registration Request contains a Mobile-Foreign Authentication
>    extension with an incorrect authenticator that fails verification.
A
>    mobile node that receives a BAD_AUTHENTICATION Code value SHOULD
>    include the Mobile-AAA Authentication Extension in the next
>    Registration Request.  This will make it possible for the Foreign
>    Agent to use its AAA infrastructure in order to authenticate the
>    mobile node.  In this case, the mobile node MUST use a new
Challenge
>    value in any new registration, obtained either from an Agent
>    Advertisement, or from a Challenge extension to the Registration
>    Reply containing the error.
>=20
>    FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the
>    Registration Request contains a Mobile-AAA Authentication extension
>    with an incorrect authenticator that fails verification.  A mobile
>    node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value
>    in any new registration, obtained either from an Agent
Advertisement,
>    or from a Challenge extension to the Registration Reply containing
>    the error.
>=20
>    HA_BAD_AAA_AUTH: This error is sent by the home agent if the
>    Registration Request contains a Mobile-AAA Authentication extension
>    with an incorrect authenticator that fails verification.  A mobile

s/incorrect//
[JB] As a part of Jari's comments, this text is removed.

>    node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value
>    in any new registration, obtained either from an Agent
Advertisement,
>    or from a Challenge extension to the Registration Reply containing
>    the error.
>=20
>    STALE_CHALLENGE: If the foreign agent receives a Registration
Request
>    with a Challenge extension containing a Challenge value previously
>    used by that mobile node, the mobile node MAY receive a
> Registration

s/MAY/may/
[JB] As a part of Jari's comments, this text is removed.

>    Reply to the mobile node containing the Code value STALE_CHALLENGE.
>    In such instances, the mobile node MUST use a new Challenge value
in
>    next Registration Request, obtained either from an Agent
>    Advertisement, or from a Challenge extension to the Registration
>    Reply containing the error.
>=20
>    HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the
>    Registration Reply from the home agent contains a different
Challenge
>    value from the one included in the Registration Request.

s/the one/that/

Repetitiveness in the challenge rules was already taken care of by
Jari's comments, I believe.=20
 [JB] Yes. As a part of Jari's comments, this text is removed. ...

> 4.  Mobile-Foreign Challenge Extension
>=20
>    This section specifies a new Mobile IP Registration extension that
is
>    used to satisfy a Challenge in an Agent Advertisement.  The
Challenge
>    extension to the Registration Request message is used to indicate
the
>    challenge that the mobile node is attempting to satisfy.
>=20
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |          Challenge ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>              Figure 2: The Mobile-Foreign Challenge Extension
>=20
>       Type:
>=20
>          132 (skippable) (see [RFC3344])
>=20
>       Length:
>=20
>          Length of the Challenge value
>=20
>       Challenge:
>=20
>          The Challenge field is copied from the Challenge field found
in
>          the Agent Advertisement Challenge extension (see section 2).

s/Agent Advertisement/received/
Cuz Agent Advertisements are not the only way to learn a Challenge.=20
[JB] Done

> 5.  Generalized Mobile IP Authentication Extension

This really should be a separate document.

>    Several new authentication extensions have been designed for
various
>    control messages proposed for extensions to Mobile IP.  A new
>    authentication extension is required for a mobile node to present
its
>    credentials to any other entity other than the ones already
defined;
>    the only entities defined in the base Mobile IP specification
>    [RFC3344] are the home agent and the foreign agent.  It is the

s/It is/The/
[JB] Done

>    purpose of the generalized authentication extension defined here to

s/here to/here is to/
[JB] Done

...
> 6.  Mobile-AAA Authentication subtype
>=20
>    The Generalized Authentication extension with subtype 1 will be
>    referred to as a Mobile-AAA Authentication extension.  The mobile
>    node MAY include a Mobile-AAA Authentication extension in any
>    Registration Request.  This extension MAY co-exist in the same
>    Registration Request with Authentication extensions defined for
>    Mobile IP Registration by [RFC3344].  If the mobile node does not

s/by//
[JB] Done
>    include a Mobile-Foreign Authentication [RFC3344] extension, then
> it

s/[RFC3344]//
[JB] Done

>    MUST include the Mobile-AAA Authentication extension whenever the
>    Challenge extension is present.  If both are present, the
Mobile-AAA
>    Authentication extension MUST precede the Mobile-Foreign
>    Authentication extension.
>=20
>    If the Mobile-AAA Authentication extension is present, then the
>    Registration Message sent by the mobile node MUST contain the
Mobile-
>    Home Authentication extension [RFC3344] if it shares a security

notice this "if"

>    association with the home agent.  If both are present, the Mobile-

and this "if" as well.
This means that MN-HA Authentication is no longer a MUST, and that it
may be absent. I believe this is a departure from rfc 3344, and if so,
it should be flagged by explicitly saying so.=20
[JB] Agree. I have reworded the paragraph as below:

From:
If the Mobile-AAA Authentication extension is present, then the
Registration Message sent by the mobile node MUST contain the
Mobile-Home Authentication extension [RFC3344] if it shares a security
association with the home agent.  If both are present, the Mobile-Home
Authentication Extension MUST appear prior to the Mobile-AAA
Authentication extension.  The corresponding response MUST include the
Mobile-Home Authentication Extension, and MUST NOT include the
Mobile-AAA Authentication Extension.

To:
If the Mobile-AAA Authentication extension is present, the Mobile-Home
Authentication Extension MUST appear prior to the Mobile-AAA
Authentication extension.  The corresponding response MUST include the
Mobile-Home Authentication Extension, and MUST NOT include the
Mobile-AAA Authentication Extension.

...

> 8.  SPIs for RADIUS AAA Servers
>=20
>    Some AAA servers only admit a single security association, and thus
>    do not use the SPI numbers for Mobile IP authentication extensions
>    for use when determining the security association that would be
>    necessary for verifying the authentication information included
with
>    the Authentication extension.
>=20
>    SPI number CHAP_SPI (see Section 9) is reserved for indicating the
>    following procedure for computing authentication data (called the
>    "authenticator"), which is used by many RADIUS servers [RFC2138]
>    today.
>=20
>    To compute the authenticator, apply MD5 [RFC1321] computed on the
>    following data, in the order shown:
>=20
>       High-order byte from Challenge || Key ||
>=20
>       MD5(Preceding Mobile IP data ||
>=20
>       Type, Subtype (if present), Length, SPI) ||
>=20
>       Least-order 237 bytes from Challenge
>=20
>    where the Type, Length, SPI, and possibly Subtype, are the fields
of
>    the authentication extension in use.  For instance, all four of
these
>    fields would be in use when SPI =3D=3D CHAP_SPI is used with the
>    Generalized Authentication extension.  Since the RADIUS protocol
>    cannot carry attributes of length greater than 253, the preceding
>    Mobile IP data, type, subtype (if present), length and SPI are
hashed
>    using MD5.  Finally, the least significant 237 bytes of the
challenge
>    are concatenated.  If the challenge has fewer than 238 bytes, this
>    algorithm includes the high-order byte in the computation twice,
but
>    ensures that the challenge is used exactly as is.  Additional
padding
>    is never used to increase the length of the challenge; the input
data
>    is allowed to be shorter than 237 bytes long.

This draft starts by trying to help the FA, not the MN. so it should at
least do no harm to the MN.=20

But this is something that can end up screwing the MN. Any device within
RF coverage of both can see everything above (including the challenge),
except the password used in CHAP. Given the weakness to dictionary
attacks, an exchange like the above effectively blasts the user's
password to anybody who cares to listen. This shouldn't be recommended.
Or am I missing something?

...
[JB] We can reflect what security AD may be proposing for this issue.

> 9.  Configurable Parameters
>=20
>    Every Mobile IP agent supporting the extensions defined in this
>    document SHOULD be able to configure each parameter in the
following
>    table.  Each table entry contains the name of the parameter, the
>    default value, and the section of the document in which the
parameter
>    first appears.
>=20
>        +------------------+---------------+---------------------+
>        | Parameter Name   | Default Value | Section of Document |
>        +------------------+---------------+---------------------+
>        | CHALLENGE_WINDOW | 2             | 3.2                 |

This has never been explained! And the first time it's mentioned is
section 2.1. [JB] I have given reference to this section (section 9) in
section 2.1

>        |                  |               |                     |
>        | CHAP_SPI         | 2             | 8                   |

First time it's mentioned is section 3.1.
[JB] We already have reference to section 9 for CHAP_SPI.
...

> 10.  Error Values
>=20
>    Each entry in the following table contains the name of the Code
>    [RFC3344] to be returned in a Registration Reply, the value for the
>    Code, and the section in which the error is first mentioned in this
>    specification.

Why is the first time it's mentioned that important? What should be
referenced is the section in which it is properly explained (which=20
could be forward referenced from wherever it's mentioned for the=20
first time).
[JB] Done (removed "first" from the statement)
>=20
>        +--------------------+-------+--------------------------+
>        | Error Name         | Value | Section of Document      |
>        +--------------------+-------+--------------------------+
>        | UNKNOWN_CHALLENGE  | 104   | 3.2                      |
>        |                    |       |                          |
>        | BAD_AUTHENTICATION | 67    | 3.2 - also see [RFC3344] |
>        |                    |       |                          |
>        | MISSING_CHALLENGE  | 105   | 3.1, 3.2                 |
>        |                    |       |                          |
>        | STALE_CHALLENGE    | 106   | 3.2                      |
>        |                    |       |                          |
>        | FA_BAD_AAA_AUTH    | TBD   | 3.2                      |
>        |                    |       |                          |
>        | HA_BAD_AAA_AUTH    | TBD   | 3.4                      |
>        |                    |       |                          |
>        | HA_WRONG_CHALLENGE | TBD   | 3.2                      |
>        +--------------------+-------+--------------------------+
>=20
>                            Table 2: Error Values
>=20

Given the errors seen in the previous table, please double-check all the
above.

...
[JB] Done

> 12.  Security Considerations
>=20
>    In the event that a malicious mobile node attempts to replay the
>    authenticator for an old Mobile-Foreign Challenge, the foreign
agent
>    would detect it since the agent always checks whether it has
recently
>    advertised the Challenge (see Section 3.2).  Allowing mobile nodes
>    with different IP addresses or NAIs to use the same Challenge value
>    does not represent a security vulnerability, because the
>    authentication data provided by the mobile node will be computed
over
>    data that is different (at least by the bytes of the mobile nodes'
IP
>    addresses).

OLD:
     at least by the bytes of the mobile nodes' IP addresses

NEW:
     at least the mobile node's IP address will vary

[JB] Done
...


>    Section 8 (SPI For RADIUS AAA Servers) defines a method of
computing
>    the Generalized Mobile IP Authentication Extension's authenticator
>    field using MD5 in a manner that is consistent with RADIUS
[RFC2138].
>    The use of MD5 in the method described in Section 8 is less secure
>    than HMAC-MD5 [RFC2104], and should be avoided whenever possible.

s/should/MUST/
But really, this MUST be avoided always, unless there's other (e.g.,
link-layer
mechanisms) that can help prevent the dictionary attacks. I guess the
latter applies throughout to the other methods as well.=20

[JB] Done. I would think that "whenever possible" term will take care of
backward compatibility issue.

>    Note that an active attacker may try to prevent successful
>    registrations by sending a large number of Agent Solicitations or
>    bogus Registration Requests, each of which could cause the foreign
>    agent to respond with a fresh challenge, invalidating the challenge
>    that the MN is currently trying to use.  To prevent such attacks,
the
>    foreign agent MUST NOT invalidate previously unused challenges when
>    responding to unauthenticated Registration Requests or Agent
>    Solicitations.  In addition, the foreign agent MUST NOT allocate
new
>    storage when responding to such messages, because this would also
>    create the possibility of denial of service.

Should say that it does not seek to provide any assurance to the MN,
only to the FA and infrastructure.

[JB] I though it is implicit. Not sure we really need specific text
saying that. I am ok clarifying further if others have issue following
the intent.

...
> 14.  Normative References
>=20
>    [FAERR]    Perkins, C., "Foreign Agent Error Extension for Mobile
>               IPv4", draft-perkins-mip4-faerr-00.txt (work in
progress),
>               January 2004.

Update this reference to the latest version.
[JB] Done
...
> Authors' Addresses
...
>    Pat R. Calhoun
>    Black Storm Networks
>    110 Nortech Parkway
>    San Jose, CA  95134
>=20
>    Fax:   +1 720-293-7501
>    Email: pcalhoun@diameter.org

Update this info.
[JB] Done

> Appendix A.  Change History

I like Jari's suggestion to detail the changes with respect to 3012.
[JB] Done
...

> Appendix B.  Verification Infrastructure
...
>    In order to verify the credentials of the mobile node, we imagine

s/imagine/assume/
[JB] Done
...

> Appendix C.  Message Flow for FA Challenge Messaging with Mobile-AAA
>              Extension
...
>    1.  The foreign agent disseminates a Challenge Value in an Agent

s/disseminates/includes/=20
[JB] Done

s/an Agent/a unicast Agent/
[JB] Done
...

> Appendix E.  Foreign Agent Algorithm for Tracking Used Challenges

This section is normative, and is where we finally see the explanation
of how to use CHALLENGE_WINDOW. This should be in the body of the
document and must not remain in an appendix.

The appendix should only have the pseudo-code example.
[JB] I am waiting for further feedback from the WG on this comment and
hence haven't included it in the document.

--=20
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/


-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 15:30:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjMyk-0001zS-PE; Mon, 05 Dec 2005 15:30:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMyk-0001zA-17
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 15:30:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07048
	for <mip4@ietf.org>; Mon, 5 Dec 2005 15:29:38 -0500 (EST)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjNK4-00087Q-6S
	for mip4@ietf.org; Mon, 05 Dec 2005 15:52:34 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id jB5KU5m07586; Mon, 5 Dec 2005 15:30:06 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Mon, 5 Dec 2005 14:29:39 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0CECB3E3@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEA=
From: "Jayshree Bharatia" <jayshree@nortel.com>
To: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>,
	"Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: quoted-printable
Cc: mip4@ietf.org, "Charles E. Perkins" <charliep@iprg.nokia.com>
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

Hi all,

Thanks for all your comments. In summary, I see that we have now general
agreement that co-located CoA support for MN-AAA extension will be part
of this draft. In that respect, I am considering text proposed by Vijay
for section 3.1 and 3.5.=20

Currently we have text saying that the mechanism used by the mobile node
to obtain the Challenge value in this case is outside the scope of this
document. Based on the input from Kent and Madjid, the following is the
proposal (modified Vijay's proposal for section 3.5):

From:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344].

To:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
recommended for the authenticator calculation mentioned in section 8.

Please note that I haven't included Vijay's proposed text for a new
section (5) and also for Security Considerations since they are already
part of RFC3344.

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
think that is the right place for it. We suggested zero based on
Charlie's initial suggestion to make implementation of CoA and CCoA less
complex, you have the same field, you just enter zero when no value is
available.

Madjid



> Also, MN sets the challenge value to zero in the MN-AAA authenticator
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay protection is
>>provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay


--
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/


-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 16:22:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjNmb-0006V5-C3; Mon, 05 Dec 2005 16:22:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNmZ-0006SK-Id
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 16:21:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12368
	for <mip4@ietf.org>; Mon, 5 Dec 2005 16:21:09 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjO7w-0001Q6-A6
	for mip4@ietf.org; Mon, 05 Dec 2005 16:44:04 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5Kl1e22086;
	Mon, 5 Dec 2005 12:47:01 -0800
X-mProtect: <200512052047> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14168.americas.nokia.com (172.18.141.68,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdjWc5QX; Mon, 05 Dec 2005 12:46:58 PST
Message-ID: <4394AF58.8030300@iprg.nokia.com>
Date: Mon, 05 Dec 2005 13:21:28 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jayshree Bharatia <jayshree@nortel.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <E3F9D87C63E2774390FE67C924EC99BB0CECB3E3@zrc2hxm1.corp.nortel.com>
In-Reply-To: <E3F9D87C63E2774390FE67C924EC99BB0CECB3E3@zrc2hxm1.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: 7bit
Cc: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>
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

Jayshree Bharatia wrote:

> 
> Please note that I haven't included Vijay's proposed text for a new
> section (5) and also for Security Considerations since they are already
> part of RFC3344.

Jayshree, we need this text for completeness. if you notice,
the text I proposed does not specify anything new. it points
to RFC 3344. for example, when one reads 3012bis, they read
that replay protection is provided by the challenge. but for
the CCoA mode, one gets the impression that the replay
protection is not adequate. so we need to point out that the
replay protection is provided by the Identification field
and just refer to RFC 3344.

not trying to be difficult, but this improves 3012bis
readability.

Vijay

> 
> Regards,
> Jayshree
> 
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] 
> Sent: Friday, December 02, 2005 11:31 AM
> To: Vijay Devarapalli; Kent Leung (kleung)
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
> Perkins
> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
> 
> 
> Vijay,
> 
> However we want to do it, needs to be specified. Motorola development
> folks share Nokia's confusion:) I think only a handful of people in the
> industry know exactly how 3344, 3012, 3957, 4004 all work together and
> that is why the key bootstrapping is not getting any traction in the
> implementations. We have endless internal "educative" sessions on this
> too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
> for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
> think that is the right place for it. We suggested zero based on
> Charlie's initial suggestion to make implementation of CoA and CCoA less
> complex, you have the same field, you just enter zero when no value is
> available.
> 
> Madjid
> 
> 
> 
> 
>>Also, MN sets the challenge value to zero in the MN-AAA authenticator
>>computation.
> 
> 
> hmm.. how about the MN does not use any challenge value (whether 0 or
> anything else)? it calculates the MN-AAA authenticator without any
> challenge field. one the basic clarifications that is needed is that
> there is no challenge to use when there is no FA.
> 
> 
>>>- clarify that in the absence of a challenge, replay protection is
>>>provided by the identification field.
>>>
>>
>>I don't think this is necessary, but doesn't matter too much to me
>>either.
> 
> 
> well, folks inside Nokia who implement mobile nodes were very confused
> by RFC 3012. it would be good to make this explicit.
> 
> Vijay
> 
> 
> --
> 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/
> 



-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 16:27:49 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjNsD-0008G2-Ak; Mon, 05 Dec 2005 16:27:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNsB-0008Fu-P6
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 16:27:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12851
	for <mip4@ietf.org>; Mon, 5 Dec 2005 16:26:58 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjODX-0001ce-NH
	for mip4@ietf.org; Mon, 05 Dec 2005 16:49:53 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5Kqiu24473;
	Mon, 5 Dec 2005 12:52:44 -0800
X-mProtect: <200512052052> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14168.americas.nokia.com (172.18.141.68,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdvit56h; Mon, 05 Dec 2005 12:52:43 PST
Message-ID: <4394B0B1.3000700@iprg.nokia.com>
Date: Mon, 05 Dec 2005 13:27:13 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <C7ED80CD916C5B4F8069B486F5DC5479C54E65@de01exm70.ds.mot.com>
In-Reply-To: <C7ED80CD916C5B4F8069B486F5DC5479C54E65@de01exm70.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: "Kent Leung \(kleung\)" <kleung@cisco.com>,
	Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>
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

Nakhjiri Madjid-MNAKHJI1 wrote:
> Vijay,
> 
> However we want to do it, needs to be specified. Motorola development
> folks share Nokia's confusion:) I think only a handful of people in the
> industry know exactly how 3344, 3012, 3957, 4004 all work together and
> that is why the key bootstrapping is not getting any traction in the
> implementations. We have endless internal "educative" sessions on this
> too :)
> I believe 4004  for Diameter missed the problem with MN-AAA AE for
> direct RRQs.
> We tried to cover it in RADIUS-MIP draft, but I don't think that is the
> right place for it. We suggested zero based on Charlie's initial
> suggestion to make implementation of CoA and CCoA less complex, you have
> the same field, you just enter zero when no value is available.

then we need one more clarification. if the SPI is set to
CHAP_SPI and the mobile node is using co-located CoA mode,
it sets the challenge to 0. if the SPI is something else,
the mobile node leaves out the challenge while calculating
the authenticator field.

agreed? please excuse me if this sounds obvious to you. :)

Vijay


-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 16:28:28 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjNsq-0008TN-PX; Mon, 05 Dec 2005 16:28:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNsp-0008TH-FO
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 16:28:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12929
	for <mip4@ietf.org>; Mon, 5 Dec 2005 16:27:37 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjOEB-0001eO-81
	for mip4@ietf.org; Mon, 05 Dec 2005 16:50:32 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5KrUg25361;
	Mon, 5 Dec 2005 12:53:30 -0800
X-mProtect: <200512052053> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14168.americas.nokia.com (172.18.141.68,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdQpI2Qw; Mon, 05 Dec 2005 12:53:28 PST
Message-ID: <4394B0DE.6000309@iprg.nokia.com>
Date: Mon, 05 Dec 2005 13:27:58 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kent Leung (kleung)" <kleung@cisco.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <2979E38DD6FC6544B789C8DAD7BAFC5201014BBB@xmb-sjc-235.amer.cisco.com>
In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014BBB@xmb-sjc-235.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>
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

agreed. if the SPI is set to CHAP_SPI then we need to
use a challenge set to 0.

Vijay

Kent Leung (kleung) wrote:
> The MN and RADIUS client (HA) needs to follow the rules for CHAP
> authentication.
> 
> Section 3.1:
> 
>    If the SPI value is
>    chosen as CHAP_SPI (see Section 9), then the mobile node specifies
>    CHAP-style authentication [RFC1994] using MD5 [RFC1321].
> 
> 
> Section 8:
> 
>    To compute the authenticator, apply MD5 [RFC1321] computed on the
>    following data, in the order shown:
> 
>       High-order byte from Challenge || Key ||
>       MD5(Preceding Mobile IP data ||
>       Type, Subtype (if present), Length, SPI) ||
>       Least-order 237 bytes from Challenge 
> 
> When there is no MFCE, then HA needs to set the "Challenge" to 0 with
> length of 1 (minimally) to populate the RADIUS CHAP-Password attribute
> properly.  The CHAP ID is expected to be one byte for authenticator
> computation.
> 
> So there is no need for MFCE because MN-FA replay protect is unnecessary
> in CCoA mode, but the challenge value (i.e. zero) is still required to
> properly perform CHAP authentication.
> 
> Did I miss your pt?
> 
> Kent
> 
> 
> 
>>>Also, MN sets the challenge value to zero in the MN-AAA 
>>
>>authenticator 
>>
>>>computation.
>>
>>hmm.. how about the MN does not use any challenge value 
>>(whether 0 or anything else)? it calculates the MN-AAA 
>>authenticator without any challenge field. one the basic 
>>clarifications that is needed is that there is no challenge 
>>to use when there is no FA.
>>



-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 18:17:17 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjPa9-0004LQ-BP; Mon, 05 Dec 2005 18:17:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPa8-0004LI-Ae
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 18:17:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29315
	for <mip4@ietf.org>; Mon, 5 Dec 2005 18:16:26 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjPvU-0006te-5g
	for mip4@ietf.org; Mon, 05 Dec 2005 18:39:22 -0500
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB5NU851027539
	for <mip4@ietf.org>; Mon, 5 Dec 2005 16:30:08 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB5NSoxH009570
	for <mip4@ietf.org>; Mon, 5 Dec 2005 17:28:50 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Mon, 5 Dec 2005 18:16:41 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479DDF167@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX54rPwOOS1qmX1Tfeu8REcniPSMQADqS2Q
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Vijay Devarapalli" <vijayd@iprg.nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable
Cc: "Kent Leung \(kleung\)" <kleung@cisco.com>,
	Jayshree Bharatia <jayshree@nortel.com>, mip4@ietf.org,
	"Charles E. Perkins" <charliep@iprg.nokia.com>
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

 Hi Vijay,

Agreed, however remember that SPI=3DCHAP-SPI and the authenticator using
the challenge value is defined under section "8: SPIs for RADIUS AAA
Servers"
So your addition should go there.

Not sure what the document recommends for Diameter, probably nothing.
For Diameter, 4004 uses MIP-MN-AAA-SPI AVP which is different from CHAP
SPI, not sure how they handle it.

Madjid

-----Original Message-----
From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20
Sent: Monday, December 05, 2005 3:27 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Kent Leung (kleung); Jayshree Bharatia; mip4@ietf.org; Charles E.
Perkins
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Nakhjiri Madjid-MNAKHJI1 wrote:
> Vijay,
>=20
> However we want to do it, needs to be specified. Motorola development=20
> folks share Nokia's confusion:) I think only a handful of people in=20
> the industry know exactly how 3344, 3012, 3957, 4004 all work together

> and that is why the key bootstrapping is not getting any traction in=20
> the implementations. We have endless internal "educative" sessions on=20
> this too :) I believe 4004  for Diameter missed the problem with=20
> MN-AAA AE for direct RRQs.
> We tried to cover it in RADIUS-MIP draft, but I don't think that is=20
> the right place for it. We suggested zero based on Charlie's initial=20
> suggestion to make implementation of CoA and CCoA less complex, you=20
> have the same field, you just enter zero when no value is available.

then we need one more clarification. if the SPI is set to CHAP_SPI and
the mobile node is using co-located CoA mode, it sets the challenge to
0. if the SPI is something else, the mobile node leaves out the
challenge while calculating the authenticator field.

agreed? please excuse me if this sounds obvious to you. :)

Vijay


-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 18:42:18 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjPyM-0003UO-1Y; Mon, 05 Dec 2005 18:42:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPyK-0003UH-JS
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 18:42:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01669
	for <mip4@ietf.org>; Mon, 5 Dec 2005 18:41:26 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQJh-0007eS-KA
	for mip4@ietf.org; Mon, 05 Dec 2005 19:04:23 -0500
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB5NtExO000575
	for <mip4@ietf.org>; Mon, 5 Dec 2005 16:55:14 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id jB5Nri66011857
	for <mip4@ietf.org>; Mon, 5 Dec 2005 17:53:44 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Mon, 5 Dec 2005 18:41:47 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479DDF17F@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcA==
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Jayshree Bharatia" <jayshree@nortel.com>,
	"Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Content-Transfer-Encoding: quoted-printable
Cc: mip4@ietf.org, "Charles E. Perkins" <charliep@iprg.nokia.com>
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

Jayshree,=20

Appreciate for the effort on gaining consensus.
I don't have a strong position either way, the text is now complete.
I sort of agree with Vijay that you might want to add that "In CCoA,
replay protection is provided through methods specified in 3344
(Identification field in RRQ)", this is just to keep people from
wondering...
I am fine with either way consensus goes on this one.

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

Thanks for all your comments. In summary, I see that we have now general
agreement that co-located CoA support for MN-AAA extension will be part
of this draft. In that respect, I am considering text proposed by Vijay
for section 3.1 and 3.5.=20

Currently we have text saying that the mechanism used by the mobile node
to obtain the Challenge value in this case is outside the scope of this
document. Based on the input from Kent and Madjid, the following is the
proposal (modified Vijay's proposal for section 3.5):

From:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344].

To:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
recommended for the authenticator calculation mentioned in section 8.

Please note that I haven't included Vijay's proposed text for a new
section (5) and also for Security Considerations since they are already
part of RFC3344.

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
think that is the right place for it. We suggested zero based on
Charlie's initial suggestion to make implementation of CoA and CCoA less
complex, you have the same field, you just enter zero when no value is
available.

Madjid



> Also, MN sets the challenge value to zero in the MN-AAA authenticator
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay protection is
>>provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay


--
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/


-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 18:56:54 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjQCU-0007Za-BG; Mon, 05 Dec 2005 18:56:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQCS-0007ZH-Qr
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 18:56:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02970
	for <mip4@ietf.org>; Mon, 5 Dec 2005 18:56:02 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.ca.nortel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQXp-00082g-QH
	for mip4@ietf.org; Mon, 05 Dec 2005 19:18:59 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	jB5NrHw23828; Mon, 5 Dec 2005 18:53:18 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Mon, 5 Dec 2005 17:56:30 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0CF5D279@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPg
From: "Jayshree Bharatia" <jayshree@nortel.com>
To: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>,
	"Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Content-Transfer-Encoding: quoted-printable
Cc: mip4@ietf.org, "Charles E. Perkins" <charliep@iprg.nokia.com>
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

Hi Madjid,

OK. In this case, I will include his text in section 3.1 (Mobile Node
processing of Registration Requests) rather than having a new section as
he suggested. I will also include his proposed text for "Security
Considerations" section.

Thanks,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20
Sent: Monday, December 05, 2005 5:42 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Jayshree,=20

Appreciate for the effort on gaining consensus.
I don't have a strong position either way, the text is now complete. I
sort of agree with Vijay that you might want to add that "In CCoA,
replay protection is provided through methods specified in 3344
(Identification field in RRQ)", this is just to keep people from
wondering... I am fine with either way consensus goes on this one.

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

Thanks for all your comments. In summary, I see that we have now general
agreement that co-located CoA support for MN-AAA extension will be part
of this draft. In that respect, I am considering text proposed by Vijay
for section 3.1 and 3.5.=20

Currently we have text saying that the mechanism used by the mobile node
to obtain the Challenge value in this case is outside the scope of this
document. Based on the input from Kent and Madjid, the following is the
proposal (modified Vijay's proposal for section 3.5):

From:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344].

To:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
recommended for the authenticator calculation mentioned in section 8.

Please note that I haven't included Vijay's proposed text for a new
section (5) and also for Security Considerations since they are already
part of RFC3344.

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
think that is the right place for it. We suggested zero based on
Charlie's initial suggestion to make implementation of CoA and CCoA less
complex, you have the same field, you just enter zero when no value is
available.

Madjid



> Also, MN sets the challenge value to zero in the MN-AAA authenticator=20
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay protection is=20
>>provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me=20
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay


--
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/



-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 19:04:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjQJN-0001MV-6M; Mon, 05 Dec 2005 19:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQJL-0001MG-9Q
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 19:04:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03726
	for <mip4@ietf.org>; Mon, 5 Dec 2005 19:03:08 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQei-0008JK-I2
	for mip4@ietf.org; Mon, 05 Dec 2005 19:26:06 -0500
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB60GuBj003737
	for <mip4@ietf.org>; Mon, 5 Dec 2005 17:16:56 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB60FclA024674
	for <mip4@ietf.org>; Mon, 5 Dec 2005 18:15:38 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Mon, 5 Dec 2005 19:03:29 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479DDF18D@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPgAACiwEA=
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Jayshree Bharatia" <jayshree@nortel.com>,
	"Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Content-Transfer-Encoding: quoted-printable
Cc: mip4@ietf.org, "Charles E. Perkins" <charliep@iprg.nokia.com>
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

Hi Jayshree,

Please note that this also impacts section 8 on use of CHAP SPI for
RADIUS server, as I mentioned in a previous email.

Regards,

Madjid=20

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 5:57 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

OK. In this case, I will include his text in section 3.1 (Mobile Node
processing of Registration Requests) rather than having a new section as
he suggested. I will also include his proposed text for "Security
Considerations" section.

Thanks,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Monday, December 05, 2005 5:42 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Jayshree,=20

Appreciate for the effort on gaining consensus.
I don't have a strong position either way, the text is now complete. I
sort of agree with Vijay that you might want to add that "In CCoA,
replay protection is provided through methods specified in 3344
(Identification field in RRQ)", this is just to keep people from
wondering... I am fine with either way consensus goes on this one.

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

Thanks for all your comments. In summary, I see that we have now general
agreement that co-located CoA support for MN-AAA extension will be part
of this draft. In that respect, I am considering text proposed by Vijay
for section 3.1 and 3.5.=20

Currently we have text saying that the mechanism used by the mobile node
to obtain the Challenge value in this case is outside the scope of this
document. Based on the input from Kent and Madjid, the following is the
proposal (modified Vijay's proposal for section 3.5):

From:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344].

To:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
recommended for the authenticator calculation mentioned in section 8.

Please note that I haven't included Vijay's proposed text for a new
section (5) and also for Security Considerations since they are already
part of RFC3344.

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
think that is the right place for it. We suggested zero based on
Charlie's initial suggestion to make implementation of CoA and CCoA less
complex, you have the same field, you just enter zero when no value is
available.

Madjid



> Also, MN sets the challenge value to zero in the MN-AAA authenticator=20
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay protection is=20
>>provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me=20
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay


--
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/



-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 19:07:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjQMk-0002LT-K4; Mon, 05 Dec 2005 19:07:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQMj-0002LJ-48
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 19:07:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04020
	for <mip4@ietf.org>; Mon, 5 Dec 2005 19:06:38 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQi6-0008Sa-Bw
	for mip4@ietf.org; Mon, 05 Dec 2005 19:29:35 -0500
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5NWVb15074;
	Mon, 5 Dec 2005 15:32:31 -0800
X-mProtect: <200512052332> Nokia Silicon Valley Messaging Protection
Received: from danira-pool05389.americas.nokia.com (10.241.53.89,
	claiming to be "[127.0.0.1]")
	by darkstar.iprg.nokia.com smtpdINgzYf; Mon, 05 Dec 2005 15:32:30 PST
Message-ID: <4394D61A.5000303@iprg.nokia.com>
Date: Mon, 05 Dec 2005 16:06:50 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jayshree Bharatia <jayshree@nortel.com>
Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
References: <E3F9D87C63E2774390FE67C924EC99BB0CF5D279@zrc2hxm1.corp.nortel.com>
In-Reply-To: <E3F9D87C63E2774390FE67C924EC99BB0CF5D279@zrc2hxm1.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: 7bit
Cc: mip4@ietf.org
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

thanks.

Vijay

Jayshree Bharatia wrote:
> Hi Madjid,
> 
> OK. In this case, I will include his text in section 3.1 (Mobile Node
> processing of Registration Requests) rather than having a new section as
> he suggested. I will also include his proposed text for "Security
> Considerations" section.
> 
> Thanks,
> Jayshree
> 
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] 
> Sent: Monday, December 05, 2005 5:42 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
> (kleung)
> Cc: mip4@ietf.org; Charles E. Perkins
> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
> 
> 
> Jayshree, 
> 
> Appreciate for the effort on gaining consensus.
> I don't have a strong position either way, the text is now complete. I
> sort of agree with Vijay that you might want to add that "In CCoA,
> replay protection is provided through methods specified in 3344
> (Identification field in RRQ)", this is just to keep people from
> wondering... I am fine with either way consensus goes on this one.
> 
> Madjid
> 
> -----Original Message-----
> From: Jayshree Bharatia [mailto:jayshree@nortel.com] 
> Sent: Monday, December 05, 2005 2:30 PM
> To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
> Cc: mip4@ietf.org; Charles E. Perkins
> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
> 
> Hi all,
> 
> Thanks for all your comments. In summary, I see that we have now general
> agreement that co-located CoA support for MN-AAA extension will be part
> of this draft. In that respect, I am considering text proposed by Vijay
> for section 3.1 and 3.5. 
> 
> Currently we have text saying that the mechanism used by the mobile node
> to obtain the Challenge value in this case is outside the scope of this
> document. Based on the input from Kent and Madjid, the following is the
> proposal (modified Vijay's proposal for section 3.5):
> 
> From:
> In the co-located CoA mode, the mobile node will receive a Registration
> Reply without the Challenge Extension and processes the Registration
> Reply as specified in [RFC3344].
> 
> To:
> In the co-located CoA mode, the mobile node will receive a Registration
> Reply without the Challenge Extension and processes the Registration
> Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
> recommended for the authenticator calculation mentioned in section 8.
> 
> Please note that I haven't included Vijay's proposed text for a new
> section (5) and also for Security Considerations since they are already
> part of RFC3344.
> 
> Regards,
> Jayshree
> 
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Friday, December 02, 2005 11:31 AM
> To: Vijay Devarapalli; Kent Leung (kleung)
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
> Perkins
> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
> 
> 
> Vijay,
> 
> However we want to do it, needs to be specified. Motorola development
> folks share Nokia's confusion:) I think only a handful of people in the
> industry know exactly how 3344, 3012, 3957, 4004 all work together and
> that is why the key bootstrapping is not getting any traction in the
> implementations. We have endless internal "educative" sessions on this
> too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
> for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
> think that is the right place for it. We suggested zero based on
> Charlie's initial suggestion to make implementation of CoA and CCoA less
> complex, you have the same field, you just enter zero when no value is
> available.
> 
> Madjid
> 
> 
> 
> 
>>Also, MN sets the challenge value to zero in the MN-AAA authenticator 
>>computation.
> 
> 
> hmm.. how about the MN does not use any challenge value (whether 0 or
> anything else)? it calculates the MN-AAA authenticator without any
> challenge field. one the basic clarifications that is needed is that
> there is no challenge to use when there is no FA.
> 
> 
>>>- clarify that in the absence of a challenge, replay protection is 
>>>provided by the identification field.
>>>
>>
>>I don't think this is necessary, but doesn't matter too much to me 
>>either.
> 
> 
> well, folks inside Nokia who implement mobile nodes were very confused
> by RFC 3012. it would be good to make this explicit.
> 
> Vijay
> 
> 
> --
> 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/
> 
> 



-- 
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/



From mip4-bounces@ietf.org Mon Dec 05 19:11:04 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjQQC-0003mR-F2; Mon, 05 Dec 2005 19:11:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQQB-0003mM-At
	for mip4@megatron.ietf.org; Mon, 05 Dec 2005 19:11:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04496
	for <mip4@ietf.org>; Mon, 5 Dec 2005 19:10:12 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQlZ-0000Ak-5S
	for mip4@ietf.org; Mon, 05 Dec 2005 19:33:09 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id jB60AeZ21419; Mon, 5 Dec 2005 19:10:40 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Mon, 5 Dec 2005 18:10:20 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0CF5D292@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPgAACiwEAAAAXbEA==
From: "Jayshree Bharatia" <jayshree@nortel.com>
To: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>,
	"Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Content-Transfer-Encoding: quoted-printable
Cc: mip4@ietf.org, "Charles E. Perkins" <charliep@iprg.nokia.com>
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

Hi Madjid,

I have covered this part in the modified text for section 3.4 I sent
earlier today. Please check that and see if you like to add or modify.=20

In short, most of Vijay's proposal is going in. But I have slightly
modified text for section 3.5 to include value of challenge for
authenticator computation in section 8. Also, instead of new section, I
will include his proposed text to section 3.1.=20

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20
Sent: Monday, December 05, 2005 6:03 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Hi Jayshree,

Please note that this also impacts section 8 on use of CHAP SPI for
RADIUS server, as I mentioned in a previous email.

Regards,

Madjid=20

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 5:57 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

OK. In this case, I will include his text in section 3.1 (Mobile Node
processing of Registration Requests) rather than having a new section as
he suggested. I will also include his proposed text for "Security
Considerations" section.

Thanks,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Monday, December 05, 2005 5:42 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Jayshree,=20

Appreciate for the effort on gaining consensus.
I don't have a strong position either way, the text is now complete. I
sort of agree with Vijay that you might want to add that "In CCoA,
replay protection is provided through methods specified in 3344
(Identification field in RRQ)", this is just to keep people from
wondering... I am fine with either way consensus goes on this one.

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

Thanks for all your comments. In summary, I see that we have now general
agreement that co-located CoA support for MN-AAA extension will be part
of this draft. In that respect, I am considering text proposed by Vijay
for section 3.1 and 3.5.=20

Currently we have text saying that the mechanism used by the mobile node
to obtain the Challenge value in this case is outside the scope of this
document. Based on the input from Kent and Madjid, the following is the
proposal (modified Vijay's proposal for section 3.5):

From:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344].

To:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
recommended for the authenticator calculation mentioned in section 8.

Please note that I haven't included Vijay's proposed text for a new
section (5) and also for Security Considerations since they are already
part of RFC3344.

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
think that is the right place for it. We suggested zero based on
Charlie's initial suggestion to make implementation of CoA and CCoA less
complex, you have the same field, you just enter zero when no value is
available.

Madjid



> Also, MN sets the challenge value to zero in the MN-AAA authenticator
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay protection is
>>provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay


--
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/




-- 
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/



From mip4-bounces@ietf.org Thu Dec 08 15:57:53 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkSpt-0008VM-1T; Thu, 08 Dec 2005 15:57:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSpr-0008V8-Kl
	for mip4@megatron.ietf.org; Thu, 08 Dec 2005 15:57:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10164
	for <mip4@ietf.org>; Thu, 8 Dec 2005 15:56:53 -0500 (EST)
Received: from motgate3.mot.com ([144.189.100.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSpp-00014t-QC
	for mip4@ietf.org; Thu, 08 Dec 2005 15:57:50 -0500
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233])
	by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id jB8LErTV022863
	for <mip4@ietf.org>; Thu, 8 Dec 2005 14:14:53 -0700 (MST)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26])
	by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB8L8bof022907
	for <mip4@ietf.org>; Thu, 8 Dec 2005 15:08:37 -0600 (CST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Date: Thu, 8 Dec 2005 15:57:00 -0500
Message-ID: <C7ED80CD916C5B4F8069B486F5DC5479DDFC08@de01exm70.ds.mot.com>
Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt
Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPgAACiwEAAAAXbEACQWv7w
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "Jayshree Bharatia" <jayshree@nortel.com>,
	"Vijay Devarapalli" <vijayd@iprg.nokia.com>,
	"Kent Leung \(kleung\)" <kleung@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
Content-Transfer-Encoding: quoted-printable
Cc: mip4@ietf.org, "Charles E. Perkins" <charliep@iprg.nokia.com>
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

Sorry, I should have responded to this email then. If you could add more
guidance in section 8 that would be great.

Madjid=20

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 6:10 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

I have covered this part in the modified text for section 3.4 I sent
earlier today. Please check that and see if you like to add or modify.=20

In short, most of Vijay's proposal is going in. But I have slightly
modified text for section 3.5 to include value of challenge for
authenticator computation in section 8. Also, instead of new section, I
will include his proposed text to section 3.1.=20

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Monday, December 05, 2005 6:03 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Hi Jayshree,

Please note that this also impacts section 8 on use of CHAP SPI for
RADIUS server, as I mentioned in a previous email.

Regards,

Madjid=20

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 5:57 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi Madjid,

OK. In this case, I will include his text in section 3.1 (Mobile Node
processing of Registration Requests) rather than having a new section as
he suggested. I will also include his proposed text for "Security
Considerations" section.

Thanks,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Monday, December 05, 2005 5:42 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung
(kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Jayshree,=20

Appreciate for the effort on gaining consensus.
I don't have a strong position either way, the text is now complete. I
sort of agree with Vijay that you might want to add that "In CCoA,
replay protection is provided through methods specified in 3344
(Identification field in RRQ)", this is just to keep people from
wondering... I am fine with either way consensus goes on this one.

Madjid

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20
Sent: Monday, December 05, 2005 2:30 PM
To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung)
Cc: mip4@ietf.org; Charles E. Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt

Hi all,

Thanks for all your comments. In summary, I see that we have now general
agreement that co-located CoA support for MN-AAA extension will be part
of this draft. In that respect, I am considering text proposed by Vijay
for section 3.1 and 3.5.=20

Currently we have text saying that the mechanism used by the mobile node
to obtain the Challenge value in this case is outside the scope of this
document. Based on the input from Kent and Madjid, the following is the
proposal (modified Vijay's proposal for section 3.5):

From:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344].

To:
In the co-located CoA mode, the mobile node will receive a Registration
Reply without the Challenge Extension and processes the Registration
Reply as specified in [RFC3344]. In this case, the Challenge value 0 is
recommended for the authenticator calculation mentioned in section 8.

Please note that I haven't included Vijay's proposed text for a new
section (5) and also for Security Considerations since they are already
part of RFC3344.

Regards,
Jayshree

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Friday, December 02, 2005 11:31 AM
To: Vijay Devarapalli; Kent Leung (kleung)
Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E.
Perkins
Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt


Vijay,

However we want to do it, needs to be specified. Motorola development
folks share Nokia's confusion:) I think only a handful of people in the
industry know exactly how 3344, 3012, 3957, 4004 all work together and
that is why the key bootstrapping is not getting any traction in the
implementations. We have endless internal "educative" sessions on this
too :) I believe 4004  for Diameter missed the problem with MN-AAA AE
for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't
think that is the right place for it. We suggested zero based on
Charlie's initial suggestion to make implementation of CoA and CCoA less
complex, you have the same field, you just enter zero when no value is
available.

Madjid



> Also, MN sets the challenge value to zero in the MN-AAA authenticator
> computation.

hmm.. how about the MN does not use any challenge value (whether 0 or
anything else)? it calculates the MN-AAA authenticator without any
challenge field. one the basic clarifications that is needed is that
there is no challenge to use when there is no FA.

>>- clarify that in the absence of a challenge, replay protection is
>>provided by the identification field.
>>
> I don't think this is necessary, but doesn't matter too much to me
> either.

well, folks inside Nokia who implement mobile nodes were very confused
by RFC 3012. it would be good to make this explicit.

Vijay


--
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/




-- 
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/



From mip4-bounces@ietf.org Fri Dec 09 15:40:58 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ekp34-0001jC-LK; Fri, 09 Dec 2005 15:40:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekp32-0001ik-Uj
	for mip4@megatron.ietf.org; Fri, 09 Dec 2005 15:40:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27601
	for <mip4@ietf.org>; Fri, 9 Dec 2005 15:40:03 -0500 (EST)
Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekp3G-0002DM-UG
	for mip4@ietf.org; Fri, 09 Dec 2005 15:41:13 -0500
Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502)
	id 797F4383E6; Fri,  9 Dec 2005 21:40:34 +0100 (CET)
Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net
	[81.228.8.92]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP
	id 448803802C; Fri,  9 Dec 2005 21:40:34 +0100 (CET)
Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com
	[81.224.201.50])
	by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id C66F937E44;
	Fri,  9 Dec 2005 21:40:33 +0100 (CET)
Received: from localhost ([127.0.0.1])
	by shiraz.levkowetz.com with esmtp (Exim 4.54)
	id 1Ekp2f-0000Pw-81; Fri, 09 Dec 2005 21:40:33 +0100
Message-ID: <4399EBBF.7080106@levkowetz.com>
Date: Fri, 09 Dec 2005 21:40:31 +0100
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mobile IPv4 Mailing List <mip4@ietf.org>, Pete McCann <mccap@lucent.com>
X-Enigmail-Version: 0.93.0.0
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: 2.0 (++)
X-Scan-Signature: b4b36b0fb877eeac6f347960137fc10b
Cc: 
Subject: [Mip4] IETF-64 Minutes
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>
Content-Type: multipart/mixed; boundary="===============1431029839=="
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1431029839==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig9BFDE71220B8363D1A75B0C2"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9BFDE71220B8363D1A75B0C2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

========================================================================
			 Mobility for IPv4 WG (mip4)
========================================================================

THURSDAY, November 10, 2005, 1300-1500
========================================================================

CHAIRS: 
        Henrik Levkowetz <henrik@levkowetz.com>

        Pete McCann <mccap@lucent.com>

AGENDA:

1. Preliminaries                                        10 min Chairs
------------------------------------------------------------------------

   - Minutes
   - Agenda bashing

   No comments on agenda

2. Document Status                                      15 min Chairs
------------------------------------------------------------------------
   draft-ietf-mip4-rfc3344bis           

   New revision submitted right before the meeting.
   Next: Chair writeup and publication request

   Comments:
      Henrik: 
        Charlie submitted a new version before the meeting. One request for a
        new error number was done. 

      Charlie: 
        submitted the weekend before the deadline but it has been on the
        website for a month and there has been no change. 

      Vijay: 
        the target is draft standard?

      Pete: 
        we had some subsequent technical changes therefore we need to
        recycle to proposed.

      Henrik: Yes, we had indicated draft standard but people need to be
          aware that we have done changes.

      Vijay: not exactly sure what changes were made? 

   draft-ietf-mip4-vpn-problem-solution         
      Ready for WG last call

   draft-ietf-mip4-dynamic-assignment           
      Waiting for AD Go-Ahead::AD Followup

   draft-ietf-mip4-faerr                        
      Waiting for AD Writeup

   draft-ietf-mip4-reg-tunnel                   
      AD Evaluation::Revised ID Needed

      This draft has an Appendix which the authors don't agree
      on how to handle.  We've had an independent review of
      the Appendix too, and need to decide what to do with it.

   Comments:
      Henrik: 
         Had a long and painful story. We may be splitting up the draft
         into an appendix and the main part and then do the appendix as
         informational.  

   draft-ietf-mip4-rfc3012bis                  
      Waiting for AD Writeup

      Several reviews done for AD,
      Need to decide whether to fork off the Generalized 
      Mobile IP Authentication Extension as a separate draft.

   Comments:
      Henrik: Jayshree is doing the few changes..

   draft-ietf-mobileip-lowlatency-handoffs-v4   
      IESG Evaluation::AD Followup

      (Just re-submitted by Karim, ready to go to RFC Editor)

   Comments:
      Henrik: has been approved.

   draft-ietf-mip4-rfc2006bis                   
                MIP-centric review done, new revision needed

   Comments:
      Henrik: 
        Kent is going to do the review alone or with help. Hopefully
        ready for MIB doctor. 


   draft-ietf-mip4-experimental-messages        RFC 4064

   draft-ietf-mip4-vpn-problem-statement        RFC 4093

   Comments:
      Henrik: that is nice.

3. New charter                                           5 min Chairs
------------------------------------------------------------------------
   http://mip4.org/charter/mip4-charter-2005-09-08.html

   Comments:

      Henrik: 
        Did not get to the IESG slate. No indication of negative
        results. If you have comments, this is your last chance. We
        have a new work items that will make into charters. Until that
        is cleared, we will not take new work items. There are some
        presentation are here for addition to the charter but that is
        the bottom line at this point.    

4. New WG drafts:                                       20 min Author
------------------------------------------------------------------------
   Status summary, open issues:

   draft-bharatia-mip4-gen-ext                        5 min Kent

   Presentation:
     http://www3.ietf.org/proceedings/05nov/slides/mip4-2.pdf

   Presentation by Kuntal. 

     The draft aims to send conf info from HA to the mobile during the
     initial exchange.

     Changes from -00 to -01 is formatting of configuration parameter
     based on DHCP options, no longer MIP-specific

     Also allows the MN to request config info from the home or visited
     network and that at the same time if needed.

     Here we reuse DHCP codes so you don't have to define new
     subtypes. Adopted the DHCP option code structure and formatting.

     received some comments on the mailing list and updated the draft based on that.

     A generic extension to be used for the method was shown, including
     type, length, entity-type (distinguishing between FA ad HA), and
     config data (conf parameters are packed here).

     an example of config parameters were shown.

     open issues:only DHCP based parameters are considered. Do we have to
     define non-DHCP parameters?

   Comments:
      Sri: 
	You may also need a default realm for DNS queries.

      Pres: 
	You can basically piggyback DHCP info with this.

      Henrik: 
	Can we define this as DHCP-only information and if we need
	non-DHCP we define a different extension for that later.

      Kuntal: 
	good idea

      Yoshi: 
	DHCP option length 

      Kuntal: 
	If all the option are going to fit in one or multiple NVSE.

      Kent: 
	We have talked among ourself on what to do with the DHCP versus
	non-DHCP, we think we should built that at subtype level rather at
	type level.

      Henrik: either way works for me.

   draft-devarapalli-mip4-mobike-connectivity         5 min ???

   Presentation:

     http://www3.ietf.org/proceedings/05nov/slides/mip4-3.pdf

   Presented by Vijay: 

     Brief update from 00 to 01:

     01 has been submitted with not
     many changes, some based on Jari and TJ's reviews.the target is
     going to a BCP doc. some additions on when this mechanism is
     used. the idea is use this for IKEV2. and IKEv1 reference was
     removed.    

   draft-sastry-mip4-string-extension                 5 min Kent

   Presentation:

     http://www3.ietf.org/proceedings/05nov/slides/mip4-0.pdf

   Presented by Kent: 

     Update since version 00:

     update to 02 some changes regarding the revocation messages.
     Changes on the use of message string extension, correction to
     security considerations.  Some changes based on TJ's comment and
     addressed most of the issues.

     Can we have some comments? it seems to be pretty straight forward and
     should go to last call.

   draft-nakhjiri-radius-mip4                         5 min Madjid

   Presentation:

     http://www3.ietf.org/proceedings/05nov/slides/mip4-1.pdf

   Presented by Madjid:

     Update since version 01:

	 Clean up of the attribute section. 

     Review from Jari Arkko. There was a question on why the registration
     request was being hashed. this was to avoid the attribute size issue
     in the future if the reg. req gets too big.

     Diameter can tell whether you are dealing with a HA or a FA. for
     RADIUS you can do this only by some information in the
     attributes. Something new is needed. A new MIP-Agent type

     Some work remaining. More details on Diameter AVP-RADIUS attribute translations

     Issue with MN-AAA authenticator and MFCE. please fix 3012bis.

   Comments:

     Vijay:
       Don't agree with CCoA mode calculation in 3012bis draft

     Kent:
       Discusses already on WG. Folks agree there are 2 solutions in RFC 3012.

     Henrik:
       Take it to the WG alias.

     Henrik: 
       We've had quite a bit of discussion with RADEXT chair and need to make
       clear what we are doing here and how we separate that from what it is
       done in Diameter. There should be a doc on this.

   draft-koodli-fmipv4                                5 min ???

     Nothing to go over here.


5. IPv6 over MIPv4 and MIPv4 over IPv6.                  5 min Chairs
------------------------------------------------------------------------

   Taking on some work in this area has been discussed earlier, during
   IETF-62.  The question has been raised by some people again, in view
   of the work on MIPv6 over IPv4 and IPv4 over MIPv6 which is being
   done in the MIP6 working group.

   Comments:

      Henrik: 
        Authors have asked to reconsider this again. He likes to ask
        for a HUMMM on which way to go. No decision is to be done here.

      Hesham: 
        The aim is to allow the operator to do IPv6 over MIPv4 and a
        similar work is done in MIPv6.

      Kent agrees.

      Vijay:
        I like to discourage these sort of things in general. It is
        better to move on to IPv6 rather to do run things this way.

      Henrik: 
        Not everybody agrees plus there are specific cases that you simply cannot do it.

      Hesham: Philosophically is better to force people on these things.

      Rajeev K:
        questions what is the relation between this and the traversal work in MIPv6.

      Henrik:
        this only deals with MIpv4 and not MIPv6 and that is why.

      Kent:
        the goal is to use one signaling protocol.

      Pete: 
        chair hat off, I submitted this draft a while ago. It makes sense IPv6 over MIPv4.

      Vijay: 
        personal experience. Operators are willing and want to move to IPv6.

      Henrik: 
        we are not proposing people to not move to IPv6 here. 
        for information only how many people want to take this or not to take this on.
        The HUMM for for is stronger than the HUMM against.

      Mohan: 
        Scope of work?

      Chairs: 
        Both drafts.
 

   Related drafts:
      draft-tsirtsis-v4v6-mipv4

      draft-larsson-v6ops-mip-scenarios

6. GRE Key Extension for Mobile IPv4                    10 min Parviz
      draft-yegani-gre-key-extension

   GRE (Generic Routing Encapsulation) [ RFC 2784 ] is one of the
   encapsulation formats permitted by RFC 3344.  GRE may use keys
   to distinguish different tunnels from each other. [RFC 2890].
   This draft proposes a MIPv4 extension to communicate GRE keys
   between MIPv4 tunnel endpoints when requesting GRE tunnelling
   for MIPv4 traffic.

   Parviz presented. 

      3344 optionally supports GRE tunneling.
      The proposal is to allow this tunneling.

      there is a need for subscribers who are home in 3GPP. You cannot
      really distinguish between traffic streams based on HoA, CoA. So we
      need a new extension.

      The idea is to allow both HA and FA to assign different keys (assymetric). 

      There are situations that these keys can be available to HA and FA.

      But in 3344 the MN can set the G bit. Here we should be able to based
      on policy overwrite the G-bit setting and request a GRE tunneling.

      Henrik: clarification, we are talking about GRE key, not encryption key.

      Mohan: is it for FA CoA or colocated mode

      Parviz: no for both.
       This is for FA CoA mode only.

      Parviz: the HA can assign two addresses to the same subscriber because
      it is private addresses.

      back to presentation: GRE key assignment is outside of the scope. The
      behavior of FA is new, the G-bit overwriting is not the in RFC. The
      impact is that key allocated by the FA can be used for FA-to-HA use.

      No changes to the MN behaviour.

      Questions/ comments/ working group item?

   Comments:
      Kent: 
        good idea. When HA is wholesale, this is a good idea. Today the
        only solution is to have different instances of HAs.

      Pete:
         I like the idea, it is done 3GPP2. But not comfortable with G-bit overwrite.

      Parviz:
         the final decision is by the HA and the HA can reject and
         finally have a different tunneling.

      Henrik:
         what happens to MN-HA-AE if you can the G-bit?

      Parviz:
         G-bit in the GRE extension is not changed. 

      Kuntal:
         why would the MN care whether you are GRE or not? why does
         have to be based on MN request.

      Kent:
         when the tunnel is between FA and HA, what is the role of MN?
         this is breaking the paradigm of the 3344.

      Sri:
         consistent. The extension is added by the FA.

      Parviz:
         which entity should assign those keys, FA or HA or both.

      Kuntal:
         both. the key that FA wants to receive should be specified by
         the FA and the one HA wants should be assigned by HA.

      Kent:
         Unidirectional and bidirectional should be supported. HA should
         be able to assign the keys for both sides.

      Kuntal:
         can't see a use case for when we want the HA to allocate both.

      Pete:
         receiver should allocate the key.

      Kent:
         agree, it is ok for the HA to allocate the key, technically.

      Henrik:
         may simplify what FA wants to do, but does not simplify the FA code.

      Kent:
         don't think implementation pov either way is harder.

      Kuntal:
         should we really have to have both options in the draft.

      Henrik:
         proposing to have the receiver assign the keys.

      Kent:
         Agree with everything but it does not hurt to add it and make it optional.

      Kuntal:
         how does the FA know what sort HA is it talking to.

      Henrik:
         Kent to propose some text and take it to the list.


7. Generic Notification Message for Mobile IPv4         10 min Hui
------------------------------------------------------------------------

      draft-deng-mip4-generic-notification-message-00.txt

   This document proposes a protocol enhancement that allows Mobile
   IPv4 entities to asynchronously send and receive explicit 
   notification messages.  The Registration Revocation mechanism of RFC
   3543 could have been specified using a message such as the one
   proposed here, had it been available at the time.

   Presented by Hui

   Presentation:

      in some cases, there is a need for MIPv4 entities to send and rx
      asynch notification events during a session. 3344 does not provide
      specification for this.

      This doc defines generic message and notification model for this process.

      does not define specific notification extensions.

      some examples are presented. 

      HA initiates a notification to MN, FA initiates a notification to MN, another case.

      Generic notification msg send by mobility agent to inform another
      mobility agent or a MN.

      3 flags were defined

      flag A, bit identifies if ack to the notification msg is need.
      other fields of the message were defined.

      issues: to discuss whether a notification MUST be acked and whether
      the use of flag is good or not.

      issue 2: R bit in Agent advertisement

      usage examples were presented: 

      registration revocation, asynch. user notification (out of credit,
      coming service interruption), asynch MN or agent notification, may be
      necessary for high availability scenarios with long reg. life times.

   Comments:
      Henrik:
         comments on the issues and the general idea

      Kuntal:
         similar in MIP6 regarding HA switch. I think this is a good
         idea, but I am struggling with the use cases and who will be doing
         this.  Why would you notify the HA when the system is going down, and
         create more traffic.

      Hui:
         Just one BS with access channel in cellular won't cause that much traffic.

      Henrik:
         you are not sending 1 Million notification, it is good idea to
         cover in the draft for planned maintenance, when you notify that you
         want to take the HA down in so and so hour.

      Kuntal:
         still you may have thousands of MNs maintained by HA, still
         that is a lot of messages.

      Henrik:
         This a small subpercentage of the overall traffic.

      Kuntal:
         why not use reg. revoke. why this one?

      Henrik:
         Are you supposing that we should do this using another message? don't agree.

      Kuntal:
         reg. revoke is done today.

      Kent:
         make this optional, not mandatory.

      Henrik:
         We should put our foot down and say no if we think something
         is causing a lot of problem (personal opinion).

      Hui:
         3GPPX wants to use SIP SDP for this.

      Parviz:
         not sure I can see the use case scenario for this.

      Hui:
         the real scenario is HA switch.

      Sri:
         don't focus on where it is used, but focus on whether this is
         useful or not. example is prepaid.

      Kuntal:
         last comment on prepaid and people use text messages for that
         purpose. HA has no business sending notification to the MN when
         account is up.  for MN-FA notifications you would need specific
         bootstrapping methods.  If something is already solved in the industry
         we don't try to go and design a new solution.

      Kent:
         right now the revocation only goes to FA, but not to the MN, so
         it may not be the right way to do it but we do have a MN-HA
         association. In deployments people don't completely shut down the HA
         anyway, but if you want to do that more power to you.


8. Mobile IPv4 Fast Handovers for 802.16e networks       5 min Junghoon
------------------------------------------------------------------------
      draft-jee-mip4-fh80216e

   IEEE 802.16e is an amendment of 802.16 ("WiMAX") which extends it
   from fixed terminals only to fixed and mobile operation.
   This document describes how Mobile IPv4 Fast Handover can be used
   IEEE 802.16e link layers.

   Presented  by Junghoon.

   Presentation:
      rfc 4068 is a work item (FMIPv4), so he proposes fmipv4 over 16.
      some of related work is done in MIPshop, so he is mentioning. 
      some mobility is done in layer 2.
      predictive and reactive (??) modes were discussed.

      Is there interest in this work? is this a topic for this working group?

   Comments:
      Pete: 
         the problem is that FMIPv6 over X is supported in MIPSHOP, but
         they have strict charter on v6. Should we get into FMIP stuff here?

      Rajeev: 
         True, may be it should be here.

      Parviz:
         why just 16e? should be FMIPv4 over anything?

      Pete:
         you need to take the specifics of the link to make it working.

      Hannes:
         it is good stuff.

      Kent:
         it is interesting.

      Henrik:
         I can predict problems down the line when we want to go for publication.


9. Using multiple interfaces for increased throughput    5 min Srinivasa
------------------------------------------------------------------------
        draft-srinivasa-mip4-mir-00.txt

   This document defines enhancements that allow a MN, when away from
   home, to simultaneously use multiple connected network interfaces
   so as to obtain higher aggregated bandwidth.

   Henrik:
      Author is not here. it is interesting work. uses multiple
      interfaces to stream videos to remote villages in India because the
      existing cellular systems and it is actual deployment. It is mature
      for adoptions. As an example of what you can do in a multiple
      interface scenarios.




--------------enig9BFDE71220B8363D1A75B0C2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmevAeVhrtTJkXCMRAleCAKD1ivniUSEcOwMuE+5/UxllhAkVbgCg87yn
ag+S6oA2hxgl1QqTuIeWjUE=
=/WdR
-----END PGP SIGNATURE-----

--------------enig9BFDE71220B8363D1A75B0C2--


--===============1431029839==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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/

--===============1431029839==--




From mip4-bounces@ietf.org Fri Dec 09 16:20:33 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkpbL-0003Yu-An; Fri, 09 Dec 2005 16:16:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkpbH-0003Y5-Md
	for mip4@megatron.ietf.org; Fri, 09 Dec 2005 16:16:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05575
	for <mip4@ietf.org>; Fri, 9 Dec 2005 16:15:18 -0500 (EST)
Received: from mail.flarion.com ([63.103.94.23])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkpbO-0004s4-T1
	for mip4@ietf.org; Fri, 09 Dec 2005 16:16:28 -0500
Received: from ftmailserver.flariontech.com ([10.10.1.140]) by
	mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	Fri, 9 Dec 2005 16:15:52 -0500
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Subject: RE: [Mip4] IETF-64 Minutes
Date: Fri, 9 Dec 2005 16:15:54 -0500
Message-ID: <A11736FE943F1A408F8BBB1B9F5FE8AD17DE64@ftmailserver.flariontech.com>
Thread-Topic: [Mip4] IETF-64 Minutes
Thread-Index: AcX9AYs2g4a0xwHrRjCe3Y/yexQG8AAARUCAAAAAhCA=
From: "Soliman, Hesham" <H.Soliman@flarion.com>
To: "Henrik Levkowetz" <henrik@levkowetz.com>,
	"Mobile IPv4 Mailing List" <mip4@ietf.org>,
	"Pete McCann" <mccap@lucent.com>
X-OriginalArrivalTime: 09 Dec 2005 21:15:52.0321 (UTC)
	FILETIME=[BC262F10:01C5FD05]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: quoted-printable
Cc: 
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



 >=20
 >       Hesham: Philosophically is better to force people on=20
 > these things.

=3D> I believe I said "...better *not* to..."

Hesham


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
This email may contain confidential and privileged material for the sole =
use
 of the intended recipient.  Any review or distribution by others is =
strictly
 prohibited.  If you are not the intended recipient please contact the =
sender
 and delete all copies.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D


-- 
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/



From mip4-bounces@ietf.org Fri Dec 09 16:30:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkpoX-00021R-OD; Fri, 09 Dec 2005 16:30:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkpoO-0001yq-SO
	for mip4@megatron.ietf.org; Fri, 09 Dec 2005 16:29:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10873
	for <mip4@ietf.org>; Fri, 9 Dec 2005 16:28:51 -0500 (EST)
Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkpoW-0006dd-2F
	for mip4@ietf.org; Fri, 09 Dec 2005 16:30:01 -0500
Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502)
	id 12B9137F6B; Fri,  9 Dec 2005 22:29:28 +0100 (CET)
Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net
	[81.228.9.101]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP
	id D6D6F37ECB; Fri,  9 Dec 2005 22:29:27 +0100 (CET)
Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com
	[81.224.201.50])
	by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 7EE6D37E49;
	Fri,  9 Dec 2005 22:29:27 +0100 (CET)
Received: from localhost ([127.0.0.1])
	by shiraz.levkowetz.com with esmtp (Exim 4.54)
	id 1Ekpny-00055r-OU; Fri, 09 Dec 2005 22:29:26 +0100
Message-ID: <4399F734.6050308@levkowetz.com>
Date: Fri, 09 Dec 2005 22:29:24 +0100
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Soliman, Hesham" <H.Soliman@flarion.com>
Subject: Re: [Mip4] IETF-64 Minutes
References: <A11736FE943F1A408F8BBB1B9F5FE8AD17DE64@ftmailserver.flariontech.com>
In-Reply-To: <A11736FE943F1A408F8BBB1B9F5FE8AD17DE64@ftmailserver.flariontech.com>
X-Enigmail-Version: 0.93.0.0
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.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: Pete McCann <mccap@lucent.com>, Mobile IPv4 Mailing List <mip4@ietf.org>
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>
Content-Type: multipart/mixed; boundary="===============1744586747=="
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1744586747==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig9B588FF50D97EFEF04A4CC18"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9B588FF50D97EFEF04A4CC18
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Hesham,

on 2005-12-09 22:15 Soliman, Hesham said the following:
> 
>> 
>>       Hesham: Philosophically is better to force people on 
>> these things.
> 
> I believe I said "...better *not* to..."

Right, I didn't think that sounded quite like you...

Fixed in the uploaded minutes.


	Henrik

--------------enig9B588FF50D97EFEF04A4CC18
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDmfc2eVhrtTJkXCMRAsdgAKCLYciwtRLnnjm6UvcHjx1aDAtk1wCggVAU
tAKx46V9Bslf7bKR7Bbv/ZI=
=Il4W
-----END PGP SIGNATURE-----

--------------enig9B588FF50D97EFEF04A4CC18--


--===============1744586747==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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/

--===============1744586747==--




From mip4-bounces@ietf.org Thu Dec 15 15:50:54 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1En03y-0006NA-Q6; Thu, 15 Dec 2005 15:50:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1En03C-00064A-2C; Thu, 15 Dec 2005 15:50:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03256;
	Thu, 15 Dec 2005 15:49:04 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1En04c-0001cH-N3; Thu, 15 Dec 2005 15:51:35 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1En038-0001PB-Es; Thu, 15 Dec 2005 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1En038-0001PB-Es@newodin.ietf.org>
Date: Thu, 15 Dec 2005 15:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: mip4@ietf.org
Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dynamic-assignment-07.txt 
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IPv4 Working Group of the IETF.

	Title		: Mobile IPv4 Dynamic Home Agent Assignment
	Author(s)	: M. Kulkarni, et al.
	Filename	: draft-ietf-mip4-dynamic-assignment-07.txt
	Pages		: 24
	Date		: 2005-12-15
	
Mobile IPv4 [1] uses the Home Agent (HA) to anchor sessions of a 
   roaming Mobile Node (MN).  This draft proposes a messaging mechanism 
   for dynamic home agent assignment and HA redirection.  The goal is to 
   provide a mechanism to assign an optimal HA for a Mobile IP session 
   while allowing any suitable method for HA selection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mip4-dynamic-assignment-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mip4-dynamic-assignment-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2005-12-15145126.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mip4-dynamic-assignment-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mip4-dynamic-assignment-07.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-12-15145126.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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/

--NextPart--




From mip4-bounces@ietf.org Wed Dec 21 10:30:29 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep5vB-0001Iv-2M; Wed, 21 Dec 2005 10:30:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep5v6-0001I4-9J; Wed, 21 Dec 2005 10:30:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00444;
	Wed, 21 Dec 2005 10:29:19 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ep5xk-0001Qf-HL; Wed, 21 Dec 2005 10:33:08 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1Ep5v3-0004qg-4V; Wed, 21 Dec 2005 10:30:21 -0500
Content-Type: text/plain
Mime-Version: 1.0
To: IETF-Announce@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1Ep5v3-0004qg-4V@newodin.ietf.org>
Date: Wed, 21 Dec 2005 10:30:21 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Cc: Peter McCann <mccap@lucent.com>, mip4@ietf.org,
	Henrik Levkowetz <henrik@levkowetz.com>
Subject: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) 
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

The Mobility for IPv4 (mip4) working group in the Internet Area of the IETF
has been rechartered. For additional information, please contact the Area 
Directors or the working group Chairs.

+++

Mobility for IPv4 (mip4)
==========================

Current Status: Active Working Group

Chair(s):
Peter McCann <mccap@lucent.com>
Henrik Levkowetz <henrik@levkowetz.com>

Internet Area Director(s):
Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:
Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:
General Discussion: mip4@ietf.org
To Subscribe: mip4-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/mip4/index.html

Description of Working Group:
IP mobility support for IPv4 nodes (hosts and routers) is specified in
RFC3344. RFC 3344 mobility allows a node to continue using its
"permanent" home address as it moves around the internet. The Mobile IP
protocols support transparency above the IP layer, including 
maintenance of active TCP connections and UDP port bindings. Besides the basic
Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns
such as optimization, security, extensions, AAA support, and deployment
issues.

Mobile IPv4 is currently being deployed on a wide basis (e.g., in
cdma2000 networks). The scope of the deployment is on a fairly large
scale and accordingly, the MIP4 WG will focus on deployment issues and
on addressing known deficiencies and shortcomings in the protocol that
have come up as a result of deployment experience. Specifically, the
working group will complete the work items to facilitate interactions
with AAA environments, interactions with enterprise environments when
Mobile IPv4 is used therein, and updating existing protocol
specifications in accordance with deployment needs and advancing those
protocols that are on the standards track.

Work expected to be done by the MIP4 WG as proposed by this charter is
as follows:

1. MIPv4 has been a proposed standard for several years. It has been
adopted by other standard development organizations and has been
deployed commercially. One of the next steps for the WG is to advance
the protocol to draft standard status. As part of advancing base
Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will be revised
to reflect implementation experience.

2. A mechanism for home agent assignment at the time of mobile-ip
registration,
rather than preconfigured for the mobile node, has been proposed.
The WG will take on the task of completing this. The ability to switch
the home agent assigned to a mobile node while registered will also be
considered as part of this task.

3. Work items that are pending from the previous Mobile IP WG, which
will be completed by the MIP4 WG, are:

- RFC3012bis (Challenge-response mechanism)
- low-latency handover draft to experimental status
- completion of the MIB for the revised base Mobile IP
specification (2006bis)
- regional registration draft.

4. The MIP4 WG will also complete the work on Mobile IPv4 interactions
in VPN scenarios. This work will involve identifying the requirements
and a solution development for Mobile IPv4 operation in the presence
of IPsec VPNs.

5. Some issues have been raised with respect to RFC3519. These will be
identified and addressed as appropriate, through errata, revision
of RFC 3519, and/or supplemental documents as needed.

Other potential work items may be identified in the future but will
require an appropriate re-charter.

Goals and Milestones:
Done    AAA Keys for MIPv4 to IESG  
Done    MIPv4 VPN interaction problem statement to IESG  
Done    Low latency handover to experimental  
Done    Experimental MIPv4 message and extensions draft to IESG  
Done    Dynamic Home Agent assignment protocol solution to IESG  
Done    Revised MIPv4 Challenge/Response (3012bis) to IESG  
Done    Regional registration document to IESG  
Nov 2005    Revised MIPv4 specification to IESG for Draft Std.  
Dec 2005    Revised MIB for MIPv4 (Proposed Std.) to IESG  
Jan 2006    MIPv4 Mobike interaction (BCP) to the IESG  
Jan 2006    MIPv4 VPN interaction (BCP) to the IESG  
Feb 2006    Generic Strings for MIPv4 (Proposed Std.) to the IESG  
Mar 2006    MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment  
Mar 2006    FMIPv4 (Experimental) to the IESG  
Apr 2006    Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG  
May 2006    RADIUS Extensions for MIPv4 to the RADEXT WG for comment  
Aug 2006    MIPv4 RADIUS Extensions Requirements to the IESG  
Aug 2006    MIPv4 Extension for Config. Options (Proposed Std.) to the IESG  
Sep 2006    RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG  


-- 
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/



From mip4-bounces@ietf.org Sun Dec 25 11:11:24 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EqYSy-0003Qk-KF; Sun, 25 Dec 2005 11:11:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpPHF-0004Fr-33; Thu, 22 Dec 2005 07:10:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01836;
	Thu, 22 Dec 2005 07:09:27 -0500 (EST)
Received: from netserv.iet.unipi.it ([131.114.53.115])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EpPK3-000871-F4; Thu, 22 Dec 2005 07:13:28 -0500
Received: from LORENZ.netserv.iet.unipi.it (lorenz.iet.unipi.it
	[::ffff:131.114.53.111]) (AUTH: LOGIN tavanti)
	by netserv.iet.unipi.it with esmtp; Thu, 22 Dec 2005 13:08:07 +0100
	id 000E6C66.43AA9728.000033BC
Message-Id: <6.2.1.2.0.20051222111901.01d7cc50@pop.ing.unipi.it>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 22 Dec 2005 11:19:25 +0100
To: (Recipient list suppressed)
From: Luca Tavanti <luca.tavanti@iet.unipi.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Antivirus: avast! (VPS 0551-2, 20/12/2005), Outbound message
X-Antivirus-Status: Clean
X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.47
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 25 Dec 2005 11:11:23 -0500
Subject: [Mip4] CFP: First IEEE workshop on advanced experimental activities
 on wireless networks and systems - EXPONWIRELESS 2006
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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[Please accept our apologies for multiple copies of this message]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

First IEEE Workshop on advanced experimental activities on wireless netw=
orks and systems

EXPONWIRELESS =AD 2006

http://netgroup.iet.unipi.it/EXPONWIRELESS/

26 June 2006 =AD Niagara-Falls, Buffalo, NY, USA

in conjunction with IEEE WoWMoM 2006 ( http://ieee-wowmom.cse.buffalo.ed=
u/)

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

CALL FOR PAPERS

Wireless networks represent a challenging and ever growing research area=
. In these systems the interactions among the different network layers a=
re very complex and their effects on the overall performance are not eas=
y to accurately identify. Experimental activities involving the developm=
ent of systems and device prototypes and the collection and analysis of =
measurements from actual networks can provide an insight on the behaviou=
r of such systems in realistic environments, which can be beneficial for=
 understanding how cross-layer interactions impact in practice the overa=
ll performance, for deriving realistic simulation models, for analyzing =
particular phenomena and evaluating algorithms and protocols, and for ex=
ploring the design choices in building actual wireless networks. Such ac=
tivities are pivotal for researchers, developers, service managers and p=
roviders, as well as for end users involved in the evolution of these ne=
tworks.

EXPONWIRELESS aims at bringing together all the aspects related to exper=
imental achievements on wireless networks, creating a forum where resear=
chers, vendors, providers and users can exchange ideas on past experienc=
e, current requirements, and future visions, useful for the development =
of new protocols, algorithms, devices and systems.

High quality papers discussing original and innovative experimental acti=
vities on wireless networks are solicited for submission. The main topic=
s of the workshop are (but are not limited to):
 
=B7  Device prototypes for wireless BANs, PANs, LANs, and MANs
=B7  QoS for real-time voice and video in wireless networks
=B7  Differentiated services in wireless multimedia networks
=B7  IP-based multimedia services over wireless networks
=B7  Multi-hop Multi-radio wireless mesh networks
=B7  Handoff and mobility management in beyond-3G systems
=B7  Seamless internetworking
=B7  Systems and methods for collecting and analyzing measurements in wi=
reless networks
=B7  Architectures for beyond-3G systems
=B7  Energy-efficient protocols and power management algorithms
=B7  Wireless security
=B7  Wireless ad-hoc networks
=B7  Wireless sensor networks
=B7  Wireless vehicular networks
=B7  Prototype implementation of wireless/mobile networks and systems
=B7  Wireless/Mobile applications
=B7  Middleware platforms for wireless/mobile environments
=B7  Software technologies and systems
=B7  Location services
=B7  Positioning and Tracking Technologies

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

PAPER SUBMISSION

Submitted manuscripts should adhere to the IEEE double-column standard f=
ormat, except the font size, which must be Times Roman 11pt (or greater)=
. Authors should use only standard fonts, i.e., Times Roman, Courier, Sy=
mbol, and Helvetica, or equivalent. The maximum length of the manuscript=
 is 6 pages. This limit includes figures, appendix, bibliography, etc. P=
apers that will be significantly in excess of this limit will be automat=
ically rejected. All submissions will be handled electronically. Authors=
 should prepare a PDF file and submit it to exponw@netserv.iet.unipi.it.
Accepted papers will be published by the IEEE Computer Society Press in =
the combined WoWMoM 2006 workshop proceedings.

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

IMPORTANT DATES

Submission Deadline: January 9, 2006
Acceptance Notification: February 27, 2006
Camera Ready Due: March 20, 2006

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

WORKSHOP CO-ORGANIZERS

Rosario G. Garroppo, Dept. of Information Engineering, University of Pis=
a, Italy
Yonghe Liu, The University of Texas at Arlington, USA
Vasilios A. Siris, Institute of Computer Science, Foundation for Researc=
h & Technology - Hellas (FORTH), and University of Crete, Greece

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

PUBLICITY CHAIR

Luca Tavanti, Dept. of Information Engineering, University of Pisa, Ital=
y

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

TECHNICAL PROGRAM COMMITTEE

Giuseppe Bianchi, University of Roma =93Tor Vergata=94, Italy
Torsten Braun, University of Berne, Switzerland
Anthony Ephremides, University of Maryland, College Park, MD, USA
Stefano Giordano, University of Pisa, Italy
Tian He, University of Minnesota, Minneapolis, MN, USA
Tristan Henderson, Dartmouth College, Hanover, NH, USA
Edward W. Knightly, Rice University, Houston, TX, USA
Mohan Kumar, University of Texas, Arlington, TX, USA
Saverio Niccolini, NEC Europe Ltd, Heidelberg, Germany
Giovanni Pau, University of California, Los Angeles, CA, USA
George Polyzos, Athens University of Economics and Business, Greece
Mihail L. Sichitiu, North Carolina State University, Raleigh, NC, USA
David Soldani, Nokia, Finland
Sandra Tartarelli, NEC Europe Ltd, Heidelberg, Germany
Phuoc Tran-Gia, University of Wuerzburg, Germany
Hongyi Wu, University of Louisiana, Lafayette, LA, USA


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Merry Christmas and a Happy New Year!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D


-- 
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/