From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 00:17:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06084
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 00:17:46 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00823;
	Sun, 30 Sep 2001 21:16:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14926;
	Sun, 30 Sep 2001 21:16:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f914FqML001348
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 30 Sep 2001 21:15:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f914FqJY001347
	for mobile-ip-dist; Sun, 30 Sep 2001 21:15:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f914FmML001340
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 21:15:48 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14845
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 21:15:42 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21948
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 21:15:41 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA00275;
	Mon, 1 Oct 2001 14:12:16 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA08679;
	Mon, 1 Oct 2001 14:13:22 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXFGS7>; Mon, 1 Oct 2001 14:13:20 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ECCC@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "'pekkas@netcore.fi'" <pekkas@netcore.fi>
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco
	very
Date: Mon, 1 Oct 2001 14:13:19 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14A2F.66C724D0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14A2F.66C724D0
Content-Type: text/plain


>  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
> anycast address); this might scale better especially if IPv6 end-nodes are
> supposed to be simple.
> 
	=> Do you have any idea about how you can secure this BU ?
	Why is this simpler than sendingit to the CN ?
	What about deployment issues, like .. every router has to have MIPv6
	in it ?

> Does anyone really believe that a washing machine, connected to an
> Intranet using IPv6, MUST be able to process e.g. Home Address Destination
> option, or SHOULD be able to process Binding Updates?, or
> 
	=> MUST. It's not that difficult really is it ? Especially if it can
do 
	IPsec !

>  2) Reinstate FA's (e.g. by default all IPv6 routers that implement MIPv6)
> in the picture, or
> 
>  3) Never mind route optimization, always tunnel back to HA
> 
	=> Hmmmm .... could you give reasons for why this is better ? 

	MIPv6 is having a key exchange problem primarily and people are 
	trying to solve it, that is not a reason to start changing
everything.

	Hesham

------_=_NextPart_001_01C14A2F.66C724D0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Discovery</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=2 FACE="Arial">&nbsp;1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router</FONT>
<BR><FONT SIZE=2 FACE="Arial">anycast address); this might scale better especially if IPv6 end-nodes are</FONT>
<BR><FONT SIZE=2 FACE="Arial">supposed to be simple.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Do you have any idea about how you can secure this BU ?</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Why is this simpler than sendingit to the CN ?</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">What about deployment issues, like .. every router has to have MIPv6</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">in it ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Does anyone really believe that a washing machine, connected to an</FONT>
<BR><FONT SIZE=2 FACE="Arial">Intranet using IPv6, MUST be able to process e.g. Home Address Destination</FONT>
<BR><FONT SIZE=2 FACE="Arial">option, or SHOULD be able to process Binding Updates?, or</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; MUST. It's not that difficult really is it ? Especially if it can do </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">IPsec !</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;2) Reinstate FA's (e.g. by default all IPv6 routers that implement MIPv6)</FONT>
<BR><FONT SIZE=2 FACE="Arial">in the picture, or</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;3) Never mind route optimization, always tunnel back to HA</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Hmmmm .... could you give reasons for why this is better ?</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">MIPv6 is having a key exchange problem primarily and people are </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">trying to solve it, that is not a reason to start changing everything.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C14A2F.66C724D0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 02:19:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18882
	for <mobileip-archive@lists.ietf.org>; Mon, 1 Oct 2001 02:19:55 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22670;
	Mon, 1 Oct 2001 00:18:51 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00642;
	Sun, 30 Sep 2001 23:18:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f916I0ML001531
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 30 Sep 2001 23:18:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f916Hxch001530
	for mobile-ip-dist; Sun, 30 Sep 2001 23:17:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f916HtML001523
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 23:17:55 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04464
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 23:17:58 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA00230
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 00:18:58 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f916HpZ00615;
	Mon, 1 Oct 2001 09:17:51 +0300
Date: Mon, 1 Oct 2001 09:17:50 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco
 very
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ECCC@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110010856240.495-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, 1 Oct 2001, Hesham Soliman (EPA) wrote:
> >  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
> > anycast address); this might scale better especially if IPv6 end-nodes are
> > supposed to be simple.
> >
> 	=> Do you have any idea about how you can secure this BU ?
> 	Why is this simpler than sendingit to the CN ?
> 	What about deployment issues, like .. every router has to have MIPv6
> 	in it ?

According to the specs, every IPv6 must be able to do most of these things
anyway, so requiring routers should be able to do this does not seem like
a too big additional requirement.

I'm not sure how BU can be secured.

Why I thought it's simpler is simply because there are about two orders of
magnitude less first-hop routers than hosts.  Which is still a lot, of
course.

> > Does anyone really believe that a washing machine, connected to an
> > Intranet using IPv6, MUST be able to process e.g. Home Address Destination
> > option, or SHOULD be able to process Binding Updates?, or
> >
> 	=> MUST. It's not that difficult really is it ? Especially if it can do
> 	IPsec !

The simple processing of e.g. Home Address Option is easy.  But if you
want to do it securely, it might get a lot more complicated.

Current MIPv6 draft is long.  BU processing, after it is secured, takes a
lot of that.

> >  2) Reinstate FA's (e.g. by default all IPv6 routers that implement MIPv6)
> > in the picture, or
> >
> >  3) Never mind route optimization, always tunnel back to HA
> >
> 	=> Hmmmm .... could you give reasons for why this is better ?

2) For example, if there would be 1000 FA's in the world (found e.g. with
anycast), the routes would be reasonably optimized, and ~1000 would still
be a reasonable order of magnitude to manage security associations.

The traffic could be sent using tunneling between CN -> "FA1" -> "FA2" ->
MN.

I've not analyzed in detail whether this would actually help (can MN/CN
trust FA's?), but if one brought the number of mobility management nodes
to much lower rate, one _might_ be able to assume something about the key
management.

What I'm thinking is like current "6to4 router" [RFC3056] approach.

3) is better (in some aspects) because CN's always send through the HA.
This is a corner-case of mobilility.  You basically need only some basic
framework and a tunnel.  Very simple to implement, and to get secure
because HA-MN can be assumed to have some trust relation.  Only major
problem is the route optimization..

> 	MIPv6 is having a key exchange problem primarily and people are
> 	trying to solve it, that is not a reason to start changing
> everything.

Of course not, in itself, but consider:  the key exchange problem creates
a very difficult set requirements.  In the end, it is probably impossible
to fulfill these without compromises. (Otherwise people would have
deployed world-wide PKI already!). If you can, great.  But if not, some
functionality (e.g. CN processing of BU's in general case) might have to
go.  If this would be the case, one could wonder whether one would need
the functionality in the basic draft then at all, whether the basic draft
could be made much simpler than it is now.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 02:34:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19973
	for <mobileip-archive@lists.ietf.org>; Mon, 1 Oct 2001 02:34:05 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28953;
	Mon, 1 Oct 2001 00:33:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01674;
	Sun, 30 Sep 2001 23:33:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f916WPML001623
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 30 Sep 2001 23:32:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f916WO30001622
	for mobile-ip-dist; Sun, 30 Sep 2001 23:32:24 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f916WLML001615
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 23:32:21 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01616
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 23:32:24 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22438
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 30 Sep 2001 23:32:23 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA09260
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 16:30:41 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA11045
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 16:31:47 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXFJNY>; Mon, 1 Oct 2001 16:31:45 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ECD2@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Pekka Savola'" <pekkas@netcore.fi>
Cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco
	 very
Date: Mon, 1 Oct 2001 16:31:43 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> > >  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
> > > anycast address); this might scale better especially if IPv6 end-nodes
> are
> > > supposed to be simple.
> > >
> > 	=> Do you have any idea about how you can secure this BU ?
> > 	Why is this simpler than sendingit to the CN ?
> > 	What about deployment issues, like .. every router has to have MIPv6
> > 	in it ?
> 
> According to the specs, every IPv6 must be able to do most of these things
> anyway, so requiring routers should be able to do this does not seem like
> a too big additional requirement.
> 
	=> No, according to the specs every node SHOULD do it. If 
	a router doesn't do it, it affects the (potentially thousands)
	of CNs attached to it. 
	Anyway, making the routers do it will involve routers modifying
	dst addresses, breaking e2e ...etc which in itself is not 
	very secure at all.

> I'm not sure how BU can be secured.
> 
	=> Even more so to an anycast address.

> Why I thought it's simpler is simply because there are about two orders of
> magnitude less first-hop routers than hosts.  Which is still a lot, of
> course.
> 
	=> Sure, and there is a lot less NATs as well, but they don't make 
	the Internet any more scalable than e2e communication.

> > > Does anyone really believe that a washing machine, connected to an
> > > Intranet using IPv6, MUST be able to process e.g. Home Address
> Destination
> > > option, or SHOULD be able to process Binding Updates?, or
> > >
> > 	=> MUST. It's not that difficult really is it ? Especially if it can
> do
> > 	IPsec !
> 
> The simple processing of e.g. Home Address Option is easy.  But if you
> want to do it securely, it might get a lot more complicated.
> 
	=> IP address spoofing is not limited to the Home Address option
	and can happen regardless, unless you have the right access 
	control mechanisms.

> Current MIPv6 draft is long.  BU processing, after it is secured, takes a
> lot of that.
> 
	=> Yes but the goal was not to make the draft shorter. RFC2002 is
also
	long and it doesn't have route opt.

> > >  2) Reinstate FA's (e.g. by default all IPv6 routers that implement
> MIPv6)
> > > in the picture, or
> > >
> > >  3) Never mind route optimization, always tunnel back to HA
> > >
> > 	=> Hmmmm .... could you give reasons for why this is better ?
> 
> 2) For example, if there would be 1000 FA's in the world (found e.g. with
> anycast), the routes would be reasonably optimized, and ~1000 would still
> be a reasonable order of magnitude to manage security associations.
> 
	=> Why is managing an SA to a random router easier than a random
	CN ? Just because there are less of them, it doesn't mean it's
	easier. Also I don't think there will only be thousands of default 
	routers, probably much more like hundreds of thousands.

> The traffic could be sent using tunneling between CN -> "FA1" -> "FA2" ->
> MN.
> 
> I've not analyzed in detail whether this would actually help (can MN/CN
> trust FA's?), but if one brought the number of mobility management nodes
> to much lower rate, one _might_ be able to assume something about the key
> management.
> 
	=> Ok maybe a more detailed analysis would better illustrate the
validity of 
	this assumption.

> What I'm thinking is like current "6to4 router" [RFC3056] approach.
> 
> 3) is better (in some aspects) because CN's always send through the HA.
> This is a corner-case of mobilility.  You basically need only some basic
> framework and a tunnel.  Very simple to implement, and to get secure
> because HA-MN can be assumed to have some trust relation.  Only major
> problem is the route optimization..
> 
	=> Yep - route opt is the problem. 

> > 	MIPv6 is having a key exchange problem primarily and people are
> > 	trying to solve it, that is not a reason to start changing
> > everything.
> 
> Of course not, in itself, but consider:  the key exchange problem creates
> a very difficult set requirements.  In the end, it is probably impossible
> to fulfill these without compromises. 
> 
	=> The requirement is made based on the fact that there will be 
	some compromises. I believe our reference is the current IPv4
	Internet, which is by no means 100% secure.

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 06:05:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09729
	for <mobileip-archive@lists.ietf.org>; Mon, 1 Oct 2001 06:05:33 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04174;
	Mon, 1 Oct 2001 04:04:44 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13542;
	Mon, 1 Oct 2001 03:04:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91A3bML001878
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 03:03:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91A3a9F001877
	for mobile-ip-dist; Mon, 1 Oct 2001 03:03:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91A3WML001870
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 03:03:32 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13437
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 03:03:33 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28381
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 04:04:32 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f91A3PC01706;
	Mon, 1 Oct 2001 13:03:25 +0300
Date: Mon, 1 Oct 2001 13:03:25 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco 
 very
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ECD2@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110011253150.1611-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I'll respond to just a few remaining points here..

On Mon, 1 Oct 2001, Hesham Soliman (EPA) wrote:
> > > >  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
> > > > anycast address); this might scale better especially if IPv6 end-nodes
> > are
> > > > supposed to be simple.
> > > >
> > > 	=> Do you have any idea about how you can secure this BU ?
> > > 	Why is this simpler than sendingit to the CN ?
> > > 	What about deployment issues, like .. every router has to have MIPv6
> > > 	in it ?
> >
> > According to the specs, every IPv6 must be able to do most of these things
> > anyway, so requiring routers should be able to do this does not seem like
> > a too big additional requirement.
> >
> 	=> No, according to the specs every node SHOULD do it. If
> 	a router doesn't do it, it affects the (potentially thousands)
> 	of CNs attached to it.
> 	Anyway, making the routers do it will involve routers modifying
> 	dst addresses, breaking e2e ...etc which in itself is not
> 	very secure at all.

Tunneling.

> > > > Does anyone really believe that a washing machine, connected to an
> > > > Intranet using IPv6, MUST be able to process e.g. Home Address
> > Destination
> > > > option, or SHOULD be able to process Binding Updates?, or
> > > >
> > > 	=> MUST. It's not that difficult really is it ? Especially if it can
> > do
> > > 	IPsec !
> >
> > The simple processing of e.g. Home Address Option is easy.  But if you
> > want to do it securely, it might get a lot more complicated.
> >
> 	=> IP address spoofing is not limited to the Home Address option
> 	and can happen regardless, unless you have the right access
> 	control mechanisms.

Without Home Address Option, the sender's ISP can perform ingress
filtering thus preventing spoofing.  With HA Option, the validation is
impossible (it would have to be done in every end node -- not a chance)
with current mechanisms (HA Option should also be checked in ingress
filtering).

So, _at least with current mechanisms for packet filtering_, Home Address
Option poses a significant threat.

Of course, in practise, at least in IPv4, a lot of ISP's don't bother with
ingress spoofing checks...

I'm thinking of writing a short I-D on additional requirements for IPv6
packet filters/firewalls (home address option, routing headers, ...), I'll
probably do this if there is interest on this and this hasn't already been
tackled.

> > > >  2) Reinstate FA's (e.g. by default all IPv6 routers that implement
> > MIPv6)
> > > > in the picture, or
> > > >
> > > >  3) Never mind route optimization, always tunnel back to HA
> > > >
> > > 	=> Hmmmm .... could you give reasons for why this is better ?
> >
> > 2) For example, if there would be 1000 FA's in the world (found e.g. with
> > anycast), the routes would be reasonably optimized, and ~1000 would still
> > be a reasonable order of magnitude to manage security associations.
> >
> 	=> Why is managing an SA to a random router easier than a random
> 	CN ? Just because there are less of them, it doesn't mean it's
> 	easier. Also I don't think there will only be thousands of default
> 	routers, probably much more like hundreds of thousands.

It need not be necessarily first-hop router.  You could get significant
traffic optimization in most cases if it were 2nd or 3rd hop also.  And if
two nodes are on the same link, there might be other mechanisms for
optimization.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 11:13:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20038
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 11:13:43 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22751;
	Mon, 1 Oct 2001 08:12:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27135;
	Mon, 1 Oct 2001 08:12:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FBXML002221
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:11:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91FBW3E002220
	for mobile-ip-dist; Mon, 1 Oct 2001 08:11:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FBTML002213
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:11:29 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28028
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:11:30 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16294
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:11:25 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f91FBOQ17918
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 17:11:24 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA08445
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 17:11:22 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f91FBLD09691
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 17:11:21 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110011511.f91FBLD09691@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Security Requirements Draft 
In-reply-to: Your message of Fri, 28 Sep 2001 12:27:37 CDT.
             <933FADF5E673D411B8A30002A5608A0E2E43CE@zrc2c012.us.nortel.com> 
Date: Mon, 01 Oct 2001 17:11:21 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   I would like to float another proposed assumption and get feedback on this.
   
   3> That there is some sort of SA (perhaps dynamically created at initial
   access) between the ARs and the MN in the visited subnet.
   
=> I don't think this is a good idea because :
 - this is hard in some cases to get this SA
 - mobile IPv6 draft has "access control for visited networks" in non-goals.

But of course the existence (or not) of this SA is important for
some threats, so my concern is only about an assumption.

Regards

Francis.Dupont@enst-bretagne.fr

PS: about the other "drop everything (:-)" thread: I disagree the only
simple solution is to drop everything but I'd like to see the
anti-optimized/reverse-tunneling solution in mobile IPv6 document
because this is both simple and very secure.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 11:24:36 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20369
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 11:24:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28262;
	Mon, 1 Oct 2001 08:23:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00026;
	Mon, 1 Oct 2001 08:22:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FM4ML002295
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:22:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91FM4n2002294
	for mobile-ip-dist; Mon, 1 Oct 2001 08:22:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FM0ML002287
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:22:00 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24684
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:22:02 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14688
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:22:01 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.6/8.9.1) with ESMTP id f91FM2G25916;
	Mon, 1 Oct 2001 08:22:02 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAW02028;
	Mon, 1 Oct 2001 08:22:00 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03251; Mon, 1 Oct 2001 08:21:59 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15288.35351.798193.83923@thomasm-u1.cisco.com>
Date: Mon, 1 Oct 2001 08:21:59 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Charles E. Perkins" <charliep@IPRG.nokia.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: [mobile-ip] Re: Scalability of Binding Updates
In-Reply-To: <20010930074929.G16146@charizard.diameter.org>
References: <MJEMJBGGCLLDLFFAHLJKAEHFDGAA.fredrik.johansson@ipunplugged.com>
	<Roam.SIMC.2.0.6.1001495690.1688.nordmark@bebop.france>
	<15282.3298.522332.579900@thomasm-u1.cisco.com>
	<20010927205547.C1723@charizard.diameter.org>
	<15284.38307.873861.584422@t <3BB4A085.CCBEF66F@iprg.nokia.com>
	<20010930074929.G16146@charizard.diameter.org>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > I'm sure that the new solution will be much better, and will address
 > my concerns. I just didn't want to take Mike's BS that I was the one
 > involved in this one to try to show how AAA keys is bad.

   Unless you constitute the sum total of the MIP working
   group, I have not now, nor ever in the past implied that
   you personally have had anything to do with the BU security
   fiasco.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 11:33:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20646
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 11:33:31 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03597;
	Mon, 1 Oct 2001 08:32:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03006;
	Mon, 1 Oct 2001 08:32:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FVmML002374
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:31:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91FVmZp002373
	for mobile-ip-dist; Mon, 1 Oct 2001 08:31:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FVjML002366
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:31:45 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26837
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:31:46 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA07722
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 09:31:35 -0600 (MDT)
Received: (qmail 21044 invoked by uid 500); 1 Oct 2001 15:17:30 -0000
Date: Mon, 1 Oct 2001 08:17:30 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Michael Thomas <mat@cisco.com>
Cc: mobile-ip@sunroof.eng.sun.com,
        "Charles E. Perkins" <charliep@IPRG.nokia.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: Re: [mobile-ip] Re: Scalability of Binding Updates
Message-ID: <20011001081730.N19374@charizard.diameter.org>
References: <MJEMJBGGCLLDLFFAHLJKAEHFDGAA.fredrik.johansson@ipunplugged.com> <Roam.SIMC.2.0.6.1001495690.1688.nordmark@bebop.france> <15282.3298.522332.579900@thomasm-u1.cisco.com> <20010927205547.C1723@charizard.diameter.org> <15284.38307.873861.584422@t <3BB4A085.CCBEF66F@iprg.nokia.com> <20010930074929.G16146@charizard.diameter.org> <15288.35351.798193.83923@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15288.35351.798193.83923@thomasm-u1.cisco.com>; from mat@cisco.com on Mon, Oct 01, 2001 at 08:21:59AM -0700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, Oct 01, 2001 at 08:21:59AM -0700, Michael Thomas wrote:
> Pat Calhoun writes:
>  > I'm sure that the new solution will be much better, and will address
>  > my concerns. I just didn't want to take Mike's BS that I was the one
>  > involved in this one to try to show how AAA keys is bad.
> 
>    Unless you constitute the sum total of the MIP working
>    group, I have not now, nor ever in the past implied that
>    you personally have had anything to do with the BU security
>    fiasco.

Thanks... I obviously misread your statement, which you later clarified. This
e-mail (which wasn't supposed to be sent to the list) was sent prior to your
response that you were in fact not accusing me of this fiasco.

Thanks and my appologies for having put words in your mouth,

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 11:38:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20899
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 11:38:52 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13391;
	Mon, 1 Oct 2001 09:37:42 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04327;
	Mon, 1 Oct 2001 08:37:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FarML002433
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:36:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91FaqQq002432
	for mobile-ip-dist; Mon, 1 Oct 2001 08:36:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FanML002425
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:36:49 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27841
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:36:51 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09246
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 09:37:50 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA04195;
	Mon, 1 Oct 2001 08:36:41 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f91FaeU11400;
	Mon, 1 Oct 2001 08:36:40 -0700
X-mProtect:  Mon, 1 Oct 2001 08:36:40 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdFpPQXT; Mon, 01 Oct 2001 08:36:39 PDT
Message-ID: <3BB88D87.6EDB9F4@iprg.nokia.com>
Date: Mon, 01 Oct 2001 08:36:39 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@inria.fr>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Security Requirements Draft
References: <200110011511.f91FBLD09691@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Francis,

Your solution is already supposed to be "in there", because the
home agent is required to be able to decapsulated packets from
the mobile node.  If this point has somehow been lost since the
time I was originally editing the document, I will make sure that
it gets restored to the text.  Thus, I don't think there is anything
to be done, unless you would like to have an appendix that points
out explicitly that home agent decapsulation is valuable for use
with mobile nodes that don't wish to use the Home Address destination
option.

Also, I would like to point out that the Home Address destination
option was designed NOT to be a threat to ingress filtering, because
the home address of the sender is right there!  Putting your true
address into the packet is a very bad way to hide.  If the worry
has something to do about using the care-of address, then it has
nothing to do with Mobile IPv6 anyway, because any node can
autoconfigure a topologically correct address that would look
indistinguishable from the mobile node's use of such a topologically
correct address.

Regards,
Charlie P.



Francis Dupont wrote:
> 
>    I would like to float another proposed assumption and get feedback on this.
> 
>    3> That there is some sort of SA (perhaps dynamically created at initial
>    access) between the ARs and the MN in the visited subnet.
> 
> => I don't think this is a good idea because :
>  - this is hard in some cases to get this SA
>  - mobile IPv6 draft has "access control for visited networks" in non-goals.
> 
> But of course the existence (or not) of this SA is important for
> some threats, so my concern is only about an assumption.
> 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr
> 
> PS: about the other "drop everything (:-)" thread: I disagree the only
> simple solution is to drop everything but I'd like to see the
> anti-optimized/reverse-tunneling solution in mobile IPv6 document
> because this is both simple and very secure.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 11:44:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21077
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 11:43:59 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18587;
	Mon, 1 Oct 2001 09:43:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06475;
	Mon, 1 Oct 2001 08:43:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FgWML002509
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:42:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91FgWSU002508
	for mobile-ip-dist; Mon, 1 Oct 2001 08:42:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FgTML002501
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:42:29 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06195;
	Mon, 1 Oct 2001 08:42:30 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12716;
	Mon, 1 Oct 2001 09:43:30 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f91FgcP18865;
	Mon, 1 Oct 2001 08:42:38 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAW02396;
	Mon, 1 Oct 2001 08:42:23 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03254; Mon, 1 Oct 2001 08:42:23 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15288.36575.656655.120872@thomasm-u1.cisco.com>
Date: Mon, 1 Oct 2001 08:42:23 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: Michael Thomas <mat@cisco.com>,
        "Charles E. Perkins" <charliep@IPRG.nokia.com>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key
In-Reply-To: <20010930073919.B16146@charizard.diameter.org>
References: <Roam.SIMC.2.0.6.1001427527.14101.nordmark@bebop.france>
	<3BB15C81.DE5655DA@iprg.nokia.com>
	<20010927204724.A1723@charizard.diameter.org>
	<15284.63652.615358.830329@thomasm-u1.cisco.com>
	<20010930073919.B16146@charizard.diameter.org>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > >    Beyond Eric's clarification, I have a question:
 > >    You clearly must derive new keys from the MN/AAA
 > >    secret which if I remember correctly comes from
 > >    the AAA, encrypted in the MN/AAA key. What prevents
 > >    key reuse, especially for rekeying?
 > 
 > no key is ever sent encrypted or otherwise. All that is sent is keying
 > material, which the mobile uses to create the actual key. The key creation
 > process does require the long term MN/AAA key.

   You didn't answer my question. The question is
   how do you insure that new entropy is added to
   the keying material when you do things like
   rekeying? You can't just derive a new key from
   the old keying material via some one way hash
   generator; you need to add fresh entropy too
   from one or more (preferably) of the 
   participants (MN, HA, AAA).
 
 > > Is there a way
 > >    to get the AAA to supply fresh key material on demand?
 > >    If so, is the performance penalty going to be acceptible?
 > >    If not, is the expectation that one or both of the
 > >    ends of the SA supply entropy? If it's only one side,
 > >    what happens if their random number generator is not
 > >    very good, like oh say open("/dev/null")?
 > 
 > Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
 > to be sent to the mobile. So, using today's protocol, the answer is no.

   No to what? I'm guessing the first, and if so it
   doesn't necessarily need to be initiated by the
   AAA. If the MN can initiate which leads to the AAA
   supplying fresh entropy, that would suffice. With
   normal PPP/AAA, I don't think the host can cause the
   NAS to challenge it. I'm not sure if that's the case
   here.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 11:58:27 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21575
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 11:58:27 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01421;
	Mon, 1 Oct 2001 09:57:36 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11142;
	Mon, 1 Oct 2001 08:57:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FukML002672
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:56:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91FukuZ002671
	for mobile-ip-dist; Mon, 1 Oct 2001 08:56:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91FugML002664
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:56:42 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10937
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:56:44 -0700 (PDT)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02547
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 08:56:44 -0700 (PDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id <TWGJJ122>; Mon, 1 Oct 2001 11:56:42 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE460548DA@ftmail>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        Michael Thomas <mat@cisco.com>
Cc: "Charles E. Perkins" <charliep@IPRG.nokia.com>,
        Erik Nordmark
	 <Erik.Nordmark@eng.sun.com>
Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key
Date: Mon, 1 Oct 2001 11:56:41 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>


-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Sunday, September 30, 2001 3:39 PM
To: Michael Thomas
Cc: mobile-ip@sunroof.eng.sun.com; Charles E. Perkins; Erik Nordmark;
Pat Calhoun
Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key

...

> Is there a way
>    to get the AAA to supply fresh key material on demand?
>    If so, is the performance penalty going to be acceptible?
>    If not, is the expectation that one or both of the
>    ends of the SA supply entropy? If it's only one side,
>    what happens if their random number generator is not
>    very good, like oh say open("/dev/null")?

Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
to be sent to the mobile. So, using today's protocol, the answer is no.


GT> I have a different concern with a possible solution that may solve this
problem. 
We are implementing challenge/response with MN-AAA extensions and Radius as
AAA. As a Mobile Node (MN) comes in contact with a new FA, it receives an
Foreign Agent Advertisement (FAA) with a Challenge to which it responds with
a MIP Registration Request (RREQ) that includes MN-AAA authenticator. The FA
gets key material from AAA server and returns it to the Mobile Node (MN)
with the registration reply (RREP) so that an MN-FA key can be constructed.
The link layer happens to provide link up/link down triggers so that if the
MN looses contact with the FA we know it immediately. If the MN regains
contact in a short time, the FA senses it also immediately. 

->The problem with a standards based MIP client would be that on
reconnection and although the MN receives an FAA with a challenge, the
advertised FA is recoginsed as one that the MN has already registered with
and does not bother to register again thus, one can not check its MN-FA key
and verify the user is still the same.

No matter what the particular scenario is, however, I think this does not
make sense for any challenge/response protocol. The behaviour should be that
if you get a challenge you MUST respond to it. So, the proposed solution is:

"If a Mobile Node receives a *unicast* FAA WITH a Challenge then it MUST
send a Registration Request with an appropriate Response or face loss of
connectivity". Note that this does not mandate that all FAAs must now be
unicasted...but it does allow a network administrator to target a specific
mobile, challenge it individually and get its credetials.
On top of that, the above proposal would also make re-keying possible since
the FA can insert new Key material in the Registration Reply.

Thoughts?

George


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 13:06:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23686
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 13:06:12 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03239;
	Mon, 1 Oct 2001 11:05:20 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29718;
	Mon, 1 Oct 2001 10:05:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91H4MML002897
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:04:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91H4M5i002896
	for mobile-ip-dist; Mon, 1 Oct 2001 10:04:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91H4JML002889
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:04:19 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26068
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:04:17 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03088
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:04:16 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f91GxG718652
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:00:45 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAY00002;
	Mon, 1 Oct 2001 10:01:16 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA03290; Mon, 1 Oct 2001 10:01:14 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15288.41306.137426.736305@thomasm-u1.cisco.com>
Date: Mon, 1 Oct 2001 10:01:14 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] AAA keys design comment
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

It seems to me that there is a fundamental design
choice that was made in the AAA keys draft is
suboptimal. That is, the basic flow is to have the
AAA deliver keys to both the MN and the HA.  I
think that this is needlessly complex, has either
a race condition, or unneeded latency, and clearly
has an extra message that is not necessary. The
reason is because the MN always needs to register
with HA, so there is a natural and available round
trip that completes the triangle as effectively as
having the AAA doing it. The trick is to have the
AAA create an encrypted blob which is keyed in the
secret between AAAH and HA which the MN can
present to the HA along with an authenticator to
prove it posseses the MN/HA session key.  For
those knowledgeable about Kerberos, this should
look familiar.

A flow is in order here. I'll write this in terms
of Kerberos messages, but I'm not necessarily
saying that it needs to be Kerberos, per se.
The technique is what is important; the bits in
the air are another topic.

MN       FA          AAAF          AAAH             HA
---------->
AS-REQ[HA]
           ------------->
	   AAA+AS-REQ[HA]
                         ------------->
			 AAA+AS-REQ[HA]
                 
                        <--------------
			 AAA+AS-REP [tick HA]
           <------------
   	    AAA+AS-REP [tick HA]
<----------
 AAA+AS-REP [tick HA]

---------------------------------------------------->
AP-REQ [tick HA]

<----------------------------------------------------
AP-REP

Note that all we've done is remove the message
exchange between AAAH, and HA. This yields many 
advantages:

1) this mechanism can be reused for many different
   application at low cost since AAA doesn't need
   to be modified for each new application

2) the mechanism is more robust and properly
   fate shared in that a partition between AAAH 
   and HA will not cause a failure.

3) The latency or race condition between 
   AAA/MN and AAA/HA is eliminated

4) The round trip between AAA and HA is eliminated

5) There's very wide spread use of this approach;
   it's been around for over a decade

6) We _could_ directly use Kerberos messages,
   though I am sympathetic to the desire to have
   something that is less heavy weight if that
   were possible. I believe that directly using
   Kerberos would also provide a solution for
   the IESG criticism that there is an implicit
   expectation that AAAH and HA are in the same
   administrative domain (ie, directly share a
   secret); cross realm Kerberos and/or IAKERB 
   provides the needed functionality. Kerberos
   also brings the ability to use PKI based 
   authentication with PKINIT and PKCROSS. 

On other accounts, I believe that the protocols
are equivalently functional.

		 Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 13:54:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25275
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 13:54:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15596;
	Mon, 1 Oct 2001 11:53:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09558;
	Mon, 1 Oct 2001 10:53:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91HqKML003013
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:52:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91HqKJg003012
	for mobile-ip-dist; Mon, 1 Oct 2001 10:52:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91HqHML003005
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:52:17 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09319
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:52:18 -0700 (PDT)
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04823
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 10:52:17 -0700 (PDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <TXLGVL7Y>; Mon, 1 Oct 2001 13:52:17 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB35C0D40F@entmail.gnilink.com>
From: "Casassa, Nathan" <ncasassa@gnilink.net>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Mobile IP Agent Software
Date: Mon, 1 Oct 2001 13:52:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is likely a common question on this group, but I am looking for a
reliable software program that can be run on Windows PCs (95,98,NT,2000) to
act as the agent to listen for agent advertisement messages from a Cisco box
and will support the agent advertisement extension so I can get them on the
mobile IP network.

Nathan Casassa
Advanced Network Engineering/Architecture
Verizon Global Networks, Inc.

Desk - 703.295.4175
Lab   - 703.295.4123



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 15:18:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27907
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 15:18:34 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07506;
	Mon, 1 Oct 2001 12:17:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07341;
	Mon, 1 Oct 2001 12:17:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91JGHML003156
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 12:16:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91JGGTZ003155
	for mobile-ip-dist; Mon, 1 Oct 2001 12:16:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91JGBML003148
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 12:16:12 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23931
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 12:16:12 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25978
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 13:16:01 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA29334
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 14:16:11 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 1 Oct 2001 14:15:44 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LTAYL>; Mon, 1 Oct 2001 14:15:43 -0500
Message-ID: <52F74DDA50B5D211AF800000F808252108E64815@zrchb212.us.nortel.com>
From: "Kuntal Chowdhury" <chowdury@nortelnetworks.com>
To: pcalhoun@diameter.org, charliep@IPRG.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, diameter@diameter.org
Subject: [mobile-ip] DIAMETER support for MIP question
Date: Mon, 1 Oct 2001 14:15:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14AAD.706FB050"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14AAD.706FB050
Content-Type: text/plain;
	charset="iso-8859-1"

Pat/Charlie,
I am curious to know the implication on a mobile node when it sends 0.0.0.0
in the HA address field in MIP registration request for HA assignment in the
local network but the HA gets assigned in the home network. In section 4.2
in "draft-ietf-aaa-diameter-mobileip-02", there is an error code
"DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5007" which AAAF sends back to AAAH to
inform that it cannot assign a HA in the local network. In this case, does
the AAAH assign a HA in the home network? Does the mobile node get any
indication of this event? 

Regards,
Kuntal

------_=_NextPart_001_01C14AAD.706FB050
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>DIAMETER support for MIP question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Pat/Charlie,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I am curious to know the implication =
on a mobile node when it sends 0.0.0.0 in the HA address field in MIP =
registration request for HA assignment in the local network but the HA =
gets assigned in the home network. In section 4.2 in =
&quot;draft-ietf-aaa-diameter-mobileip-02&quot;, there is an error code =
&quot;DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5007&quot; which AAAF sends =
back to AAAH to inform that it cannot assign a HA in the local network. =
In this case, does the AAAH assign a HA in the home network? Does the =
mobile node get any indication of this event? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Kuntal</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14AAD.706FB050--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 21:28:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06651
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 21:28:35 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03509;
	Mon, 1 Oct 2001 18:27:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19293;
	Mon, 1 Oct 2001 18:27:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f921QVML003658
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 18:26:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f921QVvx003657
	for mobile-ip-dist; Mon, 1 Oct 2001 18:26:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f921QRML003650
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 18:26:27 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18195
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 18:26:29 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13684
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 18:26:28 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA17742
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 11:24:46 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA25737
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 11:25:51 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXFW15>; Tue, 2 Oct 2001 11:25:50 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ECD6@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Pekka Savola'" <pekkas@netcore.fi>
Cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco
	  very
Date: Tue, 2 Oct 2001 11:25:49 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> On Mon, 1 Oct 2001, Hesham Soliman (EPA) wrote:
> > > > >  1) MN's would send BU's to CN's first-hop routers (e.g.
> subnet-router
> > > > > anycast address); this might scale better especially if IPv6
> end-nodes
> > > are
> > > > > supposed to be simple.
> > > > >
> > > > 	=> Do you have any idea about how you can secure this BU ?
> > > > 	Why is this simpler than sendingit to the CN ?
> > > > 	What about deployment issues, like .. every router has to
> have MIPv6
> > > > 	in it ?
> > >
> > > According to the specs, every IPv6 must be able to do most of these
> things
> > > anyway, so requiring routers should be able to do this does not seem
> like
> > > a too big additional requirement.
> > >
> > 	=> No, according to the specs every node SHOULD do it. If
> > 	a router doesn't do it, it affects the (potentially thousands)
> > 	of CNs attached to it.
> > 	Anyway, making the routers do it will involve routers modifying
> > 	dst addresses, breaking e2e ...etc which in itself is not
> > 	very secure at all.
> 
> Tunneling.
> 
	=> I think you really need to work out the details if you simply
	want to tunnel to the default router. It'll be interesting 
	to see how you would:
	- Setup an SA with the default router
	- send BUs to it
	- Get it to intercept traffic and route it to the right destination
	Once you have a proposal for the above we can compare.


> > > > > Does anyone really believe that a washing machine, connected to an
> > > > > Intranet using IPv6, MUST be able to process e.g. Home Address
> > > Destination
> > > > > option, or SHOULD be able to process Binding Updates?, or
> > > > >
> > > > 	=> MUST. It's not that difficult really is it ? Especially
> if it can
> > > do
> > > > 	IPsec !
> > >
> > > The simple processing of e.g. Home Address Option is easy.  But if you
> > > want to do it securely, it might get a lot more complicated.
> > >
> > 	=> IP address spoofing is not limited to the Home Address option
> > 	and can happen regardless, unless you have the right access
> > 	control mechanisms.
> 
> Without Home Address Option, the sender's ISP can perform ingress
> filtering thus preventing spoofing.  With HA Option, the validation is
> impossible (it would have to be done in every end node -- not a chance)
> with current mechanisms (HA Option should also be checked in ingress
> filtering).
> 
> So, _at least with current mechanisms for packet filtering_, Home Address
> Option poses a significant threat.
> 
> Of course, in practise, at least in IPv4, a lot of ISP's don't bother with
> ingress spoofing checks...
> 
> I'm thinking of writing a short I-D on additional requirements for IPv6
> packet filters/firewalls (home address option, routing headers, ...), I'll
> probably do this if there is interest on this and this hasn't already been
> tackled.
> 
	=> Sounds good.

> > > > >  2) Reinstate FA's (e.g. by default all IPv6 routers that
> implement
> > > MIPv6)
> > > > > in the picture, or
> > > > >
> > > > >  3) Never mind route optimization, always tunnel back to HA
> > > > >
> > > > 	=> Hmmmm .... could you give reasons for why this is better
> ?
> > >
> > > 2) For example, if there would be 1000 FA's in the world (found e.g.
> with
> > > anycast), the routes would be reasonably optimized, and ~1000 would
> still
> > > be a reasonable order of magnitude to manage security associations.
> > >
> > 	=> Why is managing an SA to a random router easier than a random
> > 	CN ? Just because there are less of them, it doesn't mean it's
> > 	easier. Also I don't think there will only be thousands of default
> > 	routers, probably much more like hundreds of thousands.
> 
> It need not be necessarily first-hop router.  You could get significant
> traffic optimization in most cases if it were 2nd or 3rd hop also.  And if
> two nodes are on the same link, there might be other mechanisms for
> optimization.
> 
	=> That's fine, if you have a proposal for the above points 
	please publish it so we can see how this would work.


	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 22:14:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08406
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 22:14:12 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14252;
	Mon, 1 Oct 2001 19:13:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26484;
	Mon, 1 Oct 2001 19:13:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f922CCML003767
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 19:12:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f922CCRd003766
	for mobile-ip-dist; Mon, 1 Oct 2001 19:12:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f922C8ML003759
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 19:12:09 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23744
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 19:12:10 -0700 (PDT)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02144
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 19:12:09 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C14AE7.A093FE1E"
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
Subject: RE: [mobile-ip] Security Requirements Draft
Date: Mon, 1 Oct 2001 22:12:03 -0400
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB21068B56@EXCHANGE01.domain.ecutel.com>
X-MS-TNEF-Correlator: <AF2378CBE7016247BC0FD5261F1EEB21068B56@EXCHANGE01.domain.ecutel.com>
Thread-Topic: [mobile-ip] Security Requirements Draft
Thread-Index: AcFKkEFE4k9UBEtzSvuW1lvuVQOGTwAVQ8i9
From: "Qiang Zhang" <qzhang@ecutel.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C14AE7.A093FE1E
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

IA0KIA0KIA0KDQoJQ2hhcmxpZSBhbmQgYWxsLA0KCSANCglEbyB5b3UgdGhpbmsgaXQgbWF5IGJl
IHVzZWZ1bCB0byBkZWZpbmUgYSBtb2RlIGluIHRoZSBNSVB2NiBiYXNlDQpmb3IgdGhlIE1OIHRv
IGNob29zZSB1c2luZyByZXYtdHVubmVsIG9ubHk/IFRoYXQgd2F5IGl0IG1heSBiZQ0KYmVuZWZp
Y2lhbCB0byBzb21lIHVzYWdlIG1vZGVscywgZm9yIGV4YW1wbGUsIHRvIGFjaGl2ZSBNTidzIGxv
Y2F0aW9uDQpwcml2YWN5IChubyBCVSBzZW50IHRvIENOLCBuZWl0aGVyIGZyb20gSEEgbm9yIE1O
KSBhbmQgYWxzbyBjb250cm9sbGVkDQphY2Nlc3MgcG9saWN5IGNhbiBiZSBpbXBvc2VkIGZvciB0
aGUgTU4gZnJvbSBob21lIG5ldHdvcmsuDQoJIA0KCU9yIHdvdWxkIHRoaXMgYmUgbGVmdCB0byBp
bXBsZW1lbnRhdGlvbnMgdG8gZGVmaW5lIGl0cyBvd24/IA0KCSANCglUaGFua3MNCglRaWFuZw0K
CSANCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBDaGFybGVzIEUuIFBlcmtp
bnMgDQoJU2VudDogTW9uIDEwLzEvMjAwMSAxMTozNiBBTSANCglUbzogRnJhbmNpcyBEdXBvbnQg
DQoJQ2M6IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tIA0KCVN1YmplY3Q6IFJlOiBbbW9i
aWxlLWlwXSBTZWN1cml0eSBSZXF1aXJlbWVudHMgRHJhZnQNCgkNCgkNCg0KCUhlbGxvIEZyYW5j
aXMsDQoJDQoJWW91ciBzb2x1dGlvbiBpcyBhbHJlYWR5IHN1cHBvc2VkIHRvIGJlICJpbiB0aGVy
ZSIsIGJlY2F1c2UgdGhlDQoJaG9tZSBhZ2VudCBpcyByZXF1aXJlZCB0byBiZSBhYmxlIHRvIGRl
Y2Fwc3VsYXRlZCBwYWNrZXRzIGZyb20NCgl0aGUgbW9iaWxlIG5vZGUuICBJZiB0aGlzIHBvaW50
IGhhcyBzb21laG93IGJlZW4gbG9zdCBzaW5jZSB0aGUNCgl0aW1lIEkgd2FzIG9yaWdpbmFsbHkg
ZWRpdGluZyB0aGUgZG9jdW1lbnQsIEkgd2lsbCBtYWtlIHN1cmUNCnRoYXQNCglpdCBnZXRzIHJl
c3RvcmVkIHRvIHRoZSB0ZXh0LiAgVGh1cywgSSBkb24ndCB0aGluayB0aGVyZSBpcw0KYW55dGhp
bmcNCgl0byBiZSBkb25lLCB1bmxlc3MgeW91IHdvdWxkIGxpa2UgdG8gaGF2ZSBhbiBhcHBlbmRp
eCB0aGF0DQpwb2ludHMNCglvdXQgZXhwbGljaXRseSB0aGF0IGhvbWUgYWdlbnQgZGVjYXBzdWxh
dGlvbiBpcyB2YWx1YWJsZSBmb3IgdXNlDQoJd2l0aCBtb2JpbGUgbm9kZXMgdGhhdCBkb24ndCB3
aXNoIHRvIHVzZSB0aGUgSG9tZSBBZGRyZXNzDQpkZXN0aW5hdGlvbg0KCW9wdGlvbi4NCgkNCglB
bHNvLCBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIEhvbWUgQWRkcmVzcw0KZGVz
dGluYXRpb24NCglvcHRpb24gd2FzIGRlc2lnbmVkIE5PVCB0byBiZSBhIHRocmVhdCB0byBpbmdy
ZXNzIGZpbHRlcmluZywNCmJlY2F1c2UNCgl0aGUgaG9tZSBhZGRyZXNzIG9mIHRoZSBzZW5kZXIg
aXMgcmlnaHQgdGhlcmUhICBQdXR0aW5nIHlvdXINCnRydWUNCglhZGRyZXNzIGludG8gdGhlIHBh
Y2tldCBpcyBhIHZlcnkgYmFkIHdheSB0byBoaWRlLiAgSWYgdGhlIHdvcnJ5DQoJaGFzIHNvbWV0
aGluZyB0byBkbyBhYm91dCB1c2luZyB0aGUgY2FyZS1vZiBhZGRyZXNzLCB0aGVuIGl0IGhhcw0K
CW5vdGhpbmcgdG8gZG8gd2l0aCBNb2JpbGUgSVB2NiBhbnl3YXksIGJlY2F1c2UgYW55IG5vZGUg
Y2FuDQoJYXV0b2NvbmZpZ3VyZSBhIHRvcG9sb2dpY2FsbHkgY29ycmVjdCBhZGRyZXNzIHRoYXQg
d291bGQgbG9vaw0KCWluZGlzdGluZ3Vpc2hhYmxlIGZyb20gdGhlIG1vYmlsZSBub2RlJ3MgdXNl
IG9mIHN1Y2ggYQ0KdG9wb2xvZ2ljYWxseQ0KCWNvcnJlY3QgYWRkcmVzcy4NCgkNCglSZWdhcmRz
LA0KCUNoYXJsaWUgUC4NCgkNCgkNCgkNCglGcmFuY2lzIER1cG9udCB3cm90ZToNCgk+DQoJPiAg
ICBJIHdvdWxkIGxpa2UgdG8gZmxvYXQgYW5vdGhlciBwcm9wb3NlZCBhc3N1bXB0aW9uIGFuZCBn
ZXQNCmZlZWRiYWNrIG9uIHRoaXMuDQoJPg0KCT4gICAgMz4gVGhhdCB0aGVyZSBpcyBzb21lIHNv
cnQgb2YgU0EgKHBlcmhhcHMgZHluYW1pY2FsbHkNCmNyZWF0ZWQgYXQgaW5pdGlhbA0KCT4gICAg
YWNjZXNzKSBiZXR3ZWVuIHRoZSBBUnMgYW5kIHRoZSBNTiBpbiB0aGUgdmlzaXRlZCBzdWJuZXQu
DQoJPg0KCT4gPT4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgZ29vZCBpZGVhIGJlY2F1c2UgOg0K
CT4gIC0gdGhpcyBpcyBoYXJkIGluIHNvbWUgY2FzZXMgdG8gZ2V0IHRoaXMgU0ENCgk+ICAtIG1v
YmlsZSBJUHY2IGRyYWZ0IGhhcyAiYWNjZXNzIGNvbnRyb2wgZm9yIHZpc2l0ZWQgbmV0d29ya3Mi
DQppbiBub24tZ29hbHMuDQoJPg0KCT4gQnV0IG9mIGNvdXJzZSB0aGUgZXhpc3RlbmNlIChvciBu
b3QpIG9mIHRoaXMgU0EgaXMgaW1wb3J0YW50DQpmb3INCgk+IHNvbWUgdGhyZWF0cywgc28gbXkg
Y29uY2VybiBpcyBvbmx5IGFib3V0IGFuIGFzc3VtcHRpb24uDQoJPg0KCT4gUmVnYXJkcw0KCT4N
Cgk+IEZyYW5jaXMuRHVwb250QGVuc3QtYnJldGFnbmUuZnINCgk+DQoJPiBQUzogYWJvdXQgdGhl
IG90aGVyICJkcm9wIGV2ZXJ5dGhpbmcgKDotKSIgdGhyZWFkOiBJIGRpc2FncmVlDQp0aGUgb25s
eQ0KCT4gc2ltcGxlIHNvbHV0aW9uIGlzIHRvIGRyb3AgZXZlcnl0aGluZyBidXQgSSdkIGxpa2Ug
dG8gc2VlIHRoZQ0KCT4gYW50aS1vcHRpbWl6ZWQvcmV2ZXJzZS10dW5uZWxpbmcgc29sdXRpb24g
aW4gbW9iaWxlIElQdjYNCmRvY3VtZW50DQoJPiBiZWNhdXNlIHRoaXMgaXMgYm90aCBzaW1wbGUg
YW5kIHZlcnkgc2VjdXJlLg0KCQ0KDQo=

------_=_NextPart_001_01C14AE7.A093FE1E
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgkCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD
AA4AAADRBwoAAQAWAAwAAwABAAkBASCAAwAOAAAA0QcKAAEAFgAMAAYAAQAMAQEJgAEAIQAAAEE0
Njg4MDRBNEY3NkVCNDhBM0ExOEEyQUNCMUI3N0U4AE8HAQOQBgD4FwAAOQAAAB8AGgABAAAAEgAA
AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAFgAAABSAEUAOgAgAFsAbQBvAGIA
aQBsAGUALQBpAHAAXQAgAFMAZQBjAHUAcgBpAHQAeQAgAFIAZQBxAHUAaQByAGUAbQBlAG4AdABz
ACAARAByAGEAZgB0AAAAQAA5AB7+k6DnSsEBHwA9AAEAAAAKAAAAUgBFADoAIAAAAAAAAgFHAAEA
AAAxAAAAYz11czthPSA7cD1FY3V0ZWw7bD1FWENIQU5HRTAxLTAxMTAwMjAyMTIwM1otNTE5AAAA
AB8ASQABAAAAWAAAAFIAZQA6ACAAWwBtAG8AYgBpAGwAZQAtAGkAcABdACAAUwBlAGMAdQByAGkA
dAB5ACAAUgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAIABEAHIAYQBmAHQAAABAAE4AgF2a3I5KwQEf
AFoAAQAAACYAAABDAGgAYQByAGwAZQBzACAARQAuACAAUABlAHIAawBpAG4AcwAAAAAAAgFbAAEA
AABIAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAQ2hhcmxlcyBFLiBQZXJraW5zAFNNVFAAY2hh
cmxpZXBAaXByZy5ub2tpYS5jb20AAgFcAAEAAAAdAAAAU01UUDpDSEFSTElFUEBJUFJHLk5PS0lB
LkNPTQAAAAAfAF0AAQAAACYAAABDAGgAYQByAGwAZQBzACAARQAuACAAUABlAHIAawBpAG4AcwAA
AAAAAgFeAAEAAABIAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAQ2hhcmxlcyBFLiBQZXJraW5z
AFNNVFAAY2hhcmxpZXBAaXByZy5ub2tpYS5jb20AAgFfAAEAAAAdAAAAU01UUDpDSEFSTElFUEBJ
UFJHLk5PS0lBLkNPTQAAAAAfAGYAAQAAAAoAAABTAE0AVABQAAAAAAAfAGcAAQAAADAAAABjAGgA
YQByAGwAaQBlAHAAQABpAHAAcgBnAC4AbgBvAGsAaQBhAC4AYwBvAG0AAAAfAGgAAQAAAAoAAABT
AE0AVABQAAAAAAAfAGkAAQAAADAAAABjAGgAYQByAGwAaQBlAHAAQABpAHAAcgBnAC4AbgBvAGsA
aQBhAC4AYwBvAG0AAAAfAHAAAQAAAFAAAABbAG0AbwBiAGkAbABlAC0AaQBwAF0AIABTAGUAYwB1
AHIAaQB0AHkAIABSAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwAgAEQAcgBhAGYAdAAAAAIBcQABAAAA
GwAAAAHBSpBBROJPVARLc0r7ltZb7lUDhk8AFUPIvQAfAHMAAQAAADwAAABtAG8AYgBpAGwAZQAt
AGkAcABAAHMAdQBuAHIAbwBvAGYALgBlAG4AZwAuAHMAdQBuAC4AYwBvAG0AAAAfAHQAAQAAAB4A
AABGAHIAYQBuAGMAaQBzACAARAB1AHAAbwBuAHQAAAAAAB8AGgwBAAAAGAAAAFEAaQBhAG4AZwAg
AFoAaABhAG4AZwAAAB8AHQ4BAAAAUAAAAFsAbQBvAGIAaQBsAGUALQBpAHAAXQAgAFMAZQBjAHUA
cgBpAHQAeQAgAFIAZQBxAHUAaQByAGUAbQBlAG4AdABzACAARAByAGEAZgB0AAAAAgEJEAEAAACn
DgAAow4AAL81AABMWkZ1N0HEZwMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jB
CsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2W8S6xHjCO8J9zsYzw4w
NTsR0gxgYwBQCwkBZDM2kxFgC6U0IBACKlwOsr0BkGcU8AqjEeMd6DQU8AA8IURPQ1RZUABFIEhU
TUwgUABVQkxJQyAiLSAvL1czQyGARFQiRCCUMy4yIYBFTpwiPh7tHo8jwTE4H/BvIKIjDyQfJpAz
HYAlcEV8QUQlzQ7xJu8pbyT0NkEO8DxNRVRBB7BBMSxgPSJHCfAEkGF0RQWwIhLQT05UItBUEyzw
BeFFeBDxbmdlPQZSdhMxL0EAkAIgIDawLjAuNAHBIpA1Iv4TKs8lAzc3H/BUSVQUTEUlzjQO8FJl
OpQgWwRgYgMQZS0FIEpdBlFjCHF0eTTBcbx1aRjQB4ACMAQgRC1Q6wGAJG41H/AvM18xjyZFXzSh
OKAoTyafPHQ1EWA8QEJPRFkgZDagPX08kHI74DxTACEDMD7xZM5vAOA+8QqxXHEYsD7xfxDwAzA/
VRFgPAsc8T0PZ8Q5Nh/wRElWPykAALNBZzwpNjREn0G/OB2AYCZuYnNwAoA/SCf+YQFARV88oQHA
PzcKoj83+wpxJHwwKBEh4ERrTIhB7/9C/0QPRR9GL0c/SE9JX1N//0t/TI9Nn06vVc9Qz1HfVQ//
U/9g/1YfVy9YP1lPWl9bbz9cf2OfXp9fqyEQIDBLUcxVTy3wPqYgczYwNWABLjFBUkdJTi1SjElH
IKA08DBweCLx/z9ICrEQAkBVQPNAsUFPbI//HxsRYHZgbW9gb2Z/Yo9zh60/0Gkc0iR8NCVRRi3R
6W+gaXpv8DJ36wvic2leQxEBe3Au8ABwZH/QbNRsLCR8NXeBL3zyas//Zr9nz2jfae+CD3P/dQ92
H/93L3pfeU+Mf3tvZM9l34Mf/4QvhT+GT4dfiG+Jf4qPi59/jK+Nv47Pj998r32/l3hEiG8geQhg
IHRoC4C0ayA2ICAAwDZAYi7w8nURMGZ1AyAtcD6gARD/C4B/waRQBHGkIAOgo9Au8PBNSVB2m4A6
jJj/kLTpmnFiYREwIAIQBcCmg+ZOpTIQ8G9vqcGk0AuABGcgGNB2LXR1bgctMAMgAiBseT8gVPsR
AAVAd6RxpDikoC0wpZC+Ywcxpx+oL6k1pUFzA3CPpLI8sC7wBGJscyyp49BleGFtC1BlslClQW8A
0KPgL0CqYScEIBhgY2stYC/CcAUQdgDQNkAo8m6jcEJVb6A24a6Pr5/5sKhDTrJQLTA2IKaQBcCf
A1IgkCyQtVAFwU4pf9V/sUCqwAIhA2CAMAmAs2Fj+weQBCBwBvAN4DZAtFADoP+kobYPtx+pRAdw
vCARMIAAn6n5uXOq4LFhLTB0dwWw/GsugG+Bf4KPk1+Ub5V//5aPl5+Yr5m/ms+b38RPnf//nw+Q
X5Fvzn/FP8ZPx1/Ib//Jf8qPy5/Mr8/fzs/df9Dv96BPoV9+bk8FwMGApRCAAP+j0QQgpKE1YAGA
pTK/gTVgPzbStGMEIKVINiAEIG93/m6skL0P2p+pRMHfwu/D///Uz9Xf1u/X/9kP2h/bL9w//91P
7Y/fb+B/0c/S3/e/7n//74/wn/Gv8r/zz/Tf9e/5H//4Dwa/+i/hv+LPfm6ssaQA/nPrH+wv7T/+
D/8fAC8BP/8CTwNfBG8FfwaPEO8Irwm/7wrPC98M7xZAUa5QLtAOf/8PjxCfEa8SvxPPFN8V7xb/
/xgPGR8aLyR/HE8dX/sP/B//Lq8lbyZ/J48onymvKr8rz/8s3zAPLv89rzEfHp8fr35uZi1FAuTQ
aWeloK5hTa+74bGxRQNBbTFuUlJxSn9BEMFQObA5HzInbnA9i2LVc2lGuYE6PEwyN/FKysc5CX9U
u+AgRS7ojzq/9ak1ULlAa6Wg5ZBGv0fP70jfSe9K/1WkU7XBTK9Nv41Ox020kTfALzEvfpAkMDFb
0DE6QTAgQX5NUv9UD1UfVi9XPw2mb39Y/1oPTsdMYLygrkDlkET+dbwgtd9Q7+qPXZ9er1+/82DP
S31DY2LvY/9Ox6YABGJpu3AtaXBAcyOr8LtAb2YurfBnLv1yIS67ALmgaQ9qH2svbD+DbU9YVXVi
amVjWO/jb99OuFJlOmZ/Z4+pNUpbcYddWKFjdbTQdOO1IHwwcXVpq6DmsmXx/2Wg5gBzb3R/dY+B
n4Kvg7n/eu80bzV/No83n4efOw1CYb8jJTm/fY873z9jjABQhap/kFGGr0AfQS9CP0NPRFlI96wg
tDBlhiyEb4V/g4+bDzucH50pWaOguhCxQGx1z7RzZeG6sKugYWS1IHIgvnC/pKVBvN+QP6kXIufA
+8Ayq6AislCt4LyQsZCtwP+qMZ3fnu+c/MEDsbFmUWXh54CQgGOi1mFiu3DnVLyQ+nByIGy0YLuB
o1+kb2ik+a5gY2vBYOWQuXKnT6hf/5z8wEJxhLnh55DBzDKPM578IEkzkOVjvCDnwGZgDiDv5ZC6
0KpgwQB35aFyoOXQ/7+wZm+uX78Gl9BlwKb/sW9vsn+zgeZg5+BJ5PC4gW+9RWVsgCCiwOgA58Bn
s5P8ZG9/0OaypnDAMXGwRcD8bWGwEKJRgJC5z7rfr3W/5WDm8Lzvvf+c/OgAIEYwf4DhgJC5oMCQ
osSzoq0geP50tJ+1r7a8DhCm0MKCwgD8bifmEeVwDkCmBKGiw7/3xM9opGWwec8SIf3HX8hve6L0
zrFlpnByME+R5ZB5v+UQ5PWWAMMx52EOIHar8duhkKzAcHKgwVB4s5Hm8P/P/9EPr3a4Ig5t0+/U
/+UQ19mQywDmgGll0HTBEdljV6pJrJihdXZFsHWsE2b/wJDZr9q/r3Wm0dyf3a+c/H/CwLfAs9qw
QNljzrTCwHMf6UDYIabVmeCqUkFkZP/J8c/v5F+vZunxwXHiA+Yf++cv3r1woWLLPPC/8c+dz/P0
X/VtQWyhIMKD14u4FP/fktlj66fsv+3PaKTsNu8///a/98/ybMBD6fFFcPVwrUD8Tk+XsKu1s5Gi
Ac7xmjDv0tHsb/z/rzlmcbCtIEVg/yHgpnf/7wD/ss+qNexFcnD/s5Om4NkQpjCq40VwzMCmBP4h
y0/MX7bLBg8HH1IloVDHwXPXMaEAdHJ1CZ8Kr//1bQ02uDHKlK/koaPigKYwvYAgYqIgwEHgYdgx
abR//xBvEX8SjxOfaLO3k7PA13D+chrwFg8XH6ltuIXSs6xTf5owrBDfkqbQwYassICQLf8NsQ01
pnCmEaGR2Z8gD69m/7hxIl8jb/V8tFAl2ukTW6DxtANJUHYswNKBG2GmeP/SgbRDKR8qL691rLD/
3yzf3xgeoVDCEGZACIBnw3IEwfvy4KEwb0WArLDBAnMgIiD/eVENJ9lj13QyXzNvaKSaIPxvazUP
Nh/IndkR/1I4kO/q8eLUsHGzniewQKbSDbH9ciBj6UAEwDufPK/F1Tka/z5fP2/1fDnt809JH/Vv
TD/XTU9OWnwwZ0XQZJq/UA/1Th5DK6BylgAyP0W/FHf/TA9Tn04vWN9Z71r/XA9dH/9eL18/YE9h
VJpVgQCicKGAf+rBsHCtIHmMYo9jn3ZfJvRndB15PmhvZn9nj2sv/2mvar8cXx1vcJ9xr3K/c89/
dN8eD8AwVh9XL6V013xm35og2YGacC7hDmFwsHCilPu4gKJgbQL0mnA7cMmhsFD9uUBkGyCwAMCA
oZB5/3sP/8XWGoBYr2yfba9uv2/Phj//hE+FX4Zvh3+Lj3dveH+Ob9+Pf5CPkZ+Sr7baM5RvjS9/
zbj7dM+kuLKhEZYgDaJTrkGAr4G/pWUo2PByK6DrrNCsgHnA4G05dgUCfpL9qtFuwWE5kIkfii+L
P5ef/5ivo5+VP5Nvpn+nj6ifqa/fqr+3JRogvIDXACmb35zvM9vFBJB0d7lCs6JBUmcakX+BGdJN
TkFBGcN27xqAwWDKUcNgYqLwyy2hr/+iv6wfpN+3r7W/ts+6b7jv/Zk7Pb2/vs95X7AP7j/Oy/sa
gRqDZz4gO3Ab4QTAMUb/Zf+7v7zPwI/Bn8rvrO+t//wgLcZXVaHHMeJAmuPDL//EPzR263DqESZw
f7LGY5uw/8g/yU/KX8tvzH/Yr86fz6/P0LDpZTBz7FBhZuCxJWHeIq8UOdH64EKAbOMf0u+Pgom0
NrThIgFrcyKzsvkyAG4txwA5kINv1t/X7//Y/9oP6D/mT+df6G/pf5lZfkL7IZuBOEAVkDGRGdJl
/nhBgSjArzDhH+Ivnfbg8d8u0a9wDbPVkw6CaX8Am0H/f3B/0Tnw6y/sP+1P7l/vb/+Zs9HTBOQo
cdHQ3nA5wvJB/nIo0QXv83+CtgMgObEmlP9/cH655Y/4T/lf+m/7fwWf/wOvBL8FzwbfmWhSFQh/
CY//Cp8Lrwy/EU8PXxBvEX8Sj68ej/9fgk1ktS5lNEAowLlBkC1iOpAUsRYwLkJw/xQfFS8WPxdP
GF8g7x7/IA/HIR8iL5l3UFM6AZWz8n191CI6gDkQGa8av4LFZQp2fgB5LvQoOi0p++Sg/TNkKXDD
AEFxK6A6kP/xhAFSI78kzyXfJu8n//yU9/ZxQkHR0GwB0H8y0SF9IV8q/ywPxUUqsi15YgHRSf4n
fLh+gPGDMD8xTzJfM2+fNH8Zbzf/gon20WktKsDrfyCfMHqAEC9LwC2BfoDwLXR1bj5APiEuADZI
s+TQ3otvY37wsmB0PC//PT8+Tz9fQG9Bf0KPsWvHxP/GZgGwspA1xn9yLYJN707zf36AR/CagALf
SV9Kb1SqNcFVcS9GT05UVcnc1/8jkEymTuJZqFbITtNWz05GtDcyWIFQVcBUjDBOwAFYkEJMT0NL
UVXYT1RFWP9dH2daMU7/E2KvTnM1OF+yT0RZL16dXkBkL2axN1iBSFQUTUxVwH1o4AAfADUQAQAA
AIwAAAA8AEEARgAyADMANwA4AEMAQgBFADcAMAAxADYAMgA0ADcAQgBDADAARgBEADUAMgA2ADEA
RgAxAEUARQBCADIAMQAwADYAOABCADUANgBAAEUAWABDAEgAQQBOAEcARQAwADEALgBkAG8AbQBh
AGkAbgAuAGUAYwB1AHQAZQBsAC4AYwBvAG0APgAAAB8ARxABAAAAHgAAAG0AZQBzAHMAYQBnAGUA
LwByAGYAYwA4ADIAMgAAAAAACwDyEAEAAAAfAPMQAQAAAGQAAABSAEUAJQAzAEEAIABbAG0AbwBi
AGkAbABlAC0AaQBwAF0AIABTAGUAYwB1AHIAaQB0AHkAIABSAGUAcQB1AGkAcgBlAG0AZQBuAHQA
cwAgAEQAcgBhAGYAdAAuAEUATQBMAAAACwD2EAAAAABAAAcwXuxnUOVKwQFAAAgwfPt3oudKwQED
AN4/6f0AAAMA8T8JBAAAHwD4PwEAAAAYAAAAUQBpAGEAbgBnACAAWgBoAGEAbgBnAAAAAgH5PwEA
AABcAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUVDVVRFTC9PVT1GSVJTVCBBRE1J
TklTVFJBVElWRSBHUk9VUC9DTj1SRUNJUElFTlRTL0NOPVFaSEFORwAfAPo/AQAAACoAAABTAHkA
cwB0AGUAbQAgAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADc
p0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAA
AAADAB5AAAAAAB8AMEABAAAADgAAAFEAWgBIAEEATgBHAAAAAAAfADFAAQAAAA4AAABRAFoASABB
AE4ARwAAAAAAHwAyQAEAAAAwAAAAYwBoAGEAcgBsAGkAZQBwAEAAaQBwAHIAZwAuAG4AbwBrAGkA
YQAuAGMAbwBtAAAAHwAzQAEAAAAwAAAAYwBoAGEAcgBsAGkAZQBwAEAAaQBwAHIAZwAuAG4AbwBr
AGkAYQAuAGMAbwBtAAAAHwA4QAEAAAAOAAAAUQBaAEgAQQBOAEcAAAAAAB8AOUABAAAABAAAAC4A
AAALACkAAAAAAAsAIwAAAAAAAwAGECc3wT0DAAcQAwgAAAMAEBAAAAAAAwAREAEAAAAeAAgQAQAA
AGUAAABDSEFSTElFQU5EQUxMLERPWU9VVEhJTktJVE1BWUJFVVNFRlVMVE9ERUZJTkVBTU9ERUlO
VEhFTUlQVjZCQVNFRk9SVEhFTU5UT0NIT09TRVVTSU5HUkVWLVRVTk5FTE9OTFk/AAAAAAIBfwAB
AAAARgAAADxBRjIzNzhDQkU3MDE2MjQ3QkMwRkQ1MjYxRjFFRUIyMTA2OEI1NkBFWENIQU5HRTAx
LmRvbWFpbi5lY3V0ZWwuY29tPgAAAP2S

------_=_NextPart_001_01C14AE7.A093FE1E--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  1 23:55:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11830
	for <mobileip-archive@odin.ietf.org>; Mon, 1 Oct 2001 23:55:02 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20599;
	Mon, 1 Oct 2001 21:54:15 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03131;
	Mon, 1 Oct 2001 20:54:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f923rBML003908
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 20:53:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f923rBT5003907
	for mobile-ip-dist; Mon, 1 Oct 2001 20:53:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f923r7ML003900
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 20:53:07 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03063
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 20:53:10 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20234
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 21:52:58 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA01295
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:51:27 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA28484
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:52:32 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXF557>; Tue, 2 Oct 2001 13:52:31 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ECD9@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Security Requirements Draft
Date: Tue, 2 Oct 2001 13:52:30 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14AF5.A8BFCE70"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14AF5.A8BFCE70
Content-Type: text/plain

Hi, 

I thought that section existed already, but now it seems that 
rev 14 only has that section in the HA operation part. Ch 9.5

As far as the MN is concerned it's really an internl policy
decision within the MN itself and doesn't have protocol 
impacts. 
Last time I worked on our implementation we had a 
configuration option for this in the MN. 

Maybe some text for the MN operation would help clarify
that it is a configuration / policy issue for the MN.

Cheers,
Hesham

> -----Original Message-----
> From:	Qiang Zhang [SMTP:qzhang@ecutel.com]
> Sent:	Tuesday, 2 October 2001 12:12
> To:	mobile-ip@sunroof.eng.sun.com
> Subject:	RE: [mobile-ip] Security Requirements Draft
> 
>  
>  
>  
> 
> 	Charlie and all,
> 	 
> 	Do you think it may be useful to define a mode in the MIPv6 base for
> the MN to choose using rev-tunnel only? That way it may be beneficial to
> some usage models, for example, to achive MN's location privacy (no BU
> sent to CN, neither from HA nor MN) and also controlled access policy can
> be imposed for the MN from home network.
> 	 
> 	Or would this be left to implementations to define its own? 
> 	 
> 	Thanks
> 	Qiang
> 	 
> 	-----Original Message----- 
> 	From: Charles E. Perkins 
> 	Sent: Mon 10/1/2001 11:36 AM 
> 	To: Francis Dupont 
> 	Cc: mobile-ip@sunroof.eng.sun.com 
> 	Subject: Re: [mobile-ip] Security Requirements Draft
> 	
> 	
> 
> 	Hello Francis,
> 	
> 	Your solution is already supposed to be "in there", because the
> 	home agent is required to be able to decapsulated packets from
> 	the mobile node.  If this point has somehow been lost since the
> 	time I was originally editing the document, I will make sure that
> 	it gets restored to the text.  Thus, I don't think there is anything
> 	to be done, unless you would like to have an appendix that points
> 	out explicitly that home agent decapsulation is valuable for use
> 	with mobile nodes that don't wish to use the Home Address
> destination
> 	option.
> 	
> 	Also, I would like to point out that the Home Address destination
> 	option was designed NOT to be a threat to ingress filtering, because
> 	the home address of the sender is right there!  Putting your true
> 	address into the packet is a very bad way to hide.  If the worry
> 	has something to do about using the care-of address, then it has
> 	nothing to do with Mobile IPv6 anyway, because any node can
> 	autoconfigure a topologically correct address that would look
> 	indistinguishable from the mobile node's use of such a topologically
> 	correct address.
> 	
> 	Regards,
> 	Charlie P.
> 	
> 	
> 	
> 	Francis Dupont wrote:
> 	>
> 	>    I would like to float another proposed assumption and get
> feedback on this.
> 	>
> 	>    3> That there is some sort of SA (perhaps dynamically created
> at initial
> 	>    access) between the ARs and the MN in the visited subnet.
> 	>
> 	> => I don't think this is a good idea because :
> 	>  - this is hard in some cases to get this SA
> 	>  - mobile IPv6 draft has "access control for visited networks" in
> non-goals.
> 	>
> 	> But of course the existence (or not) of this SA is important for
> 	> some threats, so my concern is only about an assumption.
> 	>
> 	> Regards
> 	>
> 	> Francis.Dupont@enst-bretagne.fr
> 	>
> 	> PS: about the other "drop everything (:-)" thread: I disagree the
> only
> 	> simple solution is to drop everything but I'd like to see the
> 	> anti-optimized/reverse-tunneling solution in mobile IPv6 document
> 	> because this is both simple and very secure.
> 	
> 

------_=_NextPart_001_01C14AF5.A8BFCE70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Security Requirements Draft</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi, </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I thought that =
section existed already, but now it seems that </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">rev 14 only has =
that section in the HA operation part. Ch 9.5</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As far as the MN is =
concerned it's really an internl policy</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">decision within the =
MN itself and doesn't have protocol </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">impacts. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Last time I worked =
on our implementation we had a </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">configuration =
option for this in the MN. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Maybe some text for =
the MN operation would help clarify</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">that it is a =
configuration / policy issue for the MN.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Qiang Zhang [SMTP:qzhang@ecutel.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, 2 October 2001 12:12</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mobile-ip@sunroof.eng.sun.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: [mobile-ip] Security =
Requirements Draft</FONT>
</P>

<P><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Charlie and all,</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Do you think it may be useful to =
define a mode in the MIPv6 base for the MN to choose using rev-tunnel =
only? That way it may be beneficial to some usage models, for example, =
to achive MN's location privacy (no BU sent to CN, neither from HA nor =
MN) and also controlled access policy can be imposed for the MN from =
home network.</FONT></P>

<P><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Or would this be left to =
implementations to define its own?</FONT>=20
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Qiang</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">From:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"> Charles E. Perkins<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"> Mon 10/1/2001 11:36 AM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"> Francis Dupont<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">Cc:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"> mobile-ip@sunroof.eng.sun.com<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Arial"> Re: [mobile-ip] Security Requirements =
Draft<BR>
<BR>
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello Francis,<BR>
<BR>
Your solution is already supposed to be &quot;in there&quot;, because =
the<BR>
home agent is required to be able to decapsulated packets from<BR>
the mobile node.&nbsp; If this point has somehow been lost since =
the<BR>
time I was originally editing the document, I will make sure that<BR>
it gets restored to the text.&nbsp; Thus, I don't think there is =
anything<BR>
to be done, unless you would like to have an appendix that points<BR>
out explicitly that home agent decapsulation is valuable for use<BR>
with mobile nodes that don't wish to use the Home Address =
destination<BR>
option.<BR>
<BR>
Also, I would like to point out that the Home Address destination<BR>
option was designed NOT to be a threat to ingress filtering, =
because<BR>
the home address of the sender is right there!&nbsp; Putting your =
true<BR>
address into the packet is a very bad way to hide.&nbsp; If the =
worry<BR>
has something to do about using the care-of address, then it has<BR>
nothing to do with Mobile IPv6 anyway, because any node can<BR>
autoconfigure a topologically correct address that would look<BR>
indistinguishable from the mobile node's use of such a =
topologically<BR>
correct address.<BR>
<BR>
Regards,<BR>
Charlie P.<BR>
<BR>
<BR>
<BR>
Francis Dupont wrote:<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp; I would like to float another proposed =
assumption and get feedback on this.<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp; 3&gt; That there is some sort of SA (perhaps =
dynamically created at initial<BR>
&gt;&nbsp;&nbsp;&nbsp; access) between the ARs and the MN in the =
visited subnet.<BR>
&gt;<BR>
&gt; =3D&gt; I don't think this is a good idea because :<BR>
&gt;&nbsp; - this is hard in some cases to get this SA<BR>
&gt;&nbsp; - mobile IPv6 draft has &quot;access control for visited =
networks&quot; in non-goals.<BR>
&gt;<BR>
&gt; But of course the existence (or not) of this SA is important =
for<BR>
&gt; some threats, so my concern is only about an assumption.<BR>
&gt;<BR>
&gt; Regards<BR>
&gt;<BR>
&gt; Francis.Dupont@enst-bretagne.fr<BR>
&gt;<BR>
&gt; PS: about the other &quot;drop everything (:-)&quot; thread: I =
disagree the only<BR>
&gt; simple solution is to drop everything but I'd like to see the<BR>
&gt; anti-optimized/reverse-tunneling solution in mobile IPv6 =
document<BR>
&gt; because this is both simple and very secure.<BR>
</FONT>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C14AF5.A8BFCE70--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 01:24:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14084
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 01:24:42 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16952;
	Mon, 1 Oct 2001 22:24:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11965;
	Mon, 1 Oct 2001 22:23:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f925N9ML004106
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 1 Oct 2001 22:23:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f925N8wE004105
	for mobile-ip-dist; Mon, 1 Oct 2001 22:23:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f925N5ML004098
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 22:23:05 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11870
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 22:23:07 -0700 (PDT)
Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15887
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 1 Oct 2001 22:23:05 -0700 (PDT)
Received: from blammo.its.monash.edu.au ([130.194.1.74])
 by vaxc.cc.monash.edu.au (PMDF V6.0-24 #39306)
 with ESMTP id <01K913MG9UC6AAUG3D@vaxc.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Tue, 02 Oct 2001 15:23:00 +1000
Received: from localhost (localhost [127.0.0.1])	by blammo.its.monash.edu.au
 (Postfix) with ESMTP	id 7334012C007; Tue, 02 Oct 2001 15:22:59 +1000 (EST)
Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60])
	by blammo.its.monash.edu.au (Postfix) with ESMTP	id C7A4112C006; Tue,
 02 Oct 2001 15:22:58 +1000 (EST)
Date: Tue, 02 Oct 2001 15:22:58 +1000
From: Gregory Daley <Greg.Daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] Security Requirements Draft
To: mobile-ip@sunroof.eng.sun.com
Cc: greg.daley@eng.monash.edu.au
Message-id: <1f1f551f2dfe.1f2dfe1f1f55@mail1.monash.edu.au>
MIME-version: 1.0
X-Mailer: Netscape Webmail
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7BIT

>        Do you think it may be useful to define a mode in the MIPv6 
> basefor the MN to choose using rev-tunnel only? That way it may be
> beneficial to some usage models, for example, to achive MN's location
> privacy (no BU sent to CN, neither from HA nor MN) and also controlled
> access policy can be imposed for the MN from home network.
>         
>        Or would this be left to implementations to define its own? 

	Hi Qiang,

	Some mechanisms to provide this function are indicated
	in the HMIPv6 draft, which provides a location privacy
	Section 6.6 (+6.5)

	This may not be the same tool I think it is 
	intended to solve the same problem. (for example,
	if a MAP is also the HA) 

	Perhaps it is better to have the function only mandated
	once so that MIPv6 doesn't expand further.

		Greg Daley
			



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 04:17:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00243
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 04:17:03 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA00983;
	Tue, 2 Oct 2001 01:16:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29551;
	Tue, 2 Oct 2001 01:13:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f928ChML004284
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 01:12:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f928Ch6P004283
	for mobile-ip-dist; Tue, 2 Oct 2001 01:12:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f928CdML004276
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 01:12:39 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28987
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 01:12:43 -0700 (PDT)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01383
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 01:12:38 -0700 (PDT)
Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA31272;
	Tue, 2 Oct 2001 10:12:49 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <mat@cisco.com>
Subject: RE: [mobile-ip] AAA keys design comment
Date: Tue, 2 Oct 2001 10:13:24 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKCEFCDHAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <15288.41306.137426.736305@thomasm-u1.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>
>It seems to me that there is a fundamental design
>choice that was made in the AAA keys draft is
>suboptimal. That is, the basic flow is to have the
>AAA deliver keys to both the MN and the HA.  I
>think that this is needlessly complex, has either
>a race condition, or unneeded latency, and clearly
>has an extra message that is not necessary. The
>reason is because the MN always needs to register
>with HA, so there is a natural and available round
>trip that completes the triangle as effectively as
>having the AAA doing it. The trick is to have the
>AAA create an encrypted blob which is keyed in the
>secret between AAAH and HA which the MN can
>present to the HA along with an authenticator to
>prove it posseses the MN/HA session key.  For
>those knowledgeable about Kerberos, this should
>look familiar.
>
>A flow is in order here. I'll write this in terms
>of Kerberos messages, but I'm not necessarily
>saying that it needs to be Kerberos, per se.
>The technique is what is important; the bits in
>the air are another topic.
>
>MN       FA          AAAF          AAAH             HA
>---------->
>AS-REQ[HA]
>           ------------->
>	   AAA+AS-REQ[HA]
>                         ------------->
>			 AAA+AS-REQ[HA]
>                 
>                        <--------------
>			 AAA+AS-REP [tick HA]
>           <------------
>   	    AAA+AS-REP [tick HA]
><----------
> AAA+AS-REP [tick HA]
>
>---------------------------------------------------->
>AP-REQ [tick HA]
>
><----------------------------------------------------
>AP-REP
>
>Note that all we've done is remove the message
>exchange between AAAH, and HA. This yields many 
>advantages:
>
>1) this mechanism can be reused for many different
>   application at low cost since AAA doesn't need
>   to be modified for each new application
>
>2) the mechanism is more robust and properly
>   fate shared in that a partition between AAAH 
>   and HA will not cause a failure.
>
>3) The latency or race condition between 
>   AAA/MN and AAA/HA is eliminated

what kind of race condition is it that can occur?
this is the message flow for initial registration and
periodic re-keying registrations
MN       FA          AAAF          AAAH             HA
---------->
Mip-RegReq[]
           ------------->
	   AMR[Mip-RegReq]
                         ------------->
			       AMR[Mip-RegReq]
                                        ------------->
                         HAR[Ha and Mn Keys,Mip-RegReq]
                                        <-------------
			             HAA[Mip-RegRep[Mn Keys]]
                         <-------------
                       AMA[FA keys, Mip-RegRep[Mn Keys]]
           <------------
   	    AMA[Fa keys, Mip-RegRep[Mn Keys]]
<----------
 Mip-RegRep[Mn Keys]

this is the message flow for periodic MIP tunnel updates
when distributed keys are still valid
MN       FA          AAAF          AAAH             HA
---------->
Mip-RegReq[]
           ----------------------------------------->
		Mip-RegReq[]
	     <-----------------------------------------
   	      Mip-RegRep[]
<----------
 Mip-RegRep[]


>4) The round trip between AAA and HA is eliminated

Yes, you eliminate the round trip between AAAh and HA,
but you add a potentially much longer round trip between 
the foreing network and the home network in that you now
have to go two round trips between the two networks. The
first one to the AAA and the second one to the HA. As it 
was before, only one round trip was required between the 
home and foreign network. See message flow above

/Fredrik

>
>5) There's very wide spread use of this approach;
>   it's been around for over a decade
>
>6) We _could_ directly use Kerberos messages,
>   though I am sympathetic to the desire to have
>   something that is less heavy weight if that
>   were possible. I believe that directly using
>   Kerberos would also provide a solution for
>   the IESG criticism that there is an implicit
>   expectation that AAAH and HA are in the same
>   administrative domain (ie, directly share a
>   secret); cross realm Kerberos and/or IAKERB 
>   provides the needed functionality. Kerberos
>   also brings the ability to use PKI based 
>   authentication with PKINIT and PKCROSS. 
>
>On other accounts, I believe that the protocols
>are equivalently functional.
>
>		 Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 05:13:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01219
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 05:13:58 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA19496;
	Tue, 2 Oct 2001 02:13:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01786;
	Tue, 2 Oct 2001 02:13:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f929C5ML004406
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 02:12:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f929C58b004405
	for mobile-ip-dist; Tue, 2 Oct 2001 02:12:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f929C2ML004398
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 02:12:02 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12192
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 02:12:03 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07899
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 03:11:52 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f929BoQ23872;
	Tue, 2 Oct 2001 11:11:50 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA18877;
	Tue, 2 Oct 2001 11:11:50 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f929BnD11887;
	Tue, 2 Oct 2001 11:11:49 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110020911.f929BnD11887@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Security Requirements Draft 
In-reply-to: Your message of Mon, 01 Oct 2001 08:36:39 PDT.
             <3BB88D87.6EDB9F4@iprg.nokia.com> 
Date: Tue, 02 Oct 2001 11:11:49 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   Your solution is already supposed to be "in there", because the
   home agent is required to be able to decapsulated packets from
   the mobile node.

=> all parts of the mechanism are there but not the whole picture.

   Thus, I don't think there is anything
   to be done, unless you would like to have an appendix that points
   out explicitly that home agent decapsulation is valuable for use
   with mobile nodes that don't wish to use the Home Address destination
   option.
   
=> something which clearly explains how to do the "anti-optimized"
mode should be really useful. I like this idea of an appendix.

   Also, I would like to point out that the Home Address destination
   option was designed NOT to be a threat to ingress filtering, because
   the home address of the sender is right there!

=> this is true for firewalls which provide tyhe ingress filtering
(i.e. they can be smart enough :-) but not for attacks like DDoS
(attacks that ingress fileting is the defense against).

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 07:04:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03566
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 07:04:33 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19338;
	Tue, 2 Oct 2001 04:03:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13276;
	Tue, 2 Oct 2001 04:03:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92B2sML004546
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 04:02:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92B2sAv004545
	for mobile-ip-dist; Tue, 2 Oct 2001 04:02:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92B2oML004538
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 04:02:50 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20422
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 04:02:51 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19401
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 04:02:50 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03306;
	Tue, 2 Oct 2001 07:02:46 -0400 (EDT)
Message-Id: <200110021102.HAA03306@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: mobile-ip@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Subject: [mobile-ip] I-D ACTION:draft-sreeman-enhance-beth-ipv6-00.txt
Date: Tue, 02 Oct 2001 07:02:46 -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Enhancements to Bi-directional Edge Tunnel Handover 
                          for IPv6
	Author(s)	: S. Faccin, B. Patil, R. Patil, S. Sreemanthula
	Filename	: draft-sreeman-enhance-beth-ipv6-00.txt
	Pages		: 16
	Date		: 01-Oct-01
	
This document discusses enhancements to the Bi-directional Edge Tunnel 
Handover for IPv6 protocol described in draft-kempf-beth-ipv6-02.txt. Such draft proposes the use of bi-directional edge tunnels and deferred Care of Address establishment to eliminate L3 signaling during handover, thereby achieving a rapid and efficient handover mechanism.  The proposal in the present draft offers some improvements to the draft-kempf-beth-ipv6-02.txt in several respects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sreeman-enhance-beth-ipv6-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sreeman-enhance-beth-ipv6-00.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-sreeman-enhance-beth-ipv6-00.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:	<20011001112801.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-sreeman-enhance-beth-ipv6-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-sreeman-enhance-beth-ipv6-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 10:47:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14550
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 10:47:11 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24127;
	Tue, 2 Oct 2001 08:46:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09850;
	Tue, 2 Oct 2001 07:46:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92EjZML004740
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:45:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92EjZel004739
	for mobile-ip-dist; Tue, 2 Oct 2001 07:45:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92EjVML004732
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:45:31 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19206
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:45:33 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA26568
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:45:31 -0700 (PDT)
Received: (qmail 26936 invoked by uid 500); 2 Oct 2001 14:31:12 -0000
Date: Tue, 2 Oct 2001 07:31:12 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Cc: Michael Thomas <mat@cisco.com>,
        "Charles E. Perkins" <charliep@IPRG.nokia.com>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        Pat Calhoun <pcalhoun@diameter.org>
Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key
Message-ID: <20011002073112.B26914@charizard.diameter.org>
References: <Roam.SIMC.2.0.6.1001427527.14101.nordmark@bebop.france> <3BB15C81.DE5655DA@iprg.nokia.com> <20010927204724.A1723@charizard.diameter.org> <15284.63652.615358.830329@thomasm-u1.cisco.com> <20010930073919.B16146@charizard.diameter.org> <15288.36575.656655.120872@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15288.36575.656655.120872@thomasm-u1.cisco.com>; from mat@cisco.com on Mon, Oct 01, 2001 at 08:42:23AM -0700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, Oct 01, 2001 at 08:42:23AM -0700, Michael Thomas wrote:
> Pat Calhoun writes:
>  > >    Beyond Eric's clarification, I have a question:
>  > >    You clearly must derive new keys from the MN/AAA
>  > >    secret which if I remember correctly comes from
>  > >    the AAA, encrypted in the MN/AAA key. What prevents
>  > >    key reuse, especially for rekeying?
>  > 
>  > no key is ever sent encrypted or otherwise. All that is sent is keying
>  > material, which the mobile uses to create the actual key. The key creation
>  > process does require the long term MN/AAA key.
> 
>    You didn't answer my question. The question is
>    how do you insure that new entropy is added to
>    the keying material when you do things like
>    rekeying? You can't just derive a new key from
>    the old keying material via some one way hash
>    generator; you need to add fresh entropy too
>    from one or more (preferably) of the 
>    participants (MN, HA, AAA).

New keys are always generated by AAA. Furthermore, since the MN authenticates the
Registration Reply, which contains the key material, using the newly generated key,
it requires that both parties have the same key. If the issue here is that a malicious
MIP infrastructure compromises the key, it would require a brute force attack on
the admittedly infrequent registration requests sent by the mobile node.

Lastly, only the AAA generates new keying material for the MN. There is no key
distribution protocol defined between the MN and the HA where they can generate
new keying material without AAA involvement.

>  > > Is there a way
>  > >    to get the AAA to supply fresh key material on demand?
>  > >    If so, is the performance penalty going to be acceptible?
>  > >    If not, is the expectation that one or both of the
>  > >    ends of the SA supply entropy? If it's only one side,
>  > >    what happens if their random number generator is not
>  > >    very good, like oh say open("/dev/null")?
>  > 
>  > Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
>  > to be sent to the mobile. So, using today's protocol, the answer is no.
> 
>    No to what? I'm guessing the first, and if so it
>    doesn't necessarily need to be initiated by the
>    AAA. If the MN can initiate which leads to the AAA
>    supplying fresh entropy, that would suffice. With
>    normal PPP/AAA, I don't think the host can cause the
>    NAS to challenge it. I'm not sure if that's the case
>    here.

The MN initiates the key request by issuing a registration request. The MIP
infrastructure cannot cause the MN to register for no reason. The registration
has a lifetime, dictated by the AAA and the HA.

So to answer your question, no the host cannot cause the NAS to challenge it.

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 10:53:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14987
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 10:53:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13524;
	Tue, 2 Oct 2001 07:52:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11943;
	Tue, 2 Oct 2001 07:52:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92EprML004835
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:51:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92EprZY004834
	for mobile-ip-dist; Tue, 2 Oct 2001 07:51:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92EpnML004827
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:51:49 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15409
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:51:51 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA00928
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 07:51:50 -0700 (PDT)
Received: (qmail 26977 invoked by uid 500); 2 Oct 2001 14:37:31 -0000
Date: Tue, 2 Oct 2001 07:37:31 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Cc: Michael Thomas <mat@cisco.com>,
        "Charles E. Perkins" <charliep@IPRG.nokia.com>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key
Message-ID: <20011002073731.C26914@charizard.diameter.org>
References: <8C92E23A3E87FB479988285F9E22BE460548DA@ftmail>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <8C92E23A3E87FB479988285F9E22BE460548DA@ftmail>; from G.Tsirtsis@flarion.com on Mon, Oct 01, 2001 at 11:56:41AM -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, Oct 01, 2001 at 11:56:41AM -0400, George Tsirtsis wrote:
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Sunday, September 30, 2001 3:39 PM
> To: Michael Thomas
> Cc: mobile-ip@sunroof.eng.sun.com; Charles E. Perkins; Erik Nordmark;
> Pat Calhoun
> Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key
> 
> ...
> 
> > Is there a way
> >    to get the AAA to supply fresh key material on demand?
> >    If so, is the performance penalty going to be acceptible?
> >    If not, is the expectation that one or both of the
> >    ends of the SA supply entropy? If it's only one side,
> >    what happens if their random number generator is not
> >    very good, like oh say open("/dev/null")?
> 
> Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
> to be sent to the mobile. So, using today's protocol, the answer is no.
> 
> 
> GT> I have a different concern with a possible solution that may solve this
> problem. 
> We are implementing challenge/response with MN-AAA extensions and Radius as
> AAA. As a Mobile Node (MN) comes in contact with a new FA, it receives an
> Foreign Agent Advertisement (FAA) with a Challenge to which it responds with
> a MIP Registration Request (RREQ) that includes MN-AAA authenticator. The FA
> gets key material from AAA server and returns it to the Mobile Node (MN)
> with the registration reply (RREP) so that an MN-FA key can be constructed.
> The link layer happens to provide link up/link down triggers so that if the
> MN looses contact with the FA we know it immediately. If the MN regains
> contact in a short time, the FA senses it also immediately. 
> 
> ->The problem with a standards based MIP client would be that on
> reconnection and although the MN receives an FAA with a challenge, the
> advertised FA is recoginsed as one that the MN has already registered with
> and does not bother to register again thus, one can not check its MN-FA key
> and verify the user is still the same.
> 
> No matter what the particular scenario is, however, I think this does not
> make sense for any challenge/response protocol. The behaviour should be that
> if you get a challenge you MUST respond to it. So, the proposed solution is:
> 
> "If a Mobile Node receives a *unicast* FAA WITH a Challenge then it MUST
> send a Registration Request with an appropriate Response or face loss of
> connectivity". Note that this does not mandate that all FAAs must now be
> unicasted...but it does allow a network administrator to target a specific
> mobile, challenge it individually and get its credetials.
> On top of that, the above proposal would also make re-keying possible since
> the FA can insert new Key material in the Registration Reply.

To address both your issues:

1. RFC 3012 is pretty clear that the MN MUST include the challenge response if the
   challenge was present in an advertisement. No way around this one, so I don't
   think there is an issue (unless I misinterpreted your comment).

2. If the FA inserts new key material in the registration reply, it must also
   add the necessary authentication extension, which must match the key generated
   by the MN via the included key material. Furthermore, the HA must also add the
   necessary MN-HA key material (which it receives from the AAAH) as well as the
   MN-HA authentication extension.

Hope this helps,

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 11:07:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15591
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 11:07:02 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11709;
	Tue, 2 Oct 2001 09:06:08 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14710;
	Tue, 2 Oct 2001 08:06:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92F5KML004943
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:05:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92F5Kll004942
	for mobile-ip-dist; Tue, 2 Oct 2001 08:05:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92F5GML004935
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:05:16 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17767
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:05:17 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA03717
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:06:17 -0600 (MDT)
Received: (qmail 27067 invoked by uid 500); 2 Oct 2001 14:50:51 -0000
Date: Tue, 2 Oct 2001 07:50:51 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] AAA keys design comment
Message-ID: <20011002075051.F26914@charizard.diameter.org>
References: <15288.41306.137426.736305@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15288.41306.137426.736305@thomasm-u1.cisco.com>; from mat@cisco.com on Mon, Oct 01, 2001 at 10:01:14AM -0700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, Oct 01, 2001 at 10:01:14AM -0700, Michael Thomas wrote:
> It seems to me that there is a fundamental design
> choice that was made in the AAA keys draft is
> suboptimal. That is, the basic flow is to have the
> AAA deliver keys to both the MN and the HA.  I
> think that this is needlessly complex, has either
> a race condition, or unneeded latency, and clearly
> has an extra message that is not necessary. The
> reason is because the MN always needs to register
> with HA, so there is a natural and available round
> trip that completes the triangle as effectively as
> having the AAA doing it. The trick is to have the
> AAA create an encrypted blob which is keyed in the
> secret between AAAH and HA which the MN can
> present to the HA along with an authenticator to
> prove it posseses the MN/HA session key.  For
> those knowledgeable about Kerberos, this should
> look familiar.

so talking about sub-optimal and unnecessarily complex you state that the
MN should issue a request to the KDC infrastructure to retrieve a key, and
then present the key to the HA, right?

This now requires that the signalling (over the air and the 'net) include two
full round trips, as opposed to a single one (which is what we have today).

so perhaps you can qualify your statement on how you perceive your proposal
above as being more efficient, which is key to mobility.

> A flow is in order here. I'll write this in terms
> of Kerberos messages, but I'm not necessarily
> saying that it needs to be Kerberos, per se.
> The technique is what is important; the bits in
> the air are another topic.
> 
> MN       FA          AAAF          AAAH             HA
> ---------->
> AS-REQ[HA]
>            ------------->
> 	   AAA+AS-REQ[HA]
>                          ------------->
> 			 AAA+AS-REQ[HA]
>                  
>                         <--------------
> 			 AAA+AS-REP [tick HA]
>            <------------
>    	    AAA+AS-REP [tick HA]
> <----------
>  AAA+AS-REP [tick HA]
> 
> ---------------------------------------------------->
> AP-REQ [tick HA]
> 
> <----------------------------------------------------
> AP-REP
> 
> Note that all we've done is remove the message
> exchange between AAAH, and HA. This yields many 
> advantages:

ok, but keet in mind that the AAAH and the HA are many times co-located
and the latency between these is very low. Actually, I'd even argue that
the latency there is lower than introducing a full round trip

for those of you not familiar with the aaa-keys approach, here it is:
 MN       FA          AAAF          AAAH             HA
 ---------->
 REG-REQ
            ------------->
 	   AAA AMR
                          ------------->
 			 AAA AMR
                  
                                       ------------->
 	                       		 AAA HAR
                  
                                      <--------------
              			         AAA HAA

                         <--------------
 			 AAA AMA

            <------------
    	    AAA AMA
 <----------
 REG-REP

The key here is a single round trip, and the over the air signalling is
minimized.

> 1) this mechanism can be reused for many different
>    application at low cost since AAA doesn't need
>    to be modified for each new application

ok

> 
> 2) the mechanism is more robust and properly
>    fate shared in that a partition between AAAH 
>    and HA will not cause a failure.

right, so now the AAAH must assume that the HA can handle the MN. In our 
solution the HA can return a negative response to the AAAH, perhaps because
it is too busy, which would cause the AAAH to select another HA.

In this solution, the MN must recontact the KDC to get new key and try another
HA.

> 
> 3) The latency or race condition between 
>    AAA/MN and AAA/HA is eliminated

pls describe the race condition, since I am not aware of one.

> 
> 4) The round trip between AAA and HA is eliminated

see comment above on whether this is really the problem

> 
> 5) There's very wide spread use of this approach;
>    it's been around for over a decade
> 
> 6) We _could_ directly use Kerberos messages,
>    though I am sympathetic to the desire to have
>    something that is less heavy weight if that
>    were possible. I believe that directly using
>    Kerberos would also provide a solution for
>    the IESG criticism that there is an implicit
>    expectation that AAAH and HA are in the same
>    administrative domain (ie, directly share a
>    secret); cross realm Kerberos and/or IAKERB 
>    provides the needed functionality. Kerberos
>    also brings the ability to use PKI based 
>    authentication with PKINIT and PKCROSS. 

The above two comments seem to be in conflict. Although
Kerberos has been around for a long time, many of the protocols
you mention in 6 are fairly new.

> On other accounts, I believe that the protocols
> are equivalently functional.

ok

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 11:17:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16091
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 11:17:48 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22152;
	Tue, 2 Oct 2001 09:16:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16782;
	Tue, 2 Oct 2001 08:16:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FG3ML005050
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:16:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92FG3pB005049
	for mobile-ip-dist; Tue, 2 Oct 2001 08:16:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FFxML005042
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:15:59 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16586
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:15:55 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10537
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:16:52 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.6/8.9.1) with ESMTP id f92FFGG23795;
	Tue, 2 Oct 2001 08:15:16 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAZ20472;
	Tue, 2 Oct 2001 08:15:15 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03562; Tue, 2 Oct 2001 08:15:15 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15289.55811.95026.478238@thomasm-u1.cisco.com>
Date: Tue, 2 Oct 2001 08:15:15 -0700 (PDT)
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
Cc: <mobile-ip@sunroof.eng.sun.com>, <mat@cisco.com>
Subject: RE: [mobile-ip] AAA keys design comment
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKCEFCDHAA.fredrik.johansson@ipunplugged.com>
References: <15288.41306.137426.736305@thomasm-u1.cisco.com>
	<MJEMJBGGCLLDLFFAHLJKCEFCDHAA.fredrik.johansson@ipunplugged.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Fredrik Johansson writes:
 > 
 > what kind of race condition is it that can occur?
 > this is the message flow for initial registration and
 > periodic re-keying registrations

   I said (probably too briefly) that it was a choice
   between a race condition or extra latency. If the
   AAA blocks to send the message to HA to eliminate the
   race, it adds latency to the entire exchange since
   the AAA could have sent the message to MN with the
   keying material at that step. It also loses robustness
   here because AAA and HA are not fate shared.

 > >4) The round trip between AAA and HA is eliminated
 > 
 > Yes, you eliminate the round trip between AAAh and HA,
 > but you add a potentially much longer round trip between 
 > the foreing network and the home network in that you now
 > have to go two round trips between the two networks. The
 > first one to the AAA and the second one to the HA. As it 
 > was before, only one round trip was required between the 
 > home and foreign network. See message flow above

   I don't see why this is true. The ticket has
   a lifetime associated with it. The MN creates
   fresh AP-REQ's destined for HA, and all FA needs 
   to do is relay them. The same general technique
   can be used to key the SA's between FA/HA,
   and FA/MN, with complete concurrency. I could
   use the same flow and show how it could key
   all three of those SA's with the same number
   of messages.

   One thing I'm not clear on the v4 version of
   this is whether MN and FA end up sharing their
   own key. Is this the case? If not, isn't there
   an implicit authorization being done for FA
   by HA which constrains the model? Ie, if AAAh and
   HA are not in the same administrative domain
   (eg AAAh == Visa), HA might be granting subsequent
   authorization that AAAh might not have agreed
   to?

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 11:23:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16390
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 11:23:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27666;
	Tue, 2 Oct 2001 09:22:43 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18494;
	Tue, 2 Oct 2001 08:22:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FM6ML005139
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:22:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92FM6Dg005138
	for mobile-ip-dist; Tue, 2 Oct 2001 08:22:06 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FM2ML005131
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:22:02 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21343
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:22:00 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21578
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:21:59 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA16917;
	Tue, 2 Oct 2001 08:21:59 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f92FLw924136;
	Tue, 2 Oct 2001 08:21:58 -0700
X-mProtect:  Tue, 2 Oct 2001 08:21:58 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdlqloHt; Tue, 02 Oct 2001 08:21:57 PDT
Message-ID: <3BB9DB96.E01A3952@iprg.nokia.com>
Date: Tue, 02 Oct 2001 08:21:58 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Security Requirements Draft
References: <200110020911.f929BnD11887@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Francis Dupont wrote:

> => something which clearly explains how to do the "anti-optimized"
> mode should be really useful. I like this idea of an appendix.

Text is always appreciated.  In this case, since you have thought about
the idea more than I have, I can imagine that you might be able to provide
the basic text.

>    Also, I would like to point out that the Home Address destination
>    option was designed NOT to be a threat to ingress filtering, because
>    the home address of the sender is right there!
> 
> => this is true for firewalls which provide tyhe ingress filtering
> (i.e. they can be smart enough :-) but not for attacks like DDoS
> (attacks that ingress fileting is the defense against).

I don't think there is a significant exposure here, but maybe you can
clear it up for me in e-mail off the list.  

Reverse tunneling is probably useful for privacy, but I don't think it
is any better than the Home Address destination option for limiting
the kind of problem you are concerned about.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 11:31:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16700
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 11:31:55 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03532;
	Tue, 2 Oct 2001 08:30:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19936;
	Tue, 2 Oct 2001 08:28:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FRQML005247
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:27:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92FRPKY005246
	for mobile-ip-dist; Tue, 2 Oct 2001 08:27:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FRMML005239
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:27:22 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19807
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:27:23 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA24149
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:27:23 -0700 (PDT)
Received: (qmail 27584 invoked by uid 500); 2 Oct 2001 15:13:05 -0000
Date: Tue, 2 Oct 2001 08:13:04 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>, mat@cisco.com
Subject: Re: [mobile-ip] AAA keys design comment
Message-ID: <20011002081304.O26914@charizard.diameter.org>
References: <15288.41306.137426.736305@thomasm-u1.cisco.com> <MJEMJBGGCLLDLFFAHLJKCEFCDHAA.fredrik.johansson@ipunplugged.com> <15289.55811.95026.478238@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15289.55811.95026.478238@thomasm-u1.cisco.com>; from mat@cisco.com on Tue, Oct 02, 2001 at 08:15:15AM -0700
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, Oct 02, 2001 at 08:15:15AM -0700, Michael Thomas wrote:
> Fredrik Johansson writes:
>  > 
>  > what kind of race condition is it that can occur?
>  > this is the message flow for initial registration and
>  > periodic re-keying registrations
> 
>    I said (probably too briefly) that it was a choice
>    between a race condition or extra latency. If the
>    AAA blocks to send the message to HA to eliminate the
>    race, it adds latency to the entire exchange since
>    the AAA could have sent the message to MN with the
>    keying material at that step. It also loses robustness
>    here because AAA and HA are not fate shared.

right, but the AAA is in constant contact with the HAs. So when the
AAA does the HA selection, assuming this is requested, then it would
most likely pick one that has been responding to watchdog messages.

> 
>  > >4) The round trip between AAA and HA is eliminated
>  > 
>  > Yes, you eliminate the round trip between AAAh and HA,
>  > but you add a potentially much longer round trip between 
>  > the foreing network and the home network in that you now
>  > have to go two round trips between the two networks. The
>  > first one to the AAA and the second one to the HA. As it 
>  > was before, only one round trip was required between the 
>  > home and foreign network. See message flow above
> 
>    I don't see why this is true. The ticket has
>    a lifetime associated with it. The MN creates
>    fresh AP-REQ's destined for HA, and all FA needs 
>    to do is relay them. The same general technique
>    can be used to key the SA's between FA/HA,
>    and FA/MN, with complete concurrency. I could
>    use the same flow and show how it could key
>    all three of those SA's with the same number
>    of messages.
> 
>    One thing I'm not clear on the v4 version of
>    this is whether MN and FA end up sharing their
>    own key. Is this the case? If not, isn't there
>    an implicit authorization being done for FA
>    by HA which constrains the model? Ie, if AAAh and
>    HA are not in the same administrative domain
>    (eg AAAh == Visa), HA might be granting subsequent
>    authorization that AAAh might not have agreed
>    to?

No. The key has an explicit lifetime and the AAAH dictates
the key lifetime. This lifetime is how long the MN is granted
access to the network. When that lifetime expires, it requires
new keying, which implies AAA interactions. At that point the
AAAH can deny access.

If the MN moves to a new domain (cross-domain roaming), the AAAH
is again contacted, and has the authority to deny access.

Thanks,

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 11:42:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17337
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 11:42:45 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10048;
	Tue, 2 Oct 2001 08:41:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27612;
	Tue, 2 Oct 2001 08:39:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FbxML005341
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:37:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92Fbw1W005340
	for mobile-ip-dist; Tue, 2 Oct 2001 08:37:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92FbtML005333
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:37:55 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23045
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 08:37:56 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA12155
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:37:45 -0600 (MDT)
Received: (qmail 27687 invoked by uid 500); 2 Oct 2001 15:23:36 -0000
Date: Tue, 2 Oct 2001 08:23:36 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Kuntal Chowdhury <chowdury@nortelnetworks.com>
Cc: pcalhoun@diameter.org, charliep@IPRG.nokia.com,
        mobile-ip@sunroof.eng.sun.com, diameter@diameter.org
Subject: [mobile-ip] Re: [diameter] DIAMETER support for MIP question
Message-ID: <20011002082336.T26914@charizard.diameter.org>
Mail-Followup-To: Kuntal Chowdhury <chowdury@nortelnetworks.com>,
	pcalhoun@diameter.org, charliep@IPRG.nokia.com,
	mobile-ip@sunroof.eng.sun.com, diameter@diameter.org
References: <52F74DDA50B5D211AF800000F808252108E64815@zrchb212.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <52F74DDA50B5D211AF800000F808252108E64815@zrchb212.us.nortel.com>; from chowdury@nortelnetworks.com on Mon, Oct 01, 2001 at 02:15:31PM -0500
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

hmmm... first off, version 2 is quite old, and 7 should be used (or even better
the 08 alpha released last week).

In the later versions, the AAAF sets a bit if it is willing to provide HA services
in the foreign network. Further, the AAAH has the option to choose whether it is
willing to let the mobile use this service. If so, it forwards the HAR to the
foreign network's AAAF, otherwise it sends the HAR to a local HA.

The zero HA address is a request to have a home agent dynamically assigned to the
mobile.

hope this helps,

PatC
On Mon, Oct 01, 2001 at 02:15:31PM -0500, Kuntal Chowdhury wrote:
> Pat/Charlie,
> I am curious to know the implication on a mobile node when it sends 0.0.0.0
> in the HA address field in MIP registration request for HA assignment in the
> local network but the HA gets assigned in the home network. In section 4.2
> in "draft-ietf-aaa-diameter-mobileip-02", there is an error code
> "DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5007" which AAAF sends back to AAAH to
> inform that it cannot assign a HA in the local network. In this case, does
> the AAAH assign a HA in the home network? Does the mobile node get any
> indication of this event? 
> 
> Regards,
> Kuntal


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 12:08:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18708
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 12:08:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24832;
	Tue, 2 Oct 2001 09:07:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04206;
	Tue, 2 Oct 2001 09:07:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92G62ML005487
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:06:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92G61CX005486
	for mobile-ip-dist; Tue, 2 Oct 2001 09:06:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92G5wML005479
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:05:58 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05479
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:06:00 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20605
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:05:59 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f92G5tq10585
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:05:55 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAZ21492;
	Tue, 2 Oct 2001 09:05:52 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03567; Tue, 2 Oct 2001 09:05:52 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15289.58848.663490.52928@thomasm-u1.cisco.com>
Date: Tue, 2 Oct 2001 09:05:52 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] AAA keys design comment
In-Reply-To: <20011002075051.F26914@charizard.diameter.org>
References: <15288.41306.137426.736305@thomasm-u1.cisco.com>
	<20011002075051.F26914@charizard.diameter.org>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > On Mon, Oct 01, 2001 at 10:01:14AM -0700, Michael Thomas wrote:
 > so talking about sub-optimal and unnecessarily complex you state that the
 > MN should issue a request to the KDC infrastructure to retrieve a key, and
 > then present the key to the HA, right?
 > 
 > This now requires that the signalling (over the air and the 'net) include two
 > full round trips, as opposed to a single one (which is what we have  today).

   It appears that I've been thinking of this too
   much like the v6 model which _does_ require the
   round trip to the HA at all times since there's
   no FA. This means that it would have a round
   to MN/HA instead of the round trip from HA/AAAh
   in the v4 case; in other words, a wash on the
   message count front. While you claim that this
   is an expensive round trip vs. a cheap round
   trip, I'm not as certain. First, not all radio
   access media are slow and I would expect that
   in the future they will get much better as they
   become more and more optimized for the net instead
   of the telco. Second, it's not at all clear to
   me that AAA round trip will necessarily be faster
   since there is no reason to believe that AAAh
   and HA will be topologically close to each other.
   This is especially true in the "Visa" model. 
   Indeed, I'm fairly certain that a lot of the 
   latency in current dial (post training, of
   course) is the AAA latency. This effectively
   doubles the message load on the AAA.

   Most of the same criticism still applies though;
   the AAAh are not fate shared with the HA, so
   adding this is less robust, and there is no
   way to do cross-realm AAAh/HA. In fact, you
   are placing a new limitation on who can operate
   the HA's in this model because they must have
   a relationship with AAAh. This model seems to
   preclude the case where I own and operate my 
   own HA, for example, but use a third party 
   settlement scheme for when I'm roaming. This
   doesn't require any business linkage to the
   HA's provider which IMO is a very good thing.

   I'll note that we have yet to have this
   discussion on IPv6. If a similar scheme is
   used, we are explicitly abandoning the "no
   FA" stance for MIPv6 which I think would be
   a step backward.

 > right, so now the AAAH must assume that the HA can handle the MN. In our 
 > solution the HA can return a negative response to the AAAH, perhaps because
 > it is too busy, which would cause the AAAH to select another HA.

   If you believe in anycast discovery of HA's,
   wouldn't you be able to achieve the same effect
   more efficiently by having the overloaded HA
   update its route metrics based on load so that
   the MN naturally selects the right HA based on
   routing?

 > The above two comments seem to be in conflict. Although
 > Kerberos has been around for a long time, many of the protocols
 > you mention in 6 are fairly new.

   The ticket mechanism is really what's important
   here; whether Kerberos itself is the right fit
   is another discussion. I honestly haven't
   sorted through the tradeoffs to form an
   opinion.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 12:20:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19112
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 12:20:03 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22253;
	Tue, 2 Oct 2001 10:18:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11468;
	Tue, 2 Oct 2001 09:18:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92GHnML005600
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:17:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92GHnqw005599
	for mobile-ip-dist; Tue, 2 Oct 2001 09:17:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92GHjML005592
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:17:45 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07451
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:17:47 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21376
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:17:47 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA03948
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 11:17:42 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 2 Oct 2001 11:10:54 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LT3XY>; Tue, 2 Oct 2001 11:17:11 -0500
Message-ID: <23BDB0046F3ED51185CD0002A5608D244B5DF7@zrc2c009.us.nortel.com>
From: "Kuntal Chowdhury" <chowdury@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Cc: "Jayshree Bharatia" <jayshree@nortelnetworks.com>
Subject: [mobile-ip] comments on draft-kempf-cdma-appl-02.txt
Date: Tue, 2 Oct 2001 11:17:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14B5D.B06AB730"
X-Orig: <chowdury@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14B5D.B06AB730
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

We have some comments on the "draft-kempf-cdma-appl-02.txt". We agree with
the main objective of this draft. We are also in agreement with the summary
section i.e. "existing micromobility scheme in a CDMA network need not be
replaced with MIP and likes".

A few comments on the text:

1. The definition of soft handoff needs to be corrected. Soft handoff is
always happening in a CDMA network. Alternatively a mobile in a CDMA network
maintains a set of PNs called active set. The notion of soft handoff from
one BTS to another is not correct.
 
2. The definition of 'hard handoff' needs some correction also. Hard handoff
happens between two BSCs, even if the BSCs belong to the same RAN.
 
3. Section 3 Page 8.
 
"When the mobile terminal begins to move out of range of stations B1 and B2,
the RAN gateway adds and deletes base stations from the set currently
serving the mobile node"
 
Apart from the RAN Gateway, which is essentially a BSC, the mobile station
itself performs the add/delete operation on the active set that it
maintains.
 
4. RAN connectivity is vital for managing this micro mobility events like
soft handoff, however in a large network or across different operator's
networks RAN connectivity may not be feasible. The extremely tight real time
constraints on traffic in the RAN limits the applicability of this scheme to
a small geographic area. 
 
5. Section 4. Page 8.
 
"This precludes routing IP packets from the mobile directly over the RAN" ->
Why so? Traffic engineered IP networks in the backhaul can be used to
satisfy stringent requirements of a CDMA backhaul network
 
6. The basic argument that hard handoff only takes place in the core network
is questionable.


-Kuntal


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

To      IETF-Announce:
From  Internet-Drafts@ietf.org
Date   Mon, 24 Sep 2001 10:59:53 -0400
CC     mobile-ip@sunroof.eng.sun.com
   
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


        Title           : IP Mobility and the CDMA Radio Access Network: 
                          Applicability Statement for Soft Handoff
        Author(s)       : J. Kempf, P. McCann, P. Roberts
        Filename        : draft-kempf-cdma-appl-02.txt
        Pages           : 12
        Date            : 21-Sep-01
        
Recently, there have been a variety of proposals submitted to the
Mobile IP Working Group and to other IETF working groups for IP
mobility solutions that seek to enhance or replace mobile IP. These
proposals, often characterized as micromobility or fast handoff, are
addressed primarily at the perceived need of multimedia sessions such
as video or voice over IP for faster handoff between radio base
stations, and are primarily directed at real time multimedia traffic
in 3rd generation cellular access networks. In this paper, we discuss
the design of CDMA radio access networks (RANs) and the applicability
of IP mobility to soft handoff in a CDMA RAN. We attempt to show that
given current IP routing algorithms and the constraints on a CDMA
RAN, IP mobility solutions have little, if any, role to play in
handoff within the RAN. In contrast, an IP mobility solution is
likely to play a big role in fast handoff between RANs, also called
hard handoff. While future developments in IP networking may change
this situation, IP mobility in CDMA networks currently seems to apply
only when the mobile node roams between disconnected RANs rather than
between base stations within a RAN or between connected RANs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-kempf-cdma-appl-02.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-kempf-cdma-appl-02.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.

<ftp://ftp.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt>
     Content-type: text/plain


------_=_NextPart_001_01C14B5D.B06AB730
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>comments on draft-kempf-cdma-appl-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">We have some comments on the =
&quot;draft-kempf-cdma-appl-02.txt&quot;. We agree with the main =
objective of this draft. We are also in agreement with the summary =
section i.e. &quot;existing micromobility scheme in a CDMA network need =
not be replaced with MIP and likes&quot;.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A few comments on the =
text:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">1. The definition of soft =
handoff needs to be corrected. Soft handoff is always happening in a =
CDMA network. Alternatively a mobile in a CDMA network maintains a set =
of PNs called active set. The notion of soft handoff from one BTS to =
another is not correct.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">2. The definition of 'hard =
handoff' needs some correction also. Hard handoff happens between two =
BSCs, even if the BSCs belong to the same RAN.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">3. Section 3 Page 8.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&quot;When the mobile terminal =
begins to move out of range of stations B1 and B2, the RAN gateway adds =
and deletes base stations from the set currently serving the mobile =
node&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Apart from the RAN Gateway, =
which is essentially a BSC, the mobile station itself performs the =
add/delete operation on the active set that it maintains.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">4. RAN connectivity is vital =
for managing this micro mobility events like soft handoff, however in a =
large network or across different operator's networks RAN connectivity =
may not be feasible. The extremely tight real time constraints on =
traffic in the RAN limits the applicability of this scheme to a small =
geographic area. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">5. Section 4. Page 8.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&quot;This precludes routing IP =
packets from the mobile directly over the RAN&quot; -&gt; Why so? =
Traffic engineered IP networks in the backhaul can be used to satisfy =
stringent requirements of a CDMA backhaul network</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">6. The basic argument that hard =
handoff only takes place in the core network is questionable.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">-Kuntal</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">--------------------------------</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">To&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IETF-Announce:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">From&nbsp; =
Internet-Drafts@ietf.org</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Date&nbsp;&nbsp; =
Mon, 24 Sep 2001 10:59:53 -0400</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">CC&nbsp;&nbsp;&nbsp;&nbsp; =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">A New =
Internet-Draft is available from the on-line Internet-Drafts </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">directories.</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : IP =
Mobility and the CDMA Radio Access Network: </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; Applicability Statement for Soft Handoff</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Kempf, P. McCann, P. =
Roberts</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-kempf-cdma-appl-02.txt</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
12</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
: 21-Sep-01</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Recently, there =
have been a variety of proposals submitted to the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Mobile IP Working =
Group and to other IETF working groups for IP</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">mobility solutions =
that seek to enhance or replace mobile IP. These</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">proposals, often =
characterized as micromobility or fast handoff, are</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">addressed primarily =
at the perceived need of multimedia sessions such</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">as video or voice =
over IP for faster handoff between radio base</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">stations, and are =
primarily directed at real time multimedia traffic</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">in 3rd generation =
cellular access networks. In this paper, we discuss</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the design of CDMA =
radio access networks (RANs) and the applicability</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">of IP mobility to =
soft handoff in a CDMA RAN. We attempt to show that</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">given current IP =
routing algorithms and the constraints on a CDMA</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">RAN, IP mobility =
solutions have little, if any, role to play in</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">handoff within the =
RAN. In contrast, an IP mobility solution is</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">likely to play a =
big role in fast handoff between RANs, also called</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">hard handoff. While =
future developments in IP networking may change</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">this situation, IP =
mobility in CDMA networks currently seems to apply</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">only when the =
mobile node roams between disconnected RANs rather than</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">between base =
stations within a RAN or between connected RANs.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">A URL for this =
Internet-Draft is:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt=
" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-kempf-cdma-a=
ppl-02.txt</A></FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">To remove yourself =
from the IETF Announcement list, send a message to </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">ietf-announce-request with the word unsubscribe in the =
body of the message.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Internet-Drafts are =
also available by anonymous FTP. Login with the username</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">type &quot;cd =
internet-drafts&quot; and then</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-kempf-cdma-appl-02.txt&quot;.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">A list of =
Internet-Drafts directories can be found in</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Internet-Drafts can =
also be obtained by e-mail.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Send a message =
to:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mailserv@ietf.org.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In the body =
type:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
/internet-drafts/draft-kempf-cdma-appl-02.txt&quot;.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">NOTE:&nbsp;&nbsp; =
The mail server at ietf.org can return the document in</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded =
form by using the &quot;mpack&quot; utility.&nbsp; To use this</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, =
insert the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
command.&nbsp; To decode the response(s), you will need =
&quot;munpack&quot; or</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a =
MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
readers</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit =
different behavior, especially when dealing with</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;multipart&quot; MIME messages (i.e. documents which have been =
split</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into =
multiple messages), so check your local documentation on</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to =
manipulate these messages.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Below is the data =
which will enable a MIME compliant mail reader</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">implementation to =
automatically retrieve the ASCII version of the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Internet-Draft.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;<A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt"=
 =
TARGET=3D"_blank">ftp://ftp.ietf.org/internet-drafts/draft-kempf-cdma-ap=
pl-02.txt</A>&gt;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Content-type: text/plain</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14B5D.B06AB730--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 12:59:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20742
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 12:59:29 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25187;
	Tue, 2 Oct 2001 09:58:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24767;
	Tue, 2 Oct 2001 09:57:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92GuqML005735
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:56:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92GuqA8005734
	for mobile-ip-dist; Tue, 2 Oct 2001 09:56:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92GumML005727
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:56:48 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20434
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 09:56:50 -0700 (PDT)
Received: from mail.cambianetworks.com (osh200-140.onshore.com [66.54.200.140] (may be forged))
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29736
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 10:56:38 -0600 (MDT)
Received: by mail.cambianetworks.com (Postfix, from userid 1063)
	id F0EBB8AE8C; Tue,  2 Oct 2001 11:56:14 -0500 (CDT)
Received: from USAROSRMARKS1 (ho01-24-131-134-27.ce.mediaone.net [24.131.134.27])
	by mail.cambianetworks.com (Postfix) with ESMTP id D0CB3B298C
	for <mobile-ip@sunroof.eng.sun.com>; Tue,  2 Oct 2001 11:56:10 -0500 (CDT)
From: "Robert J Marks" <rjmarks@cambianetworks.com>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] comments on draft-kempf-cdma-appl-02.txt
Date: Tue, 2 Oct 2001 11:57:42 -0500
Organization: Cambia Networks
Message-ID: <005b01c14b63$5a2bccf0$6700a8c0@cambianetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005C_01C14B39.7155C4F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <23BDB0046F3ED51185CD0002A5608D244B5DF7@zrc2c009.us.nortel.com>
Importance: Normal
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C14B39.7155C4F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kuntal,
 
The decision to add or drop pilots from the active set is made by the
BSC, using input from the MS.
 
Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Kuntal
Chowdhury
Sent: Tuesday, October 02, 2001 11:17 AM
To: mobile-ip@sunroof.eng.sun.com
Cc: Jayshree Bharatia
Subject: [mobile-ip] comments on draft-kempf-cdma-appl-02.txt



Hi, 

We have some comments on the "draft-kempf-cdma-appl-02.txt". We agree
with the main objective of this draft. We are also in agreement with the
summary section i.e. "existing micromobility scheme in a CDMA network
need not be replaced with MIP and likes".

A few comments on the text: 

1. The definition of soft handoff needs to be corrected. Soft handoff is
always happening in a CDMA network. Alternatively a mobile in a CDMA
network maintains a set of PNs called active set. The notion of soft
handoff from one BTS to another is not correct.


2. The definition of 'hard handoff' needs some correction also. Hard
handoff happens between two BSCs, even if the BSCs belong to the same
RAN.


3. Section 3 Page 8. 
  
"When the mobile terminal begins to move out of range of stations B1 and
B2, the RAN gateway adds and deletes base stations from the set
currently serving the mobile node"


Apart from the RAN Gateway, which is essentially a BSC, the mobile
station itself performs the add/delete operation on the active set that
it maintains.


4. RAN connectivity is vital for managing this micro mobility events
like soft handoff, however in a large network or across different
operator's networks RAN connectivity may not be feasible. The extremely
tight real time constraints on traffic in the RAN limits the
applicability of this scheme to a small geographic area. 


5. Section 4. Page 8. 
  
"This precludes routing IP packets from the mobile directly over the
RAN" -> Why so? Traffic engineered IP networks in the backhaul can be
used to satisfy stringent requirements of a CDMA backhaul network


6. The basic argument that hard handoff only takes place in the core
network is questionable. 


-Kuntal 


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

To      IETF-Announce: 
From  Internet-Drafts@ietf.org 
Date   Mon, 24 Sep 2001 10:59:53 -0400 
CC     mobile-ip@sunroof.eng.sun.com 
   
A New Internet-Draft is available from the on-line Internet-Drafts 
directories. 


        Title           : IP Mobility and the CDMA Radio Access Network:

                          Applicability Statement for Soft Handoff 
        Author(s)       : J. Kempf, P. McCann, P. Roberts 
        Filename        : draft-kempf-cdma-appl-02.txt 
        Pages           : 12 
        Date            : 21-Sep-01 
        
Recently, there have been a variety of proposals submitted to the 
Mobile IP Working Group and to other IETF working groups for IP 
mobility solutions that seek to enhance or replace mobile IP. These 
proposals, often characterized as micromobility or fast handoff, are 
addressed primarily at the perceived need of multimedia sessions such 
as video or voice over IP for faster handoff between radio base 
stations, and are primarily directed at real time multimedia traffic 
in 3rd generation cellular access networks. In this paper, we discuss 
the design of CDMA radio access networks (RANs) and the applicability 
of IP mobility to soft handoff in a CDMA RAN. We attempt to show that 
given current IP routing algorithms and the constraints on a CDMA 
RAN, IP mobility solutions have little, if any, role to play in 
handoff within the RAN. In contrast, an IP mobility solution is 
likely to play a big role in fast handoff between RANs, also called 
hard handoff. While future developments in IP networking may change 
this situation, IP mobility in CDMA networks currently seems to apply 
only when the mobile node roams between disconnected RANs rather than 
between base stations within a RAN or between connected RANs. 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt 

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message. 

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-kempf-cdma-appl-02.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-kempf-cdma-appl-02.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. 

<ftp://ftp.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt> 
     Content-type: text/plain 


------=_NextPart_000_005C_01C14B39.7155C4F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D270225516-02102001><FONT face=3DArial color=3D#0000ff =

size=3D2>Kuntal,</FONT></SPAN></DIV>
<DIV><SPAN class=3D270225516-02102001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D270225516-02102001><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
decision to add or drop pilots from the active set is made by the BSC, =
using=20
input from the MS.</FONT></SPAN></DIV>
<DIV><SPAN class=3D270225516-02102001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D270225516-02102001><FONT face=3DArial color=3D#0000ff =

size=3D2>Bob</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  owner-mobile-ip@sunroof.eng.sun.com=20
  [mailto:owner-mobile-ip@sunroof.eng.sun.com] <B>On Behalf Of =
</B>Kuntal=20
  Chowdhury<BR><B>Sent:</B> Tuesday, October 02, 2001 11:17 =
AM<BR><B>To:</B>=20
  mobile-ip@sunroof.eng.sun.com<BR><B>Cc:</B> Jayshree=20
  Bharatia<BR><B>Subject:</B> [mobile-ip] comments on=20
  draft-kempf-cdma-appl-02.txt<BR><BR></FONT></DIV>
  <P><FONT face=3D"Courier New" size=3D2>Hi,</FONT> </P>
  <P><FONT face=3D"Courier New" size=3D2>We have some comments on the=20
  "draft-kempf-cdma-appl-02.txt". We agree with the main objective of =
this=20
  draft. We are also in agreement with the summary section i.e. =
"existing=20
  micromobility scheme in a CDMA network need not be replaced with MIP =
and=20
  likes".</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2>A few comments on the =
text:</FONT> </P>
  <P><FONT face=3D"Courier New" size=3D2>1. The definition of soft =
handoff needs to=20
  be corrected. Soft handoff is always happening in a CDMA network.=20
  Alternatively a mobile in a CDMA network maintains a set of PNs called =
active=20
  set. The notion of soft handoff from one BTS to another is not=20
  correct.</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2></FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>2. The definition of 'hard handoff' needs some correction =
also. Hard=20
  handoff happens between two BSCs, even if the BSCs belong to the same=20
  RAN.</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2></FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>3. Section 3 Page 8.</FONT> <BR><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT> <BR><FONT face=3D"Courier New" size=3D2>"When =
the mobile=20
  terminal begins to move out of range of stations B1 and B2, the RAN =
gateway=20
  adds and deletes base stations from the set currently serving the =
mobile=20
  node"</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2></FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>Apart from the RAN Gateway, which is essentially a BSC, the =
mobile=20
  station itself performs the add/delete operation on the active set =
that it=20
  maintains.</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2></FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>4. RAN connectivity is vital for managing this micro mobility =
events=20
  like soft handoff, however in a large network or across different =
operator's=20
  networks RAN connectivity may not be feasible. The extremely tight =
real time=20
  constraints on traffic in the RAN limits the applicability of this =
scheme to a=20
  small geographic area. </FONT></P>
  <P><FONT face=3D"Courier New" size=3D2></FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>5. Section 4. Page 8.</FONT> <BR><FONT face=3D"Courier New"=20
  size=3D2>&nbsp;</FONT> <BR><FONT face=3D"Courier New" size=3D2>"This =
precludes=20
  routing IP packets from the mobile directly over the RAN" -&gt; Why =
so?=20
  Traffic engineered IP networks in the backhaul can be used to satisfy=20
  stringent requirements of a CDMA backhaul network</FONT></P>
  <P><FONT face=3D"Courier New" size=3D2></FONT> <BR><FONT =
face=3D"Courier New"=20
  size=3D2>6. The basic argument that hard handoff only takes place in =
the core=20
  network is questionable.</FONT> </P><BR>
  <P><FONT face=3D"Courier New" size=3D2>-Kuntal</FONT> </P><BR>
  <P><FONT face=3DArial color=3D#0000ff=20
  size=3D2>--------------------------------</FONT> </P>
  <P><FONT face=3DArial color=3D#0000ff =
size=3D2>To&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  IETF-Announce:</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>From&nbsp;=20
  Internet-Drafts@ietf.org</FONT> <BR><FONT face=3DArial color=3D#0000ff =

  size=3D2>Date&nbsp;&nbsp; Mon, 24 Sep 2001 10:59:53 -0400</FONT> =
<BR><FONT=20
  face=3DArial color=3D#0000ff size=3D2>CC&nbsp;&nbsp;&nbsp;&nbsp;=20
  mobile-ip@sunroof.eng.sun.com</FONT> <BR><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp; </FONT><BR><FONT face=3DArial color=3D#0000ff =
size=3D2>A New=20
  Internet-Draft is available from the on-line Internet-Drafts =
</FONT><BR><FONT=20
  face=3DArial color=3D#0000ff size=3D2>directories.</FONT> </P><BR>
  <P><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : IP =

  Mobility and the CDMA Radio Access Network: </FONT><BR><FONT =
face=3DArial=20
  color=3D#0000ff=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  Applicability Statement for Soft Handoff</FONT> <BR><FONT face=3DArial =

  color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Kempf, P. McCann, =
P.=20
  Roberts</FONT> <BR><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
  draft-kempf-cdma-appl-02.txt</FONT> <BR><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
12</FONT>=20
  <BR><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:=20
  21-Sep-01</FONT> <BR><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Recently, there have been a variety of =
proposals=20
  submitted to the</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>Mobile IP=20
  Working Group and to other IETF working groups for IP</FONT> <BR><FONT =

  face=3DArial color=3D#0000ff size=3D2>mobility solutions that seek to =
enhance or=20
  replace mobile IP. These</FONT> <BR><FONT face=3DArial color=3D#0000ff =

  size=3D2>proposals, often characterized as micromobility or fast =
handoff,=20
  are</FONT> <BR><FONT face=3DArial color=3D#0000ff size=3D2>addressed =
primarily at=20
  the perceived need of multimedia sessions such</FONT> <BR><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>as video or voice over IP for faster handoff =
between=20
  radio base</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>stations, and are=20
  primarily directed at real time multimedia traffic</FONT> <BR><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>in 3rd generation cellular access networks. =
In this=20
  paper, we discuss</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>the design=20
  of CDMA radio access networks (RANs) and the applicability</FONT> =
<BR><FONT=20
  face=3DArial color=3D#0000ff size=3D2>of IP mobility to soft handoff =
in a CDMA RAN.=20
  We attempt to show that</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>given=20
  current IP routing algorithms and the constraints on a CDMA</FONT> =
<BR><FONT=20
  face=3DArial color=3D#0000ff size=3D2>RAN, IP mobility solutions have =
little, if=20
  any, role to play in</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>handoff=20
  within the RAN. In contrast, an IP mobility solution is</FONT> =
<BR><FONT=20
  face=3DArial color=3D#0000ff size=3D2>likely to play a big role in =
fast handoff=20
  between RANs, also called</FONT> <BR><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>hard handoff. While future developments in IP networking may=20
  change</FONT> <BR><FONT face=3DArial color=3D#0000ff size=3D2>this =
situation, IP=20
  mobility in CDMA networks currently seems to apply</FONT> <BR><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>only when the mobile node roams between =
disconnected RANs=20
  rather than</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>between base=20
  stations within a RAN or between connected RANs.</FONT> </P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>A URL for this =
Internet-Draft=20
  is:</FONT> <BR><FONT face=3DArial color=3D#0000ff size=3D2><A =
target=3D_blank=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt"=
>http://www.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt</A></FO=
NT>=20
  </P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>To remove yourself from =
the IETF=20
  Announcement list, send a message to </FONT><BR><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>ietf-announce-request with the word unsubscribe in the body =
of the=20
  message.</FONT> </P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>Internet-Drafts are =
also available by=20
  anonymous FTP. Login with the username</FONT> <BR><FONT face=3DArial=20
  color=3D#0000ff size=3D2>"anonymous" and a password of your e-mail =
address. After=20
  logging in,</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>type "cd=20
  internet-drafts" and then</FONT> <BR><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "get=20
  draft-kempf-cdma-appl-02.txt".</FONT> </P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>A list of =
Internet-Drafts directories=20
  can be found in</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2><A=20
  target=3D_blank=20
  =
href=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<=
/A>=20
  </FONT><BR><FONT face=3DArial color=3D#0000ff size=3D2>or <A =
target=3D_blank=20
  =
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt</A></FONT>=20
  </P><BR>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>Internet-Drafts can =
also be obtained=20
  by e-mail.</FONT> </P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>Send a message =
to:</FONT> <BR><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mailserv@ietf.org.</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>In the=20
  body type:</FONT> <BR><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "FILE=20
  /internet-drafts/draft-kempf-cdma-appl-02.txt".</FONT> <BR><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT face=3DArial color=3D#0000ff =
size=3D2>NOTE:&nbsp;&nbsp; The mail=20
  server at ietf.org can return the document in</FONT> <BR><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MIME-encoded=20
  form by using the "mpack" utility.&nbsp; To use this</FONT> <BR><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  feature, insert the command "ENCODING mime" before the "FILE"</FONT> =
<BR><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  command.&nbsp; To decode the response(s), you will need "munpack" =
or</FONT>=20
  <BR><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant =
mail=20
  reader.&nbsp; Different MIME-compliant mail readers</FONT> <BR><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  exhibit different behavior, especially when dealing with</FONT> =
<BR><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "multipart" MIME messages (i.e. documents which have been split</FONT> =

  <BR><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple =
messages),=20
  so check your local documentation on</FONT> <BR><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate =
these=20
  messages.</FONT> <BR><FONT face=3DArial color=3D#0000ff=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT face=3DArial color=3D#0000ff=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT face=3DArial color=3D#0000ff size=3D2>Below is the =
data which will=20
  enable a MIME compliant mail reader</FONT> <BR><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>implementation to automatically retrieve the ASCII version of =

  the</FONT> <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>Internet-Draft.</FONT>=20
  </P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>&lt;<A target=3D_blank=20
  =
href=3D"ftp://ftp.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt">=
ftp://ftp.ietf.org/internet-drafts/draft-kempf-cdma-appl-02.txt</A>&gt;</=
FONT>=20
  <BR><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;=20
  Content-type: text/plain</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_005C_01C14B39.7155C4F0--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 13:07:31 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21413
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 13:07:31 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00164;
	Tue, 2 Oct 2001 10:06:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27341;
	Tue, 2 Oct 2001 10:06:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92H5YML005859
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 10:05:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92H5Yku005858
	for mobile-ip-dist; Tue, 2 Oct 2001 10:05:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92H5VML005850
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 10:05:31 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19512;
	Tue, 2 Oct 2001 10:05:33 -0700 (PDT)
From: Christopher.Carroll@VerizonWireless.com
Received: from mail.verizonwireless.com (mail2.verizonwireless.com [199.74.158.61])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08020;
	Tue, 2 Oct 2001 11:05:21 -0600 (MDT)
Received: from mail.verizonwireless.com 
	by mail.verizonwireless.com (414/1100) with ESMTP id f92H5Si26826;
	Tue, 2 Oct 2001 13:05:28 -0400 (EDT)
Received: by hqbedigwy1.corp.bam.com with Internet Mail Service (5.5.2653.19)
	id <4CXLF71J>; Tue, 2 Oct 2001 13:05:29 -0400
Message-ID: <43E8CCEAF148D211854C00805FA72E5808318FD1@rhqnneex1.corp.bam.com>
To: Erik.Nordmark@eng.sun.com
Cc: mobile-ip@sunroof.eng.sun.com, FlynnGe@HQ.VerizonWireless.com
Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key
Date: Tue, 2 Oct 2001 13:05:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Erik,

I am the Chair of the TR-45 Adhoc Authentication Group (AHAG) which is
responsible for the development of security protocols and cryptographic
algorithms for North American wireless TDMA and CDMA networks.  I have some
experience in analyzing, integrating, and developing secret/symmetric key
authentication and key distribution protocols.  I also have some experience
in defining a formal cryptographic/security development process.

I'm somewhat troubled by many of the current proposals that represent a
significant shift in the how the IETF may implement authentication/key
distribution for MIPv4 w/ Radius/Diameter AAA.  Unfortunately, I beleive
this is the result of a somewhat informal security design methodoly.  I'm
sure that you're well aware of the generally accepted approach to security
development:

1) Threat/Security Assessment

2) Security Requirements Document

3) Security Architecture/Model/Integration

4) Security Analysis/Review

(Note: Iterative process in which new threats can be added to initial
assessment and so on up to the security model)

Prior to implementing the development process, there should be Security
Development Policy document that at least informs people that when one step
in the process is complete and accepted, no further discussion on the issue
allowed.  For example, during the threat assessment phase, the group might
consider the disclosure of subscriber identity information a high priority
security threat.  In the security requirements step, the security
requirements document will state that subscriber anonimity is essential in
this standard/RFC.  Any later design proposal that does not implement
subscriber anonimity will be rejected.

I'm somewhat concerned that people are proposing Kerberos and other
authentication mechanisms when, from my perspective, the IETF has already
implied that a point-to-point(AAA-to-MN) authentication and key distribution
protocol would be used.  I recommend that the IETF stay focused on the
current issue of MN-HA and MN-FA key distribution within that context.

By this time next year, Verizon Wireless and Sprint PCS will have over 40
million potential MIPv4 w/AAA users. (not including the millions in Korea or
China)  Unfortunately, it is too late for the IETF to start over.  The TIA
TR-45 and 3GPP2 standards groups have already published standards based on
the existing authentication mechanisms within MIPv4 and Radius AAA.  Verizon
Wireless has analyzed the existing security extensively, identified numerous
vulnerabilities (ex. AAA-to-HA or AAA-FA links), and has defined security
solutions for the problems.  Procedures to bootstrap the MN-AAA key are
currently being defined (which is not a cryptographic process per se) and
implemented.  

We critically need a method of distributing the MN-HA key (and MN-FA key)
based on the root MN-AAA key.  The current proposal satisfies that need and
we accept the associated risks/vulnerabilities involved.  I hope you realize
that MIPv4 (or MIPv6) is only one component in a complete information system
with security mechanisms below (air-link) and above (application layer).
The IETF does not have to boil the ocean by addressing every potential
security concern within MIPv4.  

Once again, I suggest that the IETF approve the existing key distribution
proposal.  

However, I completely support the development of a new authentication and
key distribution architecture for MIPv6 and/or MIPv4 which is based on a
robust security design methodoly.

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
Sent: Friday, September 28, 2001 10:46 AM
To: Christopher.Carroll@VerizonWireless.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key


Christopher,

> I have the following comments regarding your concerns with the current
> aaa-keys procedure:
> 
> 1) Keying material is used between the MN and FA (or MN and HA) because a
> Key Agreement Protocol is used as opposed to simply encrypting and
> distributing the MN-HA or MN-FA key.  The reason for using a key agreement
> protocol is that the MN-FA link and/or MN-HA link may be over-the-air
which
> is inherently more vulnerable to eavesdropping and cryptanalysis.  Please
> review the attached comments, originally sent to Charlie Perkins and Pat
> Calhoun, regarding the vulnerabilities associated with their original
> proposal to simply encrypt the MN-HA and/or MN-FA key for transmission to
> the MN.

I understand the requirement; I just wonder whether the suggested
protocols actually satisfy the security requirements.

*Based on the proposals within the current thread, I don't beleive that the
IETF understands what the security requirements for MIPv4 w/ AAA are or
where in the security development process you are.  Is there a specific
MIPv4 w/AAA security requirements document that defines the scope and
security goals to be acheived by the MIPv4/AAA architecture.  I do
understand that many security requirements are distributed throughout every
IETF document, however it is extremely difficult for a system developer or
security assessor to synthesize all these requirements - One document (like
the current MIPv6 Security Requirements) is essential.

> Key Agreement Protocols are well understood and have been used for many
> years in GSM and North American cellular/PCS networks to enable secure
> session key generation (in a symmetric/secret key system).

Has the security of those protocols been analysed in the open
literature? Do you have pointers to such analysis papers?

*I'm somewhat amused by your comment considering there are probably over 300
million GSM and ANSI-41 cellular/PCS phones currently using the equivalent
of the proposed key agreement scheme.  GSM has used key agreement to
generate session voice privacy keys for at least ten years while TR-45 CDMA
and TDMA handsets have been using key agreement to generate SSD and privacy
keys for approx. 5 years.

The published literature regarding key agreement is quite extensive.
However, in the more recent literature, authors only briefly describe the
proposed scheme because it is so basic.  Here's a few references as a start:

A. Menezes, P. Van Oorschot and S. Vanstone, "Handbook of Applied
Cryptography," CRC Press, 1996, pp. 497 - Point-to-Point update by key
derivation and non-reversible functions, etc...

M. Bellare and P. Rogaway, "Entity Authentication and key distribution",
Advances in Crypto - Crypto 93 Proceedings, Lecture Notes in Computer
Sceience Vol. 773, D. Stinson ed., Springer-Verlag, 1993.  

M. Bellare, R. Canetti, and H. Krawczyk, "A Modular Approach to the Design
and Analysis of Authentication and Key Exhange Protocols, Proceeding of 30th
Annual Symposium on the Theory of Computing, ACM 1998.

There are many more...

> Note: It is assumed that AAA links to other MIP entities (AAA, HA and FA)
> will be protected.

One of my questions was whether there was an assumption about encryption
being used to prevent evesdropping on these links, or if it is viewed
sufficient from the key agreement protocols if this communication 
is provided with integrity protection? Replay prevention or not?
(The term "protected" is a bit unspecific.)

* We are concerned about privacy on these links.  For example, subscriber
accounting information passed on the FA-to-AAA link must be protected.
There is also a concern about integrity protection - we don't want an
attacker to flip bits and possibly change access times, ids, etc...

> 2)  With regard the AAA-to-AAA, AAA-to-HA and AAA-to-FA links, 3G Wireless
> providers intend to protect these links using one of several techniques:
1)
> IPsec, 2) Linked encryption boxes, or 3) private commication links.
> Distribution of AAA keys is NOT OUR ONLY CONCERN on these links.  We
intend
> to encrypt all data between the AAA and HA/FA for subscriber privacy
reasons
> and other security concerns.  Assuming we intend to protect these links
> using techniques outside the scope of MIP, it is inefficient from our
> perspective to utilize a more elaborate key distribution scheme between
the
> AAA and other network infrastructure components (which are controlled by
the
> service providers).  In other words, we'll already have an SA established
> between these entities and don't need to deal with bootstrapping even
> another SA!
> 
> I do recognize that other implementations of MIPv4 will require more
> inherent security compliance (architecturally built-in SA establishment
> schemes) because most users/system operators will not have the security
> expertise/resources of large service providers.  I recommend that a
separate
> procedure/protocol be developed to satisfy this requirement without
delaying
> the implementation of the existing scheme.

There are subtly but importantly different interpretatiosn of what
you say above. Let me restate and see if you agree with either one of these:
 We know that the IETF protocols and mechanisms for securing the
communication
 between FA, AAA*, and HA will not satisfy the security requirements for
 3G wireless use. But don't worry because we will use other security
protocols
 to make sure we get adequate protection.
 We do need the aaa-key and related IETF documents to move forward in the 
 IETF so that we can get adequate protection for the communication 
 involving the MN.

or

 For other reasons we will be using non-IETF standard mechanisms for
securing
 the communication between FA, AAA*, and HA thus we do not care
 (and perhaps also "have not analysed") the security that the internet
drafts 
 propose to add for the communication between FA, AAA*, and HA.
 We do need the aaa-key and related IETF documents to move forward in the 
 IETF so that we can get adequate protection for the communication 
 involving the MN.

Does either of the above get close to being a restatement of what you said
in the paragraphs above?

* I agree with your characterization that Verizon Wireless (and the 3G
wireless industry) needs the IETF to move forward to establish adequate
protection for MN communications (the air interface is the most vulnerable
link).

However I can't commit solely to either of your two subtle distinctions.  We
do recognize that the existing MIPv4 w/AAA security is apparently based on a
flawed crypto development process (and to that extent I would agree with
your first distinction), but we also recognize that MIP is only one
component within a complete communications system (and that it could be
acceptable for the IETF to consider AAA-to-AAA, AAA-to-HA, and AAA-to-FA
encryption and/or authentication outside the scope of MIPv4 w/ AAA).

Finally, I want to reiterate my support for a new security architecture in
MIPv6 or a later revision of MIPv4 or AAA, however, the current key
distribution proposal will satisfy our security goals.

thanks,

chris


  Erik


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 16:40:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28650
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 16:40:30 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24312;
	Tue, 2 Oct 2001 14:34:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20334;
	Tue, 2 Oct 2001 13:34:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92KXRML006215
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:33:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92KXQMR006214
	for mobile-ip-dist; Tue, 2 Oct 2001 13:33:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92KXNML006207
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:33:23 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15889
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:33:25 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07412
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:34:28 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA27253
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 15:33:24 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 2 Oct 2001 15:33:06 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LTVPG>; Tue, 2 Oct 2001 15:33:02 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E35074C@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco very
Date: Tue, 2 Oct 2001 15:32:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14B81.68D70170"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14B81.68D70170
Content-Type: text/plain;
	charset="iso-8859-1"

Using the SAs between existing autonomous systems solves the security
scalability problem of binding updates. i.e. chained trust. The border
routers act as trust brokers just as they do today for normal routing
updates.

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Monday, October 01, 2001 1:32 AM
To: 'Pekka Savola'
Cc: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn
Disco very


> > >  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
> > > anycast address); this might scale better especially if IPv6 end-nodes
> are
> > > supposed to be simple.
> > >
> > 	=> Do you have any idea about how you can secure this BU ?
> > 	Why is this simpler than sendingit to the CN ?
> > 	What about deployment issues, like .. every router has to have MIPv6
> > 	in it ?
> 
> According to the specs, every IPv6 must be able to do most of these things
> anyway, so requiring routers should be able to do this does not seem like
> a too big additional requirement.
> 
	=> No, according to the specs every node SHOULD do it. If 
	a router doesn't do it, it affects the (potentially thousands)
	of CNs attached to it. 
	Anyway, making the routers do it will involve routers modifying
	dst addresses, breaking e2e ...etc which in itself is not 
	very secure at all.

> I'm not sure how BU can be secured.
> 
	=> Even more so to an anycast address.

> Why I thought it's simpler is simply because there are about two orders of
> magnitude less first-hop routers than hosts.  Which is still a lot, of
> course.
> 
	=> Sure, and there is a lot less NATs as well, but they don't make 
	the Internet any more scalable than e2e communication.

> > > Does anyone really believe that a washing machine, connected to an
> > > Intranet using IPv6, MUST be able to process e.g. Home Address
> Destination
> > > option, or SHOULD be able to process Binding Updates?, or
> > >
> > 	=> MUST. It's not that difficult really is it ? Especially if it can
> do
> > 	IPsec !
> 
> The simple processing of e.g. Home Address Option is easy.  But if you
> want to do it securely, it might get a lot more complicated.
> 
	=> IP address spoofing is not limited to the Home Address option
	and can happen regardless, unless you have the right access 
	control mechanisms.

> Current MIPv6 draft is long.  BU processing, after it is secured, takes a
> lot of that.
> 
	=> Yes but the goal was not to make the draft shorter. RFC2002 is
also
	long and it doesn't have route opt.

> > >  2) Reinstate FA's (e.g. by default all IPv6 routers that implement
> MIPv6)
> > > in the picture, or
> > >
> > >  3) Never mind route optimization, always tunnel back to HA
> > >
> > 	=> Hmmmm .... could you give reasons for why this is better ?
> 
> 2) For example, if there would be 1000 FA's in the world (found e.g. with
> anycast), the routes would be reasonably optimized, and ~1000 would still
> be a reasonable order of magnitude to manage security associations.
> 
	=> Why is managing an SA to a random router easier than a random
	CN ? Just because there are less of them, it doesn't mean it's
	easier. Also I don't think there will only be thousands of default 
	routers, probably much more like hundreds of thousands.

> The traffic could be sent using tunneling between CN -> "FA1" -> "FA2" ->
> MN.
> 
> I've not analyzed in detail whether this would actually help (can MN/CN
> trust FA's?), but if one brought the number of mobility management nodes
> to much lower rate, one _might_ be able to assume something about the key
> management.
> 
	=> Ok maybe a more detailed analysis would better illustrate the
validity of 
	this assumption.

> What I'm thinking is like current "6to4 router" [RFC3056] approach.
> 
> 3) is better (in some aspects) because CN's always send through the HA.
> This is a corner-case of mobilility.  You basically need only some basic
> framework and a tunnel.  Very simple to implement, and to get secure
> because HA-MN can be assumed to have some trust relation.  Only major
> problem is the route optimization..
> 
	=> Yep - route opt is the problem. 

> > 	MIPv6 is having a key exchange problem primarily and people are
> > 	trying to solve it, that is not a reason to start changing
> > everything.
> 
> Of course not, in itself, but consider:  the key exchange problem creates
> a very difficult set requirements.  In the end, it is probably impossible
> to fulfill these without compromises. 
> 
	=> The requirement is made based on the fact that there will be 
	some compromises. I believe our reference is the current IPv4
	Internet, which is by no means 100% secure.

	Hesham

------_=_NextPart_001_01C14B81.68D70170
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn =
Disco very</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Using the SAs between existing autonomous systems =
solves the security scalability problem of binding updates. i.e. =
chained trust. The border routers act as trust brokers just as they do =
today for normal routing updates.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hesham Soliman (EPA) [<A =
HREF=3D"mailto:Hesham.Soliman@ericsson.com.au">mailto:Hesham.Soliman@eri=
csson.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, October 01, 2001 1:32 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Pekka Savola'</FONT>
<BR><FONT SIZE=3D2>Cc: 'mobile-ip@sunroof.eng.sun.com'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option =
processing, HA Dyn</FONT>
<BR><FONT SIZE=3D2>Disco very</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; 1) MN's would send BU's to CN's =
first-hop routers (e.g. subnet-router</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; anycast address); this might scale =
better especially if IPv6 end-nodes</FONT>
<BR><FONT SIZE=3D2>&gt; are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; supposed to be simple.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =3D&gt; Do you have any =
idea about how you can secure this BU ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; Why is this simpler =
than sendingit to the CN ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; What about deployment =
issues, like .. every router has to have MIPv6</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; in it ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; According to the specs, every IPv6 must be able =
to do most of these things</FONT>
<BR><FONT SIZE=3D2>&gt; anyway, so requiring routers should be able to =
do this does not seem like</FONT>
<BR><FONT SIZE=3D2>&gt; a too big additional requirement.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
No, according to the specs every node SHOULD do it. If </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a router =
doesn't do it, it affects the (potentially thousands)</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>of CNs =
attached to it. </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Anyway, =
making the routers do it will involve routers modifying</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>dst =
addresses, breaking e2e ...etc which in itself is not </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>very =
secure at all.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I'm not sure how BU can be secured.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
Even more so to an anycast address.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Why I thought it's simpler is simply because =
there are about two orders of</FONT>
<BR><FONT SIZE=3D2>&gt; magnitude less first-hop routers than =
hosts.&nbsp; Which is still a lot, of</FONT>
<BR><FONT SIZE=3D2>&gt; course.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
Sure, and there is a lot less NATs as well, but they don't make </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>the =
Internet any more scalable than e2e communication.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; &gt; Does anyone really believe that a =
washing machine, connected to an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Intranet using IPv6, MUST be able to =
process e.g. Home Address</FONT>
<BR><FONT SIZE=3D2>&gt; Destination</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; option, or SHOULD be able to process =
Binding Updates?, or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =3D&gt; MUST. It's not =
that difficult really is it ? Especially if it can</FONT>
<BR><FONT SIZE=3D2>&gt; do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; IPsec !</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The simple processing of e.g. Home Address =
Option is easy.&nbsp; But if you</FONT>
<BR><FONT SIZE=3D2>&gt; want to do it securely, it might get a lot more =
complicated.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
IP address spoofing is not limited to the Home Address option</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>and can =
happen regardless, unless you have the right access </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>control =
mechanisms.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Current MIPv6 draft is long.&nbsp; BU =
processing, after it is secured, takes a</FONT>
<BR><FONT SIZE=3D2>&gt; lot of that.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
Yes but the goal was not to make the draft shorter. RFC2002 is</FONT>
<BR><FONT SIZE=3D2>also</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>long and =
it doesn't have route opt.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; 2) Reinstate FA's (e.g. by =
default all IPv6 routers that implement</FONT>
<BR><FONT SIZE=3D2>&gt; MIPv6)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; in the picture, or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; 3) Never mind route =
optimization, always tunnel back to HA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =3D&gt; Hmmmm .... =
could you give reasons for why this is better ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2) For example, if there would be 1000 FA's in =
the world (found e.g. with</FONT>
<BR><FONT SIZE=3D2>&gt; anycast), the routes would be reasonably =
optimized, and ~1000 would still</FONT>
<BR><FONT SIZE=3D2>&gt; be a reasonable order of magnitude to manage =
security associations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
Why is managing an SA to a random router easier than a random</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>CN ? Just =
because there are less of them, it doesn't mean it's</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>easier. =
Also I don't think there will only be thousands of default </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>routers, =
probably much more like hundreds of thousands.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The traffic could be sent using tunneling =
between CN -&gt; &quot;FA1&quot; -&gt; &quot;FA2&quot; -&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; MN.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I've not analyzed in detail whether this would =
actually help (can MN/CN</FONT>
<BR><FONT SIZE=3D2>&gt; trust FA's?), but if one brought the number of =
mobility management nodes</FONT>
<BR><FONT SIZE=3D2>&gt; to much lower rate, one _might_ be able to =
assume something about the key</FONT>
<BR><FONT SIZE=3D2>&gt; management.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
Ok maybe a more detailed analysis would better illustrate the</FONT>
<BR><FONT SIZE=3D2>validity of </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>this =
assumption.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; What I'm thinking is like current &quot;6to4 =
router&quot; [RFC3056] approach.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3) is better (in some aspects) because CN's =
always send through the HA.</FONT>
<BR><FONT SIZE=3D2>&gt; This is a corner-case of mobilility.&nbsp; You =
basically need only some basic</FONT>
<BR><FONT SIZE=3D2>&gt; framework and a tunnel.&nbsp; Very simple to =
implement, and to get secure</FONT>
<BR><FONT SIZE=3D2>&gt; because HA-MN can be assumed to have some trust =
relation.&nbsp; Only major</FONT>
<BR><FONT SIZE=3D2>&gt; problem is the route optimization..</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
Yep - route opt is the problem. </FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; MIPv6 is having a key =
exchange problem primarily and people are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; trying to solve it, =
that is not a reason to start changing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; everything.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Of course not, in itself, but consider:&nbsp; =
the key exchange problem creates</FONT>
<BR><FONT SIZE=3D2>&gt; a very difficult set requirements.&nbsp; In the =
end, it is probably impossible</FONT>
<BR><FONT SIZE=3D2>&gt; to fulfill these without compromises. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>=3D&gt; =
The requirement is made based on the fact that there will be </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>some =
compromises. I believe our reference is the current IPv4</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Internet, =
which is by no means 100% secure.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Hesham</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14B81.68D70170--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 16:53:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29002
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 16:53:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05181;
	Tue, 2 Oct 2001 13:52:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24764;
	Tue, 2 Oct 2001 13:51:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92Kp4ML006326
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:51:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92Kp4fW006325
	for mobile-ip-dist; Tue, 2 Oct 2001 13:51:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92Kp1ML006318
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:51:01 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24501
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:51:04 -0700 (PDT)
Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07488
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:51:02 -0700 (PDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id UAA05964
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 20:51:02 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001100213504611583
 for <mobile-ip@sunroof.eng.sun.com>; Tue, 02 Oct 2001 13:50:46 -0700
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <T5L1BM1L>; Tue, 2 Oct 2001 13:49:02 -0700
Message-ID: <D9223EB959A5D511A98F00508B68C20C347A9A@ORSMSX108>
From: "Adrangi, Farid" <farid.adrangi@intel.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Updating Home Agnet binding entry upon receipt of a re-registrati
	on request 
Date: Tue, 2 Oct 2001 13:50:58 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

What should the home agent (HA) do with a binding entry if the it decides to
reject a re-registration request associated with that binding entry?
Consider MN <perm-address, care-of-address> registers with a HA
successfully.  Later on, the MN decides to refresh its registration with the
HA by sending another registration request.  However, this time HA rejects
the registration request with an "unspecified reason".  What is the expected
behavior of HA and MN at this point?  Should HA keep the old registration
binding entry (of course, if its life-time hasn't already expired)?  Should
MN assume that the old registration binding entry is still valid at the HA?
I haven't found any explicit explanation in the spec pertaining to this
problem (or, perhaps someone can correct me).
regards,
Farid



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 16:59:47 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29262
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 16:59:47 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09561;
	Tue, 2 Oct 2001 13:59:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26845;
	Tue, 2 Oct 2001 13:58:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92Kw7ML006427
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:58:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92Kw6e0006426
	for mobile-ip-dist; Tue, 2 Oct 2001 13:58:06 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92Kw3ML006419
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:58:03 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24972
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 13:58:05 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16302
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:57:54 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA11254;
	Tue, 2 Oct 2001 13:58:04 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f92Kw4Q02483;
	Tue, 2 Oct 2001 13:58:04 -0700
X-mProtect:  Tue, 2 Oct 2001 13:58:04 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdaow4mu; Tue, 02 Oct 2001 13:58:02 PDT
Message-ID: <3BBA2A59.EC750815@iprg.nokia.com>
Date: Tue, 02 Oct 2001 13:58:01 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Adrangi, Farid" <farid.adrangi@intel.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Updating Home Agnet binding entry upon receipt of a 
 re-registration request
References: <D9223EB959A5D511A98F00508B68C20C347A9A@ORSMSX108>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Hello Farid,

If the home agent rejects a registration request, it MUST NOT
alter the existing valid registration information (in v4,
considered to be the relevant entry in the home list).

Regards,
Charlie P.



"Adrangi, Farid" wrote:
> 
> What should the home agent (HA) do with a binding entry if the it decides to
> reject a re-registration request associated with that binding entry?
> Consider MN <perm-address, care-of-address> registers with a HA
> successfully.  Later on, the MN decides to refresh its registration with the
> HA by sending another registration request.  However, this time HA rejects
> the registration request with an "unspecified reason".  What is the expected
> behavior of HA and MN at this point?  Should HA keep the old registration
> binding entry (of course, if its life-time hasn't already expired)?  Should
> MN assume that the old registration binding entry is still valid at the HA?
> I haven't found any explicit explanation in the spec pertaining to this
> problem (or, perhaps someone can correct me).
> regards,
> Farid


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 17:09:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29646
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 17:09:13 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25549;
	Tue, 2 Oct 2001 15:08:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28894;
	Tue, 2 Oct 2001 14:08:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92L7hML006558
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:07:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92L7h1a006557
	for mobile-ip-dist; Tue, 2 Oct 2001 14:07:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92L7dML006550
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:07:39 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27524
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:07:42 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15734
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:07:41 -0700 (PDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f92L7hw15972
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:07:43 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T565a9460aaac12f256126@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 2 Oct 2001 16:07:40 -0500
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 2 Oct 2001 16:07:40 -0500
content-class: urn:content-classes:message
Subject: [mobile-ip] Improving BETH: Tunnel Negotiation
Date: Tue, 2 Oct 2001 16:07:40 -0500
Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF5E4@daebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Improving BETH: Tunnel Negotiation
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFLhkM3VSrLercdEdWaKQAAhjiT+A==
From: "Sreemanthula Srinivas (NRC/Dallas)" <Srinivas.Sreemanthula@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 02 Oct 2001 21:07:40.0783 (UTC) FILETIME=[458FAFF0:01C14B86]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f92L7eML006551
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

We are making the following proposals for improving BETH.  Please refer 
to the following draft for more details.

http://www.ietf.org/internet-drafts/draft-sreeman-enhance-beth-ipv6-00.t
xt

Proposal 1: 
Allow negotiation of lifetime of the BET between the oAR and
the nAR. The smaller of the two timers (Tunnel requester or responder)
should be the one that determines the lifetime of the
tunnel. Negotiation does not mean multiple exchange of messages
between the tunnel end-points. 

Reason: 
Flexibility of deployments especially wherein you have different
domains with differing policies for the way they deal with traffic
coming from within or an external network. 
 
Proposal 2: The support for tunnel refresh or renewal of the lifetime 
of the tunnel should be made known at the time of tunnel setup via 
a flag which indicates whether the tunnel originator or terminator 
allows it. In case either router does not support tunnel refresh, the 
other router needs to react appropriately.

Reason: Prevents subsequent signaling in the network to try to refresh 
the tunnel and discover at that point that the refresh is not possible, 
thus introducing possible latency in the MN handoff. As soon as BETH 
is completed and the MN has moved at L2, the nAR can instruct the 
MN to do get a nCoA. The proposal also provides a mechanism for the 
network of either oAR or nAR to somehow indicate to the MN to HO to 
the nAR at a certain time based on local network policies.

Thanks,
Srinivas Sreemanthula


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 17:12:16 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29812
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 17:12:15 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15211;
	Tue, 2 Oct 2001 14:11:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29325;
	Tue, 2 Oct 2001 14:11:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92LAgML006635
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:10:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92LAgnU006634
	for mobile-ip-dist; Tue, 2 Oct 2001 14:10:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92LAcML006627
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:10:38 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29181
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:10:41 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09902
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:10:38 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f92LAu720966
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:10:56 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T565a970e6eac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 2 Oct 2001 16:10:36 -0500
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 2 Oct 2001 16:10:36 -0500
content-class: urn:content-classes:message
Subject: [mobile-ip] Improving BETH: Network controlled nCoA creation in MN
Date: Tue, 2 Oct 2001 16:10:36 -0500
Message-ID: <07EE0E021034014F99A57B032BC9C0E50BDAEC@daebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Improving BETH: Network controlled nCoA creation in MN
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFLhqvxVSrLkbcdEdWaKQAAhjiT+A==
From: "Sreemanthula Srinivas (NRC/Dallas)" <Srinivas.Sreemanthula@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 02 Oct 2001 21:10:36.0393 (UTC) FILETIME=[AE3BA590:01C14B86]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f92LAdML006628
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

We are making the following proposals for improving BETH.  Please refer 
to the following draft for more details.

http://www.ietf.org/internet-drafts/draft-sreeman-enhance-beth-ipv6-00.t
xt


Current BETH:
According to draft-kempf-beth-ipv6-02.txt, the BET tunnels between the
oAR and the nAR can be renewed and as such the MN may never really
need to get a nCOA (at the nAR) even though it is now being served by
that AR. A PrtRtAdv is sent to the MN (to get a nCOA) only when the
lifetime of the tunnel cannot be extended (or other reasons).
 
Proposal:
It should be possible for the network to have more control in forcing
the MN to acquire a
new COA at the nAR and thus handoff to nAR. Hence it should be possible
to send the MN a
modified ProxyRtrAdvt based on tunnel lifetime determined. It should be
possible to do so from either the oAR and the nAR. We propose to extend
the existing 
conditions in draft-kempf-beth-ipv6-02.txt under which the network can
ask the MN 
to get a nCoA to include local policies as the reason.

Reason:
Different domains will manage traffic and QoS according to specific
mechanisms and policies. 
For some networks it may be necessary or preferrable to allow the
existence of BETs only for 
a limited period of time, thus it should be possible for the network to
force the MN to get a nCoA once the BET is established.

 



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 17:17:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29930
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 17:17:12 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02087;
	Tue, 2 Oct 2001 15:16:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00781;
	Tue, 2 Oct 2001 14:16:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92LEgML006727
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:14:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92LEg67006726
	for mobile-ip-dist; Tue, 2 Oct 2001 14:14:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92LEcML006717
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:14:38 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29070
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:14:41 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00500
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 15:14:29 -0600 (MDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f92LEx721611
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:14:59 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T565a9ac4cbac12f257079@davir04nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 2 Oct 2001 16:14:39 -0500
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 2 Oct 2001 16:14:48 -0500
content-class: urn:content-classes:message
Subject: [mobile-ip] Improving BETH: MN acknowledgement after adopting nCoA
Date: Tue, 2 Oct 2001 16:14:39 -0500
Message-ID: <07EE0E021034014F99A57B032BC9C0E50BDAED@daebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Improving BETH: MN acknowledgement after adopting nCoA
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFLhzzPVSrLrbcdEdWaKQAAhjiT+A==
From: "Sreemanthula Srinivas (NRC/Dallas)" <Srinivas.Sreemanthula@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 02 Oct 2001 21:14:48.0201 (UTC) FILETIME=[44527F90:01C14B87]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f92LEcML006720
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

We are making the following proposals for improving BETH.  Please refer 
to the following draft for more details.

http://www.ietf.org/internet-drafts/draft-sreeman-enhance-beth-ipv6-00.t
xt


Current BETH:
According to draft-kempf-beth-ipv6-02.txt, the BET tunnels can be torn
down after the MN forms the nCoA and after performing the mobility
procedures to update the HA and the CN.  After adopting the nCoA,
neither the MN nor the CN use the oCoA and therefore the BET tunnel is
not required and can be released.  

Proposal:
Introduce a specific mechanism to trigger the tear down of BET tunnels
based on a message sent by the MN.

Reason: 
The decision to tear down the tunnel with current BETH can be based e.g.
simply on the tunnel lifetime or on the amount of traffic on the BET,
but there is no definitive indication of when the tunnels are not needed
anymore. Thus, the BET must be maintained till the lifetime expiration,
or even worse the ARs can try to renew the tunnels even if they are not
in use. MN knows if it has performed the HO to nAR after getting the
nCoA, thus the MN can indicate whether the tunnels are needed or not.
Different domains will manage traffic and QoS according to specific
mechanisms and policies. For some networks it may be necessary or
preferrable to allow the existence of BETs only for a limited period of
time, thus it should be possible for the network to tear down the BET as
soon as possible.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 17:37:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00410
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 17:37:02 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18989;
	Tue, 2 Oct 2001 15:36:26 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06001;
	Tue, 2 Oct 2001 14:36:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92LZFML006833
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:35:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92LZFL2006832
	for mobile-ip-dist; Tue, 2 Oct 2001 14:35:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92LZBML006825
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:35:12 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05079
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:35:08 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10425
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 15:36:11 -0600 (MDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f92LZQ723111
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:35:26 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T565aad7ca1ac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 2 Oct 2001 16:35:06 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 2 Oct 2001 16:35:15 -0500
content-class: urn:content-classes:message
Subject:  [mobile-ip] Improving BETH: chain tunneling
Date: Tue, 2 Oct 2001 16:35:14 -0500
Message-ID: <748E8123D183394982E32A511DB3E73609CC1A@daebe005.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Improving BETH: Network controlled nCoA creation in MN
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFLhxDNv+UEhLdzEdWxLwAIx6TWeAAAlnHg
From: "Purnadi Rene (NRC/Dallas)" <rene.purnadi@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 02 Oct 2001 21:35:15.0014 (UTC) FILETIME=[1F8F4E60:01C14B8A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f92LZCML006826
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

We are making the following proposals for improving BETH.  Please refer
to the following draft for more details.

http://www.ietf.org/internet-drafts/draft-sreeman-enhance-beth-ipv6-00.t
xt

Current BETH:
 
According to draft-kempf-beth-ipv6-02.txt, in the model for the "handoff
to third" a new BET tunnel is established from the anchor AR (aAR) to
the new AR (nAR). Since the MN may maintain the BET tunnels for a while,
there may be some issues related to QoS. In fact, in order to guarantee
that the BET tunnel supports the QoS needed by the MN, we need to either
assume that an SLA is in place between the oAR and nAR or that
"pre-defined" QoS is allocated between the oAR and the nAR. However,
since it is not possible to foresee a-priori where the MN is going to
handoff to and since the BET tunnels will be established not only
between "adjacent" routers but also between non-adjacent routers (HTT
case), the adoption of SLAs or pre-defined QoS in order to guarantee the
QoS for the MN over the tunnel does not scale well. As an alternative,
at the BET establishment a QoS negotiation can take place to ensure the
QoS for the tunnel will be supported. However, such QoS negotiation may
in some situations introduce some latency.

		       new tunnel
       || ==============================================||
       ||                                               ||
  +-------+                  +-------+               +-------+
  |       |    old tunnel    |       |               |       |
  |  aAR  | ================ | oAR   |               |  nAR  |
  |       |                  |       |               |       |
  +-------+                  +-------+               +-------+

            Original BETH procedure

  +-------+                  +-------+                +-------+
  |       |    old tunnel    |       |  new tunnel    |       |
  | aAR   | ================ | oAR   | ===============|  nAR  |
  |       |                  |       |                |       |
  +-------+                  +-------+                +-------+

            Proposed Beth enhancement

Proposed enhancement:
 
We propose that the BETH model should accommodate the option of "chain
tunneling" where, in case of handoff to third, the oAR creates a new
tunnel to the nAR. The procedure to establish the new BET tunnel from
oAR to the nAR is  the same as the procedure to establish the initial
tunnel from the aAR to the oAR. 

Reason:

Different domains will manage traffic and QoS according to specific
mechanisms and policies. Some networks may prefer to support QoS for BET
tunnels by pre-allocating QoS between physically adjacent routers, i.e.
router to which the MN can move in "one step" due to handoff. Given a
router, the number of physically adjacent routers is limited, and the
amount of QoS "pre-allocated" can be determined, e.g. for cellular
links, based on the amount of radio links that can be accepted in a cell
as handoff links (this is already being done in cellular networks, thus
there is no impact on L2). The use of chain tunnels and pre-allocated
QoS is a scalable solution that allows for fast handoffs and guaranteed
QoS with minimal network configuration.

Result:

Creating long tunnel chains may have issues, e.g. many routers in the
chain need to maintain the state. The chaining issues, however, can be
reduced by forcing the MN to obtain a new COA every time it does a BETH
Handoff. The proposed chain tunneling plus the network ability to force
the MN to obtain nCoA and to move to the nAR, solve the issue related to
chain tunneling. For fast moving MN, a new BETH handoff may take place
before the MN has created nCoA and moved to the nAR,thus multiple
tunnels may exist at the same time. However, multiple tunnels are only
temporary.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 17:43:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00520
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 17:43:43 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23974;
	Tue, 2 Oct 2001 15:42:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07669;
	Tue, 2 Oct 2001 14:42:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92Lg3ML006924
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:42:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92Lg3jN006923
	for mobile-ip-dist; Tue, 2 Oct 2001 14:42:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92LfxML006916
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:41:59 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07194
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:42:00 -0700 (PDT)
Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02593
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 14:42:00 -0700 (PDT)
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id VAA11422
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 21:42:00 GMT
Received: from FMSMSX016.fm.intel.com ([132.233.42.195])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001100214433120511
 ; Tue, 02 Oct 2001 14:43:31 -0700
Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <4CKGGMG0>; Tue, 2 Oct 2001 14:40:14 -0700
Message-ID: <D9223EB959A5D511A98F00508B68C20C347A9C@ORSMSX108>
From: "Adrangi, Farid" <farid.adrangi@intel.com>
To: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
        "Adrangi, Farid" <farid.adrangi@intel.com>
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Updating Home Agnet binding entry upon receipt of
	 a  re-registration request
Date: Tue, 2 Oct 2001 14:41:58 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Thanks for a quick clarification.  Should there be an explicit reference in
the spec about this, as it seems to be important for interoperability?  Or,
perhaps the spec addresses this but I missed it!
regards,
Farid


-----Original Message-----
From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
Sent: Tuesday, October 02, 2001 1:58 PM
To: Adrangi, Farid
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Updating Home Agnet binding entry upon receipt
of a re-registration request




Hello Farid,

If the home agent rejects a registration request, it MUST NOT
alter the existing valid registration information (in v4,
considered to be the relevant entry in the home list).

Regards,
Charlie P.



"Adrangi, Farid" wrote:
> 
> What should the home agent (HA) do with a binding entry if the it decides
to
> reject a re-registration request associated with that binding entry?
> Consider MN <perm-address, care-of-address> registers with a HA
> successfully.  Later on, the MN decides to refresh its registration with
the
> HA by sending another registration request.  However, this time HA rejects
> the registration request with an "unspecified reason".  What is the
expected
> behavior of HA and MN at this point?  Should HA keep the old registration
> binding entry (of course, if its life-time hasn't already expired)?
Should
> MN assume that the old registration binding entry is still valid at the
HA?
> I haven't found any explicit explanation in the spec pertaining to this
> problem (or, perhaps someone can correct me).
> regards,
> Farid


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 18:36:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01881
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 18:36:09 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02409;
	Tue, 2 Oct 2001 16:35:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16813;
	Tue, 2 Oct 2001 15:35:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92MYgML007064
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 15:34:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92MYfrH007063
	for mobile-ip-dist; Tue, 2 Oct 2001 15:34:41 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92MYcML007056
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 15:34:38 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16644
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 15:34:39 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01643
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:34:28 -0600 (MDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f92MYIw22753
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 17:34:18 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T565ae3a440ac12f2540ff@davir01nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 2 Oct 2001 17:34:15 -0500
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 2 Oct 2001 17:34:15 -0500
content-class: urn:content-classes:message
Subject: [mobile-ip] Improving BETH
Date: Tue, 2 Oct 2001 17:34:15 -0500
Message-ID: <07EE0E021034014F99A57B032BC9C0E50BDAF1@daebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Improving BETH
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFLkllDVSrMC7cdEdWaKQAAhjiT+A==
From: "Sreemanthula Srinivas (NRC/Dallas)" <Srinivas.Sreemanthula@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 02 Oct 2001 22:34:15.0488 (UTC) FILETIME=[5DD8C400:01C14B92]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f92MYcML007057
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

The link to the draft in our previous emails was broken, 
here is right link.

www.ietf.org/internet-drafts/draft-sreeman-enhance-beth-ipv6-00.txt

Thanks,
Srinivas Sreemanthula



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 19:26:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03157
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 19:26:42 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07153;
	Tue, 2 Oct 2001 17:25:36 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02242;
	Tue, 2 Oct 2001 16:25:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92NOWML007273
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:24:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f92NOWfd007272
	for mobile-ip-dist; Tue, 2 Oct 2001 16:24:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f92NOSML007265
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:24:28 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28630
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 16:24:30 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02903
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 17:25:33 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA18997
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 18:24:29 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 2 Oct 2001 18:17:36 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LTZA4>; Tue, 2 Oct 2001 18:23:54 -0500
Message-ID: <23BDB0046F3ED51185CD0002A5608D24513558@zrc2c009.us.nortel.com>
From: "Kuntal Chowdhury" <chowdury@nortelnetworks.com>
To: Pat Calhoun <pcalhoun@diameter.org>
Cc: pcalhoun@diameter.org, charliep@IPRG.nokia.com,
        mobile-ip@sunroof.eng.sun.com, diameter@diameter.org
Subject: [mobile-ip] RE: [diameter] DIAMETER support for MIP question
Date: Tue, 2 Oct 2001 18:23:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14B99.4A9283C0"
X-Orig: <chowdury@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14B99.4A9283C0
Content-Type: text/plain;
	charset="iso-8859-1"

Pat,
Thanks for responding. I am still not clear on the following two issues in
"draft-ietf-aaa-diameter-mobileip-07":

1. Section 1.4 Page 12

AAAF in foreign network 1 will send back error code
"DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE" to AAAH if foreign network 1 does not
wish to provide HA service when the MN has moved to foreign network 2.
However it is not mentioned when the AAAH receives such an error code from
AAAF what happens to the mobile IP registration request. 
I think some text is required to capture this exception case. Options before
AAAH is either send another HAR to AAAF in network 2 (only if AAAF had set
the "Foreign-Home-Agent-Available" flag in AMR), otherwise AAAH may assign a
HA in the home network or reject the mobile IP registration request. 

2. When MN requests for a HA allocation in the foreign network, and for some
reason AAAF does not set "Foreign-Home-Agent-Available" or AAAH denies the
request, how does the MN come to know that it did not get what it requested?

If it is immaterial for the MN's MIP client to know where the HA gets
allocated, why does it ask for it differently e.g. some MNs requesting with
0.0.0.0 and some others requesting with 255.255.255.255?


Regards,
Kuntal 

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Tuesday, October 02, 2001 10:24 AM
To: Chowdhury, Kuntal [RICH2:2H18:EXCH]
Cc: pcalhoun@diameter.org; charliep@IPRG.nokia.com;
mobile-ip@sunroof.eng.sun.com; diameter@diameter.org
Subject: Re: [diameter] DIAMETER support for MIP question


hmmm... first off, version 2 is quite old, and 7 should be used (or even
better
the 08 alpha released last week).

In the later versions, the AAAF sets a bit if it is willing to provide HA
services
in the foreign network. Further, the AAAH has the option to choose whether
it is
willing to let the mobile use this service. If so, it forwards the HAR to
the
foreign network's AAAF, otherwise it sends the HAR to a local HA.

The zero HA address is a request to have a home agent dynamically assigned
to the
mobile.

hope this helps,

PatC
On Mon, Oct 01, 2001 at 02:15:31PM -0500, Kuntal Chowdhury wrote:
> Pat/Charlie,
> I am curious to know the implication on a mobile node when it sends
0.0.0.0
> in the HA address field in MIP registration request for HA assignment in
the
> local network but the HA gets assigned in the home network. In section 4.2
> in "draft-ietf-aaa-diameter-mobileip-02", there is an error code
> "DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5007" which AAAF sends back to AAAH
to
> inform that it cannot assign a HA in the local network. In this case, does
> the AAAH assign a HA in the home network? Does the mobile node get any
> indication of this event? 
> 
> Regards,
> Kuntal

------_=_NextPart_001_01C14B99.4A9283C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [diameter] DIAMETER support for MIP question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Pat,</FONT>
<BR><FONT SIZE=3D2>Thanks for responding. I am still not clear on the =
following two issues in =
&quot;draft-ietf-aaa-diameter-mobileip-07&quot;:</FONT>
</P>

<P><FONT SIZE=3D2>1. Section 1.4 Page 12</FONT>
</P>

<P><FONT SIZE=3D2>AAAF in foreign network 1 will send back error code =
&quot;DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE&quot; to AAAH if foreign =
network 1 does not wish to provide HA service when the MN has moved to =
foreign network 2. However it is not mentioned when the AAAH receives =
such an error code from AAAF what happens to the mobile IP registration =
request. </FONT></P>

<P><FONT SIZE=3D2>I think some text is required to capture this =
exception case. Options before AAAH is either send another HAR to AAAF =
in network 2 (only if AAAF had set the =
&quot;Foreign-Home-Agent-Available&quot; flag in AMR), otherwise AAAH =
may assign a HA in the home network or reject the mobile IP =
registration request. </FONT></P>

<P><FONT SIZE=3D2>2. When MN requests for a HA allocation in the =
foreign network, and for some reason AAAF does not set =
&quot;Foreign-Home-Agent-Available&quot; or AAAH denies the request, =
how does the MN come to know that it did not get what it requested? =
</FONT></P>

<P><FONT SIZE=3D2>If it is immaterial for the MN's MIP client to know =
where the HA gets allocated, why does it ask for it differently e.g. =
some MNs requesting with 0.0.0.0 and some others requesting with =
255.255.255.255?</FONT></P>
<BR>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Kuntal </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Pat Calhoun [<A =
HREF=3D"mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, October 02, 2001 10:24 AM</FONT>
<BR><FONT SIZE=3D2>To: Chowdhury, Kuntal [RICH2:2H18:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: pcalhoun@diameter.org; =
charliep@IPRG.nokia.com;</FONT>
<BR><FONT SIZE=3D2>mobile-ip@sunroof.eng.sun.com; =
diameter@diameter.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [diameter] DIAMETER support for MIP =
question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>hmmm... first off, version 2 is quite old, and 7 =
should be used (or even better</FONT>
<BR><FONT SIZE=3D2>the 08 alpha released last week).</FONT>
</P>

<P><FONT SIZE=3D2>In the later versions, the AAAF sets a bit if it is =
willing to provide HA services</FONT>
<BR><FONT SIZE=3D2>in the foreign network. Further, the AAAH has the =
option to choose whether it is</FONT>
<BR><FONT SIZE=3D2>willing to let the mobile use this service. If so, =
it forwards the HAR to the</FONT>
<BR><FONT SIZE=3D2>foreign network's AAAF, otherwise it sends the HAR =
to a local HA.</FONT>
</P>

<P><FONT SIZE=3D2>The zero HA address is a request to have a home agent =
dynamically assigned to the</FONT>
<BR><FONT SIZE=3D2>mobile.</FONT>
</P>

<P><FONT SIZE=3D2>hope this helps,</FONT>
</P>

<P><FONT SIZE=3D2>PatC</FONT>
<BR><FONT SIZE=3D2>On Mon, Oct 01, 2001 at 02:15:31PM -0500, Kuntal =
Chowdhury wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Pat/Charlie,</FONT>
<BR><FONT SIZE=3D2>&gt; I am curious to know the implication on a =
mobile node when it sends 0.0.0.0</FONT>
<BR><FONT SIZE=3D2>&gt; in the HA address field in MIP registration =
request for HA assignment in the</FONT>
<BR><FONT SIZE=3D2>&gt; local network but the HA gets assigned in the =
home network. In section 4.2</FONT>
<BR><FONT SIZE=3D2>&gt; in =
&quot;draft-ietf-aaa-diameter-mobileip-02&quot;, there is an error =
code</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE =
5007&quot; which AAAF sends back to AAAH to</FONT>
<BR><FONT SIZE=3D2>&gt; inform that it cannot assign a HA in the local =
network. In this case, does</FONT>
<BR><FONT SIZE=3D2>&gt; the AAAH assign a HA in the home network? Does =
the mobile node get any</FONT>
<BR><FONT SIZE=3D2>&gt; indication of this event? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Kuntal</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14B99.4A9283C0--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 21:49:08 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07432
	for <mobileip-archive@odin.ietf.org>; Tue, 2 Oct 2001 21:49:07 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA26532;
	Tue, 2 Oct 2001 18:48:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29090;
	Tue, 2 Oct 2001 18:48:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f931lHML007451
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 18:47:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f931lGAO007450
	for mobile-ip-dist; Tue, 2 Oct 2001 18:47:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f931lDML007443
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 18:47:13 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29556
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 18:47:14 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06181
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 18:47:13 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA04637
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 11:45:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA27865
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 11:46:37 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXGPD1>; Wed, 3 Oct 2001 11:46:36 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ECEC@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco
	 very
Date: Wed, 3 Oct 2001 11:46:34 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14BAD.3B806460"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14BAD.3B806460
Content-Type: text/plain;
	charset="iso-8859-1"

Glenn, 

I think this is a very dangerous assertion to make. You seem to imply 
that provided we have our own "secure/closed" ASs with a SG
on the edge, and provided that the edges trust each other, we'll be
ok. 
I don't think that's true.


> -----Original Message-----
> From:	Glenn Morrow [SMTP:gmorrow@nortelnetworks.com]
> Sent:	Wednesday, 3 October 2001 6:33
> To:	mobile-ip@sunroof.eng.sun.com
> Subject:	RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn
> Disco very
> 
> Using the SAs between existing autonomous systems solves the security
> scalability problem of binding updates. i.e. chained trust. The border
> routers act as trust brokers just as they do today for normal routing
> updates.
> 
> -----Original Message----- 
> From: Hesham Soliman (EPA) [ <mailto:Hesham.Soliman@ericsson.com.au>] 
> Sent: Monday, October 01, 2001 1:32 AM 
> To: 'Pekka Savola' 
> Cc: 'mobile-ip@sunroof.eng.sun.com' 
> Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn 
> Disco very 
> 
> 
> > > >  1) MN's would send BU's to CN's first-hop routers (e.g.
> subnet-router 
> > > > anycast address); this might scale better especially if IPv6
> end-nodes 
> > are 
> > > > supposed to be simple. 
> > > > 
> > >     => Do you have any idea about how you can secure this BU ? 
> > >     Why is this simpler than sendingit to the CN ? 
> > >     What about deployment issues, like .. every router has to have
> MIPv6 
> > >     in it ? 
> > 
> > According to the specs, every IPv6 must be able to do most of these
> things 
> > anyway, so requiring routers should be able to do this does not seem
> like 
> > a too big additional requirement. 
> > 
>         => No, according to the specs every node SHOULD do it. If 
>         a router doesn't do it, it affects the (potentially thousands) 
>         of CNs attached to it. 
>         Anyway, making the routers do it will involve routers modifying 
>         dst addresses, breaking e2e ...etc which in itself is not 
>         very secure at all. 
> 
> > I'm not sure how BU can be secured. 
> > 
>         => Even more so to an anycast address. 
> 
> > Why I thought it's simpler is simply because there are about two orders
> of 
> > magnitude less first-hop routers than hosts.  Which is still a lot, of 
> > course. 
> > 
>         => Sure, and there is a lot less NATs as well, but they don't make
> 
>         the Internet any more scalable than e2e communication. 
> 
> > > > Does anyone really believe that a washing machine, connected to an 
> > > > Intranet using IPv6, MUST be able to process e.g. Home Address 
> > Destination 
> > > > option, or SHOULD be able to process Binding Updates?, or 
> > > > 
> > >     => MUST. It's not that difficult really is it ? Especially if it
> can 
> > do 
> > >     IPsec ! 
> > 
> > The simple processing of e.g. Home Address Option is easy.  But if you 
> > want to do it securely, it might get a lot more complicated. 
> > 
>         => IP address spoofing is not limited to the Home Address option 
>         and can happen regardless, unless you have the right access 
>         control mechanisms. 
> 
> > Current MIPv6 draft is long.  BU processing, after it is secured, takes
> a 
> > lot of that. 
> > 
>         => Yes but the goal was not to make the draft shorter. RFC2002 is 
> also 
>         long and it doesn't have route opt. 
> 
> > > >  2) Reinstate FA's (e.g. by default all IPv6 routers that implement 
> > MIPv6) 
> > > > in the picture, or 
> > > > 
> > > >  3) Never mind route optimization, always tunnel back to HA 
> > > > 
> > >     => Hmmmm .... could you give reasons for why this is better ? 
> > 
> > 2) For example, if there would be 1000 FA's in the world (found e.g.
> with 
> > anycast), the routes would be reasonably optimized, and ~1000 would
> still 
> > be a reasonable order of magnitude to manage security associations. 
> > 
>         => Why is managing an SA to a random router easier than a random 
>         CN ? Just because there are less of them, it doesn't mean it's 
>         easier. Also I don't think there will only be thousands of default
> 
>         routers, probably much more like hundreds of thousands. 
> 
> > The traffic could be sent using tunneling between CN -> "FA1" -> "FA2"
> -> 
> > MN. 
> > 
> > I've not analyzed in detail whether this would actually help (can MN/CN 
> > trust FA's?), but if one brought the number of mobility management nodes
> 
> > to much lower rate, one _might_ be able to assume something about the
> key 
> > management. 
> > 
>         => Ok maybe a more detailed analysis would better illustrate the 
> validity of 
>         this assumption. 
> 
> > What I'm thinking is like current "6to4 router" [RFC3056] approach. 
> > 
> > 3) is better (in some aspects) because CN's always send through the HA. 
> > This is a corner-case of mobilility.  You basically need only some basic
> 
> > framework and a tunnel.  Very simple to implement, and to get secure 
> > because HA-MN can be assumed to have some trust relation.  Only major 
> > problem is the route optimization.. 
> > 
>         => Yep - route opt is the problem. 
> 
> > >     MIPv6 is having a key exchange problem primarily and people are 
> > >     trying to solve it, that is not a reason to start changing 
> > > everything. 
> > 
> > Of course not, in itself, but consider:  the key exchange problem
> creates 
> > a very difficult set requirements.  In the end, it is probably
> impossible 
> > to fulfill these without compromises. 
> > 
>         => The requirement is made based on the fact that there will be 
>         some compromises. I believe our reference is the current IPv4 
>         Internet, which is by no means 100% secure. 
> 
>         Hesham 
> 

------_=_NextPart_001_01C14BAD.3B806460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn =
Disco very</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Glenn, </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I think this is a =
very dangerous assertion to make. You seem to imply </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">that provided we =
have our own &quot;secure/closed&quot; ASs with a SG</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">on the edge, and =
provided that the edges trust each other, we'll be</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">ok. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I don't think =
that's true.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Glenn Morrow =
[SMTP:gmorrow@nortelnetworks.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, 3 October 2001 6:33</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mobile-ip@sunroof.eng.sun.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: [mobile-ip] MIPv6 SecReqs: HA =
Option processing, HA Dyn Disco very</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Using the SAs between existing =
autonomous systems solves the security scalability problem of binding =
updates. i.e. chained trust. The border routers act as trust brokers =
just as they do today for normal routing updates.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">From: Hesham Soliman (EPA) =
[</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;<A =
HREF=3D"mailto:Hesham.Soliman@ericsson.com.au">mailto:Hesham.Soliman@eri=
csson.com.au</A>&gt;</FONT></U><FONT SIZE=3D2 =
FACE=3D"Arial">]</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Sent: Monday, October 01, 2001 =
1:32 AM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">To: 'Pekka Savola'</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Cc: =
'mobile-ip@sunroof.eng.sun.com'</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Subject: RE: [mobile-ip] MIPv6 =
SecReqs: HA Option processing, HA Dyn</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Disco very</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;=A0 1) MN's would send =
BU's to CN's first-hop routers (e.g. subnet-router</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; anycast address); =
this might scale better especially if IPv6 end-nodes</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; are</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; supposed to be =
simple.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 =3D&gt; Do you =
have any idea about how you can secure this BU ?</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 Why is this =
simpler than sendingit to the CN ?</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 What about =
deployment issues, like .. every router has to have MIPv6</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 in it =
?</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; According to the specs, every IPv6 =
must be able to do most of these things</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; anyway, so requiring routers =
should be able to do this does not seem like</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; a too big additional =
requirement.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; No, according to the specs every node SHOULD do =
it. If</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">a router doesn't do it, it affects the (potentially =
thousands)</FONT><FONT FACE=3D"Arial"><BR>
=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D"Arial">of CNs =
attached to it.</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Anyway, making the routers do it will involve routers =
modifying</FONT><FONT FACE=3D"Arial"><BR>
=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D"Arial">dst =
addresses, breaking e2e ...etc which in itself is not</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">very secure at all.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I'm not sure how BU can be =
secured.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; Even more so to an anycast address.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Why I thought it's simpler is =
simply because there are about two orders of</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; magnitude less first-hop =
routers than hosts.=A0 Which is still a lot, of</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; course.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; Sure, and there is a lot less NATs as well, but =
they don't make</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">the Internet any more scalable than e2e =
communication.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Does anyone really =
believe that a washing machine, connected to an</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Intranet using =
IPv6, MUST be able to process e.g. Home Address</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; Destination</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; option, or SHOULD =
be able to process Binding Updates?, or</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 =3D&gt; MUST. =
It's not that difficult really is it ? Especially if it can</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; do</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 IPsec =
!</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; The simple processing of e.g. Home =
Address Option is easy.=A0 But if you</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; want to do it securely, it =
might get a lot more complicated.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; IP address spoofing is not limited to the Home =
Address option</FONT><FONT FACE=3D"Arial"><BR>
=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D"Arial">and can =
happen regardless, unless you have the right access</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">control mechanisms.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Current MIPv6 draft is long.=A0 =
BU processing, after it is secured, takes a</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; lot of that.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D=
"Arial">=3D&gt; Yes but the goal was not to make the draft shorter. =
RFC2002 is</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">also</FONT><FONT =
FACE=3D"Arial"><BR>
=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D"Arial">long and it =
doesn't have route opt.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;=A0 2) Reinstate FA's =
(e.g. by default all IPv6 routers that implement</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; MIPv6)</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; in the picture, =
or</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;=A0 3) Never mind =
route optimization, always tunnel back to HA</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 =3D&gt; Hmmmm =
.... could you give reasons for why this is better ?</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; 2) For example, if there would be =
1000 FA's in the world (found e.g. with</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; anycast), the routes would be =
reasonably optimized, and ~1000 would still</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; be a reasonable order of =
magnitude to manage security associations.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; Why is managing an SA to a random router easier =
than a random</FONT><FONT FACE=3D"Arial"><BR>
=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D"Arial">CN ? Just =
because there are less of them, it doesn't mean it's</FONT><FONT =
FACE=3D"Arial"><BR>
=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D"Arial">easier. Also =
I don't think there will only be thousands of default</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">routers, probably much more like hundreds of =
thousands.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The traffic could be sent using =
tunneling between CN -&gt; &quot;FA1&quot; -&gt; &quot;FA2&quot; =
-&gt;</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; MN.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; I've not analyzed in detail whether =
this would actually help (can MN/CN</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; trust FA's?), but if one =
brought the number of mobility management nodes</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; to much lower rate, one =
_might_ be able to assume something about the key</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; management.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; Ok maybe a more detailed analysis would better =
illustrate the</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">validity of</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">this assumption.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; What I'm thinking is like current =
&quot;6to4 router&quot; [RFC3056] approach.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; 3) is better (in some aspects) =
because CN's always send through the HA.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; This is a corner-case of =
mobilility.=A0 You basically need only some basic</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; framework and a tunnel.=A0 =
Very simple to implement, and to get secure</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; because HA-MN can be assumed =
to have some trust relation.=A0 Only major</FONT><FONT FACE=3D"Arial"><B=
R>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; problem is the route =
optimization..</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; Yep - route opt is the problem.</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 MIPv6 is having a =
key exchange problem primarily and people are</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =A0=A0=A0 trying to =
solve it, that is not a reason to start changing</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; everything.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt; Of course not, in itself, but =
consider:=A0 the key exchange problem creates</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; a very difficult set =
requirements.=A0 In the end, it is probably impossible</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt; to fulfill these without =
compromises.</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">=3D&gt; The requirement is made based on the fact that =
there will be</FONT><BR>
<FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">some compromises. I believe our reference is the current =
IPv4</FONT><FONT FACE=3D"Arial"><BR>
=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 FACE=3D"Arial">Internet, =
which is by no means 100% secure.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Hesham</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C14BAD.3B806460--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  2 22:26:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08708
	for <mobileip-archive@lists.ietf.org>; Tue, 2 Oct 2001 22:26:15 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05070;
	Tue, 2 Oct 2001 20:25:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11189;
	Tue, 2 Oct 2001 19:25:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f932OTML007580
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 19:24:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f932OTGe007579
	for mobile-ip-dist; Tue, 2 Oct 2001 19:24:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f932OPML007572
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 19:24:25 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03159
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 19:24:27 -0700 (PDT)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22691
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 19:24:26 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C14BB2.858A1CCC"
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
Subject: RE: [mobile-ip] Security Requirements Draft
Date: Tue, 2 Oct 2001 22:24:25 -0400
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB21068B62@EXCHANGE01.domain.ecutel.com>
X-MS-TNEF-Correlator: <AF2378CBE7016247BC0FD5261F1EEB21068B62@EXCHANGE01.domain.ecutel.com>
Thread-Topic: [mobile-ip] Security Requirements Draft
Thread-Index: AcFLArSx1Y078BL1SzK+yyLr+jb1ZgAqnFDQ
From: "Qiang Zhang" <qzhang@ecutel.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C14BB2.858A1CCC
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

IA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogR3JlZ29yeSBEYWxleSAN
CglTZW50OiBUdWUgMTAvMi8yMDAxIDE6MjIgQU0gDQoJVG86IG1vYmlsZS1pcEBzdW5yb29mLmVu
Zy5zdW4uY29tIA0KCUNjOiBncmVnLmRhbGV5QGVuZy5tb25hc2guZWR1LmF1IA0KCVN1YmplY3Q6
IFJlOiBbbW9iaWxlLWlwXSBTZWN1cml0eSBSZXF1aXJlbWVudHMgRHJhZnQNCgkNCgkNCg0KCT4g
ICAgICAgIERvIHlvdSB0aGluayBpdCBtYXkgYmUgdXNlZnVsIHRvIGRlZmluZSBhIG1vZGUgaW4g
dGhlDQpNSVB2Ng0KCT4gYmFzZWZvciB0aGUgTU4gdG8gY2hvb3NlIHVzaW5nIHJldi10dW5uZWwg
b25seT8gVGhhdCB3YXkgaXQNCm1heSBiZQ0KCT4gYmVuZWZpY2lhbCB0byBzb21lIHVzYWdlIG1v
ZGVscywgZm9yIGV4YW1wbGUsIHRvIGFjaGl2ZSBNTidzDQpsb2NhdGlvbg0KCT4gcHJpdmFjeSAo
bm8gQlUgc2VudCB0byBDTiwgbmVpdGhlciBmcm9tIEhBIG5vciBNTikgYW5kIGFsc28NCmNvbnRy
b2xsZWQNCgk+IGFjY2VzcyBwb2xpY3kgY2FuIGJlIGltcG9zZWQgZm9yIHRoZSBNTiBmcm9tIGhv
bWUgbmV0d29yay4NCgk+ICAgICAgICANCgk+ICAgICAgICBPciB3b3VsZCB0aGlzIGJlIGxlZnQg
dG8gaW1wbGVtZW50YXRpb25zIHRvIGRlZmluZSBpdHMNCm93bj8NCgkNCgkgICAgICAgIEhpIFFp
YW5nLA0KCQ0KCSAgICAgICAgU29tZSBtZWNoYW5pc21zIHRvIHByb3ZpZGUgdGhpcyBmdW5jdGlv
biBhcmUgaW5kaWNhdGVkDQoJICAgICAgICBpbiB0aGUgSE1JUHY2IGRyYWZ0LCB3aGljaCBwcm92
aWRlcyBhIGxvY2F0aW9uIHByaXZhY3kNCgkgICAgICAgIFNlY3Rpb24gNi42ICgrNi41KQ0KCQ0K
CSAgICAgICAgVGhpcyBtYXkgbm90IGJlIHRoZSBzYW1lIHRvb2wgSSB0aGluayBpdCBpcw0KCSAg
ICAgICAgaW50ZW5kZWQgdG8gc29sdmUgdGhlIHNhbWUgcHJvYmxlbS4gKGZvciBleGFtcGxlLA0K
CSAgICAgICAgaWYgYSBNQVAgaXMgYWxzbyB0aGUgSEEpDQoJDQoJICAgICAgICBQZXJoYXBzIGl0
IGlzIGJldHRlciB0byBoYXZlIHRoZSBmdW5jdGlvbiBvbmx5IG1hbmRhdGVkDQoJICAgICAgICBv
bmNlIHNvIHRoYXQgTUlQdjYgZG9lc24ndCBleHBhbmQgZnVydGhlci4NCgkNCgkgICAgICAgICAg
ICAgICAgR3JlZyBEYWxleQ0KCSAgICAgICAgICAgICAgICAgICAgICAgDQoJPT4gICBHcmVnLCB0
aGFuayB5b3UgZm9yIHBvaW50aW5nIGl0IG91dC4gSSB1bmRlcnN0YW5kIHRoYXQgYnkNCm1hbmlw
dWxhdGluZyB0aGUgTENvQSBhbmQgUkNvQSBhIHR1bm5lbCBiZXR3ZWVuIE1BUCBhbmQgTU4gY2Fu
IGJlIHNldCB1cA0Kc28gdGhhdCB0aGUgTU4ncyBtb2JpbGl0eSBpcyBoaWRkZW4gYmV0d2VlbiBN
TiBhbmQgTUFQLCB3aGljaCBpcyB0aGUNCiJyZXZlcnNlLXR1bm5lbC9hbnRpLW9wdGltaXphdGlv
biIgbW9kZSBiZWluZyB0b3NzZWQgYXJvdW5kLiBJIHNhdyBhIGZldw0KZmxhZ3MgaW4gSE1JUHY2
IHNvIGlzIGl0IHNhZmUgdG8gYXNzdW1lIHRoYXQgdGhlICJyZXYtdHVubmVsIiBjYW4gYmUNCm5l
Z290aWF0ZWQgYmV0d2VlbiB0aGUgTU4gYW5kIE1BUD8gIERvIHlvdSBzZWUgdGhlIHNhbWUgdGhp
bmcgaW4gdGhlDQpNSVB2NiB0b28/ICBTb3JyeSBJIG1pc3NlZCB0aGUgbGF0ZXN0IGRyYWZ0LCBp
ZiB0aGUgY2FwYWJpbGl0eSB0bw0KbmVnb3RpYXRlIHRoZSAicmV2LXR1bm5lbCIgbW9kZSBpcyBp
biBwbGFjZSwgdGhhdCB3b3VsZCBiZSBuaWNlLg0KDQoJUWlhbmcNCg0KCSANCg0KCSANCg0KCQ0K
CSANCg0K

------_=_NextPart_001_01C14BB2.858A1CCC
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IhsCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD
AA4AAADRBwoAAgAWABgAGQACAC0BASCAAwAOAAAA0QcKAAIAFgAYABoAAgAuAQEJgAEAIQAAADg3
NDVCRTZERDlEMzBGNDRBMjRDM0UyM0ZCM0ZBMUI1AFwHAQOQBgCwFgAAOQAAAB8AGgABAAAAEgAA
AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAFgAAABSAEUAOgAgAFsAbQBvAGIA
aQBsAGUALQBpAHAAXQAgAFMAZQBjAHUAcgBpAHQAeQAgAFIAZQBxAHUAaQByAGUAbQBlAG4AdABz
ACAARAByAGEAZgB0AAAAQAA5AMwcioWyS8EBHwA9AAEAAAAKAAAAUgBFADoAIAAAAAAAAgFHAAEA
AAAxAAAAYz11czthPSA7cD1FY3V0ZWw7bD1FWENIQU5HRTAxLTAxMTAwMzAyMjQyNVotODI4AAAA
AB8ASQABAAAAWAAAAFIAZQA6ACAAWwBtAG8AYgBpAGwAZQAtAGkAcABdACAAUwBlAGMAdQByAGkA
dAB5ACAAUgBlAHEAdQBpAHIAZQBtAGUAbgB0AHMAIABEAHIAYQBmAHQAAABAAE4AAGX9SwJLwQEf
AFoAAQAAABwAAABHAHIAZQBnAG8AcgB5ACAARABhAGwAZQB5AAAAAgFbAAEAAABIAAAAAAAAAIEr
H6S+oxAZnW4A3QEPVAIAAAAAR3JlZ29yeSBEYWxleQBTTVRQAEdyZWcuRGFsZXlAZW5nLm1vbmFz
aC5lZHUuYXUAAgFcAAEAAAAiAAAAU01UUDpHUkVHLkRBTEVZQEVORy5NT05BU0guRURVLkFVAAAA
HwBdAAEAAAAcAAAARwByAGUAZwBvAHIAeQAgAEQAYQBsAGUAeQAAAAIBXgABAAAASAAAAAAAAACB
Kx+kvqMQGZ1uAN0BD1QCAAAAAEdyZWdvcnkgRGFsZXkAU01UUABHcmVnLkRhbGV5QGVuZy5tb25h
c2guZWR1LmF1AAIBXwABAAAAIgAAAFNNVFA6R1JFRy5EQUxFWUBFTkcuTU9OQVNILkVEVS5BVQAA
AB8AZgABAAAACgAAAFMATQBUAFAAAAAAAB8AZwABAAAAOgAAAEcAcgBlAGcALgBEAGEAbABlAHkA
QABlAG4AZwAuAG0AbwBuAGEAcwBoAC4AZQBkAHUALgBhAHUAAAAAAB8AaAABAAAACgAAAFMATQBU
AFAAAAAAAB8AaQABAAAAOgAAAEcAcgBlAGcALgBEAGEAbABlAHkAQABlAG4AZwAuAG0AbwBuAGEA
cwBoAC4AZQBkAHUALgBhAHUAAAAAAB8AcAABAAAAUAAAAFsAbQBvAGIAaQBsAGUALQBpAHAAXQAg
AFMAZQBjAHUAcgBpAHQAeQAgAFIAZQBxAHUAaQByAGUAbQBlAG4AdABzACAARAByAGEAZgB0AAAA
AgFxAAEAAAAbAAAAAcFLArSx1Y078BL1SzK+yyLr+jb1ZgAqnFDQAB8AcwABAAAAOgAAAGcAcgBl
AGcALgBkAGEAbABlAHkAQABlAG4AZwAuAG0AbwBuAGEAcwBoAC4AZQBkAHUALgBhAHUAAAAAAB8A
dAABAAAAPAAAAG0AbwBiAGkAbABlAC0AaQBwAEAAcwB1AG4AcgBvAG8AZgAuAGUAbgBnAC4AcwB1
AG4ALgBjAG8AbQAAAB8AGgwBAAAAGAAAAFEAaQBhAG4AZwAgAFoAaABhAG4AZwAAAB8AHQ4BAAAA
UAAAAFsAbQBvAGIAaQBsAGUALQBpAHAAXQAgAFMAZQBjAHUAcgBpAHQAeQAgAFIAZQBxAHUAaQBy
AGUAbQBlAG4AdABzACAARAByAGEAZgB0AAAAAgEJEAEAAAAjDQAAHw0AALc2AABMWkZ156W9ZQMA
CgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jBCsBzZXQwIAcTAoD/EAMAUARWCFUH
shHVDlEDAd0Q1zIGAAbDEdUzBEYQ2W8S6xHjCO8J9zsYzw4wNTsR0gxgYwBQCwkBZDM2kxFgC6U0
IBACKlwOsr0BkGcU8AqjEeMd6DQU8AA8IURPQ1RZUABFIEhUTUwgUABVQkxJQyAiLSAvL1czQyGA
RFQiRCCUMy4yIYBFTpwiPh7tHo8jwTE4H/BvIKIjDyQfJpAzHYAlcEV8QUQlzQ7xJu8pbyT0NkEO
8DxNRVRBB7BBMSxgPSJHCfAEkGF0RQWwIhLQT05UItBUEyzwBeFFeBDxbmdlPQZSdhMxL0EAkAIg
IDawLjAuNAHBIpA1Iv4TKs8lAzc3H/BUSVQUTEUlzjQO8FJlOpQgWwRgYgMQZS0FIEpdBlFjCHF0
eTTBcbx1aRjQB4ACMAQgRC1Q6wGAJG41H/AvM18xjyZFXzShOKAoTyafPHQ1EWA8QEJPRFkgZDag
PX08kHI74DxTACEDMD7xZM5vAOA+8QqxXHEYsD7xfxDwAzA/VRFgPAsc8T0PZ8Q5Nh/wRElWPykA
ALNBZzwpNjREn0G/OB2AYCZuYnNwAoA/SCf+YQFARV88oQHAPzcKoj83+wpxJHwwKBEh4ERrTIhB
7w9C/0QDIRAgMEtRVU9zLfA+piBzNjA1YC4xQQBSR0lOLVJJR+MgoDTwMHB4IvE/SAqx/xACQFVA
80CxQU9Qbx8bEWB/WkBRT0RPSl9Gb1dnP9BpaxzSJHw0JVFGLdFTgGm6elPQMlvLC+JXSS1jQnpP
BRBnC4AHQAXQB5BzvzywNXBjQl+tLBA+QVI/K30LgGUKgVdvSIY+UFvLYrVXSUYDYTpajB/hL2kK
aU9ZIEcY0GcFsDZARP0HQGU2QDqMWN9IpFpeZc//Zt9n72j/c1gGYAIwau9r/9VtB1QKUCBOEC8i
oAHQ4jAO8DE6MhTwLMBk759x/3MPdB91L32FVG927z93/20Hbn9vj3CUNSdAc0R1bgNgb2YuCfBn
6i6GkS4FoG1673v/fQ/nfh9/L4plQ2OAz4HfbQfrCcGHMGRuIkCHEgRgY+AEc2iHAGR1LmF1/4Nv
hH9wj4h/iY+Kn4uvddz4dWJqBZB2346vbPg03/817zbyki+TP5RENzOUr5W/X5bPot+j76T/JNY1
W2Ev/2DSnA9Kn0uvTL9Nz6pPV9/voM9Z/12FH/BQVS9eqV4fn18vYD9hT2JdSA9ndElZ/j66n0h/
SY+9f76Pv5/Ar//Bv8LPw9/E78X/xw/IH8kvH8o/y0/MX81vbPhEbyAieQhgIHRoC4BrIK+ewJ/P
sZ+FhmE2QGIu8PJ1ETBmdQMgLXA+oAEQ8aexIGEgBGLSsAOg0mDBLvBNSVB2NqWvpr/vp8+7b7x/
bUNikXABEAWx/deTTtZCEPCG0BEw0u/T/yeUNdXgC4BnIBjQdi0edIagLTADIAIgbHk/93mAEQAF
QHfVgdLB1XTYL3/ZP9pP21/cb910LSHWoGP7BzHWQnMDcNXCZGHfT+BfQ4WHAQBscywg3gJl6Hhh
bQtQZe5w1lEA0LfScC9A3nEnBCAYYGMtYH8vweRv5X/mj+ef6K9tQ3BNBRB2ANA2QChu0gBCflVT
gDbh1kLrn+yvlERD/k7ucC0wnsDXoAXAA1IgkCcskPcABcFOKdbgbmRf1uDuUN7BAiEDYGyeAGR/
8N/x7/L/9A/1H21D75Bj/2Qx9mAG8A3gNkDwcNdw1bH39+/4/5REae8A3xH8QN4Jf/sj3vDrAQRP
BV+URC0wdPJ37qBrLv1f/m//fwCP/wGfDl/P384PET8STxNfFG//FX8WjxefGK8ZvxrPG98c7/8d
/x8PIB8hLyI/I08kXwu//wzPDd8O7w//Kw8mPydPLe//Lv8wDzEfMi8zPzRPNV82b/83fziPOZ86
rzu/PM8934Nf3wmPlCZjkOOA0jBs/EDSYf/wMNWx7yCigNZCBsHvIJ9yf/CD8DDWWNLAn79C35Qm
b/h3bj8oLyk/Kk9Kz0vf/0zvP19Ab1A/UU9SX1NvVH//VY9Wn1evWL9Zz1rfW+9c/89eD18fYC9s
6UhpR89I3+2UNVHqcIcgLE2fTq9Pv/9oD2kfai9iP2NPbX9uj2+f/3Cvcb9yz3PfdO91/3cPeB+/
eS96P3tPfF99b2QZU+ry7+sA76D8IEUQbUbTZP9mD+OURPZwb3Zp1zFE89YQ/m6aoPCh1uCQYIMv
hD8GVv/8MOpQ42D9P2vPbN9/L4A//35vjc+O34/vkP+SD5MflC//lT+WT5dfmG+Zf5qPm5+cr5vQ
/tdlSNfT1nByYUWQ7+5wh1+Ib/oEd9Jw76D2Yf+F0/Aw1vDwVqLfo++FR/aT/4pvi3+Mj57fn++s
b61/ro//r5+wr7G/ss+z37Tvtf+3D/+4H7kvuj+7T7xfgS2CYIbDPDYuquCnD6gf+gQoK/nBoDUp
qf+rD6wfxP/GD//HH76fv6/Kb8t/zI/Nn86v/8+/0M/R39Lv0//VD9Yf1y//2D/ZT9pfZBnjQEUR
5AL3AP/j4AQRocLB78L/+gTrQOsBk4MAA3AgSUTibmtHgf1HgHPHz8jfye/cP91P5p//56/ov+nP
6t/r7+z/7g/vH//wL/E/8k/zX/Rv9X/2j6C+f4owieAHEeA/4U9EBIMBc10DcHbf1OKzhbFiRiEu
PCAoB0L77/z/RARleP/iwEYRZ8/lL+Y/+I/5nwXP/wbfB+8I/woPCx8MLw0/Dk//D18QbxF/Eo8T
nxSvFb/6bmMs4KZQTUFQ4/GHAGzP/pDf7wEvQ7lIQcS/BG//BX8evx/PIN8X/xkPJC8lP/8mTydf
KG8pfyqPK58sry2/fy7PL98w7zH/Mw80H2QKUHRlcoKAcEew49NFMXT/ijBEcIMPHM9D14KA/sWG
h/2m0GzfYN9AieCKLyJvI3//Nc823zUPQf9DD0QfRS9GP/9HT0hfSW9Kf0uPTJ9Nr06/f0/PUN9R
7zo/O09nBabQY1//ERuCPnAa0KIkb6Ygbv4n36AC4FbgieBV31bvZwXnhoBUsBuwci4+vz/PQN//
Xb9ez1/fU19Ub2MvZD9lT/9mX2dvaH9pj2qfa69sv23P/27fb+9w/3IPcx9VP1rvW///dM9133QP
eo97n3yvfb9+z/9/34Dvgf+DD4QfhS+GP4dPh4hfiW92r0dyZWd3r+t4vwJ1RBtQZanvYY9in/+L
n4yvk++U/5YPlx+YL5k//5pPm1+cb51/no+fn6Cvob//os+j33bPjt+P73n/pp+kz/+rT6xfrW+u
f6+PsJ+xr7K//7PPtN+177b/uA+5H7ovuz//qH+pj6qfvO+9/7wvwq/Dv//Ez8Xfxu/H/8kPyh/L
L8w//81Pzl/Pb9B/0Y/Sn5IPkx+l1aQ90y9ndNR5PtVvv9Of1K/bX9xv3X/V/TXW8eAvRk9OVNdJ
3+fV7jw0ONcA4qLARAKgc2kwemU9MtdJ1iBmcy4y1eDjqI5iLFjSbmswIHlvdT1AADFwb1/7UZOQ
jpA5QekQdP/wSeYgPWD7oHJz1qBaUVjjwmI+E2lwdWw+cOnSD79vwH/+BRuxTENvQXsbQFpRUu+D
/uA9YJOgbPk5kndl+4Dej9+f3coa4uFaQk1OIGM+QDmR/yD7ObDqoHBYpxuv7Y8CSPSwqicbMG3/
oGmTgHQ+EI85cPFf8m/dymhpZOrQv/UC8QP0ovRzGvDogHf84LxjaBsS9k/3X1xoIo5w0zzg6vBl
LfB0L/TwPZDoLW9wPZBt5jDsUT2wviL5QerQOZHp0joQc/VQH1pgAHDpEOrA6nJzYXepGrFmZQXw
ZuxAZxswz/9vAH9cpJOQIEhZNBtxXzlxOUEF0AYwOgJhBOB1/m088vYVAeICZQPw9OWToPxnbz2Q
PnIGzwffXJX9Vrs9Ev3YP/oP+x83+0Q6IP/pAvVQPPQF0AtD6dMQ1VlD5w3/Dw/u1W9vEd8S7zfs
+lPpUHI+EOqQA3AE4z0Sp+xBWbBZ8GRyCpB06ID+adfQPRL04BhA+XU6EQ1Hf/8fGA8BPQxHBBMK
Ij3AcK/sQFiA6INZ8HfpEGwN0PsNEv6wZV194l/jbBt2IiKf45iTyCITk88hhjcyJ9EeUNdA1gvn
gSI/ZzI06ziRIm02XLA8LdHmqSkYeZOAMzbkL+U25i/nP1H/DZDp4CbfJ+8o/yoPKx8sL/8tPy5P
L18wbzF/Mo8aHxsv/93ZOj87TzxfPW8+fz+PQJ//Qa9Cv0PPRN9F70b/SA9JH/9KL0s/TE9NX05v
T39QjzRP/zVf55nWD9cfk69RD1IfUy//OX9UD1UfY49XP1ma5TE4hQVhLDBbgS9CTE9DwEtRVU9U
RTjfaw8XWN9x7yF3NW2SQk9ELllsjnOfWgI3OGFIVBRNTGJgfXhgAB8ANRABAAAAjAAAADwAQQBG
ADIAMwA3ADgAQwBCAEUANwAwADEANgAyADQANwBCAEMAMABGAEQANQAyADYAMQBGADEARQBFAEIA
MgAxADAANgA4AEIANgAyAEAARQBYAEMASABBAE4ARwBFADAAMQAuAGQAbwBtAGEAaQBuAC4AZQBj
AHUAdABlAGwALgBjAG8AbQA+AAAAHwBHEAEAAAAeAAAAbQBlAHMAcwBhAGcAZQAvAHIAZgBjADgA
MgAyAAAAAAALAPIQAQAAAB8A8xABAAAAZAAAAFIARQAlADMAQQAgAFsAbQBvAGIAaQBsAGUALQBp
AHAAXQAgAFMAZQBjAHUAcgBpAHQAeQAgAFIAZQBxAHUAaQByAGUAbQBlAG4AdABzACAARAByAGEA
ZgB0AC4ARQBNAEwAAAALAPYQAAAAAEAABzCcVfAlrUvBAUAACDBCzZqFskvBAQMA3j/p/QAAAwDx
PwkEAAAfAPg/AQAAABgAAABRAGkAYQBuAGcAIABaAGgAYQBuAGcAAAACAfk/AQAAAFwAAAAAAAAA
3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RUNVVEVML09VPUZJUlNUIEFETUlOSVNUUkFUSVZF
IEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049UVpIQU5HAB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAA
QQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgAAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkI
ACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAA
HwAwQAEAAAAOAAAAUQBaAEgAQQBOAEcAAAAAAB8AMUABAAAADgAAAFEAWgBIAEEATgBHAAAAAAAf
ADJAAQAAADoAAABHAHIAZQBnAC4ARABhAGwAZQB5AEAAZQBuAGcALgBtAG8AbgBhAHMAaAAuAGUA
ZAB1AC4AYQB1AAAAAAAfADNAAQAAADoAAABHAHIAZQBnAC4ARABhAGwAZQB5AEAAZQBuAGcALgBt
AG8AbgBhAHMAaAAuAGUAZAB1AC4AYQB1AAAAAAAfADhAAQAAAA4AAABRAFoASABBAE4ARwAAAAAA
HwA5QAEAAAAEAAAALgAAAAsAKQAAAAAACwAjAAAAAAADAAYQzTz6SQMABxC/BAAAAwAQEAAAAAAD
ABEQAAAAAB4ACBABAAAAZQAAAC0tLS0tT1JJR0lOQUxNRVNTQUdFLS0tLS1GUk9NOkdSRUdPUllE
QUxFWVNFTlQ6VFVFMTAvMi8yMDAxMToyMkFNVE86TU9CSUxFLUlQQFNVTlJPT0ZFTkdTVU5DT01D
QzpHUkUAAAAAAgF/AAEAAABGAAAAPEFGMjM3OENCRTcwMTYyNDdCQzBGRDUyNjFGMUVFQjIxMDY4
QjYyQEVYQ0hBTkdFMDEuZG9tYWluLmVjdXRlbC5jb20+AAAAQrQ=

------_=_NextPart_001_01C14BB2.858A1CCC--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 02:28:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28258
	for <mobileip-archive@lists.ietf.org>; Wed, 3 Oct 2001 02:28:38 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02610;
	Wed, 3 Oct 2001 00:27:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02120;
	Tue, 2 Oct 2001 23:27:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f936QrML007846
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 2 Oct 2001 23:26:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f936QrmC007845
	for mobile-ip-dist; Tue, 2 Oct 2001 23:26:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f936QnML007838
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 23:26:49 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02065
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 23:26:51 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11408
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 2 Oct 2001 23:26:51 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA00641
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 16:25:07 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA20819
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 16:26:14 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXGWZ8>; Wed, 3 Oct 2001 16:26:12 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ECEF@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Security Requirements Draft
Date: Wed, 3 Oct 2001 16:26:11 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14BD4.4B6DC6C0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14BD4.4B6DC6C0
Content-Type: text/plain

		Qiang,
> 	                       
> 	=>   Greg, thank you for pointing it out. I understand that by
> manipulating the LCoA and RCoA a tunnel between MAP and MN can be set up
> so that the MN's mobility is hidden between MN and MAP, which is the
> "reverse-tunnel/anti-optimization" mode being tossed around. I saw a few
> flags in HMIPv6 so is it safe to assume that the "rev-tunnel" can be
> negotiated between the MN and MAP?  
> 
		=> There is currently no reverse tunnelling in the draft
between the 
		MN and the MAP. Location privacy is allowed by allowing the 
		user to use RCoA as a src address instead of LCoA. This is 
		only applicable to Basic mode MAPs.

> Do you see the same thing in the MIPv6 too?  
> 	 
		In MIPv6 draft 14, the HA MUST allow reverse tunnelling
		(ch 9.5). So all the MN needs to do is simply reverse 
		tunnel and the HA support is expected. No negotiations
		are required. 

		Hesham

> 	 
> 
> 
> 	 
> 

------_=_NextPart_001_01C14BD4.4B6DC6C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Security Requirements Draft</TITLE>
</HEAD>
<BODY>
<UL><UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Qiang,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;<BR>
=3D&gt;&nbsp;&nbsp; Greg, thank you for pointing it out. I understand =
that by manipulating the LCoA and RCoA a tunnel between MAP and MN can =
be set up so that the MN's mobility is hidden between MN and MAP, which =
is the &quot;reverse-tunnel/anti-optimization&quot; mode being tossed =
around. I saw a few flags in HMIPv6 so is it safe to assume that the =
&quot;rev-tunnel&quot; can be negotiated between the MN and MAP?&nbsp; =
</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; There is =
currently no reverse tunnelling in the draft between the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">MN and the MAP. =
Location privacy is allowed by allowing the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">user to use RCoA as =
a src address instead of LCoA. This is </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">only applicable to =
Basic mode MAPs.</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Do you see the same thing in the MIPv6 =
too?&nbsp;</FONT>=20
<UL>
<P><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In MIPv6 draft 14, =
the HA MUST allow reverse tunnelling</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(ch 9.5). So all =
the MN needs to do is simply reverse </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">tunnel and the HA =
support is expected. No negotiations</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">are required. =
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>

<P><FONT FACE=3D"Arial">&nbsp;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial"></FONT>&nbsp;
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C14BD4.4B6DC6C0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 03:41:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02016
	for <mobileip-archive@lists.ietf.org>; Wed, 3 Oct 2001 03:41:35 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03347;
	Wed, 3 Oct 2001 01:40:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08318;
	Wed, 3 Oct 2001 00:40:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f937biML007988
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 00:37:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f937biue007987
	for mobile-ip-dist; Wed, 3 Oct 2001 00:37:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f937bfML007980
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 00:37:41 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01037
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 00:37:43 -0700 (PDT)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28265
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 00:37:42 -0700 (PDT)
Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA10711;
	Wed, 3 Oct 2001 09:38:06 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <mat@cisco.com>
Subject: RE: [mobile-ip] AAA keys design comment
Date: Wed, 3 Oct 2001 09:38:37 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEGHDHAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <15289.58848.663490.52928@thomasm-u1.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>
>Pat Calhoun writes:
> > On Mon, Oct 01, 2001 at 10:01:14AM -0700, Michael Thomas wrote:
> > so talking about sub-optimal and unnecessarily complex you 
>state that the
> > MN should issue a request to the KDC infrastructure to retrieve 
>a key, and
> > then present the key to the HA, right?
> > 
> > This now requires that the signalling (over the air and the 
>'net) include two
> > full round trips, as opposed to a single one (which is what we 
>have  today).
>
>   It appears that I've been thinking of this too
>   much like the v6 model which _does_ require the
>   round trip to the HA at all times since there's
>   no FA. This means that it would have a round
>   to MN/HA instead of the round trip from HA/AAAh
>   in the v4 case; in other words, a wash on the
>   message count front. While you claim that this
>   is an expensive round trip vs. a cheap round
>   trip, I'm not as certain. First, not all radio
>   access media are slow and I would expect that
>   in the future they will get much better as they
>   become more and more optimized for the net instead
>   of the telco. Second, it's not at all clear to
>   me that AAA round trip will necessarily be faster
>   since there is no reason to believe that AAAh
>   and HA will be topologically close to each other.
>   This is especially true in the "Visa" model. 
>   Indeed, I'm fairly certain that a lot of the 
>   latency in current dial (post training, of
>   course) is the AAA latency. This effectively
>   doubles the message load on the AAA.

it's not only the roundtrip over the air that can be
more expensive, it's also between the home and foreign
network (when the HA is allocated in the home network).

>
>   Most of the same criticism still applies though;
>   the AAAh are not fate shared with the HA, so
>   adding this is less robust, and there is no
>   way to do cross-realm AAAh/HA. In fact, you
>   are placing a new limitation on who can operate
>   the HA's in this model because they must have
>   a relationship with AAAh. This model seems to
>   preclude the case where I own and operate my 
>   own HA, for example, but use a third party 
>   settlement scheme for when I'm roaming. This
>   doesn't require any business linkage to the
>   HA's provider which IMO is a very good thing.
>

No, there is nothing that mandates a direct relationship
between AAAh and HA, it's enough that the AAAh has a 
relationship (either direct or via a broker) to the AAAf. 
The AAAf can then assign the HA and distribute keys in the
same way as is done for the keys needed for the FA (since 
the AAAh usually don't have a direct trust with the FAs)

/Fredrik


>   I'll note that we have yet to have this
>   discussion on IPv6. If a similar scheme is
>   used, we are explicitly abandoning the "no
>   FA" stance for MIPv6 which I think would be
>   a step backward.
>
> > right, so now the AAAH must assume that the HA can handle the 
>MN. In our 
> > solution the HA can return a negative response to the AAAH, 
>perhaps because
> > it is too busy, which would cause the AAAH to select another HA.
>
>   If you believe in anycast discovery of HA's,
>   wouldn't you be able to achieve the same effect
>   more efficiently by having the overloaded HA
>   update its route metrics based on load so that
>   the MN naturally selects the right HA based on
>   routing?
>
> > The above two comments seem to be in conflict. Although
> > Kerberos has been around for a long time, many of the protocols
> > you mention in 6 are fairly new.
>
>   The ticket mechanism is really what's important
>   here; whether Kerberos itself is the right fit
>   is another discussion. I honestly haven't
>   sorted through the tradeoffs to form an
>   opinion.
>
>		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 06:02:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05377
	for <mobileip-archive@lists.ietf.org>; Wed, 3 Oct 2001 06:02:33 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15160;
	Wed, 3 Oct 2001 04:01:58 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15277;
	Wed, 3 Oct 2001 03:01:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93A0tML008203
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 03:00:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93A0tKY008202
	for mobile-ip-dist; Wed, 3 Oct 2001 03:00:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93A0pML008195
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 03:00:51 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14241
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 03:00:51 -0700 (PDT)
Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15682
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 03:00:51 -0700 (PDT)
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id <TWGJJG4Q>; Wed, 3 Oct 2001 06:00:49 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE460548EC@ftmail>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>,
        "Charles E. Perkins"
	 <charliep@IPRG.nokia.com>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] Re-registration after unicast Challenge and re-keying (was:RE: [m
	obile-ip] Concerns/comments for aaa-keys and gen-key)
Date: Wed, 3 Oct 2001 06:00:41 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

New subject since this is slightly different thread...

Pat, please see below

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Tuesday, October 02, 2001 3:38 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: Michael Thomas; Charles E. Perkins; Erik Nordmark
Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key


On Mon, Oct 01, 2001 at 11:56:41AM -0400, George Tsirtsis wrote:
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Sunday, September 30, 2001 3:39 PM
> To: Michael Thomas
> Cc: mobile-ip@sunroof.eng.sun.com; Charles E. Perkins; Erik Nordmark;
> Pat Calhoun
> Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key
> 
> ...
> 
> > Is there a way
> >    to get the AAA to supply fresh key material on demand?
> >    If so, is the performance penalty going to be acceptible?
> >    If not, is the expectation that one or both of the
> >    ends of the SA supply entropy? If it's only one side,
> >    what happens if their random number generator is not
> >    very good, like oh say open("/dev/null")?
> 
> Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
> to be sent to the mobile. So, using today's protocol, the answer is no.
> 
> 
> GT> I have a different concern with a possible solution that may solve
this
> problem. 
> We are implementing challenge/response with MN-AAA extensions and Radius
as
> AAA. As a Mobile Node (MN) comes in contact with a new FA, it receives an
> Foreign Agent Advertisement (FAA) with a Challenge to which it responds
with
> a MIP Registration Request (RREQ) that includes MN-AAA authenticator. The
FA
> gets key material from AAA server and returns it to the Mobile Node (MN)
> with the registration reply (RREP) so that an MN-FA key can be
constructed.
> The link layer happens to provide link up/link down triggers so that if
the
> MN looses contact with the FA we know it immediately. If the MN regains
> contact in a short time, the FA senses it also immediately. 
> 
> ->The problem with a standards based MIP client would be that on
> reconnection and although the MN receives an FAA with a challenge, the
> advertised FA is recoginsed as one that the MN has already registered with
> and does not bother to register again thus, one can not check its MN-FA
key
> and verify the user is still the same.
> 
> No matter what the particular scenario is, however, I think this does not
> make sense for any challenge/response protocol. The behaviour should be
that
> if you get a challenge you MUST respond to it. So, the proposed solution
is:
> 
> "If a Mobile Node receives a *unicast* FAA WITH a Challenge then it MUST
> send a Registration Request with an appropriate Response or face loss of
> connectivity". Note that this does not mandate that all FAAs must now be
> unicasted...but it does allow a network administrator to target a specific
> mobile, challenge it individually and get its credetials.
> On top of that, the above proposal would also make re-keying possible
since
> the FA can insert new Key material in the Registration Reply.

To address both your issues:

1. RFC 3012 is pretty clear that the MN MUST include the challenge response
if the
   challenge was present in an advertisement. No way around this one, so I
don't
   think there is an issue (unless I misinterpreted your comment).

GT> Pat, unfortunately this is not exactly the case...I quote RFC3012:
"  Whenever the Agent Advertisement contains the Challenge extension, if
   the mobile node does not have a security association with the Foreign
   Agent, then it MUST include the Challenge value in a MN-FA Challenge
   extension to the Registration Request message.  If, on the other
   hand, the mobile node does have a security association with the
   foreign agent, it SHOULD include the Challenge value in its
   Registration Request message...."

The above says that a challenge response MUST be included in the
registration request if one is sent (and only if MN-FA keys does not
exist...otherwise it is a SHOULD). The spec does not say anywere that the
mobile node MUST register if it receives an foreign agent advertisement with
a challenge, which actually makes sense if the FAAs are broadcasted
periodically...In fact I am afraid that if the MN has registered in the past
and already has a MN-FA key...it will not register again unless either its
registration lifetime expires or it changes FA. So, still the FA can not
challenge the MN as it wishes even if it sends a unicast FAA+Challenge to
it. Do you see the problem?

2. If the FA inserts new key material in the registration reply, it must
also
   add the necessary authentication extension, which must match the key
generated
   by the MN via the included key material. Furthermore, the HA must also
add the
   necessary MN-HA key material (which it receives from the AAAH) as well as
the
   MN-HA authentication extension.


GT> Yes, and that is why I am arguing that the process must be possible to
be initiated by the FA (i.e.: the network operator). FA sends new challenge
(maybe with a flag indicating that MN-AAA authenticator should be used
instead of the MN-FA one)...If we can make the MN re-register at this stage
re-keying will happen naturally and according to existing mechanisms.

If what I am suggesting is not clear let me know and I will put a couple of
message flows down.

Regards
George


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 07:14:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07444
	for <mobileip-archive@lists.ietf.org>; Wed, 3 Oct 2001 07:14:42 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17931;
	Wed, 3 Oct 2001 05:13:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27459;
	Wed, 3 Oct 2001 04:13:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93BCXML008377
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 04:12:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93BCWRO008376
	for mobile-ip-dist; Wed, 3 Oct 2001 04:12:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93BCSML008369
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 04:12:28 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27390
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 04:12:29 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA20497
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 05:13:31 -0600 (MDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07153;
	Wed, 3 Oct 2001 07:12:24 -0400 (EDT)
Message-Id: <200110031112.HAA07153@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: mobile-ip@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
Date: Wed, 03 Oct 2001 07:12:24 -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Threat Models introduced by Mobile IPv6 and 
                          Requirements for Security in Mobile IPv6
	Author(s)	: A. Mankin et al.
	Filename	: draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
	Pages		: 29
	Date		: 02-Oct-01
	
The IESG returned the Mobile IPv6 (MIPv6) draft to the working group
due to concerns about the security and scalability of binding updates
(BUs) sent to correspondent nodes and the associated IPsec processing
that is specified in the draft. Since that time discussions have
continued to attempt to define what is really needed to make binding
updates secure while taking into consideration the aspect of
scalability as well as the fact that IPsec may not be the most
suitable security mechanism for securing BUs between MNs and CNs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mobileip-mipv6-scrty-reqts-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-mobileip-mipv6-scrty-reqts-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:	<20011002120722.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-mipv6-scrty-reqts-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 07:14:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07456
	for <mobileip-archive@lists.ietf.org>; Wed, 3 Oct 2001 07:14:46 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17987;
	Wed, 3 Oct 2001 05:13:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27486;
	Wed, 3 Oct 2001 04:13:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93BCmML008387
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 04:12:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93BCmYM008386
	for mobile-ip-dist; Wed, 3 Oct 2001 04:12:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93BCgML008379
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 04:12:43 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19952
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 04:12:44 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10341
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 04:12:43 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07201;
	Wed, 3 Oct 2001 07:12:39 -0400 (EDT)
Message-Id: <200110031112.HAA07201@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: mobile-ip@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Subject: [mobile-ip] I-D ACTION:draft-ishi-mobileip-behavior-ma-00.txt
Date: Wed, 03 Oct 2001 07:12:39 -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Behavior of A Mobility Agent in Mobile IP in order to 
                          manage the flow
	Author(s)	: K. Ishibashi, K. Shimizu, S. Seno
	Filename	: draft-ishi-mobileip-behavior-ma-00.txt
	Pages		: 9
	Date		: 02-Oct-01
	
Mobile IP [1] protocol allows a mobile node (MN) to move between 
different networks seamlessly. However, in certain cases, 
the latency involved in the handoff can be beyond the threshold 
required for the support of delay-sensitive or real-time services.
In order to address the above problem, there have been many 
proposals related to extensions of Mobile IP handoffs in order to 
achieve efficient handoff procedures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ishi-mobileip-behavior-ma-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ishi-mobileip-behavior-ma-00.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-ishi-mobileip-behavior-ma-00.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:	<20011002120802.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ishi-mobileip-behavior-ma-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ishi-mobileip-behavior-ma-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 08:22:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10170
	for <mobileip-archive@lists.ietf.org>; Wed, 3 Oct 2001 08:22:52 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19553;
	Wed, 3 Oct 2001 06:22:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24813;
	Wed, 3 Oct 2001 05:22:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93CLQML008589
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 05:21:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93CLQjk008588
	for mobile-ip-dist; Wed, 3 Oct 2001 05:21:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93CLMML008581
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 05:21:22 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24761
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 05:21:24 -0700 (PDT)
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18828
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 06:21:12 -0600 (MDT)
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id VAA00010
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:21:22 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from nttmail3.ecl.ntt.co.jp
	by vcs3.rdh.ecl.ntt.co.jp (8.9.3/3.7W/20010920) with ESMTP id VAA20826
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:21:22 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from eclscan3.m.ecl.ntt.co.jp
	by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id VAA01403
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:21:21 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id VAA02589
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:21:21 +0900 (JST)
Received: from ohnishi-dyna
	by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id VAA19835
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:21:19 +0900 (JST)
Date: Wed, 03 Oct 2001 21:26:52 +0900
From: Hiroyuki OHNISHI <ohnishi.hiroyuki@lab.ntt.co.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Route optimization method in Mobile IP
Message-Id: <20011003210342.2A14.OHNISHI.HIROYUKI@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi all,

We wrote a draft about a route optimization method in Mobile IP.

http://search.ietf.org/internet-drafts/draft-ohnishi-mobileip-mbg-00.txt

This method is proposed from the viewpoint of a career that will provide
mobile ip services.
To provide mobile ip services, we think route optimization is needed to use network efficiently and reduce data transmission delay.

But existing "Route optimization in Mobile IP" needs all the CNs have to have Mobile IP functions and we have no control over all of the CNs in the Internet. I know this problem can be solved if all CNs become IPv6 nodes
(if current problem will be solved).
But we think it takes long time before all the CNs become the IPv6 nodes.
So we need the some solution to achieve route optimization before all the CNs have not been IPv6 nodes yet.
And we also need route optimization method that does not tell CoA to CNs directly for maintaining the location privacy.

In our proposal, we introduce the new Mobile IP agents that are located between a mobile ISP and other networks. This agent is called as MBG (Mobile IP Border Gateway).
MBG sends the Binding Requests to HA when it received the packets for MNs. After receiving the Binding Updates from HA, it maintains a binding cache and forwarded following packets directly to CoA of MNs by using the binding caches.
These MBGs are fully under the control of mobile ISPs and have security asociations with HAs.
So this solution does not suffer from SA issues. We have already had a prototype and had tests.
Our hope is to have some solution for route optimization that can be deployed at early time and co-exist with the end-to-end route optimization method for the future Mobile IPv6 deployment time.

I am looking forward to having many comments about this approach for
route optimization.

Sincerely,
Hiroyuki 




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 10:11:41 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15613
	for <mobileip-archive@lists.ietf.org>; Wed, 3 Oct 2001 10:11:40 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29520;
	Wed, 3 Oct 2001 07:10:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09912;
	Wed, 3 Oct 2001 07:10:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93E9aML008842
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 07:09:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93E9ag7008841
	for mobile-ip-dist; Wed, 3 Oct 2001 07:09:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93E9WML008834
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 07:09:33 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11530
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 07:09:33 -0700 (PDT)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07117
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 07:09:32 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14C15.0606D0FE"
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
Subject: RE: [mobile-ip] Security Requirements Draft
Date: Wed, 3 Oct 2001 10:09:32 -0400
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB21068B63@EXCHANGE01.domain.ecutel.com>
Thread-Topic: [mobile-ip] Security Requirements Draft
Thread-Index: AcFL1OMznRnk8PbXSVWCr5Rfny0FZQAR2hdA
From: "Qiang Zhang" <qzhang@ecutel.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C14C15.0606D0FE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
       =20
          Hesham,
=20
            Thanks for clarifying, I remember the earlier draft can
allow HA to send BU to a CN. If that is removed, then a bi-directional
tunnel can be set up upon MN's decision.  Sorry for that confusion
           =20
            Qiang

 -----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Wednesday, October 03, 2001 1:26 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Security Requirements Draft



	Qiang,=20
                     =20
=3D>   Greg, thank you for pointing it out. I understand that by
manipulating the LCoA and RCoA a tunnel between MAP and MN can be set up
so that the MN's mobility is hidden between MN and MAP, which is the
"reverse-tunnel/anti-optimization" mode being tossed around. I saw a few
flags in HMIPv6 so is it safe to assume that the "rev-tunnel" can be
negotiated between the MN and MAP? =20

	=3D> There is currently no reverse tunnelling in the draft between
the=20
MN and the MAP. Location privacy is allowed by allowing the=20
user to use RCoA as a src address instead of LCoA. This is=20
only applicable to Basic mode MAPs.=20


[Qiang Zhang]=20

 Do you see the same thing in the MIPv6 too? =20

	 =20
In MIPv6 draft 14, the HA MUST allow reverse tunnelling=20
(ch 9.5). So all the MN needs to do is simply reverse=20
tunnel and the HA support is expected. No negotiations=20
are required.=20

	Hesham=20

	 =20


	 =20


------_=_NextPart_001_01C14C15.0606D0FE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [mobile-ip] Security Requirements Draft</TITLE>

<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D404350115-03102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D404350115-03102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
Hesham,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D404350115-03102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D404350115-03102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
Thanks for clarifying, I remember the earlier draft can allow HA to send =
BU to a=20
CN. If that is removed, then a bi-directional tunnel can be set up upon =
MN's=20
decision.&nbsp; Sorry for that confusion</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D404350115-03102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D404350115-03102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
Qiang</SPAN></FONT></DIV>
<DIV><SPAN class=3D404350115-03102001></SPAN><FONT =
face=3DTahoma><BR></FONT><FONT=20
face=3DTahoma><FONT size=3D2><SPAN=20
class=3D404350115-03102001>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
Hesham Soliman (EPA) =
[mailto:Hesham.Soliman@ericsson.com.au]<BR><B>Sent:</B>=20
Wednesday, October 03, 2001 1:26 AM<BR><B>To:</B>=20
'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> RE: [mobile-ip] =
Security=20
Requirements Draft<BR><BR></DIV></FONT>
<BLOCKQUOTE></FONT>
  <UL>
    <UL>
      <P><FONT color=3D#0000ff face=3DArial size=3D2>Qiang,</FONT> =
<BR><FONT=20
      face=3DArial=20
      =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>=3D=
&gt;&nbsp;&nbsp;=20
      Greg, thank you for pointing it out. I understand that by =
manipulating the=20
      LCoA and RCoA a tunnel between MAP and MN can be set up so that =
the MN's=20
      mobility is hidden between MN and MAP, which is the=20
      "reverse-tunnel/anti-optimization" mode being tossed around. I saw =
a few=20
      flags in HMIPv6 so is it safe to assume that the "rev-tunnel" can =
be=20
      negotiated between the MN and MAP?&nbsp; </FONT></P>
      <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; There is =
currently no=20
      reverse tunnelling in the draft between the </FONT><BR><FONT =
color=3D#0000ff=20
      face=3DArial size=3D2>MN and the MAP. Location privacy is allowed =
by allowing=20
      the </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>user to =
use RCoA as a=20
      src address instead of LCoA. This is </FONT><BR><FONT =
color=3D#0000ff=20
      face=3DArial size=3D2>only applicable to Basic mode MAPs.</FONT> =
</P></UL></UL>
  <P><BR><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D404350115-03102001><FONT=20
  color=3D#0000ff>[Qiang Zhang]&nbsp;</FONT></SPAN></FONT></FONT></P>
  <P><FONT size=3D2><FONT face=3DArial><SPAN=20
  class=3D404350115-03102001>&nbsp;</SPAN>Do you see the same thing in =
the MIPv6=20
  too?&nbsp;</FONT></FONT> </P>
  <UL>
    <UL>
      <P><FONT face=3DArial>&nbsp;</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
      size=3D2>In MIPv6 draft 14, the HA MUST allow reverse =
tunnelling</FONT>=20
      <BR><FONT color=3D#0000ff face=3DArial size=3D2>(ch 9.5). So all =
the MN needs to=20
      do is simply reverse </FONT><BR><FONT color=3D#0000ff face=3DArial =

      size=3D2>tunnel and the HA support is expected. No =
negotiations</FONT>=20
      <BR><FONT color=3D#0000ff face=3DArial size=3D2>are required. =
</FONT></P>
      <P><FONT color=3D#0000ff face=3DArial size=3D2>Hesham</FONT> </P>
      <P><FONT face=3DArial>&nbsp;</FONT> </P><BR>
      <P><FONT face=3DArial size=3D2></FONT>&nbsp;=20
</P></UL></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C14C15.0606D0FE--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 12:39:52 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21146
	for <mobileip-archive@odin.ietf.org>; Wed, 3 Oct 2001 12:39:51 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12599;
	Wed, 3 Oct 2001 10:38:57 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11474;
	Wed, 3 Oct 2001 09:38:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93GbtML009150
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 09:37:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93GbtTt009149
	for mobile-ip-dist; Wed, 3 Oct 2001 09:37:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93GbpML009142
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 09:37:51 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15763
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 09:37:53 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA19686
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 10:38:55 -0600 (MDT)
Received: (qmail 32244 invoked by uid 500); 3 Oct 2001 16:23:30 -0000
Date: Wed, 3 Oct 2001 09:23:30 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Cc: Pat Calhoun <pcalhoun@diameter.org>, charliep@IPRG.nokia.com,
        diameter@diameter.org
Subject: Re: [mobile-ip] RE: [diameter] DIAMETER support for MIP question
Message-ID: <20011003092330.G32101@charizard.diameter.org>
Mail-Followup-To: mobile-ip@sunroof.eng.sun.com,
	Pat Calhoun <pcalhoun@diameter.org>, charliep@IPRG.nokia.com,
	diameter@diameter.org
References: <23BDB0046F3ED51185CD0002A5608D24513558@zrc2c009.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <23BDB0046F3ED51185CD0002A5608D24513558@zrc2c009.us.nortel.com>; from chowdury@nortelnetworks.com on Tue, Oct 02, 2001 at 06:23:49PM -0500
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, Oct 02, 2001 at 06:23:49PM -0500, Kuntal Chowdhury wrote:
> Pat,
> Thanks for responding. I am still not clear on the following two issues in
> "draft-ietf-aaa-diameter-mobileip-07":
> 
> 1. Section 1.4 Page 12
> 
> AAAF in foreign network 1 will send back error code
> "DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE" to AAAH if foreign network 1 does not
> wish to provide HA service when the MN has moved to foreign network 2.
> However it is not mentioned when the AAAH receives such an error code from
> AAAF what happens to the mobile IP registration request. 
> I think some text is required to capture this exception case. Options before
> AAAH is either send another HAR to AAAF in network 2 (only if AAAF had set
> the "Foreign-Home-Agent-Available" flag in AMR), otherwise AAAH may assign a
> HA in the home network or reject the mobile IP registration request. 

The text that follows is at the end of section 1.4 and I believe it does
cover this error:

"
   If the old Foreign Network does not permit the use of its Home Agent
   when the Mobile Node moves to a new foreign network, the AAAH or AAAF
   MUST return an AMA with the Result-Code AVP set to
   DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the
   Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile
   Node with an appropriate error. The Mobile Node MAY attempt to
   request that a new Home Agent and Address be allocated. When the AAAH
   transmits such an error, it MUST issue a Diameter Abort-Session-
   Request message to the AAAF overseeing the Home Agent to enable it to
   release any resources."

Is this not sufficient?

> 2. When MN requests for a HA allocation in the foreign network, and for some
> reason AAAF does not set "Foreign-Home-Agent-Available" or AAAH denies the
> request, how does the MN come to know that it did not get what it requested?

It would receive the Registration Reply with the proper error code. There are
a variety of error codes defined in RFC2002, but perhaps a more specific error
code could be introduced? If so, where should it be specified?

> If it is immaterial for the MN's MIP client to know where the HA gets
> allocated, why does it ask for it differently e.g. some MNs requesting with
> 0.0.0.0 and some others requesting with 255.255.255.255?

corporate customers would most likely want an HA in their corporate networks.
Normal Internet users don't care where the HA resides.

PatC



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 18:10:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01251
	for <mobileip-archive@odin.ietf.org>; Wed, 3 Oct 2001 18:10:31 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26444;
	Wed, 3 Oct 2001 15:09:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17028;
	Wed, 3 Oct 2001 15:09:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93M87ML009609
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 15:08:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93M873E009608
	for mobile-ip-dist; Wed, 3 Oct 2001 15:08:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93M83ML009601
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 15:08:03 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16784
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 15:08:04 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08140
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 15:08:04 -0700 (PDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA07518
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 17:08:03 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 3 Oct 2001 17:07:41 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L4L2A>; Wed, 3 Oct 2001 17:07:40 -0500
Message-ID: <23BDB0046F3ED51185CD0002A5608D24556183@zrc2c009.us.nortel.com>
From: "Kuntal Chowdhury" <chowdury@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Cc: charliep@IPRG.nokia.com, diameter@diameter.org
Subject: RE: [mobile-ip] RE: [diameter] DIAMETER support for MIP question
Date: Wed, 3 Oct 2001 17:07:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14C57.CE151B40"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14C57.CE151B40
Content-Type: text/plain;
	charset="iso-8859-1"

Pat,
Please see my responses inline:

Thanks,
Kuntal

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Wednesday, October 03, 2001 11:24 AM
To: mobile-ip@sunroof.eng.sun.com
Cc: Pat Calhoun; charliep@IPRG.nokia.com; diameter@diameter.org
Subject: Re: [mobile-ip] RE: [diameter] DIAMETER support for MIP
question


On Tue, Oct 02, 2001 at 06:23:49PM -0500, Kuntal Chowdhury wrote:
> Pat,
> Thanks for responding. I am still not clear on the following two issues in
> "draft-ietf-aaa-diameter-mobileip-07":
> 
> 1. Section 1.4 Page 12
> 
> AAAF in foreign network 1 will send back error code
> "DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE" to AAAH if foreign network 1 does
not
> wish to provide HA service when the MN has moved to foreign network 2.
> However it is not mentioned when the AAAH receives such an error code from
> AAAF what happens to the mobile IP registration request. 
> I think some text is required to capture this exception case. Options
before
> AAAH is either send another HAR to AAAF in network 2 (only if AAAF had set
> the "Foreign-Home-Agent-Available" flag in AMR), otherwise AAAH may assign
a
> HA in the home network or reject the mobile IP registration request. 

The text that follows is at the end of section 1.4 and I believe it does
cover this error:

"
   If the old Foreign Network does not permit the use of its Home Agent
   when the Mobile Node moves to a new foreign network, the AAAH or AAAF
   MUST return an AMA with the Result-Code AVP set to
   DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the
   Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile
   Node with an appropriate error. The Mobile Node MAY attempt to
   request that a new Home Agent and Address be allocated. When the AAAH
   transmits such an error, it MUST issue a Diameter Abort-Session-
   Request message to the AAAF overseeing the Home Agent to enable it to
   release any resources."

Is this not sufficient?

KC> This text captures one of the three options that I mentioned before. The
three options for AAAH are:

i.	AAAH sends an HAR message to AAAF2 if AAAF2 sets
Foreign-Home-Agent-Available = 1
ii.	AAAH assigns a HA in the home network if (i) = false
iii.  AAAH rejects the registration request if (i) and (ii) = false

The text in the draft covers, only option (iii). 

The advantages of adopting the suggested approach are:
a) MN won't have to initiate another MIP registration request.
b) No need for extra messaging over the air.


> 2. When MN requests for a HA allocation in the foreign network, and for
some
> reason AAAF does not set "Foreign-Home-Agent-Available" or AAAH denies the
> request, how does the MN come to know that it did not get what it
requested?

It would receive the Registration Reply with the proper error code. There
are
a variety of error codes defined in RFC2002, but perhaps a more specific
error
code could be introduced? If so, where should it be specified?

KC> May be we can add this error code in 2002bis.

> If it is immaterial for the MN's MIP client to know where the HA gets
> allocated, why does it ask for it differently e.g. some MNs requesting
with
> 0.0.0.0 and some others requesting with 255.255.255.255?

corporate customers would most likely want an HA in their corporate
networks.
Normal Internet users don't care where the HA resides.

KC> 
If the corporate customers need HAs in their corporate networks, AAAH should
be able to enforce that. Even if all the mobiles send the same indication
for dynamic HA allocation, AAAH should have the ability to decide whether
the HA to be assigned in the home network or in the serving network. e.g.

-----
MN sends 0.0.0.0 in the HA field in RRQ

If AAAF is willing to provide HA service (irrespective of the value in HA
field in RRQ), then it sets flag1 == 1 in AMR
If AAAH policy says "HA must be in the home network" (say for corporate
users) then AAAH assigns HA in the home network 
If AAAH policy says "HA may be in the serving network" (say for normal
internet users) then AAAH sends HAR to AAAF

If AAAF is not willing to provide HA service, then it sets flag1 == 0 in AMR
AAAH assigns HA in the home network (no other choice)
-----

The point that I am trying to make is, MNs don't need to send different
indications to the network, the home network knows user's preferences and
should be able to assign HAs accordingly.

-Kuntal



PatC


------_=_NextPart_001_01C14C57.CE151B40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [mobile-ip] RE: [diameter] DIAMETER support for MIP question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Pat,</FONT>
<BR><FONT SIZE=2>Please see my responses inline:</FONT>
</P>

<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Kuntal</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, October 03, 2001 11:24 AM</FONT>
<BR><FONT SIZE=2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=2>Cc: Pat Calhoun; charliep@IPRG.nokia.com; diameter@diameter.org</FONT>
<BR><FONT SIZE=2>Subject: Re: [mobile-ip] RE: [diameter] DIAMETER support for MIP</FONT>
<BR><FONT SIZE=2>question</FONT>
</P>
<BR>

<P><FONT SIZE=2>On Tue, Oct 02, 2001 at 06:23:49PM -0500, Kuntal Chowdhury wrote:</FONT>
<BR><FONT SIZE=2>&gt; Pat,</FONT>
<BR><FONT SIZE=2>&gt; Thanks for responding. I am still not clear on the following two issues in</FONT>
<BR><FONT SIZE=2>&gt; &quot;draft-ietf-aaa-diameter-mobileip-07&quot;:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1. Section 1.4 Page 12</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; AAAF in foreign network 1 will send back error code</FONT>
<BR><FONT SIZE=2>&gt; &quot;DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE&quot; to AAAH if foreign network 1 does not</FONT>
<BR><FONT SIZE=2>&gt; wish to provide HA service when the MN has moved to foreign network 2.</FONT>
<BR><FONT SIZE=2>&gt; However it is not mentioned when the AAAH receives such an error code from</FONT>
<BR><FONT SIZE=2>&gt; AAAF what happens to the mobile IP registration request. </FONT>
<BR><FONT SIZE=2>&gt; I think some text is required to capture this exception case. Options before</FONT>
<BR><FONT SIZE=2>&gt; AAAH is either send another HAR to AAAF in network 2 (only if AAAF had set</FONT>
<BR><FONT SIZE=2>&gt; the &quot;Foreign-Home-Agent-Available&quot; flag in AMR), otherwise AAAH may assign a</FONT>
<BR><FONT SIZE=2>&gt; HA in the home network or reject the mobile IP registration request. </FONT>
</P>

<P><FONT SIZE=2>The text that follows is at the end of section 1.4 and I believe it does</FONT>
<BR><FONT SIZE=2>cover this error:</FONT>
</P>

<P><FONT SIZE=2>&quot;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; If the old Foreign Network does not permit the use of its Home Agent</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; when the Mobile Node moves to a new foreign network, the AAAH or AAAF</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; MUST return an AMA with the Result-Code AVP set to</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Node with an appropriate error. The Mobile Node MAY attempt to</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; request that a new Home Agent and Address be allocated. When the AAAH</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; transmits such an error, it MUST issue a Diameter Abort-Session-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Request message to the AAAF overseeing the Home Agent to enable it to</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; release any resources.&quot;</FONT>
</P>

<P><FONT SIZE=2>Is this not sufficient?</FONT>
</P>

<P><FONT SIZE=2>KC&gt; This text captures one of the three options that I mentioned before. The three options for AAAH are:</FONT>
</P>

<P><FONT SIZE=2>i.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAAH sends an HAR message to AAAF2 if AAAF2 sets Foreign-Home-Agent-Available = 1</FONT>
<BR><FONT SIZE=2>ii.&nbsp;&nbsp;&nbsp;&nbsp; AAAH assigns a HA in the home network if (i) = false</FONT>
<BR><FONT SIZE=2>iii.&nbsp; AAAH rejects the registration request if (i) and (ii) = false</FONT>
</P>

<P><FONT SIZE=2>The text in the draft covers, only option (iii). </FONT>
</P>

<P><FONT SIZE=2>The advantages of adopting the suggested approach are:</FONT>
<BR><FONT SIZE=2>a) MN won't have to initiate another MIP registration request.</FONT>
<BR><FONT SIZE=2>b) No need for extra messaging over the air.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; 2. When MN requests for a HA allocation in the foreign network, and for some</FONT>
<BR><FONT SIZE=2>&gt; reason AAAF does not set &quot;Foreign-Home-Agent-Available&quot; or AAAH denies the</FONT>
<BR><FONT SIZE=2>&gt; request, how does the MN come to know that it did not get what it requested?</FONT>
</P>

<P><FONT SIZE=2>It would receive the Registration Reply with the proper error code. There are</FONT>
<BR><FONT SIZE=2>a variety of error codes defined in RFC2002, but perhaps a more specific error</FONT>
<BR><FONT SIZE=2>code could be introduced? If so, where should it be specified?</FONT>
</P>

<P><FONT SIZE=2>KC&gt; May be we can add this error code in 2002bis.</FONT>
</P>

<P><FONT SIZE=2>&gt; If it is immaterial for the MN's MIP client to know where the HA gets</FONT>
<BR><FONT SIZE=2>&gt; allocated, why does it ask for it differently e.g. some MNs requesting with</FONT>
<BR><FONT SIZE=2>&gt; 0.0.0.0 and some others requesting with 255.255.255.255?</FONT>
</P>

<P><FONT SIZE=2>corporate customers would most likely want an HA in their corporate networks.</FONT>
<BR><FONT SIZE=2>Normal Internet users don't care where the HA resides.</FONT>
</P>

<P><FONT SIZE=2>KC&gt; </FONT>
<BR><FONT SIZE=2>If the corporate customers need HAs in their corporate networks, AAAH should be able to enforce that. Even if all the mobiles send the same indication for dynamic HA allocation, AAAH should have the ability to decide whether the HA to be assigned in the home network or in the serving network. e.g.</FONT></P>

<P><FONT SIZE=2>-----</FONT>
<BR><FONT SIZE=2>MN sends 0.0.0.0 in the HA field in RRQ</FONT>
</P>

<P><FONT SIZE=2>If AAAF is willing to provide HA service (irrespective of the value in HA field in RRQ), then it sets flag1 == 1 in AMR</FONT>
<BR><FONT SIZE=2>If AAAH policy says &quot;HA must be in the home network&quot; (say for corporate users) then AAAH assigns HA in the home network </FONT></P>

<P><FONT SIZE=2>If AAAH policy says &quot;HA may be in the serving network&quot; (say for normal internet users) then AAAH sends HAR to AAAF</FONT>
</P>

<P><FONT SIZE=2>If AAAF is not willing to provide HA service, then it sets flag1 == 0 in AMR</FONT>
<BR><FONT SIZE=2>AAAH assigns HA in the home network (no other choice)</FONT>
<BR><FONT SIZE=2>-----</FONT>
</P>

<P><FONT SIZE=2>The point that I am trying to make is, MNs don't need to send different indications to the network, the home network knows user's preferences and should be able to assign HAs accordingly.</FONT></P>

<P><FONT SIZE=2>-Kuntal</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>PatC</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14C57.CE151B40--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct  3 22:24:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08372
	for <mobileip-archive@odin.ietf.org>; Wed, 3 Oct 2001 22:24:24 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03053;
	Wed, 3 Oct 2001 20:23:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12564;
	Wed, 3 Oct 2001 19:23:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f942MUML010419
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 19:22:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f942MTQF010418
	for mobile-ip-dist; Wed, 3 Oct 2001 19:22:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f942MQML010411
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 19:22:26 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12435
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 19:22:26 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03737
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 19:22:26 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f942MSw23128
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:22:28 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5660dae442ac12f2540ff@davir01nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Wed, 3 Oct 2001 21:22:25 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 3 Oct 2001 21:22:25 -0500
content-class: urn:content-classes:message
Subject: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 3 Oct 2001 21:22:25 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E87B3@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: MIPv6 - Focus of the security discussion
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFMe2QxF4gSirhqEdWw+gAAhj/HZA==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 04 Oct 2001 02:22:25.0047 (UTC) FILETIME=[67DF7270:01C14C7B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f942MQML010412
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello,

Over the last week or so, I have seen a lot of discussion on the list
about how to secure MIPv6 Binding updates using IPsec. I just want to
make sure that the WG is really focused on the right set of issues
here:

   Binding updates need to be authenticated. The WG needs to develop a
   solution that essentially addresses the concerns raised by the IESG
   (see Jeff's slides for the set of issues, presented at IETF50). The
   intent should be to develop a solution that does not rely on IPSec,
   while making it possible for IPSec to be used. The reason why we
   are currently discussing this topic is because we need to develop a
   mechanism that does not rely on IPSec.  There needs to be a
   security association between the MN and the CN in order to secure
   the BU (I am leaving the MN-HA SA out or the moment). If there
   exists an IPsec SA between the two, that has been established via
   some means, it should be possible to use that SA to authenticate
   the BU. The problems associated with selector granularity,
   piggybacking etc. should be dealt with separately. The point is
   there should be at least an equal effort in trying to develop a
   scheme for securing BUs that does not rely on IPsec.  The
   discussion so far has been centered on how to make IPsec work for
   MIPv6. It is important to find a solution that allows the use of
   IPsec, but it should be done as a lower priority item. I believe
   the discussion needs to be on how to secure binding updates in the
   absence of IPsec while keeping IPsec as an optional mechanism. This
   will enable getting the MIPv6 spec out the door faster.

 
-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 00:20:26 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12379
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 00:20:25 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14568;
	Wed, 3 Oct 2001 22:19:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16678;
	Wed, 3 Oct 2001 21:19:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f944IJML010561
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:18:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f944IJoh010560
	for mobile-ip-dist; Wed, 3 Oct 2001 21:18:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f944IFML010553
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:18:15 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA24004
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:18:18 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14110
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:18:05 -0600 (MDT)
Received: from Intergalactic (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP
	id 7C64862D1E; Thu,  4 Oct 2001 13:18:12 +0900 (JST)
Date: Thu, 04 Oct 2001 13:17:35 +0900
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
Cc: vijayd@iprg.nokia.com, mip6@sfc.wide.ad.jp
In-Reply-To: <Roam.SIMC.2.0.6.1001512185.18385.nordmark@bebop.france>
References: <3BB0A4EC.C7E993F@iprg.nokia.com> <Roam.SIMC.2.0.6.1001512185.18385.nordmark@bebop.france>
Message-Id: <20011004122826.56EA.RYUJI@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Erik

Sorry for replying late.

I have been implementing MIP6 on kame stack at KEIO university. 
I participated in connotation 2001 and our MIP6 has interoperability with some other MIP6. 

> Since there exists implementations of MIPv6 I wonder 1) how many of them
> have implementing piggybacking and 

	We support piggybacking for both directions (incoming,outgoing)

> 2) of those have any looked at
> the effect of turning piggy-backing on and off.

	We haven't tested piggybacking with other implementation, but
	among our HA,CN, MN, we normally enable piggybacking
	functionality and it works, even though our code is based on draft-13.

	I evaluated the cost of sending BUs by piggybacking at my master thesis. 
	Unfortunately, it was written in Japanese, sorry guys, 
	but let me try to explain briefly.

	This is the results of cost for piggyback processing in the kernel, 
	when MN sends BU with AH during flood ICMP6 Echo request/reply(data 16byte) to CN .
	These value was measured by pentium counter.

			no piggyback (only BU)	/ piggyback
	sending cost	0.20 msec		/ 	0.23 msec
	receiving cost	0.29 msec		/	0.34 msec

	I guess the overhead of piggyback is caused by IPsec processing, 
	because the size of the packet(BU+data) is larger than the single BU packet.

	Our MIP6 waits default 1 sec (configurable) for some piggybacked data before sending BU.


regards,
ryuji

	
> 
> Is there any data?
> 
> > The crucial thing is to prevent Binding Updates from being sent
> > unnecessarily.  Any implementation which sends Binding Updates at
> > every change in point of connection to the Internet (or, even worse,
> > on every movement detection) is potentially doing a lot of
> > unnecessary signalling.  In contrast, an implementation that sends
> > Binding Updates in the first data packet going out after detecting
> > a change in the mobile node's point of attachment, is going to have
> > a lot less overheat.
> 
> It clearly doesn't work to always delay the BU until data needs to be sent
> to the CN. The BU needs to be sent before the CN tries to send data
> to the MN - if the CN sends to the old CoA the packet might be dropped
> (depending whether the MN was successful in updating a previous default router
> and to what extent you want to have a residual dependency on the availability
> of the previous visited link).
> 
> Predicting when a CN is going to next try to send to the MN is hard and
> requires being able to predict the behavior of the transport protocol
> as well as the applications running.
> 
> I wonder what working strategies folks have tried in implementations.
> 
>    Erik
> 
> 




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 00:50:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12808
	for <mobileip-archive@lists.ietf.org>; Thu, 4 Oct 2001 00:50:08 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA09846;
	Wed, 3 Oct 2001 21:49:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19739;
	Wed, 3 Oct 2001 21:48:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f944loML010674
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:47:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f944loMf010673
	for mobile-ip-dist; Wed, 3 Oct 2001 21:47:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f944lkML010666
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:47:46 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19635
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 21:47:49 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24515
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:47:37 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA07171;
	Thu, 4 Oct 2001 14:43:53 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA06746;
	Thu, 4 Oct 2001 14:45:00 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXHLK9>; Thu, 4 Oct 2001 14:44:58 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED02@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: vijayd@iprg.nokia.com, mip6@sfc.wide.ad.jp
Subject: RE: [mobile-ip] Draft 15
Date: Thu, 4 Oct 2001 14:44:57 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14C8F.51AAB1E0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14C8F.51AAB1E0
Content-Type: text/plain


	This is really interesting ...some comments below.


> > Since there exists implementations of MIPv6 I wonder 1) how many of them
> > have implementing piggybacking and 
> 
> 	We support piggybacking for both directions (incoming,outgoing)
> 
> > 2) of those have any looked at
> > the effect of turning piggy-backing on and off.
> 
> 	We haven't tested piggybacking with other implementation, but
> 	among our HA,CN, MN, we normally enable piggybacking
> 	functionality and it works, even though our code is based on
> draft-13.
> 
	=> But are you using IPsec ? if so then you must be protecting every

	packet ?

> 	I evaluated the cost of sending BUs by piggybacking at my master
> thesis. 
> 	Unfortunately, it was written in Japanese, sorry guys, 
> 	but let me try to explain briefly.
> 
> 	This is the results of cost for piggyback processing in the kernel, 
> 	when MN sends BU with AH during flood ICMP6 Echo request/reply(data
> 16byte) to CN .
> 	These value was measured by pentium counter.
> 
> 			no piggyback (only BU)	/ piggyback
> 	sending cost	0.20 msec		/ 	0.23 msec
> 	receiving cost	0.29 msec		/	0.34 msec
> 
> 	I guess the overhead of piggyback is caused by IPsec processing, 
> 	because the size of the packet(BU+data) is larger than the single BU
> packet.
> 
> 	Our MIP6 waits default 1 sec (configurable) for some piggybacked
> data before sending BU.
> 
	=> Ok but 1 sec is probably not acceptable for TCP or real time
apps. 
	But that's an implementation issue I guess.
	Hesham
> 	
> 

------_=_NextPart_001_01C14C8F.51AAB1E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Draft 15</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This is really =
interesting ...some comments below.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Since there exists =
implementations of MIPv6 I wonder 1) how many of them</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; have implementing piggybacking =
and </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">We support piggybacking for both directions =
(incoming,outgoing)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; 2) of those have any looked =
at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the effect of turning =
piggy-backing on and off.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">We haven't tested piggybacking with other =
implementation, but</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">among our HA,CN, MN, we normally enable =
piggybacking</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">functionality and it works, even though our code is =
based on draft-13.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; But are you =
using IPsec ? if so then you must be protecting every </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">packet ?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I evaluated the cost of sending BUs by piggybacking at =
my master thesis. </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Unfortunately, it was written in Japanese, sorry guys, =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">but let me try to explain briefly.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">This is the results of cost for piggyback processing in =
the kernel, </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">when MN sends BU with AH during flood ICMP6 Echo =
request/reply(data 16byte) to CN .</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">These value was measured by pentium counter.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">no piggyback (only BU)&nbsp; / piggyback</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">sending cost&nbsp;&nbsp;&nbsp; 0.20 =
msec&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; / =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.23 msec</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">receiving cost&nbsp; 0.29 =
msec&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.34 msec</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I guess the overhead of piggyback is caused by IPsec =
processing, </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">because the size of the packet(BU+data) is larger than =
the single BU packet.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Our MIP6 waits default 1 sec (configurable) for some =
piggybacked data before sending BU.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Ok but 1 sec =
is probably not acceptable for TCP or real time apps. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But that's an =
implementation issue I guess.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C14C8F.51AAB1E0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 01:48:55 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16115
	for <mobileip-archive@lists.ietf.org>; Thu, 4 Oct 2001 01:48:54 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA20457;
	Wed, 3 Oct 2001 22:48:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25210;
	Wed, 3 Oct 2001 22:47:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f945koML010802
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:46:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f945knf0010801
	for mobile-ip-dist; Wed, 3 Oct 2001 22:46:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f945kkML010794
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:46:46 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02219
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:46:47 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21685
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:47:49 -0600 (MDT)
Received: from Intergalactic (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP
	id CF65C62D1E; Thu,  4 Oct 2001 14:46:42 +0900 (JST)
Date: Thu, 04 Oct 2001 14:46:06 +0900
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
Cc: vijayd@iprg.nokia.com, mip6@sfc.wide.ad.jp
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED02@eaubrnt018.epa.ericsson.se>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED02@eaubrnt018.epa.ericsson.se>
Message-Id: <20011004142740.56F8.RYUJI@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Hesham

> 	This is really interesting ...some comments below.

You can find my paper on my HP, if you can understand Japanese :-)
 
> > > Since there exists implementations of MIPv6 I wonder 1) how many of them
> > > have implementing piggybacking and 
> > 
> > 	We support piggybacking for both directions (incoming,outgoing)
> > 
> > > 2) of those have any looked at
> > > the effect of turning piggy-backing on and off.
> > 
> > 	We haven't tested piggybacking with other implementation, but
> > 	among our HA,CN, MN, we normally enable piggybacking
> > 	functionality and it works, even though our code is based on
> > draft-13.
> > 
> 	=> But are you using IPsec ? if so then you must be protecting every
> 
> 	packet ?

Yes. I protect whole packets by AH, whenever BU is sent by using piggypacking.

If a packet has own SA, our MIP6 give the SA priority 
over a SA for MIP6 packets (ie. BU, BA).
I mean, when the packet is sent, MIP6 first check the SA for the packet itself.
If it is found, MIP6 use the SA instead of MIP6 SA. 
Otherwise, MIP6 uses the SA which is established for BU.


> > 	Our MIP6 waits default 1 sec (configurable) for some piggybacked
> > data before sending BU.
> > 
> 	=> Ok but 1 sec is probably not acceptable for TCP or real time
> apps. 

Yes, but we do not think this interval will be bottleneck of MIP6 performance, 
because this interval value can be configured depending on 
network situation or communication condition.

And the movement detection of MN takes more time and it
is the real bottleneck for TCP performance in our evaluation. 
We currently do not support any seamless mobility scheme in our MIP6.
That might be the problem...

> 	But that's an implementation issue I guess.

Yes that's why I stay the value as configurable

regards,
ryuji


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 01:59:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16835
	for <mobileip-archive@lists.ietf.org>; Thu, 4 Oct 2001 01:59:22 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA22512;
	Wed, 3 Oct 2001 22:58:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27717;
	Wed, 3 Oct 2001 22:58:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f945vfML010919
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:57:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f945vf9L010918
	for mobile-ip-dist; Wed, 3 Oct 2001 22:57:41 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f945vbML010911
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:57:37 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03855
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 22:57:38 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA18508
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:57:26 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA15436
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 15:55:54 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA24447
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 15:57:01 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXHNXQ>; Thu, 4 Oct 2001 15:56:59 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED05@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: mip6@sfc.wide.ad.jp
Subject: RE: [mobile-ip] Draft 15
Date: Thu, 4 Oct 2001 15:56:58 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>


> > 	This is really interesting ...some comments below.
> 
> You can find my paper on my HP, if you can understand Japanese :-)
> 
	=> I'll pass thanks :)
>  
> > > > Since there exists implementations of MIPv6 I wonder 1) how many of
> them
> > > > have implementing piggybacking and 
> > > 
> > > 	We support piggybacking for both directions (incoming,outgoing)
> > > 
> > > > 2) of those have any looked at
> > > > the effect of turning piggy-backing on and off.
> > > 
> > > 	We haven't tested piggybacking with other implementation, but
> > > 	among our HA,CN, MN, we normally enable piggybacking
> > > 	functionality and it works, even though our code is based on
> > > draft-13.
> > > 
> > 	=> But are you using IPsec ? if so then you must be protecting every
> > 
> > 	packet ?
> 
> Yes. I protect whole packets by AH, whenever BU is sent by using
> piggypacking.
> 
> If a packet has own SA, our MIP6 give the SA priority 
> over a SA for MIP6 packets (ie. BU, BA).
> I mean, when the packet is sent, MIP6 first check the SA for the packet
> itself.
> If it is found, MIP6 use the SA instead of MIP6 SA. 
> Otherwise, MIP6 uses the SA which is established for BU.
> 
	=> OK but I meant that you must protect _every_ packet
	whether it contains BU or not. 
	You seem to refer to MIP6 SA, did you add some code to
	the IPsec to make sure the selectors recognise the 
	BU option ? Or what do you mean by MIP6 SA ?


> And the movement detection of MN takes more time and it
> is the real bottleneck for TCP performance in our evaluation. 
> We currently do not support any seamless mobility scheme in our MIP6.
> That might be the problem...
> 
	=> Well on a BW-rich link (like ethernet :) ) you can do things 
	to speed up the movement detection It certainly should 
	take less than 1 sec. 
	Of course on more BW constrained links, you need other
	optimisations like the Fast Handoffs draft.

	Cheers,
	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 02:26:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26566
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 02:26:05 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27489;
	Wed, 3 Oct 2001 23:25:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00195;
	Wed, 3 Oct 2001 23:25:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f946OGML011024
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:24:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f946OGuZ011023
	for mobile-ip-dist; Wed, 3 Oct 2001 23:24:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f946ODML011016
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:24:13 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06362
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:24:15 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29711
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 00:24:03 -0600 (MDT)
Received: from Intergalactic (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP
	id C185762D1E; Thu,  4 Oct 2001 15:24:10 +0900 (JST)
Date: Thu, 04 Oct 2001 15:23:34 +0900
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
Cc: mip6@sfc.wide.ad.jp
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED05@eaubrnt018.epa.ericsson.se>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED05@eaubrnt018.epa.ericsson.se>
Message-Id: <20011004150025.56FA.RYUJI@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Hesham

 
> > Yes. I protect whole packets by AH, whenever BU is sent by using
> > piggypacking.
> > 
> > If a packet has own SA, our MIP6 give the SA priority 
> > over a SA for MIP6 packets (ie. BU, BA).
> > I mean, when the packet is sent, MIP6 first check the SA for the packet
> > itself.
> > If it is found, MIP6 use the SA instead of MIP6 SA. 
> > Otherwise, MIP6 uses the SA which is established for BU.
> > 
> 	=> OK but I meant that you must protect _every_ packet
> 	whether it contains BU or not. 
> 	You seem to refer to MIP6 SA, did you add some code to
> 	the IPsec to make sure the selectors recognise the 
> 	BU option ? Or what do you mean by MIP6 SA ?

OK, let me explain more about this,,,
As you wrote in your mail, our implementation can handle the SA only for BU and BA 
which I call MIP6 SA. I modified the IPsec.
I assigned new protocol number for MIP6 binding messages. This number is not used as
the normal protocol number and it is just magic number for IPsec selectors. 
The MIP6 protocol number indicates that the SA is established for MIP6 BU and BA.

If you would configure SA by hand, it looks like this.

spdadd 3ffe::xx/64[any] 4ffe::yy/64[any] mip6 -P in ipesc
					      ^^^^
	ah/transport//require

 
> 	=> Well on a BW-rich link (like ethernet :) ) you can do things 
> 	to speed up the movement detection It certainly should 
> 	take less than 1 sec. 
> 	Of course on more BW constrained links, you need other
> 	optimisations like the Fast Handoffs draft.

I agree with you. I guess handling layer 2 information in MIP6 layer is also requisite for
the movement detection. We plan to support one of the fast handoffs draft in near future

best regards,
ryuji


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 02:39:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27825
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 02:39:24 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00256;
	Wed, 3 Oct 2001 23:38:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04550;
	Wed, 3 Oct 2001 23:38:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f946buML011111
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:37:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f946bupm011110
	for mobile-ip-dist; Wed, 3 Oct 2001 23:37:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f946bqML011103
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:37:52 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29938
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:37:54 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06768
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 3 Oct 2001 23:37:53 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA20173;
	Thu, 4 Oct 2001 16:34:47 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA04444;
	Thu, 4 Oct 2001 16:35:53 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXHPD0>; Thu, 4 Oct 2001 16:35:51 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED06@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: mip6@sfc.wide.ad.jp
Subject: RE: [mobile-ip] Draft 15
Date: Thu, 4 Oct 2001 16:35:50 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14C9E.CF22E980"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14C9E.CF22E980
Content-Type: text/plain


> OK, let me explain more about this,,,
> As you wrote in your mail, our implementation can handle the SA only for
> BU and BA 
> which I call MIP6 SA. I modified the IPsec.
> I assigned new protocol number for MIP6 binding messages. This number is
> not used as
> the normal protocol number and it is just magic number for IPsec
> selectors. 
> The MIP6 protocol number indicates that the SA is established for MIP6 BU
> and BA.
> 
	=> OK. so it's not really draft -13 but I guess you're showing
	one way of fixing the problem.
>  
> > 	=> Well on a BW-rich link (like ethernet :) ) you can do things 
> > 	to speed up the movement detection It certainly should 
> > 	take less than 1 sec. 
> > 	Of course on more BW constrained links, you need other
> > 	optimisations like the Fast Handoffs draft.
> 
> I agree with you. I guess handling layer 2 information in MIP6 layer is
> also requisite for
> the movement detection. We plan to support one of the fast handoffs draft
> in near future
> 
	=> Handling layer 2 is important to get better BW utilisation.
	Of course if BW is not important, other methods are possible
	on the IP layer.

	Hesham

------_=_NextPart_001_01C14C9E.CF22E980
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Draft 15</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">OK, let me explain more about =
this,,,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As you wrote in your mail, our =
implementation can handle the SA only for BU and BA </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">which I call MIP6 SA. I modified the =
IPsec.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I assigned new protocol number for =
MIP6 binding messages. This number is not used as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the normal protocol number and it is =
just magic number for IPsec selectors. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The MIP6 protocol number indicates =
that the SA is established for MIP6 BU and BA.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; OK. so it's =
not really draft -13 but I guess you're showing</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">one way of fixing =
the problem.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; Well on a BW-rich link (like ethernet :) ) you can do things =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
to speed up the movement detection It certainly should </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
take less than 1 sec. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Of course on more BW constrained links, you need other</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
optimisations like the Fast Handoffs draft.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree with you. I guess handling =
layer 2 information in MIP6 layer is also requisite for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the movement detection. We plan to =
support one of the fast handoffs draft in near future</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Handling =
layer 2 is important to get better BW utilisation.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Of course if BW is =
not important, other methods are possible</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">on the IP =
layer.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C14C9E.CF22E980--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 04:55:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02209
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 04:55:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10929;
	Thu, 4 Oct 2001 02:54:55 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21759;
	Thu, 4 Oct 2001 01:54:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f948s1ML011317
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 01:54:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f948s13q011316
	for mobile-ip-dist; Thu, 4 Oct 2001 01:54:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f948rvML011309
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 01:53:57 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12686
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 01:53:58 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10482
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:53:46 -0600 (MDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA04907 for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 01:53:56 -0700 (MST)]
Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id BAA08559 for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 01:45:07 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Thu, 4 Oct 2001 01:53:46 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 471EA2ED24; Thu,  4 Oct 2001 10:50:12 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: vijayd@iprg.nokia.com, mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
References: <3BB0A4EC.C7E993F@iprg.nokia.com>
	<Roam.SIMC.2.0.6.1001512185.18385.nordmark@bebop.france>
	<20011004122826.56EA.RYUJI@sfc.wide.ad.jp>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 04 Oct 2001 10:53:38 +0200
In-Reply-To: <20011004122826.56EA.RYUJI@sfc.wide.ad.jp>
Message-Id: <m3bsjn23cd.fsf@test9.crm.mot.com>
Lines: 13
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Ryuji Wakikawa <ryuji@sfc.wide.ad.jp> writes:
> I have been implementing MIP6 on kame stack at KEIO university.  I
> participated in connotation 2001 and our MIP6 has interoperability
> with some other MIP6.

I would like to update my list of publicly available Mobile IPv6
implementations and it seems that yours is new.  Is the code available
(the neo.sfc web page says source code soon)?  What is its relation
with Ericsson's Mobile IPv6 code in KAME?

Thank you,

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 05:40:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03484
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 05:40:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21765;
	Thu, 4 Oct 2001 02:39:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26392;
	Thu, 4 Oct 2001 02:39:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f949brML011445
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:37:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f949brs3011444
	for mobile-ip-dist; Thu, 4 Oct 2001 02:37:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f949bnML011435
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:37:49 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23116
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:37:51 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06051
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 03:37:39 -0600 (MDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f949bfL17718;
	Thu, 4 Oct 2001 11:37:42 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id LAA11930; Thu, 4 Oct 2001 11:37:41 +0200
Message-ID: <3BBC2D55.80A8294B@era.ericsson.se>
Date: Thu, 04 Oct 2001 11:35:17 +0200
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: vijayd@iprg.nokia.com, mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
References: <3BB0A4EC.C7E993F@iprg.nokia.com>
		<Roam.SIMC.2.0.6.1001512185.18385.nordmark@bebop.france>
		<20011004122826.56EA.RYUJI@sfc.wide.ad.jp> <m3bsjn23cd.fsf@test9.crm.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi all,

Alexandru Petrescu wrote:
> 
> Ryuji Wakikawa <ryuji@sfc.wide.ad.jp> writes:
> > I have been implementing MIP6 on kame stack at KEIO university.  I
> > participated in connotation 2001 and our MIP6 has interoperability
> > with some other MIP6.
> 
> I would like to update my list of publicly available Mobile IPv6
> implementations and it seems that yours is new.  Is the code available
> (the neo.sfc web page says source code soon)?  What is its relation
> with Ericsson's Mobile IPv6 code in KAME?

To answer the last question: there is no real relationship. Both use
KAME IPv6 as base. Ericsson's implementation was taken in as
experimental part of KAME's source code.

/Mattias

> 
> Thank you,
> 
> Alex


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 05:53:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03706
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 05:53:55 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25583;
	Thu, 4 Oct 2001 02:52:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18972;
	Thu, 4 Oct 2001 02:52:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f949peML011543
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:51:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f949peOe011542
	for mobile-ip-dist; Thu, 4 Oct 2001 02:51:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f949paML011535
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:51:36 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27537
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:51:38 -0700 (PDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13287
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:51:37 -0700 (PDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id CAA14670 for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:43:07 -0700 (MST)]
Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id CAA28200 for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:51:36 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Thu, 4 Oct 2001 04:51:24 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id C69782ED24; Thu,  4 Oct 2001 11:47:52 +0200 (CEST)
X-Gnus-Agent-Meta-Information: mail nil
To: pekkas@netcore.fi
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 SecReqs: HA Dyn Discovery
References: <Pine.LNX.4.33.0109301519340.27777-100000@netcore.fi>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 03 Oct 2001 22:29:26 +0200
In-Reply-To: <Pine.LNX.4.33.0109301519340.27777-100000@netcore.fi>
Message-Id: <m37kuctql5.fsf@test9.crm.mot.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
Lines: 35
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Pekka Savola <pekkas@netcore.fi> writes:
>  2) the assumption may be flawed in a scenario:
> 
>    1  The mobile node and the HA have setup a pre-established security
>       association before the mobile node begins to roam and connects to
>       the network from a location that is not its home.
> 
> This wouldn't appear to work with e.g. 'Dynamic Home Agent Address
> Discovery' (10.8), that is, e.g. when the trusted HA dies and MN is
> away from home and it needs to find the new HA.  The assumption is
> valid only after a HA-MN relationship has been formed.

I think H.1 is a threat _related_ to DHAAD.  One could probably add a
new threat B.x in which DHAAD itself is attacked.  Your description
seems to imply that an attacker close to MN would reply to a discovery
sent by MN to its home, giving fake HA addresses.

As an aside, the assumption SA MN-HA can be detailed such that the SA
MN-HA is betweeen an MN's Home Address and the "Mobile IPv6
Home-Agents" anycast address (and not between the Home Address and one
Home Agent Address).  In fact, it suffices to say:

     1  The mobile node and all its potential HA's at home (the home of
        the initial Home Address and not that of an intermediary CoA)
        have setup a pre-established security association before the
        mobile node begins to roam and connects to the network from a
        location that is not its home.

instead of:

     1  The mobile node and the HA have setup a pre-established security
        association before the mobile node begins to roam and connects to
        the network from a location that is not its home.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 05:56:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03768
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 05:56:43 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26534;
	Thu, 4 Oct 2001 02:56:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19434;
	Thu, 4 Oct 2001 02:56:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f949tGML011647
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:55:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f949tGs2011646
	for mobile-ip-dist; Thu, 4 Oct 2001 02:55:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f949tCML011639
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:55:12 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22635
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 02:55:14 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15824
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 03:55:02 -0600 (MDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f949t8C24353;
	Thu, 4 Oct 2001 11:55:08 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f949t7l27368;
	Thu, 4 Oct 2001 12:55:08 +0300 (EET DST)
Message-ID: <3BBC31FC.D9485BE@lmf.ericsson.se>
Date: Thu, 04 Oct 2001 12:55:08 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: charliep@iprg.nokia.com
CC: mobile-ip@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com
Subject: [mobile-ip] Auth suboption & address ownership
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED06@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi,

I have a question on -15/-14 authentication suboption
and its handling of the 'address ownership' problem.

As a background, we of course assume that something
like BAKE can establish somehow that a particular
peer really is allowed to specify what to do with
its address. In BAKE for instance, keying material
from messages sent over different paths are combined
to establish a form of trust. My question is not about
this phase, however.

As a result of BAKE or whatever we are left with an
SA that is identified by the 'destination ip address
and SPI', and contains a shared secret with the peer.

My question relates to how we can prevent a MN from
establishing a legitimate SA with a CN, and then
misusing this SA to send a BU for _another_ MN.
Given rules in -14/-15, it seems that both sides
calculate the MAC based on the contents of the
BU packet. So, what if the sender lied about the
Home Address, but used its own SPI; hence fooling
the CN to use the wrong SA? The destination ip
address of course is the CN for both.

It seems that the rules presented so far are not
sufficient to prevent this from happening. Or have
I missed something, some text hiding somewhere perhaps?

As a possible solution, I propose that the Home
Address of the MN is stored in the SA during
BAKE/whatever, and that each reception of a BU
message not only checks the MAC but also verifies
that the given Home Address is the same one as
that in the SA. (This is similar to what selectors
do in an IPsec SA to ensure that the right kind
of packet was received from the tunnel.) Alternatively,
the text in -15 4.6. under the Binding Cache entry or
in 8.2. should be clarified that the implementations MUST
*check* that only the given BSA was used. This may be
implied from 4.6 but I'd rather have this said explicitly.

Also, it might clarify things a bit if the conceptual
data structure of an SA was described in more detail,
what the components are. Btw, do we have the algorithms
specified anywhere regarding what the suboption must
support?

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 07:05:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05566
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 07:05:23 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15919;
	Thu, 4 Oct 2001 04:04:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02246;
	Thu, 4 Oct 2001 04:04:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94B3kML011814
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 04:03:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94B3jpr011813
	for mobile-ip-dist; Thu, 4 Oct 2001 04:03:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94B3gML011806
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 04:03:42 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28903
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 04:03:43 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28251
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 05:04:45 -0600 (MDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id EAA25381 for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 04:03:41 -0700 (MST)]
Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id EAA27288 for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 04:03:40 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Thu, 4 Oct 2001 06:03:40 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id EC2EA2ED24; Thu,  4 Oct 2001 12:59:57 +0200 (CEST)
To: Pekka.Nikander@nomadiclab.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Replay attack in BAKE
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 04 Oct 2001 13:03:24 +0200
Message-Id: <m3itdvzmyr.fsf@test9.crm.mot.com>
Lines: 20
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi,

I think that in the context of BAKE, MN-initiated operation, it is
possible for an attacker to replay a set of BW and BKE to a CN.  For
example, an attacker on the MN's link listens to the BW/BKE sent to a
CN and once that MN's traffic stops (presumably MN moved), the
attacker would replay the same BW/BKE pair to the respective CN.  This
would fool the CN to believe that MN moved back to the place where
attacker is.

I think the success of this attack relies on the "freshness" of K_CN,
which is a fixed constant (moreover, a history is kept).

It also relies on the fact that CN doesn't check a history of received
N1's (since it doesn't keep state).

I probably have missed something when trying to understand BAKE, but
I'm doing my best.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 08:11:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07672
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 08:11:07 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24596;
	Thu, 4 Oct 2001 06:10:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05475;
	Thu, 4 Oct 2001 05:10:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94C9VML012002
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 05:09:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94C9VOL012001
	for mobile-ip-dist; Thu, 4 Oct 2001 05:09:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94C9RML011994
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 05:09:27 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05405
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 05:09:29 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23488
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 06:10:34 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f94C9PO15343;
	Thu, 4 Oct 2001 14:09:25 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA04416;
	Thu, 4 Oct 2001 14:09:24 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f94C9MD18571;
	Thu, 4 Oct 2001 14:09:22 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110041209.f94C9MD18571@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15 
In-reply-to: Your message of Thu, 04 Oct 2001 15:23:34 +0900.
             <20011004150025.56FA.RYUJI@sfc.wide.ad.jp> 
Date: Thu, 04 Oct 2001 14:09:22 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   As you wrote in your mail, our implementation can handle the SA
   only for BU and BA which I call MIP6 SA. I modified the IPsec.
   I assigned new protocol number for MIP6 binding messages. This
   number is not used as the normal protocol number and it is just magic
   number for IPsec selectors.
   The MIP6 protocol number indicates that the SA is established for
   MIP6 BU and BA.
   
=> I used the same kind of trick (the destination option processing
was modified and special selector is the destination option header code).
My code should be very similar (same platform and problem) but
I did't implement the sending side of piggybacking.

Thanks

Francis.Dupont@enst-bretagne


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 08:15:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07877
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 08:15:18 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27011;
	Thu, 4 Oct 2001 06:14:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06030;
	Thu, 4 Oct 2001 05:14:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94CE2ML012080
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 05:14:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94CE2vT012079
	for mobile-ip-dist; Thu, 4 Oct 2001 05:14:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94CDxML012072
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 05:13:59 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05971
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 05:14:01 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25414
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 06:15:06 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f94CDvO16326
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 14:13:57 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA04555
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 14:13:57 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f94CDvD18604
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 14:13:57 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110041213.f94CDvD18604@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Wed, 03 Oct 2001 21:22:25 CDT.
             <697DAA22C5004B4596E033803A7CEF441E87B3@daebe007.NOE.Nokia.com> 
Date: Thu, 04 Oct 2001 14:13:57 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

      Binding updates need to be authenticated.

=> I have a little concern about this. Even if authentication can be
the first step towards a solution, the real need is not authentication
but some kind of authorization (cf. authorization vs. authentication
and strong authentication == global PKI past threads).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 10:33:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14373
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 10:33:30 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03409;
	Thu, 4 Oct 2001 08:32:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27810;
	Thu, 4 Oct 2001 07:32:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EVRML012327
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:31:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94EVR1W012326
	for mobile-ip-dist; Thu, 4 Oct 2001 07:31:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EVNML012319
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:31:23 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f94EVKq03956;
	Thu, 4 Oct 2001 16:31:20 +0200 (MET DST)
Date: Thu, 4 Oct 2001 16:26:32 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] AAA keys design comment
To: Pat Calhoun <pcalhoun@diameter.org>
Cc: mobile-ip@sunroof.eng.sun.com,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>, mat@cisco.com
In-Reply-To: "Your message with ID" <20011002081304.O26914@charizard.diameter.org>
Message-ID: <Roam.SIMC.2.0.6.1002205592.5384.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> right, but the AAA is in constant contact with the HAs. So when the
> AAA does the HA selection, assuming this is requested, then it would
> most likely pick one that has been responding to watchdog messages.

Is this notion of "watchdog messages" specified in 
draft-ietf-aaa-diameter-mobileip-07.txt or somewhere else?

I didn't see any mention of it in the above draft.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 10:37:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14514
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 10:37:34 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07218;
	Thu, 4 Oct 2001 08:36:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29478;
	Thu, 4 Oct 2001 07:36:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94Ea2ML012396
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:36:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94Ea2qG012395
	for mobile-ip-dist; Thu, 4 Oct 2001 07:36:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EZwML012388
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:35:58 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29366;
	Thu, 4 Oct 2001 07:35:59 -0700 (PDT)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01654;
	Thu, 4 Oct 2001 07:35:47 -0700 (PDT)
Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA23628;
	Thu, 4 Oct 2001 16:36:09 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>,
        "Pat Calhoun" <pcalhoun@diameter.org>
Cc: <mobile-ip@sunroof.eng.sun.com>, <mat@cisco.com>
Subject: RE: [mobile-ip] AAA keys design comment
Date: Thu, 4 Oct 2001 16:36:41 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKMEKADHAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.1002205592.5384.nordmark@bebop.france>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

the watchdog mechanism is described in draft-ietf-diameter-07.txt

/Fredrik

>-----Original Message-----
>From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
>Sent: den 4 oktober 2001 16:27
>To: Pat Calhoun
>Cc: mobile-ip@sunroof.eng.sun.com; Fredrik Johansson; mat@cisco.com
>Subject: Re: [mobile-ip] AAA keys design comment
>
>
>> right, but the AAA is in constant contact with the HAs. So when the
>> AAA does the HA selection, assuming this is requested, then it would
>> most likely pick one that has been responding to watchdog messages.
>
>Is this notion of "watchdog messages" specified in 
>draft-ietf-aaa-diameter-mobileip-07.txt or somewhere else?
>
>I didn't see any mention of it in the above draft.
>
>  Erik


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 10:40:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14662
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 10:40:45 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06572;
	Thu, 4 Oct 2001 07:39:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00118;
	Thu, 4 Oct 2001 07:38:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94Ec2ML012432
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:38:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94Ec2Da012431
	for mobile-ip-dist; Thu, 4 Oct 2001 07:38:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EbvML012421
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:37:58 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f94Ebrq05251;
	Thu, 4 Oct 2001 16:37:53 +0200 (MET DST)
Date: Thu, 4 Oct 2001 16:33:05 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: RE: [mobile-ip] Concerns/comments for aaa-keys and gen-key
To: Christopher.Carroll@VerizonWireless.com
Cc: Erik.Nordmark@eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        FlynnGe@HQ.VerizonWireless.com
In-Reply-To: "Your message with ID" <43E8CCEAF148D211854C00805FA72E5808318FD1@rhqnneex1.corp.bam.com>
Message-ID: <Roam.SIMC.2.0.6.1002205985.27432.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> We critically need a method of distributing the MN-HA key (and MN-FA key)
> based on the root MN-AAA key.  The current proposal satisfies that need and
> we accept the associated risks/vulnerabilities involved.  I hope you realize
> that MIPv4 (or MIPv6) is only one component in a complete information system
> with security mechanisms below (air-link) and above (application layer).
> The IETF does not have to boil the ocean by addressing every potential
> security concern within MIPv4.  

I hope nobody in the IETF is trying to boil the ocean.
But if the IETF wants to promote quality protocols we must care about
the interaction of Mobile IPv4 and Diameter since that is something
that the IETF is working on. Assuming that somebody else will solve
that problem would be a bit irresponsible.
Of course, we could have the mobileip-aaa-keys draft refer to an
abstract secure AAA service yet have enough detail that MN, FA, and HA
implementors can implement from the spec as a way of avoiding the immediate
issues, but Pat Calhoun doesn't want to do this. I haven't heard any comments
on that issue from anybody else.

I think I asked for a somewhat technical clarification on a statement 
you made in an earlier message and I haven't seen a response.

> You said:
> > I do recognize that other implementations of MIPv4 will require more
> > inherent security compliance (architecturally built-in SA establishment
> > schemes) because most users/system operators will not have the security
> > expertise/resources of large service providers.  I recommend that a separate
> > procedure/protocol be developed to satisfy this requirement without delaying
> > the implementation of the existing scheme.
> 
> There are subtly but importantly different interpretatiosn of what
> you say above. Let me restate and see if you agree with either one of these:
>  We know that the IETF protocols and mechanisms for securing the
> communication
>  between FA, AAA*, and HA will not satisfy the security requirements for
>  3G wireless use. But don't worry because we will use other security
> protocols
>  to make sure we get adequate protection.
>  We do need the aaa-key and related IETF documents to move forward in the 
>  IETF so that we can get adequate protection for the communication 
>  involving the MN.
> 
> or
> 
>  For other reasons we will be using non-IETF standard mechanisms for securing
>  the communication between FA, AAA*, and HA thus we do not care
>  (and perhaps also "have not analysed") the security that the internet
> drafts 
>  propose to add for the communication between FA, AAA*, and HA.
>  We do need the aaa-key and related IETF documents to move forward in the 
>  IETF so that we can get adequate protection for the communication 
>  involving the MN.
> 
> Does either of the above get close to being a restatement of what you said
> in the paragraphs above?

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 10:57:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15109
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 10:57:03 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23813;
	Thu, 4 Oct 2001 08:55:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03304;
	Thu, 4 Oct 2001 07:55:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EsuML012603
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:54:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94EsuGn012602
	for mobile-ip-dist; Thu, 4 Oct 2001 07:54:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EspML012595
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:54:52 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f94Esmq07905;
	Thu, 4 Oct 2001 16:54:48 +0200 (MET DST)
Date: Thu, 4 Oct 2001 16:50:00 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: RE: [mobile-ip] AAA keys design comment
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        Pat Calhoun <pcalhoun@diameter.org>, mobile-ip@sunroof.eng.sun.com,
        mat@cisco.com
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKMEKADHAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.1002207000.10184.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> the watchdog mechanism is described in draft-ietf-diameter-07.txt

draft-ietf-aaa-diameter-07.txt doesn't actually seem to have any
text that describes when watchdog request and reply should and/or
must be used.

In any case, draft-ietf-aaa-diameter-mobileip-07.txt doesn't talk at all
about watchdog. If the intent is that all FA/AAAF and AAAH/HA relationships
keep an open diameter transport that exchanges watchdog messages it seems
to be like it would make sense to document that in that draft.

Or is the unstated assumption that a FA and HA implement all of the diameter
protocol (as opposed to the parts that are explicitly listed in
diameter-mobileip)?

  Erik




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 11:00:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15355
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 11:00:29 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27240;
	Thu, 4 Oct 2001 08:59:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04556;
	Thu, 4 Oct 2001 07:59:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94Ex0ML012675
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:59:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94EwxiN012674
	for mobile-ip-dist; Thu, 4 Oct 2001 07:58:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EwuML012667
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:58:56 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03072
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:58:57 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12208
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 07:58:57 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f94EwlL22303;
	Thu, 4 Oct 2001 16:58:47 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id QAA21954; Thu, 4 Oct 2001 16:58:46 +0200
Message-ID: <3BBC7895.B9AFB445@era.ericsson.se>
Date: Thu, 04 Oct 2001 16:56:21 +0200
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
References: <200110041209.f94C9MD18571@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Francis Dupont wrote:
> 
>    As you wrote in your mail, our implementation can handle the SA
>    only for BU and BA which I call MIP6 SA. I modified the IPsec.
>    I assigned new protocol number for MIP6 binding messages. This
>    number is not used as the normal protocol number and it is just magic
>    number for IPsec selectors.
>    The MIP6 protocol number indicates that the SA is established for
>    MIP6 BU and BA.
> 
> => I used the same kind of trick (the destination option processing
> was modified and special selector is the destination option header code).
> My code should be very similar (same platform and problem) but
> I did't implement the sending side of piggybacking.

I guess I should talk for Ericsson's MIP6 implementation in reply to
Erik's request:

First release (-09) of our code had piggybacking knob (on/off) on
sending side. No IPsec.

Second release (-13) had thrown piggybacking out to simplify the code.
Receiving is supported, though. IPsec support required DOI "any", e.g.
no special SA for MIP6 available.

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 11:32:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16528
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 11:32:01 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03371;
	Thu, 4 Oct 2001 08:30:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10846;
	Thu, 4 Oct 2001 08:25:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94FOJML012889
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 08:24:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94FOJ1U012888
	for mobile-ip-dist; Thu, 4 Oct 2001 08:24:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94FOGML012881
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 08:24:16 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07932;
	Thu, 4 Oct 2001 08:24:17 -0700 (PDT)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28557;
	Thu, 4 Oct 2001 09:25:20 -0600 (MDT)
Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA25071;
	Thu, 4 Oct 2001 17:24:37 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
Cc: "Pat Calhoun" <pcalhoun@diameter.org>, <mobile-ip@sunroof.eng.sun.com>,
        <mat@cisco.com>
Subject: RE: [mobile-ip] AAA keys design comment
Date: Thu, 4 Oct 2001 17:25:09 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKOEKDDHAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.1002207000.10184.nordmark@bebop.france>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>
>> the watchdog mechanism is described in draft-ietf-diameter-07.txt
>
>draft-ietf-aaa-diameter-07.txt doesn't actually seem to have any
>text that describes when watchdog request and reply should and/or
>must be used.

section 5.5  Transport Failure Detection
explains how the watchdog mechanism is used

>
>In any case, draft-ietf-aaa-diameter-mobileip-07.txt doesn't talk at all
>about watchdog. If the intent is that all FA/AAAF and AAAH/HA relationships
>keep an open diameter transport that exchanges watchdog messages it seems
>to be like it would make sense to document that in that draft.

all diameter peer must implement the base protocol, i.e. the diameter part
in the FA and HA must conform to the base protocol, thus implement the
watchdog
alg.

/Fredrik

>
>Or is the unstated assumption that a FA and HA implement all of
>the diameter
>protocol (as opposed to the parts that are explicitly listed in
>diameter-mobileip)?
>
>  Erik
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 11:59:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17260
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 11:59:40 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23454;
	Thu, 4 Oct 2001 09:58:55 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14850;
	Thu, 4 Oct 2001 08:58:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94FveML013028
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 08:57:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94Fve0O013027
	for mobile-ip-dist; Thu, 4 Oct 2001 08:57:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94FvbML013020
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 08:57:37 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14414
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 08:57:38 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21809
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 09:57:26 -0600 (MDT)
Received: from Intergalactic (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 13E9862D35
	for <mobile-ip@sunroof.eng.sun.com>; Fri,  5 Oct 2001 00:57:34 +0900 (JST)
Date: Fri, 05 Oct 2001 00:56:58 +0900
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
In-Reply-To: <m3bsjn23cd.fsf@test9.crm.mot.com>
References: <20011004122826.56EA.RYUJI@sfc.wide.ad.jp> <m3bsjn23cd.fsf@test9.crm.mot.com>
Message-Id: <20011005005015.6C7B.RYUJI@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Alex.


> I would like to update my list of publicly available Mobile IPv6
> implementations and it seems that yours is new.  Is the code available
> (the neo.sfc web page says source code soon)?  What is its relation
> with Ericsson's Mobile IPv6 code in KAME?

Yes our code is available, but we did not prepare the web page yet...
Please visit my HP, i put the MIP6 patch on my HP temporary.
http://www.sfc.wide.ad.jp/~ryuji/research.html

Unfortunately, the patch is a little bit older (connectathon version, i
guess) and we don't have enough document, but we will deliver newest
code on December. please check neo.sfc. web at that time.

If you have question or interest, please contact with
mip6@sfc.wide.ad.jp

There is no relation with Ericssons MIP6, 
I implemented whole MIP6 by myself.

regards,
ryuji


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 12:06:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17432
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 12:06:18 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23031;
	Thu, 4 Oct 2001 09:05:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15673;
	Thu, 4 Oct 2001 09:01:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94G0LML013067
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 09:00:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94G0LJ6013066
	for mobile-ip-dist; Thu, 4 Oct 2001 09:00:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94G0GML013059
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 09:00:17 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f94G01q15892;
	Thu, 4 Oct 2001 18:00:02 +0200 (MET DST)
Date: Thu, 4 Oct 2001 17:55:08 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: RE: [mobile-ip] AAA keys design comment
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        Pat Calhoun <pcalhoun@diameter.org>, mobile-ip@sunroof.eng.sun.com,
        mat@cisco.com
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKOEKDDHAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.1002210908.22739.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> >
> >> the watchdog mechanism is described in draft-ietf-diameter-07.txt
> >
> >draft-ietf-aaa-diameter-07.txt doesn't actually seem to have any
> >text that describes when watchdog request and reply should and/or
> >must be used.
> 
> section 5.5  Transport Failure Detection
> explains how the watchdog mechanism is used

Yes, but it doesn't say 
1) that it MUST be used (it uses "recommended" which
   might refer to RFC 2119 per section 1.2 but RFC 2119 only defined
   the upper case "RECOMMENDED"), and
2) section 5.1 and draft-ietf-aaa-diameter-mobileip doesn't say when peer
   connections SHOULD or MUST exist.

In fact 5.1 is quite loose: 
  5.1  Peer Connections

   Although a Diameter node may have many possible peers that it is able
   to communicate with, it may not be economical to have an established
   connection to all of them. At a minimum, a Diameter node SHOULD have
   an established connection with a primary and secondary peer, and MAY
   have additional connections, if it is deemed necessary.

IMHO this must be documented more clearly so that folks can implement
the intent.

> >In any case, draft-ietf-aaa-diameter-mobileip-07.txt doesn't talk at all
> >about watchdog. If the intent is that all FA/AAAF and AAAH/HA relationships
> >keep an open diameter transport that exchanges watchdog messages it seems
> >to be like it would make sense to document that in that draft.
> 
> all diameter peer must implement the base protocol, i.e. the diameter part
> in the FA and HA must conform to the base protocol, thus implement the
> watchdog
> alg.

This must be stated more clearly in diameter-mobileip.

   Erik

> >
> >Or is the unstated assumption that a FA and HA implement all of
> >the diameter
> >protocol (as opposed to the parts that are explicitly listed in
> >diameter-mobileip)?
> >
> >  Erik
> >
> 




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 12:14:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17659
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 12:14:13 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05223;
	Thu, 4 Oct 2001 10:11:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18691;
	Thu, 4 Oct 2001 09:11:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94GARML013175
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 09:10:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94GAR5W013174
	for mobile-ip-dist; Thu, 4 Oct 2001 09:10:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94GAOML013167
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 09:10:24 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22057
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 09:10:26 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03911
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 10:10:05 -0600 (MDT)
Received: from Intergalactic (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP
	id 3AA6862D0A; Fri,  5 Oct 2001 01:10:14 +0900 (JST)
Date: Fri, 05 Oct 2001 01:09:37 +0900
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
Cc: mip6@sfc.wide.ad.jp
In-Reply-To: <20011005005015.6C7B.RYUJI@sfc.wide.ad.jp>
References: <m3bsjn23cd.fsf@test9.crm.mot.com> <20011005005015.6C7B.RYUJI@sfc.wide.ad.jp>
Message-Id: <20011005010239.D44A.RYUJI@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

One more news about our MIP6.

We extended mip6 draft to support multiple network interfaces.
Our MIP6 can handle multiple network interfaces with single home address.

For instance, you can use a home address with wireless LAN and ethernet.
This idea is a kind of heterogeneous handover, if one network interface
(if1) goes does, MIP6 switch the all the flow which went through the
interface(if1) to another network interface (if2,if3, whatever).

If you are interested in this, please ask me more. I have evaluation of
the our original idea and have "english paper" for this :) 
But this paper is under submission to the conference, I can not post it
to MIP6 ML.

thanks
ryuji

> Hi Alex.
> 
> 
> > I would like to update my list of publicly available Mobile IPv6
> > implementations and it seems that yours is new.  Is the code available
> > (the neo.sfc web page says source code soon)?  What is its relation
> > with Ericsson's Mobile IPv6 code in KAME?
> 
> Yes our code is available, but we did not prepare the web page yet...
> Please visit my HP, i put the MIP6 patch on my HP temporary.
> http://www.sfc.wide.ad.jp/~ryuji/research.html
> 
> Unfortunately, the patch is a little bit older (connectathon version, i
> guess) and we don't have enough document, but we will deliver newest
> code on December. please check neo.sfc. web at that time.
> 
> If you have question or interest, please contact with
> mip6@sfc.wide.ad.jp
> 
> There is no relation with Ericssons MIP6, 
> I implemented whole MIP6 by myself.
> 
> regards,
> ryuji




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 14:24:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21390
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 14:24:58 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07281;
	Thu, 4 Oct 2001 11:23:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00831;
	Thu, 4 Oct 2001 11:22:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94ILbML013762
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 11:21:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94ILaIZ013761
	for mobile-ip-dist; Thu, 4 Oct 2001 11:21:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94ILXML013754
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 11:21:33 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01754
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 11:21:34 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01911
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 11:21:34 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA12039;
	Thu, 4 Oct 2001 11:21:30 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f94ILUm15379;
	Thu, 4 Oct 2001 11:21:30 -0700
X-mProtect:  Thu, 4 Oct 2001 11:21:30 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdCr7Hks; Thu, 04 Oct 2001 11:21:28 PDT
Message-ID: <3BBCA8A7.C6D6231C@iprg.nokia.com>
Date: Thu, 04 Oct 2001 11:21:27 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED02@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham,

> "Hesham Soliman (EPA)" wrote:
> 
>              Our MIP6 waits default 1 sec (configurable) for some
>      piggybacked data before sending BU.
> 
>      => Ok but 1 sec is probably not acceptable for TCP or real time
>      apps.
>      But that's an implementation issue I guess.
>      Hesham
> 

the BU is delayed by 1 sec and not the data packets. If no data 
appears within one sec, the BU is sent in a separate packet.

Vijay


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct  4 16:05:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24161
	for <mobileip-archive@odin.ietf.org>; Thu, 4 Oct 2001 16:05:18 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00155;
	Thu, 4 Oct 2001 14:04:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24581;
	Thu, 4 Oct 2001 13:04:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94K2wML014061
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 4 Oct 2001 13:02:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94K2vtq014060
	for mobile-ip-dist; Thu, 4 Oct 2001 13:02:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94K2sML014053
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 13:02:54 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24218
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 13:02:54 -0700 (PDT)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25791
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 4 Oct 2001 13:02:53 -0700 (PDT)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09XNSS>; Thu, 4 Oct 2001 16:01:51 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA70@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject:  [mobile-ip] IESG comments to MIP v6 draft
Date: Thu, 4 Oct 2001 16:01:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Does anyone have the comments from IESG to MIP v6 draft, i.e. from the last
review?
I would appreciate it if someone would forward it to me via e-mail. Thanks.

-Sharif.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct  5 04:37:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17145
	for <mobileip-archive@odin.ietf.org>; Fri, 5 Oct 2001 04:37:28 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20531;
	Fri, 5 Oct 2001 02:36:44 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21752;
	Fri, 5 Oct 2001 01:36:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f958ZPML015158
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 5 Oct 2001 01:35:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f958ZPOx015157
	for mobile-ip-dist; Fri, 5 Oct 2001 01:35:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f958ZLML015150
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 01:35:21 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23251
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 01:35:25 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22196
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 01:35:24 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f958ZKO10898;
	Fri, 5 Oct 2001 10:35:20 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA09127;
	Fri, 5 Oct 2001 10:35:21 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f958ZJD21331;
	Fri, 5 Oct 2001 10:35:19 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
cc: mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15 
In-reply-to: Your message of Fri, 05 Oct 2001 01:09:37 +0900.
             <20011005010239.D44A.RYUJI@sfc.wide.ad.jp> 
Date: Fri, 05 Oct 2001 10:35:19 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   We extended mip6 draft to support multiple network interfaces.
   Our MIP6 can handle multiple network interfaces with single home address.
   
=> this is fine (multiple network interface support is an essential
function of mobility) but I don't understand why you believed the
Mobile IPv6 draft needed to be extended.
BTW I implemented this too before wireless LAN support, movement detection
is very easy when drivers are fixed in order to signal up/down events.
The only issue is to manage cases where there are no or two usable
(i.e. up) interfaces at the same time (both are a bit funny).

   If you are interested in this, please ask me more. I have evaluation of
   the our original idea and have "english paper" for this :) 
   But this paper is under submission to the conference, I can not post it
   to MIP6 ML.
   
=> please !

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct  5 10:12:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22619
	for <mobileip-archive@odin.ietf.org>; Fri, 5 Oct 2001 10:12:11 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08291;
	Fri, 5 Oct 2001 07:11:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00423;
	Fri, 5 Oct 2001 07:11:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95EAIML015535
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 5 Oct 2001 07:10:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f95EAI9B015534
	for mobile-ip-dist; Fri, 5 Oct 2001 07:10:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95EAEML015527
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 07:10:14 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29489
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 07:10:15 -0700 (PDT)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16043
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 07:10:14 -0700 (PDT)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21)
	id <TYNAN6L4>; Fri, 5 Oct 2001 10:08:00 -0400
Message-ID: <CD8355C7E19ED411BD5F00508BB0D19D6981E5@megisto-sql1.megisto.com>
From: Phil Roberts <PRoberts@MEGISTO.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
Date: Fri, 5 Oct 2001 10:07:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi folks,

    this is a working group last call on the threat model and security
requirements
for Mobile IP v6 draft.  The intention is to publish this document as an
informational
RFC.  Please post comments on this document to the mobile ip mailing list.

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
.txt

Last call expires Oct 19, 2001.

Phil and Raj


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct  5 21:08:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04959
	for <mobileip-archive@odin.ietf.org>; Fri, 5 Oct 2001 21:08:15 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11937;
	Fri, 5 Oct 2001 19:07:26 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13471;
	Fri, 5 Oct 2001 18:07:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9616QML017094
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 5 Oct 2001 18:06:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9616QNN017093
	for mobile-ip-dist; Fri, 5 Oct 2001 18:06:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9616MML017086
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 18:06:23 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24663
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 18:06:24 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA26021
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 19:07:30 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9616au28407
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 18:06:36 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABG00415;
	Fri, 5 Oct 2001 18:06:22 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA04415; Fri, 5 Oct 2001 18:06:21 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15294.22797.712056.249508@thomasm-u1.cisco.com>
Date: Fri, 5 Oct 2001 18:06:21 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <697DAA22C5004B4596E033803A7CEF441E87B3@daebe007.NOE.Nokia.com>
References: <697DAA22C5004B4596E033803A7CEF441E87B3@daebe007.NOE.Nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Patil Basavaraj (NET/Dallas) writes:

  [about relegating IPsec to low priority: ]

 >    (I am leaving the MN-HA SA out or the moment).

   Why?

   An attack against the MN/HA security would be
   far more catastrophic than the MN/CN. There is
   absolutely no reason why we should not have 
   strong authentication for this security
   association, and it should be a *mandatory*
   part of any compliant MIPv6 implementation.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct  6 01:57:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12160
	for <mobileip-archive@odin.ietf.org>; Sat, 6 Oct 2001 01:57:44 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15198;
	Fri, 5 Oct 2001 23:57:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA12082;
	Fri, 5 Oct 2001 22:56:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f965toML017413
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 5 Oct 2001 22:55:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f965tol0017412
	for mobile-ip-dist; Fri, 5 Oct 2001 22:55:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f965tlML017405
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 22:55:47 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA12157
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 22:55:49 -0700 (PDT)
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05865
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 5 Oct 2001 22:55:34 -0700 (PDT)
Received: from sooguan ([172.16.3.160])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id NAA13863
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 13:54:17 +0800 (SGT)
Message-ID: <005901c14e2c$2912a5a0$a00310ac@cwc.nus.edu.sg>
From: "Eng Soo Guan" <engsg@cwc.nus.edu.sg>
To: <mobile-ip@sunroof.eng.sun.com>
References: <m3bsjn23cd.fsf@test9.crm.mot.com> <20011005005015.6C7B.RYUJI@sfc.wide.ad.jp> <20011005010239.D44A.RYUJI@sfc.wide.ad.jp>
Subject: Re: [mobile-ip] Draft 15
Date: Sat, 6 Oct 2001 14:00:10 +0800
Organization: CWC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Dear Ryuji,

I am very interested in your work, especailly the part on multiple network
interface support. May I have a copy of your English report?

Warmest regards.

SG
Eng Soo Guan
R&D Engineer (Software Lab)
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
Tel (65) 8709330
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- Original Message -----
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <mip6@sfc.wide.ad.jp>
Sent: Friday, October 05, 2001 12:09 AM
Subject: Re: [mobile-ip] Draft 15


> One more news about our MIP6.
>
> We extended mip6 draft to support multiple network interfaces.
> Our MIP6 can handle multiple network interfaces with single home address.
>
> For instance, you can use a home address with wireless LAN and ethernet.
> This idea is a kind of heterogeneous handover, if one network interface
> (if1) goes does, MIP6 switch the all the flow which went through the
> interface(if1) to another network interface (if2,if3, whatever).
>
> If you are interested in this, please ask me more. I have evaluation of
> the our original idea and have "english paper" for this :)
> But this paper is under submission to the conference, I can not post it
> to MIP6 ML.
>
> thanks
> ryuji
>



From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct  6 07:41:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25160
	for <mobileip-archive@odin.ietf.org>; Sat, 6 Oct 2001 07:41:22 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14405;
	Sat, 6 Oct 2001 04:40:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22675;
	Sat, 6 Oct 2001 04:40:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f96BdvML017694
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sat, 6 Oct 2001 04:39:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f96BdvPr017693
	for mobile-ip-dist; Sat, 6 Oct 2001 04:39:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f96BdrML017686
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 04:39:53 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22646
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 04:39:55 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22592
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 04:39:55 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA27643 for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 04:39:54 -0700 (MST)]
Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA06942 for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 04:39:54 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Sat, 6 Oct 2001 04:39:52 -0700
Received: from test9.crm.mot.com.crm.mot.com (zfr24-sr2-20.corp.mot.com [140.101.145.20])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 664D52ED2F; Sat,  6 Oct 2001 13:36:01 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
References: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 05 Oct 2001 22:27:41 +0200
In-Reply-To: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr>
Message-Id: <m34rpdhlxe.fsf@test9.crm.mot.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 24
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
>    We extended mip6 draft to support multiple network interfaces.
>    Our MIP6 can handle multiple network interfaces with single home address.
>    
> => this is fine (multiple network interface support is an essential
> function of mobility) but I don't understand why you believed the
> Mobile IPv6 draft needed to be extended.

Ryuji probably means several interfaces each having its own home
address?  Something related to multihoming, load-balancing,
optimizations?

>    If you are interested in this, please ask me more. I have evaluation of
>    the our original idea and have "english paper" for this :) 
>    But this paper is under submission to the conference, I can not post it
>    to MIP6 ML.

Yes, I would like to have a look at it.  If your paper is approved for
publication, you probably can send me title/author/conference so that
I include it in my bibliography on IP mobility.

Thank you,

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct  6 11:52:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27674
	for <mobileip-archive@odin.ietf.org>; Sat, 6 Oct 2001 11:52:30 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17904;
	Sat, 6 Oct 2001 09:51:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12397;
	Sat, 6 Oct 2001 08:51:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f96FoaML017955
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sat, 6 Oct 2001 08:50:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f96FoZsT017954
	for mobile-ip-dist; Sat, 6 Oct 2001 08:50:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f96FoWML017947
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 08:50:32 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12276
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 08:50:34 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17702
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 09:50:22 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f96FoVH18196
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 17:50:31 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA24408
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 17:50:31 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f96FoVD27281
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 6 Oct 2001 17:50:31 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110061550.f96FoVD27281@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Fri, 05 Oct 2001 18:06:21 PDT.
             <15294.22797.712056.249508@thomasm-u1.cisco.com> 
Date: Sat, 06 Oct 2001 17:50:31 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   Patil Basavaraj (NET/Dallas) writes:
   
     [about relegating IPsec to low priority: ]
   
    >    (I am leaving the MN-HA SA out or the moment).
   
(from  Michael Thomas <mat@cisco.com>)

      Why?
   
=> because this is easy (see assumption 1 in the threat draft)

      An attack against the MN/HA security would be
      far more catastrophic than the MN/CN. There is
      absolutely no reason why we should not have 
      strong authentication for this security
      association, and it should be a *mandatory*
      part of any compliant MIPv6 implementation.
   
=> I agree but we have no global PKI problem is this case and
many solutions, for instance IPsec (this is a variant of the "road
warrior" case), AAA (even if Eric should not agree :-), etc.
(Note: the HA is the main one, not a transient HA in a previous visited
link).

Regards

Francis.Dupont@enst-bretagne.fr

PS: to attack the hard part first is courageous, you shouldn't complain (:-).



From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct  7 16:21:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25273
	for <mobileip-archive@lists.ietf.org>; Sun, 7 Oct 2001 16:21:51 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28191;
	Sun, 7 Oct 2001 14:20:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29024;
	Sun, 7 Oct 2001 13:19:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f97KI9ML019350
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 7 Oct 2001 13:18:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f97KI9DT019349
	for mobile-ip-dist; Sun, 7 Oct 2001 13:18:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f97KI5ML019342
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 13:18:05 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01570
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 13:18:06 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27515
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 14:17:56 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f97KHku17361;
	Sun, 7 Oct 2001 13:17:46 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABG06738;
	Sun, 7 Oct 2001 13:17:31 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA04921; Sun, 7 Oct 2001 13:17:31 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15296.47195.273931.726242@thomasm-u1.cisco.com>
Date: Sun, 7 Oct 2001 13:17:31 -0700 (PDT)
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
Cc: <mobile-ip@sunroof.eng.sun.com>, <mat@cisco.com>
Subject: RE: [mobile-ip] AAA keys design comment
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKAEGHDHAA.fredrik.johansson@ipunplugged.com>
References: <15289.58848.663490.52928@thomasm-u1.cisco.com>
	<MJEMJBGGCLLDLFFAHLJKAEGHDHAA.fredrik.johansson@ipunplugged.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Fredrik Johansson writes:
 > >   of the telco. Second, it's not at all clear to
 > >   me that AAA round trip will necessarily be faster
 > >   since there is no reason to believe that AAAh
 > >   and HA will be topologically close to each other.
 > 
 > it's not only the roundtrip over the air that can be
 > more expensive, it's also between the home and foreign
 > network (when the HA is allocated in the home network).

   I don't see that there's any reason to believe
   that the distance from the AAAh and HA is going
   to be much better on average than the distance
   from FA and HA. AAA's are usually centralized so
   they can service many POP's. Also: since MIPv4
   requires dog leg routing, it seems pretty likely
   that you'd want to engineer the HA's to be topologically
   close to the MN when it initially registers to cut
   down on latency.

 > No, there is nothing that mandates a direct relationship
 > between AAAh and HA, it's enough that the AAAh has a 
 > relationship (either direct or via a broker) to the AAAf. 
 > The AAAf can then assign the HA and distribute keys in the
 > same way as is done for the keys needed for the FA (since 
 > the AAAh usually don't have a direct trust with the FAs)

   This isn't correct. There *must* be a relationship
   explicitly in the form of a authenticated and authorized
   exchange of the AAA generated keys to the home agent.
   If there weren't, the entire exchange would be insecure.
   There is also implicitly a business arrangement as
   well, and this method of pushing keys pretty much 
   precludes me running my own home agent since Visa
   probably isn't going to want to have scale to anybody
   who wants to become a HA provider.

	     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct  7 17:59:14 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25614
	for <mobileip-archive@lists.ietf.org>; Sun, 7 Oct 2001 17:59:13 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15760;
	Sun, 7 Oct 2001 14:58:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16250;
	Sun, 7 Oct 2001 14:57:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f97LuCML019508
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 7 Oct 2001 14:56:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f97LuC6l019507
	for mobile-ip-dist; Sun, 7 Oct 2001 14:56:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f97Lu9ML019500
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 14:56:09 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10886
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 14:56:09 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA06253
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 14:56:09 -0700 (PDT)
Received: (qmail 30180 invoked by uid 500); 7 Oct 2001 21:41:33 -0000
Date: Sun, 7 Oct 2001 14:41:33 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Pat Calhoun <pcalhoun@diameter.org>, mobile-ip@sunroof.eng.sun.com,
        mat@cisco.com
Subject: Re: [mobile-ip] AAA keys design comment
Message-ID: <20011007144133.B30157@charizard.diameter.org>
References: <MJEMJBGGCLLDLFFAHLJKOEKDDHAA.fredrik.johansson@ipunplugged.com> <Roam.SIMC.2.0.6.1002210908.22739.nordmark@bebop.france>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Roam.SIMC.2.0.6.1002210908.22739.nordmark@bebop.france>; from Erik.Nordmark@eng.sun.com on Thu, Oct 04, 2001 at 05:55:08PM +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

All of the watchdog (connection reliability text) was pulled from the most
recent draft, and to be included in the next revision of the aaa transport
draft.

This was done at the request of the chair(s) and IESG members.

PatC
On Thu, Oct 04, 2001 at 05:55:08PM +0200, Erik Nordmark wrote:
> > >
> > >> the watchdog mechanism is described in draft-ietf-diameter-07.txt
> > >
> > >draft-ietf-aaa-diameter-07.txt doesn't actually seem to have any
> > >text that describes when watchdog request and reply should and/or
> > >must be used.
> > 
> > section 5.5  Transport Failure Detection
> > explains how the watchdog mechanism is used
> 
> Yes, but it doesn't say 
> 1) that it MUST be used (it uses "recommended" which
>    might refer to RFC 2119 per section 1.2 but RFC 2119 only defined
>    the upper case "RECOMMENDED"), and
> 2) section 5.1 and draft-ietf-aaa-diameter-mobileip doesn't say when peer
>    connections SHOULD or MUST exist.
> 
> In fact 5.1 is quite loose: 
>   5.1  Peer Connections
> 
>    Although a Diameter node may have many possible peers that it is able
>    to communicate with, it may not be economical to have an established
>    connection to all of them. At a minimum, a Diameter node SHOULD have
>    an established connection with a primary and secondary peer, and MAY
>    have additional connections, if it is deemed necessary.
> 
> IMHO this must be documented more clearly so that folks can implement
> the intent.
> 
> > >In any case, draft-ietf-aaa-diameter-mobileip-07.txt doesn't talk at all
> > >about watchdog. If the intent is that all FA/AAAF and AAAH/HA relationships
> > >keep an open diameter transport that exchanges watchdog messages it seems
> > >to be like it would make sense to document that in that draft.
> > 
> > all diameter peer must implement the base protocol, i.e. the diameter part
> > in the FA and HA must conform to the base protocol, thus implement the
> > watchdog
> > alg.
> 
> This must be stated more clearly in diameter-mobileip.
> 
>    Erik
> 
> > >
> > >Or is the unstated assumption that a FA and HA implement all of
> > >the diameter
> > >protocol (as opposed to the parts that are explicitly listed in
> > >diameter-mobileip)?
> > >
> > >  Erik
> > >
> > 
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct  7 18:12:04 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25740
	for <mobileip-archive@lists.ietf.org>; Sun, 7 Oct 2001 18:12:04 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16939;
	Sun, 7 Oct 2001 15:11:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17057;
	Sun, 7 Oct 2001 15:10:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f97MA9ML019606
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 7 Oct 2001 15:10:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f97MA9Yn019605
	for mobile-ip-dist; Sun, 7 Oct 2001 15:10:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f97MA5ML019598
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 15:10:05 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17014
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 15:10:06 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA18422
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 16:09:55 -0600 (MDT)
Received: (qmail 30299 invoked by uid 500); 7 Oct 2001 21:55:29 -0000
Date: Sun, 7 Oct 2001 14:55:29 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Cc: Christopher.Carroll@VerizonWireless.com, Erik.Nordmark@eng.sun.com,
        FlynnGe@HQ.VerizonWireless.com
Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key
Message-ID: <20011007145529.H30157@charizard.diameter.org>
References: <43E8CCEAF148D211854C00805FA72E5808318FD1@rhqnneex1.corp.bam.com> <Roam.SIMC.2.0.6.1002205985.27432.nordmark@bebop.france>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Roam.SIMC.2.0.6.1002205985.27432.nordmark@bebop.france>; from Erik.Nordmark@eng.sun.com on Thu, Oct 04, 2001 at 04:33:05PM +0200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, Oct 04, 2001 at 04:33:05PM +0200, Erik Nordmark wrote:
> > We critically need a method of distributing the MN-HA key (and MN-FA key)
> > based on the root MN-AAA key.  The current proposal satisfies that need and
> > we accept the associated risks/vulnerabilities involved.  I hope you realize
> > that MIPv4 (or MIPv6) is only one component in a complete information system
> > with security mechanisms below (air-link) and above (application layer).
> > The IETF does not have to boil the ocean by addressing every potential
> > security concern within MIPv4.  
> 
> I hope nobody in the IETF is trying to boil the ocean.
> But if the IETF wants to promote quality protocols we must care about
> the interaction of Mobile IPv4 and Diameter since that is something
> that the IETF is working on. Assuming that somebody else will solve
> that problem would be a bit irresponsible.
> Of course, we could have the mobileip-aaa-keys draft refer to an
> abstract secure AAA service yet have enough detail that MN, FA, and HA
> implementors can implement from the spec as a way of avoiding the immediate
> issues, but Pat Calhoun doesn't want to do this. I haven't heard any comments
> on that issue from anybody else.

don't think that's what I said. I was questioning whether this was
required. If it is, then it will be done.

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct  7 22:42:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29430
	for <mobileip-archive@odin.ietf.org>; Sun, 7 Oct 2001 22:42:03 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16347;
	Sun, 7 Oct 2001 20:41:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29774;
	Sun, 7 Oct 2001 19:41:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f982ejML019828
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 7 Oct 2001 19:40:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f982ejjB019827
	for mobile-ip-dist; Sun, 7 Oct 2001 19:40:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f982efML019820
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 19:40:42 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20411
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 19:40:42 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15941
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 20:40:31 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA00442
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 12:38:58 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA29722
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 12:40:06 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXJC77>; Mon, 8 Oct 2001 12:40:05 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED0E@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion 
Date: Mon, 8 Oct 2001 12:40:03 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14FA2.88AF7160"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C14FA2.88AF7160
Content-Type: text/plain



	At the risk of sounding like a broken record !
>    
>      [about relegating IPsec to low priority: ]
>    
>     >    (I am leaving the MN-HA SA out or the moment).
>    
> (from  Michael Thomas <mat@cisco.com>)
> 
>       Why?
>    
> => because this is easy (see assumption 1 in the threat draft)
> 
>       An attack against the MN/HA security would be
>       far more catastrophic than the MN/CN. There is
>       absolutely no reason why we should not have 
>       strong authentication for this security
>       association, and it should be a *mandatory*
>       part of any compliant MIPv6 implementation.
>    
> => I agree but we have no global PKI problem is this case and
> many solutions, for instance IPsec 
> 
	=> But are we talking about the "IKE IPsec" or the 
	"AH/ESP IPsec " ? 
	Please separate the 2 problems. For the former it is 
	well understood that we can not rely on IKE as the 
	only key exchange mechanism and solutions are 
	bein proposed. For the latter there are a zillion
	proposals to fix it and we have to pick one. 


	Regards,
	Hesham

------_=_NextPart_001_01C14FA2.88AF7160
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion </TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">At the risk of sounding like a broken record !</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp; [about relegating IPsec to low priority: ]</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp; (I am leaving the MN-HA SA out or the moment).</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">(from&nbsp; Michael Thomas &lt;mat@cisco.com&gt;)</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Why?</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">=&gt; because this is easy (see assumption 1 in the threat draft)</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An attack against the MN/HA security would be</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; far more catastrophic than the MN/CN. There is</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; absolutely no reason why we should not have </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; strong authentication for this security</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; association, and it should be a *mandatory*</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; part of any compliant MIPv6 implementation.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">=&gt; I agree but we have no global PKI problem is this case and</FONT>
<BR><FONT SIZE=2 FACE="Arial">many solutions, for instance IPsec</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; But are we talking about the &quot;IKE IPsec&quot; or the </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">&quot;AH/ESP IPsec &quot; ? </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Please separate the 2 problems. For the former it is </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">well understood that we can not rely on IKE as the </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">only key exchange mechanism and solutions are </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">bein proposed. For the latter there are a zillion</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">proposals to fix it and we have to pick one. </FONT>
</P>
<BR>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Regards,</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C14FA2.88AF7160--


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct  7 23:05:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29597
	for <mobileip-archive@odin.ietf.org>; Sun, 7 Oct 2001 23:05:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20901;
	Sun, 7 Oct 2001 20:04:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01312;
	Sun, 7 Oct 2001 20:04:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9833mML019968
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 7 Oct 2001 20:03:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9833muh019967
	for mobile-ip-dist; Sun, 7 Oct 2001 20:03:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9833jML019960
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 20:03:45 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01208
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 20:03:47 -0700 (PDT)
From: chunan.li@nokia.com
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26422
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 7 Oct 2001 21:04:54 -0600 (MDT)
Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9834If26772
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 06:04:18 +0300 (EET DST)
Received: from esebh12nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5677519bdfac158f26077@esvir06nok.ntc.nokia.com>;
 Mon, 8 Oct 2001 06:03:44 +0300
Received: by esebh12nok with Internet Mail Service (5.5.2652.78)
	id <4M5LJ9S8>; Mon, 8 Oct 2001 06:03:44 +0300
Message-ID: <F3768A6EA461D311A4BD0008C7735E5902710045@beeis01nok>
To: mobile-ip@sunroof.eng.sun.com
Cc: Basavaraj.Patil@nokia.com, PRoberts@MEGISTO.com
Subject: RE: [mobile-ip] Draft 15
Date: Mon, 8 Oct 2001 05:47:24 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hello

I can't download the new draft from
http://people.nokia.net/charlep/txt/mobilev6/mobilev6.txt. Could you please
send one copy to me?

Thanks!

Andy (ChunAn Li)
----------------------------------------------------------------------------
------
Advanced Internet Technologies Group
Communication Systems Lab of Nokia Research Center

E-mail: chunan.li@nokia.com
MP: +86 13601028331 Fax: +86 10 84222438


-----Original Message-----
From: ext Charles E. Perkins [mailto:charliep@iprg.nokia.com]
Sent: Tuesday, September 25, 2001 5:08 AM
To: Mobile IP Working Group
Cc: Basavaraj Patil (NTC/Dallas); Phil Roberts
Subject: [mobile-ip] Draft 15


Hello folks,

I have done a rough edit on revision 15 of Mobile IPv6.
It needs some proofreading.  There may still be some problems
left over because of eliminating the Mobile Router capability,
and the "Prefix Length" field of the Binding Update.  Also,
I am still puzzling over the e-mail about how a mobile node
should get the link-layer address of the home agent when it
returns home.

Here is the current draft:
	http://people.nokia.net/charlep/txt/mobilev6/mobilev6.txt



Here is a list of changes:

    -  Removed the Mobile Router Prefix Length Sub-Option
   
    -  Removed the Prefix Length field from the Binding Update.
   
    -  Reworded the specification so that the Home Agent now has to
       perform Duplicate Address Detection for the mobile node's address
       on all the prefixes for which the router is performing home agent
       service.
   
    -  Removed the section about Mobile Routers
   
    -  Added the Authentication Data Sub-option; reorganized the section
       about computing authentication data.
    
    -  Specified that the Home Agent lifetime is by default the same as
       the Router lifetime, in a Router Advertisement.
    
    -  Specified that Binding Updates with zero lifetime and the 'A' bit
       set should cause a Binding Acknowledgement to be sent back to the
       Source IP address of the Binding Update.

    -  Qualified the allowable times when a mobile node can send a
       Binding Update to a correspondent node

    -  Added text allowing the correspondent node to extend an existing
       Routing Header by also including the care-of address as the entry
       of a routing header to be visited immediately before the home
       address.  In this way, for instance, the mobile node can be an
       intermediate node of a path along the way to some other node.
   
    -  Removed the Home Address field from the Home Agent Address
       Discovery Request Message.
    
    -  Noted that ICMP Unreachable forms a potential mechanism by which
       a malicious node can cause a correspondent node to delete a valid
       entry from its Binding Cache.

    -  Specified that, when a router stops offering home agent services
       by turning off the 'H' flag, the mobile node has to delete the
       corresponding entry from its Home Agent list. 



I'll wait a bit longer before sending it, depending on current
mailing list discussion and any other comments that may be
contributed.  Surely there will be some other changes that have
to be made anyway, but it is possible to imagine that they will
be small ones.


Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 03:07:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15041
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 03:07:02 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04534;
	Mon, 8 Oct 2001 01:06:05 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19733;
	Mon, 8 Oct 2001 00:06:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9875GML020193
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 00:05:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9875Gqs020192
	for mobile-ip-dist; Mon, 8 Oct 2001 00:05:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9875CML020185
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 00:05:12 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08824
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 00:05:14 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27715
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 00:05:13 -0700 (PDT)
Received: from ban by muminmamman.lifix.fi with local (Exim 3.12 #1 (Debian))
	id 15qUTQ-0001MF-00
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 08 Oct 2001 10:05:12 +0300
Date: Mon, 8 Oct 2001 10:05:12 +0300
From: Bjorn Andersson <bjorn@lifix.fi>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
Message-ID: <20011008100512.A4602@lifix.fi>
Mail-Followup-To: Bjorn Andersson <bjorn@lifix.fi>,
	mobile-ip@sunroof.eng.sun.com
References: <F3768A6EA461D311A4BD0008C7735E5902710045@beeis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F3768A6EA461D311A4BD0008C7735E5902710045@beeis01nok>
User-Agent: Mutt/1.3.20i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, Oct 08 2001, at 05:47:24 +0300, chunan.li@nokia.com wrote:
> I can't download the new draft from
> http://people.nokia.net/charlep/txt/mobilev6/mobilev6.txt.

There is a typo in the URL (charlep -> charliep). The correct URL is:
http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt

  Bjorn

-- 
Bjorn Andersson <bjorn@lifix.fi>                       +358 50 341 2556
Lifix Systems Oy <http://www.lifix.fi/>                 PGP id 5AFC144B
Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 04:07:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16089
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 04:07:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA10799;
	Mon, 8 Oct 2001 01:07:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24556;
	Mon, 8 Oct 2001 01:07:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9885mML020329
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 01:05:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9885mnm020328
	for mobile-ip-dist; Mon, 8 Oct 2001 01:05:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9885fML020321
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 01:05:41 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19087
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 01:05:44 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04521
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 01:05:42 -0700 (PDT)
Received: from ban by muminmamman.lifix.fi with local (Exim 3.12 #1 (Debian))
	id 15qVPx-0001qg-00
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 08 Oct 2001 11:05:41 +0300
Date: Mon, 8 Oct 2001 11:05:41 +0300
From: Bjorn Andersson <bjorn@lifix.fi>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?
Message-ID: <20011008110541.B4602@lifix.fi>
Mail-Followup-To: Bjorn Andersson <bjorn@lifix.fi>,
	mobile-ip@sunroof.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.20i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

What is the current status of the Generalized NAI Extension draft?

Some questions about the draft:
- Is there any recommended Type number for the GNAI extension that can
  be (temporarly) used for e.g. interoperability testing?
- The GNAI extension in the MIER draft had a sub type for the Previous
  FA-NAI. Is anything similar planned for the GNAI draft? Having
  this would be useful in e.g. hierarchial and smooth handoff
  solutions.
- The draft states that the "extension may be carried by
  Registration Request and Reply messages". Why not allow them in
  agent advertisements also, so that the e.g. FAs can advertise
  their NAI? For example, draft-ietf-mobileip-reg-tunnel-05.txt
  uses the GNAIE in advertisements.

Regards,
Bjorn

-- 
Bjorn Andersson <bjorn@lifix.fi>                       +358 50 341 2556
Lifix Systems Oy <http://www.lifix.fi/>                 PGP id 5AFC144B
Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 05:24:36 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16690
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 05:24:35 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09414;
	Mon, 8 Oct 2001 02:23:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25471;
	Mon, 8 Oct 2001 02:23:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f989MQML020528
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 02:22:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f989MPJZ020527
	for mobile-ip-dist; Mon, 8 Oct 2001 02:22:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f989MLML020513
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 02:22:21 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01018
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 02:22:23 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22108
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 03:23:31 -0600 (MDT)
Received: from Intergalactic (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP
	id D93F25D01E; Mon,  8 Oct 2001 18:22:29 +0900 (JST)
Date: Mon, 08 Oct 2001 02:21:40 +0900
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
Cc: mip6@sfc.wide.ad.jp
In-Reply-To: <m34rpdhlxe.fsf@test9.crm.mot.com>
References: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr> <m34rpdhlxe.fsf@test9.crm.mot.com>
Message-Id: <20011008021342.3A96.RYUJI@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Mailer: Becky! ver. 2.00.03
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f989MMML020514
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hi Alex,

> Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
> >    We extended mip6 draft to support multiple network interfaces.
> >    Our MIP6 can handle multiple network interfaces with single home address.
> >    
> > => this is fine (multiple network interface support is an essential
> > function of mobility) but I don't understand why you believed the
> > Mobile IPv6 draft needed to be extended.
> 
> Ryuji probably means several interfaces each having its own home
> address?  Something related to multihoming, load-balancing,
> optimizations?

Yes, we assume the above stuff(multihoming, QoS, policy-routing) for
MIP6 operation. For the demand, we need to extend some of MIP6 operation. 

Since our MIPv6 is developing for automobile, so we need to provide the
global-connectivity, high Bandwidth, continuous communication by
supporting multiple network interface.Our MIP6 can handle even if two of
network interfaces are available (multihoming) 
Only one network interface is not enough for the situation of automobile,
because it moves so fast and move far and wide. 

After posting some mail to this ML, I asked my friends to setup HP for
our research. So it will come up soon. You will be able to find the link
from my HP.

> Yes, I would like to have a look at it.  If your paper is approved for
> publication, you probably can send me title/author/conference so that
> I include it in my bibliography on IP mobility.

Several people contacted for the paper before, so I will notify all when
my paper is approved, please wait until someday...
anyway, thanks for contacting me.

regards,
ryuji




From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 05:24:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16702
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 05:24:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09424;
	Mon, 8 Oct 2001 02:23:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25470;
	Mon, 8 Oct 2001 02:23:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f989MSML020531
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 02:22:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f989MSfd020530
	for mobile-ip-dist; Mon, 8 Oct 2001 02:22:28 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f989MOML020520
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 02:22:24 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25366
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 02:22:26 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11904
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 03:22:14 -0600 (MDT)
Received: from Intergalactic (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP
	id E358D5D022; Mon,  8 Oct 2001 18:22:30 +0900 (JST)
Date: Mon, 08 Oct 2001 02:21:41 +0900
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Draft 15
Cc: mip6@sfc.wide.ad.jp
In-Reply-To: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr>
References: <20011005010239.D44A.RYUJI@sfc.wide.ad.jp> <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr>
Message-Id: <20011008022016.3A99.RYUJI@sfc.wide.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 
Content-Transfer-Encoding: 7bit

Hi Francis

> => this is fine (multiple network interface support is an essential
> function of mobility) but I don't understand why you believed the
> Mobile IPv6 draft needed to be extended.
> BTW I implemented this too before wireless LAN support, movement detection
> is very easy when drivers are fixed in order to signal up/down events.

OK, It is easy to support only one or two interface for move detection,
I can put some code in device driver as trigger for movement detection.
We used to use L2 information for movement detection in MIPv4, but we
found that modifying every network driver is harder, i mean I can not
modify all the interface supported on BSD. 

We can use link status like up/down for ethernet and most of interfaces.
Wireless LAN has signal strength, but I thought signal strength is not
totally equal to link up/down information of ethernet. 
I think it is not easy to define how to handle L2 information. 
This is my question what's the link status for dial-up interface  (by modem )?

I proposed a system to handle layer 2 information for mobile computing.
The system named MIBsocket, this system is implemented as
message-passing socket between layers including userland, so you can
pass layer 2 information to IP layer through MIBsocket.
All information is defined by MIB based description. This system was implemented
on BSD-based system (only IPv4).

> The only issue is to manage cases where there are no or two usable
> (i.e. up) interfaces at the same time (both are a bit funny).

This funny situation is one of my research topic..If you can use many
interfaces simultaneously, you can get some advantages for the coverage
of network connectivity, load-balancing, bandwidth, QoS, whatelse.  

regards,
ryuji





>    If you are interested in this, please ask me more. I have evaluation of
>    the our original idea and have "english paper" for this :) 
>    But this paper is under submission to the conference, I can not post it
>    to MIP6 ML.
>    
> => please !
> 
> Thanks
> 
> Francis.Dupont@enst-bretagne.fr




From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 10:52:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22947
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 10:52:37 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16689;
	Mon, 8 Oct 2001 08:51:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22405;
	Mon, 8 Oct 2001 07:51:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98EoXML020937
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 07:50:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98EoWTe020936
	for mobile-ip-dist; Mon, 8 Oct 2001 07:50:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98EoTML020929
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 07:50:29 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22266
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 07:50:29 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15788
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:50:19 -0600 (MDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f98EorQ11415
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:50:53 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56782134b4ac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Mon, 8 Oct 2001 09:50:29 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 8 Oct 2001 09:50:29 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Mon, 8 Oct 2001 09:50:29 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E87E2@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] MIPv6 - Focus of the security discussion
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFOA0uDLJjgOrnyEdWBTABQi2X+DwCBUAtg
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 08 Oct 2001 14:50:29.0391 (UTC) FILETIME=[92ADD1F0:01C15008]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f98EoTML020930
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Michael Thomas [mat@cisco.com]wrote:
>
>Patil Basavaraj (NET/Dallas) writes:
>
>  [about relegating IPsec to low priority: ]
>
> >    (I am leaving the MN-HA SA out or the moment).
>
>   Why?
>
>   An attack against the MN/HA security would be
>   far more catastrophic than the MN/CN. There is
>   absolutely no reason why we should not have 
>   strong authentication for this security
>   association, and it should be a *mandatory*
>   part of any compliant MIPv6 implementation.
>
>	   Mike

Mike,

Completely agree with what you are saying and I did not mean to imply
that we should be ignoring the MN-HA security. 
Since the MN and HA share keys or certs or have other means of
establishing an SA, securing the BUs sent to the HA is considerably
easier. The MN->CN BUs are much more difficult to deal with and this
is what the IESG has expressed concerns about and what the WG sould be
focusing on.

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 11:12:04 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23340
	for <mobileip-archive@lists.ietf.org>; Mon, 8 Oct 2001 11:12:03 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05071;
	Mon, 8 Oct 2001 08:11:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10258;
	Mon, 8 Oct 2001 08:10:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98FA7ML021139
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:10:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98FA73Z021138
	for mobile-ip-dist; Mon, 8 Oct 2001 08:10:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98FA3ML021129
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:10:03 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02473
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:10:05 -0700 (PDT)
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23946
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:11:13 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98F9US29840
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 11:09:30 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 8 Oct 2001 10:09:18 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LVXLH>; Mon, 8 Oct 2001 10:09:36 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D42158B6@zrc2c014.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?
Date: Mon, 8 Oct 2001 10:09:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1500B.39FA6CA0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1500B.39FA6CA0
Content-Type: text/plain;
	charset="iso-8859-1"



-----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Monday, October 08, 2001 10:00 AM
To: mobile-ip
Cc: bjorn
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?


The GNAIE draft has completed WG last call. It is currently being
revised based on coments received from the IESG. A new version will be
made available this week. Also it goes back to the IESG after it is
announced for moving forward to RFC status.

Bjorn Andersson [bjorn@lifix.fi] wrote:
>What is the current status of the Generalized NAI Extension draft?
>
>Some questions about the draft:
>- Is there any recommended Type number for the GNAI extension that can
>  be (temporarly) used for e.g. interoperability testing?

Not at the moment. We are currently working with IANA and the IESG to
see if we can assign temporary numbers to extensions specified by WG
documents for interop testing. Will see what we can do while waiting
for the type number for GNAIE.

>- The GNAI extension in the MIER draft had a sub type for the Previous
>  FA-NAI. Is anything similar planned for the GNAI draft? Having
>  this would be useful in e.g. hierarchial and smooth handoff
>  solutions.

This has not been incorporated into the current GNAIE spec. And as you
are aware the MIER extension format itself has been included as a part
of 2002bis and hence the MIER I-D will be deprecated.

>- The draft states that the "extension may be carried by
>  Registration Request and Reply messages". Why not allow them in
>  agent advertisements also, so that the e.g. FAs can advertise
>  their NAI? For example, draft-ietf-mobileip-reg-tunnel-05.txt
>  uses the GNAIE in advertisements.

Not sure if the authors have thought of this or if they have any
reasons why it canot be sent in Agent Advts. MK, Pat? 

MK> I don't see any problem of adding a text to the draft to allow including
the GNAI extension into the AA

>
>Regards,
>Bjorn

Basavaraj


------_=_NextPart_001_01C1500B.39FA6CA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] Status of =
draft-ietf-mobileip-gnaie-04.txt?</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Patil Basavaraj (NET/Dallas) [<A =
HREF=3D"mailto:Basavaraj.Patil@nokia.com">mailto:Basavaraj.Patil@nokia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, October 08, 2001 10:00 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip</FONT>
<BR><FONT SIZE=3D2>Cc: bjorn</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] Status of =
draft-ietf-mobileip-gnaie-04.txt?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The GNAIE draft has completed WG last call. It is =
currently being</FONT>
<BR><FONT SIZE=3D2>revised based on coments received from the IESG. A =
new version will be</FONT>
<BR><FONT SIZE=3D2>made available this week. Also it goes back to the =
IESG after it is</FONT>
<BR><FONT SIZE=3D2>announced for moving forward to RFC status.</FONT>
</P>

<P><FONT SIZE=3D2>Bjorn Andersson [bjorn@lifix.fi] wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;What is the current status of the Generalized =
NAI Extension draft?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Some questions about the draft:</FONT>
<BR><FONT SIZE=3D2>&gt;- Is there any recommended Type number for the =
GNAI extension that can</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; be (temporarly) used for e.g. =
interoperability testing?</FONT>
</P>

<P><FONT SIZE=3D2>Not at the moment. We are currently working with IANA =
and the IESG to</FONT>
<BR><FONT SIZE=3D2>see if we can assign temporary numbers to extensions =
specified by WG</FONT>
<BR><FONT SIZE=3D2>documents for interop testing. Will see what we can =
do while waiting</FONT>
<BR><FONT SIZE=3D2>for the type number for GNAIE.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;- The GNAI extension in the MIER draft had a sub =
type for the Previous</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; FA-NAI. Is anything similar planned for =
the GNAI draft? Having</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; this would be useful in e.g. hierarchial =
and smooth handoff</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; solutions.</FONT>
</P>

<P><FONT SIZE=3D2>This has not been incorporated into the current GNAIE =
spec. And as you</FONT>
<BR><FONT SIZE=3D2>are aware the MIER extension format itself has been =
included as a part</FONT>
<BR><FONT SIZE=3D2>of 2002bis and hence the MIER I-D will be =
deprecated.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;- The draft states that the &quot;extension may =
be carried by</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Registration Request and Reply =
messages&quot;. Why not allow them in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; agent advertisements also, so that the =
e.g. FAs can advertise</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; their NAI? For example, =
draft-ietf-mobileip-reg-tunnel-05.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; uses the GNAIE in advertisements.</FONT>
</P>

<P><FONT SIZE=3D2>Not sure if the authors have thought of this or if =
they have any</FONT>
<BR><FONT SIZE=3D2>reasons why it canot be sent in Agent Advts. MK, =
Pat? </FONT>
</P>

<P><FONT SIZE=3D2>MK&gt; I don't see any problem of adding a text to =
the draft to allow including the GNAI extension into the AA</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;Bjorn</FONT>
</P>

<P><FONT SIZE=3D2>Basavaraj</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1500B.39FA6CA0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 11:51:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24192
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 11:51:04 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11460;
	Mon, 8 Oct 2001 09:50:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11120;
	Mon, 8 Oct 2001 08:50:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98FnNML021242
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:49:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98FnNUB021241
	for mobile-ip-dist; Mon, 8 Oct 2001 08:49:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98FnJML021234
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:49:20 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09285
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:49:22 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15606
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:50:30 -0600 (MDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f98FnNw26167
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:49:23 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56785715f4ac12f2540ff@davir01nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Mon, 8 Oct 2001 10:49:20 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 8 Oct 2001 10:49:20 -0500
content-class: urn:content-classes:message
Subject: [mobile-ip] Reserving type numbers for experimental use
Date: Mon, 8 Oct 2001 10:49:20 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E87E9@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Reserving type numbers for experimental use
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFQEMsZUqNG0rv1EdWw/gAAhj/HZA==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 08 Oct 2001 15:49:20.0413 (UTC) FILETIME=[CB5504D0:01C15010]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f98FnKML021235
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello,

We would like to get some feedback from WG members on the following
proposal:
WG documents that specify new extensions and error codes should be
able to utilize extension numbers and error codes from a range of
reserved numbers (by IANA) for experimental use. 
This is especially useful for doing interop testing while waiting for
the WG I-D to reach RFC status and actual type numbers assigned by
IANA. The experimental numbers would be returned to the pool once IANA
had assigned the proper numbers from the registry and implementations
would have to conform to the actual type numbers specified in the
associated RFC. 

The experimental numbers (a small range) reserved for the skippable
and non-skippable extensions should be mentioned in 2002bis as it will
serve as the baseline for Mobile IPv4 specifications. 

Should we add this to 2002bis as a part of the IANA considerations
section? 

Regards,
-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 12:08:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24617
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 12:08:20 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28264;
	Mon, 8 Oct 2001 10:07:26 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14687;
	Mon, 8 Oct 2001 09:07:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98G6XML021356
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:06:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98G6XVn021355
	for mobile-ip-dist; Mon, 8 Oct 2001 09:06:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98G6TML021348
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:06:29 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12605
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:06:32 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27236
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:06:20 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f98G6iu04481
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:06:44 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABG13426;
	Mon, 8 Oct 2001 09:06:29 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05154; Mon, 8 Oct 2001 09:06:29 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15297.52997.549780.818997@thomasm-u1.cisco.com>
Date: Mon, 8 Oct 2001 09:06:29 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <697DAA22C5004B4596E033803A7CEF441E87E2@daebe007.NOE.Nokia.com>
References: <697DAA22C5004B4596E033803A7CEF441E87E2@daebe007.NOE.Nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Patil Basavaraj (NET/Dallas) writes:
 > Completely agree with what you are saying and I did not mean to imply
 > that we should be ignoring the MN-HA security. 
 > Since the MN and HA share keys or certs or have other means of
 > establishing an SA, securing the BUs sent to the HA is considerably
 > easier. The MN->CN BUs are much more difficult to deal with and this
 > is what the IESG has expressed concerns about and what the WG sould be
 > focusing on.

   The problem is that it isn't this simple. All of the
   same IPsec considerations that apply to the CN/MN
   also apply to HA/MN since I could, for example, have
   a telnet session to my HA while I'm mobile. Thus the
   piggybacking and authorization issues rear their head
   again.

   On the other hand, I believe that a small set of
   rules that have been discussed here ad infinitum
   should solve this problem for both, and that
   they can be added to the draft with minimal
   fuss. If they must be a separate draft, we
   should at least give them the same priority 
   for completion.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 13:09:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26429
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 13:09:56 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00614;
	Mon, 8 Oct 2001 11:09:11 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09945;
	Mon, 8 Oct 2001 10:08:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98GjKML021472
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:45:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98GjJiX021471
	for mobile-ip-dist; Mon, 8 Oct 2001 09:45:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98GjFML021464
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:45:15 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24565
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:45:15 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06418
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:45:04 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f98GgiC17630;
	Mon, 8 Oct 2001 09:42:57 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABI00772;
	Mon, 8 Oct 2001 09:44:47 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05163; Mon, 8 Oct 2001 09:44:45 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15297.55292.818149.151568@thomasm-u1.cisco.com>
Date: Mon, 8 Oct 2001 09:44:44 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com, Pekka Savola <pekkas@netcore.fi>
Subject: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Discovery
In-Reply-To: <Pine.LNX.4.33.0109301519340.27777-100000@netcore.fi>
References: <Pine.LNX.4.33.0109301519340.27777-100000@netcore.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola writes:
 > It appears to me that MIPv6 has gotten awfully "fat" with all of these
 > options, and may not be globally, securely workable in the end.  Would it
 > be better to consider simpler scenarios at first, e.g.
 > 
 >  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
 > anycast address); this might scale better especially if IPv6 end-nodes are
 > supposed to be simple.

Pekka, 

I think this is an interesting idea generally,
and have been thinking along the same lines.

A couple of observations and questions:

1) The ideal place to update the route is at
   the join point between the HA, MN and CN,
   which is not necessarily CN's first hop
   router

2) Would this scale (even if it were at CN's
   first hop router)

3) Could it be secured? Ie, does this introduce
   new vulnerabilities, or exacerbate old ones?

4) How do you know the subnet prefix so that you
   can create the anycast address?
 
Until these sorts of things are fleshed out,
I'm pretty sure that the WG is going to keep
the bird in hand, so to speak.

	 Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 13:10:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26448
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 13:10:08 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00610;
	Mon, 8 Oct 2001 11:09:10 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09928;
	Mon, 8 Oct 2001 10:08:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98GrbML021510
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:53:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98Grb18021509
	for mobile-ip-dist; Mon, 8 Oct 2001 09:53:37 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98GrVML021502
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:53:32 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26768
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:53:32 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13541
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:53:31 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f98GpPC22701;
	Mon, 8 Oct 2001 09:51:25 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABI01079;
	Mon, 8 Oct 2001 09:53:31 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05166; Mon, 8 Oct 2001 09:53:29 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15297.55817.543329.951143@thomasm-u1.cisco.com>
Date: Mon, 8 Oct 2001 09:53:29 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'Pekka Savola'" <pekkas@netcore.fi>
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco
	 very
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ECD2@eaubrnt018.epa.ericsson.se>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ECD2@eaubrnt018.epa.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham Soliman (EPA) writes:
 > > > >  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
 > > > > anycast address); this might scale better especially if IPv6 end-nodes
 > > are
 > > > > supposed to be simple.
 > > > >
 > > > 	=> Do you have any idea about how you can secure this BU ?
 > > > 	Why is this simpler than sendingit to the CN ?
 > > > 	What about deployment issues, like .. every router has to have MIPv6
 > > > 	in it ?
 > > 
 > > According to the specs, every IPv6 must be able to do most of these things
 > > anyway, so requiring routers should be able to do this does not seem like
 > > a too big additional requirement.
 > > 
 > 	=> No, according to the specs every node SHOULD do it. If 
 > 	a router doesn't do it, it affects the (potentially thousands)
 > 	of CNs attached to it. 
 > 	Anyway, making the routers do it will involve routers modifying
 > 	dst addresses, breaking e2e ...etc which in itself is not 
 > 	very secure at all.

   Well to be fair here, what is being talked about
   is having routers change their routing tables,
   which sounds pretty much like it's in the scope
   of things that routers do :-)

   I'm not sure where this would break e2e though.
   Instead of sending the routing update to the
   CN, it would send it to a router in the path
   instead. Assuming that all of the other
   questions could be answered (big assumption),
   how would this break e2e?

	     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 13:10:22 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26462
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 13:10:22 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00890;
	Mon, 8 Oct 2001 11:09:23 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10043;
	Mon, 8 Oct 2001 10:08:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98GsaML021522
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:54:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98Gsas4021521
	for mobile-ip-dist; Mon, 8 Oct 2001 09:54:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98GsVML021514
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:54:32 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06657
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:54:33 -0700 (PDT)
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14021
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 09:54:31 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98GruS02206
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 12:53:56 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 8 Oct 2001 11:47:19 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LV5Y0>; Mon, 8 Oct 2001 11:53:34 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D42158B9@zrc2c014.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?
Date: Mon, 8 Oct 2001 11:53:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15019.C024DB90"
X-Orig: <mkhalil@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15019.C024DB90
Content-Type: text/plain;
	charset="iso-8859-1"



-----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Monday, October 08, 2001 10:00 AM
To: mobile-ip
Cc: bjorn
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?


The GNAIE draft has completed WG last call. It is currently being
revised based on coments received from the IESG. A new version will be
made available this week. Also it goes back to the IESG after it is
announced for moving forward to RFC status.

Bjorn Andersson [bjorn@lifix.fi] wrote:
>What is the current status of the Generalized NAI Extension draft?
>
>Some questions about the draft:
>- Is there any recommended Type number for the GNAI extension that can
>  be (temporarly) used for e.g. interoperability testing?

Not at the moment. We are currently working with IANA and the IESG to
see if we can assign temporary numbers to extensions specified by WG
documents for interop testing. Will see what we can do while waiting
for the type number for GNAIE.

>- The GNAI extension in the MIER draft had a sub type for the Previous
>  FA-NAI. Is anything similar planned for the GNAI draft? Having
>  this would be useful in e.g. hierarchial and smooth handoff
>  solutions.

This has not been incorporated into the current GNAIE spec. And as you
are aware the MIER extension format itself has been included as a part
of 2002bis and hence the MIER I-D will be deprecated.

>- The draft states that the "extension may be carried by
>  Registration Request and Reply messages". Why not allow them in
>  agent advertisements also, so that the e.g. FAs can advertise
>  their NAI? For example, draft-ietf-mobileip-reg-tunnel-05.txt
>  uses the GNAIE in advertisements.

Not sure if the authors have thought of this or if they have any
reasons why it canot be sent in Agent Advts. MK, Pat? 

MK> As I indicated before that we can add the text to GNAI to include the
extension in the AA. Since MIER is part of 

>
>Regards,
>Bjorn

Basavaraj


------_=_NextPart_001_01C15019.C024DB90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] Status of =
draft-ietf-mobileip-gnaie-04.txt?</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Patil Basavaraj (NET/Dallas) [<A =
HREF=3D"mailto:Basavaraj.Patil@nokia.com">mailto:Basavaraj.Patil@nokia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, October 08, 2001 10:00 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip</FONT>
<BR><FONT SIZE=3D2>Cc: bjorn</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] Status of =
draft-ietf-mobileip-gnaie-04.txt?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The GNAIE draft has completed WG last call. It is =
currently being</FONT>
<BR><FONT SIZE=3D2>revised based on coments received from the IESG. A =
new version will be</FONT>
<BR><FONT SIZE=3D2>made available this week. Also it goes back to the =
IESG after it is</FONT>
<BR><FONT SIZE=3D2>announced for moving forward to RFC status.</FONT>
</P>

<P><FONT SIZE=3D2>Bjorn Andersson [bjorn@lifix.fi] wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;What is the current status of the Generalized =
NAI Extension draft?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Some questions about the draft:</FONT>
<BR><FONT SIZE=3D2>&gt;- Is there any recommended Type number for the =
GNAI extension that can</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; be (temporarly) used for e.g. =
interoperability testing?</FONT>
</P>

<P><FONT SIZE=3D2>Not at the moment. We are currently working with IANA =
and the IESG to</FONT>
<BR><FONT SIZE=3D2>see if we can assign temporary numbers to extensions =
specified by WG</FONT>
<BR><FONT SIZE=3D2>documents for interop testing. Will see what we can =
do while waiting</FONT>
<BR><FONT SIZE=3D2>for the type number for GNAIE.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;- The GNAI extension in the MIER draft had a sub =
type for the Previous</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; FA-NAI. Is anything similar planned for =
the GNAI draft? Having</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; this would be useful in e.g. hierarchial =
and smooth handoff</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; solutions.</FONT>
</P>

<P><FONT SIZE=3D2>This has not been incorporated into the current GNAIE =
spec. And as you</FONT>
<BR><FONT SIZE=3D2>are aware the MIER extension format itself has been =
included as a part</FONT>
<BR><FONT SIZE=3D2>of 2002bis and hence the MIER I-D will be =
deprecated.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;- The draft states that the &quot;extension may =
be carried by</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Registration Request and Reply =
messages&quot;. Why not allow them in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; agent advertisements also, so that the =
e.g. FAs can advertise</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; their NAI? For example, =
draft-ietf-mobileip-reg-tunnel-05.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; uses the GNAIE in advertisements.</FONT>
</P>

<P><FONT SIZE=3D2>Not sure if the authors have thought of this or if =
they have any</FONT>
<BR><FONT SIZE=3D2>reasons why it canot be sent in Agent Advts. MK, =
Pat? </FONT>
</P>

<P><FONT SIZE=3D2>MK&gt; As I indicated before that we can add the text =
to GNAI to include the extension in the AA. Since MIER is part of =
</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;Bjorn</FONT>
</P>

<P><FONT SIZE=3D2>Basavaraj</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15019.C024DB90--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 13:25:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27045
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 13:25:11 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15727;
	Mon, 8 Oct 2001 11:24:28 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26826;
	Mon, 8 Oct 2001 10:23:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98H33ML021563
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:03:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98H33Tl021562
	for mobile-ip-dist; Mon, 8 Oct 2001 10:03:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98H2xML021555
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:02:59 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27912
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:03:02 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19156
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:03:00 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f98H3KQ24625
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 12:03:20 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56789a78e8ac12f255079@davir02nok.americas.nokia.com>;
 Mon, 8 Oct 2001 12:02:56 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 8 Oct 2001 12:02:56 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Mon, 8 Oct 2001 12:02:56 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E87EE@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] MIPv6 - Focus of the security discussion
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFQE13aFcevJ7wEEdWJUwAIx6TWpQAB52NA
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "'ext Michael Thomas'" <mat@cisco.com>
X-OriginalArrivalTime: 08 Oct 2001 17:02:56.0875 (UTC) FILETIME=[13BFA3B0:01C1501B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f98H2xML021556
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Comments inline:

Michael Thomas [mat@cisco.com] wrote:
>
>Patil Basavaraj (NET/Dallas) writes:
> > Completely agree with what you are saying and I did not mean to
imply
> > that we should be ignoring the MN-HA security. 
> > Since the MN and HA share keys or certs or have other means of
> > establishing an SA, securing the BUs sent to the HA is considerably
> > easier. The MN->CN BUs are much more difficult to deal with and this
> > is what the IESG has expressed concerns about and what the WG sould
be
> > focusing on.
>
>   The problem is that it isn't this simple. All of the
>   same IPsec considerations that apply to the CN/MN
>   also apply to HA/MN since I could, for example, have
>   a telnet session to my HA while I'm mobile. Thus the
>   piggybacking and authorization issues rear their head
>   again.
>

Piggybacking issues, selector granularity and others exist for all
BUs that use IPsec to secure them. Authorization by the HA for the
address being sent in the BU? The HA would know if a MN sending a BU
is authorized to use that address as its home address. Do you believe
authorization is an issue w.r.t the HA as well?

But the point I was trying to make with the earlier e-mail or in this
thread I guess is that we should try to develop a scheme that works
for securing BUs in the absence of IPsec (I am repeating here). 

Solving the other IPsec issues (that you raise) is required, but lets
not get stuck on trying to make MIPv6 work only with IPsec. We could
do that as a separate effort. Whether the solution implies no
piggybacking, a new next header etc. can be dealt with separately. As
long as the non-IPsec solution does not prevent or cause problems in
sing IPsec we should go forward in getting that solution done.

>   On the other hand, I believe that a small set of
>   rules that have been discussed here ad infinitum
>   should solve this problem for both, and that
>   they can be added to the draft with minimal
>   fuss. If they must be a separate draft, we
>   should at least give them the same priority 
>   for completion.
>

Priority should be to get a solution for BUs that allows the MIPv6
spec to move forward. Why bind that to getting the IPsec solution
done? Not to say that the IPsec solution is not important, but there
is no need to create a normative reference between the MIPv6 spec and
the IPsec solution for BUs.

>	Mike
>

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 13:25:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27056
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 13:25:17 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15739;
	Mon, 8 Oct 2001 11:24:29 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26825;
	Mon, 8 Oct 2001 10:22:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98H2hML021553
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:02:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98H2hMn021552
	for mobile-ip-dist; Mon, 8 Oct 2001 10:02:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98H2cML021545
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:02:39 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21815
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:02:38 -0700 (PDT)
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23983
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 11:02:28 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98H24S04875
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 13:02:04 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 8 Oct 2001 11:55:39 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LV50F>; Mon, 8 Oct 2001 12:01:55 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D42158BA@zrc2c014.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?
Date: Mon, 8 Oct 2001 12:01:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1501A.ED910300"
X-Orig: <mkhalil@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1501A.ED910300
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,

I have added section 3.1 as follows:

      When a MN or HA adds a GNAI extension to a registration message,
      the extension MUST appear prior to any  authentication extensions.

      In the event the FA adds an GNAI extension to a registration message,
      the extension MUST appear prior to any  authentication extensions 
      added by the FA.

      The FA and HA MAY include its GNAI extension in the Agent
      Advertisement message. If present, the  extension MUST appear
      in the Agent Advertisement message after any of the advertisement 
      extensions defined in [4].
Any comments?

-----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Monday, October 08, 2001 10:00 AM
To: mobile-ip
Cc: bjorn
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?


The GNAIE draft has completed WG last call. It is currently being
revised based on coments received from the IESG. A new version will be
made available this week. Also it goes back to the IESG after it is
announced for moving forward to RFC status.

Bjorn Andersson [bjorn@lifix.fi] wrote:
>What is the current status of the Generalized NAI Extension draft?
>
>Some questions about the draft:
>- Is there any recommended Type number for the GNAI extension that can
>  be (temporarly) used for e.g. interoperability testing?

Not at the moment. We are currently working with IANA and the IESG to
see if we can assign temporary numbers to extensions specified by WG
documents for interop testing. Will see what we can do while waiting
for the type number for GNAIE.

>- The GNAI extension in the MIER draft had a sub type for the Previous
>  FA-NAI. Is anything similar planned for the GNAI draft? Having
>  this would be useful in e.g. hierarchial and smooth handoff
>  solutions.

This has not been incorporated into the current GNAIE spec. And as you
are aware the MIER extension format itself has been included as a part
of 2002bis and hence the MIER I-D will be deprecated.

>- The draft states that the "extension may be carried by
>  Registration Request and Reply messages". Why not allow them in
>  agent advertisements also, so that the e.g. FAs can advertise
>  their NAI? For example, draft-ietf-mobileip-reg-tunnel-05.txt
>  uses the GNAIE in advertisements.

Not sure if the authors have thought of this or if they have any
reasons why it canot be sent in Agent Advts. MK, Pat? 

>
>Regards,
>Bjorn

Basavaraj


------_=_NextPart_001_01C1501A.ED910300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] Status of =
draft-ietf-mobileip-gnaie-04.txt?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi All,</FONT>
</P>

<P><FONT SIZE=3D2>I have added section 3.1 as follows:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When a MN or HA adds a =
GNAI extension to a registration message,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the extension MUST =
appear prior to any&nbsp; authentication extensions.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the event the FA =
adds an GNAI extension to a registration message,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the extension MUST =
appear prior to any&nbsp; authentication extensions </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; added by the =
FA.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The FA and HA MAY =
include its GNAI extension in the Agent</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Advertisement =
message. If present, the&nbsp; extension MUST appear</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the Agent =
Advertisement message after any of the advertisement </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extensions defined in =
[4].</FONT>
<BR><FONT SIZE=3D2>Any comments?</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Patil Basavaraj (NET/Dallas) [<A =
HREF=3D"mailto:Basavaraj.Patil@nokia.com">mailto:Basavaraj.Patil@nokia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, October 08, 2001 10:00 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip</FONT>
<BR><FONT SIZE=3D2>Cc: bjorn</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] Status of =
draft-ietf-mobileip-gnaie-04.txt?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The GNAIE draft has completed WG last call. It is =
currently being</FONT>
<BR><FONT SIZE=3D2>revised based on coments received from the IESG. A =
new version will be</FONT>
<BR><FONT SIZE=3D2>made available this week. Also it goes back to the =
IESG after it is</FONT>
<BR><FONT SIZE=3D2>announced for moving forward to RFC status.</FONT>
</P>

<P><FONT SIZE=3D2>Bjorn Andersson [bjorn@lifix.fi] wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;What is the current status of the Generalized =
NAI Extension draft?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Some questions about the draft:</FONT>
<BR><FONT SIZE=3D2>&gt;- Is there any recommended Type number for the =
GNAI extension that can</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; be (temporarly) used for e.g. =
interoperability testing?</FONT>
</P>

<P><FONT SIZE=3D2>Not at the moment. We are currently working with IANA =
and the IESG to</FONT>
<BR><FONT SIZE=3D2>see if we can assign temporary numbers to extensions =
specified by WG</FONT>
<BR><FONT SIZE=3D2>documents for interop testing. Will see what we can =
do while waiting</FONT>
<BR><FONT SIZE=3D2>for the type number for GNAIE.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;- The GNAI extension in the MIER draft had a sub =
type for the Previous</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; FA-NAI. Is anything similar planned for =
the GNAI draft? Having</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; this would be useful in e.g. hierarchial =
and smooth handoff</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; solutions.</FONT>
</P>

<P><FONT SIZE=3D2>This has not been incorporated into the current GNAIE =
spec. And as you</FONT>
<BR><FONT SIZE=3D2>are aware the MIER extension format itself has been =
included as a part</FONT>
<BR><FONT SIZE=3D2>of 2002bis and hence the MIER I-D will be =
deprecated.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;- The draft states that the &quot;extension may =
be carried by</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Registration Request and Reply =
messages&quot;. Why not allow them in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; agent advertisements also, so that the =
e.g. FAs can advertise</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; their NAI? For example, =
draft-ietf-mobileip-reg-tunnel-05.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; uses the GNAIE in advertisements.</FONT>
</P>

<P><FONT SIZE=3D2>Not sure if the authors have thought of this or if =
they have any</FONT>
<BR><FONT SIZE=3D2>reasons why it canot be sent in Agent Advts. MK, =
Pat? </FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;Bjorn</FONT>
</P>

<P><FONT SIZE=3D2>Basavaraj</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1501A.ED910300--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 14:23:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28254
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 14:23:17 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10051;
	Mon, 8 Oct 2001 12:19:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10611;
	Mon, 8 Oct 2001 11:18:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98HsIML022055
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:54:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98HsIhV022054
	for mobile-ip-dist; Mon, 8 Oct 2001 10:54:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98HsEML022046
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:54:15 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23124
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:54:15 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27657
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 11:55:21 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA06098
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:54:12 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f98HsCJ11595
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:54:12 -0700
X-mProtect:  Mon, 8 Oct 2001 10:54:12 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdvXIdBc; Mon, 08 Oct 2001 10:54:11 PDT
Message-ID: <3BC1E840.E41A512B@iprg.nokia.com>
Date: Mon, 08 Oct 2001 10:54:08 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <697DAA22C5004B4596E033803A7CEF441E87EE@daebe007.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

"Patil Basavaraj (NET/Dallas)" wrote:
> 
> Solving the other IPsec issues (that you raise) is required, but lets
> not get stuck on trying to make MIPv6 work only with IPsec. We could
> do that as a separate effort. Whether the solution implies no
> piggybacking, a new next header etc. can be dealt with separately. As
> long as the non-IPsec solution does not prevent or cause problems in
> sing IPsec we should go forward in getting that solution done.

Auth Data Suboption is a very good alternative for securing the BUs.
lets work on it and move the MIPv6 spec forward.

IMO, auth data suboption can also be used to secure the BU to the home
agent.

Vijay

> 
> >   On the other hand, I believe that a small set of
> >   rules that have been discussed here ad infinitum
> >   should solve this problem for both, and that
> >   they can be added to the draft with minimal
> >   fuss. If they must be a separate draft, we
> >   should at least give them the same priority
> >   for completion.
> >
> 
> Priority should be to get a solution for BUs that allows the MIPv6
> spec to move forward. Why bind that to getting the IPsec solution
> done? Not to say that the IPsec solution is not important, but there
> is no need to create a normative reference between the MIPv6 spec and
> the IPsec solution for BUs.
> 
> >       Mike
> >
> 
> -Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 15:09:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29123
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 15:09:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25058;
	Mon, 8 Oct 2001 13:09:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13500;
	Mon, 8 Oct 2001 12:07:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98IjYML022215
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 11:45:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98IjYQF022214
	for mobile-ip-dist; Mon, 8 Oct 2001 11:45:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98IjTML022207
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 11:45:30 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08606
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 11:45:29 -0700 (PDT)
From: jens_kue@gmx.de
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA13684
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 11:45:27 -0700 (PDT)
Received: (qmail 21892 invoked by uid 0); 8 Oct 2001 18:45:26 -0000
Received: from a416c.pppool.de (HELO jens3) (213.6.65.108)
  by mail.gmx.net (mp005-rz3) with SMTP; 8 Oct 2001 18:45:26 -0000
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <jochen.grimminger@mchp.siemens.de>
Subject: [mobile-ip] New BETH Draft
Date: Mon, 8 Oct 2001 20:46:03 +0200
Message-ID: <GNENICCDAAAEMJCDJEFJOENMCAAA.jens_kue@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01C1503A.3EFBD020"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C1503A.3EFBD020
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

I have a Question in "Two Party Handover" from BETH.

What happen when the oAR or the nAR don't receive a L2 Trigger before MN
move to nAR?
What happen with the Tunnel-End?


Bye
Jens

------=_NextPart_000_0022_01C1503A.3EFBD020
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.100" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D430511018-08102001>Hello,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D430511018-08102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D430511018-08102001>I have =
a Question in=20
"Two Party Handover" from BETH.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D430511018-08102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D430511018-08102001>What =
happen when the=20
oAR or the nAR don't receive a L2 Trigger&nbsp;before MN move to nAR?=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D430511018-08102001>What =
happen with the=20
Tunnel-End?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D430511018-08102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D430511018-08102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D430511018-08102001>Bye</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D430511018-08102001>Jens</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_000_0022_01C1503A.3EFBD020--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 15:50:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29896
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 15:50:50 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24729;
	Mon, 8 Oct 2001 09:01:10 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08662;
	Mon, 8 Oct 2001 08:01:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98F0TML021052
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:00:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98F0TK8021051
	for mobile-ip-dist; Mon, 8 Oct 2001 08:00:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98F0PML021044
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:00:25 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00132
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:00:27 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06606
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 08:00:26 -0700 (PDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f98F0Sw21267
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 10:00:28 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56782a4d69ac12f256126@davir03nok.americas.nokia.com>;
 Mon, 8 Oct 2001 10:00:25 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 8 Oct 2001 10:00:25 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?
Date: Mon, 8 Oct 2001 10:00:25 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E87E3@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFP0EoJTq91g7vCEdWrxQAIx6S5QwAOZndQ
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <bjorn@lifix.fi>
X-OriginalArrivalTime: 08 Oct 2001 15:00:25.0440 (UTC) FILETIME=[F5F3AE00:01C15009]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f98F0QML021045
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

The GNAIE draft has completed WG last call. It is currently being
revised based on coments received from the IESG. A new version will be
made available this week. Also it goes back to the IESG after it is
announced for moving forward to RFC status.

Bjorn Andersson [bjorn@lifix.fi] wrote:
>What is the current status of the Generalized NAI Extension draft?
>
>Some questions about the draft:
>- Is there any recommended Type number for the GNAI extension that can
>  be (temporarly) used for e.g. interoperability testing?

Not at the moment. We are currently working with IANA and the IESG to
see if we can assign temporary numbers to extensions specified by WG
documents for interop testing. Will see what we can do while waiting
for the type number for GNAIE.

>- The GNAI extension in the MIER draft had a sub type for the Previous
>  FA-NAI. Is anything similar planned for the GNAI draft? Having
>  this would be useful in e.g. hierarchial and smooth handoff
>  solutions.

This has not been incorporated into the current GNAIE spec. And as you
are aware the MIER extension format itself has been included as a part
of 2002bis and hence the MIER I-D will be deprecated.

>- The draft states that the "extension may be carried by
>  Registration Request and Reply messages". Why not allow them in
>  agent advertisements also, so that the e.g. FAs can advertise
>  their NAI? For example, draft-ietf-mobileip-reg-tunnel-05.txt
>  uses the GNAIE in advertisements.

Not sure if the authors have thought of this or if they have any
reasons why it canot be sent in Agent Advts. MK, Pat? 

>
>Regards,
>Bjorn

Basavaraj



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 17:03:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01963
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 17:03:05 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21803;
	Mon, 8 Oct 2001 14:02:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06463;
	Mon, 8 Oct 2001 14:01:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98KgMML022599
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 13:42:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98KgMPp022598
	for mobile-ip-dist; Mon, 8 Oct 2001 13:42:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98KgIML022591
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 13:42:18 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14012
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 13:42:21 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11915
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 14:42:10 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA28410
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 15:42:16 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 8 Oct 2001 15:41:23 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LWBPB>; Mon, 8 Oct 2001 15:41:41 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D42158BD@zrc2c014.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?
Date: Mon, 8 Oct 2001 15:41:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15039.9E5A23B0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15039.9E5A23B0
Content-Type: text/plain;
	charset="iso-8859-1"

All,
 
Since this draft has already been through WG last call and IETF last call,
any addition to the current DRAFT might cause unnecessary delay for this
draft to go as standard doc. Authors suggest that new features which WG sees
that are useful, may be added by new future proposals.
 
MK
 

-----Original Message-----
From: Khalil, Mohamed [RICH1:2N51:EXCH] 
Sent: Monday, October 08, 2001 10:09 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?





-----Original Message----- 
From: Patil Basavaraj (NET/Dallas) [ mailto:Basavaraj.Patil@nokia.com
<mailto:Basavaraj.Patil@nokia.com> ] 
Sent: Monday, October 08, 2001 10:00 AM 
To: mobile-ip 
Cc: bjorn 
Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt? 


The GNAIE draft has completed WG last call. It is currently being 
revised based on coments received from the IESG. A new version will be 
made available this week. Also it goes back to the IESG after it is 
announced for moving forward to RFC status. 

Bjorn Andersson [bjorn@lifix.fi] wrote: 
>What is the current status of the Generalized NAI Extension draft? 
> 
>Some questions about the draft: 
>- Is there any recommended Type number for the GNAI extension that can 
>  be (temporarly) used for e.g. interoperability testing? 

Not at the moment. We are currently working with IANA and the IESG to 
see if we can assign temporary numbers to extensions specified by WG 
documents for interop testing. Will see what we can do while waiting 
for the type number for GNAIE. 

>- The GNAI extension in the MIER draft had a sub type for the Previous 
>  FA-NAI. Is anything similar planned for the GNAI draft? Having 
>  this would be useful in e.g. hierarchial and smooth handoff 
>  solutions. 

This has not been incorporated into the current GNAIE spec. And as you 
are aware the MIER extension format itself has been included as a part 
of 2002bis and hence the MIER I-D will be deprecated. 

>- The draft states that the "extension may be carried by 
>  Registration Request and Reply messages". Why not allow them in 
>  agent advertisements also, so that the e.g. FAs can advertise 
>  their NAI? For example, draft-ietf-mobileip-reg-tunnel-05.txt 
>  uses the GNAIE in advertisements. 

Not sure if the authors have thought of this or if they have any 
reasons why it canot be sent in Agent Advts. MK, Pat? 

MK> I don't see any problem of adding a text to the draft to allow including
the GNAI extension into the AA 

> 
>Regards, 
>Bjorn 

Basavaraj 


------_=_NextPart_001_01C15039.9E5A23B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [mobile-ip] Status of draft-ietf-mobileip-gnaie-04.txt?</TITLE>

<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV><SPAN class=930492107-09102001><FONT face=Arial color=#0000ff size=2><SPAN 
class=130263908-09102001>All,</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=930492107-09102001><FONT face=Arial color=#0000ff size=2><SPAN 
class=130263908-09102001></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=930492107-09102001><FONT face=Arial color=#0000ff size=2>Since 
this draft has already been through WG last call and IETF last call, any 
addition to the current DRAFT might cause unnecessary delay for this draft to go 
as standard doc. Authors&nbsp;suggest that new features&nbsp;which WG sees that 
are useful, may be added by new future proposals.</FONT></SPAN></DIV>
<DIV><SPAN class=930492107-09102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=930492107-09102001><SPAN class=130263908-09102001><FONT 
face=Arial color=#0000ff size=2>MK</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=930492107-09102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Khalil, Mohamed 
  [RICH1:2N51:EXCH] <BR><B>Sent:</B> Monday, October 08, 2001 10:09 
  AM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> RE: 
  [mobile-ip] Status of 
  draft-ietf-mobileip-gnaie-04.txt?<BR><BR></FONT></DIV><BR><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Patil 
  Basavaraj (NET/Dallas) [<A 
  href="mailto:Basavaraj.Patil@nokia.com">mailto:Basavaraj.Patil@nokia.com</A>]</FONT> 
  <BR><FONT size=2>Sent: Monday, October 08, 2001 10:00 AM</FONT> <BR><FONT 
  size=2>To: mobile-ip</FONT> <BR><FONT size=2>Cc: bjorn</FONT> <BR><FONT 
  size=2>Subject: RE: [mobile-ip] Status of 
  draft-ietf-mobileip-gnaie-04.txt?</FONT> </P><BR>
  <P><FONT size=2>The GNAIE draft has completed WG last call. It is currently 
  being</FONT> <BR><FONT size=2>revised based on coments received from the IESG. 
  A new version will be</FONT> <BR><FONT size=2>made available this week. Also 
  it goes back to the IESG after it is</FONT> <BR><FONT size=2>announced for 
  moving forward to RFC status.</FONT> </P>
  <P><FONT size=2>Bjorn Andersson [bjorn@lifix.fi] wrote:</FONT> <BR><FONT 
  size=2>&gt;What is the current status of the Generalized NAI Extension 
  draft?</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Some questions 
  about the draft:</FONT> <BR><FONT size=2>&gt;- Is there any recommended Type 
  number for the GNAI extension that can</FONT> <BR><FONT size=2>&gt;&nbsp; be 
  (temporarly) used for e.g. interoperability testing?</FONT> </P>
  <P><FONT size=2>Not at the moment. We are currently working with IANA and the 
  IESG to</FONT> <BR><FONT size=2>see if we can assign temporary numbers to 
  extensions specified by WG</FONT> <BR><FONT size=2>documents for interop 
  testing. Will see what we can do while waiting</FONT> <BR><FONT size=2>for the 
  type number for GNAIE.</FONT> </P>
  <P><FONT size=2>&gt;- The GNAI extension in the MIER draft had a sub type for 
  the Previous</FONT> <BR><FONT size=2>&gt;&nbsp; FA-NAI. Is anything similar 
  planned for the GNAI draft? Having</FONT> <BR><FONT size=2>&gt;&nbsp; this 
  would be useful in e.g. hierarchial and smooth handoff</FONT> <BR><FONT 
  size=2>&gt;&nbsp; solutions.</FONT> </P>
  <P><FONT size=2>This has not been incorporated into the current GNAIE spec. 
  And as you</FONT> <BR><FONT size=2>are aware the MIER extension format itself 
  has been included as a part</FONT> <BR><FONT size=2>of 2002bis and hence the 
  MIER I-D will be deprecated.</FONT> </P>
  <P><FONT size=2>&gt;- The draft states that the "extension may be carried 
  by</FONT> <BR><FONT size=2>&gt;&nbsp; Registration Request and Reply 
  messages". Why not allow them in</FONT> <BR><FONT size=2>&gt;&nbsp; agent 
  advertisements also, so that the e.g. FAs can advertise</FONT> <BR><FONT 
  size=2>&gt;&nbsp; their NAI? For example, 
  draft-ietf-mobileip-reg-tunnel-05.txt</FONT> <BR><FONT size=2>&gt;&nbsp; uses 
  the GNAIE in advertisements.</FONT> </P>
  <P><FONT size=2>Not sure if the authors have thought of this or if they have 
  any</FONT> <BR><FONT size=2>reasons why it canot be sent in Agent Advts. MK, 
  Pat? </FONT></P>
  <P><FONT size=2>MK&gt; I don't see any problem of adding a text to the draft 
  to allow including the GNAI extension into the AA</FONT> </P>
  <P><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Regards,</FONT> <BR><FONT 
  size=2>&gt;Bjorn</FONT> </P>
  <P><FONT size=2>Basavaraj</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15039.9E5A23B0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 17:17:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02458
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 17:17:12 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27363;
	Mon, 8 Oct 2001 14:16:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10069;
	Mon, 8 Oct 2001 14:14:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98KqlML022614
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 13:52:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98KqkGP022613
	for mobile-ip-dist; Mon, 8 Oct 2001 13:52:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98KqfML022606
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 13:52:42 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15308
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 13:52:40 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21311
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 14:53:50 -0600 (MDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f98KqWL09425;
	Mon, 8 Oct 2001 22:52:33 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id WAA03871; Mon, 8 Oct 2001 22:52:31 +0200
Message-ID: <3BC204D4.21A103A5@era.ericsson.se>
Date: Mon, 08 Oct 2001 21:56:04 +0200
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
References: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr> <m34rpdhlxe.fsf@test9.crm.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Alexandru Petrescu wrote:
> 
> Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
> >    We extended mip6 draft to support multiple network interfaces.
> >    Our MIP6 can handle multiple network interfaces with single home address.
> >
> > => this is fine (multiple network interface support is an essential
> > function of mobility) but I don't understand why you believed the
> > Mobile IPv6 draft needed to be extended.
> 
> Ryuji probably means several interfaces each having its own home
> address?  Something related to multihoming, load-balancing,
> optimizations?
> 

I had a look at your code Ryuji, and I thought that home addresses are
assigned to a special virtual interface called mobileipxx. Care-of
addresses can be assigned to multiple physical interfaces, and they can
have different characteristics. Each home address can use any CoA it
prefers at any time. However, there is not much use really to have
multiple home addresses, unless the home network is being renumbered.

/Mattias



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 18:33:33 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03594
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 18:33:33 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26656;
	Mon, 8 Oct 2001 15:33:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08524;
	Mon, 8 Oct 2001 15:32:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98MGfML022894
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 15:16:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98MGepA022893
	for mobile-ip-dist; Mon, 8 Oct 2001 15:16:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98MGZML022886
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 15:16:36 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06961
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 15:16:31 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10538
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 16:17:40 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f98MFRg19731;
	Mon, 8 Oct 2001 15:15:27 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABJ07199;
	Mon, 8 Oct 2001 15:15:18 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA05211; Mon, 8 Oct 2001 15:15:17 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15298.9589.769683.483215@thomasm-u1.cisco.com>
Date: Mon, 8 Oct 2001 15:15:17 -0700 (PDT)
To: Pat Calhoun <pcalhoun@diameter.org>
Cc: mobile-ip@sunroof.eng.sun.com,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>, mat@cisco.com
Subject: Re: [mobile-ip] AAA keys design comment
In-Reply-To: <20011002081304.O26914@charizard.diameter.org>
References: <15288.41306.137426.736305@thomasm-u1.cisco.com>
	<MJEMJBGGCLLDLFFAHLJKCEFCDHAA.fredrik.johansson@ipunplugged.com>
	<15289.55811.95026.478238@thomasm-u1.cisco.com>
	<20011002081304.O26914@charizard.diameter.org>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > On Tue, Oct 02, 2001 at 08:15:15AM -0700, Michael Thomas wrote:
 > >    I said (probably too briefly) that it was a choice
 > >    between a race condition or extra latency. If the
 > >    AAA blocks to send the message to HA to eliminate the
 > >    race, it adds latency to the entire exchange since
 > >    the AAA could have sent the message to MN with the
 > >    keying material at that step. It also loses robustness
 > >    here because AAA and HA are not fate shared.
 > 
 > right, but the AAA is in constant contact with the HAs. So when the
 > AAA does the HA selection, assuming this is requested, then it would
 > most likely pick one that has been responding to watchdog messages.

   But there's still the latency involved; constant
   contact may make the situation worse :-)

 > If the MN moves to a new domain (cross-domain roaming), the AAAH
 > is again contacted, and has the authority to deny access.

   Isn't it the case that the AAAh has to be contacted
   each time the MN moves? Since the keys are pushed
   from the AAA, the new FA won't have those keys, and
   there's nothing local (FA, AAAf) that has access. 

   One advantage of a Kerberos-like scheme is that
   the MN could get a ticket for either the FA, AAAf
   or both for that matter. Upon movement, the MN
   would present the ticket+authenticator to the new
   FA which could either decrypted directly (assuming
   the FA's had a common keytab), or ship it to the
   AAAf which could locally decrypt it (better, IMO). 
   This also avoids the scary prospect of context 
   transfer of secret keys.

	       Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 20:34:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04733
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 20:34:00 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05781;
	Mon, 8 Oct 2001 18:33:16 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20507;
	Mon, 8 Oct 2001 17:32:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9907kML023063
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:07:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9907kWu023062
	for mobile-ip-dist; Mon, 8 Oct 2001 17:07:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9907gML023055
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:07:42 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26238
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:07:45 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18543
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:07:33 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9907kk10542
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:07:46 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABJ10517;
	Mon, 8 Oct 2001 17:07:43 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA05226; Mon, 8 Oct 2001 17:07:41 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15298.16333.221697.602@thomasm-u1.cisco.com>
Date: Mon, 8 Oct 2001 17:07:41 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Security requirements comments
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

1) On page 10, I don't know what the DR acronym means.

2) B.3: While I agree that MN's should authenticate the AP's,
   I'm not sure that this is in the scope of this WG.
   It seems more like an L2 or URP like problem. Since this
   is requirements document for MIP WG, I don't think we 
   should be making requirements we can't address

3) I didn't see any specific discussion of replay attacks,
   especially from somebody on the same link as either
   MN or CN. It's probably worth a mention, especially
   since the requirements here may not be entirely 
   clear since there isn't an assumption of strong
   authentication

4) Editorial nit: it would be nice to tie the threats
   to the section they were found. It's somewhat
   aesthetically jarring to see sections 6.1 followed
   by A.1 when they are seemingly correlated to the
   section number. Feel free to tell me that it's just
   me :-)

5) In section 6.7, you bring up home agent functionality
   in remote networks (FMIP, HMIP, etc). It's not clear
   to me whether strong or weak authentication should be
   required, nor does this document weigh in on the matter.
   We haven't discussed that on the list yet, and I think
   the requirement should make it explicit which variety
   is acceptible. My inclination is that strong authentication
   should be a MUST.

6) General requirement 4: nit it's cipher. More generally,
   this should be predicated with an "if". That is, "if
   cryptographic mechanisms are utilized in the solution,
   it SHOULD provide a means on using different algorithms."

7) General requirement 5: this is too fuzzy. It should be
   "selectors as defined by RFC 2401"

8) General requirement 8: this is Motherhood and Apple
   Pie, but a little lacking on the "how do I know if I
   met the requirement". I would suggest just dropping
   it since I don't think there's any risk that this
   will not be scrutinized :-)

9) General requirement 10: I would actually like to have
   the requirement that the solution MUST have a means
   of being done without the use of asymmetric crypto.
   As I've posted before, I think that MIPv6 would be
   better served by doing something simple first and
   then layering the optimizations (HA proxy, DH
   exchanges to shorten subsequent exchanges) till a
   later time (ie different RFC).


	      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 20:51:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04949
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 20:51:40 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10050;
	Mon, 8 Oct 2001 17:51:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23141;
	Mon, 8 Oct 2001 17:49:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f990RmML023107
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:27:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f990RmjE023106
	for mobile-ip-dist; Mon, 8 Oct 2001 17:27:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f990RhML023099
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:27:44 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01198
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:27:44 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02833
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 17:27:44 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f990Rig05092;
	Mon, 8 Oct 2001 17:27:45 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABJ11125;
	Mon, 8 Oct 2001 17:27:41 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA05233; Mon, 8 Oct 2001 17:27:39 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15298.17531.582765.961512@thomasm-u1.cisco.com>
Date: Mon, 8 Oct 2001 17:27:39 -0700 (PDT)
To: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>, "'ext Michael Thomas'" <mat@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <697DAA22C5004B4596E033803A7CEF441E87EE@daebe007.NOE.Nokia.com>
References: <697DAA22C5004B4596E033803A7CEF441E87EE@daebe007.NOE.Nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Patil Basavaraj (NET/Dallas) writes:
 > Michael Thomas [mat@cisco.com] wrote:
 > >   The problem is that it isn't this simple. All of the
 > >   same IPsec considerations that apply to the CN/MN
 > >   also apply to HA/MN since I could, for example, have
 > >   a telnet session to my HA while I'm mobile. Thus the
 > >   piggybacking and authorization issues rear their head
 > >   again.
 > >
 > 
 > Piggybacking issues, selector granularity and others exist for all
 > BUs that use IPsec to secure them. Authorization by the HA for the
 > address being sent in the BU? The HA would know if a MN sending a BU
 > is authorized to use that address as its home address. Do you believe
 > authorization is an issue w.r.t the HA as well?

   Yes. There's no reason that my linux box at
   home shouldn't be able to function as my home
   agent as well, right? My linux box is loaded 
   up with all kinds of other goodies which don't
   necessarily have same security requirements.

 > But the point I was trying to make with the earlier e-mail or in this
 > thread I guess is that we should try to develop a scheme that works
 > for securing BUs in the absence of IPsec (I am repeating here). 

   I understand, it's just that I think they need to
   be given equal priority because they're both important
   pieces of the whole solution. It _would_ be nice to
   get back to the CN/MN problem though.

 > Solving the other IPsec issues (that you raise) is required, but lets
 > not get stuck on trying to make MIPv6 work only with IPsec. We could
 > do that as a separate effort. Whether the solution implies no
 > piggybacking, a new next header etc. can be dealt with separately. As
 > long as the non-IPsec solution does not prevent or cause problems in
 > sing IPsec we should go forward in getting that solution done.

   I'd be *very* reluctant to axe the strong
   authentication mechanism out of the main MIP
   draft, which is the way I'm reading this
   (correct me if I'm wrong). I think there's a
   lot of danger of not getting wide scale
   deployment if it isn't in the spec, and most
   especially if mipv6 allows the use of the weak
   variety (<-- should I read the requirement
   draft as forbidding that???)

 > Priority should be to get a solution for BUs that allows the MIPv6
 > spec to move forward. Why bind that to getting the IPsec solution
 > done? Not to say that the IPsec solution is not important, but there
 > is no need to create a normative reference between the MIPv6 spec and
 > the IPsec solution for BUs.

   We have no other solution that gives strong
   authentication and is backed with key
   distribution protocols. I do not see how
   we can avoid this to move mipv6 forward.

	  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 21:47:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06450
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 21:47:37 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17985;
	Mon, 8 Oct 2001 19:46:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09803;
	Mon, 8 Oct 2001 18:45:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f991hWML023391
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:43:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f991hW80023390
	for mobile-ip-dist; Mon, 8 Oct 2001 18:43:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f991hSML023383
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:43:28 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11705
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:43:30 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24480
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:43:30 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA08849;
	Mon, 8 Oct 2001 18:42:55 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f991gtw02035;
	Mon, 8 Oct 2001 18:42:55 -0700
X-mProtect:  Mon, 8 Oct 2001 18:42:55 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdzKIR5P; Mon, 08 Oct 2001 18:42:53 PDT
Message-ID: <3BC2561E.A01B8D20@iprg.nokia.com>
Date: Mon, 08 Oct 2001 18:42:54 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: Pat Calhoun <pcalhoun@diameter.org>,
        "Basavaraj Patil (NTC/Dallas)" <Basavaraj.Patil@nokia.com>,
        Phil Roberts <PRoberts@MEGISTO.com>
Subject: Re: [mobile-ip] IESG feedback on AAA keys doc
References: <CD8355C7E19ED411BD5F00508BB0D19D697FD7@megisto-sql1.megisto.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello folks,

After a few weeks of discussion, I have prepared a new
version of the document, "AAA Registration Keys for Mobile IP".
Except for proofreading, it's almost ready to be sent in as a
revised Internet Draft, and it's available at:
	http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt

I'll hold off for a little while, in case someone can tell me how
to resolve the IESG comment about security algorithm IANA namespaces,
which to expedite discussion I have moved first in the discussion
below, but which is out of order from the original e-mail from the
IESG.

Here, starts the follow-on from the IESG comments.

>>       Algorithm Identifier
>>                  This field indicates the algorithm to be used for
>>                  future computations of the MN-FA Authentication
>>                  Extension (see section 3)
> 
> It would be good to state explicitely state that this is the same
> algorithm identifier as defined in XXX (section 3 doesn't seem to do
> this either). This document doesn't say. I.e., this presumably points
> to an existing name space managed by IANA. What is it? [hmm I later
> see that this is a new name space.. see comment below.]

I am happy to use another existing name space, but the only
one I find doesn't have HMAC-MD5 in it:

========================================================================
  Hash Algorithm                     Value            References
  --------------                     -----            ----------
  MD5                                  1               [RFC1321]
  SHA                                  2              FIPS 180-1
  Tiger                                3              See Reference [TIGER]
  SHA2-256                             4                 [Leech]
  SHA2-384                             5                 [Leech] 
  SHA2-512                             6                 [Leech]
========================================================================

Should we define some more values?  How do I find out the up-to-date
list?  Is this list being actively maintained?  If we use this list,
do we have to wait until someone actively figures out the right way
to keep this list up-to-date (assuming that it is not now). (***)

............  (now, from the top) ..............

> This is a comment that probably applies to lots of MIP
> documents. Please define "security association" in the MIP context. In
> IPsec terminology, for instance, it means something very
> specific. I.e., keys, SPIs, etc., and works only between a pair of
> nodes. Once an association exists, encrypted packets can be sent. No
> further negotiation is needed. Also, one can have multiple (different
> SAs between the same set of machines). This document says:
> 
>    node and its home agent.  When the mobile node shares a security
>    association with its home AAA server, however, it is possible to use
>    that security association to create derivative security associations
>    between the mobile node and its home agent, and again between the
>    mobile node and the foreign agent currently offering connectivity to
>    the mobile node.  This document specifies extensions to the Mobile
> 
> The MN talks to its HA, not a AAA server. So I'm not clear what is
> meant by "shares a security association". From my perspective, it
> seems like "security relationship" would be more accurate terminology.

The mobile node is expected to produce authentication data according
to the security algorithm configured for its use with AAA.   I think
this corresponds exactly with the typical use of the terminology.
A security relationship would be more general than is intended here.
But since I don't know exactly what that term means, it's hard to
be sure.  Maybe the security relationship is the thing that precedes
and enables the creation of the security association.

> Note that the above paragraph also talks about "security associations"
> between the MN and HA. Here, the terminology  (I suspect) corresponds
> more closely to the IPsec usage. But I'm not sure.

I've included a Terminology section.  I hope this isn't opening another
huge can of worms, but I'm very happy to accept suggestions on how
to make appropriate and succinct defintions.

> General comment. This document is very loose about whether a MN is
> talking to a FA/HA or a AAA server. This should be made explicitly
> clear throughout. Indeed, my assumption is that conceptually, if not
> in reality, a MN NEVER speaks to an AAA server directly. Rather, it
> speaks MIP protocols with an HA/FA, and that HA/FA has a side
> conversation with the AAA server. This should be made much more clear
> throughout.

O.K.  I will try to do this.

>> 2. Scope of Protocol
>>
>>    The protocol and messages in this document are intended to facilitate
>>    the following operations which may occur between the mobile node, AAA
>>    server, home agent, and foreign agent.
> 
> Throughout this section, it should be made explicitly clear *who* is
> sending a message, and *to* *whom* the message is being sent. Also,
> when someone processes an extension *who* is doing the
> processing. This isn't clear from just reading the text.

I'll give it a shot.  Let me know if I succeed -- or fail.

> Also, it might make sense to change the section heading to "overview"
> rather than Scope, since it does seem like an overview. Assuming this
> is an overview, I think it would help the reader if the text included
> steps such as as "FA sends message to AAA server ..." "AAA server does
> X and returns Y to the FA", "FA generates reply and sends to MN"...

O.K.  I have attempted to do this.

>     2. If the mobile node does not have a Mobility Security Association
>        with the foreign agent, it SHOULD include an MN-FA Key Request
>        extension.
> 
> In what message, and sent to whom?

As part of its Registration Request that it sends to the Foreign Agent.

> What is the RFC reference to the key request extension?

It's defined later in the document.  I've added a cross reference.

>     3. Similarly, if the mobile node does not have a Mobility Security
>        Association with the home agent, it MUST add an MN-HA Key Request
>        extension.
> 
> In message sent to whom?

As part of its Registration Request that it sends to the Foreign Agent.

>     4. If one or more Key Request extensions were added, the MN-AAA
>        Authentication extension is added to the Registration Request.
> 
> Added by whom?

The mobile node.

>     5. At the time the information within the MN-AAA Authentication
>        extension is verified by the AAA server, the AAA server also
>        generates Key Material for the keys requested by the mobile node,
>        and causes insertion of the Key Material fields along with the
>        Registration Reply.
> 
> So there is an implied step here in which the FA exchanges messages
> with its local AAA server? Would be good to explicitely say that here.

I have made it more explicit.

> Is that AAA protocol already in place? What RFCs are used? I.e, is
> there a potential normative reference problem buried here? (I suspect
> the answer is no, but am not sure.)

The intention was to keep the formulation general, and not dependent
on the specifics of the AAA protocol.

>     6. The respective AAA keys are distributed to the Home and Foreign
>        Agent via the AAA protocol.
> 
> Where are the details of this described?

It is out of scope for this document, and I hope it does not have
to be specfied as part of a normative reference.  All that we
should have to do is to specify how the Mobile IP extensions work.

According to this philosophy, some of the steps in the Overview
amount to over-specification, but I don't think there is any
serious problem so O.K.

> step 6b) FA sends a reply to the MN
> 
>>    extension.  In order for the mobile node to make use of key
>>    information sent to it by the AAA server, the mobile node also has to
>>    be able to select the appropriate cryptographic algorithm that uses
>>    the key to produce the authentication.  The following table contains
> 
> I doubt the AAA server is sending messages to the MN. Isn't it the FA
> that does this (i.e., it relays this info)? Text could be more
> precise.

I reworded this to say that the AAA server "creates" the
key information.

>    Dynamic Mobility Security Associations shared between mobile nodes
> 
> What is a "Dynamic Mobility Security Association"? Is it different
> than other types of security associations?

Well, it's not manually configured.   Isn't this well-known usage?
Do we have to say "dynamically created"?  Otherwise, it is the
same as the mobility security association defined in RFC 2002.

> Note: IMO, it would be better to move the description formats of the
> extensions here, rather than at the end. It is a bit confusing to talk
> about the contents of packet fields prior to having shown the format
> of the option with all of the fields together.

I didn't see where the packet fields were mentioned.  We used
the name of some extensions that were defined in RFC 2002.
The tables supply parameter values for some fields in the
extension formats, but that's as close as I could get to
understanding your request here.  Maybe we should move the
tables after the formats?

>> 4. Key Material Creation and Derivation
>>
>>    This section contains the procedures followed in the creation of the
>>    Key Material by AAA servers, and the key derivation procedures used
>                                 ^
>>    by mobile nodes.  Note that the AAA servers will also make use of the
> 
> insert "extension" as indicated above? Also, better to say "contains
> the procedure a FA/HA follows when creating ..." (or is the procedure
> aimed at AAA servers?)

The procedure is aimed at AAA servers, and I couldn't parse the result
when I put "extension" where you indicated.  The idea is that AAA
servers will do something that is able to be understood by mobile
nodes, and that mobility agents (home agent, foreign agent) will
faithfully transcribe the results into the appropriate Mobile IP
extensions.  I have added those words to this introductory
paragraph.  It is still intended to avoid normative references
here for any AAA protocol.  If necessary, we could create an
applicability statement and use it along with the introductory section.

>    The example that follows makes use of MD5 in prefix+suffix mode,
>    whose support is mandatory in Mobile IP [11].  Other cryptographic
>    functions, such as those listed in 3 MAY also be used.
> 
> Might be better to make HMAC-MD5 the example. Also, what is meant be
> "listed in 3 MAY". Should that be "listed in [3] MAY"??

That was supposed to be Section 3.

>     1. The AAA server identifies the mobile node's via a
>        ``node-address''.  If the Home Address field of the
>        Registration Request is zero (0), the Mobile Node's NAI is used
>        instead.
> 
> First sentence doesn't parse.

Fixed!

> I'm confused by the description above in the sense that it implies
> that the MN Registration Request is sent to a AAA server. I thought it
> was sent to a FA.

Here, one has to understand the contents of RFC 2977.  I have added
a lot of text to that effect in the Introduction.  I hope that's
sufficient.  Otherwise, we would have to start copying text from
that document.

> Also, why use the term "node-address"? Don't you really mean the home
> address? (the term node-address isn't defined anywhere).

Fixed.

>  Maybe you mean to say:
> 
>     1. The AAA server identifies the mobile node via a
>        ``node-address''.  The node-address is taken from the Home
>        Address field of the Registration Request, or the NAI, if the
>        Home Address field is zero (0).
> 
> Note again how the text blurs the distinction between the FA and the
> AAA server. Does the AAA server see the registration request? I would
> think not. It sees information the FA sends to it, which includes
> portions of the registration request. The document should really make
> this clear throughout

I fixed this, I hope.  I also hope it would be clear to someone
who went through the discussion in RFC 2977.

>>    2. The AAA server generates a random [5] value of at least 64 bits.
> 
> 64 bits seems short. I'd like someone with security background to
> comment on this. But I guess this is sent in the clear, so the length
> may not matter?

That makes sense to me.

>     3. The AAA server inserts the random value into the Key extension in
>        the ``Key Material'' field.
> 
> Presumably this field is part of a message or an extension within a
> message. Which message or extension? Make explicit.

The example is supposed to work for any Key Material extension.

> Note steps 1-3 are done on the server, steps 4-5 on the mobile
> node. It might be good to make the more clear here, perhaps by having
> subsections?

O.K.  I did it, but I don't know if it's an improvement or not.

>     4. The mobile node calculates
> 
>           key = MD5(AAA-key | Key Material | node-address | AAA-key)
> 
> what is AAA-key? Where does it come from? Ditto for "Key Material" How
> does the mobile node know which AAA-key to use? Can there only be one
> (I hope not...)

The AAA-key is what the mobile node shares with the AAA server.
The Key Material is the 64 random bits.

>       Key Material
>                  A random [5] value of at least 64 bits.
> 
> Keying material of only 64 bits? Would this pass security muster??

I reckon it will, but I'm not betting my house on it.  The cryptographic
strength of the algorithm doesn't depend on this number.

>>       AAA SPI    A 32-bit opaque value, indicating the SPI that the
>>                  mobile node must use to determine the algorithm to use
>>                  for establishing the FA security information.
> 
> How does the mobile node create this SPI? Is this preconfigured?

Yes, or at least out of scope for this document.

>>       FA SPI     A 32-bit opaque value, which the mobile node MUST use
>>                  to index all the necessary information established for
>>                  the FA security information after it is decoded.
> 
> Might be better to say something like:
> 
>        FA SPI     The SPI for the Security Association to the FA that
>                   the MN creates as a result of processing this extension.

Done.

>>    The Unsolicited MN-FA Key Material From AAA extension, shown
>>    in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply
>>    Extension [12].
> 
> Shouldn't this be moved to the beginning of section 5. (e.g., as it is
> in Section 6?)

Done!

>>       HA SPI     A 32-bit opaque value, which the mobile node MUST use
>>                  to index all the necessary information established for
>>                  the HA security information after it is decoded.
> 
> Same comment as above w.r.t FA SPI. Ditto for key material.

Done.

>>    the Key Material provided by the home domain AAA server (AAAH). The
>>    key is intended for use the mobile node to secure future Mobile IP
>>    registrations with its home agent.  The MN-HA Key Reply MUST appear
> 
> sentence doesn't parse.

Fixed.

>>    The mobile node uses the Identification field data from the
>>    Registration Request as its initial synchronization data with the
>>    home agent.
> 
> What is the field referred to in this sentence?

If you look at the Registration Request format, there is a field
called the Identification field.  It allows entities using Mobile IP
to associated a Registration Reply to the appropriate Registration
Request.

I don't know if you meant to suggest adding text or not, but I wouldn't
feel it was appropriate to copy text from RFC 2002{,bis} here.

>> 7. MN-FA Key Request From AAA Subtype
>>
>>    The MN-FA Key Request From AAA subtype data uses subtype 7 of the
>>    Generalized MN-FA Key Request Extension [12].  The MN-FA Key Request
>>    From AAA extension MUST appear in the Registration Request before the
>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>    length.
>>
>>
>> 8. MN-HA Key Request From AAA Subtype
>>
>>    The MN-HA Key Request From AAA subtype data uses subtype 7 of the
>>    Generalized MN-HA Key Request Extension [12].  The MN-HA Key Request
>>    From AAA extension MUST appear in the Registration Request before the
>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>    length.
> 
> Hmm. What are the above two sections about? The first sentence in each
> seems redundent. Can't the remaining text just be put in the previous
> sections that describe the extension?

The extensions, which are Request extensions (not Reply extensions),
are defined in the Generalized Keys document, and don't have any
additional format that needs to be specfied.

> Also, why is the ordering important?

The MN-AAA Authentication extension is an "authorization-enabling"
extension, in the language of RFC 2002bis.  Such extensions have
to be last.


>> 10. IANA Considerations
> 
> This document requests certain numbers be assigned. Is this required,
> i.e., are their implementations that already use the numbers? This
> section should really say TBD for any assignments that it  doesn't
> care what the  actual value is, and let IANA pick. If it really does
> care about the value, the text should suggest a certain value be used
> and mention that the numbers are already in use by existing
> implementations. That way, IANA has some context for deciding what to
> do.

The numbers are already in use by implementations.   I have added text
to the IANA Considerations to that effect.

>>    Section 3 introduces the Algorithm Identifier namespace that requires
>>    IANA management.  This specification makes use of 1-3; all other
>>    values other than zero (0) are available for assignment, pending
>>    review and approval by a Designated Expert [9].
> 
> Can't you just leverage off an existing MIP name space (i.e, the one
> used by other extensions?) rather than creating a new one?

See above (***).


Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 21:48:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06469
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 21:48:07 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24456;
	Mon, 8 Oct 2001 18:47:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10239;
	Mon, 8 Oct 2001 18:47:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f991j8ML023408
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:45:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f991j7Ih023407
	for mobile-ip-dist; Mon, 8 Oct 2001 18:45:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f991j4ML023400
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:45:04 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11835
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:45:06 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24833
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:45:05 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA15822;
	Tue, 9 Oct 2001 11:43:52 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA00847;
	Tue, 9 Oct 2001 11:45:00 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXJ526>; Tue, 9 Oct 2001 11:44:59 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED17@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "'vijayd@iprg.nokia.com'" <vijayd@iprg.nokia.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Tue, 9 Oct 2001 11:44:56 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15063.FFCB6A30"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15063.FFCB6A30
Content-Type: text/plain

Vijay, 

> > Solving the other IPsec issues (that you raise) is required, but lets
> > not get stuck on trying to make MIPv6 work only with IPsec. We could
> > do that as a separate effort. Whether the solution implies no
> > piggybacking, a new next header etc. can be dealt with separately. As
> > long as the non-IPsec solution does not prevent or cause problems in
> > sing IPsec we should go forward in getting that solution done.
> 
> Auth Data Suboption is a very good alternative for securing the BUs.
> lets work on it and move the MIPv6 spec forward.
> 
	=> You've mentioned this a few times now and  think it's 
	misleading at best. Are you suggesting that if we all agreed today
	to go ahead with the Auth data suboption, then the MIPv6
	draft will be ready ? Nothing else to solve for the security
	issues ? No key exchange problem (much bigger than what
	we're discussing now btw) ?


	Hesham

------_=_NextPart_001_01C15063.FFCB6A30
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Vijay, </FONT>
</P>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt; Solving the other IPsec issues (that you raise) is required, but lets</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; not get stuck on trying to make MIPv6 work only with IPsec. We could</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; do that as a separate effort. Whether the solution implies no</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; piggybacking, a new next header etc. can be dealt with separately. As</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; long as the non-IPsec solution does not prevent or cause problems in</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; sing IPsec we should go forward in getting that solution done.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Auth Data Suboption is a very good alternative for securing the BUs.</FONT>
<BR><FONT SIZE=2 FACE="Arial">lets work on it and move the MIPv6 spec forward.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; You've mentioned this a few times now and&nbsp; think it's </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">misleading at best. Are you suggesting that if we all agreed today</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">to go ahead with the Auth data suboption, then the MIPv6</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">draft will be ready ? Nothing else to solve for the security</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">issues ? No key exchange problem (much bigger than what</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">we're discussing now btw) ?</FONT>
</P>
<BR>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15063.FFCB6A30--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 21:53:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06538
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 21:53:09 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25599;
	Mon, 8 Oct 2001 18:52:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11142;
	Mon, 8 Oct 2001 18:52:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f991pjML023586
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:51:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f991pjcx023585
	for mobile-ip-dist; Mon, 8 Oct 2001 18:51:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f991pgML023578
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:51:42 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11018
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:51:43 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26885
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 18:51:42 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA16621;
	Tue, 9 Oct 2001 11:50:08 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA02425;
	Tue, 9 Oct 2001 11:51:14 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXJ5QZ>; Tue, 9 Oct 2001 11:51:13 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED18@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: mip6@sfc.wide.ad.jp
Subject: RE: [mobile-ip] Draft 15
Date: Tue, 9 Oct 2001 11:51:13 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15064.E028DA90"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15064.E028DA90
Content-Type: text/plain

> > => this is fine (multiple network interface support is an essential
> > function of mobility) but I don't understand why you believed the
> > Mobile IPv6 draft needed to be extended.
> > BTW I implemented this too before wireless LAN support, movement
> detection
> > is very easy when drivers are fixed in order to signal up/down events.
> 
> OK, It is easy to support only one or two interface for move detection,
> I can put some code in device driver as trigger for movement detection.
> We used to use L2 information for movement detection in MIPv4, but we
> found that modifying every network driver is harder, i mean I can not
> modify all the interface supported on BSD. 
> 
> We can use link status like up/down for ethernet and most of interfaces.
> Wireless LAN has signal strength, but I thought signal strength is not
> totally equal to link up/down information of ethernet. 
> I think it is not easy to define how to handle L2 information. 
> This is my question what's the link status for dial-up interface  (by
> modem )?
> 
> I proposed a system to handle layer 2 information for mobile computing.
> The system named MIBsocket, this system is implemented as
> message-passing socket between layers including userland, so you can
> pass layer 2 information to IP layer through MIBsocket.
> All information is defined by MIB based description. This system was
> implemented
> on BSD-based system (only IPv4).
> 
	=> This is (again)very interesting and I've been thinkin gabout
something 
	similar for IPv6, not that there is any difference in the ideas. 
	Do you have any references for your implementation ? 
	White paper ..etc ? 

	Thanks, 
	Hesham




> >    If you are interested in this, please ask me more. I have evaluation
> of
> >    the our original idea and have "english paper" for this :) 
> >    But this paper is under submission to the conference, I can not post
> it
> >    to MIP6 ML.
> >    
> > => please !
> > 
> > Thanks
> > 
> > Francis.Dupont@enst-bretagne.fr
> 

------_=_NextPart_001_01C15064.E028DA90
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] Draft 15</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt; =&gt; this is fine (multiple network interface support is an essential</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; function of mobility) but I don't understand why you believed the</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; Mobile IPv6 draft needed to be extended.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; BTW I implemented this too before wireless LAN support, movement detection</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; is very easy when drivers are fixed in order to signal up/down events.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">OK, It is easy to support only one or two interface for move detection,</FONT>
<BR><FONT SIZE=2 FACE="Arial">I can put some code in device driver as trigger for movement detection.</FONT>
<BR><FONT SIZE=2 FACE="Arial">We used to use L2 information for movement detection in MIPv4, but we</FONT>
<BR><FONT SIZE=2 FACE="Arial">found that modifying every network driver is harder, i mean I can not</FONT>
<BR><FONT SIZE=2 FACE="Arial">modify all the interface supported on BSD. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">We can use link status like up/down for ethernet and most of interfaces.</FONT>
<BR><FONT SIZE=2 FACE="Arial">Wireless LAN has signal strength, but I thought signal strength is not</FONT>
<BR><FONT SIZE=2 FACE="Arial">totally equal to link up/down information of ethernet. </FONT>
<BR><FONT SIZE=2 FACE="Arial">I think it is not easy to define how to handle L2 information. </FONT>
<BR><FONT SIZE=2 FACE="Arial">This is my question what's the link status for dial-up interface&nbsp; (by modem )?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">I proposed a system to handle layer 2 information for mobile computing.</FONT>
<BR><FONT SIZE=2 FACE="Arial">The system named MIBsocket, this system is implemented as</FONT>
<BR><FONT SIZE=2 FACE="Arial">message-passing socket between layers including userland, so you can</FONT>
<BR><FONT SIZE=2 FACE="Arial">pass layer 2 information to IP layer through MIBsocket.</FONT>
<BR><FONT SIZE=2 FACE="Arial">All information is defined by MIB based description. This system was implemented</FONT>
<BR><FONT SIZE=2 FACE="Arial">on BSD-based system (only IPv4).</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; This is (again)very interesting and I've been thinkin gabout something </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">similar for IPv6, not that there is any difference in the ideas. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Do you have any references for your implementation ? </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">White paper ..etc ?</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Thanks, </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; If you are interested in this, please ask me more. I have evaluation of</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; the our original idea and have &quot;english paper&quot; for this :) </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; But this paper is under submission to the conference, I can not post it</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; to MIP6 ML.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; =&gt; please !</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; Thanks</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; Francis.Dupont@enst-bretagne.fr</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15064.E028DA90--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 22:12:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06774
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 22:12:30 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29304;
	Mon, 8 Oct 2001 19:11:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13566;
	Mon, 8 Oct 2001 19:11:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f992AJML023704
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:10:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f992AJs4023703
	for mobile-ip-dist; Mon, 8 Oct 2001 19:10:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f992AFML023696
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:10:15 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14454
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:10:18 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00377
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 20:10:06 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA10559
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:10:17 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f992AGX28045
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:10:16 -0700
X-mProtect:  Mon, 8 Oct 2001 19:10:16 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdToo5sv; Mon, 08 Oct 2001 19:10:15 PDT
Message-ID: <3BC25C87.6083934B@iprg.nokia.com>
Date: Mon, 08 Oct 2001 19:10:15 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED17@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Hesham,


> "Hesham Soliman (EPA)" wrote:
> 
> Vijay,
> 
>      => You've mentioned this a few times now and  think it's
>      misleading at best. Are you suggesting that if we all agreed
>      today
>      to go ahead with the Auth data suboption, then the MIPv6
>      draft will be ready ? 
>      Nothing else to solve for the security
>      issues ? No key exchange problem (much bigger than what
>      we're discussing now btw) ?

Auth Data suboption does not solve the key exchange problem. it
solves the problem of how to protect the BU once the keys
have been created between the MN and the CN. it is an alternative
to using AH and ESP. 

The MIPv6 draft talks about how to protect the BU. it does not
talk about the key exchange problem. that is done in a bunch of
drafts (BAKE, SUCV, PBK, Home Agent cookies...). so if we agree
on using the suboption, MIPv6 draft can move ahead.

Thats what I meant. and I did not intend to mislead anyone.
its you and few others who are holding the MIPv6 draft to ransom
by citing that it does not work with AH. So what? if it does not
work with AH, lets move ahead. lets find an alternative solution.

first lets figure out how BU can be protected with the auth data
suboption. (its already there in the draft 15). next lets
figure out how BAKE/AAA/Son of IKE can supply the security 
association. 

and meanwhile, the die-hard AH enthusiasts can figure out how
AH can be used to protect the BU. 

Vijay


> 
>      Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 22:14:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06819
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 22:14:55 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02581;
	Mon, 8 Oct 2001 20:13:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13906;
	Mon, 8 Oct 2001 19:14:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f992DHML023761
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:13:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f992DHET023760
	for mobile-ip-dist; Mon, 8 Oct 2001 19:13:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f992DDML023750
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:13:13 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14755
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:13:16 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02625
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:13:15 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA10630
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:13:15 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f992DEL30180
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 19:13:14 -0700
X-mProtect:  Mon, 8 Oct 2001 19:13:14 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdMBNiDc; Mon, 08 Oct 2001 19:13:13 PDT
Message-ID: <3BC25D39.6D9EC261@iprg.nokia.com>
Date: Mon, 08 Oct 2001 19:13:13 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED17@eaubrnt018.epa.ericsson.se> <3BC25C87.6083934B@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

just an additional comment

Vijay Devarapalli wrote:
> 
> Hi Hesham,
> 
> > "Hesham Soliman (EPA)" wrote:
> >
> > Vijay,
> >
> >      => You've mentioned this a few times now and  think it's
> >      misleading at best. Are you suggesting that if we all agreed
> >      today
> >      to go ahead with the Auth data suboption, then the MIPv6
> >      draft will be ready ?
> >      Nothing else to solve for the security
> >      issues ? No key exchange problem (much bigger than what
> >      we're discussing now btw) ?
> 
> Auth Data suboption does not solve the key exchange problem. it
> solves the problem of how to protect the BU once the keys
> have been created between the MN and the CN. it is an alternative
> to using AH and ESP.
> 
> The MIPv6 draft talks about how to protect the BU. it does not
> talk about the key exchange problem. that is done in a bunch of
> drafts (BAKE, SUCV, PBK, Home Agent cookies...). so if we agree
> on using the suboption, MIPv6 draft can move ahead.
> 
> Thats what I meant. and I did not intend to mislead anyone.
> its you and few others who are holding the MIPv6 draft to ransom
> by citing that it does not work with AH. So what? if it does not
> work with AH, lets move ahead. lets find an alternative solution.
> 
> first lets figure out how BU can be protected with the auth data
> suboption. (its already there in the draft 15). next lets
> figure out how BAKE/AAA/Son of IKE can supply the security
> association.

supply to mipv6 module which would then create this suboption.

> 
> and meanwhile, the die-hard AH enthusiasts can figure out how
> AH can be used to protect the BU.
> 
> Vijay
> 
> >
> >      Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct  8 23:24:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08807
	for <mobileip-archive@odin.ietf.org>; Mon, 8 Oct 2001 23:24:25 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07667;
	Mon, 8 Oct 2001 21:23:49 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19624;
	Mon, 8 Oct 2001 20:23:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f993MlML023988
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 20:22:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f993MkaX023987
	for mobile-ip-dist; Mon, 8 Oct 2001 20:22:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f993MhML023980
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 20:22:43 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19543
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 20:22:44 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06982
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 21:22:33 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA24885
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 13:21:36 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA28598
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 13:22:43 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXJ79Q>; Tue, 9 Oct 2001 13:22:41 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Tue, 9 Oct 2001 13:22:41 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15071.A7622C40"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15071.A7622C40
Content-Type: text/plain

> > 
> >      => You've mentioned this a few times now and  think it's
> >      misleading at best. Are you suggesting that if we all agreed
> >      today
> >      to go ahead with the Auth data suboption, then the MIPv6
> >      draft will be ready ? 
> >      Nothing else to solve for the security
> >      issues ? No key exchange problem (much bigger than what
> >      we're discussing now btw) ?
> 
> Auth Data suboption does not solve the key exchange problem. it
> solves the problem of how to protect the BU once the keys
> have been created between the MN and the CN. it is an alternative
> to using AH and ESP. 
> 
	=> Agreed.

> The MIPv6 draft talks about how to protect the BU. it does not
> talk about the key exchange problem. that is done in a bunch of
> drafts (BAKE, SUCV, PBK, Home Agent cookies...). so if we agree
> on using the suboption, MIPv6 draft can move ahead.
> 
	=> See below.

> Thats what I meant. and I did not intend to mislead anyone.
> its you and few others who are holding the MIPv6 draft to ransom
> by citing that it does not work with AH. So what? if it does not
> work with AH, lets move ahead. lets find an alternative solution.
> 
	=> Heh :) This is too much credit to give me or anyone else. 
	My understanding was that based on the IESG comments
	the draft could not go ahead without specifying the key
	exchange mechanism that can be used in the absence
	of IKE. So your comment about the draft going ahead
	without the key exchange mechanism doesn't seem to
	be inline with the IESG comments. I'd love to know if 
	this is a wrong interpretation of the IESG position. 
	This is why I think it's misleading to say that the BU
	protection is the only thing holding the draft back. 

	Hesham





------_=_NextPart_001_01C15071.A7622C40
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; You've mentioned this a few times now and&nbsp; think it's</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; misleading at best. Are you suggesting that if we all agreed</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; today</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to go ahead with the Auth data suboption, then the MIPv6</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft will be ready ? </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Nothing else to solve for the security</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issues ? No key exchange problem (much bigger than what</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we're discussing now btw) ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Auth Data suboption does not solve the key exchange problem. it</FONT>
<BR><FONT SIZE=2 FACE="Arial">solves the problem of how to protect the BU once the keys</FONT>
<BR><FONT SIZE=2 FACE="Arial">have been created between the MN and the CN. it is an alternative</FONT>
<BR><FONT SIZE=2 FACE="Arial">to using AH and ESP. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Agreed.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">The MIPv6 draft talks about how to protect the BU. it does not</FONT>
<BR><FONT SIZE=2 FACE="Arial">talk about the key exchange problem. that is done in a bunch of</FONT>
<BR><FONT SIZE=2 FACE="Arial">drafts (BAKE, SUCV, PBK, Home Agent cookies...). so if we agree</FONT>
<BR><FONT SIZE=2 FACE="Arial">on using the suboption, MIPv6 draft can move ahead.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; See below.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Thats what I meant. and I did not intend to mislead anyone.</FONT>
<BR><FONT SIZE=2 FACE="Arial">its you and few others who are holding the MIPv6 draft to ransom</FONT>
<BR><FONT SIZE=2 FACE="Arial">by citing that it does not work with AH. So what? if it does not</FONT>
<BR><FONT SIZE=2 FACE="Arial">work with AH, lets move ahead. lets find an alternative solution.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Heh :) This is too much credit to give me or anyone else. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">My understanding was that based on the IESG comments</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">the draft could not go ahead without specifying the key</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">exchange mechanism that can be used in the absence</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">of IKE. So your comment about the draft going ahead</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">without the key exchange mechanism doesn't seem to</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">be inline with the IESG comments. I'd love to know if </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">this is a wrong interpretation of the IESG position. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">This is why I think it's misleading to say that the BU</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">protection is the only thing holding the draft back. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
<BR>
<BR>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15071.A7622C40--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 02:12:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21862
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 02:12:41 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05618;
	Tue, 9 Oct 2001 00:04:49 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA08201;
	Mon, 8 Oct 2001 23:04:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9963wML024271
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 8 Oct 2001 23:03:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9963wP5024270
	for mobile-ip-dist; Mon, 8 Oct 2001 23:03:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9963tML024263
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 23:03:55 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27765
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 8 Oct 2001 23:03:57 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04854
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 00:03:45 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA11510
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 16:02:44 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA19853
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 16:03:51 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXKCF8>; Tue, 9 Oct 2001 16:03:49 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED23@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Interop test event
Date: Tue, 9 Oct 2001 16:03:48 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

[Sending for Sarolta ]


Dear madams/sirs,

We are pleased to inform you about the preparation of an
interoperability event which will be organised by the Conformance Lab of
Ericsson Research.

The topics addressed during the interoperability event are:

- Mobile IPv6 (<draft-ietf-mobileip-ipv6-13.txt>) and
- Hierarchical Mobile IPv6 (<draft-ietf-mobileip-hmipv6-04.txt>)


The event is scheduled for 3rd-7th December in Budapest, Hungary. 

The conformance test services of Conformance Lab on the above mentioned
protocols will be available for the participants at the event. 
We will provide testing facilities and some experts will also be present
during the event for assisting the participants. 

Participation on the event is free of charge.

Update information will be maintained on Ericsson Hungary's website
<http://www.ericsson.co.hu/conform>. Detailed information and registration
to the event will be available soon.

Suggestions are welcome.

Looking forward to recording your participation and meeting you at the
event.

Best regards

Sarolta Dibuz


-- 
Sarolta Dibuz  Ph.D.                Sarolta.Dibuz@eth.ericsson.se
Conformance Center (ETH/RLSC)       Mobile: +36-30-202-6180
Ericsson Hungary Ltd.               Tel: +36-1-437 7784
P.O.B. 107, 1300 Budapest, Hungary  Fax: +36-1-437 7219



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 04:19:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25968
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 04:19:05 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA12502;
	Tue, 9 Oct 2001 01:18:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15833;
	Tue, 9 Oct 2001 01:17:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f998GuML024611
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 01:16:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f998GufH024610
	for mobile-ip-dist; Tue, 9 Oct 2001 01:16:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f998GpML024603
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 01:16:52 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24896
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 01:16:55 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28448
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 02:16:43 -0600 (MDT)
Received: from ban by muminmamman.lifix.fi with local (Exim 3.12 #1 (Debian))
	id 15qs4L-0004TF-00
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 09 Oct 2001 11:16:53 +0300
Date: Tue, 9 Oct 2001 11:16:53 +0300
From: Bjorn Andersson <bjorn@lifix.fi>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Reserving type numbers for experimental use
Message-ID: <20011009111652.D29494@lifix.fi>
Mail-Followup-To: Bjorn Andersson <bjorn@lifix.fi>,
	mobile-ip@sunroof.eng.sun.com
References: <697DAA22C5004B4596E033803A7CEF441E87E9@daebe007.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <697DAA22C5004B4596E033803A7CEF441E87E9@daebe007.NOE.Nokia.com>
User-Agent: Mutt/1.3.20i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Mon, Oct 08 2001, at 10:49:20 -0500, Patil Basavaraj (NET/Dallas) wrote:
> We would like to get some feedback from WG members on the following
> proposal:
> WG documents that specify new extensions and error codes should be
> able to utilize extension numbers and error codes from a range of
> reserved numbers (by IANA) for experimental use. 

Would it be more effective if I-D authors used non-reserved numbers
in their drafts, without any offical permission. There would probably
not be any conflicts in 99% of the cases, and the numbers would get
accepted as such. Or doesn't IANA like this? 

Isn't this how many authors of I-Ds have done in the past?  Just to
mention one example, draft-ietf-mobileip-optim-11.txt defines four new
MIPv4 message types and their type numbers (16-19). Am I completely
missing something?

  Bjorn
-- 
Bjorn Andersson <bjorn@lifix.fi>                       +358 50 341 2556
Lifix Systems Oy <http://www.lifix.fi/>                 PGP id 5AFC144B
Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 08:35:11 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29743
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 08:35:10 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05301;
	Tue, 9 Oct 2001 05:34:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14413;
	Tue, 9 Oct 2001 05:33:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99CWnML024864
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 05:32:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99CWnbe024863
	for mobile-ip-dist; Tue, 9 Oct 2001 05:32:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99CWkML024856
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 05:32:46 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14702
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 05:32:47 -0700 (PDT)
Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25144
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 05:32:46 -0700 (PDT)
Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151])
	by postfix1-2.free.fr (Postfix) with ESMTP
	id C944BAB295; Tue,  9 Oct 2001 14:32:45 +0200 (CEST)
Received: from imp1-2.free.fr (www-data@localhost [127.0.0.1])
        by localhost (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) with ESMTP id f99CWj45025773;
	Tue, 9 Oct 2001 14:32:45 +0200
Received: (from www-data@localhost)
        by imp1-2.free.fr (8.12.0.Beta16/8.12.0.Beta16/Debian 8.12.0.Beta16) id f99CWiW5025772;
	Tue, 9 Oct 2001 14:32:44 +0200
To: Michael Thomas <mat@cisco.com>
Subject: Re: [mobile-ip] Security requirements comments
Message-ID: <1002630764.3bc2ee6cb3946@imp.free.fr>
Date: Tue, 09 Oct 2001 14:32:44 +0200 (MEST)
From: petrescu@crm.mot.com
Cc: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.42
X-Originating-IP: 192.134.4.228
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Michael Thomas <mat@cisco.com> writes:
> 1) On page 10, I don't know what the DR acronym means.

Default Route?

> 2) B.3: While I agree that MN's should authenticate the AP's,
>    I'm not sure that this is in the scope of this WG.
>    It seems more like an L2 or URP like problem. Since this
>    is requirements document for MIP WG, I don't think we 
>    should be making requirements we can't address

I agree with this, except when AR in visited net has HA functionality.

Along the same lines, I think the draft should clearly define the
terms AP, base station, AR.  For example, AP has no IP in it, so how
would it would not relate to Mobile IPv6.
AP - a device used to relay packets between radio and wired
     infrastructure and that is not IP-aware.
AR - the device of which address is at the DR of a mobile node.  One
     AR can have several AP's attached to it, one per interface.
XX - a device with both AP and AR functionality.

> 5) In section 6.7, you bring up home agent functionality
>    in remote networks (FMIP, HMIP, etc). It's not clear

I thought it refers to HA in foreign nets as part of Mobile IP and not
of FMIP/HMIP.  I would suggest a separate effort to address security
of FMIP/HMIP.

>    to me whether strong or weak authentication should be
>    required, nor does this document weigh in on the matter.
>    We haven't discussed that on the list yet, and I think
>    the requirement should make it explicit which variety
>    is acceptible. My inclination is that strong authentication
>    should be a MUST.

Sorry for my ignorance, but what's the concrete difference between
strong and weak auth in this specific context?

> 6) General requirement 4: nit it's cipher. More generally,
>    this should be predicated with an "if". That is, "if
>    cryptographic mechanisms are utilized in the solution,
>    it SHOULD provide a means on using different algorithms."

Do you think that something else than crypto could be used? I posted
along these lines a while back.  I was arguing that the requirements
should give some freedom to use "functional" mechanisms (not only
crypto) to secure Mobile IP.  There was no feedback about this, so I
suppose there's a common understanding that only crypto would do.

> 9) General requirement 10: I would actually like to have
>    the requirement that the solution MUST have a means
>    of being done without the use of asymmetric crypto.
>    As I've posted before, I think that MIPv6 would be
>    better served by doing something simple first and
>    then layering the optimizations (HA proxy, DH
>    exchanges to shorten subsequent exchanges) till a
>    later time (ie different RFC).

That is a good argument.  My oppinion too.  However, this would
eliminate HIP, SUCV, PBK-addresses from the first simple solutions.

Alex


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 12:44:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07598
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 12:44:08 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11527;
	Tue, 9 Oct 2001 10:42:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26816;
	Tue, 9 Oct 2001 09:42:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99GfWML025270
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:41:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99GfWkn025269
	for mobile-ip-dist; Tue, 9 Oct 2001 09:41:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99GfOML025262
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:41:24 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16560
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:41:25 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA02308
	for mobile-ip@sunroof.eng.sun.com; Tue, 9 Oct 2001 12:41:50 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99GMGML025241
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:22:16 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12617
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:22:18 -0700 (PDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03268
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:22:17 -0700 (PDT)
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f99GMFa06246
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:22:16 -0400 (EDT)
Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id MAA28388; Tue, 9 Oct 2001 12:22:14 -0400 (EDT)
Cc: Christopher.Carroll@verizonwireless.com
Received: from nj0117semyonmi by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id MAA28309; Tue, 9 Oct 2001 12:22:00 -0400 (EDT)
From: "S.Mizikovsky" <smizikovsky@lucent.com>
To: <charliep@iprg.nokia.com>, <mobile-ip@sunroof.eng.sun.com>
Original-Cc: <Christopher.Carroll@verizonwireless.com>
Subject: RE: [mobile-ip] IESG feedback on AAA keys doc
Date: Tue, 9 Oct 2001 12:20:21 -0400
Message-ID: <NFBBJIDMALLOJCAJGAPJIEEDCHAA.smizikovsky@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <43E8CCEAF148D211854C00805FA72E5808318FE5@rhqnneex1.corp.bam.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Dear Mr. Perkins,

At the last IETF conference, Uri Blumenthal of Lucent Technologies submitted
the proposal for PRF based on SHA-1 with recommendation to use it for
generation of key material.

As I am sure you would agree, although both MD5 and SHA-1 are highly
regarded for their MAC properties, neither is widely accepted as a PRF - a
property which is specifically significant when registration, session, and
other key material is produced as the result of running these functions.
Although discussions over Uri's proposal are still in progress, we suggest
to consider reserving at least 4 values for practical variations of PRF
based on SHA-1 and MD5.

As Uri is on a vacation this week, could you, please, copy all respective
comments to me.

Thank you

Semyon Mizikovsky
Technical Manager, Security & Fraud prevention
Lucent Technologies, Inc.
Wireless Standards Department
67 Whippany Rd., 14D-314, Whippany, NJ 07981
(973) 386-6348


-----Original Message-----
From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
Sent: Monday, October 08, 2001 9:43 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: Pat Calhoun; Basavaraj Patil (NTC/Dallas); Phil Roberts
Subject: Re: [mobile-ip] IESG feedback on AAA keys doc

Hello folks,

After a few weeks of discussion, I have prepared a new
version of the document, "AAA Registration Keys for Mobile IP".
Except for proofreading, it's almost ready to be sent in as a
revised Internet Draft, and it's available at:
	http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt

I'll hold off for a little while, in case someone can tell me how
to resolve the IESG comment about security algorithm IANA namespaces,
which to expedite discussion I have moved first in the discussion
below, but which is out of order from the original e-mail from the
IESG.

Here, starts the follow-on from the IESG comments.

>>       Algorithm Identifier
>>                  This field indicates the algorithm to be used for
>>                  future computations of the MN-FA Authentication
>>                  Extension (see section 3)
>
> It would be good to state explicitely state that this is the same
> algorithm identifier as defined in XXX (section 3 doesn't seem to do
> this either). This document doesn't say. I.e., this presumably points
> to an existing name space managed by IANA. What is it? [hmm I later
> see that this is a new name space.. see comment below.]

I am happy to use another existing name space, but the only
one I find doesn't have HMAC-MD5 in it:

========================================================================
  Hash Algorithm                     Value            References
  --------------                     -----            ----------
  MD5                                  1               [RFC1321]
  SHA                                  2              FIPS 180-1
  Tiger                                3              See Reference [TIGER]
  SHA2-256                             4                 [Leech]
  SHA2-384                             5                 [Leech]
  SHA2-512                             6                 [Leech]
========================================================================

Should we define some more values?  How do I find out the up-to-date
list?  Is this list being actively maintained?  If we use this list,
do we have to wait until someone actively figures out the right way
to keep this list up-to-date (assuming that it is not now). (***)

............  (now, from the top) ..............

> This is a comment that probably applies to lots of MIP
> documents. Please define "security association" in the MIP context. In
> IPsec terminology, for instance, it means something very
> specific. I.e., keys, SPIs, etc., and works only between a pair of
> nodes. Once an association exists, encrypted packets can be sent. No
> further negotiation is needed. Also, one can have multiple (different
> SAs between the same set of machines). This document says:
>
>    node and its home agent.  When the mobile node shares a security
>    association with its home AAA server, however, it is possible to use
>    that security association to create derivative security associations
>    between the mobile node and its home agent, and again between the
>    mobile node and the foreign agent currently offering connectivity to
>    the mobile node.  This document specifies extensions to the Mobile
>
> The MN talks to its HA, not a AAA server. So I'm not clear what is
> meant by "shares a security association". From my perspective, it
> seems like "security relationship" would be more accurate terminology.

The mobile node is expected to produce authentication data according
to the security algorithm configured for its use with AAA.   I think
this corresponds exactly with the typical use of the terminology.
A security relationship would be more general than is intended here.
But since I don't know exactly what that term means, it's hard to
be sure.  Maybe the security relationship is the thing that precedes
and enables the creation of the security association.

> Note that the above paragraph also talks about "security associations"
> between the MN and HA. Here, the terminology  (I suspect) corresponds
> more closely to the IPsec usage. But I'm not sure.

I've included a Terminology section.  I hope this isn't opening another
huge can of worms, but I'm very happy to accept suggestions on how
to make appropriate and succinct defintions.

> General comment. This document is very loose about whether a MN is
> talking to a FA/HA or a AAA server. This should be made explicitly
> clear throughout. Indeed, my assumption is that conceptually, if not
> in reality, a MN NEVER speaks to an AAA server directly. Rather, it
> speaks MIP protocols with an HA/FA, and that HA/FA has a side
> conversation with the AAA server. This should be made much more clear
> throughout.

O.K.  I will try to do this.

>> 2. Scope of Protocol
>>
>>    The protocol and messages in this document are intended to facilitate
>>    the following operations which may occur between the mobile node, AAA
>>    server, home agent, and foreign agent.
>
> Throughout this section, it should be made explicitly clear *who* is
> sending a message, and *to* *whom* the message is being sent. Also,
> when someone processes an extension *who* is doing the
> processing. This isn't clear from just reading the text.

I'll give it a shot.  Let me know if I succeed -- or fail.

> Also, it might make sense to change the section heading to "overview"
> rather than Scope, since it does seem like an overview. Assuming this
> is an overview, I think it would help the reader if the text included
> steps such as as "FA sends message to AAA server ..." "AAA server does
> X and returns Y to the FA", "FA generates reply and sends to MN"...

O.K.  I have attempted to do this.

>     2. If the mobile node does not have a Mobility Security Association
>        with the foreign agent, it SHOULD include an MN-FA Key Request
>        extension.
>
> In what message, and sent to whom?

As part of its Registration Request that it sends to the Foreign Agent.

> What is the RFC reference to the key request extension?

It's defined later in the document.  I've added a cross reference.

>     3. Similarly, if the mobile node does not have a Mobility Security
>        Association with the home agent, it MUST add an MN-HA Key Request
>        extension.
>
> In message sent to whom?

As part of its Registration Request that it sends to the Foreign Agent.

>     4. If one or more Key Request extensions were added, the MN-AAA
>        Authentication extension is added to the Registration Request.
>
> Added by whom?

The mobile node.

>     5. At the time the information within the MN-AAA Authentication
>        extension is verified by the AAA server, the AAA server also
>        generates Key Material for the keys requested by the mobile node,
>        and causes insertion of the Key Material fields along with the
>        Registration Reply.
>
> So there is an implied step here in which the FA exchanges messages
> with its local AAA server? Would be good to explicitely say that here.

I have made it more explicit.

> Is that AAA protocol already in place? What RFCs are used? I.e, is
> there a potential normative reference problem buried here? (I suspect
> the answer is no, but am not sure.)

The intention was to keep the formulation general, and not dependent
on the specifics of the AAA protocol.

>     6. The respective AAA keys are distributed to the Home and Foreign
>        Agent via the AAA protocol.
>
> Where are the details of this described?

It is out of scope for this document, and I hope it does not have
to be specfied as part of a normative reference.  All that we
should have to do is to specify how the Mobile IP extensions work.

According to this philosophy, some of the steps in the Overview
amount to over-specification, but I don't think there is any
serious problem so O.K.

> step 6b) FA sends a reply to the MN
>
>>    extension.  In order for the mobile node to make use of key
>>    information sent to it by the AAA server, the mobile node also has to
>>    be able to select the appropriate cryptographic algorithm that uses
>>    the key to produce the authentication.  The following table contains
>
> I doubt the AAA server is sending messages to the MN. Isn't it the FA
> that does this (i.e., it relays this info)? Text could be more
> precise.

I reworded this to say that the AAA server "creates" the
key information.

>    Dynamic Mobility Security Associations shared between mobile nodes
>
> What is a "Dynamic Mobility Security Association"? Is it different
> than other types of security associations?

Well, it's not manually configured.   Isn't this well-known usage?
Do we have to say "dynamically created"?  Otherwise, it is the
same as the mobility security association defined in RFC 2002.

> Note: IMO, it would be better to move the description formats of the
> extensions here, rather than at the end. It is a bit confusing to talk
> about the contents of packet fields prior to having shown the format
> of the option with all of the fields together.

I didn't see where the packet fields were mentioned.  We used
the name of some extensions that were defined in RFC 2002.
The tables supply parameter values for some fields in the
extension formats, but that's as close as I could get to
understanding your request here.  Maybe we should move the
tables after the formats?

>> 4. Key Material Creation and Derivation
>>
>>    This section contains the procedures followed in the creation of the
>>    Key Material by AAA servers, and the key derivation procedures used
>                                 ^
>>    by mobile nodes.  Note that the AAA servers will also make use of the
>
> insert "extension" as indicated above? Also, better to say "contains
> the procedure a FA/HA follows when creating ..." (or is the procedure
> aimed at AAA servers?)

The procedure is aimed at AAA servers, and I couldn't parse the result
when I put "extension" where you indicated.  The idea is that AAA
servers will do something that is able to be understood by mobile
nodes, and that mobility agents (home agent, foreign agent) will
faithfully transcribe the results into the appropriate Mobile IP
extensions.  I have added those words to this introductory
paragraph.  It is still intended to avoid normative references
here for any AAA protocol.  If necessary, we could create an
applicability statement and use it along with the introductory section.

>    The example that follows makes use of MD5 in prefix+suffix mode,
>    whose support is mandatory in Mobile IP [11].  Other cryptographic
>    functions, such as those listed in 3 MAY also be used.
>
> Might be better to make HMAC-MD5 the example. Also, what is meant be
> "listed in 3 MAY". Should that be "listed in [3] MAY"??

That was supposed to be Section 3.

>     1. The AAA server identifies the mobile node's via a
>        ``node-address''.  If the Home Address field of the
>        Registration Request is zero (0), the Mobile Node's NAI is used
>        instead.
>
> First sentence doesn't parse.

Fixed!

> I'm confused by the description above in the sense that it implies
> that the MN Registration Request is sent to a AAA server. I thought it
> was sent to a FA.

Here, one has to understand the contents of RFC 2977.  I have added
a lot of text to that effect in the Introduction.  I hope that's
sufficient.  Otherwise, we would have to start copying text from
that document.

> Also, why use the term "node-address"? Don't you really mean the home
> address? (the term node-address isn't defined anywhere).

Fixed.

>  Maybe you mean to say:
>
>     1. The AAA server identifies the mobile node via a
>        ``node-address''.  The node-address is taken from the Home
>        Address field of the Registration Request, or the NAI, if the
>        Home Address field is zero (0).
>
> Note again how the text blurs the distinction between the FA and the
> AAA server. Does the AAA server see the registration request? I would
> think not. It sees information the FA sends to it, which includes
> portions of the registration request. The document should really make
> this clear throughout

I fixed this, I hope.  I also hope it would be clear to someone
who went through the discussion in RFC 2977.

>>    2. The AAA server generates a random [5] value of at least 64 bits.
>
> 64 bits seems short. I'd like someone with security background to
> comment on this. But I guess this is sent in the clear, so the length
> may not matter?

That makes sense to me.

>     3. The AAA server inserts the random value into the Key extension in
>        the ``Key Material'' field.
>
> Presumably this field is part of a message or an extension within a
> message. Which message or extension? Make explicit.

The example is supposed to work for any Key Material extension.

> Note steps 1-3 are done on the server, steps 4-5 on the mobile
> node. It might be good to make the more clear here, perhaps by having
> subsections?

O.K.  I did it, but I don't know if it's an improvement or not.

>     4. The mobile node calculates
>
>           key = MD5(AAA-key | Key Material | node-address | AAA-key)
>
> what is AAA-key? Where does it come from? Ditto for "Key Material" How
> does the mobile node know which AAA-key to use? Can there only be one
> (I hope not...)

The AAA-key is what the mobile node shares with the AAA server.
The Key Material is the 64 random bits.

>       Key Material
>                  A random [5] value of at least 64 bits.
>
> Keying material of only 64 bits? Would this pass security muster??

I reckon it will, but I'm not betting my house on it.  The cryptographic
strength of the algorithm doesn't depend on this number.

>>       AAA SPI    A 32-bit opaque value, indicating the SPI that the
>>                  mobile node must use to determine the algorithm to use
>>                  for establishing the FA security information.
>
> How does the mobile node create this SPI? Is this preconfigured?

Yes, or at least out of scope for this document.

>>       FA SPI     A 32-bit opaque value, which the mobile node MUST use
>>                  to index all the necessary information established for
>>                  the FA security information after it is decoded.
>
> Might be better to say something like:
>
>        FA SPI     The SPI for the Security Association to the FA that
>                   the MN creates as a result of processing this extension.

Done.

>>    The Unsolicited MN-FA Key Material From AAA extension, shown
>>    in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply
>>    Extension [12].
>
> Shouldn't this be moved to the beginning of section 5. (e.g., as it is
> in Section 6?)

Done!

>>       HA SPI     A 32-bit opaque value, which the mobile node MUST use
>>                  to index all the necessary information established for
>>                  the HA security information after it is decoded.
>
> Same comment as above w.r.t FA SPI. Ditto for key material.

Done.

>>    the Key Material provided by the home domain AAA server (AAAH). The
>>    key is intended for use the mobile node to secure future Mobile IP
>>    registrations with its home agent.  The MN-HA Key Reply MUST appear
>
> sentence doesn't parse.

Fixed.

>>    The mobile node uses the Identification field data from the
>>    Registration Request as its initial synchronization data with the
>>    home agent.
>
> What is the field referred to in this sentence?

If you look at the Registration Request format, there is a field
called the Identification field.  It allows entities using Mobile IP
to associated a Registration Reply to the appropriate Registration
Request.

I don't know if you meant to suggest adding text or not, but I wouldn't
feel it was appropriate to copy text from RFC 2002{,bis} here.

>> 7. MN-FA Key Request From AAA Subtype
>>
>>    The MN-FA Key Request From AAA subtype data uses subtype 7 of the
>>    Generalized MN-FA Key Request Extension [12].  The MN-FA Key Request
>>    From AAA extension MUST appear in the Registration Request before the
>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>    length.
>>
>>
>> 8. MN-HA Key Request From AAA Subtype
>>
>>    The MN-HA Key Request From AAA subtype data uses subtype 7 of the
>>    Generalized MN-HA Key Request Extension [12].  The MN-HA Key Request
>>    From AAA extension MUST appear in the Registration Request before the
>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>    length.
>
> Hmm. What are the above two sections about? The first sentence in each
> seems redundent. Can't the remaining text just be put in the previous
> sections that describe the extension?

The extensions, which are Request extensions (not Reply extensions),
are defined in the Generalized Keys document, and don't have any
additional format that needs to be specfied.

> Also, why is the ordering important?

The MN-AAA Authentication extension is an "authorization-enabling"
extension, in the language of RFC 2002bis.  Such extensions have
to be last.


>> 10. IANA Considerations
>
> This document requests certain numbers be assigned. Is this required,
> i.e., are their implementations that already use the numbers? This
> section should really say TBD for any assignments that it  doesn't
> care what the  actual value is, and let IANA pick. If it really does
> care about the value, the text should suggest a certain value be used
> and mention that the numbers are already in use by existing
> implementations. That way, IANA has some context for deciding what to
> do.

The numbers are already in use by implementations.   I have added text
to the IANA Considerations to that effect.

>>    Section 3 introduces the Algorithm Identifier namespace that requires
>>    IANA management.  This specification makes use of 1-3; all other
>>    values other than zero (0) are available for assignment, pending
>>    review and approval by a Designated Expert [9].
>
> Can't you just leverage off an existing MIP name space (i.e, the one
> used by other extensions?) rather than creating a new one?

See above (***).


Regards,
Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 12:44:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07672
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 12:44:47 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12649;
	Tue, 9 Oct 2001 10:43:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27408;
	Tue, 9 Oct 2001 09:43:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99GguML025289
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:42:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99Gguhu025287
	for mobile-ip-dist; Tue, 9 Oct 2001 09:42:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99GgqML025279
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:42:52 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27054
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:42:52 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04284
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 09:42:54 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA15346;
	Tue, 9 Oct 2001 09:41:08 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f99Gf8c02011;
	Tue, 9 Oct 2001 09:41:08 -0700
X-mProtect:  Tue, 9 Oct 2001 09:41:08 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdI4xBqo; Tue, 09 Oct 2001 09:41:06 PDT
Message-ID: <3BC328A1.FCFB860@iprg.nokia.com>
Date: Tue, 09 Oct 2001 09:41:05 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "S.Mizikovsky" <smizikovsky@lucent.com>
CC: mobile-ip@sunroof.eng.sun.com, Christopher.Carroll@verizonwireless.com
Subject: Re: [mobile-ip] IESG feedback on AAA keys doc
References: <NFBBJIDMALLOJCAJGAPJIEEDCHAA.smizikovsky@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello folks,

While I agree with you that these numbers should probably be
allocated once the algorithms are finalized, I would somehow
be surprised if "AAA Registration Keys for Mobile IP" were the
appropriate document in which the specification should be
included.  HMAC-MD5 is mandated in the draft, so it seems much
more appropriate for specification.

Changing Mobile IP itself to use PRF variants would require
discussion far beyond the topic at hand, which is how to revise
this document to incorporate improvements and suggestions
from comments received during IESG review; this is already
after Working Group Last Call.

That still doesn't mean it's impossible, it just means that
it will be harder to convince people to do it.

Regards,
Charlie P.

PS. Give my regards to Uri.


"S.Mizikovsky" wrote:
> 
> Dear Mr. Perkins,
> 
> At the last IETF conference, Uri Blumenthal of Lucent Technologies submitted
> the proposal for PRF based on SHA-1 with recommendation to use it for
> generation of key material.
> 
> As I am sure you would agree, although both MD5 and SHA-1 are highly
> regarded for their MAC properties, neither is widely accepted as a PRF - a
> property which is specifically significant when registration, session, and
> other key material is produced as the result of running these functions.
> Although discussions over Uri's proposal are still in progress, we suggest
> to consider reserving at least 4 values for practical variations of PRF
> based on SHA-1 and MD5.
> 
> As Uri is on a vacation this week, could you, please, copy all respective
> comments to me.
> 
> Thank you
> 
> Semyon Mizikovsky
> Technical Manager, Security & Fraud prevention
> Lucent Technologies, Inc.
> Wireless Standards Department
> 67 Whippany Rd., 14D-314, Whippany, NJ 07981
> (973) 386-6348
> 
> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Monday, October 08, 2001 9:43 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Pat Calhoun; Basavaraj Patil (NTC/Dallas); Phil Roberts
> Subject: Re: [mobile-ip] IESG feedback on AAA keys doc
> 
> Hello folks,
> 
> After a few weeks of discussion, I have prepared a new
> version of the document, "AAA Registration Keys for Mobile IP".
> Except for proofreading, it's almost ready to be sent in as a
> revised Internet Draft, and it's available at:
>         http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt
> 
> I'll hold off for a little while, in case someone can tell me how
> to resolve the IESG comment about security algorithm IANA namespaces,
> which to expedite discussion I have moved first in the discussion
> below, but which is out of order from the original e-mail from the
> IESG.
> 
> Here, starts the follow-on from the IESG comments.
> 
> >>       Algorithm Identifier
> >>                  This field indicates the algorithm to be used for
> >>                  future computations of the MN-FA Authentication
> >>                  Extension (see section 3)
> >
> > It would be good to state explicitely state that this is the same
> > algorithm identifier as defined in XXX (section 3 doesn't seem to do
> > this either). This document doesn't say. I.e., this presumably points
> > to an existing name space managed by IANA. What is it? [hmm I later
> > see that this is a new name space.. see comment below.]
> 
> I am happy to use another existing name space, but the only
> one I find doesn't have HMAC-MD5 in it:
> 
> ========================================================================
>   Hash Algorithm                     Value            References
>   --------------                     -----            ----------
>   MD5                                  1               [RFC1321]
>   SHA                                  2              FIPS 180-1
>   Tiger                                3              See Reference [TIGER]
>   SHA2-256                             4                 [Leech]
>   SHA2-384                             5                 [Leech]
>   SHA2-512                             6                 [Leech]
> ========================================================================
> 
> Should we define some more values?  How do I find out the up-to-date
> list?  Is this list being actively maintained?  If we use this list,
> do we have to wait until someone actively figures out the right way
> to keep this list up-to-date (assuming that it is not now). (***)
> 
> ...........  (now, from the top) ..............
> 
> > This is a comment that probably applies to lots of MIP
> > documents. Please define "security association" in the MIP context. In
> > IPsec terminology, for instance, it means something very
> > specific. I.e., keys, SPIs, etc., and works only between a pair of
> > nodes. Once an association exists, encrypted packets can be sent. No
> > further negotiation is needed. Also, one can have multiple (different
> > SAs between the same set of machines). This document says:
> >
> >    node and its home agent.  When the mobile node shares a security
> >    association with its home AAA server, however, it is possible to use
> >    that security association to create derivative security associations
> >    between the mobile node and its home agent, and again between the
> >    mobile node and the foreign agent currently offering connectivity to
> >    the mobile node.  This document specifies extensions to the Mobile
> >
> > The MN talks to its HA, not a AAA server. So I'm not clear what is
> > meant by "shares a security association". From my perspective, it
> > seems like "security relationship" would be more accurate terminology.
> 
> The mobile node is expected to produce authentication data according
> to the security algorithm configured for its use with AAA.   I think
> this corresponds exactly with the typical use of the terminology.
> A security relationship would be more general than is intended here.
> But since I don't know exactly what that term means, it's hard to
> be sure.  Maybe the security relationship is the thing that precedes
> and enables the creation of the security association.
> 
> > Note that the above paragraph also talks about "security associations"
> > between the MN and HA. Here, the terminology  (I suspect) corresponds
> > more closely to the IPsec usage. But I'm not sure.
> 
> I've included a Terminology section.  I hope this isn't opening another
> huge can of worms, but I'm very happy to accept suggestions on how
> to make appropriate and succinct defintions.
> 
> > General comment. This document is very loose about whether a MN is
> > talking to a FA/HA or a AAA server. This should be made explicitly
> > clear throughout. Indeed, my assumption is that conceptually, if not
> > in reality, a MN NEVER speaks to an AAA server directly. Rather, it
> > speaks MIP protocols with an HA/FA, and that HA/FA has a side
> > conversation with the AAA server. This should be made much more clear
> > throughout.
> 
> O.K.  I will try to do this.
> 
> >> 2. Scope of Protocol
> >>
> >>    The protocol and messages in this document are intended to facilitate
> >>    the following operations which may occur between the mobile node, AAA
> >>    server, home agent, and foreign agent.
> >
> > Throughout this section, it should be made explicitly clear *who* is
> > sending a message, and *to* *whom* the message is being sent. Also,
> > when someone processes an extension *who* is doing the
> > processing. This isn't clear from just reading the text.
> 
> I'll give it a shot.  Let me know if I succeed -- or fail.
> 
> > Also, it might make sense to change the section heading to "overview"
> > rather than Scope, since it does seem like an overview. Assuming this
> > is an overview, I think it would help the reader if the text included
> > steps such as as "FA sends message to AAA server ..." "AAA server does
> > X and returns Y to the FA", "FA generates reply and sends to MN"...
> 
> O.K.  I have attempted to do this.
> 
> >     2. If the mobile node does not have a Mobility Security Association
> >        with the foreign agent, it SHOULD include an MN-FA Key Request
> >        extension.
> >
> > In what message, and sent to whom?
> 
> As part of its Registration Request that it sends to the Foreign Agent.
> 
> > What is the RFC reference to the key request extension?
> 
> It's defined later in the document.  I've added a cross reference.
> 
> >     3. Similarly, if the mobile node does not have a Mobility Security
> >        Association with the home agent, it MUST add an MN-HA Key Request
> >        extension.
> >
> > In message sent to whom?
> 
> As part of its Registration Request that it sends to the Foreign Agent.
> 
> >     4. If one or more Key Request extensions were added, the MN-AAA
> >        Authentication extension is added to the Registration Request.
> >
> > Added by whom?
> 
> The mobile node.
> 
> >     5. At the time the information within the MN-AAA Authentication
> >        extension is verified by the AAA server, the AAA server also
> >        generates Key Material for the keys requested by the mobile node,
> >        and causes insertion of the Key Material fields along with the
> >        Registration Reply.
> >
> > So there is an implied step here in which the FA exchanges messages
> > with its local AAA server? Would be good to explicitely say that here.
> 
> I have made it more explicit.
> 
> > Is that AAA protocol already in place? What RFCs are used? I.e, is
> > there a potential normative reference problem buried here? (I suspect
> > the answer is no, but am not sure.)
> 
> The intention was to keep the formulation general, and not dependent
> on the specifics of the AAA protocol.
> 
> >     6. The respective AAA keys are distributed to the Home and Foreign
> >        Agent via the AAA protocol.
> >
> > Where are the details of this described?
> 
> It is out of scope for this document, and I hope it does not have
> to be specfied as part of a normative reference.  All that we
> should have to do is to specify how the Mobile IP extensions work.
> 
> According to this philosophy, some of the steps in the Overview
> amount to over-specification, but I don't think there is any
> serious problem so O.K.
> 
> > step 6b) FA sends a reply to the MN
> >
> >>    extension.  In order for the mobile node to make use of key
> >>    information sent to it by the AAA server, the mobile node also has to
> >>    be able to select the appropriate cryptographic algorithm that uses
> >>    the key to produce the authentication.  The following table contains
> >
> > I doubt the AAA server is sending messages to the MN. Isn't it the FA
> > that does this (i.e., it relays this info)? Text could be more
> > precise.
> 
> I reworded this to say that the AAA server "creates" the
> key information.
> 
> >    Dynamic Mobility Security Associations shared between mobile nodes
> >
> > What is a "Dynamic Mobility Security Association"? Is it different
> > than other types of security associations?
> 
> Well, it's not manually configured.   Isn't this well-known usage?
> Do we have to say "dynamically created"?  Otherwise, it is the
> same as the mobility security association defined in RFC 2002.
> 
> > Note: IMO, it would be better to move the description formats of the
> > extensions here, rather than at the end. It is a bit confusing to talk
> > about the contents of packet fields prior to having shown the format
> > of the option with all of the fields together.
> 
> I didn't see where the packet fields were mentioned.  We used
> the name of some extensions that were defined in RFC 2002.
> The tables supply parameter values for some fields in the
> extension formats, but that's as close as I could get to
> understanding your request here.  Maybe we should move the
> tables after the formats?
> 
> >> 4. Key Material Creation and Derivation
> >>
> >>    This section contains the procedures followed in the creation of the
> >>    Key Material by AAA servers, and the key derivation procedures used
> >                                 ^
> >>    by mobile nodes.  Note that the AAA servers will also make use of the
> >
> > insert "extension" as indicated above? Also, better to say "contains
> > the procedure a FA/HA follows when creating ..." (or is the procedure
> > aimed at AAA servers?)
> 
> The procedure is aimed at AAA servers, and I couldn't parse the result
> when I put "extension" where you indicated.  The idea is that AAA
> servers will do something that is able to be understood by mobile
> nodes, and that mobility agents (home agent, foreign agent) will
> faithfully transcribe the results into the appropriate Mobile IP
> extensions.  I have added those words to this introductory
> paragraph.  It is still intended to avoid normative references
> here for any AAA protocol.  If necessary, we could create an
> applicability statement and use it along with the introductory section.
> 
> >    The example that follows makes use of MD5 in prefix+suffix mode,
> >    whose support is mandatory in Mobile IP [11].  Other cryptographic
> >    functions, such as those listed in 3 MAY also be used.
> >
> > Might be better to make HMAC-MD5 the example. Also, what is meant be
> > "listed in 3 MAY". Should that be "listed in [3] MAY"??
> 
> That was supposed to be Section 3.
> 
> >     1. The AAA server identifies the mobile node's via a
> >        ``node-address''.  If the Home Address field of the
> >        Registration Request is zero (0), the Mobile Node's NAI is used
> >        instead.
> >
> > First sentence doesn't parse.
> 
> Fixed!
> 
> > I'm confused by the description above in the sense that it implies
> > that the MN Registration Request is sent to a AAA server. I thought it
> > was sent to a FA.
> 
> Here, one has to understand the contents of RFC 2977.  I have added
> a lot of text to that effect in the Introduction.  I hope that's
> sufficient.  Otherwise, we would have to start copying text from
> that document.
> 
> > Also, why use the term "node-address"? Don't you really mean the home
> > address? (the term node-address isn't defined anywhere).
> 
> Fixed.
> 
> >  Maybe you mean to say:
> >
> >     1. The AAA server identifies the mobile node via a
> >        ``node-address''.  The node-address is taken from the Home
> >        Address field of the Registration Request, or the NAI, if the
> >        Home Address field is zero (0).
> >
> > Note again how the text blurs the distinction between the FA and the
> > AAA server. Does the AAA server see the registration request? I would
> > think not. It sees information the FA sends to it, which includes
> > portions of the registration request. The document should really make
> > this clear throughout
> 
> I fixed this, I hope.  I also hope it would be clear to someone
> who went through the discussion in RFC 2977.
> 
> >>    2. The AAA server generates a random [5] value of at least 64 bits.
> >
> > 64 bits seems short. I'd like someone with security background to
> > comment on this. But I guess this is sent in the clear, so the length
> > may not matter?
> 
> That makes sense to me.
> 
> >     3. The AAA server inserts the random value into the Key extension in
> >        the ``Key Material'' field.
> >
> > Presumably this field is part of a message or an extension within a
> > message. Which message or extension? Make explicit.
> 
> The example is supposed to work for any Key Material extension.
> 
> > Note steps 1-3 are done on the server, steps 4-5 on the mobile
> > node. It might be good to make the more clear here, perhaps by having
> > subsections?
> 
> O.K.  I did it, but I don't know if it's an improvement or not.
> 
> >     4. The mobile node calculates
> >
> >           key = MD5(AAA-key | Key Material | node-address | AAA-key)
> >
> > what is AAA-key? Where does it come from? Ditto for "Key Material" How
> > does the mobile node know which AAA-key to use? Can there only be one
> > (I hope not...)
> 
> The AAA-key is what the mobile node shares with the AAA server.
> The Key Material is the 64 random bits.
> 
> >       Key Material
> >                  A random [5] value of at least 64 bits.
> >
> > Keying material of only 64 bits? Would this pass security muster??
> 
> I reckon it will, but I'm not betting my house on it.  The cryptographic
> strength of the algorithm doesn't depend on this number.
> 
> >>       AAA SPI    A 32-bit opaque value, indicating the SPI that the
> >>                  mobile node must use to determine the algorithm to use
> >>                  for establishing the FA security information.
> >
> > How does the mobile node create this SPI? Is this preconfigured?
> 
> Yes, or at least out of scope for this document.
> 
> >>       FA SPI     A 32-bit opaque value, which the mobile node MUST use
> >>                  to index all the necessary information established for
> >>                  the FA security information after it is decoded.
> >
> > Might be better to say something like:
> >
> >        FA SPI     The SPI for the Security Association to the FA that
> >                   the MN creates as a result of processing this extension.
> 
> Done.
> 
> >>    The Unsolicited MN-FA Key Material From AAA extension, shown
> >>    in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply
> >>    Extension [12].
> >
> > Shouldn't this be moved to the beginning of section 5. (e.g., as it is
> > in Section 6?)
> 
> Done!
> 
> >>       HA SPI     A 32-bit opaque value, which the mobile node MUST use
> >>                  to index all the necessary information established for
> >>                  the HA security information after it is decoded.
> >
> > Same comment as above w.r.t FA SPI. Ditto for key material.
> 
> Done.
> 
> >>    the Key Material provided by the home domain AAA server (AAAH). The
> >>    key is intended for use the mobile node to secure future Mobile IP
> >>    registrations with its home agent.  The MN-HA Key Reply MUST appear
> >
> > sentence doesn't parse.
> 
> Fixed.
> 
> >>    The mobile node uses the Identification field data from the
> >>    Registration Request as its initial synchronization data with the
> >>    home agent.
> >
> > What is the field referred to in this sentence?
> 
> If you look at the Registration Request format, there is a field
> called the Identification field.  It allows entities using Mobile IP
> to associated a Registration Reply to the appropriate Registration
> Request.
> 
> I don't know if you meant to suggest adding text or not, but I wouldn't
> feel it was appropriate to copy text from RFC 2002{,bis} here.
> 
> >> 7. MN-FA Key Request From AAA Subtype
> >>
> >>    The MN-FA Key Request From AAA subtype data uses subtype 7 of the
> >>    Generalized MN-FA Key Request Extension [12].  The MN-FA Key Request
> >>    From AAA extension MUST appear in the Registration Request before the
> >>    MN-AAA Authentication extension.  The subtype data field is zero in
> >>    length.
> >>
> >>
> >> 8. MN-HA Key Request From AAA Subtype
> >>
> >>    The MN-HA Key Request From AAA subtype data uses subtype 7 of the
> >>    Generalized MN-HA Key Request Extension [12].  The MN-HA Key Request
> >>    From AAA extension MUST appear in the Registration Request before the
> >>    MN-AAA Authentication extension.  The subtype data field is zero in
> >>    length.
> >
> > Hmm. What are the above two sections about? The first sentence in each
> > seems redundent. Can't the remaining text just be put in the previous
> > sections that describe the extension?
> 
> The extensions, which are Request extensions (not Reply extensions),
> are defined in the Generalized Keys document, and don't have any
> additional format that needs to be specfied.
> 
> > Also, why is the ordering important?
> 
> The MN-AAA Authentication extension is an "authorization-enabling"
> extension, in the language of RFC 2002bis.  Such extensions have
> to be last.
> 
> >> 10. IANA Considerations
> >
> > This document requests certain numbers be assigned. Is this required,
> > i.e., are their implementations that already use the numbers? This
> > section should really say TBD for any assignments that it  doesn't
> > care what the  actual value is, and let IANA pick. If it really does
> > care about the value, the text should suggest a certain value be used
> > and mention that the numbers are already in use by existing
> > implementations. That way, IANA has some context for deciding what to
> > do.
> 
> The numbers are already in use by implementations.   I have added text
> to the IANA Considerations to that effect.
> 
> >>    Section 3 introduces the Algorithm Identifier namespace that requires
> >>    IANA management.  This specification makes use of 1-3; all other
> >>    values other than zero (0) are available for assignment, pending
> >>    review and approval by a Designated Expert [9].
> >
> > Can't you just leverage off an existing MIP name space (i.e, the one
> > used by other extensions?) rather than creating a new one?
> 
> See above (***).
> 
> Regards,
> Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 13:12:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08378
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 13:12:39 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08796;
	Tue, 9 Oct 2001 11:11:43 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04961;
	Tue, 9 Oct 2001 10:11:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HAcML025550
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:10:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99HAcOn025549
	for mobile-ip-dist; Tue, 9 Oct 2001 10:10:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HAYML025542
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:10:34 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10639
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:10:36 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02738
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:10:36 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA17721
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:10:35 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f99HAYR29540
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:10:34 -0700
X-mProtect:  Tue, 9 Oct 2001 10:10:34 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdfipIgA; Tue, 09 Oct 2001 10:10:33 PDT
Message-ID: <3BC32F89.652FBED7@iprg.nokia.com>
Date: Tue, 09 Oct 2001 10:10:33 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

hi Hesham,

comments below

> "Hesham Soliman (EPA)" wrote:
> 
>      >
>      >      => You've mentioned this a few times now and  think it's
>      >      misleading at best. Are you suggesting that if we all
>      agreed
>      >      today
>      >      to go ahead with the Auth data suboption, then the MIPv6
>      >      draft will be ready ?
>      >      Nothing else to solve for the security
>      >      issues ? No key exchange problem (much bigger than what
>      >      we're discussing now btw) ?
> 
>      Auth Data suboption does not solve the key exchange problem. it
>      solves the problem of how to protect the BU once the keys
>      have been created between the MN and the CN. it is an alternative
> 
>      to using AH and ESP.
> 
>      => Agreed.
> 
>      The MIPv6 draft talks about how to protect the BU. it does not
>      talk about the key exchange problem. that is done in a bunch of
>      drafts (BAKE, SUCV, PBK, Home Agent cookies...). so if we agree
>      on using the suboption, MIPv6 draft can move ahead.
> 
>      => See below.
> 
>      Thats what I meant. and I did not intend to mislead anyone.
>      its you and few others who are holding the MIPv6 draft to ransom
>      by citing that it does not work with AH. So what? if it does not
>      work with AH, lets move ahead. lets find an alternative solution.
> 
>      => Heh :) This is too much credit to give me or anyone else.
>      My understanding was that based on the IESG comments
>      the draft could not go ahead without specifying the key
>      exchange mechanism that can be used in the absence
>      of IKE. So your comment about the draft going ahead
>      without the key exchange mechanism doesn't seem to
>      be inline with the IESG comments. I'd love to know if
>      this is a wrong interpretation of the IESG position.
>      This is why I think it's misleading to say that the BU
>      protection is the only thing holding the draft back.
> 

IESG told us two things. ( I was there at the meeting with
the security ADs at the San Diego IETF last December ).

1. AH in its current form cannot be used for protecting the BU. 
Develop an alternative solution. 

2. Develop a Key distribution mechanism for MN and CN.

For the first one, the Auth Data suboption is the solution.
For the second one, we have a requirements draft and a lot of
competing proposals. We should be concentrating on this. and
NOT how we can modify things (disable piggybacking, get a 
new extension header) so that AH can be used for protecting
the BU.

The MIPv6 draft will not have the key distribution mechanism
embedded in it. It will just refer to another draft. It will 
only specify how the BU can be protected. So if we agree 
on the Auth Data suboption, we can conclude that the draft
is complete. and no further changes need to be made. (maybe
a few minor ones). thats what I meant by moving ahead.

and from you mail, you seem to say the key distribution 
mechanism is the main problem. great. thats what i wanted
to hear from you. hope, you would stop talking about how
AH can be used to protect the BU from now on.

Vijay


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 13:25:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08887
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 13:25:01 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19513;
	Tue, 9 Oct 2001 11:23:51 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08149;
	Tue, 9 Oct 2001 10:23:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HMnML025693
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:22:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99HMnko025692
	for mobile-ip-dist; Tue, 9 Oct 2001 10:22:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HMjML025685
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:22:45 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28332
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:22:48 -0700 (PDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29499
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:23:59 -0600 (MDT)
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f99HMjo25235
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 13:22:45 -0400 (EDT)
Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA10534; Tue, 9 Oct 2001 13:22:43 -0400 (EDT)
To: charliep@iprg.nokia.com
Cc: <mobile-ip@sunroof.eng.sun.com>, <Christopher.Carroll@verizonwireless.com>
Received: from nj0117semyonmi by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA10404; Tue, 9 Oct 2001 13:22:11 -0400 (EDT)
From: "S.Mizikovsky" <smizikovsky@lucent.com>
Original-To: <charliep@iprg.nokia.com>
Original-Cc: <mobile-ip@sunroof.eng.sun.com>, <Christopher.Carroll@verizonwireless.com>
Subject: RE: [mobile-ip] IESG feedback on AAA keys doc
Date: Tue, 9 Oct 2001 13:20:16 -0400
Message-ID: <NFBBJIDMALLOJCAJGAPJCEEGCHAA.smizikovsky@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3BC328A1.FCFB860@iprg.nokia.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Charles, thank you for your note. You are probably right in your assessment,
although not knowing dynamics of your group, I would rather rely on Uri's
recommendation when he returns.

From our point of view, neither SHA-1/MD5 nor HMAC-SHA/HMAC-MD5 are good
enough for producing key material. They are good to compute MAC, as that is
what they were designed for - collision resistance and MAC properties.
Generation of cryptographic keys requires randomness in the result, which
only PRF can guarantee (up-to certain extend). Discussion over this issue
has already been going in the Network Working Group. Uri can share details
with you, when he comes back.

I do appreciate your recommendation to allocate specific numbers when
standardization of the PRF is completed. I just want to trust that there
will be enough reserved numbers when it happens.

Thank you again

Semyon Mizikovsky
Technical Manager, Security & Fraud prevention
Lucent Technologies, Inc.
Wireless Standards Department
67 Whippany Rd., 14D-314, Whippany, NJ 07981
(973) 386-6348





-----Original Message-----
From: charliep@iprg.nokia.com [mailto:charliep@iprg.nokia.com]
Sent: Tuesday, October 09, 2001 12:41 PM
To: S.Mizikovsky
Cc: mobile-ip@sunroof.eng.sun.com;
Christopher.Carroll@verizonwireless.com
Subject: Re: [mobile-ip] IESG feedback on AAA keys doc



Hello folks,

While I agree with you that these numbers should probably be
allocated once the algorithms are finalized, I would somehow
be surprised if "AAA Registration Keys for Mobile IP" were the
appropriate document in which the specification should be
included.  HMAC-MD5 is mandated in the draft, so it seems much
more appropriate for specification.

Changing Mobile IP itself to use PRF variants would require
discussion far beyond the topic at hand, which is how to revise
this document to incorporate improvements and suggestions
from comments received during IESG review; this is already
after Working Group Last Call.

That still doesn't mean it's impossible, it just means that
it will be harder to convince people to do it.

Regards,
Charlie P.

PS. Give my regards to Uri.


"S.Mizikovsky" wrote:
>
> Dear Mr. Perkins,
>
> At the last IETF conference, Uri Blumenthal of Lucent Technologies
submitted
> the proposal for PRF based on SHA-1 with recommendation to use it for
> generation of key material.
>
> As I am sure you would agree, although both MD5 and SHA-1 are highly
> regarded for their MAC properties, neither is widely accepted as a PRF - a
> property which is specifically significant when registration, session, and
> other key material is produced as the result of running these functions.
> Although discussions over Uri's proposal are still in progress, we suggest
> to consider reserving at least 4 values for practical variations of PRF
> based on SHA-1 and MD5.
>
> As Uri is on a vacation this week, could you, please, copy all respective
> comments to me.
>
> Thank you
>
> Semyon Mizikovsky
> Technical Manager, Security & Fraud prevention
> Lucent Technologies, Inc.
> Wireless Standards Department
> 67 Whippany Rd., 14D-314, Whippany, NJ 07981
> (973) 386-6348
>
> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Monday, October 08, 2001 9:43 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Pat Calhoun; Basavaraj Patil (NTC/Dallas); Phil Roberts
> Subject: Re: [mobile-ip] IESG feedback on AAA keys doc
>
> Hello folks,
>
> After a few weeks of discussion, I have prepared a new
> version of the document, "AAA Registration Keys for Mobile IP".
> Except for proofreading, it's almost ready to be sent in as a
> revised Internet Draft, and it's available at:
>         http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt
>
> I'll hold off for a little while, in case someone can tell me how
> to resolve the IESG comment about security algorithm IANA namespaces,
> which to expedite discussion I have moved first in the discussion
> below, but which is out of order from the original e-mail from the
> IESG.
>
> Here, starts the follow-on from the IESG comments.
>
> >>       Algorithm Identifier
> >>                  This field indicates the algorithm to be used for
> >>                  future computations of the MN-FA Authentication
> >>                  Extension (see section 3)
> >
> > It would be good to state explicitely state that this is the same
> > algorithm identifier as defined in XXX (section 3 doesn't seem to do
> > this either). This document doesn't say. I.e., this presumably points
> > to an existing name space managed by IANA. What is it? [hmm I later
> > see that this is a new name space.. see comment below.]
>
> I am happy to use another existing name space, but the only
> one I find doesn't have HMAC-MD5 in it:
>
> ========================================================================
>   Hash Algorithm                     Value            References
>   --------------                     -----            ----------
>   MD5                                  1               [RFC1321]
>   SHA                                  2              FIPS 180-1
>   Tiger                                3              See Reference
[TIGER]
>   SHA2-256                             4                 [Leech]
>   SHA2-384                             5                 [Leech]
>   SHA2-512                             6                 [Leech]
> ========================================================================
>
> Should we define some more values?  How do I find out the up-to-date
> list?  Is this list being actively maintained?  If we use this list,
> do we have to wait until someone actively figures out the right way
> to keep this list up-to-date (assuming that it is not now). (***)
>
> ...........  (now, from the top) ..............
>
> > This is a comment that probably applies to lots of MIP
> > documents. Please define "security association" in the MIP context. In
> > IPsec terminology, for instance, it means something very
> > specific. I.e., keys, SPIs, etc., and works only between a pair of
> > nodes. Once an association exists, encrypted packets can be sent. No
> > further negotiation is needed. Also, one can have multiple (different
> > SAs between the same set of machines). This document says:
> >
> >    node and its home agent.  When the mobile node shares a security
> >    association with its home AAA server, however, it is possible to use
> >    that security association to create derivative security associations
> >    between the mobile node and its home agent, and again between the
> >    mobile node and the foreign agent currently offering connectivity to
> >    the mobile node.  This document specifies extensions to the Mobile
> >
> > The MN talks to its HA, not a AAA server. So I'm not clear what is
> > meant by "shares a security association". From my perspective, it
> > seems like "security relationship" would be more accurate terminology.
>
> The mobile node is expected to produce authentication data according
> to the security algorithm configured for its use with AAA.   I think
> this corresponds exactly with the typical use of the terminology.
> A security relationship would be more general than is intended here.
> But since I don't know exactly what that term means, it's hard to
> be sure.  Maybe the security relationship is the thing that precedes
> and enables the creation of the security association.
>
> > Note that the above paragraph also talks about "security associations"
> > between the MN and HA. Here, the terminology  (I suspect) corresponds
> > more closely to the IPsec usage. But I'm not sure.
>
> I've included a Terminology section.  I hope this isn't opening another
> huge can of worms, but I'm very happy to accept suggestions on how
> to make appropriate and succinct defintions.
>
> > General comment. This document is very loose about whether a MN is
> > talking to a FA/HA or a AAA server. This should be made explicitly
> > clear throughout. Indeed, my assumption is that conceptually, if not
> > in reality, a MN NEVER speaks to an AAA server directly. Rather, it
> > speaks MIP protocols with an HA/FA, and that HA/FA has a side
> > conversation with the AAA server. This should be made much more clear
> > throughout.
>
> O.K.  I will try to do this.
>
> >> 2. Scope of Protocol
> >>
> >>    The protocol and messages in this document are intended to
facilitate
> >>    the following operations which may occur between the mobile node,
AAA
> >>    server, home agent, and foreign agent.
> >
> > Throughout this section, it should be made explicitly clear *who* is
> > sending a message, and *to* *whom* the message is being sent. Also,
> > when someone processes an extension *who* is doing the
> > processing. This isn't clear from just reading the text.
>
> I'll give it a shot.  Let me know if I succeed -- or fail.
>
> > Also, it might make sense to change the section heading to "overview"
> > rather than Scope, since it does seem like an overview. Assuming this
> > is an overview, I think it would help the reader if the text included
> > steps such as as "FA sends message to AAA server ..." "AAA server does
> > X and returns Y to the FA", "FA generates reply and sends to MN"...
>
> O.K.  I have attempted to do this.
>
> >     2. If the mobile node does not have a Mobility Security Association
> >        with the foreign agent, it SHOULD include an MN-FA Key Request
> >        extension.
> >
> > In what message, and sent to whom?
>
> As part of its Registration Request that it sends to the Foreign Agent.
>
> > What is the RFC reference to the key request extension?
>
> It's defined later in the document.  I've added a cross reference.
>
> >     3. Similarly, if the mobile node does not have a Mobility Security
> >        Association with the home agent, it MUST add an MN-HA Key Request
> >        extension.
> >
> > In message sent to whom?
>
> As part of its Registration Request that it sends to the Foreign Agent.
>
> >     4. If one or more Key Request extensions were added, the MN-AAA
> >        Authentication extension is added to the Registration Request.
> >
> > Added by whom?
>
> The mobile node.
>
> >     5. At the time the information within the MN-AAA Authentication
> >        extension is verified by the AAA server, the AAA server also
> >        generates Key Material for the keys requested by the mobile node,
> >        and causes insertion of the Key Material fields along with the
> >        Registration Reply.
> >
> > So there is an implied step here in which the FA exchanges messages
> > with its local AAA server? Would be good to explicitely say that here.
>
> I have made it more explicit.
>
> > Is that AAA protocol already in place? What RFCs are used? I.e, is
> > there a potential normative reference problem buried here? (I suspect
> > the answer is no, but am not sure.)
>
> The intention was to keep the formulation general, and not dependent
> on the specifics of the AAA protocol.
>
> >     6. The respective AAA keys are distributed to the Home and Foreign
> >        Agent via the AAA protocol.
> >
> > Where are the details of this described?
>
> It is out of scope for this document, and I hope it does not have
> to be specfied as part of a normative reference.  All that we
> should have to do is to specify how the Mobile IP extensions work.
>
> According to this philosophy, some of the steps in the Overview
> amount to over-specification, but I don't think there is any
> serious problem so O.K.
>
> > step 6b) FA sends a reply to the MN
> >
> >>    extension.  In order for the mobile node to make use of key
> >>    information sent to it by the AAA server, the mobile node also has
to
> >>    be able to select the appropriate cryptographic algorithm that uses
> >>    the key to produce the authentication.  The following table contains
> >
> > I doubt the AAA server is sending messages to the MN. Isn't it the FA
> > that does this (i.e., it relays this info)? Text could be more
> > precise.
>
> I reworded this to say that the AAA server "creates" the
> key information.
>
> >    Dynamic Mobility Security Associations shared between mobile nodes
> >
> > What is a "Dynamic Mobility Security Association"? Is it different
> > than other types of security associations?
>
> Well, it's not manually configured.   Isn't this well-known usage?
> Do we have to say "dynamically created"?  Otherwise, it is the
> same as the mobility security association defined in RFC 2002.
>
> > Note: IMO, it would be better to move the description formats of the
> > extensions here, rather than at the end. It is a bit confusing to talk
> > about the contents of packet fields prior to having shown the format
> > of the option with all of the fields together.
>
> I didn't see where the packet fields were mentioned.  We used
> the name of some extensions that were defined in RFC 2002.
> The tables supply parameter values for some fields in the
> extension formats, but that's as close as I could get to
> understanding your request here.  Maybe we should move the
> tables after the formats?
>
> >> 4. Key Material Creation and Derivation
> >>
> >>    This section contains the procedures followed in the creation of the
> >>    Key Material by AAA servers, and the key derivation procedures used
> >                                 ^
> >>    by mobile nodes.  Note that the AAA servers will also make use of
the
> >
> > insert "extension" as indicated above? Also, better to say "contains
> > the procedure a FA/HA follows when creating ..." (or is the procedure
> > aimed at AAA servers?)
>
> The procedure is aimed at AAA servers, and I couldn't parse the result
> when I put "extension" where you indicated.  The idea is that AAA
> servers will do something that is able to be understood by mobile
> nodes, and that mobility agents (home agent, foreign agent) will
> faithfully transcribe the results into the appropriate Mobile IP
> extensions.  I have added those words to this introductory
> paragraph.  It is still intended to avoid normative references
> here for any AAA protocol.  If necessary, we could create an
> applicability statement and use it along with the introductory section.
>
> >    The example that follows makes use of MD5 in prefix+suffix mode,
> >    whose support is mandatory in Mobile IP [11].  Other cryptographic
> >    functions, such as those listed in 3 MAY also be used.
> >
> > Might be better to make HMAC-MD5 the example. Also, what is meant be
> > "listed in 3 MAY". Should that be "listed in [3] MAY"??
>
> That was supposed to be Section 3.
>
> >     1. The AAA server identifies the mobile node's via a
> >        ``node-address''.  If the Home Address field of the
> >        Registration Request is zero (0), the Mobile Node's NAI is used
> >        instead.
> >
> > First sentence doesn't parse.
>
> Fixed!
>
> > I'm confused by the description above in the sense that it implies
> > that the MN Registration Request is sent to a AAA server. I thought it
> > was sent to a FA.
>
> Here, one has to understand the contents of RFC 2977.  I have added
> a lot of text to that effect in the Introduction.  I hope that's
> sufficient.  Otherwise, we would have to start copying text from
> that document.
>
> > Also, why use the term "node-address"? Don't you really mean the home
> > address? (the term node-address isn't defined anywhere).
>
> Fixed.
>
> >  Maybe you mean to say:
> >
> >     1. The AAA server identifies the mobile node via a
> >        ``node-address''.  The node-address is taken from the Home
> >        Address field of the Registration Request, or the NAI, if the
> >        Home Address field is zero (0).
> >
> > Note again how the text blurs the distinction between the FA and the
> > AAA server. Does the AAA server see the registration request? I would
> > think not. It sees information the FA sends to it, which includes
> > portions of the registration request. The document should really make
> > this clear throughout
>
> I fixed this, I hope.  I also hope it would be clear to someone
> who went through the discussion in RFC 2977.
>
> >>    2. The AAA server generates a random [5] value of at least 64 bits.
> >
> > 64 bits seems short. I'd like someone with security background to
> > comment on this. But I guess this is sent in the clear, so the length
> > may not matter?
>
> That makes sense to me.
>
> >     3. The AAA server inserts the random value into the Key extension in
> >        the ``Key Material'' field.
> >
> > Presumably this field is part of a message or an extension within a
> > message. Which message or extension? Make explicit.
>
> The example is supposed to work for any Key Material extension.
>
> > Note steps 1-3 are done on the server, steps 4-5 on the mobile
> > node. It might be good to make the more clear here, perhaps by having
> > subsections?
>
> O.K.  I did it, but I don't know if it's an improvement or not.
>
> >     4. The mobile node calculates
> >
> >           key = MD5(AAA-key | Key Material | node-address | AAA-key)
> >
> > what is AAA-key? Where does it come from? Ditto for "Key Material" How
> > does the mobile node know which AAA-key to use? Can there only be one
> > (I hope not...)
>
> The AAA-key is what the mobile node shares with the AAA server.
> The Key Material is the 64 random bits.
>
> >       Key Material
> >                  A random [5] value of at least 64 bits.
> >
> > Keying material of only 64 bits? Would this pass security muster??
>
> I reckon it will, but I'm not betting my house on it.  The cryptographic
> strength of the algorithm doesn't depend on this number.
>
> >>       AAA SPI    A 32-bit opaque value, indicating the SPI that the
> >>                  mobile node must use to determine the algorithm to use
> >>                  for establishing the FA security information.
> >
> > How does the mobile node create this SPI? Is this preconfigured?
>
> Yes, or at least out of scope for this document.
>
> >>       FA SPI     A 32-bit opaque value, which the mobile node MUST use
> >>                  to index all the necessary information established for
> >>                  the FA security information after it is decoded.
> >
> > Might be better to say something like:
> >
> >        FA SPI     The SPI for the Security Association to the FA that
> >                   the MN creates as a result of processing this
extension.
>
> Done.
>
> >>    The Unsolicited MN-FA Key Material From AAA extension, shown
> >>    in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply
> >>    Extension [12].
> >
> > Shouldn't this be moved to the beginning of section 5. (e.g., as it is
> > in Section 6?)
>
> Done!
>
> >>       HA SPI     A 32-bit opaque value, which the mobile node MUST use
> >>                  to index all the necessary information established for
> >>                  the HA security information after it is decoded.
> >
> > Same comment as above w.r.t FA SPI. Ditto for key material.
>
> Done.
>
> >>    the Key Material provided by the home domain AAA server (AAAH). The
> >>    key is intended for use the mobile node to secure future Mobile IP
> >>    registrations with its home agent.  The MN-HA Key Reply MUST appear
> >
> > sentence doesn't parse.
>
> Fixed.
>
> >>    The mobile node uses the Identification field data from the
> >>    Registration Request as its initial synchronization data with the
> >>    home agent.
> >
> > What is the field referred to in this sentence?
>
> If you look at the Registration Request format, there is a field
> called the Identification field.  It allows entities using Mobile IP
> to associated a Registration Reply to the appropriate Registration
> Request.
>
> I don't know if you meant to suggest adding text or not, but I wouldn't
> feel it was appropriate to copy text from RFC 2002{,bis} here.
>
> >> 7. MN-FA Key Request From AAA Subtype
> >>
> >>    The MN-FA Key Request From AAA subtype data uses subtype 7 of the
> >>    Generalized MN-FA Key Request Extension [12].  The MN-FA Key Request
> >>    From AAA extension MUST appear in the Registration Request before
the
> >>    MN-AAA Authentication extension.  The subtype data field is zero in
> >>    length.
> >>
> >>
> >> 8. MN-HA Key Request From AAA Subtype
> >>
> >>    The MN-HA Key Request From AAA subtype data uses subtype 7 of the
> >>    Generalized MN-HA Key Request Extension [12].  The MN-HA Key Request
> >>    From AAA extension MUST appear in the Registration Request before
the
> >>    MN-AAA Authentication extension.  The subtype data field is zero in
> >>    length.
> >
> > Hmm. What are the above two sections about? The first sentence in each
> > seems redundent. Can't the remaining text just be put in the previous
> > sections that describe the extension?
>
> The extensions, which are Request extensions (not Reply extensions),
> are defined in the Generalized Keys document, and don't have any
> additional format that needs to be specfied.
>
> > Also, why is the ordering important?
>
> The MN-AAA Authentication extension is an "authorization-enabling"
> extension, in the language of RFC 2002bis.  Such extensions have
> to be last.
>
> >> 10. IANA Considerations
> >
> > This document requests certain numbers be assigned. Is this required,
> > i.e., are their implementations that already use the numbers? This
> > section should really say TBD for any assignments that it  doesn't
> > care what the  actual value is, and let IANA pick. If it really does
> > care about the value, the text should suggest a certain value be used
> > and mention that the numbers are already in use by existing
> > implementations. That way, IANA has some context for deciding what to
> > do.
>
> The numbers are already in use by implementations.   I have added text
> to the IANA Considerations to that effect.
>
> >>    Section 3 introduces the Algorithm Identifier namespace that
requires
> >>    IANA management.  This specification makes use of 1-3; all other
> >>    values other than zero (0) are available for assignment, pending
> >>    review and approval by a Designated Expert [9].
> >
> > Can't you just leverage off an existing MIP name space (i.e, the one
> > used by other extensions?) rather than creating a new one?
>
> See above (***).
>
> Regards,
> Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 13:32:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09494
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 13:32:25 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23229;
	Tue, 9 Oct 2001 11:27:49 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09146;
	Tue, 9 Oct 2001 10:27:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HQlML025800
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:26:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99HQkTJ025799
	for mobile-ip-dist; Tue, 9 Oct 2001 10:26:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HQgML025789
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:26:43 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08928
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:26:43 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12342
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:26:44 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f99HMjC22180
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:24:39 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABK01995;
	Tue, 9 Oct 2001 10:24:37 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05493; Tue, 9 Oct 2001 10:24:37 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15299.13013.322010.630584@thomasm-u1.cisco.com>
Date: Tue, 9 Oct 2001 10:24:37 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC32F89.652FBED7@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
	<3BC32F89.652FBED7@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Vijay Devarapalli writes:
 > For the first one, the Auth Data suboption is the solution.

   It is _a_ solution, and it has not gained anything
   resembling rough consensus, and there are still many
   unanswered criticisms of it. There has also been much 
   discussion on how to make IPsec work untouched. It
   to is _a_ solution.

   While neither seem to make it to rough consensus, as
   far as I can tell, there's a lot more support for
   fixing the problems with MIP's use of IPsec.

	      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 13:40:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10046
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 13:40:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03942;
	Tue, 9 Oct 2001 11:39:51 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14669;
	Tue, 9 Oct 2001 10:39:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99Hd3ML025957
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:39:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99Hd3d5025956
	for mobile-ip-dist; Tue, 9 Oct 2001 10:39:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HcxML025949
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:39:00 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12266
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:38:58 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02991
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:38:49 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA20048
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:38:59 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f99HcxB24847
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:38:59 -0700
X-mProtect:  Tue, 9 Oct 2001 10:38:59 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdx2D5AO; Tue, 09 Oct 2001 10:38:57 PDT
Message-ID: <3BC33631.A15946B@iprg.nokia.com>
Date: Tue, 09 Oct 2001 10:38:57 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
		<3BC32F89.652FBED7@iprg.nokia.com> <15299.13013.322010.630584@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Vijay Devarapalli writes:
>  > For the first one, the Auth Data suboption is the solution.
> 
>    It is _a_ solution, and it has not gained anything
>    resembling rough consensus, and there are still many
>    unanswered criticisms of it. There has also been much
>    discussion on how to make IPsec work untouched. It
>    to is _a_ solution.

all right. thats a start. atleast you see that as a solution.
if its not good enough, lets work on improving it.

>    While neither seem to make it to rough consensus, as
>    far as I can tell, there's a lot more support for
>    fixing the problems with MIP's use of IPsec.

well, IESG was very clear. they said 'develop an alternate
solution for AH'. I believe the IPSec WG wants to deprecate 
the use of AH. could be because of that. could be because
you need certain modifications (like either changing the
granularity of IPSec selectors or coming up with a new
extension header). 

anyway I disagree with you that there is more support for 
MIP's use of IPSec. its just a few!!

vijay

> 
>               Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 13:51:48 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10490
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 13:51:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05480;
	Tue, 9 Oct 2001 10:51:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17982;
	Tue, 9 Oct 2001 10:50:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HndML026082
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:49:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99HncTw026081
	for mobile-ip-dist; Tue, 9 Oct 2001 10:49:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HnZML026074
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:49:35 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17722
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:49:36 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13491
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:50:45 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f99Hnbg29888
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 10:49:37 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABK02945;
	Tue, 9 Oct 2001 10:49:33 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05496; Tue, 9 Oct 2001 10:49:32 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15299.14508.395954.402776@thomasm-u1.cisco.com>
Date: Tue, 9 Oct 2001 10:49:32 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC33631.A15946B@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
	<3BC32F89.652FBED7@iprg.nokia.com>
	<15299.13013.322010.630584@thomasm-u1.cisco.com>
	<3BC33631.A15946B@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Vijay Devarapalli writes:
 > >    While neither seem to make it to rough consensus, as
 > >    far as I can tell, there's a lot more support for
 > >    fixing the problems with MIP's use of IPsec.
 > 
 > well, IESG was very clear. they said 'develop an alternate
 > solution for AH'. 

   That's not what I heard from Jeff. What I heard
   is that the way that the MIP WG is intending to
   use AH is not in line with the way that RFC
   2401 IPsec selectors behave. They did _not_ say
   to abandon any IPsec based approach.

 > I believe the IPSec WG wants to deprecate 
 > the use of AH.

   There's not consensus for this. Also: ESP
   could be used instead.

 > could be because of that. could be because
 > you need certain modifications (like either changing the
 > granularity of IPSec selectors or coming up with a new
 > extension header). 

   You do _not_ need to change IPsec. All that is
   needed is a few relatively minor changes to 
   MIP. This has been discussed ad infinitum on
   this list.

 > anyway I disagree with you that there is more support for 
 > MIP's use of IPSec. its just a few!!

   I count exactly you and _maybe_ Charlie.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 14:18:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11062
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 14:18:04 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07184;
	Tue, 9 Oct 2001 12:16:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24797;
	Tue, 9 Oct 2001 11:16:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99IFGML026252
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:15:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99IFGUC026251
	for mobile-ip-dist; Tue, 9 Oct 2001 11:15:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99IFCML026244
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:15:12 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21682
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:15:11 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27304
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:16:23 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA23521
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:15:10 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f99IF9E15892
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 11:15:09 -0700
X-mProtect:  Tue, 9 Oct 2001 11:15:09 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdKJlkdH; Tue, 09 Oct 2001 11:15:07 PDT
Message-ID: <3BC33EAB.643D4377@iprg.nokia.com>
Date: Tue, 09 Oct 2001 11:15:07 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
		<3BC32F89.652FBED7@iprg.nokia.com>
		<15299.13013.322010.630584@thomasm-u1.cisco.com>
		<3BC33631.A15946B@iprg.nokia.com> <15299.14508.395954.402776@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

okay, let me try again.

Michael Thomas wrote:
> 
> Vijay Devarapalli writes:
>  > >    While neither seem to make it to rough consensus, as
>  > >    far as I can tell, there's a lot more support for
>  > >    fixing the problems with MIP's use of IPsec.
>  >
>  > well, IESG was very clear. they said 'develop an alternate
>  > solution for AH'.
> 
>    That's not what I heard from Jeff. What I heard
>    is that the way that the MIP WG is intending to
>    use AH is not in line with the way that RFC
>    2401 IPsec selectors behave. They did _not_ say
>    to abandon any IPsec based approach.

nobody is throwing out IPSec. draft 15 does not exclude
the possibility of using AH for protecting the BUs. but
its good to have another solution in hand.

>  > I believe the IPSec WG wants to deprecate
>  > the use of AH.
> 
>    There's not consensus for this. 

what if there is a consensus to throw AH out tomorrow? I 
know there is such a discussion going on in the IPSec WG. 
we do all the work, figure out how to use AH and then 
somebody tells us a few months later "AH cannot be used. 
use something else". do you want to take the risk? how 
about having an alternate solution in hand? we dont want
somebody telling us again that MIPv6 is broken (even
though it never was).

> Also: ESP
>    could be used instead.

this has been discussed a lot of times. There has been
MIP WG concensus for a long time now to use AH and not ESP.
ESP has not been found fit for protecting the BU. I do
not want to go into the details. check the archives.

>  > could be because of that. could be because
>  > you need certain modifications (like either changing the
>  > granularity of IPSec selectors or coming up with a new
>  > extension header).
> 
>    You do _not_ need to change IPsec. All that is
>    needed is a few relatively minor changes to
>    MIP. This has been discussed ad infinitum on
>    this list.

the minor changes involve throwing out piggybacking (which
in my opinion is a nice feature). and getting a new extension
header. the BU as a destination option has been through a 
lot of interoperability events (we have been at atleast 3- 
2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001 
Conectathon). lets not change it.

> 
>  > anyway I disagree with you that there is more support for
>  > MIP's use of IPSec. its just a few!!
> 
>    I count exactly you and _maybe_ Charlie.

again, both can exist. nobody wants to throw out AH. 

Vijay

> 
>            Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 15:06:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11697
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 15:06:01 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18034;
	Tue, 9 Oct 2001 13:05:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08116;
	Tue, 9 Oct 2001 12:05:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99J4CML026471
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:04:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99J4C5x026470
	for mobile-ip-dist; Tue, 9 Oct 2001 12:04:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99J48ML026463
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:04:08 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26838
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:04:09 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17147
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 13:03:58 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA27556
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:04:08 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f99J47b06057
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:04:07 -0700
X-mProtect:  Tue, 9 Oct 2001 12:04:07 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdP01MZB; Tue, 09 Oct 2001 12:04:06 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id MAA04833 for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:04:06 -0700 (PDT)
Message-ID: <3BC34A26.D125A763@iprg.nokia.com>
Date: Tue, 09 Oct 2001 12:04:06 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
			<3BC32F89.652FBED7@iprg.nokia.com>
			<15299.13013.322010.630584@thomasm-u1.cisco.com>
			<3BC33631.A15946B@iprg.nokia.com> <15299.14508.395954.402776@thomasm-u1.cisco.com> <3BC33EAB.643D4377@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Vijay Devarapalli wrote:
> 
> Michael Thomas wrote:
> >
> >    You do _not_ need to change IPsec. All that is
> >    needed is a few relatively minor changes to
> >    MIP. This has been discussed ad infinitum on
> >    this list.
> 
> the minor changes involve throwing out piggybacking (which
> in my opinion is a nice feature). and getting a new extension
> header.

Getting a new extension header is hardly a minor change. It needs
_every_ IPv6 forwarding engine to be changed, thus affecting the
ipv6 WG's scope. IMHO, people suggesting such a change should first
go to ipv6 WG to get their opinion on the issue. For the record,
I believe Francis bravely once already tried this - and, regrettably,
got rejected.

If, despite long discussion, there might be a lack of a credible
solution for AH, why not go ahead with an alternative? IMHO,
people interested in AH should work out the details (see above)
and come out with a separate description on how to solve the issue,
without stalling the base draft.

> Vijay
> 
> >
> >            Mike

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 15:58:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12635
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 15:58:03 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29766;
	Tue, 9 Oct 2001 13:57:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09491;
	Tue, 9 Oct 2001 12:57:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99Ju7ML026683
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:56:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99Ju7Rr026682
	for mobile-ip-dist; Tue, 9 Oct 2001 12:56:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99Ju3ML026675
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:56:03 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16017
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:56:03 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26249
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 13:57:15 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f99JuGu03142
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 12:56:16 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABK06915;
	Tue, 9 Oct 2001 12:55:49 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA05508; Tue, 9 Oct 2001 12:55:48 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15299.22084.836869.420536@thomasm-u1.cisco.com>
Date: Tue, 9 Oct 2001 12:55:48 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC34A26.D125A763@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1B@eaubrnt018.epa.ericsson.se>
	<3BC32F89.652FBED7@iprg.nokia.com>
	<15299.13013.322010.630584@thomasm-u1.cisco.com>
	<3BC33631.A15946B@iprg.nokia.com>
	<15299.14508.395954.402776@thomasm-u1.cisco.com>
	<3BC33EAB.643D4377@iprg.nokia.com>
	<3BC34A26.D125A763@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > Getting a new extension header is hardly a minor change. It needs
 > _every_ IPv6 forwarding engine to be changed, thus affecting the
 > ipv6 WG's scope. IMHO, people suggesting such a change should first
 > go to ipv6 WG to get their opinion on the issue. 

   Now wait a minute. I don't know about your
   forwarding engine, but ours don't route based
   on protocol number. And any flow classification
   engine which cannot deal with new IP protocols
   is broken and should be returned for full credit.

   Also: this could just as easily be done as a
   UDP packet on a well known port.

 > If, despite long discussion, there might be a lack of a credible
 > solution for AH []

   Nobody's shown that to be the case despite
   all the FUD.

		  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 21:44:33 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17597
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 21:44:32 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13964;
	Tue, 9 Oct 2001 18:44:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10069;
	Tue, 9 Oct 2001 18:43:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A1fhML027286
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 18:41:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A1fh8S027285
	for mobile-ip-dist; Tue, 9 Oct 2001 18:41:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A1fdML027278
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 18:41:39 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29226
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 18:41:40 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24133
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 19:42:50 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA05999
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:40:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA21331
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:41:36 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXKTG8>; Wed, 10 Oct 2001 11:41:35 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED25@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 11:41:35 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1512C.B2061B00"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1512C.B2061B00
Content-Type: text/plain


	Vijay, 


> IESG told us two things. ( I was there at the meeting with
> the security ADs at the San Diego IETF last December ).
> 
> 1. AH in its current form cannot be used for protecting the BU. 
> Develop an alternative solution. 
> 
	=>The way _MIPv6_ is using AH does not work. 
	That does not mean AH is not suited to MIPv6.
	I thought we've covered that in earlier discussions.

> 2. Develop a Key distribution mechanism for MN and CN.
> 
> For the first one, the Auth Data suboption is the solution.
> 
	=> Mike already answered this.

> For the second one, we have a requirements draft and a lot of
> competing proposals. We should be concentrating on this. and
> NOT how we can modify things (disable piggybacking, get a 
> new extension header) so that AH can be used for protecting
> the BU.
> 
> The MIPv6 draft will not have the key distribution mechanism
> embedded in it. It will just refer to another draft. 
> 
	=> Is this your own decision or the ADs/WG chairs ??
	I didn't see anything like this on the list before but 
	I might have missed something.


> It will 
> only specify how the BU can be protected. So if we agree 
> on the Auth Data suboption, we can conclude that the draft
> is complete. and no further changes need to be made. (maybe
> a few minor ones). thats what I meant by moving ahead.
> 
	=> Even if what you say above is correct, the draft can't 
	be an RFC when a normative reference is not.

> and from you mail, you seem to say the key distribution 
> mechanism is the main problem. great. thats what i wanted
> to hear from you. hope, you would stop talking about how
> AH can be used to protect the BU from now on.
> 
	=> No I won't. I want people to understand the real
	problem. I suggest you read Jari's draft when it comes out.

	Hesham


------_=_NextPart_001_01C1512C.B2061B00
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Vijay, </FONT>
</P>
<BR>

<P><FONT SIZE=2 FACE="Arial">IESG told us two things. ( I was there at the meeting with</FONT>
<BR><FONT SIZE=2 FACE="Arial">the security ADs at the San Diego IETF last December ).</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">1. AH in its current form cannot be used for protecting the BU. </FONT>
<BR><FONT SIZE=2 FACE="Arial">Develop an alternative solution. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt;The way _MIPv6_ is using AH does not work. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">That does not mean AH is not suited to MIPv6.</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I thought we've covered that in earlier discussions.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">2. Develop a Key distribution mechanism for MN and CN.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">For the first one, the Auth Data suboption is the solution.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Mike already answered this.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">For the second one, we have a requirements draft and a lot of</FONT>
<BR><FONT SIZE=2 FACE="Arial">competing proposals. We should be concentrating on this. and</FONT>
<BR><FONT SIZE=2 FACE="Arial">NOT how we can modify things (disable piggybacking, get a </FONT>
<BR><FONT SIZE=2 FACE="Arial">new extension header) so that AH can be used for protecting</FONT>
<BR><FONT SIZE=2 FACE="Arial">the BU.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">The MIPv6 draft will not have the key distribution mechanism</FONT>
<BR><FONT SIZE=2 FACE="Arial">embedded in it. It will just refer to another draft.</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Is this your own decision or the ADs/WG chairs ??</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I didn't see anything like this on the list before but </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I might have missed something.</FONT>
</P>
<BR>

<P><FONT SIZE=2 FACE="Arial">It will </FONT>
<BR><FONT SIZE=2 FACE="Arial">only specify how the BU can be protected. So if we agree </FONT>
<BR><FONT SIZE=2 FACE="Arial">on the Auth Data suboption, we can conclude that the draft</FONT>
<BR><FONT SIZE=2 FACE="Arial">is complete. and no further changes need to be made. (maybe</FONT>
<BR><FONT SIZE=2 FACE="Arial">a few minor ones). thats what I meant by moving ahead.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Even if what you say above is correct, the draft can't </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">be an RFC when a normative reference is not.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">and from you mail, you seem to say the key distribution </FONT>
<BR><FONT SIZE=2 FACE="Arial">mechanism is the main problem. great. thats what i wanted</FONT>
<BR><FONT SIZE=2 FACE="Arial">to hear from you. hope, you would stop talking about how</FONT>
<BR><FONT SIZE=2 FACE="Arial">AH can be used to protect the BU from now on.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; No I won't. I want people to understand the real</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">problem. I suggest you read Jari's draft when it comes out.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C1512C.B2061B00--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 21:48:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17629
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 21:48:29 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20801;
	Tue, 9 Oct 2001 19:47:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10702;
	Tue, 9 Oct 2001 18:47:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A1l0ML027358
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 18:47:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A1l0tx027357
	for mobile-ip-dist; Tue, 9 Oct 2001 18:47:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A1kuML027350
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 18:46:56 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10579
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 18:46:57 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06180
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 18:46:56 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA06598
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:45:49 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA22567
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:46:54 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXKTM0>; Wed, 10 Oct 2001 11:46:53 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED26@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 11:46:52 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1512D.6F662D70"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1512D.6F662D70
Content-Type: text/plain

> Getting a new extension header is hardly a minor change. It needs
> _every_ IPv6 forwarding engine to be changed, thus affecting the
> ipv6 WG's scope. 
> 
	=> Huh ?? Are you saying routers have to be upgraded
	every time we have a new DST-option addressed to the
	end host ?
	Thats news to me.

> IMHO, people suggesting such a change should first
> go to ipv6 WG to get their opinion on the issue. For the record,
> I believe Francis bravely once already tried this - and, regrettably,
> got rejected.
> 
	=> Francis can speak for himself but I've *never* seen a
	proposal for this in IPng. Probably for a good reason. 
	Francis did propose rearranging all ext headers in general
	and that was not agreed on for reasons that have nothing to
	do with routers.

> If, despite long discussion, there might be a lack of a credible
> solution for AH, why not go ahead with an alternative? IMHO,
> 
	=> I agree, but twe haven't seen *any* criticism for the IPsec
	solution. The only point of difference was piggybacking. 

> people interested in AH should work out the details (see above)
> and come out with a separate description on how to solve the issue,
> without stalling the base draft.
> 
	=> The details are summarised in Jari's draft that is coming out
	soon. Regarding stalling the draft this is really not true to say
the
	least.  

	Hesham

------_=_NextPart_001_01C1512D.6F662D70
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">Getting a new extension header is hardly a minor change. It needs</FONT>
<BR><FONT SIZE=2 FACE="Arial">_every_ IPv6 forwarding engine to be changed, thus affecting the</FONT>
<BR><FONT SIZE=2 FACE="Arial">ipv6 WG's scope.</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Huh ?? Are you saying routers have to be upgraded</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">every time we have a new DST-option addressed to the</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">end host ?</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Thats news to me.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">IMHO, people suggesting such a change should first</FONT>
<BR><FONT SIZE=2 FACE="Arial">go to ipv6 WG to get their opinion on the issue. For the record,</FONT>
<BR><FONT SIZE=2 FACE="Arial">I believe Francis bravely once already tried this - and, regrettably,</FONT>
<BR><FONT SIZE=2 FACE="Arial">got rejected.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Francis can speak for himself but I've *never* seen a</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">proposal for this in IPng. Probably for a good reason. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Francis did propose rearranging all ext headers in general</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">and that was not agreed on for reasons that have nothing to</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">do with routers.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">If, despite long discussion, there might be a lack of a credible</FONT>
<BR><FONT SIZE=2 FACE="Arial">solution for AH, why not go ahead with an alternative? IMHO,</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; I agree, but twe haven't seen *any* criticism for the IPsec</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">solution. The only point of difference was piggybacking. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">people interested in AH should work out the details (see above)</FONT>
<BR><FONT SIZE=2 FACE="Arial">and come out with a separate description on how to solve the issue,</FONT>
<BR><FONT SIZE=2 FACE="Arial">without stalling the base draft.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; The details are summarised in Jari's draft that is coming out</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">soon. Regarding stalling the draft this is really not true to say the</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">least.&nbsp; </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C1512D.6F662D70--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct  9 22:48:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19144
	for <mobileip-archive@odin.ietf.org>; Tue, 9 Oct 2001 22:48:07 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18554;
	Tue, 9 Oct 2001 20:47:28 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18113;
	Tue, 9 Oct 2001 19:47:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A2kJML027563
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 19:46:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A2kJEo027562
	for mobile-ip-dist; Tue, 9 Oct 2001 19:46:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A2kFML027555
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 19:46:15 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02474
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 19:46:15 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA15422
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 20:47:25 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA12058
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:45:08 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA04938
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:46:14 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXK40H>; Wed, 10 Oct 2001 12:46:12 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED2A@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 12:46:01 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15135.B262CAE0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15135.B262CAE0
Content-Type: text/plain

> > 
> >    You do _not_ need to change IPsec. All that is
> >    needed is a few relatively minor changes to
> >    MIP. This has been discussed ad infinitum on
> >    this list.
> 
> the minor changes involve throwing out piggybacking (which
> in my opinion is a nice feature). 
> 
	=> This was discussed in detail, it's nice but not practical. 
	BW-constrained links (like cellular links) allocate set
	channels based on the service, piggybacking the 
	BU _will_not_fit_ in the channel and the packet will
	dropped ! That's not nice is it. 
	Non-BW-constrained links could not care less if 
	we piggyback or not.

> and getting a new extension
> header. the BU as a destination option has been through a 
> lot of interoperability events (we have been at atleast 3- 
> 2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001 
> Conectathon). lets not change it.
> 
	=> No one suggested changing the BU option, it was
	suggested that it should be carried in a different header. 
	That does not imply changing anything in the option.

	Hesham

------_=_NextPart_001_01C15135.B262CAE0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; You do _not_ need to change IPsec. All that is</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; needed is a few relatively minor changes to</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; MIP. This has been discussed ad infinitum on</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; this list.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">the minor changes involve throwing out piggybacking (which</FONT>
<BR><FONT SIZE=2 FACE="Arial">in my opinion is a nice feature).</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; This was discussed in detail, it's nice but not practical. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">BW-constrained links (like cellular links) allocate set</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">channels based on the service, piggybacking the </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">BU _will_not_fit_ in the channel and the packet will</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">dropped ! That's not nice is it. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Non-BW-constrained links could not care less if </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">we piggyback or not.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">and getting a new extension</FONT>
<BR><FONT SIZE=2 FACE="Arial">header. the BU as a destination option has been through a </FONT>
<BR><FONT SIZE=2 FACE="Arial">lot of interoperability events (we have been at atleast 3- </FONT>
<BR><FONT SIZE=2 FACE="Arial">2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001 </FONT>
<BR><FONT SIZE=2 FACE="Arial">Conectathon). lets not change it.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; No one suggested changing the BU option, it was</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">suggested that it should be carried in a different header. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">That does not imply changing anything in the option.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15135.B262CAE0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 01:41:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22593
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 01:41:43 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27873;
	Tue, 9 Oct 2001 23:40:43 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22781;
	Tue, 9 Oct 2001 22:40:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A5dsML027813
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 22:39:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A5dssd027812
	for mobile-ip-dist; Tue, 9 Oct 2001 22:39:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A5doML027805
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 22:39:51 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18175
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 22:39:50 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27496
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 23:39:41 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA06428;
	Tue, 9 Oct 2001 22:39:51 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9A5dp720926;
	Tue, 9 Oct 2001 22:39:51 -0700
X-mProtect:  Tue, 9 Oct 2001 22:39:51 -0700 Nokia Silicon Valley Messaging Protection
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdCXAkWO; Tue, 09 Oct 2001 22:39:49 PDT
Message-ID: <3BC3DF00.4BC97412@iprg.nokia.com>
Date: Tue, 09 Oct 2001 22:39:12 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hesham Soliman (ERA)" <Hesham.Soliman@era.ericsson.se>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED2A@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Hesham,

"Hesham Soliman (EPA)" wrote:

>      the minor changes involve throwing out piggybacking (which
>      in my opinion is a nice feature).
>
>      => This was discussed in detail, it's nice but not practical.
>      BW-constrained links (like cellular links) allocate set
>      channels based on the service, piggybacking the
>      BU _will_not_fit_ in the channel and the packet will
>      dropped ! That's not nice is it.
>      Non-BW-constrained links could not care less if
>      we piggyback or not.
>

First, it was discussed in detail.  It's nice.  For some applications
on some links, it's not practical.  For other applications on other
links, it is practical.  It's been implemented, tested, and it works.

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 01:57:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23413
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 01:57:43 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04011;
	Tue, 9 Oct 2001 23:56:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19331;
	Tue, 9 Oct 2001 22:56:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A5tvML027914
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 9 Oct 2001 22:55:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A5tvbH027913
	for mobile-ip-dist; Tue, 9 Oct 2001 22:55:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A5trML027906
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 22:55:54 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA05559
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 22:55:55 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA16162
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 9 Oct 2001 23:57:06 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA29908
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 15:54:45 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA27897
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 15:55:52 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXK5HP>; Wed, 10 Oct 2001 15:55:50 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED31@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 15:55:49 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15150.3694F5D0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15150.3694F5D0
Content-Type: text/plain


	Hello Charlie, 

> >      the minor changes involve throwing out piggybacking (which
> >      in my opinion is a nice feature).
> >
> >      => This was discussed in detail, it's nice but not practical.
> >      BW-constrained links (like cellular links) allocate set
> >      channels based on the service, piggybacking the
> >      BU _will_not_fit_ in the channel and the packet will
> >      dropped ! That's not nice is it.
> >      Non-BW-constrained links could not care less if
> >      we piggyback or not.
> >
> 
> First, it was discussed in detail.  It's nice.  For some applications
> on some links, it's not practical.  For other applications on other
> links, it is practical.  It's been implemented, tested, and it works.
> 
	=> I realise it was implemented and tested. My issue here 
	is that how does a MN know whether the CN receiving 
	the piggybacked BU will be negatively impacted by piggybacking ?

	Jari has mentioned this in a previous email but I'll quickly mention
	it again. A MN on a WLAN could be sending a BU to a CN
	connected to a cellular link which was assigned a fixed channel
	size. Because the BU was piggybacked, the entire packet
	is dropped as it doesn't fit in the allocated channel. 
	Is there any solution to avoid this scenario ? 
	This is only one of the issues that were mentioned
	against piggybacking. 

	Hesham

------_=_NextPart_001_01C15150.3694F5D0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hello Charlie, </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the minor changes involve throwing out piggybacking (which</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in my opinion is a nice feature).</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; This was discussed in detail, it's nice but not practical.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BW-constrained links (like cellular links) allocate set</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; channels based on the service, piggybacking the</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BU _will_not_fit_ in the channel and the packet will</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dropped ! That's not nice is it.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Non-BW-constrained links could not care less if</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we piggyback or not.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">First, it was discussed in detail.&nbsp; It's nice.&nbsp; For some applications</FONT>
<BR><FONT SIZE=2 FACE="Arial">on some links, it's not practical.&nbsp; For other applications on other</FONT>
<BR><FONT SIZE=2 FACE="Arial">links, it is practical.&nbsp; It's been implemented, tested, and it works.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; I realise it was implemented and tested. My issue here </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">is that how does a MN know whether the CN receiving </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">the piggybacked BU will be negatively impacted by piggybacking ?</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Jari has mentioned this in a previous email but I'll quickly mention</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">it again. A MN on a WLAN could be sending a BU to a CN</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">connected to a cellular link which was assigned a fixed channel</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">size. Because the BU was piggybacked, the entire packet</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">is dropped as it doesn't fit in the allocated channel. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Is there any solution to avoid this scenario ? </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">This is only one of the issues that were mentioned</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">against piggybacking. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15150.3694F5D0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 03:15:52 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05760
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 03:15:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11870;
	Wed, 10 Oct 2001 01:14:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26648;
	Wed, 10 Oct 2001 00:14:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7E1ML028085
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:14:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A7E1Dd028084
	for mobile-ip-dist; Wed, 10 Oct 2001 00:14:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7DwML028077
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:13:58 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02299
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:14:00 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26269
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:13:59 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9A7DwH12697
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:13:58 +0300
Date: Wed, 10 Oct 2001 10:13:58 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED31@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110101012310.12685-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 10 Oct 2001, Hesham Soliman (EPA) wrote:
> 	Jari has mentioned this in a previous email but I'll quickly mention
> 	it again. A MN on a WLAN could be sending a BU to a CN
> 	connected to a cellular link which was assigned a fixed channel
> 	size. Because the BU was piggybacked, the entire packet
> 	is dropped as it doesn't fit in the allocated channel.
> 	Is there any solution to avoid this scenario ?
> 	This is only one of the issues that were mentioned
> 	against piggybacking.

Uhh.. Am I missing something that should be painfully obvious, but isn't
Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if in
doubt.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 03:42:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05987
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 03:42:30 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25455;
	Wed, 10 Oct 2001 01:41:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00448;
	Wed, 10 Oct 2001 00:41:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7eVML028188
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:40:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A7eVcN028187
	for mobile-ip-dist; Wed, 10 Oct 2001 00:40:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7eRML028180
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:40:27 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04654
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:40:27 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03432
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:40:26 -0700 (PDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9A7eOL13482;
	Wed, 10 Oct 2001 09:40:25 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9A7eOL29298;
	Wed, 10 Oct 2001 10:40:24 +0300 (EET DST)
Message-ID: <3BC3FB68.5850C4DC@lmf.ericsson.se>
Date: Wed, 10 Oct 2001 10:40:24 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pekkas@netcore.fi
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <Pine.LNX.4.33.0110101012310.12685-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>Uhh.. Am I missing something that should be painfully obvious, but isn't
>Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if in
>doubt.

No, the issue was what happens if you reserve a "tight" channel for
e.g. a multimedia stream and then you get randomly hit by extra ~ 20
bytes in the packets. What if the bytes don't fit the channel? The
channel was allocated based on the assumption that you will only
be sending the particular stream packets. Packet-Too-Big would
be inappropriate, particularly when you'd have to complain about
a size < 1280...

This is an interesting problem, and it also has variations: a
node that itself is attached to the tight channel would be able
to avoid piggybacking in its own messages, but the node on the
other end might not know this is necessary.

There might be solutions to this, but at least I'm not aware
of them. Any suggestions?

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 03:55:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06285
	for <mobileip-archive@lists.ietf.org>; Wed, 10 Oct 2001 03:55:41 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA09496;
	Wed, 10 Oct 2001 00:54:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01892;
	Wed, 10 Oct 2001 00:54:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7rTML028289
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:53:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A7rTCQ028288
	for mobile-ip-dist; Wed, 10 Oct 2001 00:53:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7rQML028281
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:53:26 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16807
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:53:28 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00962
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 01:53:16 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9A7rPR12955;
	Wed, 10 Oct 2001 10:53:25 +0300
Date: Wed, 10 Oct 2001 10:53:25 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
cc: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC3FB68.5850C4DC@lmf.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110101052280.12930-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 10 Oct 2001, Jari Arkko wrote:
> >Uhh.. Am I missing something that should be painfully obvious, but isn't
> >Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if in
> >doubt.
>
> No, the issue was what happens if you reserve a "tight" channel for
> e.g. a multimedia stream and then you get randomly hit by extra ~ 20
> bytes in the packets. What if the bytes don't fit the channel? The
> channel was allocated based on the assumption that you will only
> be sending the particular stream packets. Packet-Too-Big would
> be inappropriate, particularly when you'd have to complain about
> a size < 1280...
>
> This is an interesting problem, and it also has variations: a
> node that itself is attached to the tight channel would be able
> to avoid piggybacking in its own messages, but the node on the
> other end might not know this is necessary.
>
> There might be solutions to this, but at least I'm not aware
> of them. Any suggestions?

Link layer should fragment the IP datagram.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 03:59:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06366
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 03:59:39 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04383;
	Wed, 10 Oct 2001 01:58:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02956;
	Wed, 10 Oct 2001 00:59:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7wNML028372
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:58:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A7wNGD028371
	for mobile-ip-dist; Wed, 10 Oct 2001 00:58:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A7wJML028364
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:58:19 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02863
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 00:58:22 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03755
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 01:57:57 -0600 (MDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9A7w6L05973;
	Wed, 10 Oct 2001 09:58:07 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9A7w6L00017;
	Wed, 10 Oct 2001 10:58:06 +0300 (EET DST)
Message-ID: <3BC3FF8E.7614CE29@lmf.ericsson.se>
Date: Wed, 10 Oct 2001 10:58:06 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <Pine.LNX.4.33.0110101052280.12930-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>Link layer should fragment the IP datagram.

Yes, but then the whole stream of packets is
"moved forward" in terms of delay. Delay
might be bad enough already for this to not
be possible without loss of quality. Could
be better to throw away the whole packet.

Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 04:55:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06786
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 04:55:38 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29202;
	Wed, 10 Oct 2001 01:55:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09128;
	Wed, 10 Oct 2001 01:54:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A8s5ML028594
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 01:54:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9A8s409028593
	for mobile-ip-dist; Wed, 10 Oct 2001 01:54:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9A8s0ML028586
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 01:54:00 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13404
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 01:54:01 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29842
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 02:55:07 -0600 (MDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9A8rsL18153
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:53:54 +0200 (MEST)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Oct 10 10:53:54 2001 +0200
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <THN5GMAQ>; Wed, 10 Oct 2001 10:53:44 +0200
Message-ID: <F7709E7648BAD41181E60008C716A2290105904E@edkchnt102.lmd.ericsson.se>
From: "Peter Grimstrup (TED)" <Peter.Grimstrup@lmd.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Duplicate Address Detection
Date: Wed, 10 Oct 2001 10:53:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Draft 15 and probably the earlier drafts says:

D bit MUST not be set without A and H bit (sec. 5.1)

Section 8.2 says nothing about what to do if D is set but H is not.
One could 1) discard packet or 2) ignore D-bit or ?

Secondly, section 9.1 doesn't mention what to do if AHD == 011.
One could 1) discard packet or 2) continue as if the A bit was 1?
Later in section 9.1, A-bit is in a way forced to 1.
To be consistent, one could release section 5.1 to D-bit must not
be set without H-bit - or maybe better: D-bit is ignored if the
H-bit is not set (solves section 8.2 question as well)

Thirdly, section 9.1 requires DAD unconditionally when D-bit is
set. Does this mean, that even if the HA is already defending
the MN (i.e. the BU is updating/refreshing an already existing
entry), the DAD must be executed again?

/Peter


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 09:10:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08940
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 09:10:09 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20231;
	Wed, 10 Oct 2001 06:08:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14478;
	Wed, 10 Oct 2001 06:08:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AD7eML028982
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:07:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AD7eAA028981
	for mobile-ip-dist; Wed, 10 Oct 2001 06:07:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AD7aML028974
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:07:36 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07874
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:07:31 -0700 (PDT)
Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17997
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:07:22 -0600 (MDT)
Received: from piuha.net (ws4.piuha.net [195.165.196.4])
	by ws2.piuha.net (Postfix) with ESMTP
	id B6E606A905; Wed, 10 Oct 2001 16:07:17 +0300 (EEST)
Message-ID: <3BC4494D.9010507@piuha.net>
Date: Wed, 10 Oct 2001 16:12:45 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: jari.arkko@ericsson.fi
Subject: [mobile-ip] protecting BUs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Dear All,

I have written a draft that discusses the various
solutions on the table for the protection of
of Binding Updates after BAKE etc has done its
job.

The goal of the draft is not so much to propose
any specific solution, but rather to document
alternatives, their advantages/disadvantages
and issues brought up in the mailing list. My
hope is that this will be useful in deciding how
to move forward. First, we have to agree that
we have all solutions, know their properties,
and that the solutions actually work. I'd very
like to wellcome all feedback on these aspects
of the draft (as well as of course comments
on which solution should be chosen and why).

The draft has been submitted to the IETF, but before
it makes it to the official directories you can access
it at

http://www.piuha.net/~jarkko/publications/draft-arkko-mipv6-bu-security-00.txt

Jari Arkko
Ericsson



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 09:19:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09212
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 09:19:15 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26829;
	Wed, 10 Oct 2001 07:18:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16038;
	Wed, 10 Oct 2001 06:18:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ADHNML029059
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:17:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9ADHNoq029058
	for mobile-ip-dist; Wed, 10 Oct 2001 06:17:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ADHJML029051
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:17:19 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11892
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:17:22 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11898
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:17:20 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id GAA23996
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:17:19 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9ADHIC17465
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:17:18 -0700
X-mProtect:  Wed, 10 Oct 2001 06:17:18 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdJMYmLb; Wed, 10 Oct 2001 06:17:17 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id GAA07631 for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 06:17:17 -0700 (PDT)
Message-ID: <3BC44A5D.3AEC0166@iprg.nokia.com>
Date: Wed, 10 Oct 2001 06:17:17 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED26@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>      Getting a new extension header is hardly a minor change. It needs
>      _every_ IPv6 forwarding engine to be changed, thus affecting the
>      ipv6 WG's scope.
> 
>      => Huh ?? Are you saying routers have to be upgraded
>      every time we have a new DST-option addressed to the
>      end host ?
>      Thats news to me.

I believe unknown next header (not discussing option) values "should" result
in the packet being discarded with an ICMP error, e.g., when finding such
in the next header field of the IPv6 header. OK, the RFC allows that there
may exist routers that do not drop the packet. Their forwarding engines do
not have (a moblity-aware) input path (no CN functionality) and they have
selectively implemented forwarding paths. Though yet unknown headers are
easy to attach to most router designs I have seen, their semantics may
need some work before the node can be said to truly support a new protocol.
Let's say that at least all CN-enabled hosts and routers following the
should-rule are affected, if a new header is needed for end host (CN)
mobility support.

>      IMHO, people suggesting such a change should first
>      go to ipv6 WG to get their opinion on the issue. For the record,
>      I believe Francis bravely once already tried this - and, regrettably,
>      got rejected.
> 
>      => Francis can speak for himself but I've *never* seen a
>      proposal for this in IPng. Probably for a good reason.
>      Francis did propose rearranging all ext headers in general
>      and that was not agreed on for reasons that have nothing to
>      do with routers.

I believe his proposal also included a "nice-to-have" suggestion to
introduce a new header type for one of the options currently carried
in destination headers.

>      solution for AH..
> 
>      => The details are summarised in Jari's draft that is coming out
>      soon. Regarding stalling the draft this is really not true to say the
>      least.

If that is the case, that would be good.

>      Hesham

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 10:25:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10908
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 10:25:10 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20465;
	Wed, 10 Oct 2001 08:24:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29535;
	Wed, 10 Oct 2001 07:24:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AENHML029229
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:23:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AENH42029228
	for mobile-ip-dist; Wed, 10 Oct 2001 07:23:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AENEML029221
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:23:14 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21516
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:23:15 -0700 (PDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19528
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:23:04 -0600 (MDT)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <4KA6RAG3>; Wed, 10 Oct 2001 10:23:14 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486165C9@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Multi-homing MIPv6???
Date: Wed, 10 Oct 2001 10:23:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi

I have a non-security related question! I don't recall seeing any
discussion of mult-homing and its relation to MIPv6 HO.  Perhaps
I missed something.  Also, I don't recall seeing much discussion
of SCTP and MIPv6.  Did I miss this discussion or has it occured
elsewhere or not at all on any list?

Thank you,

Phil

--
Mesh Networks, Inc. (www.meshnetworks.com)
Phillip D. Neumiller, Staff Scientist
pneumiller@meshnetworks.com PH: 1-407-659-5387
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 10:26:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10947
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 10:26:49 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22110;
	Wed, 10 Oct 2001 08:26:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29834;
	Wed, 10 Oct 2001 07:26:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AEPPML029280
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:25:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AEPPjr029278
	for mobile-ip-dist; Wed, 10 Oct 2001 07:25:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AEPLML029271
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:25:21 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19551
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:25:20 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13184
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:25:23 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9AEPau26509
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 07:25:36 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABK22018;
	Wed, 10 Oct 2001 07:25:20 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA05787; Wed, 10 Oct 2001 07:25:19 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15300.23119.739387.647506@thomasm-u1.cisco.com>
Date: Wed, 10 Oct 2001 07:25:19 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <Pine.LNX.4.33.0110101012310.12685-100000@netcore.fi>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED31@eaubrnt018.epa.ericsson.se>
	<Pine.LNX.4.33.0110101012310.12685-100000@netcore.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola writes:
 > On Wed, 10 Oct 2001, Hesham Soliman (EPA) wrote:
 > > 	Jari has mentioned this in a previous email but I'll quickly mention
 > > 	it again. A MN on a WLAN could be sending a BU to a CN
 > > 	connected to a cellular link which was assigned a fixed channel
 > > 	size. Because the BU was piggybacked, the entire packet
 > > 	is dropped as it doesn't fit in the allocated channel.
 > > 	Is there any solution to avoid this scenario ?
 > > 	This is only one of the issues that were mentioned
 > > 	against piggybacking.
 > 
 > Uhh.. Am I missing something that should be painfully obvious, but isn't
 > Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if in
 > doubt.

Pekka,

The details are pretty krufty, but when you have a
shared media (air, cable, real ethernet), there
are just a few choices if you want to give
preferential treatment of some flows over other
flows. The most common is to appoint a scheduler
(the AP, the CMTS, etc...) who allocates time on
the upstream to the attached units, and completely
manages the downstream traffic.

While it's possible to have contention mode
upstream scheduling, (pseudo-cs/cdma) it generally
results in either additional latency, unreliable
delivery, or both. One solution to these problems
is to prearrange periodic transmission 
opportunities of a fixed length. For example, I
might at the start of a call request 40+8+12+20
(ip, udp,rtp,g.729) sized slots every 10ms to
carry voice data. The scheduler books this
resource, and the TDM-like slots are always
allocated regardless of use.

This is a simplified version as there are many
things that you can do to soak of some of the slop
inherent with TDM-like slots, but they all suffer
from a common problem: you need to allocate slots
to the roof of your sent data. For piggybacked
BU's, that means that you'd conceivably need to
also account for their size if you wanted to
piggyback them on the fixed slot channel (ie,
80+~40, eg 50% more bandwidth). Unfortunately,
that would be a huge waste of bandwidth since the
rate that you send BU's is (hopefully) miniscule
compared to the voice traffic. As such, you will
almost certainly never piggyback BU's in that sort
of environment.

       Mike, and I don't understand how ROHC
        will deal with this either...


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 11:17:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11970
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 11:17:37 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18336;
	Wed, 10 Oct 2001 08:16:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02105;
	Wed, 10 Oct 2001 08:16:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AFFJML029488
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:15:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AFFJIu029487
	for mobile-ip-dist; Wed, 10 Oct 2001 08:15:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AFFFML029480
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:15:15 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27977
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:15:15 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07813
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:15:06 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA15136
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:15:14 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 10 Oct 2001 10:13:55 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LXCPX>; Wed, 10 Oct 2001 10:14:21 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E554755@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 10:14:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1519E.3BEFD2E0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1519E.3BEFD2E0
Content-Type: text/plain;
	charset="iso-8859-1"

Jari,

I am fairly confident that these respective access technology and
compression groups can find acceptable ways around handling piggybacked
binding udpates that meet the requirements for the particular media streams
in question.

Besides route optimized MIPv6 will never be ubiquitous anyway as long as the
binding update processing by CN's is only a SHOULD. The MN and HA will
always have to be complicated by back-off procedures to forward stream
tunnel mechanisms. 

In my opinion removing this complication is more important than removing the
piggyback complication for specific access technologies and compression
mechanisms.

I would rather see the group focus on making the route optimized mobility
ubiquitous and removing the complications of it not being.

Glenn



-----Original Message-----
From: Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se]
Sent: Wednesday, October 10, 2001 2:58 AM
To: Pekka Savola
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion


>Link layer should fragment the IP datagram.

Yes, but then the whole stream of packets is
"moved forward" in terms of delay. Delay
might be bad enough already for this to not
be possible without loss of quality. Could
be better to throw away the whole packet.

Jari

------_=_NextPart_001_01C1519E.3BEFD2E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jari,</FONT>
</P>

<P><FONT SIZE=3D2>I am fairly confident that these respective access =
technology and compression groups can find acceptable ways around =
handling piggybacked binding udpates that meet the requirements for the =
particular media streams in question.</FONT></P>

<P><FONT SIZE=3D2>Besides route optimized MIPv6 will never be =
ubiquitous anyway as long as the binding update processing by CN's is =
only a SHOULD. The MN and HA will always have to be complicated by =
back-off procedures to forward stream tunnel mechanisms. </FONT></P>

<P><FONT SIZE=3D2>In my opinion removing this complication is more =
important than removing the piggyback complication for specific access =
technologies and compression mechanisms.</FONT></P>

<P><FONT SIZE=3D2>I would rather see the group focus on making the =
route optimized mobility ubiquitous and removing the complications of =
it not being.</FONT></P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jari Arkko [<A =
HREF=3D"mailto:Jari.Arkko@lmf.ericsson.se">mailto:Jari.Arkko@lmf.ericsso=
n.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, October 10, 2001 2:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Pekka Savola</FONT>
<BR><FONT SIZE=3D2>Cc: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] MIPv6 - Focus of the =
security discussion</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;Link layer should fragment the IP =
datagram.</FONT>
</P>

<P><FONT SIZE=3D2>Yes, but then the whole stream of packets is</FONT>
<BR><FONT SIZE=3D2>&quot;moved forward&quot; in terms of delay. =
Delay</FONT>
<BR><FONT SIZE=3D2>might be bad enough already for this to not</FONT>
<BR><FONT SIZE=3D2>be possible without loss of quality. Could</FONT>
<BR><FONT SIZE=3D2>be better to throw away the whole packet.</FONT>
</P>

<P><FONT SIZE=3D2>Jari</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1519E.3BEFD2E0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 11:24:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12214
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 11:24:29 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15893;
	Wed, 10 Oct 2001 09:23:43 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04260;
	Wed, 10 Oct 2001 08:23:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AFN8ML029584
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:23:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AFN8C5029583
	for mobile-ip-dist; Wed, 10 Oct 2001 08:23:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AFN4ML029576
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:23:04 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09172
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:23:06 -0700 (PDT)
Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00559
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:24:16 -0600 (MDT)
Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345)
	id 542BD2607; Wed, 10 Oct 2001 10:18:49 -0500 (CDT)
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103])
	by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 59EB61E4F
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:18:49 -0500 (CDT)
Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345)
	id 0A55B1437; Wed, 10 Oct 2001 11:18:49 -0400 (EDT)
Received: from oflume.zk3.dec.com (oflume.zk3.dec.com [16.140.112.3])
	by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id ED53A13F9
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:18:48 -0400 (EDT)
Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM)
	id LAA0000031413; Wed, 10 Oct 2001 11:18:48 -0400 (EDT)
From: Brian Haley USG <haley@zk3.dec.com>
Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM)
	id AA21618; Wed, 10 Oct 2001 11:18:48 -0400
Message-Id: <200110101518.AA21618@dogbert.zk3.dec.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Duplicate Address Detection 
Date: Wed, 10 Oct 2001 11:18:47 -0400
X-Mts: smtp
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> Draft 15 and probably the earlier drafts says:
> 
> D bit MUST not be set without A and H bit (sec. 5.1)
> 
> Section 8.2 says nothing about what to do if D is set but H is not.
> One could 1) discard packet or 2) ignore D-bit or ?

In my opinion, since section 5.1 says "This bit is only valid when the
Home Registration (H) and Acknowledge (A) bits are also set...", we
should ignore the bit.  This follows the general notion of being
liberal in what we accept.

> Secondly, section 9.1 doesn't mention what to do if AHD == 011.
> One could 1) discard packet or 2) continue as if the A bit was 1?
> Later in section 9.1, A-bit is in a way forced to 1.

I think you answered your own question here?  A home registration
MUST be acknowledged regardless of the A bit as section 9.1 says.

> To be consistent, one could release section 5.1 to D-bit must not
> be set without H-bit - or maybe better: D-bit is ignored if the
> H-bit is not set (solves section 8.2 question as well)

Covered above, section 5.1 already says this.

> Thirdly, section 9.1 requires DAD unconditionally when D-bit is
> set. Does this mean, that even if the HA is already defending
> the MN (i.e. the BU is updating/refreshing an already existing
> entry), the DAD must be executed again?

DAD only needs to be done before the address is assigned to an interface,
I don't think you ever do it again (there is a reference to RFC 2462
in this text).

-Brian



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 11:33:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12492
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 11:33:22 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26578;
	Wed, 10 Oct 2001 08:31:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06654;
	Wed, 10 Oct 2001 08:31:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AFUWML029762
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:30:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AFUWm3029761
	for mobile-ip-dist; Wed, 10 Oct 2001 08:30:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AFUSML029751
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:30:28 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06278
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 08:30:30 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22069
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:30:18 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA29581;
	Wed, 10 Oct 2001 08:30:29 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AFUS123188;
	Wed, 10 Oct 2001 08:30:28 -0700
X-mProtect:  Wed, 10 Oct 2001 08:30:28 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdBCZAEH; Wed, 10 Oct 2001 08:30:26 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id IAA07735; Wed, 10 Oct 2001 08:30:26 -0700 (PDT)
Message-ID: <3BC46992.DA860F7F@iprg.nokia.com>
Date: Wed, 10 Oct 2001 08:30:26 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: jari.arkko@ericsson.fi
Subject: Re: [mobile-ip] protecting BUs
References: <3BC4494D.9010507@piuha.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello,

Nice piece of work! Here very briefly some comments:

- On your analysis on piggybacking: A simple question: Given that
  a multitude of applications (browsing, streaming, messaging)
  over IP can have rather large variance in upper layer packet size,
  could it be that piggybacking overhead actually is a rather
  insignificant factor and the upper layer variance a much bigger
  headache? To get past that, one should be able to control the type
  of applications over such tight channels. If that is possible,
  why not consider it possible to simply recommend enabling/disabling
  of piggybacking, say, based on when using small packet size
  variance (streaming) applications? Maybe this should also be mentioned
  in the discussion?

- Addition of a New Next Header Value: Are you sure it can be done
  without any out-of-mobileip standardization work? Shouldn't there
  be analysis on the change implications of this (like you have well
  done for, e.g., IPsec modifications)? Quoting RFC2460 [Page 6]:

  > If, as a result of processing a header, a node is required to proceed
  > to the next header but the Next Header value in the current header is
  > unrecognized by the node, it should discard the packet and send an
  > ICMP Parameter Problem message to the source of the packet, with an
  > ICMP Code value of 1 ("unrecognized Next Header type encountered")

  If any node (host or router) encounters IPv6 header, it should at least
  consider whether there is a next header with a hop-by-hop option. If
  immediately in the IPv6 header the next header field has a unknown value,
  the node cannot avoid reading this value if it checks for the h-b-h,
  shouldn't it then discard the packet according to the above?

- On other requirements for change, should it not be more clearly
  indicated that the use of home address option in all IPsec cases
  (6.2 - 6.4) mean an off-the-shelf "black box" IPsec module needs to be
  modified? If a packet is passed to such an implementation, isn't it
  currently the case that it does not know home address option but uses
  the care-of-address in the IPv6 header instead? It sounds now as if
  6.2 did not require changes (we can use current version of AH but not
  exactly current implementations, right?).

BR,

-Jari


Jari Arkko wrote:
> 
> Dear All,
> 
> I have written a draft that discusses the various
> solutions on the table for the protection of
> of Binding Updates after BAKE etc has done its
> job.
> 
> The goal of the draft is not so much to propose
> any specific solution, but rather to document
> alternatives, their advantages/disadvantages
> and issues brought up in the mailing list. My
> hope is that this will be useful in deciding how
> to move forward. First, we have to agree that
> we have all solutions, know their properties,
> and that the solutions actually work. I'd very
> like to wellcome all feedback on these aspects
> of the draft (as well as of course comments
> on which solution should be chosen and why).
> 
> The draft has been submitted to the IETF, but before
> it makes it to the official directories you can access
> it at
> 
> http://www.piuha.net/~jarkko/publications/draft-arkko-mipv6-bu-security-00.txt
> 
> Jari Arkko
> Ericsson


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:06:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13079
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:06:49 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25717;
	Wed, 10 Oct 2001 10:05:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03538;
	Wed, 10 Oct 2001 09:05:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AG4QML029992
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:04:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AG4Qfc029991
	for mobile-ip-dist; Wed, 10 Oct 2001 09:04:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AG4MML029984
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:04:22 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03329
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:04:25 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24289
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:04:14 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA23565
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:04:24 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 10 Oct 2001 10:57:36 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LX1H4>; Wed, 10 Oct 2001 11:03:52 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E554883@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 11:03:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C151A5.277FB8A0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151A5.277FB8A0
Content-Type: text/plain;
	charset="iso-8859-1"

Hesham,
 
Not that this is the particular place for this discussion but it seems that
limitations of specific access technologies have again emerged into the
requirements of this IETF WG. 
 
Have you explored sending the piggybacked packets over something like - say,
the MAC representation of the signaling PDP context? 
 
It seems that this multiplexing could be accomplished quite easily via some
ROHC middle box?
 
I, for one, don't see much of a problem with some miniscule delay on one
single packet during a handoff of a mobile to mobile or mobile to cable
voice call - even if something like the signaling PDP context is not used.
 
Dropping the packet is probably worse than some miniscule segmentation delay
on one packet. 
 
I could see creating some new form of generic authentication/encryption
header that could be used for integrity and confidentiality of any set of IP
options and used in conjunction with existing IPSEC headers for the
applications; but based upon the timeliness of such work and cross WG
controversy involved in this, it seems that the logical and expedient
solution specified in the existing draft makes the best sense at this
particular point in time. I don't mind if someone suggests such as thing but
I don't think it should hamper the existing MIPv6 proposal which does solve
the problem.
 
As far a creating a new header specifically for BU, I don't see how that
would solve much of anything. Again, I don't mind if someone suggests such
as thing but I don't think it should hamper the acceptance of the existing
MIPv6 proposal.
 
regards,
 
Glenn
 
p.s. I thought this issue was settled already with further discussion
prohibited from the mailing list after being endlessly splattered by Michael
and myself. All this regurgitated FUD seems a bit strange to me. The access
technologies should easily be able to adapt to the bundled packets. 
 
 

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Wednesday, October 10, 2001 12:56 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion




	Hello Charlie, 

	>      the minor changes involve throwing out piggybacking (which 
>      in my opinion is a nice feature). 
> 
>      => This was discussed in detail, it's nice but not practical. 
>      BW-constrained links (like cellular links) allocate set 
>      channels based on the service, piggybacking the 
>      BU _will_not_fit_ in the channel and the packet will 
>      dropped ! That's not nice is it. 
>      Non-BW-constrained links could not care less if 
>      we piggyback or not. 
> 

	First, it was discussed in detail.  It's nice.  For some
applications 
on some links, it's not practical.  For other applications on other 
links, it is practical.  It's been implemented, tested, and it works. 

	=> I realise it was implemented and tested. My issue here 
is that how does a MN know whether the CN receiving 
the piggybacked BU will be negatively impacted by piggybacking ? 

	Jari has mentioned this in a previous email but I'll quickly mention

it again. A MN on a WLAN could be sending a BU to a CN 
connected to a cellular link which was assigned a fixed channel 
size. Because the BU was piggybacked, the entire packet 
is dropped as it doesn't fit in the allocated channel. 
Is there any solution to avoid this scenario ? 
This is only one of the issues that were mentioned 
against piggybacking. 

	Hesham 


------_=_NextPart_001_01C151A5.277FB8A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001>Hesham,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>Not 
that this is the particular place for this discussion but it seems that 
limitations of specific access&nbsp;technologies have again emerged into the 
requirements of this&nbsp;IETF WG.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>Have 
you explored sending the piggybacked packets over&nbsp;something like - say, the 
MAC representation of the signaling PDP context? </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>It 
seems that this multiplexing could be accomplished quite easily via some ROHC 
middle box?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>I, for 
one, don't see much of a problem with some miniscule delay on one single packet 
during a handoff of a mobile to mobile or mobile to cable voice call - even if 
something like the signaling PDP context is not used.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001>Dropping the packet is probably worse than some 
miniscule segmentation delay on one packet. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>I 
could see creating some new form of generic authentication/encryption 
header&nbsp;that could be used for integrity and confidentiality of any set of 
IP options and used in conjunction with existing IPSEC headers for the 
applications; b</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001>ut based upon the&nbsp;timeliness of such work and 
cross WG controversy involved in this, it seems that the logical and expedient 
solution specified in the existing draft makes the best sense at this particular 
point in time. I don't mind if someone suggests such as thing but I don't think 
it should hamper the existing MIPv6 proposal which does solve the 
problem.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>As far 
a creating a new header specifically for BU, I don't see how that would solve 
much of anything. Again, I don't mind if someone suggests such as thing but I 
don't think it should hamper the acceptance of the existing MIPv6 
proposal.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001>regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001>Glenn</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>p.s. 
<FONT color=#0000ff face=Arial size=2><SPAN class=527181415-10102001>I thought 
this issue was settled already with further discussion prohibited from the 
mailing list after being endlessly splattered by Michael and myself.&nbsp;All 
this regurgitated FUD seems a bit strange to me. The access technologies should 
easily be able to adapt to the bundled packets. 
</SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=527181415-10102001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hesham Soliman (EPA) 
  [mailto:Hesham.Soliman@ericsson.com.au]<BR><B>Sent:</B> Wednesday, October 10, 
  2001 12:56 AM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> 
  RE: [mobile-ip] MIPv6 - Focus of the security 
  discussion<BR><BR></DIV></FONT><BR>
  <UL>
    <P><FONT color=#0000ff face=Arial size=2>Hello Charlie, </FONT></P>
    <P><FONT face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the minor 
    changes involve throwing out piggybacking (which</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in my opinion is a nice 
    feature).</FONT> <BR><FONT face=Arial size=2>&gt;</FONT> <BR><FONT 
    face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; This was 
    discussed in detail, it's nice but not practical.</FONT> <BR><FONT 
    face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BW-constrained links 
    (like cellular links) allocate set</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; channels based on the service, 
    piggybacking the</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BU _will_not_fit_ in the channel 
    and the packet will</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dropped ! That's not nice is 
    it.</FONT> <BR><FONT face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    Non-BW-constrained links could not care less if</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we piggyback or not.</FONT> 
    <BR><FONT face=Arial size=2>&gt;</FONT> </P>
    <P><FONT face=Arial size=2>First, it was discussed in detail.&nbsp; It's 
    nice.&nbsp; For some applications</FONT> <BR><FONT face=Arial size=2>on some 
    links, it's not practical.&nbsp; For other applications on other</FONT> 
    <BR><FONT face=Arial size=2>links, it is practical.&nbsp; It's been 
    implemented, tested, and it works.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; I realise it was implemented 
    and tested. My issue here </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>is that how does a MN know whether the CN receiving </FONT><BR><FONT 
    color=#0000ff face=Arial size=2>the piggybacked BU will be negatively 
    impacted by piggybacking ?</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>Jari has mentioned this in a 
    previous email but I'll quickly mention</FONT> <BR><FONT color=#0000ff 
    face=Arial size=2>it again. A MN on a WLAN could be sending a BU to a 
    CN</FONT> <BR><FONT color=#0000ff face=Arial size=2>connected to a cellular 
    link which was assigned a fixed channel</FONT> <BR><FONT color=#0000ff 
    face=Arial size=2>size. Because the BU was piggybacked, the entire 
    packet</FONT> <BR><FONT color=#0000ff face=Arial size=2>is dropped as it 
    doesn't fit in the allocated channel. </FONT><BR><FONT color=#0000ff 
    face=Arial size=2>Is there any solution to avoid this scenario ? 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>This is only one of the 
    issues that were mentioned</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>against piggybacking. </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>Hesham</FONT> 
</P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C151A5.277FB8A0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:07:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13095
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:07:09 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26511;
	Wed, 10 Oct 2001 10:06:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03780;
	Wed, 10 Oct 2001 09:06:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AG5XML000013
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:05:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AG5XdZ000012
	for mobile-ip-dist; Wed, 10 Oct 2001 09:05:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AG5TML000005
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:05:29 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03525
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:05:31 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10083
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:05:31 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9AG5iu00619;
	Wed, 10 Oct 2001 09:05:44 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABL00462;
	Wed, 10 Oct 2001 09:05:30 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05810; Wed, 10 Oct 2001 09:05:30 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15300.29130.271521.611520@thomasm-u1.cisco.com>
Date: Wed, 10 Oct 2001 09:05:30 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Hesham Soliman (ERA)" <Hesham.Soliman@era.ericsson.se>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC3DF00.4BC97412@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED2A@eaubrnt018.epa.ericsson.se>
	<3BC3DF00.4BC97412@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Charlie Perkins writes:
 > Hello Hesham,
 > 
 > "Hesham Soliman (EPA)" wrote:
 > 
 > >      the minor changes involve throwing out piggybacking (which
 > >      in my opinion is a nice feature).
 > >
 > >      => This was discussed in detail, it's nice but not practical.
 > >      BW-constrained links (like cellular links) allocate set
 > >      channels based on the service, piggybacking the
 > >      BU _will_not_fit_ in the channel and the packet will
 > >      dropped ! That's not nice is it.
 > >      Non-BW-constrained links could not care less if
 > >      we piggyback or not.
 > >
 > 
 > First, it was discussed in detail.  It's nice.  For some applications
 > on some links, it's not practical.  For other applications on other
 > links, it is practical.  It's been implemented, tested, and it works.

   The problem is that on situations where you'd
   really like to use it (eg, cellular with voip)
   you can't. If somebody can show a real
   situation where it is a real win, that would
   be helpful. That has not been shown to my
   knowledge.

	       Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:10:13 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13222
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:10:13 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14972;
	Wed, 10 Oct 2001 09:08:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04322;
	Wed, 10 Oct 2001 09:07:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AG6XML000050
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:06:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AG6XZH000048
	for mobile-ip-dist; Wed, 10 Oct 2001 09:06:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AG6SML000037
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:06:28 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03908
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:06:30 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10663
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:06:30 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13061;
	Wed, 10 Oct 2001 12:06:26 -0400 (EDT)
Message-Id: <200110101606.MAA13061@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: mobile-ip@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-gnaie-05.txt
Date: Wed, 10 Oct 2001 12:06:26 -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Generalized NAI (GNAIE) Extension for Mobile IPv4
	Author(s)	: M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun
	Filename	: draft-ietf-mobileip-gnaie-05.txt
	Pages		: 6
	Date		: 09-Oct-01
	
The Mobile IP Extensions Rationalization (MIER) specification defines
a new extension header format, that is intended to extend the Mobile
IP extension address space. This document defines the Generalized
Network Access Identifier (NAI) extension, which SHOULD be used by
any Mobile IP extension specifying an extension containing an NAI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mobileip-gnaie-05.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-mobileip-gnaie-05.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:	<20011009101731.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-gnaie-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-gnaie-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:17:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13432
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:17:54 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06658;
	Wed, 10 Oct 2001 10:17:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07378;
	Wed, 10 Oct 2001 09:17:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGFGML000335
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:15:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AGFGIM000333
	for mobile-ip-dist; Wed, 10 Oct 2001 09:15:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGFCML000325
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:15:12 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10499
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:15:12 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02146
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:16:25 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA27054
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:15:13 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 10 Oct 2001 11:08:17 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LX14C>; Wed, 10 Oct 2001 11:14:29 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5548B3@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 11:14:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C151A6.995155F0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151A6.995155F0
Content-Type: text/plain;
	charset="iso-8859-1"

It would have made more sense to make the BU a router header option because
routing is what it is affecting albiet on the end-nodes themselves but I
don't see the need to create an entirely new header just for BU? 

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Tuesday, October 09, 2001 9:46 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion



	> 
>    You do _not_ need to change IPsec. All that is 
>    needed is a few relatively minor changes to 
>    MIP. This has been discussed ad infinitum on 
>    this list. 

	the minor changes involve throwing out piggybacking (which 
in my opinion is a nice feature). 

	=> This was discussed in detail, it's nice but not practical. 
BW-constrained links (like cellular links) allocate set 
channels based on the service, piggybacking the 
BU _will_not_fit_ in the channel and the packet will 
dropped ! That's not nice is it. 
Non-BW-constrained links could not care less if 
we piggyback or not. 

	and getting a new extension 
header. the BU as a destination option has been through a 
lot of interoperability events (we have been at atleast 3- 
2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001 
Conectathon). lets not change it. 

	=> No one suggested changing the BU option, it was 
suggested that it should be carried in a different header. 
That does not imply changing anything in the option. 

	Hesham 


------_=_NextPart_001_01C151A6.995155F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=745210716-10102001>It 
would have made more sense to make the BU a router header option because routing 
is what it is affecting albiet on the end-nodes themselves but I don't see the 
need to create an entirely new header just for BU? </SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hesham Soliman (EPA) 
  [mailto:Hesham.Soliman@ericsson.com.au]<BR><B>Sent:</B> Tuesday, October 09, 
  2001 9:46 PM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> 
  RE: [mobile-ip] MIPv6 - Focus of the security discussion<BR><BR></DIV></FONT>
  <UL>
    <P><FONT face=Arial size=2>&gt; </FONT><BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp; You do _not_ need to change IPsec. All that 
    is</FONT> <BR><FONT face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp; needed is a few 
    relatively minor changes to</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp; MIP. This has been discussed ad infinitum 
    on</FONT> <BR><FONT face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp; this 
    list.</FONT> </P>
    <P><FONT face=Arial size=2>the minor changes involve throwing out 
    piggybacking (which</FONT> <BR><FONT face=Arial size=2>in my opinion is a 
    nice feature).</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; This was discussed in detail, 
    it's nice but not practical. </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>BW-constrained links (like cellular links) allocate set</FONT> 
    <BR><FONT color=#0000ff face=Arial size=2>channels based on the service, 
    piggybacking the </FONT><BR><FONT color=#0000ff face=Arial size=2>BU 
    _will_not_fit_ in the channel and the packet will</FONT> <BR><FONT 
    color=#0000ff face=Arial size=2>dropped ! That's not nice is it. 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>Non-BW-constrained links 
    could not care less if </FONT><BR><FONT color=#0000ff face=Arial size=2>we 
    piggyback or not.</FONT> </P>
    <P><FONT face=Arial size=2>and getting a new extension</FONT> <BR><FONT 
    face=Arial size=2>header. the BU as a destination option has been through a 
    </FONT><BR><FONT face=Arial size=2>lot of interoperability events (we have 
    been at atleast 3- </FONT><BR><FONT face=Arial size=2>2000 Conectathon, 2000 
    ETSI IPv6 bakeoff amd 2001 </FONT><BR><FONT face=Arial size=2>Conectathon). 
    lets not change it.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; No one suggested changing the 
    BU option, it was</FONT> <BR><FONT color=#0000ff face=Arial size=2>suggested 
    that it should be carried in a different header. </FONT><BR><FONT 
    color=#0000ff face=Arial size=2>That does not imply changing anything in the 
    option.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>Hesham</FONT> 
</P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C151A6.995155F0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:29:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13728
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:29:36 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17998;
	Wed, 10 Oct 2001 10:28:43 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10801;
	Wed, 10 Oct 2001 09:28:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGRSML000461
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:27:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AGRSm5000460
	for mobile-ip-dist; Wed, 10 Oct 2001 09:27:28 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGROML000451
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:27:24 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10379
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:27:27 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25853
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:27:26 -0700 (PDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA00496
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:27:26 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 10 Oct 2001 11:26:27 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LXFAQ>; Wed, 10 Oct 2001 11:26:53 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5548F4@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 11:26:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C151A8.5CFB1940"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151A8.5CFB1940
Content-Type: text/plain;
	charset="iso-8859-1"

Hesham,
 
Not that this is the particular place for this discussion but it seems that
limitations of specific access technologies have again emerged into the
requirements of this IETF WG. 
 
Have you explored sending the piggybacked packets over something like - say,
the MAC representation of the signaling PDP context? 
 
It seems that this multiplexing could be accomplished quite easily via some
ROHC middle box?
 
I, for one, don't see much of a problem with some miniscule delay on one
single packet during a handoff of a mobile to mobile or mobile to cable
voice call - even if something like the signaling PDP context is not used.
 
Dropping the packet is probably worse than some miniscule segmentation delay
on one packet. 
 
I could see creating some new form of generic authentication/encryption
header that could be used for integrity and confidentiality of any set of IP
options and used in conjunction with existing IPSEC headers for the
applications; but based upon the timeliness of such work and cross WG
controversy involved in this, it seems that the logical and expedient
solution specified in the existing draft makes the best sense at this
particular point in time. I don't mind if someone suggests such as thing but
I don't think it should hamper the existing MIPv6 proposal which does solve
the problem.
 
As far a creating a new header specifically for BU, I don't see how that
would solve much of anything. Again, I don't mind if someone suggests such
as thing but I don't think it should hamper the acceptance of the existing
MIPv6 proposal.
 
regards,
 
Glenn
 
p.s. I thought this issue was settled already with further discussion
prohibited from the mailing list after being endlessly splattered by Michael
and myself. All this regurgitated FUD seems a bit strange to me. The access
technologies should easily be able to adapt to the bundled packets. 
 
 
-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Wednesday, October 10, 2001 12:56 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion




Hello Charlie, 
>      the minor changes involve throwing out piggybacking (which 
>      in my opinion is a nice feature). 
> 
>      => This was discussed in detail, it's nice but not practical. 
>      BW-constrained links (like cellular links) allocate set 
>      channels based on the service, piggybacking the 
>      BU _will_not_fit_ in the channel and the packet will 
>      dropped ! That's not nice is it. 
>      Non-BW-constrained links could not care less if 
>      we piggyback or not. 
> 
First, it was discussed in detail.  It's nice.  For some applications 
on some links, it's not practical.  For other applications on other 
links, it is practical.  It's been implemented, tested, and it works. 
=> I realise it was implemented and tested. My issue here 
is that how does a MN know whether the CN receiving 
the piggybacked BU will be negatively impacted by piggybacking ? 
Jari has mentioned this in a previous email but I'll quickly mention 
it again. A MN on a WLAN could be sending a BU to a CN 
connected to a cellular link which was assigned a fixed channel 
size. Because the BU was piggybacked, the entire packet 
is dropped as it doesn't fit in the allocated channel. 
Is there any solution to avoid this scenario ? 
This is only one of the issues that were mentioned 
against piggybacking. 
Hesham 

------_=_NextPart_001_01C151A8.5CFB1940
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RESEND: [mobile-ip] MIPv6 - Focus of the security =
discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hesham,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Not that this is the particular place for this =
discussion but it seems that limitations of specific access =
technologies have again emerged into the requirements of this IETF WG. =
</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Have you explored sending the piggybacked packets =
over something like - say, the MAC representation of the signaling PDP =
context? </FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>It seems that this multiplexing could be =
accomplished quite easily via some ROHC middle box?</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I, for one, don't see much of a problem with some =
miniscule delay on one single packet during a handoff of a mobile to =
mobile or mobile to cable voice call - even if something like the =
signaling PDP context is not used.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Dropping the packet is probably worse than some =
miniscule segmentation delay on one packet. </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I could see creating some new form of generic =
authentication/encryption header that could be used for integrity and =
confidentiality of any set of IP options and used in conjunction with =
existing IPSEC headers for the applications; but based upon the =
timeliness of such work and cross WG controversy involved in this, it =
seems that the logical and expedient solution specified in the existing =
draft makes the best sense at this particular point in time. I don't =
mind if someone suggests such as thing but I don't think it should =
hamper the existing MIPv6 proposal which does solve the =
problem.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>As far a creating a new header specifically for BU, =
I don't see how that would solve much of anything. Again, I don't mind =
if someone suggests such as thing but I don't think it should hamper =
the acceptance of the existing MIPv6 proposal.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>regards,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Glenn</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>p.s. I thought this issue was settled already with =
further discussion prohibited from the mailing list after being =
endlessly splattered by Michael and myself. All this regurgitated FUD =
seems a bit strange to me. The access technologies should easily be =
able to adapt to the bundled packets. </FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hesham Soliman (EPA) [<A =
HREF=3D"mailto:Hesham.Soliman@ericsson.com.au">mailto:Hesham.Soliman@eri=
csson.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, October 10, 2001 12:56 AM</FONT>
<BR><FONT SIZE=3D2>To: 'mobile-ip@sunroof.eng.sun.com'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] MIPv6 - Focus of the =
security discussion</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello Charlie, </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the minor changes =
involve throwing out piggybacking (which </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in my opinion is =
a nice feature). </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D&gt; This was =
discussed in detail, it's nice but not practical. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BW-constrained =
links (like cellular links) allocate set </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; channels based on =
the service, piggybacking the </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BU _will_not_fit_ =
in the channel and the packet will </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dropped ! That's =
not nice is it. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Non-BW-constrained links could not care less if </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we piggyback or =
not. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>First, it was discussed in detail.&nbsp; It's =
nice.&nbsp; For some applications </FONT>
<BR><FONT SIZE=3D2>on some links, it's not practical.&nbsp; For other =
applications on other </FONT>
<BR><FONT SIZE=3D2>links, it is practical.&nbsp; It's been implemented, =
tested, and it works. </FONT>
<BR><FONT SIZE=3D2>=3D&gt; I realise it was implemented and tested. My =
issue here </FONT>
<BR><FONT SIZE=3D2>is that how does a MN know whether the CN receiving =
</FONT>
<BR><FONT SIZE=3D2>the piggybacked BU will be negatively impacted by =
piggybacking ? </FONT>
<BR><FONT SIZE=3D2>Jari has mentioned this in a previous email but I'll =
quickly mention </FONT>
<BR><FONT SIZE=3D2>it again. A MN on a WLAN could be sending a BU to a =
CN </FONT>
<BR><FONT SIZE=3D2>connected to a cellular link which was assigned a =
fixed channel </FONT>
<BR><FONT SIZE=3D2>size. Because the BU was piggybacked, the entire =
packet </FONT>
<BR><FONT SIZE=3D2>is dropped as it doesn't fit in the allocated =
channel. </FONT>
<BR><FONT SIZE=3D2>Is there any solution to avoid this scenario ? =
</FONT>
<BR><FONT SIZE=3D2>This is only one of the issues that were mentioned =
</FONT>
<BR><FONT SIZE=3D2>against piggybacking. </FONT>
<BR><FONT SIZE=3D2>Hesham </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C151A8.5CFB1940--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:30:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13772
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:30:19 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25830;
	Wed, 10 Oct 2001 09:29:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10830;
	Wed, 10 Oct 2001 09:28:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGRsML000472
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:27:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AGRr0S000471
	for mobile-ip-dist; Wed, 10 Oct 2001 09:27:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGRmML000464
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:27:48 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14492
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:27:48 -0700 (PDT)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11594
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:29:00 -0600 (MDT)
Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA11430;
	Wed, 10 Oct 2001 18:28:03 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Pat Calhoun" <pcalhoun@diameter.org>,
        "Basavaraj Patil \(NTC/Dallas\)" <Basavaraj.Patil@nokia.com>,
        "Phil Roberts" <PRoberts@MEGISTO.com>
Subject: RE: [mobile-ip] IESG feedback on AAA keys doc
Date: Wed, 10 Oct 2001 18:28:33 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEAMDIAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3BC2561E.A01B8D20@iprg.nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Thanks Charlie,
the draft look a lot better, However there are still some questions.

Section 2 second bullet.
"2. If the mobile node does not have a Mobility Security Association
       with the foreign agent, it SHOULD include an MN-FA Key Request
       extension 7 as part of its Registration Request that it sends to
       the Foreign Agent."

it SHOULD include an MN-FA Key Request extension 7 as part...
what do you mean by extension 7, I guess it has something to do
with subtype 7, defined where?

Section 2 bullet 3.
same applies here for MN-HA Key Request extension 8...

section 2 bullet 8.
"8. If the Reply passes authentication and contains the Unsolicited
       MN-HA Key Material From AAA extension (see section 6), the mobile
       node generates the key using the Key Material provided, according
       to its security association with the AAA. The resulting key is
       used to establish the mobile node's security association with its
       home agent, and is used to authenticate the MN-HA authentication
       extension."

If the reply passes authentication... the mobile node generates the key
using the Key Material provided...

The key has to be generated first in order to verify authentication since
the key is used in the verification process.

Section 3.
SHA-1 is missing in the table, in 08.txt it was SHA-1 but I believe it
should
be HMAC-SHA-1 that should be used.

Section 4 last paragraph.
"The AAA-key used here is the key that has been previously configured
   as the basis of the security assocation between the mobile node and
   the AAA server creating the key."

The AAA-key used is the one pointed to by the AAA SPI, i.e. the AAA SPI
points
to what algorithm to use and what key to use to create the key.

IANA Considerations.
The number 7 is assigned to several of hte subtypes. Both MN-FA and MN-HA
Key
Request from AAA Subtype. Probably a cut'n'paste error

/Fredrik
>
>Hello folks,
>
>After a few weeks of discussion, I have prepared a new
>version of the document, "AAA Registration Keys for Mobile IP".
>Except for proofreading, it's almost ready to be sent in as a
>revised Internet Draft, and it's available at:
>	http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt
>
>I'll hold off for a little while, in case someone can tell me how
>to resolve the IESG comment about security algorithm IANA namespaces,
>which to expedite discussion I have moved first in the discussion
>below, but which is out of order from the original e-mail from the
>IESG.
>
>Here, starts the follow-on from the IESG comments.
>
>>>       Algorithm Identifier
>>>                  This field indicates the algorithm to be used for
>>>                  future computations of the MN-FA Authentication
>>>                  Extension (see section 3)
>>
>> It would be good to state explicitely state that this is the same
>> algorithm identifier as defined in XXX (section 3 doesn't seem to do
>> this either). This document doesn't say. I.e., this presumably points
>> to an existing name space managed by IANA. What is it? [hmm I later
>> see that this is a new name space.. see comment below.]
>
>I am happy to use another existing name space, but the only
>one I find doesn't have HMAC-MD5 in it:
>
>========================================================================
>  Hash Algorithm                     Value            References
>  --------------                     -----            ----------
>  MD5                                  1               [RFC1321]
>  SHA                                  2              FIPS 180-1
>  Tiger                                3              See Reference [TIGER]
>  SHA2-256                             4                 [Leech]
>  SHA2-384                             5                 [Leech]
>  SHA2-512                             6                 [Leech]
>========================================================================
>
>Should we define some more values?  How do I find out the up-to-date
>list?  Is this list being actively maintained?  If we use this list,
>do we have to wait until someone actively figures out the right way
>to keep this list up-to-date (assuming that it is not now). (***)
>
>............  (now, from the top) ..............
>
>> This is a comment that probably applies to lots of MIP
>> documents. Please define "security association" in the MIP context. In
>> IPsec terminology, for instance, it means something very
>> specific. I.e., keys, SPIs, etc., and works only between a pair of
>> nodes. Once an association exists, encrypted packets can be sent. No
>> further negotiation is needed. Also, one can have multiple (different
>> SAs between the same set of machines). This document says:
>>
>>    node and its home agent.  When the mobile node shares a security
>>    association with its home AAA server, however, it is possible to use
>>    that security association to create derivative security associations
>>    between the mobile node and its home agent, and again between the
>>    mobile node and the foreign agent currently offering connectivity to
>>    the mobile node.  This document specifies extensions to the Mobile
>>
>> The MN talks to its HA, not a AAA server. So I'm not clear what is
>> meant by "shares a security association". From my perspective, it
>> seems like "security relationship" would be more accurate terminology.
>
>The mobile node is expected to produce authentication data according
>to the security algorithm configured for its use with AAA.   I think
>this corresponds exactly with the typical use of the terminology.
>A security relationship would be more general than is intended here.
>But since I don't know exactly what that term means, it's hard to
>be sure.  Maybe the security relationship is the thing that precedes
>and enables the creation of the security association.
>
>> Note that the above paragraph also talks about "security associations"
>> between the MN and HA. Here, the terminology  (I suspect) corresponds
>> more closely to the IPsec usage. But I'm not sure.
>
>I've included a Terminology section.  I hope this isn't opening another
>huge can of worms, but I'm very happy to accept suggestions on how
>to make appropriate and succinct defintions.
>
>> General comment. This document is very loose about whether a MN is
>> talking to a FA/HA or a AAA server. This should be made explicitly
>> clear throughout. Indeed, my assumption is that conceptually, if not
>> in reality, a MN NEVER speaks to an AAA server directly. Rather, it
>> speaks MIP protocols with an HA/FA, and that HA/FA has a side
>> conversation with the AAA server. This should be made much more clear
>> throughout.
>
>O.K.  I will try to do this.
>
>>> 2. Scope of Protocol
>>>
>>>    The protocol and messages in this document are intended to facilitate
>>>    the following operations which may occur between the mobile node, AAA
>>>    server, home agent, and foreign agent.
>>
>> Throughout this section, it should be made explicitly clear *who* is
>> sending a message, and *to* *whom* the message is being sent. Also,
>> when someone processes an extension *who* is doing the
>> processing. This isn't clear from just reading the text.
>
>I'll give it a shot.  Let me know if I succeed -- or fail.
>
>> Also, it might make sense to change the section heading to "overview"
>> rather than Scope, since it does seem like an overview. Assuming this
>> is an overview, I think it would help the reader if the text included
>> steps such as as "FA sends message to AAA server ..." "AAA server does
>> X and returns Y to the FA", "FA generates reply and sends to MN"...
>
>O.K.  I have attempted to do this.
>
>>     2. If the mobile node does not have a Mobility Security Association
>>        with the foreign agent, it SHOULD include an MN-FA Key Request
>>        extension.
>>
>> In what message, and sent to whom?
>
>As part of its Registration Request that it sends to the Foreign Agent.
>
>> What is the RFC reference to the key request extension?
>
>It's defined later in the document.  I've added a cross reference.
>
>>     3. Similarly, if the mobile node does not have a Mobility Security
>>        Association with the home agent, it MUST add an MN-HA Key Request
>>        extension.
>>
>> In message sent to whom?
>
>As part of its Registration Request that it sends to the Foreign Agent.
>
>>     4. If one or more Key Request extensions were added, the MN-AAA
>>        Authentication extension is added to the Registration Request.
>>
>> Added by whom?
>
>The mobile node.
>
>>     5. At the time the information within the MN-AAA Authentication
>>        extension is verified by the AAA server, the AAA server also
>>        generates Key Material for the keys requested by the mobile node,
>>        and causes insertion of the Key Material fields along with the
>>        Registration Reply.
>>
>> So there is an implied step here in which the FA exchanges messages
>> with its local AAA server? Would be good to explicitely say that here.
>
>I have made it more explicit.
>
>> Is that AAA protocol already in place? What RFCs are used? I.e, is
>> there a potential normative reference problem buried here? (I suspect
>> the answer is no, but am not sure.)
>
>The intention was to keep the formulation general, and not dependent
>on the specifics of the AAA protocol.
>
>>     6. The respective AAA keys are distributed to the Home and Foreign
>>        Agent via the AAA protocol.
>>
>> Where are the details of this described?
>
>It is out of scope for this document, and I hope it does not have
>to be specfied as part of a normative reference.  All that we
>should have to do is to specify how the Mobile IP extensions work.
>
>According to this philosophy, some of the steps in the Overview
>amount to over-specification, but I don't think there is any
>serious problem so O.K.
>
>> step 6b) FA sends a reply to the MN
>>
>>>    extension.  In order for the mobile node to make use of key
>>>    information sent to it by the AAA server, the mobile node also has to
>>>    be able to select the appropriate cryptographic algorithm that uses
>>>    the key to produce the authentication.  The following table contains
>>
>> I doubt the AAA server is sending messages to the MN. Isn't it the FA
>> that does this (i.e., it relays this info)? Text could be more
>> precise.
>
>I reworded this to say that the AAA server "creates" the
>key information.
>
>>    Dynamic Mobility Security Associations shared between mobile nodes
>>
>> What is a "Dynamic Mobility Security Association"? Is it different
>> than other types of security associations?
>
>Well, it's not manually configured.   Isn't this well-known usage?
>Do we have to say "dynamically created"?  Otherwise, it is the
>same as the mobility security association defined in RFC 2002.
>
>> Note: IMO, it would be better to move the description formats of the
>> extensions here, rather than at the end. It is a bit confusing to talk
>> about the contents of packet fields prior to having shown the format
>> of the option with all of the fields together.
>
>I didn't see where the packet fields were mentioned.  We used
>the name of some extensions that were defined in RFC 2002.
>The tables supply parameter values for some fields in the
>extension formats, but that's as close as I could get to
>understanding your request here.  Maybe we should move the
>tables after the formats?
>
>>> 4. Key Material Creation and Derivation
>>>
>>>    This section contains the procedures followed in the creation of the
>>>    Key Material by AAA servers, and the key derivation procedures used
>>                                 ^
>>>    by mobile nodes.  Note that the AAA servers will also make use of the
>>
>> insert "extension" as indicated above? Also, better to say "contains
>> the procedure a FA/HA follows when creating ..." (or is the procedure
>> aimed at AAA servers?)
>
>The procedure is aimed at AAA servers, and I couldn't parse the result
>when I put "extension" where you indicated.  The idea is that AAA
>servers will do something that is able to be understood by mobile
>nodes, and that mobility agents (home agent, foreign agent) will
>faithfully transcribe the results into the appropriate Mobile IP
>extensions.  I have added those words to this introductory
>paragraph.  It is still intended to avoid normative references
>here for any AAA protocol.  If necessary, we could create an
>applicability statement and use it along with the introductory section.
>
>>    The example that follows makes use of MD5 in prefix+suffix mode,
>>    whose support is mandatory in Mobile IP [11].  Other cryptographic
>>    functions, such as those listed in 3 MAY also be used.
>>
>> Might be better to make HMAC-MD5 the example. Also, what is meant be
>> "listed in 3 MAY". Should that be "listed in [3] MAY"??
>
>That was supposed to be Section 3.
>
>>     1. The AAA server identifies the mobile node's via a
>>        ``node-address''.  If the Home Address field of the
>>        Registration Request is zero (0), the Mobile Node's NAI is used
>>        instead.
>>
>> First sentence doesn't parse.
>
>Fixed!
>
>> I'm confused by the description above in the sense that it implies
>> that the MN Registration Request is sent to a AAA server. I thought it
>> was sent to a FA.
>
>Here, one has to understand the contents of RFC 2977.  I have added
>a lot of text to that effect in the Introduction.  I hope that's
>sufficient.  Otherwise, we would have to start copying text from
>that document.
>
>> Also, why use the term "node-address"? Don't you really mean the home
>> address? (the term node-address isn't defined anywhere).
>
>Fixed.
>
>>  Maybe you mean to say:
>>
>>     1. The AAA server identifies the mobile node via a
>>        ``node-address''.  The node-address is taken from the Home
>>        Address field of the Registration Request, or the NAI, if the
>>        Home Address field is zero (0).
>>
>> Note again how the text blurs the distinction between the FA and the
>> AAA server. Does the AAA server see the registration request? I would
>> think not. It sees information the FA sends to it, which includes
>> portions of the registration request. The document should really make
>> this clear throughout
>
>I fixed this, I hope.  I also hope it would be clear to someone
>who went through the discussion in RFC 2977.
>
>>>    2. The AAA server generates a random [5] value of at least 64 bits.
>>
>> 64 bits seems short. I'd like someone with security background to
>> comment on this. But I guess this is sent in the clear, so the length
>> may not matter?
>
>That makes sense to me.
>
>>     3. The AAA server inserts the random value into the Key extension in
>>        the ``Key Material'' field.
>>
>> Presumably this field is part of a message or an extension within a
>> message. Which message or extension? Make explicit.
>
>The example is supposed to work for any Key Material extension.
>
>> Note steps 1-3 are done on the server, steps 4-5 on the mobile
>> node. It might be good to make the more clear here, perhaps by having
>> subsections?
>
>O.K.  I did it, but I don't know if it's an improvement or not.
>
>>     4. The mobile node calculates
>>
>>           key = MD5(AAA-key | Key Material | node-address | AAA-key)
>>
>> what is AAA-key? Where does it come from? Ditto for "Key Material" How
>> does the mobile node know which AAA-key to use? Can there only be one
>> (I hope not...)
>
>The AAA-key is what the mobile node shares with the AAA server.
>The Key Material is the 64 random bits.
>
>>       Key Material
>>                  A random [5] value of at least 64 bits.
>>
>> Keying material of only 64 bits? Would this pass security muster??
>
>I reckon it will, but I'm not betting my house on it.  The cryptographic
>strength of the algorithm doesn't depend on this number.
>
>>>       AAA SPI    A 32-bit opaque value, indicating the SPI that the
>>>                  mobile node must use to determine the algorithm to use
>>>                  for establishing the FA security information.
>>
>> How does the mobile node create this SPI? Is this preconfigured?
>
>Yes, or at least out of scope for this document.
>
>>>       FA SPI     A 32-bit opaque value, which the mobile node MUST use
>>>                  to index all the necessary information established for
>>>                  the FA security information after it is decoded.
>>
>> Might be better to say something like:
>>
>>        FA SPI     The SPI for the Security Association to the FA that
>>                   the MN creates as a result of processing this
>extension.
>
>Done.
>
>>>    The Unsolicited MN-FA Key Material From AAA extension, shown
>>>    in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply
>>>    Extension [12].
>>
>> Shouldn't this be moved to the beginning of section 5. (e.g., as it is
>> in Section 6?)
>
>Done!
>
>>>       HA SPI     A 32-bit opaque value, which the mobile node MUST use
>>>                  to index all the necessary information established for
>>>                  the HA security information after it is decoded.
>>
>> Same comment as above w.r.t FA SPI. Ditto for key material.
>
>Done.
>
>>>    the Key Material provided by the home domain AAA server (AAAH). The
>>>    key is intended for use the mobile node to secure future Mobile IP
>>>    registrations with its home agent.  The MN-HA Key Reply MUST appear
>>
>> sentence doesn't parse.
>
>Fixed.
>
>>>    The mobile node uses the Identification field data from the
>>>    Registration Request as its initial synchronization data with the
>>>    home agent.
>>
>> What is the field referred to in this sentence?
>
>If you look at the Registration Request format, there is a field
>called the Identification field.  It allows entities using Mobile IP
>to associated a Registration Reply to the appropriate Registration
>Request.
>
>I don't know if you meant to suggest adding text or not, but I wouldn't
>feel it was appropriate to copy text from RFC 2002{,bis} here.
>
>>> 7. MN-FA Key Request From AAA Subtype
>>>
>>>    The MN-FA Key Request From AAA subtype data uses subtype 7 of the
>>>    Generalized MN-FA Key Request Extension [12].  The MN-FA Key Request
>>>    From AAA extension MUST appear in the Registration Request before the
>>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>>    length.
>>>
>>>
>>> 8. MN-HA Key Request From AAA Subtype
>>>
>>>    The MN-HA Key Request From AAA subtype data uses subtype 7 of the
>>>    Generalized MN-HA Key Request Extension [12].  The MN-HA Key Request
>>>    From AAA extension MUST appear in the Registration Request before the
>>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>>    length.
>>
>> Hmm. What are the above two sections about? The first sentence in each
>> seems redundent. Can't the remaining text just be put in the previous
>> sections that describe the extension?
>
>The extensions, which are Request extensions (not Reply extensions),
>are defined in the Generalized Keys document, and don't have any
>additional format that needs to be specfied.
>
>> Also, why is the ordering important?
>
>The MN-AAA Authentication extension is an "authorization-enabling"
>extension, in the language of RFC 2002bis.  Such extensions have
>to be last.
>
>
>>> 10. IANA Considerations
>>
>> This document requests certain numbers be assigned. Is this required,
>> i.e., are their implementations that already use the numbers? This
>> section should really say TBD for any assignments that it  doesn't
>> care what the  actual value is, and let IANA pick. If it really does
>> care about the value, the text should suggest a certain value be used
>> and mention that the numbers are already in use by existing
>> implementations. That way, IANA has some context for deciding what to
>> do.
>
>The numbers are already in use by implementations.   I have added text
>to the IANA Considerations to that effect.
>
>>>    Section 3 introduces the Algorithm Identifier namespace that requires
>>>    IANA management.  This specification makes use of 1-3; all other
>>>    values other than zero (0) are available for assignment, pending
>>>    review and approval by a Designated Expert [9].
>>
>> Can't you just leverage off an existing MIP name space (i.e, the one
>> used by other extensions?) rather than creating a new one?
>
>See above (***).
>
>
>Regards,
>Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:30:22 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13799
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:30:22 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18976;
	Wed, 10 Oct 2001 10:29:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11085;
	Wed, 10 Oct 2001 09:29:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGSQML000498
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:28:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AGSQwT000497
	for mobile-ip-dist; Wed, 10 Oct 2001 09:28:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGSMML000490
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:28:22 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24166
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:28:25 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17507
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:28:13 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA00752
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:28:24 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 10 Oct 2001 11:27:33 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LXFBP>; Wed, 10 Oct 2001 11:28:00 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5548FB@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 11:27:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C151A8.83CA18A0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151A8.83CA18A0
Content-Type: text/plain;
	charset="iso-8859-1"


Jari,

I am fairly confident that these respective access technology and
compression groups can find acceptable ways around handling piggybacked
binding udpates that meet the requirements for the particular media streams
in question.

Besides route optimized MIPv6 will never be ubiquitous anyway as long as the
binding update processing by CN's is only a SHOULD. The MN and HA will
always have to be complicated by back-off procedures to forward stream
tunnel mechanisms. 

In my opinion removing this complication is more important than removing the
piggyback complication for specific access technologies and compression
mechanisms.

I would rather see the group focus on making the route optimized mobility
ubiquitous and removing the complications of it not being.

Glenn



-----Original Message-----
From: Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se]
Sent: Wednesday, October 10, 2001 2:58 AM
To: Pekka Savola
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion


>Link layer should fragment the IP datagram.

Yes, but then the whole stream of packets is
"moved forward" in terms of delay. Delay
might be bad enough already for this to not
be possible without loss of quality. Could
be better to throw away the whole packet.

Jari

------_=_NextPart_001_01C151A8.83CA18A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RESEND: [mobile-ip] MIPv6 - Focus of the security =
discussion</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Jari,</FONT>
</P>

<P><FONT SIZE=3D2>I am fairly confident that these respective access =
technology and compression groups can find acceptable ways around =
handling piggybacked binding udpates that meet the requirements for the =
particular media streams in question.</FONT></P>

<P><FONT SIZE=3D2>Besides route optimized MIPv6 will never be =
ubiquitous anyway as long as the binding update processing by CN's is =
only a SHOULD. The MN and HA will always have to be complicated by =
back-off procedures to forward stream tunnel mechanisms. </FONT></P>

<P><FONT SIZE=3D2>In my opinion removing this complication is more =
important than removing the piggyback complication for specific access =
technologies and compression mechanisms.</FONT></P>

<P><FONT SIZE=3D2>I would rather see the group focus on making the =
route optimized mobility ubiquitous and removing the complications of =
it not being.</FONT></P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jari Arkko [<A =
HREF=3D"mailto:Jari.Arkko@lmf.ericsson.se">mailto:Jari.Arkko@lmf.ericsso=
n.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, October 10, 2001 2:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Pekka Savola</FONT>
<BR><FONT SIZE=3D2>Cc: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] MIPv6 - Focus of the =
security discussion</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;Link layer should fragment the IP =
datagram.</FONT>
</P>

<P><FONT SIZE=3D2>Yes, but then the whole stream of packets is</FONT>
<BR><FONT SIZE=3D2>&quot;moved forward&quot; in terms of delay. =
Delay</FONT>
<BR><FONT SIZE=3D2>might be bad enough already for this to not</FONT>
<BR><FONT SIZE=3D2>be possible without loss of quality. Could</FONT>
<BR><FONT SIZE=3D2>be better to throw away the whole packet.</FONT>
</P>

<P><FONT SIZE=3D2>Jari</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C151A8.83CA18A0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 12:41:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14174
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 12:41:24 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29929;
	Wed, 10 Oct 2001 09:36:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11514;
	Wed, 10 Oct 2001 09:30:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGSpML000520
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:28:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AGSoCc000517
	for mobile-ip-dist; Wed, 10 Oct 2001 09:28:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AGShML000502
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:28:43 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24218
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:28:46 -0700 (PDT)
Received: from mail.tahoenetworks.com (nat2.tahoenetworks.com [63.99.114.2])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07506
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 09:28:44 -0700 (PDT)
Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Wed, 10 Oct 2001 09:28:44 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151A8.A0E80ED8"
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Wed, 10 Oct 2001 09:28:43 -0700
Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
Thread-Topic: [mobile-ip] MIPv6 - Focus of the security discussion
Thread-Index: AcFRXyz2ZhXoTyIXQ9aMebneH6/+JQASJG2A
From: "Mohan Parthasarathy" <mohanp@tahoenetworks.com>
To: <mobile-ip@sunroof.eng.sun.com>, <pekkas@netcore.fi>
X-OriginalArrivalTime: 10 Oct 2001 16:28:44.0269 (UTC) FILETIME=[A12051D0:01C151A8]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C151A8.A0E80ED8
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


=20
>=20
> >Uhh.. Am I missing something that should be painfully obvious, but
isn't
> >Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if
in
> >doubt.
>=20
> No, the issue was what happens if you reserve a "tight" channel for
> e.g. a multimedia stream and then you get randomly hit by extra ~ 20
> bytes in the packets. What if the bytes don't fit the channel? The

I don't understand why this problem is specific to binding updates.
Are you saying that under such a reservation, the packet size can't
vary at all ? If I have been sending 1000 bytes, which is way less
than 1280, if I send 1020 bytes, will it be dropped ? Then when such
a tight channel is reserved there should be indication to IP to
change its MTU value so that path mtu discovery can kick in.=20

-mohan

> channel was allocated based on the assumption that you will only
> be sending the particular stream packets. Packet-Too-Big would
> be inappropriate, particularly when you'd have to complain about
> a size < 1280...
>=20
> This is an interesting problem, and it also has variations: a
> node that itself is attached to the tight channel would be able
> to avoid piggybacking in its own messages, but the node on the
> other end might not know this is necessary.
>=20
> There might be solutions to this, but at least I'm not aware
> of them. Any suggestions?
>=20
> Jari

------_=_NextPart_001_01C151A8.A0E80ED8
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>&nbsp;</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt;Uhh.. Am I missing something that should be =
painfully obvious, but isn't</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;Path MTU Discovery supposed to detect =
this?&nbsp; Or just have MTU 1280 if in</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;doubt.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; No, the issue was what happens if you reserve a =
&quot;tight&quot; channel for</FONT>

<BR><FONT SIZE=3D2>&gt; e.g. a multimedia stream and then you get =
randomly hit by extra ~ 20</FONT>

<BR><FONT SIZE=3D2>&gt; bytes in the packets. What if the bytes don't =
fit the channel? The</FONT>
</P>

<P><FONT SIZE=3D2>I don't understand why this problem is specific to =
binding updates.</FONT>

<BR><FONT SIZE=3D2>Are you saying that under such a reservation, the =
packet size can't</FONT>

<BR><FONT SIZE=3D2>vary at all ? If I have been sending 1000 bytes, =
which is way less</FONT>

<BR><FONT SIZE=3D2>than 1280, if I send 1020 bytes, will it be dropped ? =
Then when such</FONT>

<BR><FONT SIZE=3D2>a tight channel is reserved there should be =
indication to IP to</FONT>

<BR><FONT SIZE=3D2>change its MTU value so that path mtu discovery can =
kick in. </FONT>
</P>

<P><FONT SIZE=3D2>-mohan</FONT>
</P>

<P><FONT SIZE=3D2>&gt; channel was allocated based on the assumption =
that you will only</FONT>

<BR><FONT SIZE=3D2>&gt; be sending the particular stream packets. =
Packet-Too-Big would</FONT>

<BR><FONT SIZE=3D2>&gt; be inappropriate, particularly when you'd have =
to complain about</FONT>

<BR><FONT SIZE=3D2>&gt; a size &lt; 1280...</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; This is an interesting problem, and it also has =
variations: a</FONT>

<BR><FONT SIZE=3D2>&gt; node that itself is attached to the tight =
channel would be able</FONT>

<BR><FONT SIZE=3D2>&gt; to avoid piggybacking in its own messages, but =
the node on the</FONT>

<BR><FONT SIZE=3D2>&gt; other end might not know this is =
necessary.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; There might be solutions to this, but at least =
I'm not aware</FONT>

<BR><FONT SIZE=3D2>&gt; of them. Any suggestions?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Jari</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C151A8.A0E80ED8--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:17:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15327
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:17:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03623;
	Wed, 10 Oct 2001 11:16:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06712;
	Wed, 10 Oct 2001 10:16:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHEvML000917
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:14:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHEv20000916
	for mobile-ip-dist; Wed, 10 Oct 2001 10:14:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHErML000909
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:14:53 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25199
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:14:56 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24603
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:14:56 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9AHF9u20335;
	Wed, 10 Oct 2001 10:15:09 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABL02293;
	Wed, 10 Oct 2001 10:14:33 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05820; Wed, 10 Oct 2001 10:14:31 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15300.33271.335089.998138@thomasm-u1.cisco.com>
Date: Wed, 10 Oct 2001 10:14:31 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: <pekkas@netcore.fi>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Mohan Parthasarathy writes:
 > I don't understand why this problem is specific to binding updates.
 > Are you saying that under such a reservation, the packet size can't
 > vary at all ? If I have been sending 1000 bytes, which is way less
 > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
 > a tight channel is reserved there should be indication to IP to
 > change its MTU value so that path mtu discovery can kick in. 

   Yup, that's the problem. It really has nothing to do
   with MTU; it's about keeping within the constraint of
   a reservation. MTU is link based, not flow based afterall.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:21:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15502
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:21:52 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22539;
	Wed, 10 Oct 2001 10:21:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08177;
	Wed, 10 Oct 2001 10:20:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHKAML001028
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:20:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHKAZJ001027
	for mobile-ip-dist; Wed, 10 Oct 2001 10:20:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHK7ML001020
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:20:07 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07852
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:20:10 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28059
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:20:10 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA06943
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:20:09 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AHK8v18502
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:20:08 -0700
X-mProtect:  Wed, 10 Oct 2001 10:20:08 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdYba2kj; Wed, 10 Oct 2001 10:20:07 PDT
Message-ID: <3BC48347.DC1A29CD@iprg.nokia.com>
Date: Wed, 10 Oct 2001 10:20:07 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED25@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> "Hesham Soliman (EPA)" wrote:
> 
>      Vijay,

>      The MIPv6 draft will not have the key distribution mechanism
>      embedded in it. It will just refer to another draft.
> 
>      => Is this your own decision or the ADs/WG chairs ??
>      I didn't see anything like this on the list before but
>      I might have missed something.

if it is not obvious for you, I cant help it. it does not make
sense to have they key distribution mechanism for MN and CN
embedded in the MIPv6 draft. it has never been so. if you care 
to take a look at draft 15, it might make sense to you.

vijay


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:25:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15617
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:24:59 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11767;
	Wed, 10 Oct 2001 11:24:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09386;
	Wed, 10 Oct 2001 10:24:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHNfML001121
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:23:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHNfTM001120
	for mobile-ip-dist; Wed, 10 Oct 2001 10:23:41 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHNbML001113
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:23:37 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09129
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:23:40 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10890
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:23:29 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA07175
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:23:39 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AHNcG26041
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:23:38 -0700
X-mProtect:  Wed, 10 Oct 2001 10:23:38 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd810sNN; Wed, 10 Oct 2001 10:23:37 PDT
Message-ID: <3BC48419.57EEB789@iprg.nokia.com>
Date: Wed, 10 Oct 2001 10:23:37 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED2A@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> "Hesham Soliman (EPA)" wrote:
> 
      and getting a new extension
>      header. the BU as a destination option has been through a
>      lot of interoperability events (we have been at atleast 3-
>      2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001
>      Conectathon). lets not change it.
> 
>      => No one suggested changing the BU option, it was
>      suggested that it should be carried in a different header.
>      That does not imply changing anything in the option.

read the sentence again. when i said lets not change it,
i meant lets not change BU as a destination option.

vijay


> 
>      Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:26:57 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15722
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:26:56 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25467;
	Wed, 10 Oct 2001 10:26:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09819;
	Wed, 10 Oct 2001 10:25:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHOjML001159
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:24:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHOjrW001158
	for mobile-ip-dist; Wed, 10 Oct 2001 10:24:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHOfML001145
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:24:41 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28243
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:24:44 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11973
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:24:32 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9AHOuu26988
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:24:56 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABL02657;
	Wed, 10 Oct 2001 10:24:32 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05823; Wed, 10 Oct 2001 10:24:31 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15300.33871.590231.560847@thomasm-u1.cisco.com>
Date: Wed, 10 Oct 2001 10:24:31 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC48347.DC1A29CD@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED25@eaubrnt018.epa.ericsson.se>
	<3BC48347.DC1A29CD@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Vijay Devarapalli writes:
 > > "Hesham Soliman (EPA)" wrote:
 > > 
 > >      Vijay,
 > 
 > >      The MIPv6 draft will not have the key distribution mechanism
 > >      embedded in it. It will just refer to another draft.
 > > 
 > >      => Is this your own decision or the ADs/WG chairs ??
 > >      I didn't see anything like this on the list before but
 > >      I might have missed something.
 > 
 > if it is not obvious for you, I cant help it. it does not make
 > sense to have they key distribution mechanism for MN and CN
 > embedded in the MIPv6 draft. it has never been so. if you care 
 > to take a look at draft 15, it might make sense to you.

   The problem with the -15 draft is that it points 
   to the null set. Quite literally. Nor is that likely
   to change in its current form.

   This is a problem.

	  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:30:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15878
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:30:17 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27416;
	Wed, 10 Oct 2001 10:29:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11513;
	Wed, 10 Oct 2001 10:29:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHSaML001342
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:28:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHSaBB001341
	for mobile-ip-dist; Wed, 10 Oct 2001 10:28:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHSWML001334
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:28:33 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10434
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:28:36 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03548
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:28:36 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA07536;
	Wed, 10 Oct 2001 10:28:35 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AHSY704475;
	Wed, 10 Oct 2001 10:28:34 -0700
X-mProtect:  Wed, 10 Oct 2001 10:28:34 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd3p5vsS; Wed, 10 Oct 2001 10:28:33 PDT
Message-ID: <3BC48542.76ED17CE@iprg.nokia.com>
Date: Wed, 10 Oct 2001 10:28:34 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Glenn Morrow <gmorrow@nortelnetworks.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E5548FB@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Glenn,

> Besides route optimized MIPv6 will never be ubiquitous anyway as long as the
> binding update processing by CN's is only a SHOULD. The MN and HA will always
> have to be complicated by back-off procedures to forward stream tunnel
> mechanisms.

I think it's too late by more than a year to change this from
a SHOULD to a MUST.  And, anyway, we can hope that by the time
we're pushing multiple billions of IPv6 nodes, the benefits of
routing directly to the care-of address are obvious enough, and
the code well enough understood.  Then naturally, most nodes
will process Binding Updates.

> In my opinion removing this complication is more important than removing the
> piggyback complication for specific access technologies and compression
> mechanisms.
> 
> I would rather see the group focus on making the route optimized mobility
> ubiquitous and removing the complications of it not being.

The complications of using Destination Options with payload are all
on the sending side.  The receivers implementation is very natural.
That's why it makes very much sense to me, to leave it as a possible
option for _senders_ that want to maximize the performance of their
communications.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:32:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16018
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:32:28 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28608;
	Wed, 10 Oct 2001 10:31:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12418;
	Wed, 10 Oct 2001 10:31:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHULML001408
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:30:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHULXJ001407
	for mobile-ip-dist; Wed, 10 Oct 2001 10:30:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHUHML001400
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:30:17 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11099
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:30:21 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17839
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:30:19 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA07744
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:30:17 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AHUHg09355
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:30:17 -0700
X-mProtect:  Wed, 10 Oct 2001 10:30:17 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdtmKVzy; Wed, 10 Oct 2001 10:30:15 PDT
Message-ID: <3BC485A7.5DD4DE76@iprg.nokia.com>
Date: Wed, 10 Oct 2001 10:30:15 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED25@eaubrnt018.epa.ericsson.se>
		<3BC48347.DC1A29CD@iprg.nokia.com> <15300.33871.590231.560847@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
>  > if it is not obvious for you, I cant help it. it does not make
>  > sense to have they key distribution mechanism for MN and CN
>  > embedded in the MIPv6 draft. it has never been so. if you care
>  > to take a look at draft 15, it might make sense to you.
> 
>    The problem with the -15 draft is that it points
>    to the null set. Quite literally. Nor is that likely
>    to change in its current form.

i am more optimistic. once the current proposals 
(BAKE/SUCV/PBK/whatever) are compared with the 
requirements draft, i am confident that we can 
come up with an acceptable solution. And this is 
what the WG should be concentrating on (IMHO).

vijay

> 
>    This is a problem.
> 
>           Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:45:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16397
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:45:55 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01650;
	Wed, 10 Oct 2001 11:45:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15237;
	Wed, 10 Oct 2001 10:45:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHiBML001662
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:44:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHiBdV001661
	for mobile-ip-dist; Wed, 10 Oct 2001 10:44:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHi7ML001654
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:44:07 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14990
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:44:09 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00383
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:43:57 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9AHi9k21670
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:44:09 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABL03358;
	Wed, 10 Oct 2001 10:44:00 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05826; Wed, 10 Oct 2001 10:43:59 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15300.35039.736471.526733@thomasm-u1.cisco.com>
Date: Wed, 10 Oct 2001 10:43:59 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC485A7.5DD4DE76@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED25@eaubrnt018.epa.ericsson.se>
	<3BC48347.DC1A29CD@iprg.nokia.com>
	<15300.33871.590231.560847@thomasm-u1.cisco.com>
	<3BC485A7.5DD4DE76@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Vijay Devarapalli writes:
 > Michael Thomas wrote:
 > > 
 > >  > if it is not obvious for you, I cant help it. it does not make
 > >  > sense to have they key distribution mechanism for MN and CN
 > >  > embedded in the MIPv6 draft. it has never been so. if you care
 > >  > to take a look at draft 15, it might make sense to you.
 > > 
 > >    The problem with the -15 draft is that it points
 > >    to the null set. Quite literally. Nor is that likely
 > >    to change in its current form.
 > 
 > i am more optimistic. once the current proposals 
 > (BAKE/SUCV/PBK/whatever) are compared with the 
 > requirements draft, i am confident that we can 
 > come up with an acceptable solution. And this is 
 > what the WG should be concentrating on (IMHO).

   None of these provide for strong authentication.
   Nor should they; key distribution protocols for
   strong authentication are well beyond the scope
   of this working group.

   That leaves you with a hole in the requirements
   with -15.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:57:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16773
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:57:12 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12290;
	Wed, 10 Oct 2001 11:56:17 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18610;
	Wed, 10 Oct 2001 10:56:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHtWML001818
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:55:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHtWV4001817
	for mobile-ip-dist; Wed, 10 Oct 2001 10:55:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHtRML001809
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:55:27 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18330
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:55:29 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11389
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:55:17 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA09702;
	Wed, 10 Oct 2001 10:55:28 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AHtRD29401;
	Wed, 10 Oct 2001 10:55:27 -0700
X-mProtect:  Wed, 10 Oct 2001 10:55:27 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpd3mOqmX; Wed, 10 Oct 2001 10:55:25 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA07853; Wed, 10 Oct 2001 10:55:25 -0700 (PDT)
Message-ID: <3BC48B8D.48BB04AF@iprg.nokia.com>
Date: Wed, 10 Oct 2001 10:55:25 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: jari.arkko@ericsson.fi
Subject: Re: [mobile-ip] protecting BUs
References: <3BC4494D.9010507@piuha.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Just some minor comments (piggybacking):

There seem to be no clear comment on that when sending data and BU packets
separately one also reserves a L2 channel more often. In addition to the
L3 payload issues, this can be a significant factor where piggybacking
can result in savings of last hop bandwidth.

[draft Ch. 7.5]
>     Firewalls  and  other similar devices should be able to process piggy-
>     backed packets, even if they have BU options in them. If they  do  not
>     let such traffic through they will also not let regular Mobile IP Home
>     Address options through, blocking all traffic. If the BUs are sent  in
>     separate packets, the firewalls have to have rules to allow this traf-
>     fic in.

Since there need to be home address options in BU packets,
and if a firewall has rules for data packets based on home address option,
why would BU packets need separate rules?

> There are no key distribution mechanisms currently designed to key -14 BSAs
is a bit strong statement: would it be more like
There are currently no established rules for keying -14 BSAs for strong
authentication using currently available key distribution mechanisms.

There is work in progress on many key distribution schemes in e.g. with some
extensions to the aaa; also one wonders why should, say, ipsra mechanisms
be completely unable to key a BSA on every movement, to provide an
independent one-time key for each BU? They would not be optimal at all,
but isn't IKE also a bit heavy on signaling?

BR,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 13:58:48 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16815
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 13:58:48 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11913;
	Wed, 10 Oct 2001 10:57:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18523;
	Wed, 10 Oct 2001 10:56:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHt5ML001806
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:55:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AHt5AS001805
	for mobile-ip-dist; Wed, 10 Oct 2001 10:55:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AHt1ML001798
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:55:01 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06542
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:55:02 -0700 (PDT)
Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01910
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 10:55:00 -0700 (PDT)
Received: (from msa@localhost)
	by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA14581;
	Wed, 10 Oct 2001 20:54:58 +0300
Date: Wed, 10 Oct 2001 20:54:58 +0300
Message-Id: <200110101754.UAA14581@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: mobile-ip@sunroof.eng.sun.com
CC: mobile-ip@sunroof.eng.sun.com, jari.arkko@ericsson.fi
In-reply-to: <3BC46992.DA860F7F@iprg.nokia.com> (jmalinen@iprg.nokia.com)
Subject: Re: [mobile-ip] protecting BUs
References: <3BC4494D.9010507@piuha.net> <3BC46992.DA860F7F@iprg.nokia.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>

>   consider whether there is a next header with a hop-by-hop option. If
>   immediately in the IPv6 header the next header field has a unknown value,
>   the node cannot avoid reading this value if it checks for the h-b-h,
>   shouldn't it then discard the packet according to the above?

No! No! A *router* on the path should only examine the IP header *and*
check if the immediate next-header is hop-by-hop header (in which case
it may need to look into this).

*Routers* do not care whether next header field is unknown to them.

The rule about dropping a packet with unknown extension header
conserns only the end-node.

-- 
Markku Savela <Markku.Savela@iki.fi>


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 14:05:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17075
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 14:05:17 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15466;
	Wed, 10 Oct 2001 11:04:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21409;
	Wed, 10 Oct 2001 11:04:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AI2oML001993
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:02:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AI2oV7001992
	for mobile-ip-dist; Wed, 10 Oct 2001 11:02:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AI2kML001985
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:02:46 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08612
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:02:47 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13150
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:03:57 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA10263;
	Wed, 10 Oct 2001 11:02:37 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AI2bV13118;
	Wed, 10 Oct 2001 11:02:37 -0700
X-mProtect:  Wed, 10 Oct 2001 11:02:37 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdknZIs8; Wed, 10 Oct 2001 11:02:35 PDT
Message-ID: <3BC48D3B.DDB2F432@iprg.nokia.com>
Date: Wed, 10 Oct 2001 11:02:36 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com> <15300.33271.335089.998138@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

> Mohan Parthasarathy writes:
>  > I don't understand why this problem is specific to binding updates.
>  > Are you saying that under such a reservation, the packet size can't
>  > vary at all ? If I have been sending 1000 bytes, which is way less
>  > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
>  > a tight channel is reserved there should be indication to IP to
>  > change its MTU value so that path mtu discovery can kick in.
>
>    Yup, that's the problem. It really has nothing to do
>    with MTU; it's about keeping within the constraint of
>    a reservation. MTU is link based, not flow based afterall.
>

It is not entirely accurate to say that you cannot piggyback when using a
dedicated channel. For instance, it is well-known that header compression
gain can vary from packet to packet, thus affecting the compressor states.
In a dedicated channel, which is what this thread is focussing on
I assume, in order to accommodate `header bursts', you need to reserve for
the worst-case. Now, IF that's the case, piggybacking a BU does not
necessarily violate the reservation, since, I could piggyback a BU on  FO
or SO packets (which have better compression gain compared to a packet
with no compression gain). The BU length, assuming 12 bytes for
Authentication Data, is 26 bytes compared to 40 bytes for IPv6 header
alone. So, when IPv6 header is not present, as would be the case in a SO
or FO packet, you _can_ piggyback, even in the so-called dedicated
channels.

Regards,

-Rajeev





>
>         Mike



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 14:06:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17143
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 14:06:19 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15669;
	Wed, 10 Oct 2001 11:04:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21458;
	Wed, 10 Oct 2001 11:04:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AI2uML002003
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:02:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AI2udq002002
	for mobile-ip-dist; Wed, 10 Oct 2001 11:02:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AI2qML001995
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:02:52 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08713
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:02:53 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06645
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:02:52 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA10281;
	Wed, 10 Oct 2001 11:02:52 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AI2pr13541;
	Wed, 10 Oct 2001 11:02:51 -0700
X-mProtect:  Wed, 10 Oct 2001 11:02:51 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdKyMMnP; Wed, 10 Oct 2001 11:02:49 PDT
Message-ID: <3BC48D49.FBDA3414@iprg.nokia.com>
Date: Wed, 10 Oct 2001 11:02:49 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] IESG feedback on AAA keys doc
References: <MJEMJBGGCLLDLFFAHLJKAEAMDIAA.fredrik.johansson@ipunplugged.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Fredrik,

Thanks for your comments.

> it SHOULD include an MN-FA Key Request extension 7 as part...
> what do you mean by extension 7, I guess it has something to do
> with subtype 7, defined where?
> 
> Section 2 bullet 3.
> same applies here for MN-HA Key Request extension 8...

These were meant to be cross-references to the appropriate
section, not type numbers!  I've fixed this now.

> section 2 bullet 8.
> "8. If the Reply passes authentication and contains the Unsolicited
>        MN-HA Key Material From AAA extension (see section 6), the mobile
>        node generates the key using the Key Material provided, according
>        to its security association with the AAA. The resulting key is
>        used to establish the mobile node's security association with its
>        home agent, and is used to authenticate the MN-HA authentication
>        extension."
> 
> If the reply passes authentication... the mobile node generates the key
> using the Key Material provided...
> 
> The key has to be generated first in order to verify authentication since
> the key is used in the verification process.

Good point!   I have reworded this paragraph.


> Section 3.
> SHA-1 is missing in the table, in 08.txt it was SHA-1 but I believe it
> should
> be HMAC-SHA-1 that should be used.

O.K.  I made an entry in the table for both SHA-1 and HMAC-SHA-1.
However, this may become a moot point, depending on what is decided
about where this table should most appropriately be specified.

Maybe the right thing to do is to delete the table, and ask for
some new numbers to be allocated in the IKE table.  What do you
think we should do?  Shouldn't we also add something for AES and
maybe for the recently mentioned PRF variants?  But why should
Mobile-IP be in charge of such a table?

> Section 4 last paragraph.
> "The AAA-key used here is the key that has been previously configured
>    as the basis of the security assocation between the mobile node and
>    the AAA server creating the key."
> 
> The AAA-key used is the one pointed to by the AAA SPI, i.e. the AAA SPI
> points
> to what algorithm to use and what key to use to create the key.

Thanks.  I made the clarification you suggested, while also keeping the
more explanatory text.  I could also delete the explanatory text if
you think that would be better.

> IANA Considerations.
> The number 7 is assigned to several of hte subtypes. Both MN-FA and MN-HA
> Key
> Request from AAA Subtype. Probably a cut'n'paste error


These numbers were supposed to be whatever was already in use.
They could both be 7, since they are subtypes of different
generalized extensions.  However, if there isn't any real
problem with changing the numbers, then we probably ought to
leave it as TBD, and let IANA pick the numbers.  What do you
think?


Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 14:26:52 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17588
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 14:26:52 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10155;
	Wed, 10 Oct 2001 12:25:42 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28102;
	Wed, 10 Oct 2001 11:25:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AIOoML002268
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:24:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AIOoNt002267
	for mobile-ip-dist; Wed, 10 Oct 2001 11:24:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AIOkML002259
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:24:46 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27222
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:24:48 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27809
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:25:57 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9AIMdC17062;
	Wed, 10 Oct 2001 11:22:40 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABL04872;
	Wed, 10 Oct 2001 11:24:32 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA05836; Wed, 10 Oct 2001 11:24:32 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15300.37472.221083.604277@thomasm-u1.cisco.com>
Date: Wed, 10 Oct 2001 11:24:32 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC48D3B.DDB2F432@iprg.nokia.com>
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
	<15300.33271.335089.998138@thomasm-u1.cisco.com>
	<3BC48D3B.DDB2F432@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Rajeev Koodli writes:
 > It is not entirely accurate to say that you cannot piggyback when using a
 > dedicated channel. For instance, it is well-known that header compression
 > gain can vary from packet to packet, thus affecting the compressor states.
 > In a dedicated channel, which is what this thread is focussing on
 > I assume, in order to accommodate `header bursts', you need to reserve for
 > the worst-case. 

   If you have to allocate for the worst case,
   why run header compression at all for those
   L2's?

   Serious question. I truly don't understand how
   folks expect ROHC will be helpful for voip
   traffic in cellular/wireless environments. This
   is the reason that the DOCSIS cable MAC uses the
   more predictable, but less bandwidth efficient
   payload header suppression (PHS).

		  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 14:46:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18164
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 14:46:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05652;
	Wed, 10 Oct 2001 11:46:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03647;
	Wed, 10 Oct 2001 11:45:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AIitML002399
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:44:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AIitqC002398
	for mobile-ip-dist; Wed, 10 Oct 2001 11:44:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AIipML002391
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:44:51 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03241
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:44:53 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05152
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:44:52 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA14490
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 13:44:51 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 10 Oct 2001 13:38:01 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LXJA3>; Wed, 10 Oct 2001 13:44:18 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E554B16@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: "Charles E. Perkins" <charliep@IPRG.nokia.com>
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 10 Oct 2001 13:44:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C151BB.8D7E6690"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151BB.8D7E6690
Content-Type: text/plain;
	charset="iso-8859-1"

Worries below:

-----Original Message-----
From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com]
Sent: Wednesday, October 10, 2001 12:29 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security
discussion



Hello Glenn,

> Besides route optimized MIPv6 will never be ubiquitous anyway as long as
the
> binding update processing by CN's is only a SHOULD. The MN and HA will
always
> have to be complicated by back-off procedures to forward stream tunnel
> mechanisms.

I think it's too late by more than a year to change this from
a SHOULD to a MUST.  And, anyway, we can hope that by the time
we're pushing multiple billions of IPv6 nodes, the benefits of
routing directly to the care-of address are obvious enough, and
the code well enough understood.  Then naturally, most nodes
will process Binding Updates.

GM] I would like to believe this but then I see these documents from the
3GPP mobile vendors that say they won't even support the binding update as a
requirement. It seems to me that if the mobile vendors won't support it as a
requirement, why should the standard OS manufacturers support it? MSFT has
prototyped it, but it ain't in there. I don't see a critical mass going to
Linux and Star office yet, either. I do hope you are right, though, and I
have pretty much resigned myself to it standing as is. I don't see why its a
problem if every now and then I keep bringing the suggestion up on the
mailing list, though.


> In my opinion removing this complication is more important than removing
the
> piggyback complication for specific access technologies and compression
> mechanisms.
> 
> I would rather see the group focus on making the route optimized mobility
> ubiquitous and removing the complications of it not being.

The complications of using Destination Options with payload are all
on the sending side.  The receivers implementation is very natural.
That's why it makes very much sense to me, to leave it as a possible
option for _senders_ that want to maximize the performance of their
communications.


GM] I am definitely O.K. with it being a destination option.

Regards,
Charlie P.

------_=_NextPart_001_01C151BB.8D7E6690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: RESEND: [mobile-ip] MIPv6 - Focus of the security =
discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Worries below:</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Charles E. Perkins [<A =
HREF=3D"mailto:charliep@IPRG.nokia.com">mailto:charliep@IPRG.nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, October 10, 2001 12:29 PM</FONT>
<BR><FONT SIZE=3D2>To: Morrow, Glenn [RICH2:C330:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of =
the security</FONT>
<BR><FONT SIZE=3D2>discussion</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello Glenn,</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Besides route optimized MIPv6 will never be =
ubiquitous anyway as long as the</FONT>
<BR><FONT SIZE=3D2>&gt; binding update processing by CN's is only a =
SHOULD. The MN and HA will always</FONT>
<BR><FONT SIZE=3D2>&gt; have to be complicated by back-off procedures =
to forward stream tunnel</FONT>
<BR><FONT SIZE=3D2>&gt; mechanisms.</FONT>
</P>

<P><FONT SIZE=3D2>I think it's too late by more than a year to change =
this from</FONT>
<BR><FONT SIZE=3D2>a SHOULD to a MUST.&nbsp; And, anyway, we can hope =
that by the time</FONT>
<BR><FONT SIZE=3D2>we're pushing multiple billions of IPv6 nodes, the =
benefits of</FONT>
<BR><FONT SIZE=3D2>routing directly to the care-of address are obvious =
enough, and</FONT>
<BR><FONT SIZE=3D2>the code well enough understood.&nbsp; Then =
naturally, most nodes</FONT>
<BR><FONT SIZE=3D2>will process Binding Updates.</FONT>
</P>

<P><FONT SIZE=3D2>GM] I would like to believe this but then I see these =
documents from the 3GPP mobile vendors that say they won't even support =
the binding update as a requirement. It seems to me that if the mobile =
vendors won't support it as a requirement, why should the standard OS =
manufacturers support it? MSFT has prototyped it, but it ain't in =
there. I don't see a critical mass going to Linux and Star office yet, =
either. I do hope you are right, though, and I have pretty much =
resigned myself to it standing as is. I don't see why its a problem if =
every now and then I keep bringing the suggestion up on the mailing =
list, though.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; In my opinion removing this complication is more =
important than removing the</FONT>
<BR><FONT SIZE=3D2>&gt; piggyback complication for specific access =
technologies and compression</FONT>
<BR><FONT SIZE=3D2>&gt; mechanisms.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would rather see the group focus on making =
the route optimized mobility</FONT>
<BR><FONT SIZE=3D2>&gt; ubiquitous and removing the complications of it =
not being.</FONT>
</P>

<P><FONT SIZE=3D2>The complications of using Destination Options with =
payload are all</FONT>
<BR><FONT SIZE=3D2>on the sending side.&nbsp; The receivers =
implementation is very natural.</FONT>
<BR><FONT SIZE=3D2>That's why it makes very much sense to me, to leave =
it as a possible</FONT>
<BR><FONT SIZE=3D2>option for _senders_ that want to maximize the =
performance of their</FONT>
<BR><FONT SIZE=3D2>communications.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>GM] I am definitely O.K. with it being a destination =
option.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Charlie P.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C151BB.8D7E6690--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 14:51:15 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18342
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 14:51:14 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07635;
	Wed, 10 Oct 2001 11:50:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04794;
	Wed, 10 Oct 2001 11:50:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AInPML002492
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:49:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AInPIR002491
	for mobile-ip-dist; Wed, 10 Oct 2001 11:49:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AInLML002484
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:49:21 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04629
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:49:23 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22332
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:49:23 -0700 (PDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9AInIg25801;
	Wed, 10 Oct 2001 11:49:18 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (dhcp-wall-59-62.cisco.com [171.68.59.62])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABD05626;
	Wed, 10 Oct 2001 11:49:13 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 14:47:20 -0400
To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
Cc: pekkas@netcore.fi
In-Reply-To: <3BC48D3B.DDB2F432@iprg.nokia.com>
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
 <15300.33271.335089.998138@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

At 11:02 AM 10/10/2001 -0700, Rajeev Koodli wrote:
>Michael Thomas wrote:
>
> > Mohan Parthasarathy writes:
> >  > I don't understand why this problem is specific to binding updates.
> >  > Are you saying that under such a reservation, the packet size can't
> >  > vary at all ? If I have been sending 1000 bytes, which is way less
> >  > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
> >  > a tight channel is reserved there should be indication to IP to
> >  > change its MTU value so that path mtu discovery can kick in.
> >
> >    Yup, that's the problem. It really has nothing to do
> >    with MTU; it's about keeping within the constraint of
> >    a reservation. MTU is link based, not flow based afterall.
> >
>
>It is not entirely accurate to say that you cannot piggyback when using a
>dedicated channel. For instance, it is well-known that header compression
>gain can vary from packet to packet, thus affecting the compressor states.
>In a dedicated channel, which is what this thread is focussing on
>I assume, in order to accommodate `header bursts', you need to reserve for
>the worst-case. Now, IF that's the case, piggybacking a BU does not
>necessarily violate the reservation, since, I could piggyback a BU on  FO
>or SO packets (which have better compression gain compared to a packet
>with no compression gain). The BU length, assuming 12 bytes for
>Authentication Data, is 26 bytes compared to 40 bytes for IPv6 header
>alone. So, when IPv6 header is not present, as would be the case in a SO
>or FO packet, you _can_ piggyback, even in the so-called dedicated
>channels.

Rajeev,

Sounds like you are only considering one side here - the MN sending.

Assuming you are using link-by-link compression ... consider the
case where the "other end" is also a MN that can receive and send
"piggybacked" BUs AND is using a similar header compression scheme.
This is a legitimate, if not increasingly prevalent, case.

Unfortunately ... you won't know (on the sending link) which packets
will have headers compressed on the "far-end" link ... as each link
can compress headers independently.

Thus, although you know when it is "safe" to piggyback on the
sending MN link ... you won't know whether the resulting packet
will fit into the "far end" MN link.

So ... I strongly disagree ... you really don't know when it is safe to
add a BU to the (real-time, TDM constrained) flow!

Seems to me that you really should not be piggybacking BUs
without BOTH ENDS agreeing that this is OK.

Not piggybacking is OK as long as you have something like BETH
anyway. If the BU takes a little longer to get where it is going, BETH
should take care of the problem.

Additionally you probably desire some form of over-the-air persistence
on the (non ultra-delay-sensitive) BU (i.e., a re-transmission) ... and
probably don't desire the re-transmission of the real-time packet.

So ... my vote would be for allowing piggybacked BUs only when
both ends say OK. OK?

Comments?

Michael Ramalho


>Regards,
>
>-Rajeev
>
>
>
>
>
> >
> >         Mike


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 14:59:55 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18522
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 14:59:54 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12264;
	Wed, 10 Oct 2001 11:59:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06719;
	Wed, 10 Oct 2001 11:59:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AIwHML002633
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:58:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AIwGFc002632
	for mobile-ip-dist; Wed, 10 Oct 2001 11:58:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AIwDML002625
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:58:13 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23529
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:58:15 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13450
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 11:58:13 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9AIwCV16779;
	Wed, 10 Oct 2001 21:58:12 +0300
Date: Wed, 10 Oct 2001 21:58:12 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Glenn Morrow <gmorrow@nortelnetworks.com>
Subject: [mobile-ip] Requirements for non-MIPv6 implementations [MIPv6 - Focus of the
 security discussion]
In-Reply-To: <3BC48542.76ED17CE@iprg.nokia.com>
Message-ID: <Pine.LNX.4.33.0110102118200.16576-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 10 Oct 2001, Charles E. Perkins wrote:
> Hello Glenn,
>
> > Besides route optimized MIPv6 will never be ubiquitous anyway as long as the
> > binding update processing by CN's is only a SHOULD. The MN and HA will always
> > have to be complicated by back-off procedures to forward stream tunnel
> > mechanisms.
>
> I think it's too late by more than a year to change this from
> a SHOULD to a MUST.  And, anyway, we can hope that by the time
> we're pushing multiple billions of IPv6 nodes, the benefits of
> routing directly to the care-of address are obvious enough, and
> the code well enough understood.  Then naturally, most nodes
> will process Binding Updates.

<perhaps I should just have settled for grinding my teeth....>

About Glenn's awful suggestion..

Issues about BU security are very unclear at the moment.  It may be that a
_good_ solution will not be developed for some time yet, and we'll have to
settle for a mostly working solution.

[ I'm discussing MN to CN problem here, where CN is stationary ]

And still you're suggesting that under every circumstance, you should
always rely on (badly, if at all authenticated) binding updates?  And no
other operation (that is, _reliable_, _always works_, tunneling from HA to
MN) would be allowed?

Sigh.

There's a lot of life outside mobile-ip.  A lot of IPv6 implementations
will very probably never process Binding Updates, Home Address options and
what not unless they are verifiably secure.  No amount of MUST would
change this, (hopefully) only make the draft harder to pass in the IESG if
they're acting responsibly.

Please do not try to enforce (unsound) MUST rules on non-mipv6
implementations.  What's done with MIPv6 with no requirements for
non-mobile nodes might be viewed as a "mobile-ip wg problem", but the
pollution of all the IPv6 is a more general worry :-).

.. I most definitely hope I misunderstood something in the idea ..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords







From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:08:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18711
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:08:49 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17567;
	Wed, 10 Oct 2001 13:07:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09458;
	Wed, 10 Oct 2001 12:08:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJ7HML002741
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:07:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJ7HhV002740
	for mobile-ip-dist; Wed, 10 Oct 2001 12:07:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJ7DML002733
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:07:13 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09189
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:07:15 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21402
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 13:08:26 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA16687;
	Wed, 10 Oct 2001 12:07:14 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AJ7DK25944;
	Wed, 10 Oct 2001 12:07:13 -0700
X-mProtect:  Wed, 10 Oct 2001 12:07:13 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdAs8lcT; Wed, 10 Oct 2001 12:07:11 PDT
Message-ID: <3BC49C60.CE9B7AE4@iprg.nokia.com>
Date: Wed, 10 Oct 2001 12:07:12 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Requirements for non-MIPv6 implementations [MIPv6 - 
 Focus of thesecurity discussion]
References: <Pine.LNX.4.33.0110102118200.16576-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola wrote:

>> I think it's too late by more than a year to change this from
>> a SHOULD to a MUST.  And, anyway, we can hope that by the time
>> we're pushing multiple billions of IPv6 nodes, the benefits of
>> routing directly to the care-of address are obvious enough, and
>> the code well enough understood.  Then naturally, most nodes
>> will process Binding Updates.

> Issues about BU security are very unclear at the moment.  It may be that a
> _good_ solution will not be developed for some time yet, and we'll have to
> settle for a mostly working solution.
> 
> [ I'm discussing MN to CN problem here, where CN is stationary ]
> 
> And still you're suggesting that under every circumstance, you should
> always rely on (badly, if at all authenticated) binding updates?  And no
> other operation (that is, _reliable_, _always works_, tunneling from HA to
> MN) would be allowed?

I am pretty sure that no one has suggested disallowing tunneling from
the Home Agent to the Mobile Node.  If you have seen text otherwise
that you think warrants discussion, please post it to the mailing list.

I also do not think that anyone has suggested that we rely on
poorly authenticated Binding Updates.   At least I don't remember
any such discussion.

> . I most definitely hope I misunderstood something in the idea ..

Well, from the above worries, it may be so.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:12:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18783
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:12:15 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20410;
	Wed, 10 Oct 2001 13:11:23 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10474;
	Wed, 10 Oct 2001 12:11:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJASML002838
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:10:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJASCi002837
	for mobile-ip-dist; Wed, 10 Oct 2001 12:10:28 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJAOML002825
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:10:24 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26426
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:10:26 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19595
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 13:10:15 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17427;
	Wed, 10 Oct 2001 12:10:25 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AJAOW01905;
	Wed, 10 Oct 2001 12:10:24 -0700
X-mProtect:  Wed, 10 Oct 2001 12:10:24 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd8YuPpD; Wed, 10 Oct 2001 12:10:23 PDT
Message-ID: <3BC49D1F.180D1001@iprg.nokia.com>
Date: Wed, 10 Oct 2001 12:10:23 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Glenn Morrow <gmorrow@nortelnetworks.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E554B16@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Glenn,


> GM] I would like to believe this but then I see these documents from the 3GPP
> mobile vendors that say they won't even support the binding update as a
> requirement. It seems to me that if the mobile vendors won't support it as a
> requirement, why should the standard OS manufacturers support it?

3GPP documents are driven by a very strong requirement to utilize
only existing IETF standards, and I believe that is the problem in this
case.  When we have Mobile IPv6 as a Proposed Standard, then I believe
we'll have a case for inclusion of IP-mobility features into subsequent
3GPP standards.

On the other hand, if people say that they wish to change the specification
for supporting Binding Update from a SHOULD to a MUST, then I'll be quite
happy do edit the document accordingly :-)


Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:13:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18833
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:13:47 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21895;
	Wed, 10 Oct 2001 13:13:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29088;
	Wed, 10 Oct 2001 12:12:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJCBML002886
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:12:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJCBFp002885
	for mobile-ip-dist; Wed, 10 Oct 2001 12:12:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJC7ML002878
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:12:08 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26780
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:12:10 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20956
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 13:11:58 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17615;
	Wed, 10 Oct 2001 12:12:02 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AJC1a05512;
	Wed, 10 Oct 2001 12:12:01 -0700
X-mProtect:  Wed, 10 Oct 2001 12:12:01 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd9BQ62K; Wed, 10 Oct 2001 12:11:59 PDT
Message-ID: <3BC49D80.76E54E23@iprg.nokia.com>
Date: Wed, 10 Oct 2001 12:12:00 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
		<15300.33271.335089.998138@thomasm-u1.cisco.com>
		<3BC48D3B.DDB2F432@iprg.nokia.com> <15300.37472.221083.604277@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

> Rajeev Koodli writes:
>  > It is not entirely accurate to say that you cannot piggyback when using a
>  > dedicated channel. For instance, it is well-known that header compression
>  > gain can vary from packet to packet, thus affecting the compressor states.
>  > In a dedicated channel, which is what this thread is focussing on
>  > I assume, in order to accommodate `header bursts', you need to reserve for
>  > the worst-case.
>
>    If you have to allocate for the worst case,
>    why run header compression at all for those
>    L2's?
>

worst-case allocation does not imply CBR-only. A VBR channel (with CIR, PIR,
MBS) would work.


>
>    Serious question. I truly don't understand how
>    folks expect ROHC will be helpful for voip
>    traffic in cellular/wireless environments. This
>

Enlightenment elsewhere!

Regards,

-Rajeev


>    is the reason that the DOCSIS cable MAC uses the
>    more predictable, but less bandwidth efficient
>    payload header suppression (PHS).
>
>                   Mike



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:15:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18890
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:15:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23757;
	Wed, 10 Oct 2001 13:15:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29682;
	Wed, 10 Oct 2001 12:15:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJE3ML002979
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:14:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJE3ik002978
	for mobile-ip-dist; Wed, 10 Oct 2001 12:14:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJDxML002971
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:13:59 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10655
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:14:01 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22656
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 13:13:50 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17791;
	Wed, 10 Oct 2001 12:14:00 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9AJDxZ10745;
	Wed, 10 Oct 2001 12:13:59 -0700
X-mProtect:  Wed, 10 Oct 2001 12:13:59 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdV4edv8; Wed, 10 Oct 2001 12:13:57 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id MAA07952; Wed, 10 Oct 2001 12:13:58 -0700 (PDT)
Message-ID: <3BC49DF6.D3F9B23D@iprg.nokia.com>
Date: Wed, 10 Oct 2001 12:13:58 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: jari.arkko@ericsson.fi
Subject: Re: [mobile-ip] protecting BUs
References: <3BC4494D.9010507@piuha.net> <3BC46992.DA860F7F@iprg.nokia.com> <200110101754.UAA14581@burp.tkv.asdf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Markku Savela wrote:
> 
> > From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
> 
> >   consider whether there is a next header with a hop-by-hop option. If
> >   immediately in the IPv6 header the next header with unknown value,
> >   the node cannot avoid reading this value if it checks for the h-b-h,
> >   shouldn't it then discard the packet according to the above?
> 
> No! No! A *router* on the path should only examine the IP header *and*
> check if the immediate next-header is hop-by-hop header (in which case
> it may need to look into this).
> 
> *Routers* do not care whether next header field is unknown to them.
> 
> The rule about dropping a packet with unknown extension header
> conserns only the end-node.

This is the obviously the more interoperable way to interpret this.
If all did so, there would be no problem with forwarding boxes,
as long as no-one suggests a new value before routing header, source
routing nodes would otherwise suffer. It is advisable trying to
read RFCs and new proposals "the other way around" pondering what are
the worst case interoperation implications their interpretations allow.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:21:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19038
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:21:54 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28087;
	Wed, 10 Oct 2001 13:20:55 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01262;
	Wed, 10 Oct 2001 12:20:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJK0ML003162
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:20:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJK066003161
	for mobile-ip-dist; Wed, 10 Oct 2001 12:20:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJJuML003154
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:19:56 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00955
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:19:56 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08793
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:19:58 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA27693
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 14:19:58 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 10 Oct 2001 14:13:09 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LXK20>; Wed, 10 Oct 2001 14:19:25 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E554BC7@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: Pekka Savola <pekkas@netcore.fi>,
        mobile-ip <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] RE: Requirements for non-MIPv6 implementations [MIPv6 - Focus of the 
         security discussion]
Date: Wed, 10 Oct 2001 14:19:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C151C0.784BF8A0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151C0.784BF8A0
Content-Type: text/plain;
	charset="iso-8859-1"

Actually Pekka, you seem to have confirmed my worries. Do you agree with the
statement:

"MIPv6 will not provide ubiquitous route-optimized mobility for IPv6."?

The other comments about awful, etc.. I am not sure how to respond to but
that's O.K. - I still like you and I understand your point of view quite
well.

-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: Wednesday, October 10, 2001 1:58 PM
To: mobile-ip
Cc: Morrow, Glenn [RICH2:C330:EXCH]
Subject: Requirements for non-MIPv6 implementations [MIPv6 - Focus of
the security discussion]


On Wed, 10 Oct 2001, Charles E. Perkins wrote:
> Hello Glenn,
>
> > Besides route optimized MIPv6 will never be ubiquitous anyway as long as
the
> > binding update processing by CN's is only a SHOULD. The MN and HA will
always
> > have to be complicated by back-off procedures to forward stream tunnel
> > mechanisms.
>
> I think it's too late by more than a year to change this from
> a SHOULD to a MUST.  And, anyway, we can hope that by the time
> we're pushing multiple billions of IPv6 nodes, the benefits of
> routing directly to the care-of address are obvious enough, and
> the code well enough understood.  Then naturally, most nodes
> will process Binding Updates.

<perhaps I should just have settled for grinding my teeth....>

About Glenn's awful suggestion..

Issues about BU security are very unclear at the moment.  It may be that a
_good_ solution will not be developed for some time yet, and we'll have to
settle for a mostly working solution.

[ I'm discussing MN to CN problem here, where CN is stationary ]

And still you're suggesting that under every circumstance, you should
always rely on (badly, if at all authenticated) binding updates?  And no
other operation (that is, _reliable_, _always works_, tunneling from HA to
MN) would be allowed?

Sigh.

There's a lot of life outside mobile-ip.  A lot of IPv6 implementations
will very probably never process Binding Updates, Home Address options and
what not unless they are verifiably secure.  No amount of MUST would
change this, (hopefully) only make the draft harder to pass in the IESG if
they're acting responsibly.

Please do not try to enforce (unsound) MUST rules on non-mipv6
implementations.  What's done with MIPv6 with no requirements for
non-mobile nodes might be viewed as a "mobile-ip wg problem", but the
pollution of all the IPv6 is a more general worry :-).

.. I most definitely hope I misunderstood something in the idea ..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords






------_=_NextPart_001_01C151C0.784BF8A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Requirements for non-MIPv6 implementations [MIPv6 - Focus of =
the  security discussion]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Actually Pekka, you seem to have confirmed my =
worries. Do you agree with the statement:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;MIPv6 will not provide ubiquitous =
route-optimized mobility for IPv6.&quot;?</FONT>
</P>

<P><FONT SIZE=3D2>The other comments about awful, etc.. I am not sure =
how to respond to but that's O.K. - I still like you and I understand =
your point of view quite well.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Pekka Savola [<A =
HREF=3D"mailto:pekkas@netcore.fi">mailto:pekkas@netcore.fi</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, October 10, 2001 1:58 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip</FONT>
<BR><FONT SIZE=3D2>Cc: Morrow, Glenn [RICH2:C330:EXCH]</FONT>
<BR><FONT SIZE=3D2>Subject: Requirements for non-MIPv6 implementations =
[MIPv6 - Focus of</FONT>
<BR><FONT SIZE=3D2>the security discussion]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Wed, 10 Oct 2001, Charles E. Perkins wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Hello Glenn,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Besides route optimized MIPv6 will never =
be ubiquitous anyway as long as the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; binding update processing by CN's is only =
a SHOULD. The MN and HA will always</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; have to be complicated by back-off =
procedures to forward stream tunnel</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mechanisms.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I think it's too late by more than a year to =
change this from</FONT>
<BR><FONT SIZE=3D2>&gt; a SHOULD to a MUST.&nbsp; And, anyway, we can =
hope that by the time</FONT>
<BR><FONT SIZE=3D2>&gt; we're pushing multiple billions of IPv6 nodes, =
the benefits of</FONT>
<BR><FONT SIZE=3D2>&gt; routing directly to the care-of address are =
obvious enough, and</FONT>
<BR><FONT SIZE=3D2>&gt; the code well enough understood.&nbsp; Then =
naturally, most nodes</FONT>
<BR><FONT SIZE=3D2>&gt; will process Binding Updates.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;perhaps I should just have settled for grinding =
my teeth....&gt;</FONT>
</P>

<P><FONT SIZE=3D2>About Glenn's awful suggestion..</FONT>
</P>

<P><FONT SIZE=3D2>Issues about BU security are very unclear at the =
moment.&nbsp; It may be that a</FONT>
<BR><FONT SIZE=3D2>_good_ solution will not be developed for some time =
yet, and we'll have to</FONT>
<BR><FONT SIZE=3D2>settle for a mostly working solution.</FONT>
</P>

<P><FONT SIZE=3D2>[ I'm discussing MN to CN problem here, where CN is =
stationary ]</FONT>
</P>

<P><FONT SIZE=3D2>And still you're suggesting that under every =
circumstance, you should</FONT>
<BR><FONT SIZE=3D2>always rely on (badly, if at all authenticated) =
binding updates?&nbsp; And no</FONT>
<BR><FONT SIZE=3D2>other operation (that is, _reliable_, _always =
works_, tunneling from HA to</FONT>
<BR><FONT SIZE=3D2>MN) would be allowed?</FONT>
</P>

<P><FONT SIZE=3D2>Sigh.</FONT>
</P>

<P><FONT SIZE=3D2>There's a lot of life outside mobile-ip.&nbsp; A lot =
of IPv6 implementations</FONT>
<BR><FONT SIZE=3D2>will very probably never process Binding Updates, =
Home Address options and</FONT>
<BR><FONT SIZE=3D2>what not unless they are verifiably secure.&nbsp; No =
amount of MUST would</FONT>
<BR><FONT SIZE=3D2>change this, (hopefully) only make the draft harder =
to pass in the IESG if</FONT>
<BR><FONT SIZE=3D2>they're acting responsibly.</FONT>
</P>

<P><FONT SIZE=3D2>Please do not try to enforce (unsound) MUST rules on =
non-mipv6</FONT>
<BR><FONT SIZE=3D2>implementations.&nbsp; What's done with MIPv6 with =
no requirements for</FONT>
<BR><FONT SIZE=3D2>non-mobile nodes might be viewed as a =
&quot;mobile-ip wg problem&quot;, but the</FONT>
<BR><FONT SIZE=3D2>pollution of all the IPv6 is a more general worry =
:-).</FONT>
</P>

<P><FONT SIZE=3D2>.. I most definitely hope I misunderstood something =
in the idea ..</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Pekka =
Savola&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Tell me of difficulties =
surmounted,</FONT>
<BR><FONT SIZE=3D2>Netcore =
Oy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not those you stumble over and =
fall&quot;</FONT>
<BR><FONT SIZE=3D2>Systems. Networks. Security.&nbsp; -- Robert Jordan: =
A Crown of Swords</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C151C0.784BF8A0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:23:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19068
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:23:10 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23106;
	Wed, 10 Oct 2001 12:22:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01585;
	Wed, 10 Oct 2001 12:22:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJLFML003205
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:21:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJLFU6003204
	for mobile-ip-dist; Wed, 10 Oct 2001 12:21:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJLBML003197
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:21:11 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28578
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:21:13 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09415
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:21:12 -0700 (PDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA27794;
	Wed, 10 Oct 2001 14:21:05 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9AJL5P20398;
	Wed, 10 Oct 2001 14:21:05 -0500 (CDT)
Message-ID: <3BC49048.68C64687@alcatel.com>
Date: Wed, 10 Oct 2001 14:15:36 -0400
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "Charles E. Perkins" <charliep@iprg.nokia.com>
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E554B16@zrc2c012.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------7808E0070265D37F99390EDB"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------7808E0070265D37F99390EDB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Charlie, Glenn,


Glenn Morrow wrote:

>
>
> Worries below:
>
> > Besides route optimized MIPv6 will never be ubiquitous anyway as
> long as the
> > binding update processing by CN's is only a SHOULD. The MN and HA
> will always
> > have to be complicated by back-off procedures to forward stream
> tunnel
> > mechanisms.
>

This must a political way of moving drafts fast. I thought that IPv6 had
a requirement on all IPv6 nodes to support CN functionality of MIPv6,
and I could not locate the document that stated this!
Remember that MIPv4 allows having configurations with no FA.
All to satisfy in short term the 3GPP guys
which is trying to handle mobility in VoIP using SIP mobility!
  What we need is that people like Charlie from Nokia and Hesham from
Ericsson going to 3GPP meetings, I think.

> I think it's too late by more than a year to change this from
> a SHOULD to a MUST.  And, anyway, we can hope that by the time
> we're pushing multiple billions of IPv6 nodes, the benefits of
> routing directly to the care-of address are obvious enough, and
> the code well enough understood.  Then naturally, most nodes
> will process Binding Updates.
>

Regards,

--
Behcet

--------------7808E0070265D37F99390EDB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Charlie, Glenn,
<br>&nbsp;
<p>Glenn Morrow wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>Worries below:</font>
<p><font size=-1>> Besides route optimized MIPv6 will never be ubiquitous
anyway as long as the</font>
<br><font size=-1>> binding update processing by CN's is only a SHOULD.
The MN and HA will always</font>
<br><font size=-1>> have to be complicated by back-off procedures to forward
stream tunnel</font>
<br><font size=-1>> mechanisms.</font>
<br><font size=-1></font>&nbsp;</blockquote>
This must a political way of moving drafts fast. I thought that IPv6 had
a requirement on all IPv6 nodes to support CN functionality of MIPv6, and
I could not locate the document that stated this!
<br>Remember that MIPv4 allows having configurations with no FA.
<br>All to satisfy in short term the 3GPP guys
<br>which is trying to handle mobility in VoIP using SIP mobility!
<br>&nbsp; What we need is that people like Charlie from Nokia and Hesham
from Ericsson going to 3GPP meetings, I think.
<blockquote TYPE=CITE><font size=-1>I think it's too late by more than
a year to change this from</font>
<br><font size=-1>a SHOULD to a MUST.&nbsp; And, anyway, we can hope that
by the time</font>
<br><font size=-1>we're pushing multiple billions of IPv6 nodes, the benefits
of</font>
<br><font size=-1>routing directly to the care-of address are obvious enough,
and</font>
<br><font size=-1>the code well enough understood.&nbsp; Then naturally,
most nodes</font>
<br><font size=-1>will process Binding Updates.</font>
<br><font size=-1></font>&nbsp;</blockquote>

<p><br>Regards,
<p>--
<br>Behcet</html>

--------------7808E0070265D37F99390EDB--



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:42:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19440
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:42:40 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14511;
	Wed, 10 Oct 2001 13:41:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05668;
	Wed, 10 Oct 2001 12:41:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJdOML003409
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:39:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJdNla003408
	for mobile-ip-dist; Wed, 10 Oct 2001 12:39:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJdKML003401
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:39:20 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02981
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:39:22 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10273
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:39:21 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9AJccU17184;
	Wed, 10 Oct 2001 22:38:38 +0300
Date: Wed, 10 Oct 2001 22:38:37 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Glenn Morrow <gmorrow@nortelnetworks.com>
cc: mobile-ip <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] RE: Requirements for non-MIPv6 implementations [MIPv6 - Focus of
 the          security discussion]
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E554BC7@zrc2c012.us.nortel.com>
Message-ID: <Pine.LNX.4.33.0110102223560.17103-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 10 Oct 2001, Glenn Morrow wrote:
> Actually Pekka, you seem to have confirmed my worries. Do you agree with the
> statement:
>
> "MIPv6 will not provide ubiquitous route-optimized mobility for IPv6."?

I agree.

The above statement _might_ be o.k. if the security of MIPv6 could be
implemented scalably and in such a way that it would not be felt
threatening to implement (or enable) the certain MIPv6 parts for
non-mobile IPv6 nodes.

Currently it most certainly seems like either:
 - asking for trouble (unauthenticated BU's, ...)
 - working for an intranet/closed environment only (IPSec requirement ok)

Mobile IPv6 complicates certain portions of non-mobile IPv6
implementation, making those options harder to control.  Most notably
routing headers and home address option (binding updates go without
saying).  I have a ~10 page draft in its final stages where I try to give
some examples of these problems.

Sorry for getting a little heated. :-)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords





From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 15:43:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19459
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 15:43:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15842;
	Wed, 10 Oct 2001 13:42:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05952;
	Wed, 10 Oct 2001 12:42:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJfSML003428
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:41:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9AJfS4L003427
	for mobile-ip-dist; Wed, 10 Oct 2001 12:41:28 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9AJfOML003420
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:41:24 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05648
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:41:24 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11497
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 12:41:26 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9AJfSg01570;
	Wed, 10 Oct 2001 12:41:28 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABL07200;
	Wed, 10 Oct 2001 12:40:32 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA05840; Wed, 10 Oct 2001 12:40:29 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15300.42029.755888.763501@thomasm-u1.cisco.com>
Date: Wed, 10 Oct 2001 12:40:29 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC49D80.76E54E23@iprg.nokia.com>
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
	<15300.33271.335089.998138@thomasm-u1.cisco.com>
	<3BC48D3B.DDB2F432@iprg.nokia.com>
	<15300.37472.221083.604277@thomasm-u1.cisco.com>
	<3BC49D80.76E54E23@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Rajeev Koodli writes:
 > Michael Thomas wrote:
 > >    If you have to allocate for the worst case,
 > >    why run header compression at all for those
 > >    L2's?
 > >
 > 
 > worst-case allocation does not imply CBR-only. A VBR channel (with CIR, PIR,
 > MBS) would work.

   If they are available. I'm under the impression
   that cellular doesn't have those available, nor
   am I all that hopeful that a VBR-like service is
   going to have enough of the desirable characteristics
   (upstream latency in particular) that a voip service
   would like.

   I've been through this many, many times with cable.
   If you have references to a shared media VBR scheme
   which has the proper latency characteristics which
   isn't at the expense of bandwidth, I'd be very 
   interested to read about it.

	      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 21:32:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24191
	for <mobileip-archive@lists.ietf.org>; Wed, 10 Oct 2001 21:32:21 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03987;
	Wed, 10 Oct 2001 18:30:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23672;
	Wed, 10 Oct 2001 18:30:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1TaML003963
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:29:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B1TZFd003962
	for mobile-ip-dist; Wed, 10 Oct 2001 18:29:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1TWML003955
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:29:32 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20422
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:29:34 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26792
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:29:33 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA26333
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:28:20 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA23875
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:29:26 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLLHK>; Thu, 11 Oct 2001 11:29:25 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED36@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 11 Oct 2001 11:29:21 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151F4.2779AC40"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151F4.2779AC40
Content-Type: text/plain;
	charset="iso-8859-1"


	Hi Glenn, 
>  
> Not that this is the particular place for this discussion but it seems
> that limitations of specific access technologies have again emerged into
> the requirements of this IETF WG. 
> 
	=> Probably not the right place but we can try till the chairs tell
us to stop :)
>  
> Have you explored sending the piggybacked packets over something like -
> say, the MAC representation of the signaling PDP context? 
> 
	=> I don't get that, could you elaborate a bit ? 

> It seems that this multiplexing could be accomplished quite easily via
> some ROHC middle box?
>  
> I, for one, don't see much of a problem with some miniscule delay on one
> single packet during a handoff of a mobile to mobile or mobile to cable
> voice call - even if something like the signaling PDP context is not used.
>  
> Dropping the packet is probably worse than some miniscule segmentation
> delay on one packet. 
> 
	=> I'm not sure that it's a miniscule delay at all. The delay will
probably be doubled.
	If one packet fits nicely in the radio frame, and the extra bytes
	take it beyond that frame, then it is likely that the delay will at
least be doubled
	(I'm clearly considering the delays over the air whichh are the
major portion of 
	the RTT delay in a cellular network). 
	Now for a real time application, this delay is just as good as
dropping the 
	packet. Have I missed something ?
>  
> I could see creating some new form of generic authentication/encryption
> header that could be used for integrity and confidentiality of any set of
> IP options and used in conjunction with existing IPSEC headers for the
> applications; but based upon the timeliness of such work and cross WG
> controversy involved in this, it seems that the logical and expedient
> solution specified in the existing draft makes the best sense at this
> particular point in time. I don't mind if someone suggests such as thing
> but I don't think it should hamper the existing MIPv6 proposal which does
> solve the problem.
> 
	=> This is an orthogonal issue to piggybacking IMHO. The current 
	soution in the draft doesn't solve the problems we're discussing. 
	Obviously this new susboption will not be compressed by 
	ROHC, s the extra bytes are still there. 
>  
> As far a creating a new header specifically for BU, I don't see how that
> would solve much of anything. Again, I don't mind if someone suggests such
> as thing but I don't think it should hamper the acceptance of the existing
> MIPv6 proposal.
> 
	=>  Again this is another (a third issues). This was suggested for 
	allowing IPsec to protect the BUs. Have a look at Jari's draft. 

	Hesham

> 	-----Original Message-----
> 	From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
> 	Sent: Wednesday, October 10, 2001 12:56 AM
> 	To: 'mobile-ip@sunroof.eng.sun.com'
> 	Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
> 	
> 	
> 
> 
> 		Hello Charlie, 
> 
> 		>      the minor changes involve throwing out piggybacking
> (which 
> 	>      in my opinion is a nice feature). 
> 	> 
> 	>      => This was discussed in detail, it's nice but not practical.
> 
> 	>      BW-constrained links (like cellular links) allocate set 
> 	>      channels based on the service, piggybacking the 
> 	>      BU _will_not_fit_ in the channel and the packet will 
> 	>      dropped ! That's not nice is it. 
> 	>      Non-BW-constrained links could not care less if 
> 	>      we piggyback or not. 
> 	> 
> 
> 		First, it was discussed in detail.  It's nice.  For some
> applications 
> 	on some links, it's not practical.  For other applications on other 
> 	links, it is practical.  It's been implemented, tested, and it
> works. 
> 
> 		=> I realise it was implemented and tested. My issue here 
> 	is that how does a MN know whether the CN receiving 
> 	the piggybacked BU will be negatively impacted by piggybacking ? 
> 
> 		Jari has mentioned this in a previous email but I'll quickly
> mention 
> 	it again. A MN on a WLAN could be sending a BU to a CN 
> 	connected to a cellular link which was assigned a fixed channel 
> 	size. Because the BU was piggybacked, the entire packet 
> 	is dropped as it doesn't fit in the allocated channel. 
> 	Is there any solution to avoid this scenario ? 
> 	This is only one of the issues that were mentioned 
> 	against piggybacking. 
> 
> 		Hesham 
> 

------_=_NextPart_001_01C151F4.2779AC40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi Glenn, </FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Not that this is =
the particular place for this discussion but it seems that limitations =
of specific access technologies have again emerged into the =
requirements of this IETF WG. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Probably not =
the right place but we can try till the chairs tell us to stop =
:)</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Have you explored =
sending the piggybacked packets over something like - say, the MAC =
representation of the signaling PDP context?</FONT> </P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; I don't get =
that, could you elaborate a bit ?</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It seems that this =
multiplexing could be accomplished quite easily via some ROHC middle =
box?</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I, for one, don't =
see much of a problem with some miniscule delay on one single packet =
during a handoff of a mobile to mobile or mobile to cable voice call - =
even if something like the signaling PDP context is not =
used.</FONT></P>

<P><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dropping the packet =
is probably worse than some miniscule segmentation delay on one =
packet.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; I'm not sure =
that it's a miniscule delay at all. The delay will probably be =
doubled.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If one packet fits =
nicely in the radio frame, and the extra bytes</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">take it beyond that =
frame, then it is likely that the delay will at least be doubled</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(I'm clearly =
considering the delays over the air whichh are the major portion of =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the RTT delay in a =
cellular network). </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Now for a real time =
application, this delay is just as good as dropping the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">packet. Have I =
missed something ?</FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I could see =
creating some new form of generic authentication/encryption header that =
could be used for integrity and confidentiality of any set of IP =
options and used in conjunction with existing IPSEC headers for the =
applications; but based upon the timeliness of such work and cross WG =
controversy involved in this, it seems that the logical and expedient =
solution specified in the existing draft makes the best sense at this =
particular point in time. I don't mind if someone suggests such as =
thing but I don't think it should hamper the existing MIPv6 proposal =
which does solve the problem.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; This is an =
orthogonal issue to piggybacking IMHO. The current </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">soution in the =
draft doesn't solve the problems we're discussing. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Obviously this new =
susboption will not be compressed by </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">ROHC, s the extra =
bytes are still there. </FONT>
<BR><FONT FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As far a creating a =
new header specifically for BU, I don't see how that would solve much =
of anything. Again, I don't mind if someone suggests such as thing but =
I don't think it should hamper the acceptance of the existing MIPv6 =
proposal.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">=3D&gt;</FONT>&nbsp;<FONT FACE=3D"Arial"> </FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Again this is another (a =
third issues). This was suggested for </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">allowing IPsec to =
protect the BUs. Have a look at Jari's draft.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">-----Original Message-----<BR>
<B>From:</B> Hesham Soliman (EPA) [</FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Tahoma"><A =
HREF=3D"mailto:Hesham.Soliman@ericsson.com.au">mailto:Hesham.Soliman@eri=
csson.com.au</A></FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Wednesday, October 10, 2001 12:56 AM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> 'mobile-ip@sunroof.eng.sun.com'<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> RE: [mobile-ip] MIPv6 - Focus of the security =
discussion<BR>
<BR>
</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Hello Charlie,</FONT>=20
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the minor changes =
involve throwing out piggybacking (which</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
in my opinion is a nice feature).</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; This was discussed in detail, it's nice but not =
practical.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
BW-constrained links (like cellular links) allocate set</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
channels based on the service, piggybacking the</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
BU _will_not_fit_ in the channel and the packet will</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
dropped ! That's not nice is it.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Non-BW-constrained links could not care less if</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
we piggyback or not.</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">First, it was discussed in detail.&nbsp; It's =
nice.&nbsp; For some applications</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">on some links, it's not =
practical.&nbsp; For other applications on other</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">links, it is practical.&nbsp; It's =
been implemented, tested, and it works.</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">=3D&gt; I realise it was implemented and =
tested. My issue here</FONT><BR>
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is that how does a MN =
know whether the CN receiving</FONT><BR>
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the piggybacked BU will =
be negatively impacted by piggybacking ?</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Jari has mentioned this in a previous email but =
I'll quickly mention</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">it again. A MN =
on a WLAN could be sending a BU to a CN</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">connected to a =
cellular link which was assigned a fixed channel</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">size. Because =
the BU was piggybacked, the entire packet</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is dropped as it =
doesn't fit in the allocated channel.</FONT><BR>
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Is there any solution =
to avoid this scenario ?</FONT><BR>
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This is only one of the =
issues that were mentioned</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">against =
piggybacking.</FONT>=20
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Hesham</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C151F4.2779AC40--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 21:35:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24523
	for <mobileip-archive@lists.ietf.org>; Wed, 10 Oct 2001 21:35:06 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04875;
	Wed, 10 Oct 2001 18:34:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24266;
	Wed, 10 Oct 2001 18:34:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1XKML004047
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:33:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B1XK4R004046
	for mobile-ip-dist; Wed, 10 Oct 2001 18:33:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1XGML004039
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:33:16 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01878
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:33:18 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03890
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:33:17 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA26751
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:32:09 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA25913
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:33:15 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLLLL>; Thu, 11 Oct 2001 11:33:14 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED37@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 11 Oct 2001 11:33:07 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151F4.ADD19C30"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151F4.ADD19C30
Content-Type: text/plain

> > 
>       and getting a new extension
> >      header. the BU as a destination option has been through a
> >      lot of interoperability events (we have been at atleast 3-
> >      2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001
> >      Conectathon). lets not change it.
> > 
> >      => No one suggested changing the BU option, it was
> >      suggested that it should be carried in a different header.
> >      That does not imply changing anything in the option.
> 
> read the sentence again. when i said lets not change it,
> i meant lets not change BU as a destination option.
> 
	=> It is stil a BU OPTION just a different header
	you can still call it a DESTINATION option, like DST-3 
	for example. 
	Got it ?

	Hesham

------_=_NextPart_001_01C151F4.ADD19C30
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and getting a new extension</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; header. the BU as a destination option has been through a</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lot of interoperability events (we have been at atleast 3-</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Conectathon). lets not change it.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; No one suggested changing the BU option, it was</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; suggested that it should be carried in a different header.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; That does not imply changing anything in the option.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">read the sentence again. when i said lets not change it,</FONT>
<BR><FONT SIZE=2 FACE="Arial">i meant lets not change BU as a destination option.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; It is stil a BU OPTION just a different header</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">you can still call it a DESTINATION option, like DST-3 </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">for example. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Got it ?</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C151F4.ADD19C30--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 21:42:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25246
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 21:42:47 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11950;
	Wed, 10 Oct 2001 19:41:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25409;
	Wed, 10 Oct 2001 18:41:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1eJML004178
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:40:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B1eJll004177
	for mobile-ip-dist; Wed, 10 Oct 2001 18:40:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1eGML004170
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:40:16 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11866
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:40:17 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17722
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:41:29 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA27464;
	Thu, 11 Oct 2001 11:39:00 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA28097;
	Thu, 11 Oct 2001 11:40:02 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLLR0>; Thu, 11 Oct 2001 11:40:01 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED38@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: pekkas@netcore.fi
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 11 Oct 2001 11:39:56 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151F5.A1E3E8F0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151F5.A1E3E8F0
Content-Type: text/plain

Hi Rajeev, 

> >  > I don't understand why this problem is specific to binding updates.
> >  > Are you saying that under such a reservation, the packet size can't
> >  > vary at all ? If I have been sending 1000 bytes, which is way less
> >  > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
> >  > a tight channel is reserved there should be indication to IP to
> >  > change its MTU value so that path mtu discovery can kick in.
> >
> >    Yup, that's the problem. It really has nothing to do
> >    with MTU; it's about keeping within the constraint of
> >    a reservation. MTU is link based, not flow based afterall.
> >
> 
> It is not entirely accurate to say that you cannot piggyback when using a
> dedicated channel. For instance, it is well-known that header compression
> gain can vary from packet to packet, thus affecting the compressor states.
> In a dedicated channel, which is what this thread is focussing on
> I assume, in order to accommodate `header bursts', you need to reserve for
> the worst-case. 
> 
	=> Sure, that would solve it, but wouldn't that add additional
	costs for a user ? For instance if I reserve for the worste case
	which will only happen rarely compared to the BW required 
	for my application, it would seem like I'm paying more than
	I need for y application. 
	I don''t really think the problems are significantly different 
	for Header compression (ie. whether you piggyback or not)
	so I'm more concerned about the BW reservation consequences.

	Regards,
	Hesham



> >
> >         Mike

------_=_NextPart_001_01C151F5.A1E3E8F0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hi Rajeev, </FONT>
</P>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt;&nbsp; &gt; I don't understand why this problem is specific to binding updates.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp; &gt; Are you saying that under such a reservation, the packet size can't</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp; &gt; vary at all ? If I have been sending 1000 bytes, which is way less</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp; &gt; than 1280, if I send 1020 bytes, will it be dropped ? Then when such</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp; &gt; a tight channel is reserved there should be indication to IP to</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp; &gt; change its MTU value so that path mtu discovery can kick in.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; Yup, that's the problem. It really has nothing to do</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; with MTU; it's about keeping within the constraint of</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; a reservation. MTU is link based, not flow based afterall.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">It is not entirely accurate to say that you cannot piggyback when using a</FONT>
<BR><FONT SIZE=2 FACE="Arial">dedicated channel. For instance, it is well-known that header compression</FONT>
<BR><FONT SIZE=2 FACE="Arial">gain can vary from packet to packet, thus affecting the compressor states.</FONT>
<BR><FONT SIZE=2 FACE="Arial">In a dedicated channel, which is what this thread is focussing on</FONT>
<BR><FONT SIZE=2 FACE="Arial">I assume, in order to accommodate `header bursts', you need to reserve for</FONT>
<BR><FONT SIZE=2 FACE="Arial">the worst-case.</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Sure, that would solve it, but wouldn't that add additional</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">costs for a user ? For instance if I reserve for the worste case</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">which will only happen rarely compared to the BW required </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">for my application, it would seem like I'm paying more than</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I need for y application. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I don''t really think the problems are significantly different </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">for Header compression (ie. whether you piggyback or not)</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">so I'm more concerned about the BW reservation consequences.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Regards,</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2 FACE="Arial">&gt;</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C151F5.A1E3E8F0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 21:44:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25275
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 21:44:14 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12634;
	Wed, 10 Oct 2001 19:43:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25713;
	Wed, 10 Oct 2001 18:43:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1fgML004201
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:41:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B1fgQJ004200
	for mobile-ip-dist; Wed, 10 Oct 2001 18:41:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1fcML004193
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:41:38 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25377
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:41:37 -0700 (PDT)
Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA18110
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:42:51 -0600 (MDT)
Received: from blammo.its.monash.edu.au ([130.194.1.74])
 by vaxh.cc.monash.edu.au (PMDF V5.2-31 #29714)
 with ESMTP id <01K9DGIN91RM8X5GOB@vaxh.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Thu, 11 Oct 2001 11:41:16 +1000
Received: from localhost (localhost [127.0.0.1])	by blammo.its.monash.edu.au
 (Postfix) with ESMTP id 1CBAB12C00E	for <mobile-ip@sunroof.eng.sun.com>; Thu,
 11 Oct 2001 11:41:16 +1000 (EST)
Received: from eng.monash.edu.au
 (PC00004790.eng.monash.edu.au [130.194.137.189])	by blammo.its.monash.edu.au
 (Postfix) with ESMTP id E952812C014	for <mobile-ip@sunroof.eng.sun.com>; Thu,
 11 Oct 2001 11:41:13 +1000 (EST)
Date: Thu, 11 Oct 2001 11:46:23 +1000
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] Interop test event
To: mobile-ip@sunroof.eng.sun.com
Message-id: <3BC4F9EF.E0B9509F@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-Virus-Scanned: by AMaViS perl-11
References: 
 <4B6BC00CD15FD2119E5F0008C7A419A51308ED23@eaubrnt018.epa.ericsson.se>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7BIT

	It looks like we are being given our opportunity.

		Greg 

"Hesham Soliman (EPA)" wrote:
> 
> [Sending for Sarolta ]
> 
> Dear madams/sirs,
> 
> We are pleased to inform you about the preparation of an
> interoperability event which will be organised by the Conformance Lab of
> Ericsson Research.
> 
> The topics addressed during the interoperability event are:
> 
> - Mobile IPv6 (<draft-ietf-mobileip-ipv6-13.txt>) and
> - Hierarchical Mobile IPv6 (<draft-ietf-mobileip-hmipv6-04.txt>)
> 
> The event is scheduled for 3rd-7th December in Budapest, Hungary.
> 
> The conformance test services of Conformance Lab on the above mentioned
> protocols will be available for the participants at the event.
> We will provide testing facilities and some experts will also be present
> during the event for assisting the participants.
> 
> Participation on the event is free of charge.
> 
> Update information will be maintained on Ericsson Hungary's website
> <http://www.ericsson.co.hu/conform>. Detailed information and registration
> to the event will be available soon.
> 
> Suggestions are welcome.
> 
> Looking forward to recording your participation and meeting you at the
> event.
> 
> Best regards
> 
> Sarolta Dibuz
> 
> --
> Sarolta Dibuz  Ph.D.                Sarolta.Dibuz@eth.ericsson.se
> Conformance Center (ETH/RLSC)       Mobile: +36-30-202-6180
> Ericsson Hungary Ltd.               Tel: +36-1-437 7784
> P.O.B. 107, 1300 Budapest, Hungary  Fax: +36-1-437 7219


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 21:48:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25319
	for <mobileip-archive@lists.ietf.org>; Wed, 10 Oct 2001 21:48:19 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08249;
	Wed, 10 Oct 2001 18:47:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26608;
	Wed, 10 Oct 2001 18:47:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1jtML004400
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:45:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B1jtNJ004399
	for mobile-ip-dist; Wed, 10 Oct 2001 18:45:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1jpML004392
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:45:51 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12565
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:45:53 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01823
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:45:52 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA28087;
	Thu, 11 Oct 2001 11:44:39 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA29625;
	Thu, 11 Oct 2001 11:45:45 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLLXY>; Thu, 11 Oct 2001 11:45:44 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED39@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: jari.arkko@ericsson.fi
Subject: RE: [mobile-ip] protecting BUs
Date: Thu, 11 Oct 2001 11:45:39 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151F6.6E283CE0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151F6.6E283CE0
Content-Type: text/plain


Hello Jari, 

> > No! No! A *router* on the path should only examine the IP header *and*
> > check if the immediate next-header is hop-by-hop header (in which case
> > it may need to look into this).
> > 
> > *Routers* do not care whether next header field is unknown to them.
> > 
> > The rule about dropping a packet with unknown extension header
> > conserns only the end-node.
> 
> This is the obviously the more interoperable way to interpret this.
> If all did so, there would be no problem with forwarding boxes,
> as long as no-one suggests a new value before routing header, source
> routing nodes would otherwise suffer. It is advisable trying to
> read RFCs and new proposals "the other way around" pondering what are
> the worst case interoperation implications their interpretations allow.
> 
	=> That's fair, but where do you get that impression when 
	reading RFC 2460 ? I'd like to get some idea because if 
	that is the case we should really address it on the IPng
	list. If your interpretation of the RFC is shared by other 
	implementors we should really address this. 

	Hesham

------_=_NextPart_001_01C151F6.6E283CE0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] protecting BUs</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hello Jari, </FONT>
</P>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt; No! No! A *router* on the path should only examine the IP header *and*</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; check if the immediate next-header is hop-by-hop header (in which case</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; it may need to look into this).</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; *Routers* do not care whether next header field is unknown to them.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; The rule about dropping a packet with unknown extension header</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; conserns only the end-node.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">This is the obviously the more interoperable way to interpret this.</FONT>
<BR><FONT SIZE=2 FACE="Arial">If all did so, there would be no problem with forwarding boxes,</FONT>
<BR><FONT SIZE=2 FACE="Arial">as long as no-one suggests a new value before routing header, source</FONT>
<BR><FONT SIZE=2 FACE="Arial">routing nodes would otherwise suffer. It is advisable trying to</FONT>
<BR><FONT SIZE=2 FACE="Arial">read RFCs and new proposals &quot;the other way around&quot; pondering what are</FONT>
<BR><FONT SIZE=2 FACE="Arial">the worst case interoperation implications their interpretations allow.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; That's fair, but where do you get that impression when </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">reading RFC 2460 ? I'd like to get some idea because if </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">that is the case we should really address it on the IPng</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">list. If your interpretation of the RFC is shared by other </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">implementors we should really address this. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C151F6.6E283CE0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 21:50:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25378
	for <mobileip-archive@lists.ietf.org>; Wed, 10 Oct 2001 21:50:51 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08954;
	Wed, 10 Oct 2001 18:50:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27030;
	Wed, 10 Oct 2001 18:50:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1nHML004487
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:49:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B1nHkY004486
	for mobile-ip-dist; Wed, 10 Oct 2001 18:49:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1nDML004479
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:49:13 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23142
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:49:15 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15543
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:49:04 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA14261
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:49:14 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9B1nDv18703
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:49:13 -0700
X-mProtect:  Wed, 10 Oct 2001 18:49:13 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdA9gDIY; Wed, 10 Oct 2001 18:49:11 PDT
Message-ID: <3BC4FA98.444C2EB7@iprg.nokia.com>
Date: Wed, 10 Oct 2001 18:49:12 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED37@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> "Hesham Soliman (EPA)" wrote:
> 
> 
>      read the sentence again. when i said lets not change it,
>      i meant lets not change BU as a destination option.
> 
>      => It is stil a BU OPTION just a different header
>      you can still call it a DESTINATION option, like DST-3
>      for example.
>      Got it ?

Huh? i meant protocol 60.

vijay

> 
>      Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 21:57:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25519
	for <mobileip-archive@lists.ietf.org>; Wed, 10 Oct 2001 21:57:16 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10223;
	Wed, 10 Oct 2001 18:56:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04862;
	Wed, 10 Oct 2001 18:56:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1t5ML004633
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:55:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B1t5kX004632
	for mobile-ip-dist; Wed, 10 Oct 2001 18:55:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B1t1ML004625
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:55:01 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23691
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:55:03 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11563
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 18:55:02 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA29134
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:53:54 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA02161
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:55:00 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLMAX>; Thu, 11 Oct 2001 11:54:59 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED3B@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 11 Oct 2001 11:54:50 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151F7.B6D48EC0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151F7.B6D48EC0
Content-Type: text/plain



> > 
> >      read the sentence again. when i said lets not change it,
> >      i meant lets not change BU as a destination option.
> > 
> >      => It is stil a BU OPTION just a different header
> >      you can still call it a DESTINATION option, like DST-3
> >      for example.
> >      Got it ?
> 
> Huh? i meant protocol 60.
> 
	=> Protocol 60 ? Have a look at Jari's
	draft. I think this will be a good base for the 
	discussion. 

	Hesham



------_=_NextPart_001_01C151F7.B6D48EC0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; read the sentence again. when i said lets not change it,</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i meant lets not change BU as a destination option.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; It is stil a BU OPTION just a different header</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; you can still call it a DESTINATION option, like DST-3</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for example.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Got it ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Huh? i meant protocol 60.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Protocol 60 ? Have a look at Jari's</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">draft. I think this will be a good base for the </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">discussion. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C151F7.B6D48EC0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 22:03:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25630
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 22:03:56 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21757;
	Wed, 10 Oct 2001 20:03:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05631;
	Wed, 10 Oct 2001 19:03:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B22JML004744
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:02:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B22IcB004743
	for mobile-ip-dist; Wed, 10 Oct 2001 19:02:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B22FML004736
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:02:15 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14280
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:02:17 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07047
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:02:17 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA14782
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:02:16 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9B22F802448
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:02:15 -0700
X-mProtect:  Wed, 10 Oct 2001 19:02:15 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdbhN25u; Wed, 10 Oct 2001 19:02:14 PDT
Message-ID: <3BC4FDA7.AB3B79A5@iprg.nokia.com>
Date: Wed, 10 Oct 2001 19:02:15 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED3B@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> "Hesham Soliman (EPA)" wrote:
> 
>      >
>      >      read the sentence again. when i said lets not change it,
>      >      i meant lets not change BU as a destination option.
>      >
>      >      => It is stil a BU OPTION just a different header
>      >      you can still call it a DESTINATION option, like DST-3
>      >      for example.
>      >      Got it ?
> 
>      Huh? i meant protocol 60.
> 
>      => Protocol 60 ? Have a look at Jari's
>      draft. I think this will be a good base for the
>      discussion.

do you always twist others' statements and arrive at a point
where others have no clue what you are talking about? all i 
said was BU as an option in the extension header protocol 60 
has been through a lot of interoperability tests. lets not 
change it. lets not move it to a new extension header.

I have read Jari's draft. and I like it. and I prefer his 
application specific protection (solution 4).

Vijay


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 10 22:10:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25674
	for <mobileip-archive@odin.ietf.org>; Wed, 10 Oct 2001 22:10:41 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24455;
	Wed, 10 Oct 2001 20:09:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06549;
	Wed, 10 Oct 2001 19:09:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B28sML004861
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:08:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B28sFx004860
	for mobile-ip-dist; Wed, 10 Oct 2001 19:08:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B28oML004853
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:08:51 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15437
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 19:08:52 -0700 (PDT)
Received: from newish7.ericsson.com.au ([203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24026
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 20:08:40 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA00608
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:07:43 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA05613
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:08:50 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLM3K>; Thu, 11 Oct 2001 12:08:49 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED3D@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Multi-homing MIPv6???
Date: Thu, 11 Oct 2001 12:08:39 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151F9.A4F8A630"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C151F9.A4F8A630
Content-Type: text/plain

> I have a non-security related question! 
> 
	=> How dare you com on this list :) 

> I don't recall seeing any
> discussion of mult-homing and its relation to MIPv6 HO.  Perhaps
> I missed something.  
> 
	=> Well there is a couple  of issues here: 
	1. How well does ND handle multihoming
	2. How can MIPv6 implementations handle 
	    multihomed hosts for outbound traffic
	3. How can MIPv6 handle inbound traffic 
	    for multihomed hosts

	We had problems with the KAME implementation 
	last year but Mattias can explain that much better 
	than I can. 
	 
	For the second point, there are some implementations
	out there that allow attaching the Home address to 
	a "virtual" interface, hence giving hosts the flexibility
	of splitting their flows on different interfaces. 

	We tried to address the third point in
	
http://standards.ericsson.net/hesham/draft-soliman-mobileip-flow-move-00.txt

	People have commented on it but we haven't added the 
	comments yet. 

> Also, I don't recall seeing much discussion
> of SCTP and MIPv6. 
> 
	=> What kinds of issues do you see ?

	Other useful (related) drafts:

	
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-06
.txt
	
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-selection-00.tx
t

	Also Homeless MIPv6 made a nice attempt but I can't find 
	the link to the draft. Perhaps you could do a serach for 
	it. 

	Cheers,
	Hesham


------_=_NextPart_001_01C151F9.A4F8A630
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Multi-homing MIPv6???</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I have a non-security related =
question!</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; How dare you =
com on this list :) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't recall seeing any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">discussion of mult-homing and its =
relation to MIPv6 HO.&nbsp; Perhaps</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I missed something.&nbsp;</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Well there =
is a couple&nbsp; of issues here: </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">1. How well does ND =
handle multihoming</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">2. How can MIPv6 =
implementations handle </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
multihomed hosts for outbound traffic</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">3. How can MIPv6 =
handle inbound traffic </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
for multihomed hosts</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">We had problems with =
the KAME implementation </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">last year but =
Mattias can explain that much better </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">than I can. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">For the second =
point, there are some implementations</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">out there that =
allow attaching the Home address to </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">a =
&quot;virtual&quot; interface, hence giving hosts the =
flexibility</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">of splitting their =
flows on different interfaces. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">We tried to address =
the third point in</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://standards.ericsson.net/hesham/draft-soliman-mobileip-flow=
-move-00.txt" =
TARGET=3D"_blank">http://standards.ericsson.net/hesham/draft-soliman-mob=
ileip-flow-move-00.txt</A></FONT></U>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">People have =
commented on it but we haven't added the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">comments yet. =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Also, I don't recall seeing much =
discussion</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of SCTP and MIPv6.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; What kinds =
of issues do you see ?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Other useful =
(related) drafts:</FONT>
</P>

<P><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-ad=
dr-select-06.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-=
default-addr-select-06.txt</A></FONT></U>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-sel=
ection-00.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-=
router-selection-00.txt</A></FONT></U>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Also Homeless MIPv6 =
made a nice attempt but I can't find </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the link to the =
draft. Perhaps you could do a serach for </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">it. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C151F9.A4F8A630--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 00:09:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27676
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 00:09:38 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11219;
	Wed, 10 Oct 2001 22:08:55 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18396;
	Wed, 10 Oct 2001 21:08:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B482ML005076
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 10 Oct 2001 21:08:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B4825N005075
	for mobile-ip-dist; Wed, 10 Oct 2001 21:08:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B47wML005068
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 21:07:58 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11186
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 21:07:59 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA23154
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 21:08:00 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA19335
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 21:08:00 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9B47x032296
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 21:07:59 -0700
X-mProtect:  Wed, 10 Oct 2001 21:07:59 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdbn0X7t; Wed, 10 Oct 2001 21:07:58 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id VAA08449 for <mobile-ip@sunroof.eng.sun.com>; Wed, 10 Oct 2001 21:07:58 -0700 (PDT)
Message-ID: <3BC51B1E.7B53FE40@iprg.nokia.com>
Date: Wed, 10 Oct 2001 21:07:58 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED39@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham,

>      > No! No! A *router* on the path should only examine the IP header *and*
>      > check if the immediate next-header is hop-by-hop header (in which case
>      > it may need to look into this).
>      >
>      > *Routers* do not care whether next header field is unknown to them.
>      >
>      > The rule about dropping a packet with unknown extension header
>      > conserns only the end-node.
> 
>      This is the obviously the more interoperable way to interpret this.
>      If all did so, there would be no problem with forwarding boxes,
>      as long as no-one suggests a new value before routing header, source
>      routing nodes would otherwise suffer. It is advisable trying to
>      read RFCs and new proposals "the other way around" pondering what are
>      the worst case interoperation implications their interpretations allow.
> 
>      => That's fair, but where do you get that impression when
>      reading RFC 2460 ? I'd like to get some idea because if
>      that is the case we should really address it on the IPng
>      list. If your interpretation of the RFC is shared by other
>      implementors we should really address this.

If one reads the last paragraph of page 6 one can read it two ways:

Either: "With one exception, extension headers are not examined or processed
by any node along a packet's delivery path.." meaning hop-by-hop options
header. Then, "If, as a result of processing a header, a node is required
to proceed to the next header, but the Next Header value in the current
header is unrecognized..", could mean: possible existence of hop-by-hop options header "must be examined" resulting in that after IPv6 header
the "required to proceed" condition is met, but the Next Header is unknown,
this would result in the discarding rule. There is, luckily, even in this
case, the possibility to ignore this.

Or: That there is not h-b-h next header invalidates the "must be examined"
rule and one could skip an unknown number (just forwarding the packet
irrespective what garbage there is at its end). I hope this could be
the correct interpretation since the h-b-h must immediately follow the
IPv6 header. Unless someone challenges this order rule with a new header,
or someone comes with a new h-b-h option requiring proceeding to something
else, this could hopefully be the "right interpretation".

If someone observes the former, it would risk that there are boxes that
drop packets with new unknown next headers. In the latter there would not
be. Our boxes do the right thing, but can it be guaranteed so do others?
This could have been clearer in the text saying that routers must ignore
next headers other than h-b-h. But, this would not be the first RFC in
routing where "well-known" implementation guidelines help interpret the
actual text.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 03:29:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13247
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 03:29:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18007;
	Thu, 11 Oct 2001 00:26:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29666;
	Thu, 11 Oct 2001 00:26:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B7PmML005317
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 00:25:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B7Pl3T005316
	for mobile-ip-dist; Thu, 11 Oct 2001 00:25:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B7PiML005309
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 00:25:44 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17324
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 00:25:47 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13694
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 00:25:46 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9B7Pj721123
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:25:45 +0300
Date: Thu, 11 Oct 2001 10:25:45 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] protecting BUs
In-Reply-To: <3BC51B1E.7B53FE40@iprg.nokia.com>
Message-ID: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 10 Oct 2001, Jari T. Malinen wrote:
> Either: "With one exception, extension headers are not examined or processed
> by any node along a packet's delivery path.." meaning hop-by-hop options
> header. Then, "If, as a result of processing a header, a node is required
> to proceed to the next header, but the Next Header value in the current
> header is unrecognized..", could mean: possible existence of hop-by-hop options header "must be examined" resulting in that after IPv6 header
> the "required to proceed" condition is met, but the Next Header is unknown,
> this would result in the discarding rule. There is, luckily, even in this
> case, the possibility to ignore this.
>
> Or: That there is not h-b-h next header invalidates the "must be examined"
> rule and one could skip an unknown number (just forwarding the packet
> irrespective what garbage there is at its end). I hope this could be
> the correct interpretation since the h-b-h must immediately follow the
> IPv6 header. Unless someone challenges this order rule with a new header,
> or someone comes with a new h-b-h option requiring proceeding to something
> else, this could hopefully be the "right interpretation".
>
> If someone observes the former, it would risk that there are boxes that
> drop packets with new unknown next headers. In the latter there would not
> be. Our boxes do the right thing, but can it be guaranteed so do others?
> This could have been clearer in the text saying that routers must ignore
> next headers other than h-b-h. But, this would not be the first RFC in
> routing where "well-known" implementation guidelines help interpret the
> actual text.

This is, by no means, a trivial issue.

I'm not sure where the new Destination Options are recommended to be
placed in the header chain but coupled with e.g. Routing Header w/ traffic
engineering/multihoming/... it could get ugly:

dst addr=some non-MIPv6 router
src addr=some MIPv6 node
home address option=MIPv6 node HA
routing header=CoA of a MIPv6 node, segments left=1

Here, if HA/BU/Binding Ack/... etc. are placed before routing header,
'some non-MIPv6 router', when processing the routing header chain, will
notice an unknown header type, drop the packet and send back ICMP error.

Could get ugly.

Also, RFC2460 seems ignorant of IPv6 firewalls/packet filters which most
assuredly would like to process upto e.g. TCP header, therefore also
noticing an unknown header type.  The expected behaviour can be quickly
deduced though.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 04:58:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13685
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 04:58:02 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14969;
	Thu, 11 Oct 2001 01:57:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05648;
	Thu, 11 Oct 2001 01:57:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B8uBML005554
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 01:56:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B8uBCX005553
	for mobile-ip-dist; Thu, 11 Oct 2001 01:56:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B8u6ML005546
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 01:56:07 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9B8u5q00145;
	Thu, 11 Oct 2001 10:56:05 +0200 (MET DST)
Date: Thu, 11 Oct 2001 10:51:01 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] protecting BUs
To: jmalinen@iprg.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@ericsson.fi
In-Reply-To: "Your message with ID" <3BC46992.DA860F7F@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.1002790261.25110.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> - Addition of a New Next Header Value: Are you sure it can be done
>   without any out-of-mobileip standardization work? Shouldn't there
>   be analysis on the change implications of this (like you have well
>   done for, e.g., IPsec modifications)? Quoting RFC2460 [Page 6]:
> 
>   > If, as a result of processing a header, a node is required to proceed
>   > to the next header but the Next Header value in the current header is
>   > unrecognized by the node, it should discard the packet and send an
>   > ICMP Parameter Problem message to the source of the packet, with an
>   > ICMP Code value of 1 ("unrecognized Next Header type encountered")
> 
>   If any node (host or router) encounters IPv6 header, it should at least
>   consider whether there is a next header with a hop-by-hop option. If
>   immediately in the IPv6 header the next header field has a unknown value,
>   the node cannot avoid reading this value if it checks for the h-b-h,
>   shouldn't it then discard the packet according to the above?

You are talking about a router, right?

If the packet isn't explicitly addresses to the router then the router
should just check whether the nextheader = hbh. It must not care about
other nexthdr values.

If folks think routers should reject packets in the forwarding path
with an unknown nexthdr, how could we possibly deploy a new transport
protocol like SCTP? It has a new nexthdr value. 

So please tell me that I'm reading your note incorrectly.

  Erik
  



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 05:06:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13802
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 05:06:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18098;
	Thu, 11 Oct 2001 02:05:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06549;
	Thu, 11 Oct 2001 02:05:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B94dML005671
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 02:04:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B94dZV005670
	for mobile-ip-dist; Thu, 11 Oct 2001 02:04:39 -0700 (PDT)
Date: Thu, 11 Oct 2001 02:04:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B94ZML005663;
	Thu, 11 Oct 2001 02:04:35 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06398;
	Thu, 11 Oct 2001 02:04:37 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01455;
	Thu, 11 Oct 2001 03:04:25 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA06983;
	Thu, 11 Oct 2001 19:03:28 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA00829;
	Thu, 11 Oct 2001 19:04:34 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLXBV>; Thu, 11 Oct 2001 19:04:33 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        ipng@sunroof.eng.sun.com
Subject: [mobile-ip] Date: Thu, 11 Oct 2001 19:04:26 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
	Jari, 

	[I'm ccing IPng for the interpretation of RFC 2460 ]

> If one reads the last paragraph of page 6 one can read it two ways:
> 
> Either: "With one exception, extension headers are not examined or
> processed
> by any node along a packet's delivery path.." meaning hop-by-hop options
> header. Then, "If, as a result of processing a header, a node is required
> to proceed to the next header, but the Next Header value in the current
> header is unrecognized..", could mean: possible existence of hop-by-hop
> options header "must be examined" resulting in that after IPv6 header
> the "required to proceed" condition is met, but the Next Header is
> unknown,
> this would result in the discarding rule. There is, luckily, even in this
> case, the possibility to ignore this.
> 
> Or: That there is not h-b-h next header invalidates the "must be examined"
> rule and one could skip an unknown number (just forwarding the packet
> irrespective what garbage there is at its end). I hope this could be
> the correct interpretation since the h-b-h must immediately follow the
> IPv6 header. Unless someone challenges this order rule with a new header,
> or someone comes with a new h-b-h option requiring proceeding to something
> else, this could hopefully be the "right interpretation".
> 
	=> I believe so, but you could also check that on IPng. 
	Anyhow, the new header value we've been discussing is 
	a new DST-opt header which will only be processed by
	the end nodes. 
	If a router is forwarding a packet and the first header below
	the IPv6 header is not h-b-h then I see no reason for 
	it to recognise/process this header. 


> If someone observes the former, it would risk that there are boxes that
> drop packets with new unknown next headers. In the latter there would not
> be. Our boxes do the right thing, but can it be guaranteed so do others?
> 
	=> It sounds like the others are faulty if they're doing the 
	opposite. Faulty boxes do exist I suppose, we can't design
	protocols around them. Having said that, I haven't seen anyone
	saying they implemented their boxes in this way. 

> This could have been clearer in the text saying that routers must ignore
> next headers other than h-b-h. But, this would not be the first RFC in
> routing where "well-known" implementation guidelines help interpret the
> actual text.
> 
> 
	Hesham



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 05:13:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13852
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 05:13:35 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07011;
	Thu, 11 Oct 2001 03:13:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07692;
	Thu, 11 Oct 2001 02:12:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B9BpML005816
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 02:11:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B9BpNF005815
	for mobile-ip-dist; Thu, 11 Oct 2001 02:11:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B9BlML005808
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 02:11:47 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07604
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 02:11:49 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11055
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 03:13:01 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA07264
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:10:40 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA01806
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:11:46 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXLX1T>; Thu, 11 Oct 2001 19:11:45 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED47@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] protecting BUs
Date: Thu, 11 Oct 2001 19:11:39 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15234.BCA15030"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15234.BCA15030
Content-Type: text/plain


> Here, if HA/BU/Binding Ack/... etc. are placed before routing header,
> 'some non-MIPv6 router', when processing the routing header chain, will
> notice an unknown header type, drop the packet and send back ICMP error.
> 
> 
	=> All MIPv6 options are after the routing header.

	Hesham

------_=_NextPart_001_01C15234.BCA15030
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] protecting BUs</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=2 FACE="Arial">Here, if HA/BU/Binding Ack/... etc. are placed before routing header,</FONT>
<BR><FONT SIZE=2 FACE="Arial">'some non-MIPv6 router', when processing the routing header chain, will</FONT>
<BR><FONT SIZE=2 FACE="Arial">notice an unknown header type, drop the packet and send back ICMP error.</FONT>
</P>
<BR>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; All MIPv6 options are after the routing header.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15234.BCA15030--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 06:45:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14361
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 06:45:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29393;
	Thu, 11 Oct 2001 04:45:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19215;
	Thu, 11 Oct 2001 03:44:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BAhmML006061
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 03:43:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BAhmga006060
	for mobile-ip-dist; Thu, 11 Oct 2001 03:43:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BAhiML006053
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 03:43:44 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19158
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 03:43:42 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18478
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 03:43:44 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9BAhhC27935
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:43:43 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id MAA02118; Thu, 11 Oct 2001 12:43:41 +0200
Message-ID: <3BC57744.1166BAE4@era.ericsson.se>
Date: Thu, 11 Oct 2001 12:41:08 +0200
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multi-homing MIPv6???
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED3D@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


"Hesham Soliman (EPA)" wrote:
>      I don't recall seeing any
>      discussion of mult-homing and its relation to MIPv6 HO.  Perhaps
>      I missed something.
> 
>      => Well there is a couple  of issues here:
>      1. How well does ND handle multihoming
>      2. How can MIPv6 implementations handle
>          multihomed hosts for outbound traffic
>      3. How can MIPv6 handle inbound traffic
>          for multihomed hosts
> 
>      We had problems with the KAME implementation
>      last year but Mattias can explain that much better
>      than I can.

I don't know if we had problems, just too many possibilies... :)

Seriously, multihoming comes in two flavors:
 - One interface that is connected to a multihomed site
 - Multiple interfaces connected to different sites

In the first case the MN has one default router (could be multiple
routers too), and receives RAs with multiple prefixes in them. The MN
would have to choose the correct source and destination address
according to draft-ietf-ipngwg-default-addr-select-06.txt.

In the second case the MN for sure has more than one default router. It
will have a hard time choosing an appropriate next hop just following
RFC2461. Mobile IPv6 gives the implementer free hands, while
draft-ietf-ipngwg-router-selection-00.txt provides some useful
guidelines.

The problems we had were related to that regular ND is not defined for
multiple interfaces.


> 
>      For the second point, there are some implementations
>      out there that allow attaching the Home address to
>      a "virtual" interface, hence giving hosts the flexibility
>      of splitting their flows on different interfaces.

Using different care-of addresses on different interfaces is one aspect
of multihoming with MIPv6.

Another is when the home subnet is multihomed and you will have multiple
home addresses.

Yet another is when you have multiple home networks (because you have
multiple interfaces or for some other reason) and each is generating a
set of home addresses.

> 
>      We tried to address the third point in
>      http://standards.ericsson.net/hesham/draft-soliman-mobileip-flow-move-00.txt
> 
>      People have commented on it but we haven't added the
>      comments yet.
> 
>      Also, I don't recall seeing much discussion
>      of SCTP and MIPv6.
> 
>      => What kinds of issues do you see ?
> 
>      Other useful (related) drafts:
> 
>      http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-06.txt
> 
>      http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-selection-00.txt
> 
>      Also Homeless MIPv6 made a nice attempt but I can't find
>      the link to the draft. Perhaps you could do a serach for
>      it.

Homeless MIPv6 is interesting because it targets both mobility and
multihoming. In that draft all addresses are valid for communication.
There is no such thing as home addresses and care-of addresses (although
they are mentioned for backwards compatibility), and renumbering,
mobility and multihoming is hopefully covered by this protocol. The
upper layers are somewhat aware of all addresses used.

I figure SCTP could be made to do similar things, but it is not designed
for mobility.

Mobile IPv6 is very different because it focuses on a static home
address that is visible to the upper layers while the actual addresses
used are hidden.

BTW, has anyone tried Mobile IPv6 together with home network multihoming
or renumbering?

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 07:47:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14769
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 07:47:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA03777;
	Thu, 11 Oct 2001 04:47:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01634;
	Thu, 11 Oct 2001 04:47:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BBkCML006199
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 04:46:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BBkCkv006198
	for mobile-ip-dist; Thu, 11 Oct 2001 04:46:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BBk9ML006191
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 04:46:09 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24742
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 04:46:07 -0700 (PDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00826
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 05:45:59 -0600 (MDT)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <4KA6RBGX>; Thu, 11 Oct 2001 07:46:07 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486165CC@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Multi-homing MIPv6???
Date: Thu, 11 Oct 2001 07:46:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> 
> I don't know if we had problems, just too many possibilies... :)
> 
> Seriously, multihoming comes in two flavors:
>  - One interface that is connected to a multihomed site
>  - Multiple interfaces connected to different sites
There is another case, at least for some of us trying to get
mobile routers working properly and that is multiple interfaces,
routing multi-homed clients and the router itself being
multi-homed!

Home 1    Home 2
|          |
MR1--------.
|    
|    MR2----> Other homes.
|     |
|-----.
MN

Perhaps this is a bit too weird to be practical???  I could also
see the benefit of SCTP having access to the route table in MRs
so it could do its magic there.  In fact, it may very well be 
possible to do a handover WITHOUT MIPv6 in this manner???

-pdn
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 08:41:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15263
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 08:41:44 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01586;
	Thu, 11 Oct 2001 06:40:11 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07526;
	Thu, 11 Oct 2001 05:40:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BCdDML006303
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 05:39:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BCdCun006302
	for mobile-ip-dist; Thu, 11 Oct 2001 05:39:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BCd8ML006295;
	Thu, 11 Oct 2001 05:39:08 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07411;
	Thu, 11 Oct 2001 05:39:10 -0700 (PDT)
Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00729;
	Thu, 11 Oct 2001 06:38:57 -0600 (MDT)
Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1])
	by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f9BCelA02666;
	Thu, 11 Oct 2001 19:40:48 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        ipng@sunroof.eng.sun.com
Subject: [mobile-ip] Re: 
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se> 
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 Oct 2001 19:40:47 +0700
Message-ID: <2664.1002804047@brandenburg.cs.mu.OZ.AU>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
    Date:        Thu, 11 Oct 2001 19:04:26 +1000
    From:        "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
    Message-ID:  <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se>

  | > If one reads the last paragraph of page 6 one can read it two ways:

I think way too much is being read into that.   Routers are only
required to look at the IPv6 header, and the HbH options header if
one exists.   Only if there is some problem with one of those will
a router drop a packet (for IPv6 reasons, as distinct from congestion,
no route, etc).

The
	If, as a result of processing a header, a node is required
	to proceed to the next header, ...

means "where a node has to look at the next header", then if its type
is unknown, the packet has to be dropped.   A router never looks at the
next header, unless its type is "HbH" - in which case (one hopes) it
isn't an unknown type.

Note: it doesn't say that if you process a header and it contains an
unknown next header field you drop the packet - only if you have to
process the next header, and its type (which comes from the current
header) is unknown.  Routers never have to process the next header...

ie: your reply is right, the question is assuming things the text doesn't say.

kre



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 11:42:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18288
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 11:41:57 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04399;
	Thu, 11 Oct 2001 09:41:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27714;
	Thu, 11 Oct 2001 08:41:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BFeQML006724
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:40:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BFePHf006723
	for mobile-ip-dist; Thu, 11 Oct 2001 08:40:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BFeMML006716
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:40:22 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03987
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:40:23 -0700 (PDT)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20545
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:40:19 -0700 (PDT)
Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA10655;
	Thu, 11 Oct 2001 17:40:24 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <charliep@iprg.nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IESG feedback on AAA keys doc
Date: Thu, 11 Oct 2001 17:40:53 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKIECADIAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3BC48D49.FBDA3414@iprg.nokia.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Thanks,

see coments inline

/Fredrik
>
>Hello Fredrik,
>
>Thanks for your comments.
>
>> it SHOULD include an MN-FA Key Request extension 7 as part...
>> what do you mean by extension 7, I guess it has something to do
>> with subtype 7, defined where?
>>
>> Section 2 bullet 3.
>> same applies here for MN-HA Key Request extension 8...
>
>These were meant to be cross-references to the appropriate
>section, not type numbers!  I've fixed this now.
>
>> section 2 bullet 8.
>> "8. If the Reply passes authentication and contains the Unsolicited
>>        MN-HA Key Material From AAA extension (see section 6), the mobile
>>        node generates the key using the Key Material provided, according
>>        to its security association with the AAA. The resulting key is
>>        used to establish the mobile node's security association with its
>>        home agent, and is used to authenticate the MN-HA authentication
>>        extension."
>>
>> If the reply passes authentication... the mobile node generates the key
>> using the Key Material provided...
>>
>> The key has to be generated first in order to verify authentication since
>> the key is used in the verification process.
>
>Good point!   I have reworded this paragraph.
>
>
>> Section 3.
>> SHA-1 is missing in the table, in 08.txt it was SHA-1 but I believe it
>> should
>> be HMAC-SHA-1 that should be used.
>
>O.K.  I made an entry in the table for both SHA-1 and HMAC-SHA-1.
>However, this may become a moot point, depending on what is decided
>about where this table should most appropriately be specified.
>
>Maybe the right thing to do is to delete the table, and ask for
>some new numbers to be allocated in the IKE table.  What do you
>think we should do?  Shouldn't we also add something for AES and
>maybe for the recently mentioned PRF variants?  But why should
>Mobile-IP be in charge of such a table?

How do you mean when you say allocate new numbers in the IKE table? do you
mean
reuse the numbers already specified for these algorithms in some other table
or to use another table and just specify that table in this draft.

I believe that by having a table in the aaa-key draft we can easier prohibit
some
algorithms to be used (e.g. if they are considered unsecure, btw,
is md5-pre/suff considered safe? or should/can we remove it?) On the other
hand
it's harder to add new algorithms and it's yet another table to maintain.
I'm not realy sure what's best.

>
>> Section 4 last paragraph.
>> "The AAA-key used here is the key that has been previously configured
>>    as the basis of the security assocation between the mobile node and
>>    the AAA server creating the key."
>>
>> The AAA-key used is the one pointed to by the AAA SPI, i.e. the AAA SPI
>> points
>> to what algorithm to use and what key to use to create the key.
>
>Thanks.  I made the clarification you suggested, while also keeping the
>more explanatory text.  I could also delete the explanatory text if
>you think that would be better.

I believe it's good to have some explanatory text

>
>> IANA Considerations.
>> The number 7 is assigned to several of hte subtypes. Both MN-FA and MN-HA
>> Key
>> Request from AAA Subtype. Probably a cut'n'paste error
>
>
>These numbers were supposed to be whatever was already in use.
>They could both be 7, since they are subtypes of different
>generalized extensions.  However, if there isn't any real
>problem with changing the numbers, then we probably ought to
>leave it as TBD, and let IANA pick the numbers.  What do you
>think?

We can probably leave them as TBD, the only implementations available should
be a limited number of prototypes (as far as I know)

>
>
>Regards,
>Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 11:50:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18377
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 11:50:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13662;
	Thu, 11 Oct 2001 09:49:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29617;
	Thu, 11 Oct 2001 08:49:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BFn8ML006807
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:49:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BFn8Ij006806
	for mobile-ip-dist; Thu, 11 Oct 2001 08:49:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BFn4ML006799
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:49:04 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17314
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:49:06 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12628
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:50:18 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA27774
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:01 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 11 Oct 2001 10:47:48 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LXY3X>; Thu, 11 Oct 2001 10:48:17 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5D951C@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Requirements for non-MIPv6 implementations [MIPv6 - 
         Focus of thesecurity discussion]
Date: Thu, 11 Oct 2001 10:48:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1526C.23D85410"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1526C.23D85410
Content-Type: text/plain;
	charset="iso-8859-1"

Charlie and Pekka,

In relation to changing the BU processing to a MUST from a SHOULD for CN's:


It just seems to me that some protection needs to be done even for the HA
option to prevent against DDOS redirect (bouncing) and that the solutions
that seem tenable (don't require that every packet is  authenticated)
require some sort of authorization and state table similar to a binding
cache in size, lookup structure etc.. 

So if the HA option is a MUST and we have to protect against this DOS
redirect (bounce) problem then it seems like you might as well go ahead and
make the binding update processing a MUST too and get the ubiquity of route
optimization for IPv6. The HA integrity appears to me to be almost the same
class of problem and solution set as the BU integrity.

Thanks,

Glenn

------_=_NextPart_001_01C1526C.23D85410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] Requirements for non-MIPv6 implementations =
[MIPv6 -  Focus of thesecurity discussion]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Charlie and Pekka,</FONT>
</P>

<P><FONT SIZE=3D2>In relation to changing the BU processing to a MUST =
from a SHOULD for CN's:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>It just seems to me that some protection needs to be =
done even for the HA option to prevent against DDOS redirect (bouncing) =
and that the solutions that seem tenable (don't require that every =
packet is&nbsp; authenticated) require some sort of authorization and =
state table similar to a binding cache in size, lookup structure etc.. =
</FONT></P>

<P><FONT SIZE=3D2>So if the HA option is a MUST and we have to protect =
against this DOS redirect (bounce) problem then it seems like you might =
as well go ahead and make the binding update processing a MUST too and =
get the ubiquity of route optimization for IPv6. The HA integrity =
appears to me to be almost the same class of problem and solution set =
as the BU integrity.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1526C.23D85410--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 12:01:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18604
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 12:01:18 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24765;
	Thu, 11 Oct 2001 10:00:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02260;
	Thu, 11 Oct 2001 09:00:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BFqNML006870
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:52:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BFqNKB006869
	for mobile-ip-dist; Thu, 11 Oct 2001 08:52:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BFqKML006862
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:52:20 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18079
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 08:52:21 -0700 (PDT)
Received: from megisto-sql1.megisto.com ([63.113.114.132])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13649
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:53:00 -0600 (MDT)
Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21)
	id <TYNA3BP3>; Thu, 11 Oct 2001 11:48:01 -0400
Message-ID: <CD8355C7E19ED411BD5F00508BB0D19D698259@megisto-sql1.megisto.com>
From: Phil Roberts <PRoberts@MEGISTO.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: Purpose of: RE: [mobile-ip] protecting BUs
Date: Thu, 11 Oct 2001 11:47:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi folks,

   we requested Jari to put this draft together so that we'd
have written in one place the tradeoffs and issues surrounding
the use (or not) of IPSEC and piggybacking BUs.  There's been
a tremendous amount of discussion on the list on this which
is very hard to reference.  We'd like the working group to
work on this document and reach consensus that it adequately
describes the tradeoffs.  Not sure what we'll end up doing with
this document, but its contents should inform what finally
goes into the MIPv6 spec wrt implementation.

Thanks,
Phil


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Wednesday, October 10, 2001 9:13 AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Cc: jari.arkko@ericsson.fi
> Subject: [mobile-ip] protecting BUs
> 
> 
> Dear All,
> 
> I have written a draft that discusses the various
> solutions on the table for the protection of
> of Binding Updates after BAKE etc has done its
> job.
> 
> The goal of the draft is not so much to propose
> any specific solution, but rather to document
> alternatives, their advantages/disadvantages
> and issues brought up in the mailing list. My
> hope is that this will be useful in deciding how
> to move forward. First, we have to agree that
> we have all solutions, know their properties,
> and that the solutions actually work. I'd very
> like to wellcome all feedback on these aspects
> of the draft (as well as of course comments
> on which solution should be chosen and why).
> 
> The draft has been submitted to the IETF, but before
> it makes it to the official directories you can access
> it at
> 
> http://www.piuha.net/~jarkko/publications/draft-arkko-mipv6-bu
-security-00.txt

Jari Arkko
Ericsson


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 12:15:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18874
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 12:15:18 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01579;
	Thu, 11 Oct 2001 09:14:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04834;
	Thu, 11 Oct 2001 09:10:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BG1qML006953
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:01:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BG1pBG006952
	for mobile-ip-dist; Thu, 11 Oct 2001 09:01:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BG1lML006944;
	Thu, 11 Oct 2001 09:01:47 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20436;
	Thu, 11 Oct 2001 09:01:49 -0700 (PDT)
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20368;
	Thu, 11 Oct 2001 10:02:22 -0600 (MDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA44014;
	Thu, 11 Oct 2001 11:56:58 -0400
Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9BFxD0245380;
	Thu, 11 Oct 2001 09:59:14 -0600
Subject: Re: [mobile-ip] Duplicate Address Detection
To: Peter.Grimstrup@lmd.ericsson.se, mobile-ip@sunroof.eng.sun.com
Cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        owner-mobile-ip@sunroof.eng.sun.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFB4534D54.C1B679B0-ON88256AE2.00568FA2@boulder.ibm.com>
From: "Krishna Kumar" <kumarkr@us.ibm.com>
Date: Thu, 11 Oct 2001 08:56:07 -0700
X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 10/11/2001 09:59:12 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Peter,

To clarify your third question :

> Thirdly, section 9.1 requires DAD unconditionally when D-bit is
> set. Does this mean, that even if the HA is already defending
> the MN (i.e. the BU is updating/refreshing an already existing
> entry), the DAD must be executed again?

Section 10.7 talks about this :

While the mobile node is away from home, it relies on the home agent
to participate in Duplicate Address Detection (DAD) to defend its
home address against stateless autoconfiguration performed by another
node.  Therefore, the mobile node SHOULD set the Duplicate Address
Detection (D) bit based on any requirements for DAD that would apply
to the mobile node if it were at home [17, 27].  If the mobile
node's recent Binding Update was accepted by the home agent, and the
lifetime for that Binding Update has not yet expired, the mobile node
SHOULD NOT set the `D' bit in the new Binding Update; the home agent
will already be defending the home address(es) of the mobile node and
does not need to perform DAD again.

Regards,

- KK



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 12:29:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19120
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 12:29:33 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22325;
	Thu, 11 Oct 2001 10:26:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09105;
	Thu, 11 Oct 2001 09:26:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BGIHML007117
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:18:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BGIHWH007116
	for mobile-ip-dist; Thu, 11 Oct 2001 09:18:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BGICML007109
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:18:12 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24568
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:18:14 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04001
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:19:24 -0600 (MDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9BGIAC28939
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 18:18:10 +0200 (MEST)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Oct 11 18:17:58 2001 +0200
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <THQNVMKL>; Thu, 11 Oct 2001 18:17:58 +0200
Message-ID: <F7709E7648BAD41181E60008C716A22901059055@edkchnt102.lmd.ericsson.se>
From: "Peter Grimstrup (TED)" <Peter.Grimstrup@lmd.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Duplicate Address Detection 
Date: Thu, 11 Oct 2001 18:18:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Brian,

Thanks for your answer
> 
> > Draft 15 and probably the earlier drafts says:
> > 
> > D bit MUST not be set without A and H bit (sec. 5.1)
> > 
> > Section 8.2 says nothing about what to do if D is set but H is not.
> > One could 1) discard packet or 2) ignore D-bit or ?
> 
> In my opinion, since section 5.1 says "This bit is only valid when the
> Home Registration (H) and Acknowledge (A) bits are also set...", we
> should ignore the bit.  This follows the general notion of being
> liberal in what we accept.

Agree, but why not whenever it is possible/easy write it explicitly, i.e.
change 5.1 to "D-bit is ignored if the H-bit is not set."

/Peter


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 12:39:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19396
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 12:39:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14745;
	Thu, 11 Oct 2001 09:39:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12305;
	Thu, 11 Oct 2001 09:38:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BGUMML007221
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:30:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BGULFV007220
	for mobile-ip-dist; Thu, 11 Oct 2001 09:30:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BGUHML007210
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:30:17 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28189
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:30:19 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25970
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:30:07 -0600 (MDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9BGUGL24043
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 18:30:16 +0200 (MEST)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Oct 11 18:30:15 2001 +0200
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <THQNVMLR>; Thu, 11 Oct 2001 18:30:15 +0200
Message-ID: <F7709E7648BAD41181E60008C716A22901059056@edkchnt102.lmd.ericsson.se>
From: "Peter Grimstrup (TED)" <Peter.Grimstrup@lmd.ericsson.se>
To: "'Krishna Kumar'" <kumarkr@us.ibm.com>, mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Duplicate Address Detection
Date: Thu, 11 Oct 2001 18:30:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Krishna,

Thanks for your answer, I have another comment

> To clarify your third question :
> 
> > Thirdly, section 9.1 requires DAD unconditionally when D-bit is
> > set. Does this mean, that even if the HA is already defending
> > the MN (i.e. the BU is updating/refreshing an already existing
> > entry), the DAD must be executed again?
> 
> Section 10.7 talks about this :
> 
> While the mobile node is away from home, it relies on the home agent
> to participate in Duplicate Address Detection (DAD) to defend its
> home address against stateless autoconfiguration performed by another
> node.  Therefore, the mobile node SHOULD set the Duplicate Address
> Detection (D) bit based on any requirements for DAD that would apply
> to the mobile node if it were at home [17, 27].  If the mobile
> node's recent Binding Update was accepted by the home agent, and the
> lifetime for that Binding Update has not yet expired, the mobile node
> SHOULD NOT set the `D' bit in the new Binding Update; the home agent
> will already be defending the home address(es) of the mobile node and
> does not need to perform DAD again.
> 

Fine, but this is a description of the MN behaviour.
Generally, implementing a HA, I cannot trust the MN allways to behave
correctly. Whenever possible, the HA should act reasonably on "minor"
errors from the MN - if some reaction is not explicitly in the standard.

Maybe it's better to remove the D bit and let the HA decide when to do DAD
(according to RFC2462, I guess).

/Peter


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 13:03:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20036
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 13:03:21 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01216;
	Thu, 11 Oct 2001 11:02:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19258;
	Thu, 11 Oct 2001 10:02:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BGs0ML007385
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:54:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BGs0pI007384
	for mobile-ip-dist; Thu, 11 Oct 2001 09:54:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BGruML007377
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:53:56 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17263
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:53:55 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09592
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 09:53:57 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA23722;
	Thu, 11 Oct 2001 09:53:55 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BGrsN03932;
	Thu, 11 Oct 2001 09:53:54 -0700
X-mProtect:  Thu, 11 Oct 2001 09:53:54 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdpvQrRg; Thu, 11 Oct 2001 09:53:52 PDT
Message-ID: <3BC5CEA1.55B811CA@iprg.nokia.com>
Date: Thu, 11 Oct 2001 09:53:53 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
CC: mobile-ip@sunroof.eng.sun.com, Phil Roberts <PRoberts@MEGISTO.com>
Subject: Re: [mobile-ip] IESG feedback on AAA keys doc
References: <MJEMJBGGCLLDLFFAHLJKIECADIAA.fredrik.johansson@ipunplugged.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Fredrik,

Some minor clarification here, and follow-on comments.
Plus, a solution may be available, thanks to some mail from
Phil Roberts.

> How do you mean when you say allocate new numbers in the IKE table? do you
> mean reuse the numbers already specified for these algorithms in some other
> table or to use another table and just specify that table in this draft.

I meant the latter.

> I believe that by having a table in the aaa-key draft we can easier prohibit
> some algorithms to be used (e.g. if they are considered unsecure, btw,
> is md5-pre/suff considered safe? or should/can we remove it?) On the other
> hand it's harder to add new algorithms and it's yet another table to maintain.
> I'm not realy sure what's best.

On general principles, with everything else being equal, I would always
prefer to use a pre-existing table.  This is even more true when the
items to be tabulated are properly in the domain of another working group.
However, in this case, not everything else is equal:
- The tabulation has to include HMAC-MD5, since that is mandated
- The tabulation has to be "live", which means that it's a table
  which has not been obsoleted for some reason.
- There has to be some reasonable expectation that as our needs
  change, the table can be updated

The original table I found was in:
	http://www.iana.org/assignments/ipsec-registry
It does not have HMAC-MD5.

Phil pointed me to tables in IANA's registry for ISAKMP:
	http://www.iana.org/assignments/isakmp-registry
Turns out there are _two_ relevant tables there.
One is a list of "Transform ID"s for AH:

==================================================================

Transform ID            Value                           Reference
------------            -----                           ---------
RESERVED                0-1                             [RFC2407]
AH_MD5                  2                               [RFC2407]
AH_SHA                  3                               [RFC2407]
AH_DES                  4                               [RFC2407]
AH_SHA2-256             5                                 [Leech] 
AH_SHA2-384             6                                 [Leech]
AH_SHA2-512             7                                 [Leech]
AH_RIPEMD               8                               [RFC2857]

==================================================================

That does not have HMAC-MD5.

The other table at the same URL is a list of Authentication
Algorithms allowable as values for the "Attribute Type" (5)
(i.e., "Authentication Algorithm").  Type (5) is one of the
classifications in the tabulated Attribute Types for
"IPSEC Security Association Attributes".

=================================================================

  Authentication Algorithm

        Name            Value                   Reference
        ----            -----                   ---------
        Reserved        0                       [RFC2407]       
        HMAC-MD5        1                       [RFC2407]       
        HMAC-SHA        2                       [RFC2407]       
        DES-MAC         3                       [RFC2407]       
        KPDK            4                       [RFC2407]       
        HMAC-SHA2-256   5                         [Leech]
        HMAC-SHA2-384   6                         [Leech]
        HMAC-SHA2-512   7                         [Leech]
        HMAC-RIPEMD     8                       [RFC2857]    

=================================================================

This table has HMAC-MD5.  I think that maybe it could also
fulfill the other needs - basically for future extensibility
and continued compatibility with the need for authenticating
registration messages as part of the extensions in our document.

My current suggestion is that we use this table, and delete the
new table specification from within the AAA keys draft.  But, I am
really neutral, and I only make the suggestion as a positive
response to the IESG feedback which we have received.  I will
happily do whatever others suggest here.

In case this all seems to be tedious and hard to follow, my
apologies.  I don't know how to make a clearer explanation.
If anyone here knows why there are three different but seemingly
related tables of the "same thing" (with different entries),
I would be curious to know the answer.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 13:09:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20140
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 13:09:50 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08024;
	Thu, 11 Oct 2001 11:09:07 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21184;
	Thu, 11 Oct 2001 10:09:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BH0ZML007416
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:00:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BH0ZNI007415
	for mobile-ip-dist; Thu, 11 Oct 2001 10:00:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BH0VML007408
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:00:31 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18792
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:00:30 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28780
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:00:22 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24185
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:00:32 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BH0Wc16416
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:00:32 -0700
X-mProtect:  Thu, 11 Oct 2001 10:00:32 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdtSznCA; Thu, 11 Oct 2001 10:00:30 PDT
Message-ID: <3BC5D02F.90092222@iprg.nokia.com>
Date: Thu, 11 Oct 2001 10:00:31 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Duplicate Address Detection
References: <F7709E7648BAD41181E60008C716A22901059055@edkchnt102.lmd.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Peter,

"Peter Grimstrup (TED)" wrote:

> Agree, but why not whenever it is possible/easy write it explicitly, i.e.
> change 5.1 to "D-bit is ignored if the H-bit is not set."

I don't see any problem with this.  Unless someone else can say
why not to do this, I will make the change.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 13:30:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20566
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 13:30:01 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11757;
	Thu, 11 Oct 2001 10:29:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26747;
	Thu, 11 Oct 2001 10:29:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BHKjML007629
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:20:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BHKjd2007628
	for mobile-ip-dist; Thu, 11 Oct 2001 10:20:45 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BHKfML007621
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:20:41 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01568
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:20:44 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26447
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:20:43 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA26601;
	Thu, 11 Oct 2001 10:20:36 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BHKZY20649;
	Thu, 11 Oct 2001 10:20:35 -0700
X-mProtect:  Thu, 11 Oct 2001 10:20:35 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdKbsDke; Thu, 11 Oct 2001 10:20:33 PDT
Message-ID: <3BC5D4E1.E484E004@iprg.nokia.com>
Date: Thu, 11 Oct 2001 10:20:33 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED38@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Hesham,

"Hesham Soliman (EPA)" wrote:

>
>
> Hi Rajeev,
>
>      >  > I don't understand why this problem is specific to binding
>      updates.
>      >  > Are you saying that under such a reservation, the packet
>      size can't
>      >  > vary at all ? If I have been sending 1000 bytes, which is
>      way less
>      >  > than 1280, if I send 1020 bytes, will it be dropped ? Then
>      when such
>      >  > a tight channel is reserved there should be indication to IP
>      to
>      >  > change its MTU value so that path mtu discovery can kick in.
>
>      >
>      >    Yup, that's the problem. It really has nothing to do
>      >    with MTU; it's about keeping within the constraint of
>      >    a reservation. MTU is link based, not flow based afterall.
>      >
>
>      It is not entirely accurate to say that you cannot piggyback when
>      using a
>      dedicated channel. For instance, it is well-known that header
>      compression
>      gain can vary from packet to packet, thus affecting the
>      compressor states.
>      In a dedicated channel, which is what this thread is focussing on
>
>      I assume, in order to accommodate `header bursts', you need to
>      reserve for
>      the worst-case.
>
>      => Sure, that would solve it, but wouldn't that add additional
>      costs for a user ? For instance if I reserve for the worste case
>      which will only happen rarely compared to the BW required
>      for my application, it would seem like I'm paying more than
>      I need for y application.
>      I don''t really think the problems are significantly different
>      for Header compression (ie. whether you piggyback or not)
>      so I'm more concerned about the BW reservation consequences.
>
>

Well, if you support Full IP header transmission at all, with or without
header compression, you already are reserving for the worst-case. If you
don't have header compression, you have to reserve taking into account
the header bytes for all packets. If you have header compression, only
few (init, refresh) packets would need more bytes.

Anyway, my point is that some "wiggle" room will likely exist in
channels supporting IP for piggybacking.

Regards,

-Rajeev


>
>      Regards,
>      Hesham
>
>
>      >
>      >         Mike
>



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 13:54:11 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21152
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 13:54:10 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25154;
	Thu, 11 Oct 2001 10:53:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22112;
	Thu, 11 Oct 2001 10:53:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BHj3ML007755
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:45:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BHj3CU007754
	for mobile-ip-dist; Thu, 11 Oct 2001 10:45:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BHixML007747
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:44:59 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10973
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:44:59 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05406
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:46:12 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28223;
	Thu, 11 Oct 2001 10:44:51 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BHioq02898;
	Thu, 11 Oct 2001 10:44:50 -0700
X-mProtect:  Thu, 11 Oct 2001 10:44:50 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd2wJIxe; Thu, 11 Oct 2001 10:44:49 PDT
Message-ID: <3BC5DA91.9426DC18@iprg.nokia.com>
Date: Thu, 11 Oct 2001 10:44:49 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
	 <15300.33271.335089.998138@thomasm-u1.cisco.com> <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Michael,

interesting point. However, even with link-by-link compression I think it will
still work.

Here is your scenario:

1) MN1 sends a compressed packet with piggybacked BU to AR. The AR
decompresses the packet on the received link.

2) AR sends compressed packet with piggybacked BU to MN2 on another link.


Your point is you may not have enough capacity to do 2) above, right ?

Well, I think header compression has this predictability property. If you
compress a packet, decompress it and compress it again, the compression gain
should be the same! In other words,

let H be the total header size.
   1.   X = compress[H]
   2.   H = decompress[X]
          goto 1.

In the second iteration, value of X should be the same as in the first
iteration.


Regarding your other comment concerning BU persistence, you can re-transmit a
BU on a fresh real-time packet. You don't need to re-transmit the original
real-time packet itself.

Regards,

-Rajeev

ps. no comments regarding BETH.





"Michael A. Ramalho" wrote:

> At 11:02 AM 10/10/2001 -0700, Rajeev Koodli wrote:
> >Michael Thomas wrote:
> >
> > > Mohan Parthasarathy writes:
> > >  > I don't understand why this problem is specific to binding updates.
> > >  > Are you saying that under such a reservation, the packet size can't
> > >  > vary at all ? If I have been sending 1000 bytes, which is way less
> > >  > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
> > >  > a tight channel is reserved there should be indication to IP to
> > >  > change its MTU value so that path mtu discovery can kick in.
> > >
> > >    Yup, that's the problem. It really has nothing to do
> > >    with MTU; it's about keeping within the constraint of
> > >    a reservation. MTU is link based, not flow based afterall.
> > >
> >
> >It is not entirely accurate to say that you cannot piggyback when using a
> >dedicated channel. For instance, it is well-known that header compression
> >gain can vary from packet to packet, thus affecting the compressor states.
> >In a dedicated channel, which is what this thread is focussing on
> >I assume, in order to accommodate `header bursts', you need to reserve for
> >the worst-case. Now, IF that's the case, piggybacking a BU does not
> >necessarily violate the reservation, since, I could piggyback a BU on  FO
> >or SO packets (which have better compression gain compared to a packet
> >with no compression gain). The BU length, assuming 12 bytes for
> >Authentication Data, is 26 bytes compared to 40 bytes for IPv6 header
> >alone. So, when IPv6 header is not present, as would be the case in a SO
> >or FO packet, you _can_ piggyback, even in the so-called dedicated
> >channels.
>
> Rajeev,
>
> Sounds like you are only considering one side here - the MN sending.
>
> Assuming you are using link-by-link compression ... consider the
> case where the "other end" is also a MN that can receive and send
> "piggybacked" BUs AND is using a similar header compression scheme.
> This is a legitimate, if not increasingly prevalent, case.
>
> Unfortunately ... you won't know (on the sending link) which packets
> will have headers compressed on the "far-end" link ... as each link
> can compress headers independently.
>
> Thus, although you know when it is "safe" to piggyback on the
> sending MN link ... you won't know whether the resulting packet
> will fit into the "far end" MN link.
>
> So ... I strongly disagree ... you really don't know when it is safe to
> add a BU to the (real-time, TDM constrained) flow!
>
> Seems to me that you really should not be piggybacking BUs
> without BOTH ENDS agreeing that this is OK.
>
> Not piggybacking is OK as long as you have something like BETH
> anyway. If the BU takes a little longer to get where it is going, BETH
> should take care of the problem.
>
> Additionally you probably desire some form of over-the-air persistence
> on the (non ultra-delay-sensitive) BU (i.e., a re-transmission) ... and
> probably don't desire the re-transmission of the real-time packet.
>
> So ... my vote would be for allowing piggybacked BUs only when
> both ends say OK. OK?
>
> Comments?
>
> Michael Ramalho
>
> >Regards,
> >
> >-Rajeev
> >
> >
> >
> >
> >
> > >
> > >         Mike
>
> Michael A. Ramalho, Ph.D.
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 13:58:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21303
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 13:58:44 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27894;
	Thu, 11 Oct 2001 11:58:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23882;
	Thu, 11 Oct 2001 10:58:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BHnvML007797
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BHnudu007796
	for mobile-ip-dist; Thu, 11 Oct 2001 10:49:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BHnrML007789
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:53 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03022
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:50 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14483
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:53 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28611
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:51 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BHnpM11253
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:51 -0700
X-mProtect:  Thu, 11 Oct 2001 10:49:51 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpd1d7tVR; Thu, 11 Oct 2001 10:49:49 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA09407 for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 10:49:49 -0700 (PDT)
Message-ID: <3BC5DBBD.1548E5B4@iprg.nokia.com>
Date: Thu, 11 Oct 2001 10:49:49 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola wrote

> > be. Our boxes do the right thing, but can it be guaranteed so do others?
> > This could have been clearer in the text saying that routers must ignore
> > next headers other than h-b-h. But, this would not be the first RFC in
> > routing where "well-known" implementation guidelines help interpret the
> > actual text.
> 
> This is, by no means, a trivial issue.

I guess it might be safe to conclude that depending on your ordering rule
and semantics for a new header type you can in general break all,
some, or no routers (before h-b-h, between h-b-h and rthdr, after rthdr).
Hence, a new destination header needs to be after routing headers.

> Also, RFC2460 seems ignorant of IPv6 firewalls/packet filters which most
> assuredly would like to process upto e.g. TCP header, therefore also
> noticing an unknown header type.  The expected behaviour can be quickly
> deduced though.

This is also a bit tricky: If FWs follow RFC2460, corporate networks
cannot receive new binding updates, if we relax it on filtering rules,
they can (requires changing old strict-RFC2460 FW boxes), right?
So is this a requirement for change in case a new dst hdr type is
accepted?

> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 14:10:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21594
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 14:10:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05191;
	Thu, 11 Oct 2001 11:10:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27885;
	Thu, 11 Oct 2001 11:09:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BI1iML008001
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:01:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BI1iF9008000
	for mobile-ip-dist; Thu, 11 Oct 2001 11:01:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BI1eML007993
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:01:40 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06616
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:01:38 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16394
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:02:52 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9BI1ig25705
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:01:44 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABN04925;
	Thu, 11 Oct 2001 11:01:30 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06159; Thu, 11 Oct 2001 11:01:28 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15301.56952.774758.130701@thomasm-u1.cisco.com>
Date: Thu, 11 Oct 2001 11:01:28 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
In-Reply-To: <3BC5DBBD.1548E5B4@iprg.nokia.com>
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
	<3BC5DBBD.1548E5B4@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Uh, this is an interesting discussion and all, but
nobody's recommending that we have a new
intermediate header. The BU would be the final
header, and could just as easily be on a well
known UDP port instead of a new protocol number.

	  Mike

Jari T. Malinen writes:
 > Pekka Savola wrote
 > 
 > > > be. Our boxes do the right thing, but can it be guaranteed so do others?
 > > > This could have been clearer in the text saying that routers must ignore
 > > > next headers other than h-b-h. But, this would not be the first RFC in
 > > > routing where "well-known" implementation guidelines help interpret the
 > > > actual text.
 > > 
 > > This is, by no means, a trivial issue.
 > 
 > I guess it might be safe to conclude that depending on your ordering rule
 > and semantics for a new header type you can in general break all,
 > some, or no routers (before h-b-h, between h-b-h and rthdr, after rthdr).
 > Hence, a new destination header needs to be after routing headers.
 > 
 > > Also, RFC2460 seems ignorant of IPv6 firewalls/packet filters which most
 > > assuredly would like to process upto e.g. TCP header, therefore also
 > > noticing an unknown header type.  The expected behaviour can be quickly
 > > deduced though.
 > 
 > This is also a bit tricky: If FWs follow RFC2460, corporate networks
 > cannot receive new binding updates, if we relax it on filtering rules,
 > they can (requires changing old strict-RFC2460 FW boxes), right?
 > So is this a requirement for change in case a new dst hdr type is
 > accepted?
 > 
 > > Pekka Savola                 "Tell me of difficulties surmounted,
 > > Netcore Oy                   not those you stumble over and fall"
 > > Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
 > 
 > -Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 14:19:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21799
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 14:19:56 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10216;
	Thu, 11 Oct 2001 11:18:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00956;
	Thu, 11 Oct 2001 11:18:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIAdML008050
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:10:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BIAd53008049
	for mobile-ip-dist; Thu, 11 Oct 2001 11:10:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIAZML008042
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:10:35 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28136
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:10:36 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23842
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:10:36 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9BIAnu12424;
	Thu, 11 Oct 2001 11:10:49 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABN05238;
	Thu, 11 Oct 2001 11:09:59 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06162; Thu, 11 Oct 2001 11:09:59 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15301.57462.800600.138736@thomasm-u1.cisco.com>
Date: Thu, 11 Oct 2001 11:09:58 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC5D4E1.E484E004@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED38@eaubrnt018.epa.ericsson.se>
	<3BC5D4E1.E484E004@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Rajeev Koodli writes:
 > Well, if you support Full IP header transmission at all, with or without
 > header compression, you already are reserving for the worst-case. If you
 > don't have header compression, you have to reserve taking into account
 > the header bytes for all packets. If you have header compression, only
 > few (init, refresh) packets would need more bytes.
 > 
 > Anyway, my point is that some "wiggle" room will likely exist in
 > channels supporting IP for piggybacking.

   Again, I'd like to see a MAC which works well with
   real time traffic on a shared access media
   because I know that the DOCSIS MAC specifically
   made the tradeoff of using the less efficient
   payload header supression which works well with
   TDM-like slots, where CRTP (or ROHC) does not.
   I guarantee you that cable MSO's are paranoid 
   about upstream bandwidth too.

   Until then, I chalk this up to wishful thinking.

	       Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 14:29:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21962
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 14:29:19 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16446;
	Thu, 11 Oct 2001 11:28:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07076;
	Thu, 11 Oct 2001 11:28:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIJXML008174
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:19:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BIJXL3008173
	for mobile-ip-dist; Thu, 11 Oct 2001 11:19:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIJTML008157
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:19:29 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01196
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:19:30 -0700 (PDT)
Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29590
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:19:29 -0700 (PDT)
Received: from piuha.net (ws4.piuha.net [195.165.196.4])
	by ws2.piuha.net (Postfix) with ESMTP id 927256A905
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 21:19:21 +0300 (EEST)
Message-ID: <3BC5E3F1.10700@piuha.net>
Date: Thu, 11 Oct 2001 21:24:49 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
		 <15300.33271.335089.998138@thomasm-u1.cisco.com> <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com> <3BC5DA91.9426DC18@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Rajeev Koodli wrote:


> 1) MN1 sends a compressed packet with piggybacked BU to AR. The AR
> decompresses the packet on the received link.
> 
> 2) AR sends compressed packet with piggybacked BU to MN2 on another link.
> 
> 
> Your point is you may not have enough capacity to do 2) above, right ?
> 
> Well, I think header compression has this predictability property. If you
> compress a packet, decompress it and compress it again, the compression gain
> should be the same! In other words,

Yes, but I think the scenario was that the sender
was e.g. a multimedia server on www.cnn.com, completely
unaware of the fact that the other end is on a tight
channel, and uncompressed. Then it happens to piggyback
a Binding Ack on the multimedia stream. Or a WLAN MN
capable of using a lot of bandwidth compared to the
cellular MN on the other side.

Jari




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 14:44:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22341
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 14:44:40 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14559;
	Thu, 11 Oct 2001 12:44:07 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02418;
	Thu, 11 Oct 2001 11:44:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIZXML008337
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:35:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BIZXgG008336
	for mobile-ip-dist; Thu, 11 Oct 2001 11:35:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIZTML008329
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:35:30 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11325
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:35:26 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13398
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:35:25 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA02396
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:35:25 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BIZOs29987
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:35:24 -0700
X-mProtect:  Thu, 11 Oct 2001 11:35:24 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdAqrJxT; Thu, 11 Oct 2001 11:35:22 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id LAA09463 for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:35:22 -0700 (PDT)
Message-ID: <3BC5E66A.D09C9D7F@iprg.nokia.com>
Date: Thu, 11 Oct 2001 11:35:22 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Roam.SIMC.2.0.6.1002790261.25110.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> If folks think routers should reject packets in the forwarding path
> with an unknown nexthdr, how could we possibly deploy a new transport
> protocol like SCTP? It has a new nexthdr value.
> 
> So please tell me that I'm reading your note incorrectly.
> 
>   Erik

A new upper layer is easy since it is at the end of the packet,
I was more thinking in general terms if you add a new header to
any place in the ordering. Before routing hdr and esp. before
hop-by-hop there would be problems.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 14:52:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22515
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 14:52:19 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29386;
	Thu, 11 Oct 2001 11:51:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04383;
	Thu, 11 Oct 2001 11:50:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIgTML008359
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:42:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BIgTDp008358
	for mobile-ip-dist; Thu, 11 Oct 2001 11:42:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIgPML008351
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:42:25 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13606
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:42:26 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11065
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:43:39 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA02762;
	Thu, 11 Oct 2001 11:42:18 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BIgHJ07372;
	Thu, 11 Oct 2001 11:42:17 -0700
X-mProtect:  Thu, 11 Oct 2001 11:42:17 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdl64D9h; Thu, 11 Oct 2001 11:42:16 PDT
Message-ID: <3BC5E807.3EDA55BB@iprg.nokia.com>
Date: Thu, 11 Oct 2001 11:42:15 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED38@eaubrnt018.epa.ericsson.se>
		<3BC5D4E1.E484E004@iprg.nokia.com> <15301.57462.800600.138736@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

> Rajeev Koodli writes:
>  > Well, if you support Full IP header transmission at all, with or without
>  > header compression, you already are reserving for the worst-case. If you
>  > don't have header compression, you have to reserve taking into account
>  > the header bytes for all packets. If you have header compression, only
>  > few (init, refresh) packets would need more bytes.
>  >
>  > Anyway, my point is that some "wiggle" room will likely exist in
>  > channels supporting IP for piggybacking.
>
>    Again, I'd like to see a MAC which works well with
>    real time traffic on a shared access media
>    because I know that the DOCSIS MAC specifically
>    made the tradeoff of using the less efficient
>    payload header supression which works well with
>    TDM-like slots, where CRTP (or ROHC) does not.
>    I guarantee you that cable MSO's are paranoid
>    about upstream bandwidth too.
>
>    Until then, I chalk this up to wishful thinking.

You might want to look into some ROHC implementations.

Regards,

-Rajeev


>
>
>                Mike



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 15:00:16 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22652
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 15:00:15 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04206;
	Thu, 11 Oct 2001 11:58:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07077;
	Thu, 11 Oct 2001 11:58:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BInuML008461
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:49:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BInuYW008460
	for mobile-ip-dist; Thu, 11 Oct 2001 11:49:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BInqML008453
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:49:52 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24480
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:49:51 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18663
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:49:54 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA03332
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:49:53 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BInqY18689
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:49:52 -0700
X-mProtect:  Thu, 11 Oct 2001 11:49:52 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd2BdVcU; Thu, 11 Oct 2001 11:49:50 PDT
Message-ID: <3BC5E9CF.5EFA7C6@iprg.nokia.com>
Date: Thu, 11 Oct 2001 11:49:51 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
			 <15300.33271.335089.998138@thomasm-u1.cisco.com> <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com> <3BC5DA91.9426DC18@iprg.nokia.com> <3BC5E3F1.10700@piuha.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari Arkko wrote:

> Rajeev Koodli wrote:
>
> > 1) MN1 sends a compressed packet with piggybacked BU to AR. The AR
> > decompresses the packet on the received link.
> >
> > 2) AR sends compressed packet with piggybacked BU to MN2 on another link.
> >
> >
> > Your point is you may not have enough capacity to do 2) above, right ?
> >
> > Well, I think header compression has this predictability property. If you
> > compress a packet, decompress it and compress it again, the compression gain
> > should be the same! In other words,
>
> Yes, but I think the scenario was that the sender
> was e.g. a multimedia server on www.cnn.com, completely
> unaware of the fact that the other end is on a tight
> channel, and uncompressed. Then it happens to piggyback
> a Binding Ack on the multimedia stream. Or a WLAN MN
> capable of using a lot of bandwidth compared to the
> cellular MN on the other side.

There are ways to handle the scenario you describe. That's the purpose of this
note.

Regards,

-Rajeev


>
>
> Jari



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 15:06:04 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22893
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 15:06:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07776;
	Thu, 11 Oct 2001 12:04:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08864;
	Thu, 11 Oct 2001 12:02:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIrvML008545
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:53:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BIrvBW008544
	for mobile-ip-dist; Thu, 11 Oct 2001 11:53:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BIrsML008537
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:53:54 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17395
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 11:53:55 -0700 (PDT)
Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24713
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:53:43 -0600 (MDT)
Received: (from msa@localhost)
	by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA16176;
	Thu, 11 Oct 2001 21:53:53 +0300
Date: Thu, 11 Oct 2001 21:53:53 +0300
Message-Id: <200110111853.VAA16176@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: mobile-ip@sunroof.eng.sun.com
In-reply-to: <3BC5E66A.D09C9D7F@iprg.nokia.com> (jmalinen@iprg.nokia.com)
Subject: Re: [mobile-ip] protecting BUs
References: <Roam.SIMC.2.0.6.1002790261.25110.nordmark@bebop.france> <3BC5E66A.D09C9D7F@iprg.nokia.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> A new upper layer is easy since it is at the end of the packet,
> I was more thinking in general terms if you add a new header to
> any place in the ordering. Before routing hdr and esp. before
> hop-by-hop there would be problems.

I repeat, *ROUTERS* only look at IP header and possibly
hbh.

ROUTER is not looking for routing header in IPv6. That is the function
of the node identified by the destination address of the IP header.

Firewall is something else than a ROUTER. If it wants to look through
all headers, it needs to know them. But, "core" routers do not need
this info.




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 15:16:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23262
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 15:16:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15951;
	Thu, 11 Oct 2001 13:15:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12689;
	Thu, 11 Oct 2001 12:14:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJ6FML008740
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:06:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BJ6Fbu008739
	for mobile-ip-dist; Thu, 11 Oct 2001 12:06:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJ6BML008732
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:06:12 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28168
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:06:10 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03481
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:06:12 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9BJ6Ck20878;
	Thu, 11 Oct 2001 12:06:12 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABN07346;
	Thu, 11 Oct 2001 12:05:54 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA06168; Thu, 11 Oct 2001 12:05:54 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15301.60818.89571.917642@thomasm-u1.cisco.com>
Date: Thu, 11 Oct 2001 12:05:54 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC5E807.3EDA55BB@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED38@eaubrnt018.epa.ericsson.se>
	<3BC5D4E1.E484E004@iprg.nokia.com>
	<15301.57462.800600.138736@thomasm-u1.cisco.com>
	<3BC5E807.3EDA55BB@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Rajeev Koodli writes:
 > Michael Thomas wrote:
 > >    Again, I'd like to see a MAC which works well with
 > >    real time traffic on a shared access media
 > >    because I know that the DOCSIS MAC specifically
 > >    made the tradeoff of using the less efficient
 > >    payload header supression which works well with
 > >    TDM-like slots, where CRTP (or ROHC) does not.
 > >    I guarantee you that cable MSO's are paranoid
 > >    about upstream bandwidth too.
 > >
 > >    Until then, I chalk this up to wishful thinking.
 > 
 > You might want to look into some ROHC implementations.

   This is getting pretty frustrating.

   This has nothing to do with ROHC implementations.

   I have asked about 4 times now for a pointer to
   an L2 on a shared media which has the VBR 
   characteristics you claim exist which do not 
   compromise latency or bandwidth.

   Until you can come up with _one_ example, I'm
   going to assume that it does not exist and that 
   ROHC and piggybacking will result in unacceptible
   bandwidth use for real time traffic on shared 
   media.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 15:34:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23551
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 15:34:02 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01658;
	Thu, 11 Oct 2001 13:32:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18156;
	Thu, 11 Oct 2001 12:32:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJNSML008854
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:23:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BJNSCl008853
	for mobile-ip-dist; Thu, 11 Oct 2001 12:23:28 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJNOML008846
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:23:24 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25881
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:23:26 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07702
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:23:26 -0700 (PDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9BJNSk04425
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:23:28 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (dhcp-wall-59-62.cisco.com [171.68.59.62])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABD28896;
	Thu, 11 Oct 2001 12:23:25 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011011140647.050084c0@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 11 Oct 2001 15:21:32 -0400
To: mobile-ip@sunroof.eng.sun.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC5DA91.9426DC18@iprg.nokia.com>
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
 <15300.33271.335089.998138@thomasm-u1.cisco.com>
 <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Rajeev,

Another volley to make myself more clear. You have my point
*almost* correct.

Comments in line.

Michael Ramalho

At 10:44 AM 10/11/2001 -0700, you wrote:
>Hello Michael,
>
>interesting point. However, even with link-by-link compression I think it will
>still work.
>
>Here is your scenario:
>
>1) MN1 sends a compressed packet with piggybacked BU to AR. The AR
>decompresses the packet on the received link.
>
>2) AR sends compressed packet with piggybacked BU to MN2 on another link.
>
>
>Your point is you may not have enough capacity to do 2) above, right ?

Yes ... I'll explain in line below.


>Well, I think header compression has this predictability property. If you
>compress a packet, decompress it and compress it again, the compression gain
>should be the same! In other words,
>
>let H be the total header size.
>    1.   X = compress[H]
>    2.   H = decompress[X]
>           goto 1.
>
>In the second iteration, value of X should be the same as in the first
>iteration.

One hopes that the "predictability property" is always true.

But ... links make the compression decision independently
(as I previously stated).

Consider three links (to make it simple), L1 -> L2 -> L3.

Lets say, without loss of generality, that L1 and L3 are the
links to the mobile nodes AND lets say that L2 *does not
use compression*.

That is the compression state of L1 is *INDEPENDENT OF
THE COMPRESSION STATE* of link 3.

Specifically ... your compressed BU sent on L1 (w/ FO or
SO state on compressed link L1) is decompressed
for transmission on L2.

But how do you know a priori that L3 is *NOT IN IR STATE*
when L3 gets it.

The point is that you don't know this a priori - and therefore
do not know if the BU will fit onto L3.

It usually will ... as L3 hopes to be in FO or S0 state and
obtaining compression ... but my point is that it is not
guaranteed.

Ordinarily I like it when the odds are with me in probabilistic sense,
but this isn't an ordinary UDP voice packet (where I wouldn't
mind an isolated loss) ... it has a BU piggybacked to it.

So ... you need another email volley to convince me.


>Regarding your other comment concerning BU persistence, you can re-transmit a
>BU on a fresh real-time packet. You don't need to re-transmit the original
>real-time packet itself.

Interesting proposal ... and it is doable ... and it raises an interesting
tradeoff and a question or two.

Your proposal assumes that the link layer knew that there was an
error ... and that it was smart enough to know that the packet was
a real-time packet (and not attempt to retransmit it) AND smart enough
to know that the BU it had piggybacked could be delayed until the
next real-time packet (i.e., not immediately sent).

Does the link layer always know when the next packet is supposed to
arrive (for example, VoIP with VAD ... you don't know!)? I guess you
could simply transmit the BU if the "expected packet" doesn't arrive
in time (a timeout based on the expected interpacket arrival time of
the real-time flow).

But ... I hope this is moot ... since I had hoped to convince you that
piggybacking on L1 may not be a good idea.

If you are into building specialized link layers for outgoing BU's, I
*could* be convinced that building a specialized link layer at the
L1 decompressor that ALWAYS de-biggybacked a BU which was
sent over L1 could be designed. This would localize the effect of
the piggybacking only to a given link. But since I have not given the
idea full thought ... you would need to work on me a little more :-).

Regards,

Michael Ramalho


>Regards,
>
>-Rajeev
>
>ps. no comments regarding BETH.

opps .. :-)





>"Michael A. Ramalho" wrote:
>
> > At 11:02 AM 10/10/2001 -0700, Rajeev Koodli wrote:
> > >Michael Thomas wrote:
> > >
> > > > Mohan Parthasarathy writes:
> > > >  > I don't understand why this problem is specific to binding updates.
> > > >  > Are you saying that under such a reservation, the packet size can't
> > > >  > vary at all ? If I have been sending 1000 bytes, which is way less
> > > >  > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
> > > >  > a tight channel is reserved there should be indication to IP to
> > > >  > change its MTU value so that path mtu discovery can kick in.
> > > >
> > > >    Yup, that's the problem. It really has nothing to do
> > > >    with MTU; it's about keeping within the constraint of
> > > >    a reservation. MTU is link based, not flow based afterall.
> > > >
> > >
> > >It is not entirely accurate to say that you cannot piggyback when using a
> > >dedicated channel. For instance, it is well-known that header compression
> > >gain can vary from packet to packet, thus affecting the compressor states.
> > >In a dedicated channel, which is what this thread is focussing on
> > >I assume, in order to accommodate `header bursts', you need to reserve for
> > >the worst-case. Now, IF that's the case, piggybacking a BU does not
> > >necessarily violate the reservation, since, I could piggyback a BU on  FO
> > >or SO packets (which have better compression gain compared to a packet
> > >with no compression gain). The BU length, assuming 12 bytes for
> > >Authentication Data, is 26 bytes compared to 40 bytes for IPv6 header
> > >alone. So, when IPv6 header is not present, as would be the case in a SO
> > >or FO packet, you _can_ piggyback, even in the so-called dedicated
> > >channels.
> >
> > Rajeev,
> >
> > Sounds like you are only considering one side here - the MN sending.
> >
> > Assuming you are using link-by-link compression ... consider the
> > case where the "other end" is also a MN that can receive and send
> > "piggybacked" BUs AND is using a similar header compression scheme.
> > This is a legitimate, if not increasingly prevalent, case.
> >
> > Unfortunately ... you won't know (on the sending link) which packets
> > will have headers compressed on the "far-end" link ... as each link
> > can compress headers independently.
> >
> > Thus, although you know when it is "safe" to piggyback on the
> > sending MN link ... you won't know whether the resulting packet
> > will fit into the "far end" MN link.
> >
> > So ... I strongly disagree ... you really don't know when it is safe to
> > add a BU to the (real-time, TDM constrained) flow!
> >
> > Seems to me that you really should not be piggybacking BUs
> > without BOTH ENDS agreeing that this is OK.
> >
> > Not piggybacking is OK as long as you have something like BETH
> > anyway. If the BU takes a little longer to get where it is going, BETH
> > should take care of the problem.
> >
> > Additionally you probably desire some form of over-the-air persistence
> > on the (non ultra-delay-sensitive) BU (i.e., a re-transmission) ... and
> > probably don't desire the re-transmission of the real-time packet.
> >
> > So ... my vote would be for allowing piggybacked BUs only when
> > both ends say OK. OK?
> >
> > Comments?
> >
> > Michael Ramalho
> >
> > >Regards,
> > >
> > >-Rajeev
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >         Mike
> >
> > Michael A. Ramalho, Ph.D.
> > Office email: mramalho@cisco.com
> > Personal email: mar42@cornell.edu
> > Office: +1.732.449.5762
> > Cell: +1.732.809.0188


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 15:43:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23675
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 15:43:23 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27859;
	Thu, 11 Oct 2001 12:41:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15313;
	Thu, 11 Oct 2001 12:41:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJT3ML008879
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:29:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BJT3Ag008878
	for mobile-ip-dist; Thu, 11 Oct 2001 12:29:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJSxML008871
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:28:59 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12268
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:29:01 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28451
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:28:49 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9BJSwI25730
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 22:28:58 +0300
Date: Thu, 11 Oct 2001 22:28:58 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] protecting BUs
In-Reply-To: <200110111853.VAA16176@burp.tkv.asdf.org>
Message-ID: <Pine.LNX.4.33.0110112218470.25674-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 11 Oct 2001, Markku Savela wrote:
> > A new upper layer is easy since it is at the end of the packet,
> > I was more thinking in general terms if you add a new header to
> > any place in the ordering. Before routing hdr and esp. before
> > hop-by-hop there would be problems.
>
> I repeat, *ROUTERS* only look at IP header and possibly
> hbh.
>
> ROUTER is not looking for routing header in IPv6. That is the function
> of the node identified by the destination address of the IP header.

Uhh.

When a packet with routing header reaches the destination (possibly a
ROUTER, e.g. in certain traffic engineering/multihoming etc. needs), it
will need to know the type of all headers before Routing Header so it can
swap the addresses etc.

One has to keep this in mind if you'd put a new shiny header before
routing header.

> Firewall is something else than a ROUTER. If it wants to look through
> all headers, it needs to know them. But, "core" routers do not need
> this info.

Sure.  You must be aware of how RFC2460 was supposed to be implemented to
get this right.

In practise firewalls are routers, because they surely are _not_ hosts as
they perform forwarding between interfaces.

It does not matter if the firewalling happens in core network or elsewhere
in the packet trail (e.g. near the border/access routers) -- if the packet
is dropped, it is dropped.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 16:03:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23916
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 16:03:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08332;
	Thu, 11 Oct 2001 13:02:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20449;
	Thu, 11 Oct 2001 13:02:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJqgML009097
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:52:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BJqgYj009096
	for mobile-ip-dist; Thu, 11 Oct 2001 12:52:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJqcML009089
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:52:38 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18095
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:52:40 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22091
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:53:48 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA19017
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:52:35 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 11 Oct 2001 14:51:37 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LX0J4>; Thu, 11 Oct 2001 14:52:06 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5D99D6@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Requirements for non-MIPv6 implementations [MIPv6 - 
         Focus of thesecurity discussion]
Date: Thu, 11 Oct 2001 14:52:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1528E.3325BF30"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1528E.3325BF30
Content-Type: text/plain;
	charset="iso-8859-1"

Clarification:

What I referred to below as DDOS redirection or bouncing is actually
referred to in the security requirements draft as "packet reflector"
-(Section 6.8: Threat H.3 and Scenario H.3. Sorry about the discontinuity in
terminology.

-----Original Message-----

Charlie and Pekka, 
In relation to changing the BU processing to a MUST from a SHOULD for CN's: 


It just seems to me that some protection needs to be done even for the HA
option to prevent against DDOS redirect (bouncing) and that the solutions
that seem tenable (don't require that every packet is  authenticated)
require some sort of authorization and state table similar to a binding
cache in size, lookup structure etc.. 
So if the HA option is a MUST and we have to protect against this DOS
redirect (bounce) problem then it seems like you might as well go ahead and
make the binding update processing a MUST too and get the ubiquity of route
optimization for IPv6. The HA integrity appears to me to be almost the same
class of problem and solution set as the BU integrity.
Thanks, 
Glenn 

------_=_NextPart_001_01C1528E.3325BF30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] Requirements for non-MIPv6 implementations =
[MIPv6 -  Focus of thesecurity discussion]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Clarification:</FONT>
</P>

<P><FONT SIZE=3D2>What I referred to below as DDOS redirection or =
bouncing is actually referred to in the security requirements draft as =
&quot;packet reflector&quot; -(Section 6.8: Threat H.3 and Scenario =
H.3. Sorry about the discontinuity in terminology.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
</P>

<P><FONT SIZE=3D2>Charlie and Pekka, </FONT>
<BR><FONT SIZE=3D2>In relation to changing the BU processing to a MUST =
from a SHOULD for CN's: </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>It just seems to me that some protection needs to be =
done even for the HA option to prevent against DDOS redirect (bouncing) =
and that the solutions that seem tenable (don't require that every =
packet is&nbsp; authenticated) require some sort of authorization and =
state table similar to a binding cache in size, lookup structure etc.. =
</FONT></P>

<P><FONT SIZE=3D2>So if the HA option is a MUST and we have to protect =
against this DOS redirect (bounce) problem then it seems like you might =
as well go ahead and make the binding update processing a MUST too and =
get the ubiquity of route optimization for IPv6. The HA integrity =
appears to me to be almost the same class of problem and solution set =
as the BU integrity.</FONT></P>

<P><FONT SIZE=3D2>Thanks, </FONT>
<BR><FONT SIZE=3D2>Glenn </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1528E.3325BF30--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 16:09:22 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24062
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 16:09:21 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03297;
	Thu, 11 Oct 2001 14:08:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22162;
	Thu, 11 Oct 2001 13:08:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJxRML009140
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:59:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BJxRLL009139
	for mobile-ip-dist; Thu, 11 Oct 2001 12:59:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BJxNML009132
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:59:23 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19570
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 12:59:20 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25026
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:59:08 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9BJxIl25877
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 22:59:18 +0300
Date: Thu, 11 Oct 2001 22:59:18 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] protecting BUs
In-Reply-To: <3BC5DBBD.1548E5B4@iprg.nokia.com>
Message-ID: <Pine.LNX.4.33.0110112229220.25674-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 11 Oct 2001, Jari T. Malinen wrote:
> Pekka Savola wrote
>
> > > be. Our boxes do the right thing, but can it be guaranteed so do others?
> > > This could have been clearer in the text saying that routers must ignore
> > > next headers other than h-b-h. But, this would not be the first RFC in
> > > routing where "well-known" implementation guidelines help interpret the
> > > actual text.
> >
> > This is, by no means, a trivial issue.
>
> I guess it might be safe to conclude that depending on your ordering rule
> and semantics for a new header type you can in general break all,
> some, or no routers (before h-b-h, between h-b-h and rthdr, after rthdr).
> Hence, a new destination header needs to be after routing headers.

After routing header, definitely, as Hesham noted.

> > Also, RFC2460 seems ignorant of IPv6 firewalls/packet filters which most
> > assuredly would like to process upto e.g. TCP header, therefore also
> > noticing an unknown header type.  The expected behaviour can be quickly
> > deduced though.
>
> This is also a bit tricky: If FWs follow RFC2460, corporate networks
> cannot receive new binding updates, if we relax it on filtering rules,
> they can (requires changing old strict-RFC2460 FW boxes), right?
> So is this a requirement for change in case a new dst hdr type is
> accepted?

As a matter of fact, to clarify, looking at RFC2460 4.2. and MIPv6 -14..

BU, BAck, HA, etc. are indeed Destination Options Header options, not
extension headers (the interpretation under debate with ipng@ was about
ext header processing IIRC), there is some hope for some of them at least.

If the option type begins with '00', the specified behaviour is to skip
over the option and continue processing if the option was not recognized.

So it would appear:

BU: 198 ==> whole packet dropped if the option is not recognized
BAck: 7 ==> ok
Breq: 8 ==> ok
HA: 201 ==> whole packet dropped if the option is not recognized

How the firewalls would interpret this is up to the implementors, I
suppose.  I hope to be able to write an I-D about new challenges of IPv6
for firewall/packet filter implementors at some point, unless there's
already some work going on on the subject.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords





From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 17:01:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25369
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:01:53 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08425;
	Thu, 11 Oct 2001 14:00:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11730;
	Thu, 11 Oct 2001 14:00:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BKpUML009436
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:51:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BKpUhT009435
	for mobile-ip-dist; Thu, 11 Oct 2001 13:51:30 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BKpQML009428
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:51:26 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02951
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:51:29 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25743
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:52:41 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA08031
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:51:27 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 11 Oct 2001 15:50:33 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LYBD9>; Thu, 11 Oct 2001 15:51:02 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5D9AC7@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 11 Oct 2001 15:50:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15296.6D9CF720"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15296.6D9CF720
Content-Type: text/plain;
	charset="iso-8859-1"

Hey Hesham,
 
I guess people just don't agree on the value of piggybacking, the affect of
delays incurred by segmentation and whether the access network should drive
the IP definitions or the access networks should adapt to the IP
definitions. 
 
The last time I got involved in this piggyback discussion it got very messy
and so I think I'll refrain from further discussion for now.
 
I do want to commend Jari for taking the time and effort to produce what I
consider a fairly unbiased BU security draft in record time.
 
Best wishes,
 
Glenn

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Wednesday, October 10, 2001 8:29 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion




	Hi Glenn, 
  
Not that this is the particular place for this discussion but it seems that
limitations of specific access technologies have again emerged into the
requirements of this IETF WG. 

	=> Probably not the right place but we can try till the chairs tell
us to stop :) 
  
Have you explored sending the piggybacked packets over something like - say,
the MAC representation of the signaling PDP context? 

	=> I don't get that, could you elaborate a bit ? 

	It seems that this multiplexing could be accomplished quite easily
via some ROHC middle box? 
  
I, for one, don't see much of a problem with some miniscule delay on one
single packet during a handoff of a mobile to mobile or mobile to cable
voice call - even if something like the signaling PDP context is not used.

	  
Dropping the packet is probably worse than some miniscule segmentation delay
on one packet. 

	=> I'm not sure that it's a miniscule delay at all. The delay will
probably be doubled. 
If one packet fits nicely in the radio frame, and the extra bytes 
take it beyond that frame, then it is likely that the delay will at least be
doubled 
(I'm clearly considering the delays over the air whichh are the major
portion of 
the RTT delay in a cellular network). 
Now for a real time application, this delay is just as good as dropping the 
packet. Have I missed something ? 
  
I could see creating some new form of generic authentication/encryption
header that could be used for integrity and confidentiality of any set of IP
options and used in conjunction with existing IPSEC headers for the
applications; but based upon the timeliness of such work and cross WG
controversy involved in this, it seems that the logical and expedient
solution specified in the existing draft makes the best sense at this
particular point in time. I don't mind if someone suggests such as thing but
I don't think it should hamper the existing MIPv6 proposal which does solve
the problem.

	=> This is an orthogonal issue to piggybacking IMHO. The current 
soution in the draft doesn't solve the problems we're discussing. 
Obviously this new susboption will not be compressed by 
ROHC, s the extra bytes are still there. 
  
As far a creating a new header specifically for BU, I don't see how that
would solve much of anything. Again, I don't mind if someone suggests such
as thing but I don't think it should hamper the acceptance of the existing
MIPv6 proposal.

	=>  Again this is another (a third issues). This was suggested for 
allowing IPsec to protect the BUs. Have a look at Jari's draft. 

	Hesham 

	-----Original Message-----
From: Hesham Soliman (EPA) [ mailto:Hesham.Soliman@ericsson.com.au
<mailto:Hesham.Soliman@ericsson.com.au> ]
Sent: Wednesday, October 10, 2001 12:56 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion




	        Hello Charlie, 

	        >      the minor changes involve throwing out piggybacking
(which
>      in my opinion is a nice feature).
>
>      => This was discussed in detail, it's nice but not practical.
>      BW-constrained links (like cellular links) allocate set
>      channels based on the service, piggybacking the
>      BU _will_not_fit_ in the channel and the packet will
>      dropped ! That's not nice is it.
>      Non-BW-constrained links could not care less if
>      we piggyback or not.
> 

	        First, it was discussed in detail.  It's nice.  For some
applications
on some links, it's not practical.  For other applications on other
links, it is practical.  It's been implemented, tested, and it works. 

	        => I realise it was implemented and tested. My issue here
is that how does a MN know whether the CN receiving
the piggybacked BU will be negatively impacted by piggybacking ? 

	        Jari has mentioned this in a previous email but I'll quickly
mention
it again. A MN on a WLAN could be sending a BU to a CN
connected to a cellular link which was assigned a fixed channel
size. Because the BU was piggybacked, the entire packet
is dropped as it doesn't fit in the allocated channel.
Is there any solution to avoid this scenario ?
This is only one of the issues that were mentioned
against piggybacking. 

	        Hesham 


------_=_NextPart_001_01C15296.6D9CF720
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=918523320-11102001>Hey 
Hesham,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=918523320-11102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=918523320-11102001>I 
guess people just don't agree on the value of piggybacking, the affect of delays 
incurred by segmentation and whether the access network should drive the&nbsp;IP 
definitions or the access networks should adapt to the IP definitions. 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=918523320-11102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=918523320-11102001>The 
last time I got involved in this piggyback discussion it got very messy and so I 
think I'll refrain from further discussion for now.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=918523320-11102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=918523320-11102001>I do 
want to commend Jari for taking the time and effort to produce what I consider a 
fairly unbiased&nbsp;BU security draft in record time.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=918523320-11102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=918523320-11102001>Best 
wishes,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=918523320-11102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=918523320-11102001>Glenn</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hesham Soliman (EPA) 
  [mailto:Hesham.Soliman@ericsson.com.au]<BR><B>Sent:</B> Wednesday, October 10, 
  2001 8:29 PM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> 
  RE: [mobile-ip] MIPv6 - Focus of the security 
  discussion<BR><BR></DIV></FONT><BR>
  <UL>
    <P><FONT color=#0000ff face=Arial size=2>Hi Glenn, </FONT><BR><FONT 
    face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial size=2>Not that 
    this is the particular place for this discussion but it seems that 
    limitations of specific access technologies have again emerged into the 
    requirements of this IETF WG. </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; Probably not the right place 
    but we can try till the chairs tell us to stop :)</FONT> <BR><FONT 
    face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial size=2>Have you 
    explored sending the piggybacked packets over something like - say, the MAC 
    representation of the signaling PDP context?</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; I don't get that, could you 
    elaborate a bit ?</FONT><FONT face=Arial> </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>It seems that this multiplexing 
    could be accomplished quite easily via some ROHC middle box?</FONT> 
    <BR><FONT face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>I, for one, don't see much of a problem with some miniscule delay on 
    one single packet during a handoff of a mobile to mobile or mobile to cable 
    voice call - even if something like the signaling PDP context is not 
    used.</FONT></P>
    <P><FONT face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>Dropping the packet is probably worse than some miniscule 
    segmentation delay on one packet.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; I'm not sure that it's a 
    miniscule delay at all. The delay will probably be doubled.</FONT> <BR><FONT 
    color=#0000ff face=Arial size=2>If one packet fits nicely in the radio 
    frame, and the extra bytes</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>take it beyond that frame, then it is likely that the delay will at 
    least be doubled</FONT> <BR><FONT color=#0000ff face=Arial size=2>(I'm 
    clearly considering the delays over the air whichh are the major portion of 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>the RTT delay in a cellular 
    network). </FONT><BR><FONT color=#0000ff face=Arial size=2>Now for a real 
    time application, this delay is just as good as dropping the 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>packet. Have I missed 
    something ?</FONT> <BR><FONT face=Arial>&nbsp;</FONT> <BR><FONT 
    color=#0000ff face=Arial size=2>I could see creating some new form of 
    generic authentication/encryption header that could be used for integrity 
    and confidentiality of any set of IP options and used in conjunction with 
    existing IPSEC headers for the applications; but based upon the timeliness 
    of such work and cross WG controversy involved in this, it seems that the 
    logical and expedient solution specified in the existing draft makes the 
    best sense at this particular point in time. I don't mind if someone 
    suggests such as thing but I don't think it should hamper the existing MIPv6 
    proposal which does solve the problem.</FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; This is an orthogonal issue 
    to piggybacking IMHO. The current </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>soution in the draft doesn't solve the problems we're discussing. 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>Obviously this new 
    susboption will not be compressed by </FONT><BR><FONT color=#0000ff 
    face=Arial size=2>ROHC, s the extra bytes are still there. </FONT><BR><FONT 
    face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial size=2>As far a 
    creating a new header specifically for BU, I don't see how that would solve 
    much of anything. Again, I don't mind if someone suggests such as thing but 
    I don't think it should hamper the acceptance of the existing MIPv6 
    proposal.</FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt;</FONT>&nbsp;<FONT face=Arial> 
    </FONT><FONT color=#0000ff face=Arial size=2>Again this is another (a third 
    issues). This was suggested for </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>allowing IPsec to protect the BUs. Have a look at Jari's 
    draft.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>Hesham</FONT> </P>
    <UL>
      <P><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
      Hesham Soliman (EPA) [</FONT><U><FONT color=#0000ff face=Tahoma size=2><A 
      href="mailto:Hesham.Soliman@ericsson.com.au">mailto:Hesham.Soliman@ericsson.com.au</A></FONT></U><FONT 
      face=Tahoma size=2>]<BR></FONT><B><FONT face=Tahoma 
      size=2>Sent:</FONT></B><FONT face=Tahoma size=2> Wednesday, October 10, 
      2001 12:56 AM<BR></FONT><B><FONT face=Tahoma size=2>To:</FONT></B><FONT 
      face=Tahoma size=2> 'mobile-ip@sunroof.eng.sun.com'<BR></FONT><B><FONT 
      face=Tahoma size=2>Subject:</FONT></B><FONT face=Tahoma size=2> RE: 
      [mobile-ip] MIPv6 - Focus of the security 
discussion<BR><BR></FONT></P><BR>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#0000ff 
      face=Arial size=2>Hello Charlie,</FONT> </P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the minor changes involve 
      throwing out piggybacking (which</FONT><FONT face=Arial><BR></FONT><FONT 
      face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in my opinion is a 
      nice feature).</FONT><FONT face=Arial><BR></FONT><FONT face=Arial 
      size=2>&gt;</FONT><FONT face=Arial><BR></FONT><FONT face=Arial 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; This was discussed in 
      detail, it's nice but not practical.</FONT><FONT 
      face=Arial><BR></FONT><FONT face=Arial 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BW-constrained links (like 
      cellular links) allocate set</FONT><FONT face=Arial><BR></FONT><FONT 
      face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; channels based on the 
      service, piggybacking the</FONT><FONT face=Arial><BR></FONT><FONT 
      face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BU _will_not_fit_ in 
      the channel and the packet will</FONT><FONT face=Arial><BR></FONT><FONT 
      face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dropped ! That's not 
      nice is it.</FONT><FONT face=Arial><BR></FONT><FONT face=Arial 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Non-BW-constrained links could 
      not care less if</FONT><FONT face=Arial><BR></FONT><FONT face=Arial 
      size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we piggyback or not.</FONT><FONT 
      face=Arial><BR></FONT><FONT face=Arial size=2>&gt;</FONT><FONT face=Arial> 
      </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
      size=2>First, it was discussed in detail.&nbsp; It's nice.&nbsp; For some 
      applications</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>on 
      some links, it's not practical.&nbsp; For other applications on 
      other</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>links, it 
      is practical.&nbsp; It's been implemented, tested, and it 
      works.</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#0000ff 
      face=Arial size=2>=&gt; I realise it was implemented and tested. My issue 
      here</FONT><BR><FONT color=#0000ff face=Arial size=2>is that how does a MN 
      know whether the CN receiving</FONT><BR><FONT color=#0000ff face=Arial 
      size=2>the piggybacked BU will be negatively impacted by piggybacking 
      ?</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#0000ff 
      face=Arial size=2>Jari has mentioned this in a previous email but I'll 
      quickly mention</FONT><FONT face=Arial><BR></FONT><FONT color=#0000ff 
      face=Arial size=2>it again. A MN on a WLAN could be sending a BU to a 
      CN</FONT><FONT face=Arial><BR></FONT><FONT color=#0000ff face=Arial 
      size=2>connected to a cellular link which was assigned a fixed 
      channel</FONT><FONT face=Arial><BR></FONT><FONT color=#0000ff face=Arial 
      size=2>size. Because the BU was piggybacked, the entire packet</FONT><FONT 
      face=Arial><BR></FONT><FONT color=#0000ff face=Arial size=2>is dropped as 
      it doesn't fit in the allocated channel.</FONT><BR><FONT color=#0000ff 
      face=Arial size=2>Is there any solution to avoid this scenario 
      ?</FONT><BR><FONT color=#0000ff face=Arial size=2>This is only one of the 
      issues that were mentioned</FONT><FONT face=Arial><BR></FONT><FONT 
      color=#0000ff face=Arial size=2>against piggybacking.</FONT> </P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#0000ff 
      face=Arial size=2>Hesham</FONT><FONT face=Arial> 
</FONT></P></UL></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15296.6D9CF720--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 17:06:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25466
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:06:03 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11149;
	Thu, 11 Oct 2001 14:05:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13134;
	Thu, 11 Oct 2001 14:04:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BKuCML009458
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:56:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BKuCjC009457
	for mobile-ip-dist; Thu, 11 Oct 2001 13:56:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BKu8ML009450
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:56:08 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03989
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:56:11 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28497
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:57:21 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA13112
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:56:09 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BKu8U13011
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:56:08 -0700
X-mProtect:  Thu, 11 Oct 2001 13:56:08 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdxZeJsf; Thu, 11 Oct 2001 13:56:05 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA09600 for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 13:56:05 -0700 (PDT)
Message-ID: <3BC60765.69B8B9C2@iprg.nokia.com>
Date: Thu, 11 Oct 2001 13:56:05 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Pine.LNX.4.33.0110112229220.25674-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> > > Also, RFC2460 seems ignorant of IPv6 firewalls/packet filters which most
> > > assuredly would like to process upto e.g. TCP header, therefore also
> > > noticing an unknown header type.  The expected behaviour can be quickly
> > > deduced though.
> >
> > This is also a bit tricky: If FWs follow RFC2460, corporate networks
> > cannot receive new binding updates, if we relax it on filtering rules,
> > they can (requires changing old strict-RFC2460 FW boxes), right?
> > So is this a requirement for change in case a new dst hdr type is
> > accepted?
> 
> As a matter of fact, to clarify, looking at RFC2460 4.2. and MIPv6 -14..
> 
> BU, BAck, HA, etc. are indeed Destination Options Header options, not
> extension headers (the interpretation under debate with ipng@ was about
> ext header processing IIRC), there is some hope for some of them at least.

Yes, depending on whether they are mandatory or optional in practice
(see below).
 
> If the option type begins with '00', the specified behaviour is to skip
> over the option and continue processing if the option was not recognized.
> 
> So it would appear:
> 
> BU: 198 ==> whole packet dropped if the option is not recognized
> BAck: 7 ==> ok
> Breq: 8 ==> ok
> HA: 201 ==> whole packet dropped if the option is not recognized
> 
> How the firewalls would interpret this is up to the implementors, I
> suppose.

This is how things look in practice when universal support is missing.
Once new headers are introduced it is even harder to convince every box
to do this soon. Originally I guess it was thought every node is a CN
understanding BU and HA. Then, all the above would be accepted always,
the optimistic interpretations of having a MUST in a standard.

> I hope to be able to write an I-D about new challenges of IPv6
> for firewall/packet filter implementors at some point, unless there's
> already some work going on on the subject.

This would be of interest to many people, especially if components
of IPv6 such as moblity much longer are in flux. Also, given that routers
(by practical meaning of the term, not by RFC2460 definition..) should
allow for future extendibility of IPv6, more generic rules how to
cope with optional, or MUST extensions not yet such in practice,
would be good to have.

> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 17:17:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25730
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 17:17:27 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04930;
	Thu, 11 Oct 2001 15:16:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29893;
	Thu, 11 Oct 2001 14:16:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BL75ML009626
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:07:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BL75is009625
	for mobile-ip-dist; Thu, 11 Oct 2001 14:07:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BL71ML009615
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:07:01 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13926
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:07:04 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04684
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:08:14 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA14005
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:07:00 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BL6xI05787
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:06:59 -0700
X-mProtect:  Thu, 11 Oct 2001 14:06:59 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdGt1nyg; Thu, 11 Oct 2001 14:06:58 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA09614 for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:06:58 -0700 (PDT)
Message-ID: <3BC609F2.D6ACF8A6@iprg.nokia.com>
Date: Thu, 11 Oct 2001 14:06:58 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
		<3BC5DBBD.1548E5B4@iprg.nokia.com> <15301.56952.774758.130701@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Uh, this is an interesting discussion and all, but
> nobody's recommending that we have a new
> intermediate header. The BU would be the final
> header, and could just as easily be on a well
> known UDP port instead of a new protocol number.

I believe this would make it practically impossible to
even consider piggybacking. At least with UDP, you can't
have two upper layers (if by UDP port you mean inserting
a UDP hdr). I believe the potential new header should be
intermediate, and after a routing header. Even better if
no new header would be needed.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 17:40:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26203
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 17:40:27 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26959;
	Thu, 11 Oct 2001 15:39:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06668;
	Thu, 11 Oct 2001 14:39:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BLUhML009789
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:30:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BLUgKg009788
	for mobile-ip-dist; Thu, 11 Oct 2001 14:30:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BLUdML009781
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:30:39 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00513
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:30:40 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18641
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:31:52 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9BLSSC05144
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 14:28:30 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABN11608;
	Thu, 11 Oct 2001 14:30:13 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA06205; Thu, 11 Oct 2001 14:30:13 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15302.3941.78567.628465@thomasm-u1.cisco.com>
Date: Thu, 11 Oct 2001 14:30:13 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
In-Reply-To: <3BC609F2.D6ACF8A6@iprg.nokia.com>
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
	<3BC5DBBD.1548E5B4@iprg.nokia.com>
	<15301.56952.774758.130701@thomasm-u1.cisco.com>
	<3BC609F2.D6ACF8A6@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > Michael Thomas wrote:
 > > 
 > > Uh, this is an interesting discussion and all, but
 > > nobody's recommending that we have a new
 > > intermediate header. The BU would be the final
 > > header, and could just as easily be on a well
 > > known UDP port instead of a new protocol number.
 > 
 > I believe this would make it practically impossible to
 > even consider piggybacking. At least with UDP, you can't
 > have two upper layers (if by UDP port you mean inserting
 > a UDP hdr). I believe the potential new header should be
 > intermediate, and after a routing header. Even better if
 > no new header would be needed.

This entire discussion started because you said
there was a problem with a new protocol type being
proposed to allow use of IPsec. The proposal was
to eliminate piggybacking too, mainly because RFC
2401 doesn't have the ability to deal with options
as part of the selector mechanism. Thus this
entire discussion is moot.

		     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 18:36:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27736
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 18:36:43 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20802;
	Thu, 11 Oct 2001 15:35:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21314;
	Thu, 11 Oct 2001 15:35:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BMQqML009946
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:26:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BMQqtO009945
	for mobile-ip-dist; Thu, 11 Oct 2001 15:26:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BMQmML009938
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:26:48 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19003
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:26:46 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23106
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:26:49 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA21208
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:26:49 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9BMQnf29444
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:26:49 -0700
X-mProtect:  Thu, 11 Oct 2001 15:26:49 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdKjYqCC; Thu, 11 Oct 2001 15:26:47 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id PAA09702 for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:26:47 -0700 (PDT)
Message-ID: <3BC61CA7.73D3D6F4@iprg.nokia.com>
Date: Thu, 11 Oct 2001 15:26:47 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
		<3BC5DBBD.1548E5B4@iprg.nokia.com>
		<15301.56952.774758.130701@thomasm-u1.cisco.com>
		<3BC609F2.D6ACF8A6@iprg.nokia.com> <15302.3941.78567.628465@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Jari T. Malinen writes:
>  > Michael Thomas wrote:
>  > >
>  > > Uh, this is an interesting discussion and all, but
>  > > nobody's recommending that we have a new
>  > > intermediate header. The BU would be the final
>  > > header, and could just as easily be on a well
>  > > known UDP port instead of a new protocol number.
>  >
>  > I believe this would make it practically impossible to
>  > even consider piggybacking. At least with UDP, you can't
>  > have two upper layers (if by UDP port you mean inserting
>  > a UDP hdr). I believe the potential new header should be
>  > intermediate, and after a routing header. Even better if
>  > no new header would be needed.
> 
> This entire discussion started because you said
> there was a problem with a new protocol type being
> proposed to allow use of IPsec. The proposal was
> to eliminate piggybacking too, mainly because RFC
> 2401 doesn't have the ability to deal with options
> as part of the selector mechanism. Thus this
> entire discussion is moot.

Let us call "problem" as some requirements for change introduced.
For hosts they undisputably exist, for routers, excluding
firewalls, maybe not. Introducing new headers may require some
discussion in the ipv6 wg, though.
I believe Jari Arkko did a nice work outlining 4 alternative
ways of protecting the BU. All of them do not call for the
removal of piggybacking, nor for the addition of a new hdr.
And if one adds a header, why design it so that piggybacking
becomes impossible if a more flexible design is possible.
But, maybe it is good stop discussing it here, I am sure
we will still hear enoug of this from implementors etc.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 19:07:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28215
	for <mobileip-archive@lists.ietf.org>; Thu, 11 Oct 2001 19:07:20 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02556;
	Thu, 11 Oct 2001 16:06:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07241;
	Thu, 11 Oct 2001 16:06:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BMwDML010067
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:58:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BMwDDB010066
	for mobile-ip-dist; Thu, 11 Oct 2001 15:58:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BMwAML010059
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:58:10 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05081
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 15:58:11 -0700 (PDT)
Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28062
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 16:58:00 -0600 (MDT)
Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP
	id 574AC5D015; Fri, 12 Oct 2001 07:58:09 +0900 (JST)
Date: Fri, 12 Oct 2001 07:57:40 +0900 (JST)
Message-Id: <20011012.075740.68539035.ryuji@sfc.wide.ad.jp>
To: mobile-ip@sunroof.eng.sun.com, mattias.pettersson@era.ericsson.se
Cc: mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
In-Reply-To: <3BC204D4.21A103A5@era.ericsson.se>
References: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr>
	<m34rpdhlxe.fsf@test9.crm.mot.com>
	<3BC204D4.21A103A5@era.ericsson.se>
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Mattias.

I guess the detail of implementation may not be an appropriate issue
in this ML, but I want to make our implementation points clear. 
sorry about that.

> I had a look at your code Ryuji, and I thought that home addresses are
> assigned to a special virtual interface called mobileipxx. Care-of

Yes, I prepared the virtual network interface to support multiple network 
interfaces/CoAs with single home address.

> addresses can be assigned to multiple physical interfaces, and they can
> have different characteristics. Each home address can use any CoA it
> prefers at any time. However, there is not much use really to have
> multiple home addresses, unless the home network is being renumbered.

Maybe, but supporting multiple home addresses is not the exact our
main purpose for using the virtual network interface. 
I summarize the idea below.

If the home address is assigned to the real network interfaces, MIP6 can
not handle multiple IFs/CoAs simultaneously. 
I believe that using virtual network interface is the ideal design 
for this purpose on the UNIX.

Our implementation.

	mobileip (virutal)	
	 Homeaddr
	   |
   +--------------+
   |		  |
   ep		  wlp	(physical)
   CoA1		  CoA2	

   MIP6 can use both network interfaces simultaneously, 
   whenever they are available.

Your implementation.

   +-------------+
   |		 |   
   ep		wlp    (physical)
   CoA1		CoA2
   Homeaddr

   Where can you put the home address
   when multiple IFs are available at the same time?

regards,
ryuji




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 21:07:27 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00012
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 21:07:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10259;
	Thu, 11 Oct 2001 19:07:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16900;
	Thu, 11 Oct 2001 18:07:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C16AML010389
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 18:06:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9C16AxV010388
	for mobile-ip-dist; Thu, 11 Oct 2001 18:06:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C164ML010373
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 18:06:05 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22897
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 18:06:04 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01008
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 18:06:07 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9C16Lu14496
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 18:06:21 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABN17625;
	Thu, 11 Oct 2001 18:05:51 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA06220; Thu, 11 Oct 2001 18:05:50 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15302.16878.224113.877607@thomasm-u1.cisco.com>
Date: Thu, 11 Oct 2001 18:05:50 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
In-Reply-To: <3BC61CA7.73D3D6F4@iprg.nokia.com>
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
	<3BC5DBBD.1548E5B4@iprg.nokia.com>
	<15301.56952.774758.130701@thomasm-u1.cisco.com>
	<3BC609F2.D6ACF8A6@iprg.nokia.com>
	<15302.3941.78567.628465@thomasm-u1.cisco.com>
	<3BC61CA7.73D3D6F4@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > I believe Jari Arkko did a nice work outlining 4 alternative
 > ways of protecting the BU. All of them do not call for the
 > removal of piggybacking, []

   The primary reason the analysis of piggybacking is in
   there is because removal of piggybacking is what is
   necessary to make IPsec work. Hence, this entire 
   discussion is moot because nobody's talking about
   creating a new middle header.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 22:08:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01744
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 22:08:16 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06013;
	Thu, 11 Oct 2001 20:07:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14681;
	Thu, 11 Oct 2001 19:07:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C26UML010677
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:06:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9C26Tti010676
	for mobile-ip-dist; Thu, 11 Oct 2001 19:06:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C26QML010669
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:06:26 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25329
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:06:27 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA15722
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 20:07:41 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA06197
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:06:26 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9C26PQ25182
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:06:25 -0700
X-mProtect:  Thu, 11 Oct 2001 19:06:25 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdxauceL; Thu, 11 Oct 2001 19:06:24 PDT
Message-ID: <3BC65021.E38A8774@iprg.nokia.com>
Date: Thu, 11 Oct 2001 19:06:25 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
	 <15300.33271.335089.998138@thomasm-u1.cisco.com>
	 <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com> <4.3.2.7.2.20011011140647.050084c0@mira-sjc5-9.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Michael,

thanks for clarifying. I have some clarifications as well.

- a *compressor* resides in IR/FO/SO states, not a *link*.
- similarly, a decompressor has either no context, static context or full context.

- compression is limited to IP and transport protocol headers. So, once you do
ip_output, the HC engine works on IP and transport headers before the device
driver output occurs. Nowhere in this *compression process*, the link layer itself
comes into play.

It turns out that Compressor-1 (on L1) need not know in which state Compressor-2
(on L3) is before sending a piggybacked BU. Consider the following two cases.
First, the compressor on L3 would be in an IR state if it has never initialized a
context for this stream or there has been a pathological failure of an existing
context. Note that once a compressor determines that the decompressor has Full
Context, it must not transition to the IR state unless there is an irrepairable
context. It should be in FO, SO, or IR-DYN states, all of which have enough room
to include additional bytes the size of a BU.

Second, if Compressor-2 _is in_ IR state when it receives a piggybacked BU, it
would have to be able to include the BU as part of initialization, just as it
should be able to handle any IPv6 extension header. I believe 3095 specifies how
to handle the extension headers.

So, in summary, the chances of Compressor-2 being in the IR state when a
piggybacked BU is received should be small. However, if it is indeed in the
IR state, it should not matter.

Regards,

-Rajeev





"Michael A. Ramalho" wrote:

> Rajeev,
>
> Another volley to make myself more clear. You have my point
> *almost* correct.
>
> Comments in line.
>
> Michael Ramalho
>
> At 10:44 AM 10/11/2001 -0700, you wrote:
> >Hello Michael,
> >
> >interesting point. However, even with link-by-link compression I think it will
> >still work.
> >
> >Here is your scenario:
> >
> >1) MN1 sends a compressed packet with piggybacked BU to AR. The AR
> >decompresses the packet on the received link.
> >
> >2) AR sends compressed packet with piggybacked BU to MN2 on another link.
> >
> >
> >Your point is you may not have enough capacity to do 2) above, right ?
>
> Yes ... I'll explain in line below.
>
> >Well, I think header compression has this predictability property. If you
> >compress a packet, decompress it and compress it again, the compression gain
> >should be the same! In other words,
> >
> >let H be the total header size.
> >    1.   X = compress[H]
> >    2.   H = decompress[X]
> >           goto 1.
> >
> >In the second iteration, value of X should be the same as in the first
> >iteration.
>
> One hopes that the "predictability property" is always true.
>
> But ... links make the compression decision independently
> (as I previously stated).
>
> Consider three links (to make it simple), L1 -> L2 -> L3.
>
> Lets say, without loss of generality, that L1 and L3 are the
> links to the mobile nodes AND lets say that L2 *does not
> use compression*.
>
> That is the compression state of L1 is *INDEPENDENT OF
> THE COMPRESSION STATE* of link 3.
>
> Specifically ... your compressed BU sent on L1 (w/ FO or
> SO state on compressed link L1) is decompressed
> for transmission on L2.
>
> But how do you know a priori that L3 is *NOT IN IR STATE*
> when L3 gets it.
>
> The point is that you don't know this a priori - and therefore
> do not know if the BU will fit onto L3.
>
> It usually will ... as L3 hopes to be in FO or S0 state and
> obtaining compression ... but my point is that it is not
> guaranteed.
>
> Ordinarily I like it when the odds are with me in probabilistic sense,
> but this isn't an ordinary UDP voice packet (where I wouldn't
> mind an isolated loss) ... it has a BU piggybacked to it.
>
> So ... you need another email volley to convince me.
>
> >Regarding your other comment concerning BU persistence, you can re-transmit a
> >BU on a fresh real-time packet. You don't need to re-transmit the original
> >real-time packet itself.
>
> Interesting proposal ... and it is doable ... and it raises an interesting
> tradeoff and a question or two.
>
> Your proposal assumes that the link layer knew that there was an
> error ... and that it was smart enough to know that the packet was
> a real-time packet (and not attempt to retransmit it) AND smart enough
> to know that the BU it had piggybacked could be delayed until the
> next real-time packet (i.e., not immediately sent).
>
> Does the link layer always know when the next packet is supposed to
> arrive (for example, VoIP with VAD ... you don't know!)? I guess you
> could simply transmit the BU if the "expected packet" doesn't arrive
> in time (a timeout based on the expected interpacket arrival time of
> the real-time flow).
>
> But ... I hope this is moot ... since I had hoped to convince you that
> piggybacking on L1 may not be a good idea.
>
> If you are into building specialized link layers for outgoing BU's, I
> *could* be convinced that building a specialized link layer at the
> L1 decompressor that ALWAYS de-biggybacked a BU which was
> sent over L1 could be designed. This would localize the effect of
> the piggybacking only to a given link. But since I have not given the
> idea full thought ... you would need to work on me a little more :-).
>
> Regards,
>
> Michael Ramalho
>
> >Regards,
> >
> >-Rajeev
> >
> >ps. no comments regarding BETH.
>
> opps .. :-)
>
> >"Michael A. Ramalho" wrote:
> >
> > > At 11:02 AM 10/10/2001 -0700, Rajeev Koodli wrote:
> > > >Michael Thomas wrote:
> > > >
> > > > > Mohan Parthasarathy writes:
> > > > >  > I don't understand why this problem is specific to binding updates.
> > > > >  > Are you saying that under such a reservation, the packet size can't
> > > > >  > vary at all ? If I have been sending 1000 bytes, which is way less
> > > > >  > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
> > > > >  > a tight channel is reserved there should be indication to IP to
> > > > >  > change its MTU value so that path mtu discovery can kick in.
> > > > >
> > > > >    Yup, that's the problem. It really has nothing to do
> > > > >    with MTU; it's about keeping within the constraint of
> > > > >    a reservation. MTU is link based, not flow based afterall.
> > > > >
> > > >
> > > >It is not entirely accurate to say that you cannot piggyback when using a
> > > >dedicated channel. For instance, it is well-known that header compression
> > > >gain can vary from packet to packet, thus affecting the compressor states.
> > > >In a dedicated channel, which is what this thread is focussing on
> > > >I assume, in order to accommodate `header bursts', you need to reserve for
> > > >the worst-case. Now, IF that's the case, piggybacking a BU does not
> > > >necessarily violate the reservation, since, I could piggyback a BU on  FO
> > > >or SO packets (which have better compression gain compared to a packet
> > > >with no compression gain). The BU length, assuming 12 bytes for
> > > >Authentication Data, is 26 bytes compared to 40 bytes for IPv6 header
> > > >alone. So, when IPv6 header is not present, as would be the case in a SO
> > > >or FO packet, you _can_ piggyback, even in the so-called dedicated
> > > >channels.
> > >
> > > Rajeev,
> > >
> > > Sounds like you are only considering one side here - the MN sending.
> > >
> > > Assuming you are using link-by-link compression ... consider the
> > > case where the "other end" is also a MN that can receive and send
> > > "piggybacked" BUs AND is using a similar header compression scheme.
> > > This is a legitimate, if not increasingly prevalent, case.
> > >
> > > Unfortunately ... you won't know (on the sending link) which packets
> > > will have headers compressed on the "far-end" link ... as each link
> > > can compress headers independently.
> > >
> > > Thus, although you know when it is "safe" to piggyback on the
> > > sending MN link ... you won't know whether the resulting packet
> > > will fit into the "far end" MN link.
> > >
> > > So ... I strongly disagree ... you really don't know when it is safe to
> > > add a BU to the (real-time, TDM constrained) flow!
> > >
> > > Seems to me that you really should not be piggybacking BUs
> > > without BOTH ENDS agreeing that this is OK.
> > >
> > > Not piggybacking is OK as long as you have something like BETH
> > > anyway. If the BU takes a little longer to get where it is going, BETH
> > > should take care of the problem.
> > >
> > > Additionally you probably desire some form of over-the-air persistence
> > > on the (non ultra-delay-sensitive) BU (i.e., a re-transmission) ... and
> > > probably don't desire the re-transmission of the real-time packet.
> > >
> > > So ... my vote would be for allowing piggybacked BUs only when
> > > both ends say OK. OK?
> > >
> > > Comments?
> > >
> > > Michael Ramalho
> > >
> > > >Regards,
> > > >
> > > >-Rajeev
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >         Mike
> > >
> > > Michael A. Ramalho, Ph.D.
> > > Office email: mramalho@cisco.com
> > > Personal email: mar42@cornell.edu
> > > Office: +1.732.449.5762
> > > Cell: +1.732.809.0188
>
> Michael A. Ramalho, Ph.D.
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 11 22:13:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01798
	for <mobileip-archive@odin.ietf.org>; Thu, 11 Oct 2001 22:13:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21752;
	Thu, 11 Oct 2001 19:13:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25989;
	Thu, 11 Oct 2001 19:13:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C2CZML010775
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:12:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9C2CYdu010774
	for mobile-ip-dist; Thu, 11 Oct 2001 19:12:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C2CUML010767
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:12:31 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01039
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:12:29 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA17651
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 20:13:45 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA06892
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:12:31 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9C2CU232721
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:12:30 -0700
X-mProtect:  Thu, 11 Oct 2001 19:12:30 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdVkVEwa; Thu, 11 Oct 2001 19:12:29 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id TAA09935 for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 19:12:29 -0700 (PDT)
Message-ID: <3BC6518D.8B4E2076@iprg.nokia.com>
Date: Thu, 11 Oct 2001 19:12:29 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
		<3BC5DBBD.1548E5B4@iprg.nokia.com>
		<15301.56952.774758.130701@thomasm-u1.cisco.com>
		<3BC609F2.D6ACF8A6@iprg.nokia.com>
		<15302.3941.78567.628465@thomasm-u1.cisco.com>
		<3BC61CA7.73D3D6F4@iprg.nokia.com> <15302.16878.224113.877607@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Jari T. Malinen writes:
>  > I believe Jari Arkko did a nice work outlining 4 alternative
>  > ways of protecting the BU. All of them do not call for the
>  > removal of piggybacking, []
> 
>    The primary reason the analysis of piggybacking is in
>    there is because removal of piggybacking is what is
>    necessary to make IPsec work. Hence, this entire
>    discussion is moot because nobody's talking about
>    creating a new middle header.

For alternative 4 one could imagine a variant with piggybacking
and IPsec mutually exclusive. New hdr type for the selector problem,
middle header to enable piggybacking when using application specific
protection.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 03:28:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20129
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 03:28:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA19533;
	Fri, 12 Oct 2001 00:28:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25015;
	Fri, 12 Oct 2001 00:27:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C7R4ML011209
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:27:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9C7R35K011208
	for mobile-ip-dist; Fri, 12 Oct 2001 00:27:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C7R0ML011201
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:27:00 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01428
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:26:59 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04344
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 01:28:15 -0600 (MDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id AAA01521 for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:27:00 -0700 (MST)]
Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id AAA24855 for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:27:00 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 12 Oct 2001 02:26:59 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP id DE6C22ED2F
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 09:22:46 +0200 (CEST)
X-Gnus-Agent-Meta-Information: mail nil
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multi-homing MIPv6???
References: <0DF9FBC42474A24CA50F7A27FB08E0486165CC@meshpdc.meshnetworks.com>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 11 Oct 2001 22:25:33 +0200
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0486165CC@meshpdc.meshnetworks.com>
Message-Id: <m3n12x7wle.fsf@test9.crm.mot.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
Lines: 27
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Phillip Neumiller <PNeumiller@MeshNetworks.com> writes:
> There is another case, at least for some of us trying to get
> mobile routers working properly and that is multiple interfaces,
> routing multi-homed clients and the router itself being
> multi-homed!

Ah, did I read mobile router :-)?  There was a long thread right after
London IETF about MR's.  If I remember correctly someone separated
multihoming from mobile routers.  Also, there was discussion on
authentication issues with MR's prefixes.

> Home 1    Home 2
> |          |
> MR1--------.
> |    
> |    MR2----> Other homes.
> |     |
> |-----.
> MN
> 
> Perhaps this is a bit too weird to be practical???

Depends what you consider Home1, 2 and Other Homes to be.  Are they
some kind of public wireless Internet providers?  What's the most
likely embodiment of the subnet between MR1 and MR2?

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 03:29:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20146
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 03:29:15 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13438;
	Fri, 12 Oct 2001 01:28:49 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25177;
	Fri, 12 Oct 2001 00:28:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C7S6ML011226
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:28:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9C7S630011225
	for mobile-ip-dist; Fri, 12 Oct 2001 00:28:06 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C7S0ML011218
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:28:01 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25057
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:28:03 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12856
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 01:27:51 -0600 (MDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id AAA02367 for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:28:02 -0700 (MST)]
Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id AAA18283 for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 00:19:04 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Fri, 12 Oct 2001 02:28:00 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id E61FE2ED3C; Fri, 12 Oct 2001 09:23:47 +0200 (CEST)
X-Gnus-Agent-Meta-Information: mail nil
To: mobile-ip@sunroof.eng.sun.com
Cc: Jari Arkko <jari.arkko@piuha.net>
Subject: [mobile-ip] More comments on BAKE
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 11 Oct 2001 22:53:29 +0200
Message-Id: <m33d4p7vau.fsf@test9.crm.mot.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
Lines: 20
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi,

I'm aware that proposals are about to be compared against the
requirements draft (Gabriel?); the following comments are just in case
that BAKE will be found to fit these requirements.

draft-perkins-bake-01.txt

N1 should be related to the CoA.  Same N1 should not be used with
subsequent CoA's.

On line 541
    -  Allows initation by the correspondent node.
              initiation

On line 1114
      MN->CN: < CoA, CNA, HoA, T0, T2, N_BK >
      MN->CN: < CoA, CNA, HoA, T0, T2, N_BK, N1 >

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 06:05:23 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20974
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 06:05:23 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05553;
	Fri, 12 Oct 2001 04:05:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29556;
	Fri, 12 Oct 2001 03:04:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CA3hML011546
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 03:03:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CA3hxI011545
	for mobile-ip-dist; Fri, 12 Oct 2001 03:03:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CA3dML011538;
	Fri, 12 Oct 2001 03:03:39 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29426;
	Fri, 12 Oct 2001 03:03:40 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04747;
	Fri, 12 Oct 2001 04:03:22 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9CA3Ti05863;
	Fri, 12 Oct 2001 13:03:29 +0300
Date: Fri, 12 Oct 2001 13:03:29 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: <ipng@sunroof.eng.sun.com>
Subject: [mobile-ip] IPv6 Routing Header, Home Address security draft
Message-ID: <Pine.LNX.4.33.0110121246260.5734-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hello folks,

(I think mobile-ip@ is probably the best place for possible follow-ups)

I've submitted the following "Informational-nature" draft to
internet-drafts:

"Security of IPv6 Routing Header and Home Address Options"
http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-ha-security-00.txt

This raises the concern, among others, on MIPv6-imposed requirements and
recommendations for _all_ IPv6 nodes.  Binding Updates is a different
problem, being discussed separately, and only RH and HA are covered.

It should be noted, of course, that there are very valid uses for routing
header outside of mobile ip too.  But MIPv6 imposes some requirements for
RH use, so it might be better to restrict its use in some way or another.

The abstract:

   All IPv6 nodes must be able to process Routing Header [IPV6] and Home
   Address [MIPV6] Options.  With these, packet filter access lists can
   be tricked (among other things) as the destination and source
   addresses, respectively, are being rewritten as the packet traverses
   the network.  Some of the security considerations of these features
   are analyzed, and a few possible solutions presented.  It will be
   shown that with the current architecture, the network-based security
   does not seem to scale to the requirements of Mobile IPv6; it seems
   possible that unless security is taken seriously when implementing
   the nodes, the new Mobile IPv6 requirements might not be allowed to
   be used at all in some circumstances.

Comments welcome, of course.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 08:29:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23849
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 08:29:18 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16551;
	Fri, 12 Oct 2001 06:28:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00695;
	Fri, 12 Oct 2001 05:28:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CCS2ML011759
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 05:28:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CCS2gW011758
	for mobile-ip-dist; Fri, 12 Oct 2001 05:28:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CCRwML011751
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 05:27:58 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26629
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 05:28:00 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15795
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 06:27:48 -0600 (MDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9CCS1k20160
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 05:28:01 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn1-229.cisco.com [10.21.96.229])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABD42504;
	Fri, 12 Oct 2001 05:27:58 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011012073856.043c19c0@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 12 Oct 2001 08:26:03 -0400
To: mobile-ip@sunroof.eng.sun.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC65021.E38A8774@iprg.nokia.com>
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
 <15300.33271.335089.998138@thomasm-u1.cisco.com>
 <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com>
 <4.3.2.7.2.20011011140647.050084c0@mira-sjc5-9.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Rajeev,

One more time for further clarity. I think the discussion
moved off the original point. Comments in line.

Regards,

Michael Ramalho

At 07:06 PM 10/11/2001 -0700, Rajeev Koodli wrote:
>Hello Michael,
>
>thanks for clarifying. I have some clarifications as well.
>
>- a *compressor* resides in IR/FO/SO states, not a *link*.
>- similarly, a decompressor has either no context, static context or full 
>context.
>
>- compression is limited to IP and transport protocol headers. So, once you do
>ip_output, the HC engine works on IP and transport headers before the device
>driver output occurs. Nowhere in this *compression process*, the link 
>layer itself
>comes into play.
>
>It turns out that Compressor-1 (on L1) need not know in which state 
>Compressor-2
>(on L3) is before sending a piggybacked BU. Consider the following two cases.
>First, the compressor on L3 would be in an IR state if it has never 
>initialized a
>context for this stream or there has been a pathological failure of an 
>existing
>context. Note that once a compressor determines that the decompressor has Full
>Context, it must not transition to the IR state unless there is an 
>irrepairable
>context. It should be in FO, SO, or IR-DYN states, all of which have 
>enough room
>to include additional bytes the size of a BU.
>
>Second, if Compressor-2 _is in_ IR state when it receives a piggybacked BU, it
>would have to be able to include the BU as part of initialization, just as it
>should be able to handle any IPv6 extension header. I believe 3095 
>specifies how
>to handle the extension headers.

I have no doubt that the Compressor-2 knows how to do its job - it would
do it as you have said. That was never my point (hopefully I have proved that
I am cluefull on this issue and move on).

The issue that triggered this thread was that the outgoing packet with the
piggybacked BU could only fit on the outgoing link (L1) if ROHC was in
FO or SO - for the case of a QoS constrained, DOCSYS-like output link
(which effectively has packet length limitations due to the QoS granting
mechanisms used on the link).

I agreed with that ... but said you were forgetting about the link on the
other side.

On the other side ... you do *not* know the compression state ... and
do not know if the packet with the piggybacked BU will fit into the QoS
channel.

I have *no doubt* that ROHC knows what to do with a packet with
a piggybacked BU. My point is not about compression; but rather
on the point (Mike Thomas' actually) that the piggybacked packet
may be too large for other links as well.


>So, in summary, the chances of Compressor-2 being in the IR state when a
>piggybacked BU is received should be small. However, if it is indeed in the
>IR state, it should not matter.

Again, I have little doubt that the ROHC folks know how to handle this
case. The issue is whether a QoS link can handle the larger packet
created by a piggybacked BU.

>Regards,
>
>-Rajeev
>

Think for a moment what one is saving via a piggybacked BU.

One argument is that it is saving precious bandwidth - so piggybacking
is good.

However, this *ignores* the way QoS flows are provisioned. One
example - the one above with a QoS grant mechanism on a link - shows
that piggybacking can be detrimental. But it is far from the only example.

Most QoS provisioned flows are policed at the edge of a network to
fit within a certain TSPEC/RSPEC. Given the expected frequency of
BUs ... to all but the most tight policers (in time constant or in strict
bandwidth), this increase would be negligible. This is effectively your
"wiggle room" argument. But one could imagine some policers would
actually mark the packet for discard eligibility (the new DE bit) or drop
it if the packet was too long. This is exactly the *wrong* thing to happen
to the BU (and to the QoS flow, which did nothing wrong!).

If I (and people like Mike Thomas) have not convinced the group that
BU piggybacking has more downsides than are worth it ... we may
be forced into a bigger debate on the interaction of QoS and mobileip.

[do you really want to go here ...]

To give an example of the proposed further debate .... suppose that
a pair of hosts have a "session" between them with a multiplicity of
QoS flows associated with this session (e.g., a videoconference with
QoS only provisioned on the voice). Now you want to send a BU.
Which "QoS type" packet do you piggyback onto. If the link layer
is dumb (the usual case) ... choosing the next packet is the easiest
choice. But you don't know the next packet's QoS treatment. In this
scenario, I'd choose one of the "reliable, delay insensitive" channels
if I had a choice. I would *not* choose the voice QoS channel.

In general, choosing "what type" of packet to piggyback onto is
hard. If you simply choose the "next or present" packet - at best
you get the QoS of this flow - and at worst you effectively harm
the packet/flow (e.g., marking it DE) for the flow that wanted
premium treatment.

Until convinced otherwise ... I am not persuaded that BU piggybacking
benefits outweigh the potential downsides. And I have not even
exhausted thinking about the downside arguments yet.

Remember ... one can make the following argument as
well ... "given the expected frequency of the BUs, that the
bandwidth saved by piggybacking is also negligible".

I am attempting to be a realist here. Bandwidth savings (piggybacking)
is usually good ... unless it causes more pain than the savings is worth.

Best Regards,

Michael Ramalho


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 09:25:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26285
	for <mobileip-archive@lists.ietf.org>; Fri, 12 Oct 2001 09:25:45 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02897;
	Fri, 12 Oct 2001 06:25:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18161;
	Fri, 12 Oct 2001 06:25:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CDOQML011896
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 06:24:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CDOQi0011895
	for mobile-ip-dist; Fri, 12 Oct 2001 06:24:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CDOMML011888
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 06:24:22 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18043
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 06:24:25 -0700 (PDT)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21757
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:24:11 -0600 (MDT)
Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA07525;
	Fri, 12 Oct 2001 15:24:12 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <charliep@iprg.nokia.com>
Cc: <mobile-ip@sunroof.eng.sun.com>, "Phil Roberts" <PRoberts@MEGISTO.com>
Subject: RE: [mobile-ip] IESG feedback on AAA keys doc
Date: Fri, 12 Oct 2001 15:24:42 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKGEDPDIAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3BC5CEA1.55B811CA@iprg.nokia.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Charlie,

I agree that not specifying a specific MIP table would be the best.
However, the IPsec DOI doesn't support md5 prefix/suffix mode, can 
we get ride of this?

If so, we can probably use the IPsec DOI as a normative reference

/Fredrik

>
>
>Hello Fredrik,
>
>Some minor clarification here, and follow-on comments.
>Plus, a solution may be available, thanks to some mail from
>Phil Roberts.
>
>> How do you mean when you say allocate new numbers in the IKE 
>table? do you
>> mean reuse the numbers already specified for these algorithms in 
>some other
>> table or to use another table and just specify that table in this draft.
>
>I meant the latter.
>
>> I believe that by having a table in the aaa-key draft we can 
>easier prohibit
>> some algorithms to be used (e.g. if they are considered unsecure, btw,
>> is md5-pre/suff considered safe? or should/can we remove it?) On 
>the other
>> hand it's harder to add new algorithms and it's yet another 
>table to maintain.
>> I'm not realy sure what's best.
>
>On general principles, with everything else being equal, I would always
>prefer to use a pre-existing table.  This is even more true when the
>items to be tabulated are properly in the domain of another working group.
>However, in this case, not everything else is equal:
>- The tabulation has to include HMAC-MD5, since that is mandated
>- The tabulation has to be "live", which means that it's a table
>  which has not been obsoleted for some reason.
>- There has to be some reasonable expectation that as our needs
>  change, the table can be updated
>
>The original table I found was in:
>	http://www.iana.org/assignments/ipsec-registry
>It does not have HMAC-MD5.
>
>Phil pointed me to tables in IANA's registry for ISAKMP:
>	http://www.iana.org/assignments/isakmp-registry
>Turns out there are _two_ relevant tables there.
>One is a list of "Transform ID"s for AH:
>
>==================================================================
>
>Transform ID            Value                           Reference
>------------            -----                           ---------
>RESERVED                0-1                             [RFC2407]
>AH_MD5                  2                               [RFC2407]
>AH_SHA                  3                               [RFC2407]
>AH_DES                  4                               [RFC2407]
>AH_SHA2-256             5                                 [Leech] 
>AH_SHA2-384             6                                 [Leech]
>AH_SHA2-512             7                                 [Leech]
>AH_RIPEMD               8                               [RFC2857]
>
>==================================================================
>
>That does not have HMAC-MD5.
>
>The other table at the same URL is a list of Authentication
>Algorithms allowable as values for the "Attribute Type" (5)
>(i.e., "Authentication Algorithm").  Type (5) is one of the
>classifications in the tabulated Attribute Types for
>"IPSEC Security Association Attributes".
>
>=================================================================
>
>  Authentication Algorithm
>
>        Name            Value                   Reference
>        ----            -----                   ---------
>        Reserved        0                       [RFC2407]       
>        HMAC-MD5        1                       [RFC2407]       
>        HMAC-SHA        2                       [RFC2407]       
>        DES-MAC         3                       [RFC2407]       
>        KPDK            4                       [RFC2407]       
>        HMAC-SHA2-256   5                         [Leech]
>        HMAC-SHA2-384   6                         [Leech]
>        HMAC-SHA2-512   7                         [Leech]
>        HMAC-RIPEMD     8                       [RFC2857]    
>
>=================================================================
>
>This table has HMAC-MD5.  I think that maybe it could also
>fulfill the other needs - basically for future extensibility
>and continued compatibility with the need for authenticating
>registration messages as part of the extensions in our document.
>
>My current suggestion is that we use this table, and delete the
>new table specification from within the AAA keys draft.  But, I am
>really neutral, and I only make the suggestion as a positive
>response to the IESG feedback which we have received.  I will
>happily do whatever others suggest here.
>
>In case this all seems to be tedious and hard to follow, my
>apologies.  I don't know how to make a clearer explanation.
>If anyone here knows why there are three different but seemingly
>related tables of the "same thing" (with different entries),
>I would be curious to know the answer.
>
>Regards,
>Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 09:57:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27857
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 09:57:33 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14738;
	Fri, 12 Oct 2001 07:57:10 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11595;
	Fri, 12 Oct 2001 06:57:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CDtHML012063
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 06:55:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CDtHQH012062
	for mobile-ip-dist; Fri, 12 Oct 2001 06:55:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CDtDML012055
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 06:55:13 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22328
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 06:55:14 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22221
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:56:24 -0600 (MDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9CDt7C22315
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:55:07 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Oct 12 15:55:06 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2KQVT6>; Fri, 12 Oct 2001 15:47:39 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320C5205A1@esealnt117>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] New version of Low Latency handoffs draft
Date: Fri, 12 Oct 2001 15:54:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hello all,

I've submitted a new version (02) of the Low Latency handoffs draft.
There are two major changes from 01:
- removal of bicasting as agreed in London (to be considered separately
  from low latency handoffs)
- POST-REG modified to include additions (HTT) proposed in London and
  other clarifications.
You can find the new version at:
http://standards.ericsson.net/karim/draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt

Cheers
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 10:03:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28172
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 10:03:48 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19692;
	Fri, 12 Oct 2001 08:03:15 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13163;
	Fri, 12 Oct 2001 07:03:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CE2SML012169
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:02:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CE2RnL012168
	for mobile-ip-dist; Fri, 12 Oct 2001 07:02:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CE2OML012161
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:02:24 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23588
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:02:24 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18793
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 08:02:11 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA22317
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 09:02:23 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 12 Oct 2001 08:55:29 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LY2V0>; Fri, 12 Oct 2001 09:01:42 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5D9EF3@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Requirements for non-MIPv6 implementations [MIPv6 - 
         Focus of thesecurity discussion]
Date: Fri, 12 Oct 2001 09:01:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15326.6B445EB0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15326.6B445EB0
Content-Type: text/plain;
	charset="iso-8859-1"

And even more clarification:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt


-----Original Message-----

Clarification: 
What I referred to below as DDOS redirection or bouncing is actually
referred to in the security requirements draft as "packet reflector"
-(Section 6.8: Threat H.3 and Scenario H.3. Sorry about the discontinuity in
terminology.
-----Original Message----- 
Charlie and Pekka, 
In relation to changing the BU processing to a MUST from a SHOULD for CN's: 


It just seems to me that some protection needs to be done even for the HA
option to prevent against DDOS redirect (bouncing) and that the solutions
that seem tenable (don't require that every packet is  authenticated)
require some sort of authorization and state table similar to a binding
cache in size, lookup structure etc.. 
So if the HA option is a MUST and we have to protect against this DOS
redirect (bounce) problem then it seems like you might as well go ahead and
make the binding update processing a MUST too and get the ubiquity of route
optimization for IPv6. The HA integrity appears to me to be almost the same
class of problem and solution set as the BU integrity.
Thanks, 
Glenn 

------_=_NextPart_001_01C15326.6B445EB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] Requirements for non-MIPv6 implementations =
[MIPv6 -  Focus of thesecurity discussion]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>And even more clarification:</FONT>
</P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-secu=
rity-00.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-savola-ipv6-=
rh-ha-security-00.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
</P>

<P><FONT SIZE=3D2>Clarification: </FONT>
<BR><FONT SIZE=3D2>What I referred to below as DDOS redirection or =
bouncing is actually referred to in the security requirements draft as =
&quot;packet reflector&quot; -(Section 6.8: Threat H.3 and Scenario =
H.3. Sorry about the discontinuity in terminology.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>Charlie and Pekka, </FONT>
<BR><FONT SIZE=3D2>In relation to changing the BU processing to a MUST =
from a SHOULD for CN's: </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>It just seems to me that some protection needs to be =
done even for the HA option to prevent against DDOS redirect (bouncing) =
and that the solutions that seem tenable (don't require that every =
packet is&nbsp; authenticated) require some sort of authorization and =
state table similar to a binding cache in size, lookup structure etc.. =
</FONT></P>

<P><FONT SIZE=3D2>So if the HA option is a MUST and we have to protect =
against this DOS redirect (bounce) problem then it seems like you might =
as well go ahead and make the binding update processing a MUST too and =
get the ubiquity of route optimization for IPv6. The HA integrity =
appears to me to be almost the same class of problem and solution set =
as the BU integrity.</FONT></P>

<P><FONT SIZE=3D2>Thanks, </FONT>
<BR><FONT SIZE=3D2>Glenn </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15326.6B445EB0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 10:25:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29261
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 10:25:34 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28482;
	Fri, 12 Oct 2001 07:25:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18180;
	Fri, 12 Oct 2001 07:24:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CEO2ML012284
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:24:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CEO2xh012283
	for mobile-ip-dist; Fri, 12 Oct 2001 07:24:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CENwML012276
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:23:59 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17932
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 07:23:56 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06871
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 08:25:11 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA29037
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 09:23:58 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 12 Oct 2001 09:17:12 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LYJMQ>; Fri, 12 Oct 2001 09:23:26 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E5D9F75@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 12 Oct 2001 09:23:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15329.7487B5A0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15329.7487B5A0
Content-Type: text/plain;
	charset="iso-8859-1"

Michael R.,

I am pleased that you have brought this QoS issues up and I would definitely
like to "go there" with respect to the use of RSVP and BUs. 

Is it your intention to do node mobility with RSVP or do you see more value
allowing a BU and an RSVP message being conveyed in the same packet or are
you just trying to kill route optimization?

It seems clear to most the two should be harmonized in some way in the end.
The answer to the question above will simply draw the line in the sand a bit
better as to where people are going with their arguments. I think it would
be quite healthy for people to "go there" and get this debate settled now.

Thanks,

Glenn

-----Original Message-----
From: Michael A. Ramalho [mailto:mramalho@cisco.com]
Sent: Friday, October 12, 2001 7:26 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion


Rajeev,

One more time for further clarity. I think the discussion
moved off the original point. Comments in line.

Regards,

Michael Ramalho

At 07:06 PM 10/11/2001 -0700, Rajeev Koodli wrote:
>Hello Michael,
>
>thanks for clarifying. I have some clarifications as well.
>
>- a *compressor* resides in IR/FO/SO states, not a *link*.
>- similarly, a decompressor has either no context, static context or full 
>context.
>
>- compression is limited to IP and transport protocol headers. So, once you
do
>ip_output, the HC engine works on IP and transport headers before the
device
>driver output occurs. Nowhere in this *compression process*, the link 
>layer itself
>comes into play.
>
>It turns out that Compressor-1 (on L1) need not know in which state 
>Compressor-2
>(on L3) is before sending a piggybacked BU. Consider the following two
cases.
>First, the compressor on L3 would be in an IR state if it has never 
>initialized a
>context for this stream or there has been a pathological failure of an 
>existing
>context. Note that once a compressor determines that the decompressor has
Full
>Context, it must not transition to the IR state unless there is an 
>irrepairable
>context. It should be in FO, SO, or IR-DYN states, all of which have 
>enough room
>to include additional bytes the size of a BU.
>
>Second, if Compressor-2 _is in_ IR state when it receives a piggybacked BU,
it
>would have to be able to include the BU as part of initialization, just as
it
>should be able to handle any IPv6 extension header. I believe 3095 
>specifies how
>to handle the extension headers.

I have no doubt that the Compressor-2 knows how to do its job - it would
do it as you have said. That was never my point (hopefully I have proved
that
I am cluefull on this issue and move on).

The issue that triggered this thread was that the outgoing packet with the
piggybacked BU could only fit on the outgoing link (L1) if ROHC was in
FO or SO - for the case of a QoS constrained, DOCSYS-like output link
(which effectively has packet length limitations due to the QoS granting
mechanisms used on the link).

I agreed with that ... but said you were forgetting about the link on the
other side.

On the other side ... you do *not* know the compression state ... and
do not know if the packet with the piggybacked BU will fit into the QoS
channel.

I have *no doubt* that ROHC knows what to do with a packet with
a piggybacked BU. My point is not about compression; but rather
on the point (Mike Thomas' actually) that the piggybacked packet
may be too large for other links as well.


>So, in summary, the chances of Compressor-2 being in the IR state when a
>piggybacked BU is received should be small. However, if it is indeed in the
>IR state, it should not matter.

Again, I have little doubt that the ROHC folks know how to handle this
case. The issue is whether a QoS link can handle the larger packet
created by a piggybacked BU.

>Regards,
>
>-Rajeev
>

Think for a moment what one is saving via a piggybacked BU.

One argument is that it is saving precious bandwidth - so piggybacking
is good.

However, this *ignores* the way QoS flows are provisioned. One
example - the one above with a QoS grant mechanism on a link - shows
that piggybacking can be detrimental. But it is far from the only example.

Most QoS provisioned flows are policed at the edge of a network to
fit within a certain TSPEC/RSPEC. Given the expected frequency of
BUs ... to all but the most tight policers (in time constant or in strict
bandwidth), this increase would be negligible. This is effectively your
"wiggle room" argument. But one could imagine some policers would
actually mark the packet for discard eligibility (the new DE bit) or drop
it if the packet was too long. This is exactly the *wrong* thing to happen
to the BU (and to the QoS flow, which did nothing wrong!).

If I (and people like Mike Thomas) have not convinced the group that
BU piggybacking has more downsides than are worth it ... we may
be forced into a bigger debate on the interaction of QoS and mobileip.

[do you really want to go here ...]

To give an example of the proposed further debate .... suppose that
a pair of hosts have a "session" between them with a multiplicity of
QoS flows associated with this session (e.g., a videoconference with
QoS only provisioned on the voice). Now you want to send a BU.
Which "QoS type" packet do you piggyback onto. If the link layer
is dumb (the usual case) ... choosing the next packet is the easiest
choice. But you don't know the next packet's QoS treatment. In this
scenario, I'd choose one of the "reliable, delay insensitive" channels
if I had a choice. I would *not* choose the voice QoS channel.

In general, choosing "what type" of packet to piggyback onto is
hard. If you simply choose the "next or present" packet - at best
you get the QoS of this flow - and at worst you effectively harm
the packet/flow (e.g., marking it DE) for the flow that wanted
premium treatment.

Until convinced otherwise ... I am not persuaded that BU piggybacking
benefits outweigh the potential downsides. And I have not even
exhausted thinking about the downside arguments yet.

Remember ... one can make the following argument as
well ... "given the expected frequency of the BUs, that the
bandwidth saved by piggybacking is also negligible".

I am attempting to be a realist here. Bandwidth savings (piggybacking)
is usually good ... unless it causes more pain than the savings is worth.

Best Regards,

Michael Ramalho


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188


------_=_NextPart_001_01C15329.7487B5A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Michael R.,</FONT>
</P>

<P><FONT SIZE=3D2>I am pleased that you have brought this QoS issues up =
and I would definitely like to &quot;go there&quot; with respect to the =
use of RSVP and BUs. </FONT></P>

<P><FONT SIZE=3D2>Is it your intention to do node mobility with RSVP or =
do you see more value allowing a BU and an RSVP message being conveyed =
in the same packet or are you just trying to kill route =
optimization?</FONT></P>

<P><FONT SIZE=3D2>It seems clear to most the two should be harmonized =
in some way in the end. The answer to the question above will simply =
draw the line in the sand a bit better as to where people are going =
with their arguments. I think it would be quite healthy for people to =
&quot;go there&quot; and get this debate settled now.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael A. Ramalho [<A =
HREF=3D"mailto:mramalho@cisco.com">mailto:mramalho@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Friday, October 12, 2001 7:26 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] MIPv6 - Focus of the =
security discussion</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Rajeev,</FONT>
</P>

<P><FONT SIZE=3D2>One more time for further clarity. I think the =
discussion</FONT>
<BR><FONT SIZE=3D2>moved off the original point. Comments in =
line.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Michael Ramalho</FONT>
</P>

<P><FONT SIZE=3D2>At 07:06 PM 10/11/2001 -0700, Rajeev Koodli =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Hello Michael,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;thanks for clarifying. I have some =
clarifications as well.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;- a *compressor* resides in IR/FO/SO states, not =
a *link*.</FONT>
<BR><FONT SIZE=3D2>&gt;- similarly, a decompressor has either no =
context, static context or full </FONT>
<BR><FONT SIZE=3D2>&gt;context.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;- compression is limited to IP and transport =
protocol headers. So, once you do</FONT>
<BR><FONT SIZE=3D2>&gt;ip_output, the HC engine works on IP and =
transport headers before the device</FONT>
<BR><FONT SIZE=3D2>&gt;driver output occurs. Nowhere in this =
*compression process*, the link </FONT>
<BR><FONT SIZE=3D2>&gt;layer itself</FONT>
<BR><FONT SIZE=3D2>&gt;comes into play.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;It turns out that Compressor-1 (on L1) need not =
know in which state </FONT>
<BR><FONT SIZE=3D2>&gt;Compressor-2</FONT>
<BR><FONT SIZE=3D2>&gt;(on L3) is before sending a piggybacked BU. =
Consider the following two cases.</FONT>
<BR><FONT SIZE=3D2>&gt;First, the compressor on L3 would be in an IR =
state if it has never </FONT>
<BR><FONT SIZE=3D2>&gt;initialized a</FONT>
<BR><FONT SIZE=3D2>&gt;context for this stream or there has been a =
pathological failure of an </FONT>
<BR><FONT SIZE=3D2>&gt;existing</FONT>
<BR><FONT SIZE=3D2>&gt;context. Note that once a compressor determines =
that the decompressor has Full</FONT>
<BR><FONT SIZE=3D2>&gt;Context, it must not transition to the IR state =
unless there is an </FONT>
<BR><FONT SIZE=3D2>&gt;irrepairable</FONT>
<BR><FONT SIZE=3D2>&gt;context. It should be in FO, SO, or IR-DYN =
states, all of which have </FONT>
<BR><FONT SIZE=3D2>&gt;enough room</FONT>
<BR><FONT SIZE=3D2>&gt;to include additional bytes the size of a =
BU.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Second, if Compressor-2 _is in_ IR state when it =
receives a piggybacked BU, it</FONT>
<BR><FONT SIZE=3D2>&gt;would have to be able to include the BU as part =
of initialization, just as it</FONT>
<BR><FONT SIZE=3D2>&gt;should be able to handle any IPv6 extension =
header. I believe 3095 </FONT>
<BR><FONT SIZE=3D2>&gt;specifies how</FONT>
<BR><FONT SIZE=3D2>&gt;to handle the extension headers.</FONT>
</P>

<P><FONT SIZE=3D2>I have no doubt that the Compressor-2 knows how to do =
its job - it would</FONT>
<BR><FONT SIZE=3D2>do it as you have said. That was never my point =
(hopefully I have proved that</FONT>
<BR><FONT SIZE=3D2>I am cluefull on this issue and move on).</FONT>
</P>

<P><FONT SIZE=3D2>The issue that triggered this thread was that the =
outgoing packet with the</FONT>
<BR><FONT SIZE=3D2>piggybacked BU could only fit on the outgoing link =
(L1) if ROHC was in</FONT>
<BR><FONT SIZE=3D2>FO or SO - for the case of a QoS constrained, =
DOCSYS-like output link</FONT>
<BR><FONT SIZE=3D2>(which effectively has packet length limitations due =
to the QoS granting</FONT>
<BR><FONT SIZE=3D2>mechanisms used on the link).</FONT>
</P>

<P><FONT SIZE=3D2>I agreed with that ... but said you were forgetting =
about the link on the</FONT>
<BR><FONT SIZE=3D2>other side.</FONT>
</P>

<P><FONT SIZE=3D2>On the other side ... you do *not* know the =
compression state ... and</FONT>
<BR><FONT SIZE=3D2>do not know if the packet with the piggybacked BU =
will fit into the QoS</FONT>
<BR><FONT SIZE=3D2>channel.</FONT>
</P>

<P><FONT SIZE=3D2>I have *no doubt* that ROHC knows what to do with a =
packet with</FONT>
<BR><FONT SIZE=3D2>a piggybacked BU. My point is not about compression; =
but rather</FONT>
<BR><FONT SIZE=3D2>on the point (Mike Thomas' actually) that the =
piggybacked packet</FONT>
<BR><FONT SIZE=3D2>may be too large for other links as well.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;So, in summary, the chances of Compressor-2 being =
in the IR state when a</FONT>
<BR><FONT SIZE=3D2>&gt;piggybacked BU is received should be small. =
However, if it is indeed in the</FONT>
<BR><FONT SIZE=3D2>&gt;IR state, it should not matter.</FONT>
</P>

<P><FONT SIZE=3D2>Again, I have little doubt that the ROHC folks know =
how to handle this</FONT>
<BR><FONT SIZE=3D2>case. The issue is whether a QoS link can handle the =
larger packet</FONT>
<BR><FONT SIZE=3D2>created by a piggybacked BU.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-Rajeev</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Think for a moment what one is saving via a =
piggybacked BU.</FONT>
</P>

<P><FONT SIZE=3D2>One argument is that it is saving precious bandwidth =
- so piggybacking</FONT>
<BR><FONT SIZE=3D2>is good.</FONT>
</P>

<P><FONT SIZE=3D2>However, this *ignores* the way QoS flows are =
provisioned. One</FONT>
<BR><FONT SIZE=3D2>example - the one above with a QoS grant mechanism =
on a link - shows</FONT>
<BR><FONT SIZE=3D2>that piggybacking can be detrimental. But it is far =
from the only example.</FONT>
</P>

<P><FONT SIZE=3D2>Most QoS provisioned flows are policed at the edge of =
a network to</FONT>
<BR><FONT SIZE=3D2>fit within a certain TSPEC/RSPEC. Given the expected =
frequency of</FONT>
<BR><FONT SIZE=3D2>BUs ... to all but the most tight policers (in time =
constant or in strict</FONT>
<BR><FONT SIZE=3D2>bandwidth), this increase would be negligible. This =
is effectively your</FONT>
<BR><FONT SIZE=3D2>&quot;wiggle room&quot; argument. But one could =
imagine some policers would</FONT>
<BR><FONT SIZE=3D2>actually mark the packet for discard eligibility =
(the new DE bit) or drop</FONT>
<BR><FONT SIZE=3D2>it if the packet was too long. This is exactly the =
*wrong* thing to happen</FONT>
<BR><FONT SIZE=3D2>to the BU (and to the QoS flow, which did nothing =
wrong!).</FONT>
</P>

<P><FONT SIZE=3D2>If I (and people like Mike Thomas) have not convinced =
the group that</FONT>
<BR><FONT SIZE=3D2>BU piggybacking has more downsides than are worth it =
... we may</FONT>
<BR><FONT SIZE=3D2>be forced into a bigger debate on the interaction of =
QoS and mobileip.</FONT>
</P>

<P><FONT SIZE=3D2>[do you really want to go here ...]</FONT>
</P>

<P><FONT SIZE=3D2>To give an example of the proposed further debate =
.... suppose that</FONT>
<BR><FONT SIZE=3D2>a pair of hosts have a &quot;session&quot; between =
them with a multiplicity of</FONT>
<BR><FONT SIZE=3D2>QoS flows associated with this session (e.g., a =
videoconference with</FONT>
<BR><FONT SIZE=3D2>QoS only provisioned on the voice). Now you want to =
send a BU.</FONT>
<BR><FONT SIZE=3D2>Which &quot;QoS type&quot; packet do you piggyback =
onto. If the link layer</FONT>
<BR><FONT SIZE=3D2>is dumb (the usual case) ... choosing the next =
packet is the easiest</FONT>
<BR><FONT SIZE=3D2>choice. But you don't know the next packet's QoS =
treatment. In this</FONT>
<BR><FONT SIZE=3D2>scenario, I'd choose one of the &quot;reliable, =
delay insensitive&quot; channels</FONT>
<BR><FONT SIZE=3D2>if I had a choice. I would *not* choose the voice =
QoS channel.</FONT>
</P>

<P><FONT SIZE=3D2>In general, choosing &quot;what type&quot; of packet =
to piggyback onto is</FONT>
<BR><FONT SIZE=3D2>hard. If you simply choose the &quot;next or =
present&quot; packet - at best</FONT>
<BR><FONT SIZE=3D2>you get the QoS of this flow - and at worst you =
effectively harm</FONT>
<BR><FONT SIZE=3D2>the packet/flow (e.g., marking it DE) for the flow =
that wanted</FONT>
<BR><FONT SIZE=3D2>premium treatment.</FONT>
</P>

<P><FONT SIZE=3D2>Until convinced otherwise ... I am not persuaded that =
BU piggybacking</FONT>
<BR><FONT SIZE=3D2>benefits outweigh the potential downsides. And I =
have not even</FONT>
<BR><FONT SIZE=3D2>exhausted thinking about the downside arguments =
yet.</FONT>
</P>

<P><FONT SIZE=3D2>Remember ... one can make the following argument =
as</FONT>
<BR><FONT SIZE=3D2>well ... &quot;given the expected frequency of the =
BUs, that the</FONT>
<BR><FONT SIZE=3D2>bandwidth saved by piggybacking is also =
negligible&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>I am attempting to be a realist here. Bandwidth =
savings (piggybacking)</FONT>
<BR><FONT SIZE=3D2>is usually good ... unless it causes more pain than =
the savings is worth.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Michael Ramalho</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Michael A. Ramalho, Ph.D.</FONT>
<BR><FONT SIZE=3D2>Office email: mramalho@cisco.com</FONT>
<BR><FONT SIZE=3D2>Personal email: mar42@cornell.edu</FONT>
<BR><FONT SIZE=3D2>Office: +1.732.449.5762</FONT>
<BR><FONT SIZE=3D2>Cell: +1.732.809.0188</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15329.7487B5A0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 13:02:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03540
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 13:02:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20389;
	Fri, 12 Oct 2001 11:02:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03378;
	Fri, 12 Oct 2001 10:02:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CH1GML012551
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 10:01:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CH1GvL012550
	for mobile-ip-dist; Fri, 12 Oct 2001 10:01:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CH1CML012543
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 10:01:12 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06619
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 10:01:14 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09836
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:01:08 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14881
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 10:01:11 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9CH1BO32162
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 10:01:11 -0700
X-mProtect:  Fri, 12 Oct 2001 10:01:11 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdkcwEeB; Fri, 12 Oct 2001 10:01:09 PDT
Message-ID: <3BC721D3.28DE3FD1@iprg.nokia.com>
Date: Fri, 12 Oct 2001 10:01:07 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
	 <15300.33271.335089.998138@thomasm-u1.cisco.com>
	 <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com>
	 <4.3.2.7.2.20011011140647.050084c0@mira-sjc5-9.cisco.com> <4.3.2.7.2.20011012073856.043c19c0@mira-sjc5-9.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Michael,

"Michael A. Ramalho" wrote:

> Rajeev,
>
> One more time for further clarity. I think the discussion
> moved off the original point. Comments in line.
>

I believe it did with your following e-mail in which QoS replaced header
compression as the topic of discussion :-)

In my e-mail exchange with _yours_, I saw no reference to QoS earlier. It was
limited to how header compression would work, with piggybacking, when it is done
on a "link-by-link" basis as you called it. From your reply below, seems like you
agree that piggybacking would still work even if the far end compressor was in
IR state. In fact, it should work regardless of in which state the compressor is.
If the far end channel knows how to support ROHC at all, piggybacking should work.
So, good; I would like to move on as well.


Regards,

-Rajeev


>
> Regards,
>
> Michael Ramalho
>
> At 07:06 PM 10/11/2001 -0700, Rajeev Koodli wrote:
> >Hello Michael,
> >
> >thanks for clarifying. I have some clarifications as well.
> >
> >- a *compressor* resides in IR/FO/SO states, not a *link*.
> >- similarly, a decompressor has either no context, static context or full
> >context.
> >
> >- compression is limited to IP and transport protocol headers. So, once you do
> >ip_output, the HC engine works on IP and transport headers before the device
> >driver output occurs. Nowhere in this *compression process*, the link
> >layer itself
> >comes into play.
> >
> >It turns out that Compressor-1 (on L1) need not know in which state
> >Compressor-2
> >(on L3) is before sending a piggybacked BU. Consider the following two cases.
> >First, the compressor on L3 would be in an IR state if it has never
> >initialized a
> >context for this stream or there has been a pathological failure of an
> >existing
> >context. Note that once a compressor determines that the decompressor has Full
> >Context, it must not transition to the IR state unless there is an
> >irrepairable
> >context. It should be in FO, SO, or IR-DYN states, all of which have
> >enough room
> >to include additional bytes the size of a BU.
> >
> >Second, if Compressor-2 _is in_ IR state when it receives a piggybacked BU, it
> >would have to be able to include the BU as part of initialization, just as it
> >should be able to handle any IPv6 extension header. I believe 3095
> >specifies how
> >to handle the extension headers.
>
> I have no doubt that the Compressor-2 knows how to do its job - it would
> do it as you have said. That was never my point (hopefully I have proved that
> I am cluefull on this issue and move on).
>
> The issue that triggered this thread was that the outgoing packet with the
> piggybacked BU could only fit on the outgoing link (L1) if ROHC was in
> FO or SO - for the case of a QoS constrained, DOCSYS-like output link
> (which effectively has packet length limitations due to the QoS granting
> mechanisms used on the link).
>
> I agreed with that ... but said you were forgetting about the link on the
> other side.
>
> On the other side ... you do *not* know the compression state ... and
> do not know if the packet with the piggybacked BU will fit into the QoS
> channel.
>
> I have *no doubt* that ROHC knows what to do with a packet with
> a piggybacked BU. My point is not about compression; but rather
> on the point (Mike Thomas' actually) that the piggybacked packet
> may be too large for other links as well.
>
> >So, in summary, the chances of Compressor-2 being in the IR state when a
> >piggybacked BU is received should be small. However, if it is indeed in the
> >IR state, it should not matter.
>
> Again, I have little doubt that the ROHC folks know how to handle this
> case. The issue is whether a QoS link can handle the larger packet
> created by a piggybacked BU.
>
> >Regards,
> >
> >-Rajeev
> >
>
> Think for a moment what one is saving via a piggybacked BU.
>
> One argument is that it is saving precious bandwidth - so piggybacking
> is good.
>
> However, this *ignores* the way QoS flows are provisioned. One
> example - the one above with a QoS grant mechanism on a link - shows
> that piggybacking can be detrimental. But it is far from the only example.
>
> Most QoS provisioned flows are policed at the edge of a network to
> fit within a certain TSPEC/RSPEC. Given the expected frequency of
> BUs ... to all but the most tight policers (in time constant or in strict
> bandwidth), this increase would be negligible. This is effectively your
> "wiggle room" argument. But one could imagine some policers would
> actually mark the packet for discard eligibility (the new DE bit) or drop
> it if the packet was too long. This is exactly the *wrong* thing to happen
> to the BU (and to the QoS flow, which did nothing wrong!).
>
> If I (and people like Mike Thomas) have not convinced the group that
> BU piggybacking has more downsides than are worth it ... we may
> be forced into a bigger debate on the interaction of QoS and mobileip.
>
> [do you really want to go here ...]
>
> To give an example of the proposed further debate .... suppose that
> a pair of hosts have a "session" between them with a multiplicity of
> QoS flows associated with this session (e.g., a videoconference with
> QoS only provisioned on the voice). Now you want to send a BU.
> Which "QoS type" packet do you piggyback onto. If the link layer
> is dumb (the usual case) ... choosing the next packet is the easiest
> choice. But you don't know the next packet's QoS treatment. In this
> scenario, I'd choose one of the "reliable, delay insensitive" channels
> if I had a choice. I would *not* choose the voice QoS channel.
>
> In general, choosing "what type" of packet to piggyback onto is
> hard. If you simply choose the "next or present" packet - at best
> you get the QoS of this flow - and at worst you effectively harm
> the packet/flow (e.g., marking it DE) for the flow that wanted
> premium treatment.
>
> Until convinced otherwise ... I am not persuaded that BU piggybacking
> benefits outweigh the potential downsides. And I have not even
> exhausted thinking about the downside arguments yet.
>
> Remember ... one can make the following argument as
> well ... "given the expected frequency of the BUs, that the
> bandwidth saved by piggybacking is also negligible".
>
> I am attempting to be a realist here. Bandwidth savings (piggybacking)
> is usually good ... unless it causes more pain than the savings is worth.
>
> Best Regards,
>
> Michael Ramalho
>
> Michael A. Ramalho, Ph.D.
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 14:26:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05951
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 14:26:12 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24007;
	Fri, 12 Oct 2001 11:25:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24639;
	Fri, 12 Oct 2001 11:25:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CIOEML012687
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:24:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CIOEqY012686
	for mobile-ip-dist; Fri, 12 Oct 2001 11:24:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CIOAML012679
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:24:10 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10016
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:24:12 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10744
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:24:10 -0700 (PDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9CILoC21755
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:21:59 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (dhcp-wall-59-64.cisco.com [171.68.59.64])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABD48636;
	Fri, 12 Oct 2001 11:23:54 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011012140307.0225b8d0@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 12 Oct 2001 14:22:00 -0400
To: mobile-ip@sunroof.eng.sun.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BC721D3.28DE3FD1@iprg.nokia.com>
References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF0F6@TNEXVS02.tahoenetworks.com>
 <15300.33271.335089.998138@thomasm-u1.cisco.com>
 <4.3.2.7.2.20011010142602.00b7f5d8@mira-sjc5-9.cisco.com>
 <4.3.2.7.2.20011011140647.050084c0@mira-sjc5-9.cisco.com>
 <4.3.2.7.2.20011012073856.043c19c0@mira-sjc5-9.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

At 10:01 AM 10/12/2001 -0700, you wrote:
>Hello Michael,
>
>"Michael A. Ramalho" wrote:
>
> > Rajeev,
> >
> > One more time for further clarity. I think the discussion
> > moved off the original point. Comments in line.
> >
>
>I believe it did with your following e-mail in which QoS replaced header
>compression as the topic of discussion :-)
>
>In my e-mail exchange with _yours_, I saw no reference to QoS earlier. It was
>limited to how header compression would work, with piggybacking, when it 
>is done
>on a "link-by-link" basis as you called it. From your reply below, seems 
>like you
>agree that piggybacking would still work even if the far end compressor was in
>IR state. In fact, it should work regardless of in which state the 
>compressor is.
>If the far end channel knows how to support ROHC at all, piggybacking 
>should work.
>So, good; I would like to move on as well.

I'll reiterate what Mike Thomas said about 5 emails back:
"This has nothing to do with ROHC implementations."

As far as the compression technique was concerned, ROHC
works at the far end. But that was not the issue.

The piggybacked packet *would not fit* on a similarly QoS
constrained link at the far end. Additionally, it might ruin
existing QoS flows to the mobile endpoint. This was the
point of my earlier email.

Thus ... don't piggyback to begin with (i.e., do NOT put it
in the L3 standard).

Now ... if you build L2 links specific to a technology (i.e.,
digital cable TV/DOCSYS links ... or special cellular links)
please feel free to specify special "L2 link specific" technology
that ... on that particular link type .... can piggyback the
BU to save bandwidth if you desire. But be sure to
"de-piggyback" the BU upon egress from your link.
That way, L3 never knew about the piggybacking.

Thus, if you absolutely need to piggyback a BU for a
particular L2 technology .... specify it at L2 in 3GPP
type bodies. Specifying BU piggybacking at L3 in the
IETF has the detriments of my earlier email (and others
that I have not thought of yet).

Besides, there are enough cross L2/L3 issues in
mobility to begin with :-).

Regards,

Michael Ramalho


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 14:35:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06377
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 14:35:13 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08402;
	Fri, 12 Oct 2001 12:34:49 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27725;
	Fri, 12 Oct 2001 11:34:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CIY4ML012802
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:34:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CIY4A7012801
	for mobile-ip-dist; Fri, 12 Oct 2001 11:34:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CIY0ML012794
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:34:00 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02289
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:34:02 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00319
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 12:34:11 -0600 (MDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9CIY4k03169
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 11:34:04 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (dhcp-wall-59-64.cisco.com [171.68.59.64])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABD48936;
	Fri, 12 Oct 2001 11:33:59 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011012142237.022bceb8@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 12 Oct 2001 14:32:05 -0400
To: mobile-ip@sunroof.eng.sun.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E5D9F75@zrc2c012.us.nortel.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

At 09:23 AM 10/12/2001 -0500, you wrote:

>Michael R.,
>
>I am pleased that you have brought this QoS issues up and I would 
>definitely like to "go there" with respect to the use of RSVP and BUs.

I was kind of hoping no one really wanted to go there .... at
least not right now.


>Is it your intention to do node mobility with RSVP or do you see more 
>value allowing a BU and an RSVP message being conveyed in the same packet 
>or are you just trying to kill route optimization?

Being a VoIP guy ... I'm definitely not trying to kill route optimization.

I simply see piggybacking as unnecessary ... as the savings are
trivial given typical BU update frequencies.

In a response to Rajeev .. I suggested that if he really needed the
bandwidth savings on the mobile link ... that he specify the
"effective piggybacking" at L2 ... to save the link bandwidth.


>It seems clear to most the two should be harmonized in some way in the end.

I agree that the QoS issue needs to be resolved. Not piggybacking
the BU allows for de coupling of the QoS and the security issues. The
day of reckoning on QoS and security is simply postponed.

>The answer to the question above will simply draw the line in the sand a 
>bit better as to where people are going with their arguments. I think it 
>would be quite healthy for people to "go there" and get this debate 
>settled now.

>Thanks,
>
>Glenn
>
>-----Original Message-----
>From: Michael A. Ramalho 
>[<mailto:mramalho@cisco.com>mailto:mramalho@cisco.com]
>Sent: Friday, October 12, 2001 7:26 AM
>To: mobile-ip@sunroof.eng.sun.com
>Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
>
>Rajeev,
>
>One more time for further clarity. I think the discussion
>moved off the original point. Comments in line.
>
>Regards,
>
>Michael Ramalho
>
>At 07:06 PM 10/11/2001 -0700, Rajeev Koodli wrote:
> >Hello Michael,
> >
> >thanks for clarifying. I have some clarifications as well.
> >
> >- a *compressor* resides in IR/FO/SO states, not a *link*.
> >- similarly, a decompressor has either no context, static context or full
> >context.
> >
> >- compression is limited to IP and transport protocol headers. So, once 
> you do
> >ip_output, the HC engine works on IP and transport headers before the 
> device
> >driver output occurs. Nowhere in this *compression process*, the link
> >layer itself
> >comes into play.
> >
> >It turns out that Compressor-1 (on L1) need not know in which state
> >Compressor-2
> >(on L3) is before sending a piggybacked BU. Consider the following two 
> cases.
> >First, the compressor on L3 would be in an IR state if it has never
> >initialized a
> >context for this stream or there has been a pathological failure of an
> >existing
> >context. Note that once a compressor determines that the decompressor 
> has Full
> >Context, it must not transition to the IR state unless there is an
> >irrepairable
> >context. It should be in FO, SO, or IR-DYN states, all of which have
> >enough room
> >to include additional bytes the size of a BU.
> >
> >Second, if Compressor-2 _is in_ IR state when it receives a piggybacked 
> BU, it
> >would have to be able to include the BU as part of initialization, just 
> as it
> >should be able to handle any IPv6 extension header. I believe 3095
> >specifies how
> >to handle the extension headers.
>
>I have no doubt that the Compressor-2 knows how to do its job - it would
>do it as you have said. That was never my point (hopefully I have proved that
>I am cluefull on this issue and move on).
>
>The issue that triggered this thread was that the outgoing packet with the
>piggybacked BU could only fit on the outgoing link (L1) if ROHC was in
>FO or SO - for the case of a QoS constrained, DOCSYS-like output link
>(which effectively has packet length limitations due to the QoS granting
>mechanisms used on the link).
>
>I agreed with that ... but said you were forgetting about the link on the
>other side.
>
>On the other side ... you do *not* know the compression state ... and
>do not know if the packet with the piggybacked BU will fit into the QoS
>channel.
>
>I have *no doubt* that ROHC knows what to do with a packet with
>a piggybacked BU. My point is not about compression; but rather
>on the point (Mike Thomas' actually) that the piggybacked packet
>may be too large for other links as well.
>
> >So, in summary, the chances of Compressor-2 being in the IR state when a
> >piggybacked BU is received should be small. However, if it is indeed in the
> >IR state, it should not matter.
>
>Again, I have little doubt that the ROHC folks know how to handle this
>case. The issue is whether a QoS link can handle the larger packet
>created by a piggybacked BU.
>
> >Regards,
> >
> >-Rajeev
> >
>
>Think for a moment what one is saving via a piggybacked BU.
>
>One argument is that it is saving precious bandwidth - so piggybacking
>is good.
>
>However, this *ignores* the way QoS flows are provisioned. One
>example - the one above with a QoS grant mechanism on a link - shows
>that piggybacking can be detrimental. But it is far from the only example.
>
>Most QoS provisioned flows are policed at the edge of a network to
>fit within a certain TSPEC/RSPEC. Given the expected frequency of
>BUs ... to all but the most tight policers (in time constant or in strict
>bandwidth), this increase would be negligible. This is effectively your
>"wiggle room" argument. But one could imagine some policers would
>actually mark the packet for discard eligibility (the new DE bit) or drop
>it if the packet was too long. This is exactly the *wrong* thing to happen
>to the BU (and to the QoS flow, which did nothing wrong!).
>
>If I (and people like Mike Thomas) have not convinced the group that
>BU piggybacking has more downsides than are worth it ... we may
>be forced into a bigger debate on the interaction of QoS and mobileip.
>
>[do you really want to go here ...]
>
>To give an example of the proposed further debate .... suppose that
>a pair of hosts have a "session" between them with a multiplicity of
>QoS flows associated with this session (e.g., a videoconference with
>QoS only provisioned on the voice). Now you want to send a BU.
>Which "QoS type" packet do you piggyback onto. If the link layer
>is dumb (the usual case) ... choosing the next packet is the easiest
>choice. But you don't know the next packet's QoS treatment. In this
>scenario, I'd choose one of the "reliable, delay insensitive" channels
>if I had a choice. I would *not* choose the voice QoS channel.
>
>In general, choosing "what type" of packet to piggyback onto is
>hard. If you simply choose the "next or present" packet - at best
>you get the QoS of this flow - and at worst you effectively harm
>the packet/flow (e.g., marking it DE) for the flow that wanted
>premium treatment.
>
>Until convinced otherwise ... I am not persuaded that BU piggybacking
>benefits outweigh the potential downsides. And I have not even
>exhausted thinking about the downside arguments yet.
>
>Remember ... one can make the following argument as
>well ... "given the expected frequency of the BUs, that the
>bandwidth saved by piggybacking is also negligible".
>
>I am attempting to be a realist here. Bandwidth savings (piggybacking)
>is usually good ... unless it causes more pain than the savings is worth.
>
>Best Regards,
>
>Michael Ramalho
>
>Michael A. Ramalho, Ph.D.
>Office email: mramalho@cisco.com
>Personal email: mar42@cornell.edu
>Office: +1.732.449.5762
>Cell: +1.732.809.0188


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 15:20:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07646
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 15:20:51 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12574;
	Fri, 12 Oct 2001 13:20:29 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08569;
	Fri, 12 Oct 2001 12:20:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CJJZML013046
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 12:19:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CJJYxa013045
	for mobile-ip-dist; Fri, 12 Oct 2001 12:19:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CJJWML013038
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 12:19:32 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22368
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:19:33 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA16368
	for mobile-ip@sunroof.eng.sun.com; Fri, 12 Oct 2001 15:20:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9C6YQML011161
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 23:34:26 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09816
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 23:34:28 -0700 (PDT)
Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26673
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 11 Oct 2001 23:34:28 -0700 (PDT)
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id PAA20559;
	Fri, 12 Oct 2001 15:34:25 +0900 (JST)
Received: (from root@localhost)
	by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id f9C6YOP00180;
	Fri, 12 Oct 2001 15:34:24 +0900 (JST)
Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id RAA00178 ; Fri, 12 Oct 2001 15:34:24 +0900
Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317)
	id PAA14069; Fri, 12 Oct 2001 15:34:25 +0900 (JST)
Received: by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id PAA19409; Fri, 12 Oct 2001 15:34:24 +0900 (JST)
Message-Id: <200110120634.PAA19409@toshiba.co.jp>
To: mobile-ip@sunroof.eng.sun.com
cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Phil Roberts <PRoberts@MEGISTO.com>
Subject: Re: [mobile-ip] IESG feedback on AAA keys doc 
In-reply-to: charliep's message of "Thu, 11 Oct 2001 09:53:53 MST."
             <3BC5CEA1.55B811CA@iprg.nokia.com> 
Date: Fri, 12 Oct 2001 15:34:20 +0900
From: FUKUMOTO Atsushi <atsushi.fukumoto@toshiba.co.jp>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Charlie Perkins wrote:
> Phil pointed me to tables in IANA's registry for ISAKMP:
> 	http://www.iana.org/assignments/isakmp-registry
> Turns out there are _two_ relevant tables there.
> One is a list of "Transform ID"s for AH:
> 
> ==================================================================
> 
> Transform ID            Value                           Reference
> ------------            -----                           ---------
> RESERVED                0-1                             [RFC2407]
> AH_MD5                  2                               [RFC2407]
> AH_SHA                  3                               [RFC2407]
> AH_DES                  4                               [RFC2407]
> AH_SHA2-256             5                                 [Leech] 
> AH_SHA2-384             6                                 [Leech]
> AH_SHA2-512             7                                 [Leech]
> AH_RIPEMD               8                               [RFC2857]
> 
> ==================================================================
> 
> That does not have HMAC-MD5.


I wasn't following this discussion closely, so, please forgive me if
I'm missing point.  To specify a security association for AH, you MUST
specify Authentication Algorithm attribute along with Transform ID.
AH_MD5 for Transform ID and HMAC-MD5 for Auth Alg means HMAC-MD5-96.
AH_MD5 for Transform ID and KPDK for Auth Alg means Keyed MD5.

(It is for historical reason, I believe...  When ESP incorporated
authentication, ISAKMP needed Auth Alg negotiation.  Then found the
KPDK is weak and HMAC should be used, so Auth Alg is used for AH to
choose KPDK and HMAC.)

I think an algorithm and a protocol definition should be distinguished
more clearly.  For example, RFC2104 defines HMAC algorithm.  RFC2403
defines HMAC-MD5-96 as a part of communication protocol using HMAC and
MD5 funciton algorithm.  That means I think Mobile-IP specification is
slightly ambiguous about it, although it was minor enough that it did
not cause interoperability problem, I guess.


					FUKUMOTO Atsushi
					fukumoto@isl.rdc.toshiba.co.jp


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 16:36:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09022
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 16:36:58 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15419;
	Fri, 12 Oct 2001 13:36:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11246;
	Fri, 12 Oct 2001 13:36:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CKZYML013528
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 13:35:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CKZY6f013527
	for mobile-ip-dist; Fri, 12 Oct 2001 13:35:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CKZTML013520
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 13:35:31 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13013
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 13:35:24 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13697
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 13:35:26 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9CKZPf09371
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 23:35:25 +0300
Date: Fri, 12 Oct 2001 23:35:25 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <CD8355C7E19ED411BD5F00508BB0D19D6981E5@megisto-sql1.megisto.com>
Message-ID: <Pine.LNX.4.33.0110122320320.9262-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Fri, 5 Oct 2001, Phil Roberts wrote:
>     this is a working group last call on the threat model and security
> requirements
> for Mobile IP v6 draft.  The intention is to publish this document as an
> informational
> RFC.  Please post comments on this document to the mobile ip mailing list.
>
> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
> .txt
>
> Last call expires Oct 19, 2001.

I posted some comments on:

Date: Sun, 30 Sep 2001 15:49:31 +0300 (EEST)
Subject: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Discovery

There was a lot of philosophical cruft :-) in the mail, though, but a
main point from SecReqs perpective was:

--8<--
I have may have missed something, but it appears to me that two scenarios
discussed in more detail:

 1) usage of Home Address Option.  Its use need not be authenticated.
Anyone can put it in.  This makes _one-way_ (nice enough for UDP and ICMP)
IP spoofing less than trivial.
--8<--

This has not been commented by anyone.

I think SecReqs document should also address the following issues:

(new)
 - mobile nodes (at least) MUST have forwarding via routing headers
enabled.  This can be used to e.g. reflect traffic by laundering (DoS,
security disclosure, ...) by anyone in the Internet.  This works for TCP
connections too.

(home address)
 - use of home address may allow one to perform DoS attacks w/ source
address spoofing, among others.  Home Option must be processed in every
IPv6 node even if there is no BU or anything that will use it.  This could
get nasty.

These are covered, to some extent, in:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

I'd definitely want to have these issues taken into consideration when
considering different MIPv6 security options, as these could basically
affect every IPv6 node, whether mobile or not, in the end..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords







From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 18:29:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10445
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 18:29:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27410;
	Fri, 12 Oct 2001 15:29:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05180;
	Fri, 12 Oct 2001 15:29:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMS8ML013913
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:28:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CMS7BY013912
	for mobile-ip-dist; Fri, 12 Oct 2001 15:28:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMS4ML013905
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:28:04 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA00112;
	Fri, 12 Oct 2001 15:28:07 -0700 (PDT)
Message-Id: <200110122228.PAA00112@heliopolis.eng.sun.com>
Date: Fri, 12 Oct 2001 15:28:06 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [mobile-ip] New BETH Draft
To: mobile-ip@sunroof.eng.sun.com
Cc: jochen.grimminger@mchp.siemens.de, kempf42@yahoo.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: p48bsFHZWnKl27zJCe5+WA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

>
>I have a Question in "Two Party Handover" from BETH.
>
>What happen when the oAR or the nAR don't receive a L2 Trigger before MN
>move to nAR?
>What happen with the Tunnel-End?
>
>
>

In general,  BETH depends on having accurate and timely information
on handover sequencing. The draft identifies which L2 trigger
events are required, and which are just helpful in achieving optimizations
such as limiting tunnel lifetime.

If an L2 Source Trigger or L2 Target Trigger is missing, then there may not be 
enough time prior to the L2 handover event to actually achieve loss free
handover. In this situation, the establishment of the tunnel would
depend on trigger information on the nAR, presumably only on
L2 Link Up. The oAR and nAR must exchange HRqst/HRply while the
MN is waiting. The result would be a gap in L3 level coverage which
must be covered by buffering.

If the the L2 Link Down trigger on oAR is lacking, the oAR can use the 
sending/receipt of the HRply to initiate the tunnel, but there may then be a 
period of time in which packets to the MN are delievered to the
MN through both the oAR and nAR ("bicasting"), even if the MN is
not physically on the nAR L2 yet.

Neither case is optimal, but both can be covered by particular
smoothing techniques.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 18:35:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10509
	for <mobileip-archive@lists.ietf.org>; Fri, 12 Oct 2001 18:35:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25516;
	Fri, 12 Oct 2001 16:35:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06639;
	Fri, 12 Oct 2001 15:35:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMYIML014000
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:34:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CMYIa3013999
	for mobile-ip-dist; Fri, 12 Oct 2001 15:34:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from heliopolis.eng.sun.com (bigbang.Eng.Sun.COM [152.70.8.30])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMYEML013992
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:34:14 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA00710;
	Fri, 12 Oct 2001 15:34:17 -0700 (PDT)
Message-Id: <200110122234.PAA00710@heliopolis.eng.sun.com>
Date: Fri, 12 Oct 2001 15:34:16 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [mobile-ip] Improving BETH: Tunnel Negotiation
To: mobile-ip@sunroof.eng.sun.com
Cc: kempf42@yahoo.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4MDXoEEExjNelgTl75RdWQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Sreemanthula, 

Thanx for these proposals. Sorry it took so long to get back to
you, I was on vacation.

>Proposal 1: 
>Allow negotiation of lifetime of the BET between the oAR and
>the nAR. The smaller of the two timers (Tunnel requester or responder)
>should be the one that determines the lifetime of the
>tunnel. Negotiation does not mean multiple exchange of messages
>between the tunnel end-points. 
>
>Reason: 
>Flexibility of deployments especially wherein you have different
>domains with differing policies for the way they deal with traffic
>coming from within or an external network. 
> 

I think the current draft has aAR controlling the tunnel
lifetime, but I agree that the above proposal would be desirable. The intent
of having the aAR control the tunnel lifetime is that an
aAR may be serving as an anchor for many tunnels, and so
it may have need to limit the lifetime of tunnels that
it can support. But one could make the same argument for the
other end of the tunnel.


>Proposal 2: The support for tunnel refresh or renewal of the lifetime 
>of the tunnel should be made known at the time of tunnel setup via 
>a flag which indicates whether the tunnel originator or terminator 
>allows it. In case either router does not support tunnel refresh, the 
>other router needs to react appropriately.
>
>Reason: Prevents subsequent signaling in the network to try to refresh 
>the tunnel and discover at that point that the refresh is not possible, 
>thus introducing possible latency in the MN handoff. As soon as BETH 
>is completed and the MN has moved at L2, the nAR can instruct the 
>MN to do get a nCoA. The proposal also provides a mechanism for the 
>network of either oAR or nAR to somehow indicate to the MN to HO to 
>the nAR at a certain time based on local network policies.
>

This sounds reasonable to me as well.

Unless anyone else in the WG has objections, can you send specific proposed 
wording changes in the draft to Gopal (cc'ing me at kempf42@yahoo.com)?

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 18:38:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10548
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 18:38:57 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00515;
	Fri, 12 Oct 2001 15:38:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07423;
	Fri, 12 Oct 2001 15:38:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMbrML014087
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:37:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CMbrks014086
	for mobile-ip-dist; Fri, 12 Oct 2001 15:37:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from heliopolis.eng.sun.com (bigbang.Eng.Sun.COM [152.70.8.30])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMboML014079
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:37:50 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA01024
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:37:53 -0700 (PDT)
Message-Id: <200110122237.PAA01024@heliopolis.eng.sun.com>
Date: Fri, 12 Oct 2001 15:37:52 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [mobile-ip] Improving BETH: MN acknowledgement after adopting nCoA
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: eQ2XLRrwmq81n4KV0Ne8rQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Sreemanthula,

Again, thanx for the proposal.

>
>Current BETH:
>According to draft-kempf-beth-ipv6-02.txt, the BET tunnels can be torn
>down after the MN forms the nCoA and after performing the mobility
>procedures to update the HA and the CN.  After adopting the nCoA,
>neither the MN nor the CN use the oCoA and therefore the BET tunnel is
>not required and can be released.  
>
>Proposal:
>Introduce a specific mechanism to trigger the tear down of BET tunnels
>based on a message sent by the MN.
>
>Reason: 
>The decision to tear down the tunnel with current BETH can be based e.g.
>simply on the tunnel lifetime or on the amount of traffic on the BET,
>but there is no definitive indication of when the tunnels are not needed
>anymore. Thus, the BET must be maintained till the lifetime expiration,
>or even worse the ARs can try to renew the tunnels even if they are not
>in use. MN knows if it has performed the HO to nAR after getting the
>nCoA, thus the MN can indicate whether the tunnels are needed or not.
>Different domains will manage traffic and QoS according to specific
>mechanisms and policies. For some networks it may be necessary or
>preferrable to allow the existence of BETs only for a limited period of
>time, thus it should be possible for the network to tear down the BET as
>soon as possible.
>
>

If you look at the current draft, the specification is to trigger 
tunnel teardown based on a BU to the aAR. The BU is issued when the MN has 
completed nCoA establishment. So, unless you see some problem with this
mechanism, I think the proposal is covered.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 12 18:49:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10636
	for <mobileip-archive@odin.ietf.org>; Fri, 12 Oct 2001 18:49:42 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03931;
	Fri, 12 Oct 2001 15:49:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09510;
	Fri, 12 Oct 2001 15:49:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMmcML014197
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:48:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CMmcCQ014196
	for mobile-ip-dist; Fri, 12 Oct 2001 15:48:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from heliopolis.eng.sun.com (bigbang.Eng.Sun.COM [152.70.8.30])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CMmYML014189
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 12 Oct 2001 15:48:34 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA02072;
	Fri, 12 Oct 2001 15:48:37 -0700 (PDT)
Message-Id: <200110122248.PAA02072@heliopolis.eng.sun.com>
Date: Fri, 12 Oct 2001 15:48:37 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [mobile-ip] Improving BETH: chain tunneling
To: mobile-ip@sunroof.eng.sun.com
Cc: kempf42@yahoo.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: zlb8x9ithrTW8AgsBGxRig==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Purnadi,

Comments embedded.

>Current BETH:
> 
>According to draft-kempf-beth-ipv6-02.txt, in the model for the "handoff
>to third" a new BET tunnel is established from the anchor AR (aAR) to
>the new AR (nAR). Since the MN may maintain the BET tunnels for a while,
>there may be some issues related to QoS. In fact, in order to guarantee
>that the BET tunnel supports the QoS needed by the MN, we need to either
>assume that an SLA is in place between the oAR and nAR or that
>"pre-defined" QoS is allocated between the oAR and the nAR. However,
>since it is not possible to foresee a-priori where the MN is going to
>handoff to and since the BET tunnels will be established not only
>between "adjacent" routers but also between non-adjacent routers (HTT
>case), the adoption of SLAs or pre-defined QoS in order to guarantee the
>QoS for the MN over the tunnel does not scale well. 

Can you explain why this is any different than standard MIPv6?

>As an alternative,
>at the BET establishment a QoS negotiation can take place to ensure the
>QoS for the tunnel will be supported. However, such QoS negotiation may
>in some situations introduce some latency.
>
>		       new tunnel
>       || ==============================================||
>       ||                                               ||
>  +-------+                  +-------+               +-------+
>  |       |    old tunnel    |       |               |       |
>  |  aAR  | ================ | oAR   |               |  nAR  |
>  |       |                  |       |               |       |
>  +-------+                  +-------+               +-------+
>
>            Original BETH procedure
>
>  +-------+                  +-------+                +-------+
>  |       |    old tunnel    |       |  new tunnel    |       |
>  | aAR   | ================ | oAR   | ===============|  nAR  |
>  |       |                  |       |                |       |
>  +-------+                  +-------+                +-------+
>
>            Proposed Beth enhancement
>
>Proposed enhancement:
> 
>We propose that the BETH model should accommodate the option of "chain
>tunneling" where, in case of handoff to third, the oAR creates a new
>tunnel to the nAR. The procedure to establish the new BET tunnel from
>oAR to the nAR is  the same as the procedure to establish the initial
>tunnel from the aAR to the oAR. 
>

The difficulty with this proposal is that it introduces the possibility
of routing loops if the MN moves back to aAR. Can you explain how you would 
avoid that, short of forcing the MN to always establish
a nCoA on nAR?

>Reason:
>
>Different domains will manage traffic and QoS according to specific
>mechanisms and policies. Some networks may prefer to support QoS for BET
>tunnels by pre-allocating QoS between physically adjacent routers, i.e.
>router to which the MN can move in "one step" due to handoff. Given a
>router, the number of physically adjacent routers is limited, and the
>amount of QoS "pre-allocated" can be determined, e.g. for cellular
>links, based on the amount of radio links that can be accepted in a cell
>as handoff links (this is already being done in cellular networks, thus
>there is no impact on L2). The use of chain tunnels and pre-allocated
>QoS is a scalable solution that allows for fast handoffs and guaranteed
>QoS with minimal network configuration.
>
>Result:
>
>Creating long tunnel chains may have issues, e.g. many routers in the
>chain need to maintain the state. The chaining issues, however, can be
>reduced by forcing the MN to obtain a new COA every time it does a BETH
>Handoff. 

This issue comes up all the time, and I am curious why. People
seem to have difficulty with the concept of removing all
IP signalling so that you just have the bare minimum latency. Basically,
any introducion of MIP signalling on handover is going to result
in a disruption of the real time traffic on handover on low
speed links, period. The whole point of BETH is to let the MN decide when to 
perform handover, or have the network force handover if its required.

>The proposed chain tunneling plus the network ability to force
>the MN to obtain nCoA and to move to the nAR, solve the issue related to
>chain tunneling. For fast moving MN, a new BETH handoff may take place
>before the MN has created nCoA and moved to the nAR,thus multiple
>tunnels may exist at the same time. However, multiple tunnels are only
>temporary.
>
>

The network is *always* in a position to force handover. If an AR 
requires that the MN establish a nCoA to force QoS negotiation
or for any other reason, it can send an unsolicited Router Advert
and the MN must perform the handover.

		jak



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 03:43:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21754
	for <mobileip-archive@lists.ietf.org>; Mon, 15 Oct 2001 03:43:01 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24756;
	Mon, 15 Oct 2001 01:41:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18879;
	Mon, 15 Oct 2001 00:41:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9F7eoML018004
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 00:40:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9F7enQU018003
	for mobile-ip-dist; Mon, 15 Oct 2001 00:40:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9F7ekML017996
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 00:40:46 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00431
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 00:40:49 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08632
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 00:40:48 -0700 (PDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9F7eeC02428;
	Mon, 15 Oct 2001 09:40:42 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id JAA01980; Mon, 15 Oct 2001 09:40:40 +0200
Message-ID: <3BCA9261.B8BC44B7@era.ericsson.se>
Date: Mon, 15 Oct 2001 09:38:09 +0200
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
CC: mobile-ip@sunroof.eng.sun.com, mip6@sfc.wide.ad.jp
Subject: Re: [mobile-ip] Draft 15
References: <200110050835.f958ZJD21331@givry.rennes.enst-bretagne.fr>
		<m34rpdhlxe.fsf@test9.crm.mot.com>
		<3BC204D4.21A103A5@era.ericsson.se> <20011012.075740.68539035.ryuji@sfc.wide.ad.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Ryuji Wakikawa wrote:
> 
> Hi Mattias.
> 
> I guess the detail of implementation may not be an appropriate issue
> in this ML, but I want to make our implementation points clear.
> sorry about that.
> 
> > I had a look at your code Ryuji, and I thought that home addresses are
> > assigned to a special virtual interface called mobileipxx. Care-of
> 
> Yes, I prepared the virtual network interface to support multiple network
> interfaces/CoAs with single home address.
> 
> > addresses can be assigned to multiple physical interfaces, and they can
> > have different characteristics. Each home address can use any CoA it
> > prefers at any time. However, there is not much use really to have
> > multiple home addresses, unless the home network is being renumbered.
> 
> Maybe, but supporting multiple home addresses is not the exact our
> main purpose for using the virtual network interface.
> I summarize the idea below.
> 
> If the home address is assigned to the real network interfaces, MIP6 can
> not handle multiple IFs/CoAs simultaneously.

That is not necessarily true. As BSD implements loose routing (between
interfaces) the home address can be assigned to any interface. The
problem is that the home address is derived from a real interface
identifier and that removal of the physical interface card is
disasterous.

> I believe that using virtual network interface is the ideal design
> for this purpose on the UNIX.

I agree.

> Our implementation.
> 
>         mobileip (virutal)
>          Homeaddr
>            |
>    +--------------+
>    |              |
>    ep             wlp   (physical)
>    CoA1           CoA2
> 
>    MIP6 can use both network interfaces simultaneously,
>    whenever they are available.
> 
> Your implementation.

We had this behaviour in our first release. In the second, we used a
virtual interface, just like you (we used lo0). Actually, the first
release allowed you to specify any interface you'd like to assign the
home address to, so lo0 was possible to select too.

However, we choose to clean this up for the second release in order to
support renumbering and tunneling of RA from the home agent.

> 
>    +-------------+
>    |             |
>    ep           wlp    (physical)
>    CoA1         CoA2
>    Homeaddr
> 
>    Where can you put the home address
>    when multiple IFs are available at the same time?

As I said above, BSD will accept incoming packets no matter what
interface the destination address is assigned to.

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 05:29:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22353
	for <mobileip-archive@lists.ietf.org>; Mon, 15 Oct 2001 05:29:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04861;
	Mon, 15 Oct 2001 03:26:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14624;
	Mon, 15 Oct 2001 02:27:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9F9QAML018242
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 02:26:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9F9QA87018241
	for mobile-ip-dist; Mon, 15 Oct 2001 02:26:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9F9Q6ML018234
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 02:26:06 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09646
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 02:26:09 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01909
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 02:26:08 -0700 (PDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA00113 for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 02:26:08 -0700 (MST)]
Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA09476 for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 02:26:07 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 15 Oct 2001 01:06:33 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP id 312B72ED42
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:34:21 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
References: <Pine.LNX.4.33.0110122320320.9262-100000@netcore.fi>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 14 Oct 2001 22:36:29 +0200
In-Reply-To: <Pine.LNX.4.33.0110122320320.9262-100000@netcore.fi>
Message-Id: <m3ofna6jsi.fsf@test9.crm.mot.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 26
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Pekka Savola <pekkas@netcore.fi> writes:
>  1) usage of Home Address Option.  Its use need not be
> authenticated.  Anyone can put it in.  This makes _one-way_ (nice
> enough for UDP and ICMP) IP spoofing less than trivial.

It looks to me you're describing an attacker that puts a Home Address
option in a random packet towards a victim, without using any Mobile
IPv6 features (notably, without any BU's), right?

>  - mobile nodes (at least) MUST have forwarding via routing headers
> enabled.  This can be used to e.g. reflect traffic by laundering (DoS,
> security disclosure, ...) by anyone in the Internet.  This works for TCP
> connections too.

If I understand correctly your scenario: attacker sends packets
containing a routing header first to "victim MN" and then "victim MN"
would route them to a victim2 elsewhere; victim2 will not realize who
is the true attacker, it would believe the attacker is the "victim
MN".  Right?  If so, then this is not related to Mobile IPv6, I think.

> http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

Yes, thank you for the draft.  I replied in private, my comments not
related to Mobile IPv6 or the requirements draft.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 06:40:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22894
	for <mobileip-archive@lists.ietf.org>; Mon, 15 Oct 2001 06:40:02 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18727;
	Mon, 15 Oct 2001 04:38:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29184;
	Mon, 15 Oct 2001 03:38:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FAbwML018386
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 03:37:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FAbwuY018385
	for mobile-ip-dist; Mon, 15 Oct 2001 03:37:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FAbtML018378
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 03:37:55 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15860
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 03:37:55 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18103
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 04:37:35 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9FAbq931930
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 13:37:52 +0300
Date: Mon, 15 Oct 2001 13:37:52 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <m3ofna6jsi.fsf@test9.crm.mot.com>
Message-ID: <Pine.LNX.4.33.0110151328370.31771-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On 14 Oct 2001, Alexandru Petrescu wrote:
> Pekka Savola <pekkas@netcore.fi> writes:
> >  1) usage of Home Address Option.  Its use need not be
> > authenticated.  Anyone can put it in.  This makes _one-way_ (nice
> > enough for UDP and ICMP) IP spoofing less than trivial.
> 
> It looks to me you're describing an attacker that puts a Home Address
> option in a random packet towards a victim, without using any Mobile
> IPv6 features (notably, without any BU's), right?

Yes.

> >  - mobile nodes (at least) MUST have forwarding via routing headers
> > enabled.  This can be used to e.g. reflect traffic by laundering (DoS,
> > security disclosure, ...) by anyone in the Internet.  This works for TCP
> > connections too.
> 
> If I understand correctly your scenario: attacker sends packets
> containing a routing header first to "victim MN" and then "victim MN"
> would route them to a victim2 elsewhere; victim2 will not realize who
> is the true attacker, it would believe the attacker is the "victim
> MN".  Right?  If so, then this is not related to Mobile IPv6, I think.

Not quite.  

Victim2 would see packets coming from the direction of 'victim MN', and 
if the source address is spoofed, this trail leads to 'vicim MN', not the 
actual attacker.  This is an issue, but nothing new.

What I tried to say is that if a router/packet filter guarding victim MN
and victim2 would pass the intended traffic to victim MN but _not_
victim2, this will get around the block as destination address is
overwritten.

These problems, in itself, are not Mobile IPv6 specific.  I don't claim 
them to be.  There are some consequences, though, combined with Home 
Address usage.

But the _real problem_, one could say caused by MIPv6, is that all nodes
(at least all mobile nodes) _must_ have this Routing Header processing
enabled.  One could say MIPv6, as defined, may open every mobile node for
abuse.

If there was no MIPv6, there would be no strong need to be able to process 
routing headers in hosts, only a few, possibly hand-picked, routers.  The 
risks would be manageable.

As you see, MIPv6 appears to make the Routing Header abuse problem the 
reality.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 07:02:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23339
	for <mobileip-archive@lists.ietf.org>; Mon, 15 Oct 2001 07:02:15 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01956;
	Mon, 15 Oct 2001 05:01:44 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18244;
	Mon, 15 Oct 2001 04:01:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FB0VML018494
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 04:00:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FB0VJ1018493
	for mobile-ip-dist; Mon, 15 Oct 2001 04:00:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FB0RML018486
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 04:00:27 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18095
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 04:00:28 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05179
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 04:00:27 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23023;
	Mon, 15 Oct 2001 07:00:25 -0400 (EDT)
Message-Id: <200110151100.HAA23023@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: mobile-ip@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt
Date: Mon, 15 Oct 2001 07:00:25 -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: Low latency Handoffs in Mobile IPv4
	Author(s)	: K. Malki et al.
	Filename	: draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt
	Pages		: 49
	Date		: 12-Oct-01
	
Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs
between subnets served by different Foreign Agents. In certain cases,
the latency involved in these handoffs can be above the threshold
required for the support of delay-sensitive or real-time services.
The aim of this document is to present two methods to achieve low-
latency Mobile IP handoffs. In addition, a combination of these two
methods is described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mobileip-lowlatency-handoffs-v4-02.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-mobileip-lowlatency-handoffs-v4-02.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:	<20011012150909.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 08:19:08 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25106
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 08:19:07 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13898;
	Mon, 15 Oct 2001 05:17:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24405;
	Mon, 15 Oct 2001 05:17:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FCGCML018669
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 05:16:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FCGCif018668
	for mobile-ip-dist; Mon, 15 Oct 2001 05:16:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FCG7ML018661
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 05:16:07 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27565
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 05:16:09 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27880
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 05:16:07 -0700 (PDT)
Received: from ban by muminmamman.lifix.fi with local (Exim 3.12 #1 (Debian))
	id 15t6f8-0002t7-00
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:16:06 +0300
Date: Mon, 15 Oct 2001 15:16:06 +0300
From: Bjorn Andersson <bjorn@lifix.fi>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Authentication requirement in RFC3012
Message-ID: <20011015151606.B20542@lifix.fi>
Mail-Followup-To: Bjorn Andersson <bjorn@lifix.fi>,
	mobile-ip@sunroof.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.20i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

RFC3012 requires that the mobile node has a security association with
either the foreign agent or the AAA infrastructure if FA challenges
are used. Why is this is a MUST? This prevents one from, for example,
making an access network that does not require any authentication,
but gives a higher QoS for those that can authenticate themselves
and have an agreement with the access provider.

What would be lost if authentication wasn't required (and if the
advertisement challenge extension would be skippable)?

Regards,
Bjorn

-- 
Bjorn Andersson <bjorn@lifix.fi>                       +358 50 341 2556
Lifix Systems Oy <http://www.lifix.fi/>                 PGP id 5AFC144B
Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 12:32:01 2001
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04365
	for <mobileip-archive@lists.ietf.org>; Mon, 15 Oct 2001 12:32:01 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24836;
	Mon, 15 Oct 2001 10:41:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11044;
	Mon, 15 Oct 2001 09:30:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FGT7ML019126
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:29:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FGT7XT019125
	for mobile-ip-dist; Mon, 15 Oct 2001 09:29:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FGT4ML019118
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:29:04 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19545
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:29:00 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10675
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:29:05 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA26408 for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:29:04 -0700 (MST)]
Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA09224 for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:29:02 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Mon, 15 Oct 2001 09:28:56 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 822ED2ED2F; Mon, 15 Oct 2001 18:24:34 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Pekka Savola <pekkas@netcore.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
References: <Pine.LNX.4.33.0110151328370.31771-100000@netcore.fi>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 15 Oct 2001 18:28:58 +0200
Message-Id: <m3adyskgtx.fsf@test9.crm.mot.com>
Lines: 46
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Pekka Savola <pekkas@netcore.fi> writes:
> On 14 Oct 2001, Alexandru Petrescu wrote:
> > Pekka Savola <pekkas@netcore.fi> writes:
> > >  1) usage of Home Address Option.  Its use need not be
> > > authenticated.  Anyone can put it in.  This makes _one-way_ (nice
> > > enough for UDP and ICMP) IP spoofing less than trivial.
> > 
> > It looks to me you're describing an attacker that puts a Home Address
> > option in a random packet towards a victim, without using any Mobile
> > IPv6 features (notably, without any BU's), right?
> 
> Yes.

So I take this as your agreement that the attack above (on the Home
Address option) is not related to Mobile IPv6, so not to be taken into
account into the requirements draft.  Moreover, a quick scan of the
-15 draft shows that care has been taken to protect nodes against
usage of the Home Address option (disconnected from BU's).  For
example state is not created in nodes receiving Home Address options.

> What I tried to say is that if a router/packet filter guarding
> victim MN and victim2 would pass the intended traffic to victim MN
> but _not_ victim2, this will get around the block as destination
> address is overwritten.

Can you give a simple, but simple, scenario of a threat?  One
paragraph?

> But the _real problem_, one could say caused by MIPv6, is that all
> nodes (at least all mobile nodes) _must_ have this Routing Header
> processing enabled.  One could say MIPv6, as defined, may open every
> mobile node for abuse.

I understand.  But I think that Routing Headers are processed by
mobile nodes not because Mobile IPv6 requires them, but because
rfc2460 requires them.

> If there was no MIPv6, there would be no strong need to be able to
> process routing headers in hosts, only a few, possibly hand-picked,
> routers.

Can you assert that Mobile IPv6 is the only protocol that relies on a
host to process a Routing Header?  Are you sure that no other IETF
protocol does so?  I would be interested to find out this too.  

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 12:48:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04987
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 12:48:30 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21011;
	Mon, 15 Oct 2001 09:47:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16527;
	Mon, 15 Oct 2001 09:46:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FGjsML019233
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:45:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FGjsOg019232
	for mobile-ip-dist; Mon, 15 Oct 2001 09:45:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FGjpML019225
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:45:51 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01731
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:45:53 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02711
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 09:45:52 -0700 (PDT)
Received: from auds952.usa.alcatel.com ([143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA08765
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:45:52 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9FGjpF03441
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:45:51 -0500 (CDT)
Message-ID: <3BCB0362.955EA9B6@alcatel.com>
Date: Mon, 15 Oct 2001 11:40:18 -0400
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Pine.LNX.4.33.0110111013250.21038-100000@netcore.fi>
		<3BC5DBBD.1548E5B4@iprg.nokia.com>
		<15301.56952.774758.130701@thomasm-u1.cisco.com>
		<3BC609F2.D6ACF8A6@iprg.nokia.com>
		<15302.3941.78567.628465@thomasm-u1.cisco.com>
		<3BC61CA7.73D3D6F4@iprg.nokia.com> <15302.16878.224113.877607@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael Thomas wrote:

> Jari T. Malinen writes:
>  > I believe Jari Arkko did a nice work outlining 4 alternative
>  > ways of protecting the BU. All of them do not call for the
>  > removal of piggybacking, []
>
>    The primary reason the analysis of piggybacking is in
>    there is because removal of piggybacking is what is
>    necessary to make IPsec work.

So what is wrong with having BU/Back on separate packets possibly on a
different protocol field? This is how Mobile IPv4 works. Afterall
BU/Back are registration, i.e. control packets so there are conceptual
gains, i.e. protocol design is better,  to be made this way.

> Hence, this entire
>    discussion is moot because nobody's talking about
>    creating a new middle header.
>
>             Mike

Why is the discussion moot?

Regards,

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 14:13:28 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08434
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 14:13:27 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26168;
	Mon, 15 Oct 2001 11:05:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21158;
	Mon, 15 Oct 2001 10:36:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FHZBML019503
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:35:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FHZBZc019502
	for mobile-ip-dist; Mon, 15 Oct 2001 10:35:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FHZ7ML019495
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:35:08 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15915
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:35:08 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05790
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:35:07 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9FHZ5702092
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 20:35:05 +0300
Date: Mon, 15 Oct 2001 20:35:04 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <m3adyskgtx.fsf@test9.crm.mot.com>
Message-ID: <Pine.LNX.4.33.0110152002340.1930-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On 15 Oct 2001, Alexandru Petrescu wrote:
> Pekka Savola <pekkas@netcore.fi> writes:
> > On 14 Oct 2001, Alexandru Petrescu wrote:
> > > Pekka Savola <pekkas@netcore.fi> writes:
> > > >  1) usage of Home Address Option.  Its use need not be
> > > > authenticated.  Anyone can put it in.  This makes _one-way_ (nice
> > > > enough for UDP and ICMP) IP spoofing less than trivial.
> > > 
> > > It looks to me you're describing an attacker that puts a Home Address
> > > option in a random packet towards a victim, without using any Mobile
> > > IPv6 features (notably, without any BU's), right?
> > 
> > Yes.
> 
> So I take this as your agreement that the attack above (on the Home
> Address option) is not related to Mobile IPv6, so not to be taken into
> account into the requirements draft.

Wrong.

Mobile IPv6 adds Home Address option.  If there was no MIPv6, there would
be no HA and there would be no attack.  Thus MIPv6 is "responsible" for
this behaviour (ie: security of home address option).

>  Moreover, a quick scan of the
> -15 draft shows that care has been taken to protect nodes against
> usage of the Home Address option (disconnected from BU's).  For
> example state is not created in nodes receiving Home Address options.

No state protects only against one kind of DoS, namely, overloading the 
state machine or exhausting memory.

I have yet to see _anything_ that would protect e.g. against:

src host=spoofed-someone/real-someone
dst host=victim
dst option, home address=victim-i-want-to-blame/someone-victim-trusts
udp header, dst port=111

and some nice exploit/DoS in the payload.

The fact remains that the destinations will always see source as 
"someone-victim-trusts", even if it has never received any binding updates 
or anything MIPv6-specific, save the home address option.

If I have missed this scenario, please clarify?
 
> > What I tried to say is that if a router/packet filter guarding
> > victim MN and victim2 would pass the intended traffic to victim MN
> > but _not_ victim2, this will get around the block as destination
> > address is overwritten.
> 
> Can you give a simple, but simple, scenario of a threat?  One
> paragraph?

Not easy, unless something can be assumed, host[1,...,N] defined, and
perhaps a diagram drawn.

"Mobile hosts must process routing header.  Having to enable routing
header processing for everyone is dangerous as it can be used to reflect
traffic and to get around packet filters' access lists."

More would require pretty specific elaboration on how processing works.
 
> > But the _real problem_, one could say caused by MIPv6, is that all
> > nodes (at least all mobile nodes) _must_ have this Routing Header
> > processing enabled.  One could say MIPv6, as defined, may open every
> > mobile node for abuse.
> 
> I understand.  But I think that Routing Headers are processed by
> mobile nodes not because Mobile IPv6 requires them, but because
> rfc2460 requires them.

RFC2460 appears to be intentionally vague about this.  There are different
opinions on this.  I think 2460 may have been made this way so that MIPv6
etc. would work.

It's clear that RH processing would be disabled on hosts by default (if
for nothing else, the IPv4 Host Requirements RFC), if not for MIPv6.
 
> > If there was no MIPv6, there would be no strong need to be able to
> > process routing headers in hosts, only a few, possibly hand-picked,
> > routers.
> 
> Can you assert that Mobile IPv6 is the only protocol that relies on a
> host to process a Routing Header?  Are you sure that no other IETF
> protocol does so?  I would be interested to find out this too.  

This was discussed (rather duologous conversation between me and Francis 
Dupont) on ipng last month under subject "Routing Header Considered 
Harmful".

Microsoft mentioned using something called "round-trip traceroute" as an
option IIRC, which may use routing header w/ hosts.  I don't recall any
other possible requirement.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 14:18:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08592
	for <mobileip-archive@lists.ietf.org>; Mon, 15 Oct 2001 14:18:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05890;
	Mon, 15 Oct 2001 12:15:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01693;
	Mon, 15 Oct 2001 11:15:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FIEDML019793
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:14:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FIEDeD019792
	for mobile-ip-dist; Mon, 15 Oct 2001 11:14:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FIE9ML019785
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:14:09 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18729
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:14:05 -0700 (PDT)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13094
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:14:09 -0700 (PDT)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09YCGK>; Mon, 15 Oct 2001 14:13:10 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA7B@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
Date: Mon, 15 Oct 2001 14:13:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hung,

	Is the entire mobility scheme based on RFC2002? Or do you have
another level beneath that, say
802.11?

-Sharif.

-----Original Message-----
From: Bui, Hung [mailto:Hung.Bui@Nextel.com]
Sent: Monday, October 15, 2001 1:54 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP


Jim,

Our mobile IP implementation is according to RFC2002.

This service is available nationwide, so it is available in San Diego.  You
need any handset which is internet ready (the I-Plus model).

Cheers,
Hung

-----Original Message-----
From: Jim Willkie [mailto:jwillkie@qualcomm.com]
Sent: Thursday, September 13, 2001 9:39 AM
To: mobile-ip@sunroof.eng.sun.com; 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP

At 09:02 AM 9/12/2001 -0400, Bui, Hung wrote:
>Dear Sharif,
>
>I am working for Nextel Communications, Inc.  I joined Nextel last month.
>
>Today, Nextel is actually deploying Mobile IP.  We have over 2 millions
>mobile IP node subscribers.
>
>Please let me know should you have any questions on commercial mobile IP
>system.  As I am new here, I may not have all the answers for you.

Mr. Hung:
A couple of brief questions regarding the Nextel MobileIP deployment:

1) Is this a packet data deployment? Is it VOIP?

2) I presume this deployment is for a wireless service. Is this correct?

3) Are static IP address assignment used? How about dynamic IP address
assignments? Do you folks do both?

4) Is this service available in San Diego, Calif?

Thank you, Jim Willkie


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 14:33:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09007
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 14:33:50 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26462;
	Mon, 15 Oct 2001 12:33:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06358;
	Mon, 15 Oct 2001 11:33:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FIVeML019891
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:31:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FIVdPA019890
	for mobile-ip-dist; Mon, 15 Oct 2001 11:31:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FIVaML019883
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:31:36 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23514
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:31:32 -0700 (PDT)
Received: from strange.qualcomm.com (strange.qualcomm.com [129.46.64.124])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09008
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 11:31:35 -0700 (PDT)
Received: from MOBILEIP.qualcomm.com (mobileip.qualcomm.com [129.46.216.133])
	by strange.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f9FIVHG23184;
	Mon, 15 Oct 2001 11:31:17 -0700 (PDT)
Message-Id: <4.3.1.2.20011015013521.01f7bb30@clea.qualcomm.com>
X-Sender: nabrol@clea.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 15 Oct 2001 02:11:36 -0700
To: charliep@iprg.nokia.com, pcalhoun@diameter.org,
        mobile-ip@sunroof.eng.sun.com
From: Nish Abrol <nabrol@qualcomm.com>
Subject: [mobile-ip] rfc3012 interpretation question
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_939134854==_.ALT"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--=====================_939134854==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Pat/Charlie and other RFC3012 cognizant folks,

A question regarding the  interpretation of section 8 of rfc3012. This 
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the 
high order byte which was already used in the MD5 calculation  be included 
again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator be 
calculated  as:
     (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

       where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems  that 
calculating the MD5 authenticator with the same information(high order 
byte) at different locations of the payload weakens the authenticator.

So, what was the intention of the RFC and how should it be implemented? 
Also, do you know if RFC3012 implementations have participated in any 
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.





--=====================_939134854==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Pat/Charlie and other RFC3012 cognizant folks,<br>
<br>
A question regarding the&nbsp; interpretation of section 8 of rfc3012.
This section specifies how to calculate the MN-AAA authenticator. It
says:<br>
<br>
&quot; To compute the authenticator, apply MD5 [11] computed on the<br>
following data, in the order shown:<br>
<br>
High-order byte from Challenge || Key ||<br>
MD5(Preceding Mobile IP data ||<br>
Type, Subtype (if present), Length, SPI) ||<br>
Least-order 237 bytes from Challenge &quot;<br>
<br>
The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation&nbsp; be
included again as part of the&nbsp; &quot;least-order 237 bytes from
Challenge&quot;?<br>
<br>
e.g. if the challenge is 50 bytes in length - should the authenticator be
calculated&nbsp; as:<br>
&nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator = md5(byte0 || key.......||
byte1 through byte49)<br>
<br>
or (b) authenticator = md5(byte0 || key ......|| <u>byte0 </u>through
byte49).<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the most significant byte
of the challenge.<br>
<br>
A strict reading of the RFC seems to suggest (b). However, it seems&nbsp;
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.<br>
<br>
So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?<br>
<br>
Your help will be really appreciated.<br>
<br>
Thanks<br>
Nish Abrol<br>
Qualcomm, Inc.<br>
<br>
<br>
<br>
<br>
</html>

--=====================_939134854==_.ALT--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 14:51:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09339
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 14:51:21 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11213;
	Mon, 15 Oct 2001 11:50:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25721;
	Mon, 15 Oct 2001 10:53:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FHqIML019673
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:52:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FHqI8p019672
	for mobile-ip-dist; Mon, 15 Oct 2001 10:52:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FHqEML019665
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:52:14 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05212
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:52:10 -0700 (PDT)
Received: from atlsnmx1.nextel.com (nat-167-20.nextel.com [168.73.245.70])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16626
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 10:52:09 -0700 (PDT)
Received: from atlntgw02.nextel.com (atlntgw02.nextel.com [10.8.79.186])
	by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id NAA02271
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 13:52:12 -0400 (EDT)
Received: by atlntgw02.nextel.com with Internet Mail Service (5.5.2650.21)
	id <4JZ0ZW82>; Mon, 15 Oct 2001 13:52:18 -0400
Message-ID: <D456C897C3DBD311816F0008C716D05107BBC173@NHQNTEX02.nextel.com>
From: "Bui, Hung" <Hung.Bui@Nextel.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
Date: Mon, 15 Oct 2001 13:54:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Jim,

Our mobile IP implementation is according to RFC2002.

This service is available nationwide, so it is available in San Diego.  You
need any handset which is internet ready (the I-Plus model).

Cheers,
Hung

-----Original Message-----
From: Jim Willkie [mailto:jwillkie@qualcomm.com]
Sent: Thursday, September 13, 2001 9:39 AM
To: mobile-ip@sunroof.eng.sun.com; 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP

At 09:02 AM 9/12/2001 -0400, Bui, Hung wrote:
>Dear Sharif,
>
>I am working for Nextel Communications, Inc.  I joined Nextel last month.
>
>Today, Nextel is actually deploying Mobile IP.  We have over 2 millions
>mobile IP node subscribers.
>
>Please let me know should you have any questions on commercial mobile IP
>system.  As I am new here, I may not have all the answers for you.

Mr. Hung:
A couple of brief questions regarding the Nextel MobileIP deployment:

1) Is this a packet data deployment? Is it VOIP?

2) I presume this deployment is for a wireless service. Is this correct?

3) Are static IP address assignment used? How about dynamic IP address
assignments? Do you folks do both?

4) Is this service available in San Diego, Calif?

Thank you, Jim Willkie


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 17:07:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11761
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 17:07:37 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18462;
	Mon, 15 Oct 2001 15:06:07 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06393;
	Mon, 15 Oct 2001 14:06:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FL5AML020400
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:05:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FL5Aht020399
	for mobile-ip-dist; Mon, 15 Oct 2001 14:05:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FL56ML020392
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:05:06 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23218
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:05:08 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11768
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:16:37 -0600 (MDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9FL5AQ06855
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 16:05:10 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T569d84b395ac12f256126@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Mon, 15 Oct 2001 16:05:07 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 15 Oct 2001 16:05:06 -0500
content-class: urn:content-classes:message
Subject: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
Date: Mon, 15 Oct 2001 16:05:06 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCE6E@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
Thread-Index: AcFVvRDuxxbygcFzEdWxCQAAhj/HZA==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 15 Oct 2001 21:05:06.0832 (UTC) FILETIME=[112B6100:01C155BD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9FL57ML020393
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello,

I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI for the Foreign
Agent and Home Agent. These NAIs are carried in the Reg_Req and
Reg_Resp messages of Mobile IPv4. The draft does not specify the
applicability of these NAIs. What do you believe will be the need and
the use for NAIs asociated with Foreign agents and Home Agents? 
Is there a real need for HA/FA NAIs? Comments, opinions...

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 17:26:11 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12498
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 17:26:11 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28891;
	Mon, 15 Oct 2001 14:24:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10407;
	Mon, 15 Oct 2001 14:23:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FLM4ML020497
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:22:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FLM4vX020496
	for mobile-ip-dist; Mon, 15 Oct 2001 14:22:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FLM0ML020489
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:22:00 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05310
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:21:55 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01070
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:21:41 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA00741
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:21:59 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9FLLwE26813
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:21:58 -0700
X-mProtect:  Mon, 15 Oct 2001 14:21:58 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpddDSNzd; Mon, 15 Oct 2001 14:21:55 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA17660 for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:21:56 -0700 (PDT)
Message-ID: <3BCB5374.3221BC2@iprg.nokia.com>
Date: Mon, 15 Oct 2001 14:21:56 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
References: <697DAA22C5004B4596E033803A7CEF444CCE6E@daebe007.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

"Patil Basavaraj (NET/Dallas)" wrote:
> 
> Hello,
> 
> I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI for the Foreign
> Agent and Home Agent. These NAIs are carried in the Reg_Req and
> Reg_Resp messages of Mobile IPv4. The draft does not specify the
> applicability of these NAIs. What do you believe will be the need and
> the use for NAIs asociated with Foreign agents and Home Agents?
> Is there a real need for HA/FA NAIs? Comments, opinions...
> 
> -Basavaraj

FA NAI can be used to identify a visited network or visited domain
in case of LMM.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 17:56:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13393
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 17:56:28 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12414;
	Mon, 15 Oct 2001 14:54:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16764;
	Mon, 15 Oct 2001 14:47:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FLkVML020661
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:46:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FLkVM9020660
	for mobile-ip-dist; Mon, 15 Oct 2001 14:46:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FLkSML020653
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:46:28 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16477
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:46:29 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21979
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:46:10 -0600 (MDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9FLktQ26584
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 16:46:55 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T569daa8eceac12f257079@davir04nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Mon, 15 Oct 2001 16:46:28 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 15 Oct 2001 16:46:27 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
Date: Mon, 15 Oct 2001 16:46:27 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCE71@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
Thread-Index: AcFVv5r29hpKU8GxEdWBTQBQi2X+DwAAyqUA
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 15 Oct 2001 21:46:27.0816 (UTC) FILETIME=[D7F37E80:01C155C2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9FLkSML020654
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

>"Patil Basavaraj (NET/Dallas)" wrote:
>> 
>> Hello,
>> 
>> I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI for the Foreign
>> Agent and Home Agent. These NAIs are carried in the Reg_Req and
>> Reg_Resp messages of Mobile IPv4. The draft does not specify the
>> applicability of these NAIs. What do you believe will be the need and
>> the use for NAIs asociated with Foreign agents and Home Agents?
>> Is there a real need for HA/FA NAIs? Comments, opinions...
>> 
>> -Basavaraj
>
>FA NAI can be used to identify a visited network or visited domain
>in case of LMM.
>

Identify the visited network/domain to the MN? But the agent
advertisement does not carry the FA NAI (at least not according to the
I-D). Did you mean something else with your statement, especially
since you introduce LMMs into this thread.

>-Jari

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 18:01:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13739
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 18:01:33 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14777;
	Mon, 15 Oct 2001 15:00:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26227;
	Mon, 15 Oct 2001 14:58:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FLulML020797
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:56:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FLulRK020796
	for mobile-ip-dist; Mon, 15 Oct 2001 14:56:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FLuhML020789
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:56:43 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19512
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:56:44 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29969
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 14:56:43 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA03953
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 16:56:42 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 15 Oct 2001 16:49:56 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LZNHY>; Mon, 15 Oct 2001 16:56:07 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D42158CD@zrc2c014.us.nortel.com>
From: "Mohamed Khalil" <mkhalil@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05. txt)
Date: Mon, 15 Oct 2001 16:55:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C155C4.2AA2AE20"
X-Orig: <mkhalil@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C155C4.2AA2AE20
Content-Type: text/plain;
	charset="iso-8859-1"

For applications of FA-NAI refer to:

draft-ietf-mobileip-reg-tunnel-05.txt
draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt

-----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Monday, October 15, 2001 4:05 PM
To: 'Mobile IP'
Subject: [mobile-ip] NAIs for HA and FA
(draft-ietf-mobileip-gnaie-05.txt)


Hello,

I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI for the Foreign
Agent and Home Agent. These NAIs are carried in the Reg_Req and
Reg_Resp messages of Mobile IPv4. The draft does not specify the
applicability of these NAIs. What do you believe will be the need and
the use for NAIs asociated with Foreign agents and Home Agents? 
Is there a real need for HA/FA NAIs? Comments, opinions...

-Basavaraj

------_=_NextPart_001_01C155C4.2AA2AE20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] NAIs for HA and FA =
(draft-ietf-mobileip-gnaie-05.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>For applications of FA-NAI refer to:</FONT>
</P>

<P><FONT SIZE=3D2>draft-ietf-mobileip-reg-tunnel-05.txt</FONT>
<BR><FONT =
SIZE=3D2>draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Patil Basavaraj (NET/Dallas) [<A =
HREF=3D"mailto:Basavaraj.Patil@nokia.com">mailto:Basavaraj.Patil@nokia.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, October 15, 2001 4:05 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Mobile IP'</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] NAIs for HA and FA</FONT>
<BR><FONT SIZE=3D2>(draft-ietf-mobileip-gnaie-05.txt)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI =
for the Foreign</FONT>
<BR><FONT SIZE=3D2>Agent and Home Agent. These NAIs are carried in the =
Reg_Req and</FONT>
<BR><FONT SIZE=3D2>Reg_Resp messages of Mobile IPv4. The draft does not =
specify the</FONT>
<BR><FONT SIZE=3D2>applicability of these NAIs. What do you believe =
will be the need and</FONT>
<BR><FONT SIZE=3D2>the use for NAIs asociated with Foreign agents and =
Home Agents? </FONT>
<BR><FONT SIZE=3D2>Is there a real need for HA/FA NAIs? Comments, =
opinions...</FONT>
</P>

<P><FONT SIZE=3D2>-Basavaraj</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C155C4.2AA2AE20--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 18:32:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14525
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 18:32:15 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00505;
	Mon, 15 Oct 2001 16:31:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05419;
	Mon, 15 Oct 2001 15:31:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FMTiML021013
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:29:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FMTiAP021012
	for mobile-ip-dist; Mon, 15 Oct 2001 15:29:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FMTeML021005
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:29:40 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13773
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:29:41 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07889
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 16:41:12 -0600 (MDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9FMU8Q29471
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 17:30:08 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T569dd21df5ac12f257079@davir04nok.americas.nokia.com>;
 Mon, 15 Oct 2001 17:29:40 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 15 Oct 2001 17:29:40 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
Date: Mon, 15 Oct 2001 17:29:40 -0500
Message-ID: <57A26D272F67A743952F6B4371B8F811378268@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFVvT2Fg/S67sGvEdWBTQBQi2X+DwAC0F8Q
From: "Le Franck (NRC/Dallas)" <Franck.Le@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "aaa-wg" <aaa-wg@merit.edu>
X-OriginalArrivalTime: 15 Oct 2001 22:29:40.0250 (UTC) FILETIME=[E12987A0:01C155C8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9FMTeML021006
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

There is a discussion on the AAA mailing list "MN migration to new realm
/ draft-mobileip-08-alpha01": a Mobile node may be moving from  Foreign
domain 1, where it has been assigned a dynamic HA, to Foreign Domain 2;
and the MN wants to keep its HA. 
The MN's AAAh needs to be informed of the Home agent address to know
where to send the HAR.
The HA NAI can probably be used in this case .

Franck

> -----Original Message-----
> From: ext Patil Basavaraj (NET/Dallas) 
> Sent: 15 October, 2001 4:05 PM
> To: 'Mobile IP'
> Subject: [mobile-ip] NAIs for HA and FA
> (draft-ietf-mobileip-gnaie-05.txt)
> 
> 
> Hello,
> 
> I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI for the Foreign
> Agent and Home Agent. These NAIs are carried in the Reg_Req and
> Reg_Resp messages of Mobile IPv4. The draft does not specify the
> applicability of these NAIs. What do you believe will be the need and
> the use for NAIs asociated with Foreign agents and Home Agents? 
> Is there a real need for HA/FA NAIs? Comments, opinions...
> 
> -Basavaraj
> 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 18:32:28 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14539
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 18:32:28 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29062;
	Mon, 15 Oct 2001 15:32:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05429;
	Mon, 15 Oct 2001 15:31:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FMTxML021027
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:29:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FMTwIt021026
	for mobile-ip-dist; Mon, 15 Oct 2001 15:29:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FMTtML021015
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:29:55 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27556
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:29:56 -0700 (PDT)
Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA28620
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 16:29:34 -0600 (MDT)
Message-ID: <20011015222948.53181.qmail@web13905.mail.yahoo.com>
Received: from [216.98.102.225] by web13905.mail.yahoo.com via HTTP; Mon, 15 Oct 2001 15:29:48 PDT
Date: Mon, 15 Oct 2001 15:29:48 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I have some comments on the latest low latency V4
draft.

General comment: There are many cases in the document
in which prescriptive, normative statements are made
about the protocol that are not phrased in RFC 2119
language. For example, pg. 16, paragraph 3:

"...Therefore tunneling advertisements is only
applicable where the TTL limitation of [1] can be
relaxed. This should be the case for unicast
messages."

Is the last "should" really a SHOULD? Or is it a MUST?
There are many other examples. The language here needs
to be tightened.

1) pg. 3 end of paragraph 2, Appendix B. 
Appendix B is very tentative and not very well tied to
the protocol discussed. There may well be ways to do
intertechnology handoff that do involve the protocol.
For example, suppose the 2nd interface has no IP
address, and the MN discovers the new AP/FA via either
L2 information on the second interface, or via a
capabilities discovery protocol through the configured
interface (such as the Seamoby CAR discovery
protocol). The MN could then issue a ProxyRtSol on the
configured interface for the new FA, and when it
received the ProxyRtAdv, it could tear down the home
IP address on the old interface and transfer it to the
new. This has nothing to do with low latency handoff,
but it is a use of the protocol that would allow
seamless handover to a new interface. Note that this
would avoid having the MN solicit a regular FA Advert
over multiple subnets.

I'm not sure how to address this issue. Perhaps
folding the Appendix into the text with a discussion
of about how the protocol could, in fact, support
intertechnology handover would be appropriate.
Alternatively, given the urgency of getting this
document out, perhaps sectioning it off into a
separate document would be better.

2) pg. 4, definition of bi-directional edge tunneling-
This still includes text implying that bicasting is
required. I would suggest changing the first and
second sentences to:

"A set of unidirectional tunnels established between
two FAs for purposes of temporarily routing a MN's
traffic to/from  it on a new subnet without requiring
the MN to change CoA."

3) pg. 22, point 4c
The requirements language needs tightening (specific
case of general comment.) How about:

"c) When the MN receives the L2-LU, it MAY initiate
the Mobile IP Registration process by soliciting an
Agent Advertisement as described in [1]. If the
Registration is successful, the nFA takes over the
role of anchor FA (aFA) from the oFA. The MN MAY also
choose to defer nCoA establishment, if real time
traffic is occuring (see Section 4.4)."

4) pg. 24, Section 4.2, paragraph 1.
The requirement level of MAY for HTT is too weak.
There are some radio protocols where HTT is required,
others where it may not be. It needs tightening. I
would suggest the following wording:

"For radio L2 protocols in which it is possible for
the MN to move so rapidly from one FA to another that
that a probability exists that nCoA establishment on
the initial nFA will not complete, HTT MUST be
implemented. For other radio L2 protocols with
sufficient L2 trigger support, HTT SHOULD be
implemented as it provides the opportunity for the MN
to optimize handover of real time traffic at the
expense of a certain amount of header overhead on the
backbone network."

5) pg. 30, Section 4.4, point 1)
"...sending the an Agent Advertisement to the MN..."
->
"...sending an Agent Advertisement to the MN"

6) pg. 30, Section 4.4
The discussion in this section is valuable and useful,
but too restrictive IMHO and also does not consider a
couple of other cases. First off, is the FA
necessarily
always the default router? Secondly, if not, then the
FA registration, and, in addition, the HA registration
need to be renewed as well. Thirdly, since the routing
through the tunnel for POST-REG is already set up,
what is the problem with simply renewing down the
tunnel to the old default router and/or FA, and to the
HA?

As a practical matter, I think most BETs will be
terminated well before the 30 min. lifetime of the
default router advert (phone calls reputedly last on
the average about 3 minutes). But unless there are any
specific issues affecting interoperability, I believe
exactly when the network or MN should demand
termination of the BET should be left up to the
implementation. One such case obviously is if HTT is
not implemented, in that case, the MN must terminate
the BET after the first handoff.

7) pg. 32, definition of Lifetime, pg. 33 definition
of Lifetime:
0xffff should be defined as "good until canceled",
not "infinite".

8) pg. 36, Section 6, first paragraph
This paragraph is trying to say that for particular
radio protocols, deployment situations, and
implementations, smoothing techniques may be required,
but it is very ambiguous and hard to figure out what
is being said, IMHO. The title of the section should
be changed to "Handoff Smoothing Considerations" and
the language should be tightened to address the issue
directly. 

9) Appendix A, also reference [2]
During IETF 51, there was some discussion about not
wanting to put a reference in to the abstract L2
triggers draft in order not to end up with a reference
to a draft that was not close to RFC, to avoid slowing
down the progress of low latency. Yet, here is a
potential reference to exactly such a draft. How close
to RFC is the regional registration draft? Would it
make sense to remove the reference, since, while
extremely useful in the global picture of optimizing
MIP signalling, the relationship between regional
registration and low latency handover is somewhat
tenuous.

                             jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 15 18:37:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14667
	for <mobileip-archive@odin.ietf.org>; Mon, 15 Oct 2001 18:37:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01193;
	Mon, 15 Oct 2001 15:36:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15637;
	Mon, 15 Oct 2001 15:35:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FMYtML021182
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:34:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FMYtbL021181
	for mobile-ip-dist; Mon, 15 Oct 2001 15:34:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FMYpML021174
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:34:52 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06376
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:34:53 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11506
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:34:53 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA08035
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:34:52 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9FMYqW07511
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:34:52 -0700
X-mProtect:  Mon, 15 Oct 2001 15:34:52 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdOhBtjH; Mon, 15 Oct 2001 15:34:50 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id PAA17901 for <mobile-ip@sunroof.eng.sun.com>; Mon, 15 Oct 2001 15:34:50 -0700 (PDT)
Message-ID: <3BCB648A.BE211FA2@iprg.nokia.com>
Date: Mon, 15 Oct 2001 15:34:50 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt)
References: <697DAA22C5004B4596E033803A7CEF444CCE71@daebe007.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

"Patil Basavaraj (NET/Dallas)" wrote:
> 
> >"Patil Basavaraj (NET/Dallas)" wrote:
> >>
> >> Hello,
> >>
> >> I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI for the Foreign
> >> Agent and Home Agent. These NAIs are carried in the Reg_Req and
> >> Reg_Resp messages of Mobile IPv4. The draft does not specify the
> >> applicability of these NAIs. What do you believe will be the need and
> >> the use for NAIs asociated with Foreign agents and Home Agents?
> >> Is there a real need for HA/FA NAIs? Comments, opinions...
> >>
> >> -Basavaraj
> >
> >FA NAI can be used to identify a visited network or visited domain
> >in case of LMM.
> >
> 
> Identify the visited network/domain to the MN? But the agent
> advertisement does not carry the FA NAI (at least not according to the
> I-D). Did you mean something else with your statement, especially
> since you introduce LMMs into this thread.
> 
> -Basavaraj

It is an optional feature of the movement detection in the
IPv4 regional registration. If FA advertises only its GMA, movement
detection needs FA-NAI. If agent adv will be cleared of FA-NAI, this
document is affected.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 03:42:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06948
	for <mobileip-archive@lists.ietf.org>; Tue, 16 Oct 2001 03:42:00 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05581;
	Tue, 16 Oct 2001 01:41:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03909;
	Tue, 16 Oct 2001 00:41:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9G7dwOI000879
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 00:39:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9G7dwfK000878
	for mobile-ip-dist; Tue, 16 Oct 2001 00:39:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9G7dsOI000871
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 00:39:54 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03700
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 00:39:57 -0700 (PDT)
Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02274
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 00:39:53 -0700 (PDT)
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id KAA28252
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:36:31 +0300
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma028248; Tue, 16 Oct 01 10:36:22 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f9G7bAD23923;
	Tue, 16 Oct 2001 10:37:10 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id KAA01720;
	Tue, 16 Oct 2001 10:39:18 +0300 (EEST)
X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs
Date: Tue, 16 Oct 2001 10:39:18 +0300 (EEST)
From: Henrik Petander <lpetande@tml.hut.fi>
To: mobile-ip@sunroof.eng.sun.com
cc: Catharina Linnea Candolin <candolin@tml.hut.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
Message-ID: <Pine.SOL.4.10.10110161027170.1627-100000@morphine.tml.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi,

Here are some comments on the draft:

1) Replay protection : MN and HA are assumed to have an existing security
association. If it is a manually configured shared secret, i.e., not
created dynamically, replay protection becomes an issue in the subnets of
MN and HA. Still replay protection is not mentioned in the requirements
and neither is replay attacks in the threats section. 

Replay attacks can be generally divided into a) DoS attacks where an
attacker in same subnet as MN, HA (or CN) replays BU of MN to HA (or CN)  
to a random address and b) redirect attacks where the attacker located in
old foreign subnet of MN replays the BU from MN and configures itself with
old CoA to get packets to home address of MN.

2) Different requirements for HAs. The draft handles HAs differently
depending on whether they are "foreign" HAs or "normal" HAs. Still both
kinds of HAs provide exactly the same HA services to MN. MIPv6 protocol
does not define any differences. The difference between how MN and its
"normal" HA and how MN and its foreign "HA" interact is only a matter of
policy. Thus also the security assumptions and requirements for the
protocol should probably be the same.

3) The requirement of authenticating ICMP DHAAD requests should be made
less strict or removed altogether. If IPSec is used for authenticating it,
MN needs to have a SA for an anycast address. AFAIK, this is not possible.
If MN wants to do DHAAD with its old foreign network HAs, how could it
dynamically create a SA with the home agents anycast address?

4) The requirement H.3 of not allowing the processing of the home address
option, if it is not authorized, in practice prevents triangle routing. We
agree with the analysis of the threat H.3 caused by home address option,
though. This should be specified more excatly if authorization for home
address option is required.

5) The draft seems to accept or implicitly propose an authorization
mechanism, which is vulnerable to attackers located in the subnets of MN,
CN or HA. From a security point of view these vulnerabilities should be
avoided if possible in the first place. Later adding an option to use more
secure alternatives such as SUCV, CAM, etc. does not really add to the
security, if a less secure mechanism based on return routability is still
mandatory. Also first creating a less secure mechanism and later adding
more security as an "optimization" does not work, since vendors will from
interoperability reasons support the old mechanisms and most
administrators probably do not really understand their difference.

It should be noted that any authorization mechanism for BUs based on
return routability is not applicable to CNs on insecure links (for example
MN in its home WLAN acting as a CN) and its use MUST be configurable.

6) The requirement D.2 of authenticating BRs is useful only if MN uses
reverse tunneling via HA or mechanisms decribed in 7.2.3. If MN uses
triangle routing, CN gets to know both the home address and the care-of
addresses of MN by pinging the home address. The effect is the same. If
BRs should be accepted only from CNs MN is already communicating with, the
same requirement should apply to triangle routing.
  
Editorial comments:

1) 7.3 Requirement B.4 is ambiguous. It should be ...mobile node SHOULD
ensure the sender of the BA was authorized to send it.  Now the text gives
the impression that MN should generally trust the sender, whereas MN
should actually trust that the sender of the BA was the node to which MN
sent the BU and which is authorized to send the BA.


Regards,

Henrik Petander,
Catharina Candolin

		----------------------------------
		Henrik Petander 		
		Helsinki University of Technology,	
		GO/Core Project 
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846 
		GSM: +358 (0)40 741 5248	
		----------------------------------





From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 05:29:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08160
	for <mobileip-archive@lists.ietf.org>; Tue, 16 Oct 2001 05:29:37 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10924;
	Tue, 16 Oct 2001 02:29:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18772;
	Tue, 16 Oct 2001 02:29:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9G9SDOI001088
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 02:28:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9G9SD5S001087
	for mobile-ip-dist; Tue, 16 Oct 2001 02:28:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9G9S9OI001080
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 02:28:09 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02901
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 02:28:11 -0700 (PDT)
Received: from HKISRV06.teleware.fi (mail.teleware.fi [193.65.76.33])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12078
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 02:28:09 -0700 (PDT)
Received: from hkisrv08.teleware.fi ([10.204.2.28]) by HKISRV06.teleware.fi with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 16 Oct 2001 12:27:24 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
Date: Tue, 16 Oct 2001 12:28:07 +0300
Message-ID: <EE9F3A089F0B01499C5782E7CFA93527013B7B@hkisrv08.teleware.fi>
Thread-Topic: [mobile-ip] Commercial deployment o Mobile IP
Thread-Index: AcFVopwAhoiK18wUSSC5b8McuVDeqwAfDUoA
From: "Anssi Porttikivi" <anssi.porttikivi@teleware.fi>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 16 Oct 2001 09:27:24.0188 (UTC) FILETIME=[C38095C0:01C15624]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9G9SAOI001081
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

I don't quite understand, what kind of system yours is. Are the some
dual-mode handsets commercially available, that can roam from one radio
standard/network to another (satellite, CPDP, PCS, GSM,..) based on
Mobile IP foreign agent reachability? I doubt that! If the mobile node
only roams within base stations / access points of your one (satellite?)
radio network, how does it even know when to re-register its new IP
location to the HA, and why should it in the first place?

>From: Bui, Hung [mailto:Hung.Bui@Nextel.com]
>Sent: 15. lokakuuta 2001 20:54
>To: 'mobile-ip@sunroof.eng.sun.com'
>Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
>
>Our mobile IP implementation is according to RFC2002.
>
>This service is available nationwide, so it is available in San Diego.
You
>need any handset which is internet ready (the I-Plus model).


>Cheers,
>Hung


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 05:54:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08372
	for <mobileip-archive@lists.ietf.org>; Tue, 16 Oct 2001 05:54:06 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17942;
	Tue, 16 Oct 2001 02:53:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05281;
	Tue, 16 Oct 2001 02:53:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9G9qXOI001183
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 02:52:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9G9qWl0001182
	for mobile-ip-dist; Tue, 16 Oct 2001 02:52:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9G9qTOI001175
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 02:52:29 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28395
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 02:52:31 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05968
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 04:06:14 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9G9qS707382;
	Tue, 16 Oct 2001 12:52:28 +0300
Date: Tue, 16 Oct 2001 12:52:28 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Catharina Linnea Candolin <candolin@tml.hut.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
In-Reply-To: <Pine.SOL.4.10.10110161027170.1627-100000@morphine.tml.hut.fi>
Message-ID: <Pine.LNX.4.33.0110161237260.7307-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Henrik Petander wrote:
> 3) The requirement of authenticating ICMP DHAAD requests should be made
> less strict or removed altogether. If IPSec is used for authenticating it,
> MN needs to have a SA for an anycast address. AFAIK, this is not possible.
> If MN wants to do DHAAD with its old foreign network HAs, how could it
> dynamically create a SA with the home agents anycast address?

I don't follow this line of though.  If ICMP DHAAD cannot be done
securely, why should the requirements be made less strict to allow it to
be done insecurely?  What point would there be in security if the
requirements could be waived when they may be inconvenient?

If this cannot be worked around, perhaps best course would be to remove
ICMP DHAAD altogether for now like mobile routers, and specify it better
later, when it can be done properly.

> 4) The requirement H.3 of not allowing the processing of the home
> address option, if it is not authorized, in practice prevents triangle
> routing. We agree with the analysis of the threat H.3 caused by home
> address option, though. This should be specified more excatly if
> authorization for home address option is required.

Let me phrase it this way:

If a CN does not have a binding for the MN, would there be any need for CN
to process HA option?

I don't think so, but I may be wrong.

A probable corner-case is establishing the binding, which has even more
reason to be done securely.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords





From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 07:17:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09433
	for <mobileip-archive@lists.ietf.org>; Tue, 16 Oct 2001 07:17:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01599;
	Tue, 16 Oct 2001 05:16:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28733;
	Tue, 16 Oct 2001 04:16:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GBFnOI001349
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 04:15:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GBFnmg001348
	for mobile-ip-dist; Tue, 16 Oct 2001 04:15:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GBFjOI001341
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 04:15:45 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28563
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 04:15:26 -0700 (PDT)
Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29259
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 04:15:31 -0700 (PDT)
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id OAA31187
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:12:11 +0300
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma031181; Tue, 16 Oct 01 14:12:03 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f9GBCrD26060
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:12:53 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id OAA03596
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:15:02 +0300 (EEST)
X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs
Date: Tue, 16 Oct 2001 14:15:02 +0300 (EEST)
From: Henrik Petander <lpetande@tml.hut.fi>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
In-Reply-To: <Pine.LNX.4.33.0110161237260.7307-100000@netcore.fi>
Message-ID: <Pine.SOL.4.10.10110161320110.1627-100000@morphine.tml.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Pekka Savola wrote:

> On Tue, 16 Oct 2001, Henrik Petander wrote:
> > 3) The requirement of authenticating ICMP DHAAD requests should be made
> > less strict or removed altogether. If IPSec is used for authenticating it,
> > MN needs to have a SA for an anycast address. AFAIK, this is not possible.
> > If MN wants to do DHAAD with its old foreign network HAs, how could it
> > dynamically create a SA with the home agents anycast address?
> 
> I don't follow this line of though.  If ICMP DHAAD cannot be done
> securely, why should the requirements be made less strict to allow it to
> be done insecurely?  

Bad choice of words from me. The comment on the requirement of
authenticating DHAAD being difficult to do was not meant as a reason not
to authenticate DHAAD, but as a comment on the feasibility of doing it.

IMHO the authenticating of DHAAD requests should be optional or a SHOULD,
since the threats DHAAD creates are not relevant in many cases. The home
agents can still be found locally from router advertisments sent to the
home subnet or remotely possibly with traceroute or pinging the all home
agents anycast address, etc. Actually a more relevant threat is a faked
reply to MN, which would result in MN sending BUs to nonexistant
addresses.

On closer reading I noticed also a sentence about using HA as a packet
reflector in 6.8., Result H.1. This should probably be in some other
section (header for H.2?) since DHAAD does create any new opportunities
for DoS using HA as a packety reflector when compared to other ICMP types.

> 
> If this cannot be worked around, perhaps best course would be to remove
> ICMP DHAAD altogether for now like mobile routers, and specify it better
> later, when it can be done properly.

The authentication requirements for anycast DHAAD requests probably make
it more convenient to use some workaround, e.g, configure MN with the DNS
name or the IP address of its home agent and then possibly send DHAAD
requests to the unicast address.

> 
> > 4) The requirement H.3 of not allowing the processing of the home
> > address option, if it is not authorized, in practice prevents triangle
> > routing. We agree with the analysis of the threat H.3 caused by home
> > address option, though. This should be specified more excatly if
> > authorization for home address option is required.
> 
> Let me phrase it this way:
> 
> If a CN does not have a binding for the MN, would there be any need for CN
> to process HA option?

Yes, if the CN does not support route optimization and the MN sends
packets directly to it. CNs with minimal protocol stacks probably will not
support route optimization, whereas processing the home address option
requires only very little effort and no state from a CN. Even if a CN
supports route optimization, a MN can send a BU to the CN only after
receiving the first tunneled packet from the CN.

Henrik

		----------------------------------
		Henrik Petander 		
		Helsinki University of Technology,	
		GO/Core Project 
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846 
		GSM: +358 (0)40 741 5248	
		----------------------------------



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 08:42:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12846
	for <mobileip-archive@lists.ietf.org>; Tue, 16 Oct 2001 08:42:53 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24090;
	Tue, 16 Oct 2001 06:42:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15637;
	Tue, 16 Oct 2001 05:42:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GCfXOI001539
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 05:41:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GCfX3Y001538
	for mobile-ip-dist; Tue, 16 Oct 2001 05:41:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GCfSOI001531
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 05:41:29 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GCfRq00062;
	Tue, 16 Oct 2001 14:41:27 +0200 (MET DST)
Date: Tue, 16 Oct 2001 14:36:11 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] protecting BUs
To: jmalinen@iprg.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3BC5E66A.D09C9D7F@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.1003235771.32157.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> A new upper layer is easy since it is at the end of the packet,
> I was more thinking in general terms if you add a new header to
> any place in the ordering. Before routing hdr and esp. before
> hop-by-hop there would be problems.

Huh?

How can the supposed router know where the end of the packet is
when the h-b-h header contains a next hdr value which the router
doesn't recognize? The next hdr = 254 could be a new transport protocol
or a new intermediate next hdr, but if the router doesn't know 254
it doesn't know.

In any case, if everybody follows this advise
in RFC 1122 the problem goes away as far as I can tell.


      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 09:18:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16521
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 09:18:32 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18573;
	Tue, 16 Oct 2001 07:17:20 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14113;
	Tue, 16 Oct 2001 06:17:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GDFOOI001636
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:15:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GDFNKO001635
	for mobile-ip-dist; Tue, 16 Oct 2001 06:15:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GDFJOI001628
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:15:20 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26748
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:15:22 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29979
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:15:20 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GDFJ908561
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 16:15:19 +0300
Date: Tue, 16 Oct 2001 16:15:19 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
In-Reply-To: <Pine.SOL.4.10.10110161320110.1627-100000@morphine.tml.hut.fi>
Message-ID: <Pine.LNX.4.33.0110161551280.8342-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Henrik Petander wrote:
> > > 4) The requirement H.3 of not allowing the processing of the home
> > > address option, if it is not authorized, in practice prevents triangle
> > > routing. We agree with the analysis of the threat H.3 caused by home
> > > address option, though. This should be specified more excatly if
> > > authorization for home address option is required.
> > 
> > Let me phrase it this way:
> > 
> > If a CN does not have a binding for the MN, would there be any need for CN
> > to process HA option?
> 
> Yes, if the CN does not support route optimization and the MN sends
> packets directly to it. CNs with minimal protocol stacks probably will not
> support route optimization, whereas processing the home address option
> requires only very little effort and no state from a CN. Even if a CN
> supports route optimization, a MN can send a BU to the CN only after
> receiving the first tunneled packet from the CN.

Am I right by saying:

 - with Home Address, without BU: the route will be suboptimal, but 
mobility (connections break if MN changes IP address) will still work.
 - with Home Address, with BU: route will be optimal and mobility works.
 - without Home Address, without BU: the route will be optimal and 
mobility will not work
 - without Home Address, with BU: route will be optimal but mobility will 
not work.

That is, 

if HA
  mobility
  if BU
    route optimization
  fi
else
  route optimization
fi

From above, the only reason why HA should be useful for a dummy node not
implementing BU is mobility (non-breaking connections).  Is that scenario
relevant enough to justify non-authorized HA usage?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 09:37:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18717
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 09:37:39 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01370;
	Tue, 16 Oct 2001 06:37:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22515;
	Tue, 16 Oct 2001 06:37:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GDXLOI001766
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:33:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GDXLMU001765
	for mobile-ip-dist; Tue, 16 Oct 2001 06:33:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GDXFOI001758
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:33:17 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GDXFq06215;
	Tue, 16 Oct 2001 15:33:15 +0200 (MET DST)
Date: Tue, 16 Oct 2001 15:28:00 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
To: pekkas@netcore.fi
Cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0110122320320.9262-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> --8<--
> I have may have missed something, but it appears to me that two scenarios
> discussed in more detail:
> 
>  1) usage of Home Address Option.  Its use need not be authenticated.
> Anyone can put it in.  This makes _one-way_ (nice enough for UDP and ICMP)
> IP spoofing less than trivial.
> --8<--
> 
> This has not been commented by anyone.

When the HA option was designed there wasn't a good understanding
of reflectors for DoS attacks, thus the analysis of the HA option
security doesn't take this into account.

Do you expect the result of this is that HA options can not be used unless
athenticated and authorized?
This seems to imply that some significant work is needed to change MIPv6
so that an HA option is not sent until the CN has the HA->CoA mapping
in its binding cache. This would be a significant change because today
a CN can garbage collect binding cache entries at will which doesn't
seem to work if the MN needs to know for sure that a binding cache entry
exists before sending the HA option.


> I think SecReqs document should also address the following issues:
> 
> (new)
>  - mobile nodes (at least) MUST have forwarding via routing headers
> enabled.  This can be used to e.g. reflect traffic by laundering (DoS,
> security disclosure, ...) by anyone in the Internet.  This works for TCP
> connections too.

I think it is useful to clarify this in both the security requirements doc
and in the MIPv6 spec.
Note that the MN does not need be able to forward in general for MIPv6
to work - the next hop when processing the routing header is the MN itself.

So it makes sense to state this in the security req draft and also
make the MIPv6 spec say that a MN processing a routing header should,
unless it is serving as a router for other purposes, only process routing
headers where the MN itself (one of its Home Addresses) is the next=last hop
in the routing header.

   Erik

>  - use of home address may allow one to perform DoS attacks w/ source
> address spoofing, among others.  Home Option must be processed in every
> IPv6 node even if there is no BU or anything that will use it.  This could
> get nasty.
> 
> These are covered, to some extent, in:
> 
> http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt
> 
> I'd definitely want to have these issues taken into consideration when
> considering different MIPv6 security options, as these could basically
> affect every IPv6 node, whether mobile or not, in the end..
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> 
> 
> 
> 




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 09:54:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20551
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 09:54:30 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15487;
	Tue, 16 Oct 2001 07:53:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24962;
	Tue, 16 Oct 2001 06:53:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GDqpOI001892
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:52:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GDqp24001891
	for mobile-ip-dist; Tue, 16 Oct 2001 06:52:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GDqlOI001884
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 06:52:47 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11080;
	Tue, 16 Oct 2001 06:52:48 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24377;
	Tue, 16 Oct 2001 08:06:38 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GDqij08764;
	Tue, 16 Oct 2001 16:52:44 +0300
Date: Tue, 16 Oct 2001 16:52:44 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0110161638420.8663-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Erik Nordmark wrote:
> > --8<--
> > I have may have missed something, but it appears to me that two scenarios
> > discussed in more detail:
> > 
> >  1) usage of Home Address Option.  Its use need not be authenticated.
> > Anyone can put it in.  This makes _one-way_ (nice enough for UDP and ICMP)
> > IP spoofing less than trivial.
> > --8<--
> > 
> > This has not been commented by anyone.
> 
> When the HA option was designed there wasn't a good understanding
> of reflectors for DoS attacks, thus the analysis of the HA option
> security doesn't take this into account.
> 
> Do you expect the result of this is that HA options can not be used unless
> athenticated and authorized?

Yes.

Yes, it's painful :-(.

But I don't especially like the idea of being able to spoof the source 
address at will either.  And having this kind of feature integrated so 
deeply in IPv6 that it can never be dug out.

> > I think SecReqs document should also address the following issues:
> > 
> > (new)
> >  - mobile nodes (at least) MUST have forwarding via routing headers
> > enabled.  This can be used to e.g. reflect traffic by laundering (DoS,
> > security disclosure, ...) by anyone in the Internet.  This works for TCP
> > connections too.
> 
> I think it is useful to clarify this in both the security requirements doc
> and in the MIPv6 spec.
> Note that the MN does not need be able to forward in general for MIPv6
> to work - the next hop when processing the routing header is the MN itself.
> 
> So it makes sense to state this in the security req draft and also
> make the MIPv6 spec say that a MN processing a routing header should,
> unless it is serving as a router for other purposes, only process routing
> headers where the MN itself (one of its Home Addresses) is the next=last hop
> in the routing header.

Yes, which is why I suggested another routing header type (say Type 2) 
altogether, to clearly separate the processing of the two.  And to make it 
distinguishable by intermediate nodes (e.g. packet filters), which could 
IMO be of big help in the long run.

A more straightforward approach would be to revise Type 0 processing rules
as you pointed out.  This has its own caveats too (think of
"private"/"public" addresses assigned on the same node), outlined in
"Security Considerations" of my draft:
 
http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 10:08:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22215
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 10:08:33 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25752;
	Tue, 16 Oct 2001 08:07:05 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27181;
	Tue, 16 Oct 2001 07:07:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GE5LOI002015
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:05:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GE5LAd002014
	for mobile-ip-dist; Tue, 16 Oct 2001 07:05:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GE5HOI002007
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:05:17 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26670
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:05:18 -0700 (PDT)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12967;
	Tue, 16 Oct 2001 07:05:14 -0700 (PDT)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id f9GE2Mg02404;
	Tue, 16 Oct 2001 16:02:22 +0200 (MEST)
Message-ID: <3BCC3DF0.FC3DA5F0@inrialpes.fr>
Date: Tue, 16 Oct 2001 16:02:24 +0200
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: pekkas@netcore.fi, gab@sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements 
 for MIP v6
References: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
Content-Type: multipart/alternative;
 boundary="------------74B069EC33E83852D97F3A4F"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------74B069EC33E83852D97F3A4F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Erik Nordmark wrote:

> So it makes sense to state this in the security req draft and also
> make the MIPv6 spec say that a MN processing a routing header should,
> unless it is serving as a router for other purposes, only process routing
> headers where the MN itself (one of its Home Addresses) is the next=last hop
> in the routing header.

Actually MIPv6 uses the routing header as a destination option...

The routing headers used by a CN to send packets to a MN are
only meant to be processed by the end-host (namely the MN) and not
by the intermediate nodes...(so why using a routing header? There might be
some good or historical reasons that i don't see?)

Wouldn't it make sense to define a new destination option that will
contains the HomeAddress of the MN (very similar to the MIPv6 current
HomeAddress option by in the other direction). A CN would then send the packets
to the MN's current CoA and add this new option that contains the MN's home
address.

This would solve most of the problems described in the draft:
(1) a firewall could decide to reject all packets that contain a routing header
and MIP
would still be supported, (2) this new option could be authenticated and
possibly be encrypted for confidentiality reason....

What do you think? Did i miss something?

Thanks,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------74B069EC33E83852D97F3A4F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello,
<p>Erik Nordmark wrote:
<blockquote TYPE=CITE>So it makes sense to state this in the security req
draft and also
<br>make the MIPv6 spec say that a MN processing a routing header should,
<br>unless it is serving as a router for other purposes, only process routing
<br>headers where the MN itself (one of its Home Addresses) is the next=last
hop
<br>in the routing header.</blockquote>
Actually MIPv6 uses the routing header as a destination option...
<p>The routing headers used by a CN&nbsp;to send packets to a MN are
<br>only meant to be processed by the end-host (namely the MN) and not
<br>by the intermediate nodes...(so why using a routing header? There might
be
<br>some good or historical reasons that i don't see?)
<p>Wouldn't it make sense to define a new destination option that will
<br>contains the HomeAddress of the MN (very similar to the MIPv6 current
<br>HomeAddress option by in the other direction). A CN&nbsp;would then
send the packets
<br>to the MN's current CoA and add this new option that contains the MN's
home
<br>address.
<p>This would solve most of the problems described in the draft:
<br>(1) a firewall could decide to reject all packets that contain a routing
header and MIP
<br>would still be supported, (2) this new option could be authenticated
and
<br>possibly be encrypted for confidentiality reason....
<p>What do you think? Did i miss something?
<p>Thanks,
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------74B069EC33E83852D97F3A4F--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 10:28:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24785
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 10:28:44 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23225;
	Tue, 16 Oct 2001 07:27:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29914;
	Tue, 16 Oct 2001 07:27:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEQKOI002118
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:26:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GEQKEb002117
	for mobile-ip-dist; Tue, 16 Oct 2001 07:26:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEQGOI002110
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:26:16 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06324
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:26:18 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06572
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:26:17 -0700 (PDT)
Received: from auds951.usa.alcatel.com ([143.209.238.80])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA11274
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:26:16 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9GEQGO08126
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:26:16 -0500 (CDT)
Message-ID: <3BCC44FE.6E1EAF23@alcatel.com>
Date: Tue, 16 Oct 2001 09:32:30 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Commercial deployment o Mobile IP
References: <EE9F3A089F0B01499C5782E7CFA93527013B7B@hkisrv08.teleware.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

We constantly hear MIP being deployed but we have never heard of any usage
statistics, the info as you asked, etc.

Anssi Porttikivi wrote:

> I don't quite understand, what kind of system yours is. Are the some
> dual-mode handsets commercially available, that can roam from one radio
> standard/network to another (satellite, CPDP, PCS, GSM,..) based on
> Mobile IP foreign agent reachability? I doubt that! If the mobile node
> only roams within base stations / access points of your one (satellite?)
> radio network, how does it even know when to re-register its new IP
> location to the HA, and why should it in the first place?
>
> >From: Bui, Hung [mailto:Hung.Bui@Nextel.com]
> >Sent: 15. lokakuuta 2001 20:54
> >To: 'mobile-ip@sunroof.eng.sun.com'
> >Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
> >
> >Our mobile IP implementation is according to RFC2002.
> >
> >This service is available nationwide, so it is available in San Diego.
> You
> >need any handset which is internet ready (the I-Plus model).
>
> >Cheers,
> >Hung

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 10:37:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26059
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 10:37:51 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27748;
	Tue, 16 Oct 2001 07:37:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18450;
	Tue, 16 Oct 2001 07:37:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEaROI002219
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:36:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GEaR3B002218
	for mobile-ip-dist; Tue, 16 Oct 2001 07:36:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEaOOI002211
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:36:24 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29603
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:36:20 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17384
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:50:15 -0600 (MDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA09338 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:36:24 -0700 (MST)]
Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA15621 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:36:22 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 16 Oct 2001 09:36:15 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 369E72ED2F; Tue, 16 Oct 2001 16:31:45 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi, Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
References: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 16 Oct 2001 16:36:12 +0200
In-Reply-To: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
Message-Id: <m3bsj7mz37.fsf@test9.crm.mot.com>
Lines: 12
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Erik Nordmark <Erik.Nordmark@eng.sun.com> writes:
> When the HA option was designed there wasn't a good understanding
> of reflectors for DoS attacks, thus the analysis of the HA option
> security doesn't take this into account.
> 
> Do you expect the result of this is that HA options can not be used unless
> athenticated and authorized?

I would rather say that the HA options can not be used unless part of
an authenticated BU or similar, and not independent.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 10:46:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27188
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 10:46:10 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27000;
	Tue, 16 Oct 2001 08:45:28 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19720;
	Tue, 16 Oct 2001 07:45:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEj1OI002402
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:45:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GEj0DK002401
	for mobile-ip-dist; Tue, 16 Oct 2001 07:45:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEivOI002394
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:44:57 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00538
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:44:53 -0700 (PDT)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26214
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:44:39 -0600 (MDT)
Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id f9GEg7g03690
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 16:42:07 +0200 (MEST)
Message-ID: <3BCC4741.526059E@inrialpes.fr>
Date: Tue, 16 Oct 2001 16:42:09 +0200
From: Claude Castelluccia <claude.castelluccia@inrialpes.fr>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements  
 for MIP v6
References: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
		<3BCC3DF0.FC3DA5F0@inrialpes.fr> <m37ktvmywu.fsf@test9.crm.mot.com>
Content-Type: multipart/alternative;
 boundary="------------83EA4EAD9629B5242BF639D7"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------83EA4EAD9629B5242BF639D7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alexandru Petrescu wrote:

> Claude Castelluccia <claude.castelluccia@inrialpes.fr> writes:
> > The routing headers used by a CN to send packets to a MN are only
> > meant to be processed by the end-host (namely the MN) and not by the
> > intermediate nodes...(so why using a routing header? There might be
> > some good or historical reasons that i don't see?)
>
> I think a good reason for using routing headers for this purpose is
> that they are supposedly readily implemented by "normal" IPv6 nodes,
> so no additional implementation effort for Mobile IPv6.

A "normal" IPv6 already needs to implement the HomeAddress option in
order to
support MIPv6...so i don't buy your argument ;-)

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------83EA4EAD9629B5242BF639D7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Alexandru Petrescu wrote:
<blockquote TYPE=CITE>Claude Castelluccia &lt;claude.castelluccia@inrialpes.fr>
writes:
<br>> The routing headers used by a CN to send packets to a MN are only
<br>> meant to be processed by the end-host (namely the MN) and not by
the
<br>> intermediate nodes...(so why using a routing header? There might
be
<br>> some good or historical reasons that i don't see?)
<p>I think a good reason for using routing headers for this purpose is
<br>that they are supposedly readily implemented by "normal" IPv6 nodes,
<br>so no additional implementation effort for Mobile IPv6.</blockquote>
A "normal" IPv6 already needs to implement the HomeAddress option in order
to
<br>support MIPv6...so i don't buy your argument ;-)
<p>Claude.
<pre>--&nbsp;

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes&nbsp;&nbsp;
ph:&nbsp; +33 4.76.61.52.15 (fax: 52.52)
<A HREF="http://www.inrialpes.fr/planete/">http://www.inrialpes.fr/planete/</A></pre>
&nbsp;</html>

--------------83EA4EAD9629B5242BF639D7--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 10:50:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27788
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 10:50:40 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01331;
	Tue, 16 Oct 2001 07:44:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19027;
	Tue, 16 Oct 2001 07:40:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEe9OI002300
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:40:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GEe9ha002299
	for mobile-ip-dist; Tue, 16 Oct 2001 07:40:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEe5OI002292
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:40:05 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29994
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:40:02 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14240
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:40:06 -0700 (PDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA24429 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:40:05 -0700 (MST)]
Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA23384 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:40:05 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Tue, 16 Oct 2001 07:40:04 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id C23E42ED2F; Tue, 16 Oct 2001 16:35:34 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi, gab@sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements  for MIP v6
References: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
	<3BCC3DF0.FC3DA5F0@inrialpes.fr>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 16 Oct 2001 16:40:01 +0200
In-Reply-To: <3BCC3DF0.FC3DA5F0@inrialpes.fr>
Message-Id: <m37ktvmywu.fsf@test9.crm.mot.com>
Lines: 11
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Claude Castelluccia <claude.castelluccia@inrialpes.fr> writes:
> The routing headers used by a CN to send packets to a MN are only
> meant to be processed by the end-host (namely the MN) and not by the
> intermediate nodes...(so why using a routing header? There might be
> some good or historical reasons that i don't see?)

I think a good reason for using routing headers for this purpose is
that they are supposedly readily implemented by "normal" IPv6 nodes,
so no additional implementation effort for Mobile IPv6.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 11:04:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29502
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 11:04:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13968;
	Tue, 16 Oct 2001 09:03:26 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22559;
	Tue, 16 Oct 2001 08:03:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GF2uOI002691
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:02:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GF2uPm002690
	for mobile-ip-dist; Tue, 16 Oct 2001 08:02:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GF2qOI002680
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:02:52 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11624
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:02:54 -0700 (PDT)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27163
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:02:52 -0700 (PDT)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09Y1LR>; Tue, 16 Oct 2001 11:01:54 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA7D@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
Date: Tue, 16 Oct 2001 11:01:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Along these thoughts, I was also wondering if the Mobile IP protocol is
deployed to provide
end-to-end mobility management in these systems. 

With such a scanario, I was wondering what kind of bit-rates are attainable
in pedestrian and fast moving vehicular situations?

What is the proportion of administritive messages in the networks -- with
respect to scalability?

And, also what is the hand off speed?

It would also be helpful if these companies can make presentations on these
issues at MIP WG sessions.


-Sharif.

-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Tuesday, October 16, 2001 10:33 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Commercial deployment o Mobile IP


We constantly hear MIP being deployed but we have never heard of any usage
statistics, the info as you asked, etc.

Anssi Porttikivi wrote:

> I don't quite understand, what kind of system yours is. Are the some
> dual-mode handsets commercially available, that can roam from one radio
> standard/network to another (satellite, CPDP, PCS, GSM,..) based on
> Mobile IP foreign agent reachability? I doubt that! If the mobile node
> only roams within base stations / access points of your one (satellite?)
> radio network, how does it even know when to re-register its new IP
> location to the HA, and why should it in the first place?
>
> >From: Bui, Hung [mailto:Hung.Bui@Nextel.com]
> >Sent: 15. lokakuuta 2001 20:54
> >To: 'mobile-ip@sunroof.eng.sun.com'
> >Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
> >
> >Our mobile IP implementation is according to RFC2002.
> >
> >This service is available nationwide, so it is available in San Diego.
> You
> >need any handset which is internet ready (the I-Plus model).
>
> >Cheers,
> >Hung

--
Behcet


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 11:14:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00606
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 11:14:11 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16486;
	Tue, 16 Oct 2001 08:13:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23561;
	Tue, 16 Oct 2001 08:07:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GF6POI002765
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:06:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GF6P3l002764
	for mobile-ip-dist; Tue, 16 Oct 2001 08:06:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GF6KOI002754
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:06:21 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GF6Jq16874;
	Tue, 16 Oct 2001 17:06:19 +0200 (MET DST)
Date: Tue, 16 Oct 2001 17:01:04 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)
To: pekkas@netcore.fi
Cc: mobile-ip@sunroof.eng.sun.com,
        Catharina Linnea Candolin <candolin@tml.hut.fi>
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0110161237260.7307-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1003244464.9846.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> Let me phrase it this way:
> 
> If a CN does not have a binding for the MN, would there be any need for CN
> to process HA option?

Yes.
As MIPv6 is currently defined the MN will always (except when reverse tunneling
through the HA) include a HA option. The home address will be the address used
in higher level protocols. For instance, the TCP connection identification and
TCP pseudo-header checksum use the address in the HA option.

Thus all IPv6 implementations MUST process the HA option as MIPv6 is currently
defined.

If it turns out that this is an unacceptable source of reflectors (that can be
used for DoS attacks etc) then I suspect that the protocol needs to change
so that the HA option is only used once it is known that the CN has
accepted a BU from the MN.

Thus MIPv6 would operate in two different modes: 
before a BU is accepted doing rectangular routing i.e. reverse tunnel.
after the BU is accepted send packets directly to CN using HA option.

Changing the protocol to work this way seems to require that the MN always
ask for an ACK to BUs sent to CN so that it knows for sure when a BU
was accepted and some mechanism to recover from a CN that as accidentally
or intentionally (garbage collected) the binding cache entry.

But first let's make sure we agree on the requirement wrt the HA option.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 11:14:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00739
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 11:14:57 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16753;
	Tue, 16 Oct 2001 08:14:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21791;
	Tue, 16 Oct 2001 08:00:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GExQOI002634
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:59:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GExQxs002633
	for mobile-ip-dist; Tue, 16 Oct 2001 07:59:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GExMOI002626
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:59:22 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GExJq15947;
	Tue, 16 Oct 2001 16:59:19 +0200 (MET DST)
Date: Tue, 16 Oct 2001 16:54:04 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)
To: lpetande@tml.hut.fi
Cc: mobile-ip@sunroof.eng.sun.com,
        Catharina Linnea Candolin <candolin@tml.hut.fi>
In-Reply-To: "Your message with ID" <Pine.SOL.4.10.10110161027170.1627-100000@morphine.tml.hut.fi>
Message-ID: <Roam.SIMC.2.0.6.1003244044.19675.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> 1) Replay protection : MN and HA are assumed to have an existing security
> association. If it is a manually configured shared secret, i.e., not
> created dynamically, replay protection becomes an issue in the subnets of
> MN and HA. Still replay protection is not mentioned in the requirements
> and neither is replay attacks in the threats section. 

Agreed that the document should talk about replay threats.

> 2) Different requirements for HAs. The draft handles HAs differently
> depending on whether they are "foreign" HAs or "normal" HAs. Still both
> kinds of HAs provide exactly the same HA services to MN. MIPv6 protocol
> does not define any differences. The difference between how MN and its
> "normal" HA and how MN and its foreign "HA" interact is only a matter of
> policy. Thus also the security assumptions and requirements for the
> protocol should probably be the same.

The difference between the HA and the "previous default router action as
a HA for a previous CoA" (I sure wish there was a concise term for
the latter) is that requirement D.1 (which is really an assumption)
applies in the former case but not in the latter.

Only if you believe there will be pre-existing security associations between
the MN and all possible default routers it uses while moving around ,
does it make sense to treat them the same.

> 3) The requirement of authenticating ICMP DHAAD requests should be made
> less strict or removed altogether. If IPSec is used for authenticating it,
> MN needs to have a SA for an anycast address. AFAIK, this is not possible.
> If MN wants to do DHAAD with its old foreign network HAs, how could it
> dynamically create a SA with the home agents anycast address?

Are you saying that the reason to make the requirements weaker is because
we don't know how to implement it securely? How does this create secure 
protocols?

In reality I think it can be implemented. If the MN has some abstract SA with
its collection of home agents (the boxes that provide it with the
home agent service on its home subnet) it can clearly use that to
communicate with any HA, including the anycast address.
You do have a point if this abstract SA is implemented e.g. as an AH or ESP
SA. It would be good to understand the options in this case.
Can't the pre-establishment of such an AH or ESP SA be made with a collection
of machines i.e. some machinery to associate e.g. the same IKE pre-shared
keys with both the HA anycast address and the HA addresses that are
discovered?

So I think the requirement is a reasonable one.

> 4) The requirement H.3 of not allowing the processing of the home address
> option, if it is not authorized, in practice prevents triangle routing. We
> agree with the analysis of the threat H.3 caused by home address option,
> though. This should be specified more excatly if authorization for home
> address option is required.

Agreed.

> 5) The draft seems to accept or implicitly propose an authorization
> mechanism, which is vulnerable to attackers located in the subnets of MN,
> CN or HA. From a security point of view these vulnerabilities should be
> avoided if possible in the first place. Later adding an option to use more
> secure alternatives such as SUCV, CAM, etc. does not really add to the
> security, if a less secure mechanism based on return routability is still
> mandatory. Also first creating a less secure mechanism and later adding
> more security as an "optimization" does not work, since vendors will from
> interoperability reasons support the old mechanisms and most
> administrators probably do not really understand their difference.

Mandatory to implement doesn't imply that all CNs are required to accept
BUs with the weaker forms of security forever.
Some CNs might reject BUs for such simple reasons as not wanting
to create a huge binding cache, so rejecting them for security reasons should
be fine as well.

> It should be noted that any authorization mechanism for BUs based on
> return routability is not applicable to CNs on insecure links (for example
> MN in its home WLAN acting as a CN) and its use MUST be configurable.
> 
> 6) The requirement D.2 of authenticating BRs is useful only if MN uses
> reverse tunneling via HA or mechanisms decribed in 7.2.3. If MN uses
> triangle routing, CN gets to know both the home address and the care-of
> addresses of MN by pinging the home address. The effect is the same. If
> BRs should be accepted only from CNs MN is already communicating with, the
> same requirement should apply to triangle routing.

By "communicating with" do you mean "to which the MN has sent a BU" i.e.
"the CN is in the binding update list"?

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 11:15:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00802
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 11:15:12 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16640;
	Tue, 16 Oct 2001 08:14:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24003;
	Tue, 16 Oct 2001 08:08:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GF8COI002815
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:08:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GF8CUQ002814
	for mobile-ip-dist; Tue, 16 Oct 2001 08:08:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GF87OI002792
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:08:07 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04341
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:08:04 -0700 (PDT)
Received: from kestrel.xedia.com (kestrel.xedia.com [198.202.232.189])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00322
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:08:08 -0700 (PDT)
Received: from xedia.com ([10.198.100.16])
	by kestrel.xedia.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA82006
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:08:07 -0400 (EDT)
Message-ID: <3BCC4CAC.57ECFA9E@xedia.com>
Date: Tue, 16 Oct 2001 11:05:16 -0400
From: Kishore Asarpota <kishore@xedia.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Mobile Nodes for Testing
References: <Roam.SIMC.2.0.6.1003244044.19675.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi,

Is there a Mobile Node product out there that I can use for
testing my HA and FA routers. I am just curious to find out
what is everyone using as their MN for testing. I have the Linux
version running, is there anything else.

thx, kishore



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 11:15:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00857
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 11:15:34 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16818;
	Tue, 16 Oct 2001 08:14:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25422;
	Tue, 16 Oct 2001 08:14:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GFDJOI002992
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:13:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GFDIYg002991
	for mobile-ip-dist; Tue, 16 Oct 2001 08:13:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GFDEOI002984
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:13:15 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GFDBq17923;
	Tue, 16 Oct 2001 17:13:11 +0200 (MET DST)
Date: Tue, 16 Oct 2001 17:07:54 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
To: Pekka Savola <pekkas@netcore.fi>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0110161638420.8663-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1003244874.10507.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> But I don't especially like the idea of being able to spoof the source 
> address at will either.  And having this kind of feature integrated so 
> deeply in IPv6 that it can never be dug out.

As the analysis at the time shows (somewhere in the MIPv6 spec)
the fact that the CoA (the topologically correct) and the HA address
are present in the packet means that it isn't identical to
being able to spoof source addresses.

E.g. if X is sending packets to B with IP src = CoA = X and HAopt=A
to as part of a DoS attack against B, then when the DoS attack is
investigated by observing the packets both X and A can be seen.
With "normal" source address spoofing only A would have been in the packet.

But the problem is that if B is running any upper layer protocol that
acts as a reflector (by responding to received packets) then this can
be used to attack A. And TCP is a good reflector responding to SYN packets
by sending SYN|ACK packets.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 11:17:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01113
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 11:17:15 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25961;
	Tue, 16 Oct 2001 09:16:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14309;
	Tue, 16 Oct 2001 08:16:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GFFMOI003073
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:15:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GFFMLX003072
	for mobile-ip-dist; Tue, 16 Oct 2001 08:15:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GFFJOI003062
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:15:19 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06639
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:15:15 -0700 (PDT)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10414
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:29:12 -0600 (MDT)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09Y1N7>; Tue, 16 Oct 2001 11:14:20 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA7E@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Mobile Nodes for Testing
Date: Tue, 16 Oct 2001 11:14:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I am also interested in this, with respect to Visual C running on Windows
2000. Thanks.

-Sharif.

-----Original Message-----
From: Kishore Asarpota [mailto:kishore@xedia.com]
Sent: Tuesday, October 16, 2001 11:05 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Mobile Nodes for Testing


Hi,

Is there a Mobile Node product out there that I can use for
testing my HA and FA routers. I am just curious to find out
what is everyone using as their MN for testing. I have the Linux
version running, is there anything else.

thx, kishore


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 11:30:52 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02722
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 11:30:51 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25400;
	Tue, 16 Oct 2001 08:30:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16904;
	Tue, 16 Oct 2001 08:30:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GFSgOI003263
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:28:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GFSgGJ003262
	for mobile-ip-dist; Tue, 16 Oct 2001 08:28:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GFSdOI003255
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:28:39 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16573
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:28:41 -0700 (PDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06866
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:28:22 -0600 (MDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA15858 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:19:59 -0700 (MST)]
Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA25116 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 08:28:39 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Tue, 16 Oct 2001 08:28:33 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 5E4DB2ED2F; Tue, 16 Oct 2001 17:24:08 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi, Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
References: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
	<m3bsj7mz37.fsf@test9.crm.mot.com>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 16 Oct 2001 17:28:35 +0200
In-Reply-To: <m3bsj7mz37.fsf@test9.crm.mot.com>
Message-Id: <m3669fk3j0.fsf@test9.crm.mot.com>
Lines: 16
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9GFSdOI003256
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Alexandru Petrescu <petrescu@crm.mot.com> writes:
> Erik Nordmark <Erik.Nordmark@eng.sun.com> writes:
> > When the HA option was designed there wasn't a good understanding
> > of reflectors for DoS attacks, thus the analysis of the HA option
> > security doesn't take this into account.
> > 
> > Do you expect the result of this is that HA options can not be used unless
> > athenticated and authorized?
> 
> I would rather say that the HA options can not be used unless part of
> an authenticated BU or similar, and not independent.

Sorry for following on my message, my above comment is rather naïve
(where's the cancel key? :-)

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 12:07:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07512
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 12:07:16 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11490;
	Tue, 16 Oct 2001 10:05:42 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24188;
	Tue, 16 Oct 2001 09:05:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GG4YOI003397
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:04:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GG4YBP003396
	for mobile-ip-dist; Tue, 16 Oct 2001 09:04:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GG4VOI003389
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:04:31 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23644
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:04:33 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18186
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:04:32 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA13324
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:04:32 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 16 Oct 2001 10:57:41 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3LZW4Z>; Tue, 16 Oct 2001 11:03:53 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E6A0AC2@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] WG Last Call on Threat Model and Security Require 
         ments for MIP v6
Date: Tue, 16 Oct 2001 11:03:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1565C.24D73C70"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1565C.24D73C70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think we need to make sure that the SHOULDs and MUSTs of the security
threat draft and the MIP draft synch up.=20

-----Original Message-----
From: Alexandru Petrescu [mailto:petrescu@crm.mot.com]
Sent: Tuesday, October 16, 2001 10:29 AM
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi; Erik Nordmark
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security
Requirements for MIP v6


Alexandru Petrescu <petrescu@crm.mot.com> writes:
> Erik Nordmark <Erik.Nordmark@eng.sun.com> writes:
> > When the HA option was designed there wasn't a good understanding
> > of reflectors for DoS attacks, thus the analysis of the HA option
> > security doesn't take this into account.
> >=20
> > Do you expect the result of this is that HA options can not be used
unless
> > athenticated and authorized?
>=20
> I would rather say that the HA options can not be used unless part of
> an authenticated BU or similar, and not independent.

Sorry for following on my message, my above comment is rather na=EFve
(where's the cancel key? :-)

Alex


------_=_NextPart_001_01C1565C.24D73C70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] WG Last Call on Threat Model and Security =
Requirements  for MIP v6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think we need to make sure that the SHOULDs and =
MUSTs of the security threat draft and the MIP draft synch up. </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Alexandru Petrescu [<A =
HREF=3D"mailto:petrescu@crm.mot.com">mailto:petrescu@crm.mot.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, October 16, 2001 10:29 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Cc: pekkas@netcore.fi; Erik Nordmark</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] WG Last Call on Threat =
Model and Security</FONT>
<BR><FONT SIZE=3D2>Requirements for MIP v6</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Alexandru Petrescu &lt;petrescu@crm.mot.com&gt; =
writes:</FONT>
<BR><FONT SIZE=3D2>&gt; Erik Nordmark &lt;Erik.Nordmark@eng.sun.com&gt; =
writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; When the HA option was designed there =
wasn't a good understanding</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of reflectors for DoS attacks, thus the =
analysis of the HA option</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; security doesn't take this into =
account.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Do you expect the result of this is that =
HA options can not be used unless</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; athenticated and authorized?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would rather say that the HA options can not =
be used unless part of</FONT>
<BR><FONT SIZE=3D2>&gt; an authenticated BU or similar, and not =
independent.</FONT>
</P>

<P><FONT SIZE=3D2>Sorry for following on my message, my above comment =
is rather na=EFve</FONT>
<BR><FONT SIZE=3D2>(where's the cancel key? :-)</FONT>
</P>

<P><FONT SIZE=3D2>Alex</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1565C.24D73C70--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 13:07:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10915
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 13:07:37 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07483;
	Tue, 16 Oct 2001 11:06:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15444;
	Tue, 16 Oct 2001 10:06:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GH5FOI003569
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:05:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GH5EP2003568
	for mobile-ip-dist; Tue, 16 Oct 2001 10:05:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GH5AOI003561
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:05:10 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11031
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:05:08 -0700 (PDT)
Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18612
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:20:01 -0600 (MDT)
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id UAA04541
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 20:01:50 +0300
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma004533; Tue, 16 Oct 01 20:01:43 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f9GH2YD29574;
	Tue, 16 Oct 2001 20:02:34 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id UAA05907;
	Tue, 16 Oct 2001 20:04:42 +0300 (EEST)
X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs
Date: Tue, 16 Oct 2001 20:04:41 +0300 (EEST)
From: Henrik Petander <lpetande@tml.hut.fi>
To: mobile-ip@sunroof.eng.sun.com
cc: Catharina Linnea Candolin <candolin@tml.hut.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
In-Reply-To: <Roam.SIMC.2.0.6.1003244044.19675.nordmark@bebop.france>
Message-ID: <Pine.SOL.4.10.10110162001170.1627-100000@morphine.tml.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Erik Nordmark wrote:
>
> The difference between the HA and the "previous default router action as
> a HA for a previous CoA" (I sure wish there was a concise term for
> the latter) is that requirement D.1 (which is really an assumption)
> applies in the former case but not in the latter.
>
> Only if you believe there will be pre-existing security associations
between
> the MN and all possible default routers it uses while moving around ,
> does it make sense to treat them the same.
 
The main point was that if MN and its regular HA need a "strong" SA, so do
MN and its "foreign" HA. I agree that the assumption that MN and its HA
have a preconfigured security association might not easily apply to the
"foreign" HAs. Probably they and MN will still have an existing trust
relationship, so that they can create a "strong" SA.
 
>
> Are you saying that the reason to make the requirements weaker is
> because
> we don't know how to implement it securely? How does this create secure
> protocols?
 
See my response to Pekka's mail. The reason for not requiring it was not
the difficulty of making it work, but more related to the benefits of
authenticating the requests.
 
>
> In reality I think it can be implemented. If the MN has some abstract SA
with
> its collection of home agents (the boxes that provide it with the
> home agent service on its home subnet) it can clearly use that to
> communicate with any HA, including the anycast address.
 
I agree that it should work on a theoretical level, but I am just afraid
that specifying it to work using existing mechanisms such as IPSec may be
difficult.
 
> You do have a point if this abstract SA is implemented e.g. as an AH or
> ESP
> SA. It would be good to understand the options in this case.
 
Probably ESP or AH would be the easiest way to secure the ICMP messages in
MIPv6. Speaking of ICMP messages, I did not see any mention of the mobile
prefix solicitation and advertisement, of which at least the latter should
be authenticated, since it creates state in MN. This is already mentioned
in the draft of draft 15.
 
The authentication of DHAAD request would require that the SA between MN
and the anycast address would apply to all the HAs and that they would
share and synchronize all state for the SA. I don't know if this is
actually doable, at least replay protection would break this or make
synchonization expensive. Maybe it could work without replay protection,
though.
 
> Can't the pre-establishment of such an AH or ESP SA be made with a
> collection
> of machines i.e. some machinery to associate e.g. the same IKE
> pre-shared
> keys with both the HA anycast address and the HA addresses that are
> discovered?
 
If you establish a SA with one of the HAs, the HA receiving the DHAAD
request could be a different one. There would need to be a system to
distribute the created SA from the HA, which took part in IKE with MN, to
also the other HAs.
 
> >
> > 6) The requirement D.2 of authenticating BRs is useful only if MN uses
> > reverse tunneling via HA or mechanisms decribed in 7.2.3. If MN uses
> > triangle routing, CN gets to know both the home address and the 
> > care-of addresses of MN by pinging the home address. The effect is the
> > same. If BRs should be accepted only from CNs MN is already
> > communicating with,the same requirement should apply to triangle
> >routing.

> By "communicating with" do you mean "to which the MN has sent a BU" i.e.
> "the CN is in the binding update list"
 
More generally, the decision to reveal both the home address and care-of
address should be handled similarly by the privacy policy of MN,
regardless of the method the location and identity are revealed. (If MN
has a privacy policy not to send BUs to certain nodes, it should not use
triangle routing with those nodes.)
 
 
Henrik

		----------------------------------
		Henrik Petander 		
		Helsinki University of Technology,	
		GO/Core Project 
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846 
		GSM: +358 (0)40 741 5248	
		----------------------------------



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 13:18:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11323
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 13:18:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21721;
	Tue, 16 Oct 2001 10:17:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18468;
	Tue, 16 Oct 2001 10:17:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GHG2OI003692
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:16:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GHG2Ew003691
	for mobile-ip-dist; Tue, 16 Oct 2001 10:16:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GHFwOI003684
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:15:58 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GHFsq02693;
	Tue, 16 Oct 2001 19:15:54 +0200 (MET DST)
Date: Tue, 16 Oct 2001 18:42:31 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements  for MIP v6
To: claude.castelluccia@inrialpes.fr
Cc: mobile-ip@sunroof.eng.sun.com, pekkas@netcore.fi, gab@sun.com
In-Reply-To: "Your message with ID" <3BCC3DF0.FC3DA5F0@inrialpes.fr>
Message-ID: <Roam.SIMC.2.0.6.1003250551.1277.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> Actually MIPv6 uses the routing header as a destination option...
> 
> The routing headers used by a CN to send packets to a MN are
> only meant to be processed by the end-host (namely the MN) and not
> by the intermediate nodes...(so why using a routing header? There might be
> some good or historical reasons that i don't see?)

Yes, MIPv6 uses routing headers in a special way. Only one address in
the routing header and the IPv6 dst and the routing header address
must be assigned to the same node.
 
> Wouldn't it make sense to define a new destination option that will
> contains the HomeAddress of the MN (very similar to the MIPv6 current
> HomeAddress option by in the other direction). A CN would then send the
> packets to the MN's current CoA and add this new option that contains the
> MN's home address.

If folks want to redefine the actual packet formats as opposed to
adding rules on how routing headers are processed by MNs, then it
might make sense to go the direction of viewing this use of the routing
header as a "compressed" form of IPinIP tunneling instead of a different
destination option.
Such a compressed IPinIP option would just have one IPv6 address (since
the source address of the "tunnel" to the MN is the source address in
the IPv6 header) thus it would be the same size as the routing header
with one IPv6 address.

  Erik

> This would solve most of the problems described in the draft:
> (1) a firewall could decide to reject all packets that contain a routing
> header and MIP
> would still be supported, (2) this new option could be authenticated and
> possibly be encrypted for confidentiality reason....
> 
> What do you think? Did i miss something?
> 
> Thanks,
> 
> Claude.
> 
> --
> 
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
> 
> 




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 13:20:06 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11375
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 13:20:06 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22905;
	Tue, 16 Oct 2001 10:19:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18937;
	Tue, 16 Oct 2001 10:19:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GHINOI003724
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:18:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GHINre003723
	for mobile-ip-dist; Tue, 16 Oct 2001 10:18:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GHILOI003713
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 10:18:21 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04210
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:18:23 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA20728
	for mobile-ip@sunroof.eng.sun.com; Tue, 16 Oct 2001 13:18:54 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GAuIOI001296
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 03:56:18 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27066
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 03:56:15 -0700 (PDT)
Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22474
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 03:56:19 -0700 (PDT)
Received: by EMAIL5 with Internet Mail Service (5.5.2653.19)
	id <4TYSFQAT>; Tue, 16 Oct 2001 12:56:09 +0200
Message-ID: <BB603AE6E737D5118C0300508BB4A8119F0747@EMAIL6>
From: Philippe Cousin <Philippe.Cousin@etsi.fr>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Ipv6 interoperabilty event including mobile Ipv6 topics
Date: Tue, 16 Oct 2001 12:56:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

dear all members off the IP mobile area

As you may be aware of, ETSI is organising a second IPv6 interoperability
event  .
The registration is now open at our web site
(<http://www.etsi.org/plugtests/02UpcomingEvents/IPv6/IPv6_home.htm> ).

Key expertise from UNH (US), TAHI(JP), ERICSSON(HU) and IRISA (FR) will be
offered on site. Test tools, test cases and new test scenarios for Mobile
IPv6 will be available all the week.

As your are highly involved in Mobile IPv6 we would not miss your
participation  in order to have a maximum value at this interoperability
event . Don't miss to check that your products are interoperable with others
as well as still learning on specific technical features with are important
for you and the whole technical community.

As you know , E.T.S.I is a neutral and non-for-profit organisation and
therefore we are acting for the benfit of the Ipv6 community with the
support of the EU eEurope initiative. "ETSI brings competitors together to
advance IPv6"( see press release
<http://www.etsi.org/pressroom/Previous/2001/IPv6_event.htm>  )

We count on your participation

regards
Philippe

Philippe COUSIN
Interoperability Service Manager
Tel: + 33 (0)4 92 94 4306
Fax: +33 (0)4 93 65 4716
http://www.etsi.org/plugtests/



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 14:06:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13314
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 14:06:38 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29545;
	Tue, 16 Oct 2001 12:05:11 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27725;
	Tue, 16 Oct 2001 11:05:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GI49OI004066
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:04:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GI48va004065
	for mobile-ip-dist; Tue, 16 Oct 2001 11:04:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GI45OI004058
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:04:05 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00440;
	Tue, 16 Oct 2001 11:04:06 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22221;
	Tue, 16 Oct 2001 12:19:03 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GI44F10488;
	Tue, 16 Oct 2001 21:04:04 +0300
Date: Tue, 16 Oct 2001 21:04:03 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <Roam.SIMC.2.0.6.1003244874.10507.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0110162058310.10452-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

(no need to have me as Cc:, btw :)

On Tue, 16 Oct 2001, Erik Nordmark wrote:
> > But I don't especially like the idea of being able to spoof the source 
> > address at will either.  And having this kind of feature integrated so 
> > deeply in IPv6 that it can never be dug out.
> 
> As the analysis at the time shows (somewhere in the MIPv6 spec)
> the fact that the CoA (the topologically correct) and the HA address
> are present in the packet means that it isn't identical to
> being able to spoof source addresses.
> 
> E.g. if X is sending packets to B with IP src = CoA = X and HAopt=A
> to as part of a DoS attack against B, then when the DoS attack is
> investigated by observing the packets both X and A can be seen.
> With "normal" source address spoofing only A would have been in the packet.

True, but there is also the issue of "Double Spoofing".  X and A could 
both be spoofed (A trivially, X if there is no ingress filtering, or it's 
done so that it's not precise enough).

For example, X would be spoofed so that the originator cannot be traced, 
and A spoofed to be a node that is suspected/known to be trusted by the 
destination.
 
> But the problem is that if B is running any upper layer protocol that
> acts as a reflector (by responding to received packets) then this can
> be used to attack A. And TCP is a good reflector responding to SYN packets
> by sending SYN|ACK packets.

Also very true.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 14:08:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13441
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 14:08:44 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02226;
	Tue, 16 Oct 2001 12:08:07 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28642;
	Tue, 16 Oct 2001 11:08:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GI7WOI004119
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:07:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GI7Vsb004118
	for mobile-ip-dist; Tue, 16 Oct 2001 11:07:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GI7SOI004111
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:07:28 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01550
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:07:30 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15201
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:07:29 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA20723
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:07:28 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9GI7S407436
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:07:28 -0700
X-mProtect:  Tue, 16 Oct 2001 11:07:28 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdlAnW7F; Tue, 16 Oct 2001 11:07:26 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id LAA19388 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:07:26 -0700 (PDT)
Message-ID: <3BCC775E.1C916A9A@iprg.nokia.com>
Date: Tue, 16 Oct 2001 11:07:26 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Roam.SIMC.2.0.6.1003235771.32157.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Erik Nordmark wrote:
> 
> > A new upper layer is easy since it is at the end of the packet,
> > I was more thinking in general terms if you add a new header to
> > any place in the ordering. Before routing hdr and esp. before
> > hop-by-hop there would be problems.
> 
> Huh?
> 
> How can the supposed router know where the end of the packet is
> when the h-b-h header contains a next hdr value which the router
> doesn't recognize? The next hdr = 254 could be a new transport protocol
> or a new intermediate next hdr, but if the router doesn't know 254
> it doesn't know.

The comment was about ordering rules; if a new header were to be
required too early in the ordering, it would change how a node needs to
scan the packet before it sees e.g. hop-by-hop header or in case a node
does source routing, a routing header. If the packet is beyond routing
header by the ordering rules, it's transparent and a router or
source-routing node does not ever need to look its type. So, as you
say, a legacy node would not know unknown type, it would not observe
the new rule and not go beyond the packet. E.g. if a new header would
be before routing header by its ordering rule, a source routing node 
wouldn't scan to the routing header thus missing it.

But as discussed, this wouldn't be a problem if a new header is beyond
routing header in its ordering rules (such as an upper layer whose ordering would require it to be at end).

> In any case, if everybody follows this advise
> in RFC 1122 the problem goes away as far as I can tell.
> 
>       1.2.2  Robustness Principle
> 
>          At every layer of the protocols, there is a general rule whose
>          application can lead to enormous benefits in robustness and
>          interoperability [IP:1]:
> 
>                 "Be liberal in what you accept, and
>                  conservative in what you send"

Very much agreed, which kind of brings me back to the start of this
discussion. Though new headers could be nice, avoiding new headers
would be even more conservative. In case of protecting the BU with
IPsec, this would suggest favoring the UDP port approach over a new
header type.

And, if this is applied to piggybacking, accepting a piggybacked BU
is liberal, sending one would need dynamic enabling/disabling of it.
In case of IPsec, disable it, add the UDP port, in case of application
specific protection, allow it, do not add that UDP as upper layer.

>   Erik

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 14:14:24 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13609
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 14:14:23 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06809;
	Tue, 16 Oct 2001 12:13:10 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00160;
	Tue, 16 Oct 2001 11:13:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GICZOI004221
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:12:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GICYl6004220
	for mobile-ip-dist; Tue, 16 Oct 2001 11:12:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GICVOI004213
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:12:31 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14241;
	Tue, 16 Oct 2001 11:12:33 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06822;
	Tue, 16 Oct 2001 11:12:31 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GICSG10538;
	Tue, 16 Oct 2001 21:12:29 +0300
Date: Tue, 16 Oct 2001 21:12:28 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Alexandru Petrescu <petrescu@crm.mot.com>
cc: <mobile-ip@sunroof.eng.sun.com>, <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <m33d4jmyi8.fsf@test9.crm.mot.com>
Message-ID: <Pine.LNX.4.33.0110162105380.10452-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On 16 Oct 2001, Alexandru Petrescu wrote:
> Also, it's interesting to note that rfc1825 (superseded by rfc2401)
> states:
>    "Routing headers for which integrity has not been cryptographically
>     protected SHOULD be ignored by the receiver.  If this rule is not
>     strictly adhered to, then the system will be vulnerable to various
>     kinds of attacks, including source routing attacks [Bel89] [CB94]
>     [CERT95]."
> This shows there was a certain level of awareness of the routing
> header problem at the time of writing of that rfc.

However, it appears that RFC2460 authors wanted to leave this open in the
standards track document; the wording there (about Routing Header being
mirrored in the destination if it was authenticated) suggest they were
also aware of (at least some) AH issues.  Probably not enough.

It's also clear that RFC2401 and RFC2460 people may have had a different
view of the global, in practise, applicability of IPSEC AH.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 14:14:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13629
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 14:14:45 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01314;
	Tue, 16 Oct 2001 08:49:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20500;
	Tue, 16 Oct 2001 07:50:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEn1OI002493
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:49:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GEn07F002492
	for mobile-ip-dist; Tue, 16 Oct 2001 07:49:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEmvOI002485
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:48:57 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20329
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:48:59 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24543
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 09:02:45 -0600 (MDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA26599 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:48:51 -0700 (MST)]
Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA24866 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 07:48:50 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 16 Oct 2001 09:48:49 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 3792B2ED2F; Tue, 16 Oct 2001 16:44:20 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: pekkas@netcore.fi, Erik.Nordmark@eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6
References: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 16 Oct 2001 16:48:47 +0200
In-Reply-To: <Roam.SIMC.2.0.6.1003238880.26352.nordmark@bebop.france>
Message-Id: <m33d4jmyi8.fsf@test9.crm.mot.com>
Lines: 29
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Erik Nordmark <Erik.Nordmark@eng.sun.com> writes:
> So it makes sense to state this in the security req draft and also
> make the MIPv6 spec say that a MN processing a routing header
> should, unless it is serving as a router for other purposes, only
> process routing headers where the MN itself (one of its Home
> Addresses) is the next=last hop in the routing header.

Just a quick note on the other usages of routing header; I found by
scanning the drafts:

-hmipv6
-Mobile IPv6 Regional Forwarding
-Mobile ipv6 neighborhood routing for fast handoff
-draft-itojun-ipv6-anycast-analysis-02.txt
-Mobile IPv6 handoff by Explicit Multicast
-draft-ohnishi-mobileip-mbg-00.txt
-draft-draves-ipngwg-ingress-filtering-00.txt

Also, it's interesting to note that rfc1825 (superseded by rfc2401)
states:
   "Routing headers for which integrity has not been cryptographically
    protected SHOULD be ignored by the receiver.  If this rule is not
    strictly adhered to, then the system will be vulnerable to various
    kinds of attacks, including source routing attacks [Bel89] [CB94]
    [CERT95]."
This shows there was a certain level of awareness of the routing
header problem at the time of writing of that rfc.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 14:32:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14341
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 14:32:01 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29560;
	Tue, 16 Oct 2001 11:31:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04524;
	Tue, 16 Oct 2001 11:28:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GIRwOI004347
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:27:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GIRwDm004346
	for mobile-ip-dist; Tue, 16 Oct 2001 11:27:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GIRtOI004339
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:27:55 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02462
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 11:27:51 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15743;
	Tue, 16 Oct 2001 11:27:54 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GIRqg10621;
	Tue, 16 Oct 2001 21:27:52 +0300
Date: Tue, 16 Oct 2001 21:27:52 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: <claude.castelluccia@inrialpes.fr>, <gab@sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
  for MIP v6
In-Reply-To: <Roam.SIMC.2.0.6.1003250551.1277.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0110162119420.10452-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Erik Nordmark wrote:
> > Wouldn't it make sense to define a new destination option that will
> > contains the HomeAddress of the MN (very similar to the MIPv6 current
> > HomeAddress option by in the other direction). A CN would then send the
> > packets to the MN's current CoA and add this new option that contains the
> > MN's home address.
> 
> If folks want to redefine the actual packet formats as opposed to
> adding rules on how routing headers are processed by MNs, then it
> might make sense to go the direction of viewing this use of the routing
> header as a "compressed" form of IPinIP tunneling instead of a different
> destination option.
>
> Such a compressed IPinIP option would just have one IPv6 address (since
> the source address of the "tunnel" to the MN is the source address in
> the IPv6 header) thus it would be the same size as the routing header
> with one IPv6 address.

This makes sense as an alternative approach.

But always remember that "automatic tunneling open to everyone in the 
Internet" presents yet another slew of possible security problems as noted 
from ngtrans methods like 6to4, compatible addresses etc.

So this definitely should not be implemented like e.g. every node would 
have to receive and process IP6-IP6 tunneled packets.

If this compressed form had sufficient number of sanity checks etc. I
guess it could be made to work.  But basically it would still require a
new header/option type.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 15:03:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15768
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 15:03:41 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14689;
	Tue, 16 Oct 2001 12:03:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19787;
	Tue, 16 Oct 2001 12:03:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJ2COI004534
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 12:02:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GJ2CVM004533
	for mobile-ip-dist; Tue, 16 Oct 2001 12:02:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJ28OI004526
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 12:02:08 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16745;
	Tue, 16 Oct 2001 12:02:08 -0700 (PDT)
Received: from sun.com (vpn-129-159-0-38.EMEA.Sun.COM [129.159.0.38])
	by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id f9GJ24k11528;
	Tue, 16 Oct 2001 12:02:05 -0700 (PDT)
Message-ID: <3BCC83D7.515CBB0@sun.com>
Date: Tue, 16 Oct 2001 21:00:39 +0200
From: gabriel montenegro <gab@sun.com>
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: mobile-ip@sunroof.eng.sun.com, claude.castelluccia@inrialpes.fr
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110162119420.10452-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola wrote:

> On Tue, 16 Oct 2001, Erik Nordmark wrote:
> ...
> > If folks want to redefine the actual packet formats as opposed to
> > adding rules on how routing headers are processed by MNs, then it
> > might make sense to go the direction of viewing this use of the routing
> > header as a "compressed" form of IPinIP tunneling instead of a different
> > destination option.
> >
> > Such a compressed IPinIP option would just have one IPv6 address (since
> > the source address of the "tunnel" to the MN is the source address in
> > the IPv6 header) thus it would be the same size as the routing header
> > with one IPv6 address.
>
> This makes sense as an alternative approach.

...

> If this compressed form had sufficient number of sanity checks etc. I
> guess it could be made to work.  But basically it would still require a
> new header/option type.

I was thinking along these lines today in an exchange with Claude and was taking some notes...

Issues with MIPv6 and Routing Headers

Turns out MIPv6 does not use routing headers correctly. It really wants to use another destination option
(quite similar to the home address destination option already defined).

RH's are unbounded in the number of intermediate nodes, so they're harder to control and it's harder to
track down the originator of, say, a reflector attack (this is exactly the problem pointed out by vern paxson
in his paper on DDOS in the internet as the main problem with gnutella).
So, yes,  a simpler bounded option used exclusively for mobile ip would make it more palatable.

Even the rh-ha draft notion of 'interface-local' doesn't make sense, unless i'm misunderstanding.
Wouldn't you want something more like 'host-local' instead? One example:
mosquito net had a metricom star-mode hack whereby they would xmit using one
modem and receive on another, so wouldn't this 'interface-local' rule fail in this case?
Many similar cases, you don't care much about both addresses belonging to the same
interface, you care that they belong to the same host.

Processing the Forwarding Option

    For home addr option: the CN should verify that it has a binding for homeAddress (in the HA option)
    and care-of address (the src of the packet). Both of these are remote addresses; both should
    correspond to the same remote host.

     For this new forwarding option: the MN must verify that the address contained
    therein is one of its local addresses. Both of these are local addresses; both should correspond to
    this, the destination host.

Perhaps this new option is useful for renumbering, quick failover or multihoming purposes as well?

Forwarding Option for BETH

This option could be used to save in the tunneling, supposedly a not negligible gain, given we're
doing BETH to begin with. So instead of doing rfc2473 (generic packet tunneling in ipv6), one
would use this new forwarding header which should be smaller.

Now, however, instead of being end-to-end as in the routing header replacement usage above,
it would be initiated at the aAR:

     CN sends:
        cn->coa
            (which may itself include a forwarding option with the home address
            and perhaps a 'local' bit on)

     aAR substitutes the destination address and sends this:
        cn->AR
        forwarding option: coa (this may have a bit saying if its supposed to be local forwarding or not)

The AR gets it from aAR, processes the forwarding option and sends the packet on its
way:

        cn->coa

It's just a shorter form of 2473. Presumably, if one's interested in draft-sreeman-enhance-beth*
and its chained tunneling one could do the above as follows:

     CN sends:
            cn->coa
                (which may itself include a forwarding option with the home address and perhaps a 'local' bit on)

     aAR substitutes the destination address and sends this:
            cn->oAR
            forwarding option: coa this may have a bit saying if its supposed to be local forwarding or not

     oAR substitutes the destination address and sends this:
            cn->nAR
            forwarding option: coa this may have a bit saying if its supposed to be local forwarding or not

The nAR gets it from oAR, processes the forwarding option and sends the packet on its  way:
        cn->coa

One may not need to use a bit to indicate 'local' versus 'non-local' forwarding.
As long as the receiving node has some sort of  'binding' (local or non-local) for the address in the
forwarding option then it may work.

-gabriel



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 15:19:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16578
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 15:19:28 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02910;
	Tue, 16 Oct 2001 13:17:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23234;
	Tue, 16 Oct 2001 12:17:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJGROI004628
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 12:16:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GJGR2x004627
	for mobile-ip-dist; Tue, 16 Oct 2001 12:16:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJGJOI004620
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 12:16:21 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19970
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 12:15:51 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22198;
	Tue, 16 Oct 2001 12:15:49 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GJFlH10922;
	Tue, 16 Oct 2001 22:15:47 +0300
Date: Tue, 16 Oct 2001 22:15:47 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: gabriel montenegro <gab@sun.com>
cc: <mobile-ip@sunroof.eng.sun.com>, <claude.castelluccia@inrialpes.fr>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
In-Reply-To: <3BCC83D7.515CBB0@sun.com>
Message-ID: <Pine.LNX.4.33.0110162204440.10828-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I'll respond to just one point here.

On Tue, 16 Oct 2001, gabriel montenegro wrote:
> Even the rh-ha draft notion of 'interface-local' doesn't make sense,
> unless i'm misunderstanding. Wouldn't you want something more like
> 'host-local' instead? One example: mosquito net had a metricom
> star-mode hack whereby they would xmit using one modem and receive on
> another, so wouldn't this 'interface-local' rule fail in this case?
> Many similar cases, you don't care much about both addresses belonging
> to the same interface, you care that they belong to the same host.

No.  Host-local is too open; please see Security Consideration of my 
draft.

Either the MIPv6 implementation would have to "bind" the allowed addresses
together somehow, or this would have to be really restricted (if e.g.  
one would want to support this form of "routing header" outside of MIPv6)

With IPv4 analogy:

Host A has two interfaces eth0 and eth1.  eth0 is two public IP addresses
and eth1 a private 10.x.x.x address.  A few services are meant for private
network only, with e.g. a specific bind().

Now with routing header, anyone could reach to eth1's private 10.x.x.x 
address from anywhere in the internet.

This seems very bad.

Therefore, the check must be strict, in one way or the other.  The same
zone (ie. not global-site/global-linklocal/site-link, ...), and same
interface.  This isn't perfect but it's the best you can do, I fear, in
the global case.

If the check is *MIPv6* -only, the final address could be defined to "MUST 
match the configured Home Address".

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:01:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18979
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:01:42 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07547;
	Tue, 16 Oct 2001 14:01:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00875;
	Tue, 16 Oct 2001 13:01:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJxMOI004875
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 12:59:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GJxM3c004874
	for mobile-ip-dist; Tue, 16 Oct 2001 12:59:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJxHOI004867
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 12:59:18 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GJxDq13009;
	Tue, 16 Oct 2001 21:59:13 +0200 (MET DST)
Date: Tue, 16 Oct 2001 21:52:04 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)
To: lpetande@tml.hut.fi
Cc: mobile-ip@sunroof.eng.sun.com,
        Catharina Linnea Candolin <candolin@tml.hut.fi>
In-Reply-To: "Your message with ID" <Pine.SOL.4.10.10110162001170.1627-100000@morphine.tml.hut.fi>
Message-ID: <Roam.SIMC.2.0.6.1003261924.19172.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> > Only if you believe there will be pre-existing security associations
> between
> > the MN and all possible default routers it uses while moving around ,
> > does it make sense to treat them the same.
>  
> The main point was that if MN and its regular HA need a "strong" SA, so do
> MN and its "foreign" HA. I agree that the assumption that MN and its HA
> have a preconfigured security association might not easily apply to the
> "foreign" HAs. Probably they and MN will still have an existing trust
> relationship, so that they can create a "strong" SA.

Could you explain the source of your belief expressed in the last sentence?

If you are correct and a MN can have a trust relationship with an
arbitrary previous default router, then why is that limited to just routers?
If it isn't then I think you've just shown that an MN can have a trust 
relationship with an arbitrary CN.
Thus we wouldn't need any new method for securiting BUs following this
logic.

Where did I go wrong?

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:04:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19045
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:04:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12363;
	Tue, 16 Oct 2001 13:04:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01427;
	Tue, 16 Oct 2001 13:03:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GK33OI004952
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:03:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GK33pn004951
	for mobile-ip-dist; Tue, 16 Oct 2001 13:03:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GK2wOI004944
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:02:59 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GK2sq13395;
	Tue, 16 Oct 2001 22:02:55 +0200 (MET DST)
Date: Tue, 16 Oct 2001 21:57:34 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] protecting BUs
To: jmalinen@iprg.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3BCC775E.1C916A9A@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.1003262254.2228.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> The comment was about ordering rules; if a new header were to be
> required too early in the ordering, it would change how a node needs to
> scan the packet before it sees e.g. hop-by-hop header or in case a node
> does source routing, a routing header. If the packet is beyond routing
> header by the ordering rules, it's transparent and a router or
> source-routing node does not ever need to look its type.


What about packets that don't have a routing header?
The ordering rules doesn't require that every extension header be present
in every packet.

Thus if a packet with IPv6 header and h-b-h header arrives at the router
and the h-b-h header has a next hdr = 254 (or some other undefined value)
what do you think the router will do?

Same question if the packet has an IPv6 header with next hdr = 254.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:10:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19186
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:10:13 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14254;
	Tue, 16 Oct 2001 14:09:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02535;
	Tue, 16 Oct 2001 13:08:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GK7dOI005056
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:07:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GK7dJa005055
	for mobile-ip-dist; Tue, 16 Oct 2001 13:07:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GK7YOI005048
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:07:35 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GK7Rq13707;
	Tue, 16 Oct 2001 22:07:31 +0200 (MET DST)
Date: Tue, 16 Oct 2001 22:02:05 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements  for MIP v6
To: pekkas@netcore.fi
Cc: mobile-ip@sunroof.eng.sun.com, claude.castelluccia@inrialpes.fr,
        gab@sun.com
In-Reply-To: "Your message with ID" <Pine.LNX.4.33.0110162119420.10452-100000@netcore.fi>
Message-ID: <Roam.SIMC.2.0.6.1003262525.8565.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> On Tue, 16 Oct 2001, Erik Nordmark wrote:
> > Such a compressed IPinIP option would just have one IPv6 address (since
> > the source address of the "tunnel" to the MN is the source address in
> > the IPv6 header) thus it would be the same size as the routing header
> > with one IPv6 address.
> 
> This makes sense as an alternative approach.
> 
> But always remember that "automatic tunneling open to everyone in the 
> Internet" presents yet another slew of possible security problems as noted 
> from ngtrans methods like 6to4, compatible addresses etc.

I didn't claim a different encoding would change anything security wise -
it doesn't.

I just responded to Claude's suggestion about using a destination option
as a different encoding suggesting an alternate different encoding to
the current one.

> So this definitely should not be implemented like e.g. every node would 
> have to receive and process IP6-IP6 tunneled packets.

Agreed.

> If this compressed form had sufficient number of sanity checks etc. I
> guess it could be made to work.  But basically it would still require a
> new header/option type.

Agreed.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:18:14 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19440
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:18:13 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18381;
	Tue, 16 Oct 2001 13:17:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04530;
	Tue, 16 Oct 2001 13:16:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKG3OI005158
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:16:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GKG3Vf005157
	for mobile-ip-dist; Tue, 16 Oct 2001 13:16:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKG0OI005150
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:16:00 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04217
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:15:31 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15390
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:15:31 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA02532
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:15:30 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9GKFUA01760
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:15:30 -0700
X-mProtect:  Tue, 16 Oct 2001 13:15:30 -0700 Nokia Silicon Valley Messaging Protection
Received: from maxdialin12.iprg.nokia.com (205.226.20.242, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdL1nT0W; Tue, 16 Oct 2001 13:15:26 PDT
Message-ID: <3BCC9540.66113EFD@iprg.nokia.com>
Date: Tue, 16 Oct 2001 13:14:56 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mobile IP Working Group Mailing List <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Comments on security requirements draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello,

Here are some comments on the recent revision of the security
requirements document.

==============================================================
Document Structure
==============================================================

I think that the document needs to be restructured.
The main body of the document identifies security
issues, explains why there might be a vulnerability,
sometimes almost wholly unrelated to Mobile IPv6.
In most, but not all cases, an issue is described
by presenting a scenario, a threat, an effect,
a requirement, and in at least one case a "reaction".

I would rather see the following:
- Each threat/vulnerability/issue should be clearly
  identified and have its own name and subsection.
  This way, it would also appear in the table of contents
- Threats that are not specific to Mobile IPv6 should
  typically be put in the appendix, unless they are
  important for understanding something that IS specific.
- The "scenario/threat/effect/requirement" structure
  could easily be abandoned.  Each named issue, with
  the name in the subsection title, should be described.
  Maybe an occasional scenario would help.  Maybe some
  issues would need multiple scenarios.  Maybe some
  issues would be obvious and no scenarios needed.
  Possible suggestion: one paragraph for the issue,
  one short paragraph for the resulting requirement.

The table at the beginning of section 6 is, I think,
useless, at least in its current form.  I tried to imagine
using it while I was reading the document, and I could not
do so.  Maybe a different set of "axes" might cause some
sort of tabulation to be useful.  For instance:
- threats against MN/CN/HA/?/ as the rows ...?

As it is now, I think the table should be deleted.
Besides, it hasn't been updated to match the rest of
the document anyway.

I also think that the document needs a more coherent
"theme".  As it is, one can assort the "threats" in
the document into one of three classifications:

1. Problems that are not directly related to the design
   problems to be solved by Mobile IPv6.
2. Problems that have already been solved by Mobile IPv6.
3. Problems that need further attention and discussion.

So, for instance, describing threats that are really
relevant to Duplicate Address Detection might not be
appropriate for discussion on this document, even though
Mobile IPv6 presumes that nodes are able to use Duplicate
Address Detection(*).  Another possibility would be to collect
together all such discussion points into a preliminary
section (perhaps after the introduction) so that people
reading the document would better understand the overall
security vulnerabilities of IPv6 address autoconfiguration.
That might help avoid confusion during the discussion on
things that need to be considered specifically within the
Mobile IP working group.

(*) I picked this as an example specifically because it
    does not appear in the document, and thus hopefully
    could not obscure my point.  The threats that I feel
    are similarly extraneous include A.2, B.2, D.2.4
    (not meant to be exhaustive).

===============================================================

The title is wrong, and intimidating.  The first clause should
be deleted.  The second clause captures what I thought was
the point of the document quite well, and stands on its own
as a reasonable title.

Use of the word "introduce" means that the threat did not
exist before Mobile IPv6, and that the threat does exist
now.  This is clearly wrong, because mostly Mobile IPv6
does not introduce or even enable the threats that are
described.  Most often, the discussion centers around the
threat introduced by "remote redirection", terminology
predating even Mobile IPv4 (see RFC 2002).  Mobile IPv6 does
not enable this threat, and certainly does not introduce it.
Every use of the word "introduce" should be carefully
considered in this light.  I checked on this, and it's
not just in the existing title where the mistake is made.

However, it is entirely appropriate to list that threat as
justification for a security requirement.  This version of
the document does properly point out that Mobile IPv6 does
meet the relevant security requirement.  Understanding the
threat, and the subsequent need for the requirement, is a
valid and important topic for this document.  Describing that
threat as something introduced or enabled by Mobile IPv6 is
not valid or appropriate or true.

============================================================

There are too many variations on the exact same theme of
what happens when Binding Updates would be accepted without
authentication.  In Mobile IPv6, that cannot happen anyway.
But even working under the assumption that the threat should
be clearly described so that all readers can understand,
the current document muddies the issue by claiming so
many variations on it.  To take an absurd example, consider
what would happen if we added the following sections

Section Q.1:  What happens to SNMP if Binding Updates are
              not authenticated
Section Q.2:  What happens to IPv6 Encapsulation if Binding
              Updates are not authenticated
Section Q.3:  What happens to e-mail if ...
...
Section Q.9:  What happens to telnet if ...
Section Q.9.A:  What happens to telnet within the Home
                Domain if ...
Section Q.9.B:  What happens to telnet within another
                Domain if ...
Section Q.9.C:  What if the mobile node is a telnet _server_
                instead of a telnet _client_ if ...

Nobody needs to read through all that, and it does not
help.  What's important is that the Binding Updates need
to be authenticated, and it's always for exactly the same
reason.  Building it up into a bigger threat by allocating
so many different sections for the same problem is not
helping, in my opinion.

Plus, every time it is mentioned, it MUST be made very
clear that the threat DOES NOT EXIST in current (or past!)
Mobile IPv6 specification revisions.  Otherwise I fear
we will be diverted towards chasing problems that are not
there.

=============================================================

Section (2): the terminology entries shouldn't be numbered,
             and the terms should have white space or
             a new line separating them from the definitions

=============================================================

The threat of malicious, unauthenticated remote redirection is
the same, whether it happens at the home agent or a correspondent
node.  The only difference is that it might happen more often
at the home agent than at any particular correspondent node.
Thus, the discussion in section (3) should be reformulated to
avoid having separate classification.

Likewise, the introductory part of section (4) needs to be
substantially revamped.  Editorial: replace "covered" by
"eliminated".

============================================================

The classification in section (5) is not systematically
used in the rest of the document.  It is indeed helpful to
analyze each possible attack to see whether it can be
mounted at the various places mentioned.  The claim at
the end of the section is not really borne out in the
rest of the document, since denial of service attacks are
usually not considered under all four listed possibilities.

=============================================================

The table in section 6 should probably be deleted.  But, if
it is retained, then it should all appear on one page.
One of the column separators needs to be aligned.  A.4 is
missing.  D.1 is not described.  The attacks need to be
named instead of numbered.  I don't expect many people to
really flip back and forth through the document in order to
make use of the table, but maybe that's because I don't
understand what people would use the table for.

Replace "other's" by "others".

I think that 6.1.2 could safely be deleted, along with B.1.
B.3 should be put in the appendix.  The words "low cost"
are not needed.

Requirement B.4: replace "ensure it trusts the sender of"
by "authenticate".

Section 6.4 and elsewhere: replace "it's" by "its".
In Threat D.1: delete "easily", or else put in "if
authentication is not required".
In Effect D.1: replace "agains" by "against".  Plus,
the effect is not at all clear to me.

For threat D.2, it needs to be explained why this
flooding attack is at all different from any other
flooding attack.  Otherwise, the point seems irrelevant
to me.  Any control message can be utilized as the
data for a flooding attack -- or, for that matter,
any application directive or even vanilla data packet.
A difficulty might arise if the mobile node has to do
a lot of work to fulfill the request.

Effect D.2: (3) has the first two words of the second
sentence capitalized.  Plus, it doesn't seem relevant
anyway to the point about sending Binding Requests.
Same for points (1) and (2), actually.

Threat D.3 could be deleted without loss.

Effect E.1 and elsewhere: "masquerade" is spelled
           incorrectly as "masquarade".

Attack F.1 doesn't add anything to the discussion,
it seems to me.

Something is wrong between "Result H.1" and "Threat H.2".
The last sentence of that paragraph should perhaps be
deleted?

There are two "Threat H.2"s, not much different in content.

Requirement H.3: This is under debate on the mailing list
                 just now, but if it appears in the final
                 revision (and I hope it does not) one of
                 the capitalized specifiers would have to
                 be deleted.

===========================================================

Requirements:

There is nothing in the document to support the need for
identify verification.

Trivial editorial moot point: "MUST not" should be "MUST NOT",
except that in this case the construction shouldn't be there
anyway.  But the same problem does occur elsewhere in the
document.

7.1/D.2  Replace "for e.g" by "for instance".

7.1/5    Replace "SHOULD not" by "SHOULD NOT".  Besides, this
         item is also under current discussion.

7.2/9    This is not supported within the text, and furthermore
         it should be enough for mobile nodes to follow a
         mandated backoff algorithm.

===============================================================
  
Appendix B: The parenthesized clause can be deleted without
            harm, and the next sentence mentions a
            "specific condition", but I could not figure out
            what the condition was.

Question 2: The Binding Cache is specified to be handled as
            a cache, with any reasonable cache replacement
            policy.  LRU is good.  FIFO would not be as good.

Comment 2: Please insert "some" before "wireless" in the first
           sentence.  There are more instances of "it's" that
           should be "its" here.


===============================================================

Lastly, I hope that the process of identifying whether we
have satisfied the security requirements laid out in this
document can proceed right away, without having to wait for
the document to be completed.  I think the process of creating
the document has made people aware of the issues, and that we
could try to make some progress with the other documents.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:20:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19526
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:20:02 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22919;
	Tue, 16 Oct 2001 14:19:34 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05208;
	Tue, 16 Oct 2001 13:19:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKIXOI005227
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:18:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GKIXK0005226
	for mobile-ip-dist; Tue, 16 Oct 2001 13:18:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKITOI005219
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:18:29 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20542
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:18:32 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07598
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:34:15 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GKITZ11282;
	Tue, 16 Oct 2001 23:18:29 +0300
Date: Tue, 16 Oct 2001 23:18:29 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: <jmalinen@iprg.nokia.com>
Subject: Re: [mobile-ip] protecting BUs
In-Reply-To: <Roam.SIMC.2.0.6.1003262254.2228.nordmark@bebop.france>
Message-ID: <Pine.LNX.4.33.0110162314320.11247-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Erik Nordmark wrote:
> > The comment was about ordering rules; if a new header were to be
> > required too early in the ordering, it would change how a node needs to
> > scan the packet before it sees e.g. hop-by-hop header or in case a node
> > does source routing, a routing header. If the packet is beyond routing
> > header by the ordering rules, it's transparent and a router or
> > source-routing node does not ever need to look its type.
> 
> 
> What about packets that don't have a routing header?
> The ordering rules doesn't require that every extension header be present
> in every packet.
> 
> Thus if a packet with IPv6 header and h-b-h header arrives at the router
> and the h-b-h header has a next hdr = 254 (or some other undefined value)
> what do you think the router will do?

In case dst=Router:

Discard the packet as it cannot process it far enough to see whether it 
should process it itself or keep forwarding (rt header).

Else:

Forward the packet.  Router only cares about h-b-h, and is allowed to be 
present only once.

> Same question if the packet has an IPv6 header with next hdr = 254.

In case of dst=Router:

Discard the packet as nxt header value is unknown, and further processing 
is not known.

Else:

Forward the packet, because next hdr was not 0, thus indicating h-b-h and 
must-be-processed-by-router.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:37:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20154
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:37:34 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28727;
	Tue, 16 Oct 2001 13:37:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10005;
	Tue, 16 Oct 2001 13:34:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKXOOI005372
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:33:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GKXNcS005371
	for mobile-ip-dist; Tue, 16 Oct 2001 13:33:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKXKOI005364
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:33:20 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05178;
	Tue, 16 Oct 2001 13:33:17 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04952;
	Tue, 16 Oct 2001 14:33:02 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA04404;
	Tue, 16 Oct 2001 13:33:20 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9GKXJH05647;
	Tue, 16 Oct 2001 13:33:19 -0700
X-mProtect:  Tue, 16 Oct 2001 13:33:19 -0700 Nokia Silicon Valley Messaging Protection
Received: from maxdialin12.iprg.nokia.com (205.226.20.242, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdstZbBq; Tue, 16 Oct 2001 13:33:17 PDT
Message-ID: <3BCC9963.E5623AB2@iprg.nokia.com>
Date: Tue, 16 Oct 2001 13:32:35 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gabriel Montenegro <Gabriel.Montenegro@eng.sun.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110162119420.10452-100000@netcore.fi> <3BCC83D7.515CBB0@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Gabriel,

gabriel montenegro wrote:

> Issues with MIPv6 and Routing Headers
>
> Turns out MIPv6 does not use routing headers correctly. It really wants to use another destination option
> (quite similar to the home address destination option already defined).

I looked, and I didn't see why you made this claim.  What is
incorrect?

> RH's are unbounded in the number of intermediate nodes, so they're harder to control and it's harder to
> track down the originator of, say, a reflector attack (this is exactly the problem pointed out by vern paxson
> in his paper on DDOS in the internet as the main problem with gnutella).
> So, yes,  a simpler bounded option used exclusively for mobile ip would make it more palatable.

A new option, while it may have a more restricted applicability,
would not necessarily be simpler for at least the reason that it
would take longer to specify correctly.  The fact that a new option
can be made to have restricted applicability does not mean that
the more general option is being used incorrectly.  Furthermore,
since the options would be so similar, it might take a lot of
effort to figure out exactly how they interact, what the ordering
would be if they both appeared, and so on.

I don't even see that there is a problem here that needs to be
solved.  If there is one, then it seems to me to be a lot better to
solve it using the easiest available methods, instead of creating
whole new design approaches.

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:50:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20515
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:49:59 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03597;
	Tue, 16 Oct 2001 13:48:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14170;
	Tue, 16 Oct 2001 13:48:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKllOI005481
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:47:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GKllKw005480
	for mobile-ip-dist; Tue, 16 Oct 2001 13:47:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKlhOI005473
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:47:44 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GKlZq15590;
	Tue, 16 Oct 2001 22:47:41 +0200 (MET DST)
Date: Tue, 16 Oct 2001 22:42:13 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on security requirements draft
To: charliep@iprg.nokia.com
Cc: Mobile IP Working Group Mailing List <mobile-ip@sunroof.eng.sun.com>
In-Reply-To: "Your message with ID" <3BCC9540.66113EFD@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.1003264933.5966.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Charlie,

> (*) I picked this as an example specifically because it
>     does not appear in the document, and thus hopefully
>     could not obscure my point.  The threats that I feel
>     are similarly extraneous include A.2, B.2, D.2.4
>     (not meant to be exhaustive).

A.2 is about the effect on ICMP errors in the binding cache.
MIPv6 introduces the notion of a binding cache thus this sure seems to
be MIPv6 specific.

D.2.4 is about flooding Binding Requests, and BRs is part of MIPv6.

B.2 states that it isn't MIPv6 specific, but I think it makes
sense to include it in the document since it points out that there
are other unaddressed threats that allow for attackers on the MN's link
to redirect or black-hole traffic. Thus having this attack discussed
helps point out that MIPv6 doesn't necessarily need to address new attacks
made possible by MIPv6 when the attacker is constrained to being on the same
link.

So which are the other ones you think don't belong?

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 16:56:43 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20748
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 16:56:42 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07340;
	Tue, 16 Oct 2001 13:56:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16206;
	Tue, 16 Oct 2001 13:56:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKtFOI005570
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:55:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GKtF81005569
	for mobile-ip-dist; Tue, 16 Oct 2001 13:55:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKtCOI005562
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:55:12 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15968
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:55:15 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23661
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:54:56 -0600 (MDT)
Received: from auds953.usa.alcatel.com ([143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA02983
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 15:55:14 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9GKtDD14767
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 15:55:14 -0500 (CDT)
Message-ID: <3BCCA025.E02CD109@alcatel.com>
Date: Tue, 16 Oct 2001 16:01:25 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110162119420.10452-100000@netcore.fi> <3BCC83D7.515CBB0@sun.com> <3BCC9963.E5623AB2@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Charlie,
  You seem to favor the solution 6.1 in Arkko's draft?
I kind of like 6.2 as well, it is also simple. Maybe problem with present implementations, but correcting a design
flaw early is better, IMHO.
  Appreciate if you can clarify.
Regards,

Charlie Perkins wrote:

> Hello Gabriel,
>
> gabriel montenegro wrote:
>
> > Issues with MIPv6 and Routing Headers
> >
> > Turns out MIPv6 does not use routing headers correctly. It really wants to use another destination option
> > (quite similar to the home address destination option already defined).
>
> I looked, and I didn't see why you made this claim.  What is
> incorrect?
>
> > RH's are unbounded in the number of intermediate nodes, so they're harder to control and it's harder to
> > track down the originator of, say, a reflector attack (this is exactly the problem pointed out by vern paxson
> > in his paper on DDOS in the internet as the main problem with gnutella).
> > So, yes,  a simpler bounded option used exclusively for mobile ip would make it more palatable.
>
> A new option, while it may have a more restricted applicability,
> would not necessarily be simpler for at least the reason that it
> would take longer to specify correctly.  The fact that a new option
> can be made to have restricted applicability does not mean that
> the more general option is being used incorrectly.  Furthermore,
> since the options would be so similar, it might take a lot of
> effort to figure out exactly how they interact, what the ordering
> would be if they both appeared, and so on.
>
> I don't even see that there is a problem here that needs to be
> solved.  If there is one, then it seems to me to be a lot better to
> solve it using the easiest available methods, instead of creating
> whole new design approaches.
>
> Regards,
> Charlie P.

--
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S CTO2
1201 E. Campbell Rd.
Richardson, TX 75081-1936 USA
Email : behcet.sarikaya@alcatel.com
Phone : (972) 996-5075 Fax : (972) 996-5174




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 17:00:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20821
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 17:00:28 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27304;
	Tue, 16 Oct 2001 14:59:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17283;
	Tue, 16 Oct 2001 13:59:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKwROI005690
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:58:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GKwRFA005689
	for mobile-ip-dist; Tue, 16 Oct 2001 13:58:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GKwOOI005682
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 13:58:24 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16830;
	Tue, 16 Oct 2001 13:58:27 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24020;
	Tue, 16 Oct 2001 13:58:26 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA06423;
	Tue, 16 Oct 2001 13:58:26 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9GKwQR29437;
	Tue, 16 Oct 2001 13:58:26 -0700
X-mProtect:  Tue, 16 Oct 2001 13:58:26 -0700 Nokia Silicon Valley Messaging Protection
Received: from maxdialin12.iprg.nokia.com (205.226.20.242, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdxClPZq; Tue, 16 Oct 2001 13:58:24 PDT
Message-ID: <3BCC9F36.931DE2@iprg.nokia.com>
Date: Tue, 16 Oct 2001 13:57:26 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
CC: Mobile IP Working Group Mailing List <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Comments on security requirements draft
References: <Roam.SIMC.2.0.6.1003264933.5966.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Erik,

That was fast!

Erik Nordmark wrote:

> A.2 is about the effect on ICMP errors in the binding cache.
> MIPv6 introduces the notion of a binding cache thus this sure seems to
> be MIPv6 specific.

In that sense, I agree with you.  But the more general problem is
that ICMP Unreachable would be likely to cause applications to
be disrupted, networks to be unreachable, and other similarly
bad effects, all without authentication.  So I was thinking that the
described threat was a minor sub-part of a much more general
problem with ICMP.  In other words, it's the unauthenticated
ICMP that's the problem, not that it has some associated effect
on Binding Cache entries.

I'm not suggesting that we have to authenticate ICMP messages.

> D.2.4 is about flooding Binding Requests, and BRs is part of MIPv6.

But the problem is with flooding, and the fact that the water is flavored
with "Binding Request" bits doesn't matter much as far as I could tell.

> B.2 states that it isn't MIPv6 specific, but I think it makes
> sense to include it in the document since it points out that there
> are other unaddressed threats that allow for attackers on the MN's link
> to redirect or black-hole traffic. Thus having this attack discussed
> helps point out that MIPv6 doesn't necessarily need to address new attacks
> made possible by MIPv6 when the attacker is constrained to being on the same
> link.

O.K.  I would again suggest that all such descriptive text belongs in
a preliminary section on background, or else an appendix, and should
be clearly separated out from the more directly relevant security
discussions.

> So which are the other ones you think don't belong?

Can I take a rain check on this invitation?  I'll try to get back to
it, depending on subsequent discussion.

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 17:12:14 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21037
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 17:12:13 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14293;
	Tue, 16 Oct 2001 14:11:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21147;
	Tue, 16 Oct 2001 14:11:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GLAAOI005823
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:10:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GLAAGM005822
	for mobile-ip-dist; Tue, 16 Oct 2001 14:10:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GLA6OI005815
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:10:06 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03016
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:10:09 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06092
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 15:09:50 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA07796;
	Tue, 16 Oct 2001 14:10:08 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9GLA7a21818;
	Tue, 16 Oct 2001 14:10:07 -0700
X-mProtect:  Tue, 16 Oct 2001 14:10:07 -0700 Nokia Silicon Valley Messaging Protection
Received: from maxdialin12.iprg.nokia.com (205.226.20.242, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdA15mUR; Tue, 16 Oct 2001 14:10:04 PDT
Message-ID: <3BCCA1EA.9A52A94B@iprg.nokia.com>
Date: Tue, 16 Oct 2001 14:08:58 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Behcet Sarikaya <sarikaya@U-AIZU.AC.JP>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110162119420.10452-100000@netcore.fi> <3BCC83D7.515CBB0@sun.com> <3BCC9963.E5623AB2@iprg.nokia.com> <3BCCA025.E02CD109@alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Behcet,

I didn't yet get around to transcribing my comments on Jari's
draft, but if I may offer an incomplete opinion I think it is a
fine piece of work.  I would favor the approach outlined
in section 6.4, with the proviso that:
- If IPsec is agreeably configured to authenticate
   Binding Update, it can be used instead of the BU
   authentication data option.  In other words, sometimes
   a Binding Update could be authenticated by a method
   that depends on some future IPsec mechanism, instead
   of requiring the authentication data suboption to be present
   anyway even if IPsec were already somehow enabled to
   to do the job.

But as I said this is an incompletely formed opinion, and
I have to finish studying the document to figure it out more.
Plus, I definitely don't intend to say that we have to figure
out how to do all the IPsec stuff right now.

Regards,
Charlie P.



Behcet Sarikaya wrote:

> Hi Charlie,
>   You seem to favor the solution 6.1 in Arkko's draft?
> I kind of like 6.2 as well, it is also simple. Maybe problem with present implementations, but correcting a design
> flaw early is better, IMHO.
>   Appreciate if you can clarify.
> Regards,
>
> Charlie Perkins wrote:
>
> > Hello Gabriel,
> >
> > gabriel montenegro wrote:
> >
> > > Issues with MIPv6 and Routing Headers
> > >
> > > Turns out MIPv6 does not use routing headers correctly. It really wants to use another destination option
> > > (quite similar to the home address destination option already defined).
> >
> > I looked, and I didn't see why you made this claim.  What is
> > incorrect?
> >
> > > RH's are unbounded in the number of intermediate nodes, so they're harder to control and it's harder to
> > > track down the originator of, say, a reflector attack (this is exactly the problem pointed out by vern paxson
> > > in his paper on DDOS in the internet as the main problem with gnutella).
> > > So, yes,  a simpler bounded option used exclusively for mobile ip would make it more palatable.
> >
> > A new option, while it may have a more restricted applicability,
> > would not necessarily be simpler for at least the reason that it
> > would take longer to specify correctly.  The fact that a new option
> > can be made to have restricted applicability does not mean that
> > the more general option is being used incorrectly.  Furthermore,
> > since the options would be so similar, it might take a lot of
> > effort to figure out exactly how they interact, what the ordering
> > would be if they both appeared, and so on.
> >
> > I don't even see that there is a problem here that needs to be
> > solved.  If there is one, then it seems to me to be a lot better to
> > solve it using the easiest available methods, instead of creating
> > whole new design approaches.
> >
> > Regards,
> > Charlie P.
>
> --
> Behcet Sarikaya
> Network Strategy Group, Mobile Networking Team
> Alcatel USA M/S CTO2
> 1201 E. Campbell Rd.
> Richardson, TX 75081-1936 USA
> Email : behcet.sarikaya@alcatel.com
> Phone : (972) 996-5075 Fax : (972) 996-5174



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 17:34:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21302
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 17:34:36 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24865;
	Tue, 16 Oct 2001 15:34:10 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21880;
	Tue, 16 Oct 2001 14:34:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GLWvOI005983
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:32:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GLWvQK005982
	for mobile-ip-dist; Tue, 16 Oct 2001 14:32:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GLWrOI005975
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:32:53 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21419
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:32:44 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23397
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 15:32:31 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA09485
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:32:49 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9GLWmJ17963
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:32:48 -0700
X-mProtect:  Tue, 16 Oct 2001 14:32:48 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdDtzQyF; Tue, 16 Oct 2001 14:32:47 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA19549 for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 14:32:44 -0700 (PDT)
Message-ID: <3BCCA77C.863A871C@iprg.nokia.com>
Date: Tue, 16 Oct 2001 14:32:44 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] protecting BUs
References: <Roam.SIMC.2.0.6.1003262254.2228.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Erik Nordmark wrote:
> 
> > The comment was about ordering rules; if a new header were to be
> > required too early in the ordering, it would change how a node needs to
> > scan the packet before it sees e.g. hop-by-hop header or in case a node
> > does source routing, a routing header. If the packet is beyond routing
> > header by the ordering rules, it's transparent and a router or
> > source-routing node does not ever need to look its type.
> 
> What about packets that don't have a routing header?
> The ordering rules doesn't require that every extension header be present
> in every packet.
> 
> Thus if a packet with IPv6 header and h-b-h header arrives at the router
> and the h-b-h header has a next hdr = 254 (or some other undefined value)
> what do you think the router will do?
> 
> Same question if the packet has an IPv6 header with next hdr = 254.

I believe Pekka explained the practical operation; the ordering rules
afffect when one needs to look ahead (beyond other possible packets)
to see particular packets.

>   Erik

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 18:30:28 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22174
	for <mobileip-archive@odin.ietf.org>; Tue, 16 Oct 2001 18:30:27 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16283;
	Tue, 16 Oct 2001 15:30:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22082;
	Tue, 16 Oct 2001 15:29:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GMSmOI006151
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 15:28:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GMSm22006150
	for mobile-ip-dist; Tue, 16 Oct 2001 15:28:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GMShOI006143
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 15:28:44 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9GMSWq20795;
	Wed, 17 Oct 2001 00:28:32 +0200 (MET DST)
Date: Wed, 17 Oct 2001 00:23:06 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Comments on security requirements draft
To: Charlie Perkins <charliep@iprg.nokia.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        Mobile IP Working Group Mailing List <mobile-ip@sunroof.eng.sun.com>
In-Reply-To: "Your message with ID" <3BCC9F36.931DE2@iprg.nokia.com>
Message-ID: <Roam.SIMC.2.0.6.1003270986.4094.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> > A.2 is about the effect on ICMP errors in the binding cache.
> > MIPv6 introduces the notion of a binding cache thus this sure seems to
> > be MIPv6 specific.
> 
> In that sense, I agree with you.  But the more general problem is
> that ICMP Unreachable would be likely to cause applications to
> be disrupted, networks to be unreachable, and other similarly
> bad effects, all without authentication.  So I was thinking that the
> described threat was a minor sub-part of a much more general
> problem with ICMP.  In other words, it's the unauthenticated
> ICMP that's the problem, not that it has some associated effect
> on Binding Cache entries.
> 
> I'm not suggesting that we have to authenticate ICMP messages.

Yes, but the purpose of the document is to explain threats so that 
protocol designers can take the threats into account.

And typically (as required by RFC 1122) ICMP destination unreachable messages
must not terminate TCP connections - instead they are just recorded so
that in case the TCP connection times out the appropriate error is
returned to the application.

> > D.2.4 is about flooding Binding Requests, and BRs is part of MIPv6.
> 
> But the problem is with flooding, and the fact that the water is flavored
> with "Binding Request" bits doesn't matter much as far as I could tell.

Again, purpose if for designers of MIPv6 security mechanisms to understand
the threats.

For instance, if there is a design that causes the reception of any BR to
have the MN do some expensive computation or send multiple packets,
then that would be a source of concern.

> > B.2 states that it isn't MIPv6 specific, but I think it makes
> > sense to include it in the document since it points out that there
> > are other unaddressed threats that allow for attackers on the MN's link
> > to redirect or black-hole traffic. Thus having this attack discussed
> > helps point out that MIPv6 doesn't necessarily need to address new attacks
> > made possible by MIPv6 when the attacker is constrained to being on the same
> > link.
> 
> O.K.  I would again suggest that all such descriptive text belongs in
> a preliminary section on background, or else an appendix, and should
> be clearly separated out from the more directly relevant security
> discussions.

I'm not too concerned by the organization of the document 
at this point in time - the actual content like making sure that the
threats cover the bases and that the requirement are related to reality
is more important.

But to me it makes sense to list all the threats that have
been considered in and around mobile IPv6 in one place whether or not
that threat results in specific requirements for mobile ipv6.

  Erik





From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 16 19:40:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22943
	for <mobileip-archive@lists.ietf.org>; Tue, 16 Oct 2001 19:40:33 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10598;
	Tue, 16 Oct 2001 16:39:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08001;
	Tue, 16 Oct 2001 16:38:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GNbUOI006371
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 16 Oct 2001 16:37:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GNbTKE006370
	for mobile-ip-dist; Tue, 16 Oct 2001 16:37:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GNbQOI006363
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 16 Oct 2001 16:37:26 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26535;
	Tue, 16 Oct 2001 16:37:29 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA18476;
	Tue, 16 Oct 2001 17:54:55 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA19897;
	Tue, 16 Oct 2001 16:37:27 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9GNbQT30497;
	Tue, 16 Oct 2001 16:37:26 -0700
X-mProtect:  Tue, 16 Oct 2001 16:37:26 -0700 Nokia Silicon Valley Messaging Protection
Received: from maxdialin29.iprg.nokia.com (205.226.20.223, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdoYrob3; Tue, 16 Oct 2001 16:37:24 PDT
Message-ID: <3BCCC397.41E0C6D2@iprg.nokia.com>
Date: Tue, 16 Oct 2001 16:32:39 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
CC: Mobile IP Working Group Mailing List <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Comments on security requirements draft
References: <Roam.SIMC.2.0.6.1003270986.4094.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello again Erik,

> I'm not too concerned by the organization of the document
> at this point in time - the actual content like making sure that the
> threats cover the bases and that the requirement are related to reality
> is more important.

Content is important first and foremost, but the organization of the
document seems to be crucial for getting the best results.  It's not a choice
"either/or".  Both are crucial.

Here is another proposal.

We can identify the kinds of attacks that need to be prevented.
- Flooding
- DDoS
- Remote Redirection
- ICMP effects
- ... others

For each kind, have a major section.
For each way that there might be some danger of such an
attack, have subsections.  Each subsection could be entitled:
"<Kind of Attack>:<Method>", where, for "Flooding" (to use
the example in our previous notes), <Method> might be
Abusing Binding Updates.

Another useful organization would be to have major sections
according to the Mobile IPv6 functionality involved.
But I think it would be better to have the sections according
to the attacks, and then have a later section that cross-references
the attacks according to the Mobile IPv6 functionality.  In fact,
maybe the "ICMP effects" from my earlier list would belong
in this later section.

So, for instance, this later section might look like:
- Binding Update
  = remote redirection if missing authentication (bad!)
  = flooding would be bad if CN/HA has to authenticate too much
- Binding Acknowledgement
  = bad if missing authentication
  = flooding would be bad if MN has to authenticate too miuch
- Binding Request
  = flooding would be bad if MN does too much work
- ...

Of course, I am just making this up, but I think such an organization
would be far more useful than the current document.  And, it would
seem to address your concerns also.

Regards,
Charlie P.





From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 03:45:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15765
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 03:45:36 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22436;
	Wed, 17 Oct 2001 01:44:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14550;
	Wed, 17 Oct 2001 00:44:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H7hFOI006819
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 00:43:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9H7hFDA006818
	for mobile-ip-dist; Wed, 17 Oct 2001 00:43:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H7hBOI006811
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 00:43:11 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14429
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 00:43:09 -0700 (PDT)
Received: from telesoft.indts.com ([164.164.71.52])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10082
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 00:43:13 -0700 (PDT)
Received: from indts_fs.indts.com (indts_fs [201.64.64.29])
	by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id MAA11204
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:09:38 +0530
Received: by INDTS_FS with Internet Mail Service (5.5.2650.21)
	id <VAVVJCC1>; Wed, 17 Oct 2001 11:59:21 +0530
Message-ID: <F73B646FCC01D5118F530002B32C33724C703D@INDTS_FS>
From: Amit Shakya <amits@indts.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] DOUBTS ABT. RFC 2002-bis-08 and RFC 2977
Date: Wed, 17 Oct 2001 11:59:20 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

hi 
I have a few queries.
1. The RFC 2002-bis-08 says that  
When a foreign agent receives a Registration Reply message, it MUST search
its visitor list for a pending Registration Request with the same mobile
node home address as indicated in the Reply.  If no such pending Request is
found, and if the Registration Reply does not correspond with any pending
Registration Request with a zero mobile node home address (see section
3.7.1), the foreign agent MUST silently discard the Reply. The foreign agent
MUST also silently discard the Reply if the low-order 32 bits of the
Identification field in the Reply do not match those in the Request.

Now my first doubt (first underline) abt. this is that why does the FA not
use the Identification field in the Replies and Requests for matching then,
when it has been provided for this purpose, apart from reply protection. why
Home Address has been suggested for matching?

My second question (second underline) is which mechanism does the FA use to
check matching replies and requests when zero mobile home address is
present?

Another doubt is that if the zero home address is sent, how will HA know
wether the Request is from a MN under its domain? how will such a request be
treated by HA?

Another doubt is in section 3.7.3.2, paragraph 2, which states that,
Finally, if the Code indicates that the registration was denied by the home
agent, the foreign agent MUST delete its pending
registration list entry, but not its visitor list entry, for the mobile
node.

while in paragraph 5 of the same section it is stated that
On the other hand, if the Registration Reply indicates that the registration
was rejected by the home agent, the foreign agent deletes its visitor list
entry for this attempted registration.

These two statements are contradicting. Now wat i wanna know is which is the
right behaviour on recieving a reply with code as HA rejection? shud the MN
entry be deleted from both vistor list and pending Registration Request
List? 


2. Another doubt is abt RFC 2977 which specifies the AAA Requirements for
Mobile IP.

Here no AAA messages or format for it has been specified and it has been
mentioned that FA will send it to AAA server. Now will the FA frame the
message from the Registration Request received and send it to AAA server or
FA will forward the whole Registration Request as such to AAA server ?
If FA will frame a message from the Registration Request, where can i get
info. abt the format of message formed or which fields are important and as
to how the message is formed?
Another thing is that RFC says that when the MN boots in a foreign subnet
and if it wants a service which is local to the foreign domain, then the FA
via AAA server can arrange a temporary HA and IP address for MN. And for
traffic from the actual HA to be routed to it, a dynamic update to DNS, to
associate the mobile node's home FQDN (Fully Qualified Domain Name ) with
its new IP address, will require insertion of a foreign IP address into the
home DNS server database. Now my question is who will do this update to DNS
? 
It will be nice, if someone could clarify my doubts and queries.
Regards,
Amit
 



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 04:36:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16297
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 04:36:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22573;
	Wed, 17 Oct 2001 02:36:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15001;
	Wed, 17 Oct 2001 01:36:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H8ZnOI007046
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 01:35:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9H8ZmOI007045
	for mobile-ip-dist; Wed, 17 Oct 2001 01:35:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H8ZiOI007038
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 01:35:44 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14851
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 01:35:48 -0700 (PDT)
Received: from muminmamman.lifix.fi ([195.238.204.197])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21945
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 02:35:29 -0600 (MDT)
Received: from ban by muminmamman.lifix.fi with local (Exim 3.12 #1 (Debian))
	id 15tmB0-0004c3-00
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:35:46 +0300
Date: Wed, 17 Oct 2001 11:35:46 +0300
From: Bjorn Andersson <bjorn@lifix.fi>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] DOUBTS ABT. RFC 2002-bis-08 and RFC 2977
Message-ID: <20011017113546.A16908@lifix.fi>
Mail-Followup-To: Bjorn Andersson <bjorn@lifix.fi>,
	mobile-ip@sunroof.eng.sun.com
References: <F73B646FCC01D5118F530002B32C33724C703D@INDTS_FS>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F73B646FCC01D5118F530002B32C33724C703D@INDTS_FS>
User-Agent: Mutt/1.3.20i
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, Oct 17 2001, at 11:59:20 +0530, Amit Shakya wrote:
> hi 
> I have a few queries.
> 1. The RFC 2002-bis-08 says that  
> When a foreign agent receives a Registration Reply message, it MUST search
> its visitor list for a pending Registration Request with the same mobile
> node home address as indicated in the Reply.  If no such pending Request is
> found, and if the Registration Reply does not correspond with any pending
> Registration Request with a zero mobile node home address (see section
> 3.7.1), the foreign agent MUST silently discard the Reply. The foreign agent
> MUST also silently discard the Reply if the low-order 32 bits of the
> Identification field in the Reply do not match those in the Request.
> 
> Now my first doubt (first underline) abt. this is that why does the FA not
> use the Identification field in the Replies and Requests for matching then,
> when it has been provided for this purpose, apart from reply protection. why
> Home Address has been suggested for matching?

Although very improbable, the ID field from two different mobile
nodes may be identical. 

> My second question (second underline) is which mechanism does the FA use to
> check matching replies and requests when zero mobile home address is
> present?

The NAI should be used as indicated in RFC2794. 

This leads to another question: RFC2794 says that "the foreign agent
SHOULD send the Registration Reply to the mobile node, changing the
Code to the value MISSING_NAI" if the Home Agent does not include
the NAI in the reply. I realize this is a SHOULD, but how does
the FA know which mobile to send the failure reply if the home address
was 0.0.0.0 in the request, and the home agent does not include
a NAI? The reply is silently discarded, right?

> Another doubt is that if the zero home address is sent, how will HA know
> wether the Request is from a MN under its domain? how will such a request be
> treated by HA?

It will know it from the home agent address and the NAI in the
request.

> Another doubt is in section 3.7.3.2, paragraph 2, which states that,
> Finally, if the Code indicates that the registration was denied by the home
> agent, the foreign agent MUST delete its pending
> registration list entry, but not its visitor list entry, for the mobile
> node.
> 
> while in paragraph 5 of the same section it is stated that
> On the other hand, if the Registration Reply indicates that the registration
> was rejected by the home agent, the foreign agent deletes its visitor list
> entry for this attempted registration.
> 
> These two statements are contradicting. Now wat i wanna know is which is the
> right behaviour on recieving a reply with code as HA rejection? shud the MN
> entry be deleted from both vistor list and pending Registration Request
> List? 

I think the foreign agent should not delete any valid previous 
registrations. The key words are probably "for this attempted
registration" in the 5th paragraph.

Bjorn

-- 
Bjorn Andersson <bjorn@lifix.fi>                       +358 50 341 2556
Lifix Systems Oy <http://www.lifix.fi/>                 PGP id 5AFC144B
Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 04:44:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16370
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 04:44:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27091;
	Wed, 17 Oct 2001 02:43:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15707;
	Wed, 17 Oct 2001 01:43:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H8h7OI007133
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 01:43:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9H8h6vf007132
	for mobile-ip-dist; Wed, 17 Oct 2001 01:43:06 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H8h2OI007125
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 01:43:02 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20961
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 01:43:00 -0700 (PDT)
Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26518
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 02:42:46 -0600 (MDT)
Received: (from smap@localhost)
	by tml-gw.tml.hut.fi (8.8.7/8.8.7) id LAA12616;
	Wed, 17 Oct 2001 11:39:42 +0300
Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0)
	id xma012610; Wed, 17 Oct 01 11:39:13 +0300
Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7])
	by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f9H8e7D04361;
	Wed, 17 Oct 2001 11:40:07 +0300 (EEST)
Received: from localhost (lpetande@localhost)
	by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id LAA07372;
	Wed, 17 Oct 2001 11:42:13 +0300 (EEST)
X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs
Date: Wed, 17 Oct 2001 11:42:13 +0300 (EEST)
From: Henrik Petander <lpetande@tml.hut.fi>
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
In-Reply-To: <Roam.SIMC.2.0.6.1003261924.19172.nordmark@bebop.france>
Message-ID: <Pine.SOL.4.10.10110171103300.7311-100000@morphine.tml.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, 16 Oct 2001, Erik Nordmark wrote:

> > > Only if you believe there will be pre-existing security associations
> > between
> > > the MN and all possible default routers it uses while moving around ,
> > > does it make sense to treat them the same.
> >  
> > The main point was that if MN and its regular HA need a "strong" SA, so do
> > MN and its "foreign" HA. I agree that the assumption that MN and its HA
> > have a preconfigured security association might not easily apply to the
> > "foreign" HAs. Probably they and MN will still have an existing trust
> > relationship, so that they can create a "strong" SA.
> 
> Could you explain the source of your belief expressed in the last sentence?

MN and the ISP providing the access via the router are likely to have a
trust relationship, since MN is allowed to use the resources of the ISP.
This trust relationship could be used also between the (acccess) routers
acting as HAs and MN to authorize the use of the HA service.

I think that the problem of authorizing the home registration is twofold,
on one hand MN needs to prove that it is allowed to use the service of HA,
and on the other it needs to prove that it "owns" the possibly temporary
address it is trying to register with the HA. The trust relationship
between MN and the default router could easily be used for the first
purpose, but for the second purpose something else is needed. 

One possible solution is that MN creates the SA with the "foreign" HA when
it is in the same network as the HA and, if the HA does not have an
existing registration / SA for that address it accepts the SA, provided
that MN is authorized to use the HA service. If the registration fails MN
creates a new CoA with a random host identifier and tries to establish a
SA for it. DAD would guarantee that there would not be two nodes with the
same address.

MN presents its credentials to the HA to gain access to the HA service, so
only nodes authorized to use the service of the HA could establish SAs and
do home registrations for the addresses. This should protect the system
against DoS attacks effectively. The same system could perhaps be used
also for "normal" home registration with dynamic DNS. 

What do you think?

Henrik

> 
>   Erik
> 

		----------------------------------
		Henrik Petander 		
		Helsinki University of Technology,	
		GO/Core Project 
		Henrik.Petander@hut.fi
		Office: +358 (0)9 451 5846 
		GSM: +358 (0)40 741 5248	
		----------------------------------



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 05:47:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16795
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 05:47:34 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA23313;
	Wed, 17 Oct 2001 02:47:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09694;
	Wed, 17 Oct 2001 02:47:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H9k5OI007271
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 02:46:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9H9k4qV007270
	for mobile-ip-dist; Wed, 17 Oct 2001 02:46:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H9k1OI007263
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 02:46:01 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08912
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 02:46:04 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01895
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 03:45:44 -0600 (MDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9H9k2j29930
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:46:02 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Oct 17 11:46:01 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <THZ74L2T>; Wed, 17 Oct 2001 11:46:01 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320C5205BF@esealnt117>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof
	fs-v4-02.txt
Date: Wed, 17 Oct 2001 11:45:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hello James

> General comment: There are many cases in the document
> in which prescriptive, normative statements are made
> about the protocol that are not phrased in RFC 2119
> language. For example, pg. 16, paragraph 3:
> 
> "...Therefore tunneling advertisements is only
> applicable where the TTL limitation of [1] can be
> relaxed. This should be the case for unicast
> messages."
> 
> Is the last "should" really a SHOULD? Or is it a MUST?
> There are many other examples. The language here needs
> to be tightened.

OK, I'll read it through to clarify these.

> 
> 1) pg. 3 end of paragraph 2, Appendix B. 
> Appendix B is very tentative and not very well tied to
> the protocol discussed. There may well be ways to do
> intertechnology handoff that do involve the protocol.
> For example, suppose the 2nd interface has no IP
> address, and the MN discovers the new AP/FA via either
> L2 information on the second interface, or via a
> capabilities discovery protocol through the configured
> interface (such as the Seamoby CAR discovery
> protocol). The MN could then issue a ProxyRtSol on the
> configured interface for the new FA, and when it
> received the ProxyRtAdv, it could tear down the home
> IP address on the old interface and transfer it to the
> new. This has nothing to do with low latency handoff,
> but it is a use of the protocol that would allow
> seamless handover to a new interface. Note that this
> would avoid having the MN solicit a regular FA Advert
> over multiple subnets.
> 
> I'm not sure how to address this issue. Perhaps
> folding the Appendix into the text with a discussion
> of about how the protocol could, in fact, support
> intertechnology handover would be appropriate.
> Alternatively, given the urgency of getting this
> document out, perhaps sectioning it off into a
> separate document would be better.

The Appendix used to be in the main text. It is only meant
to give an example of a simple way to do handoffs over
multiple interfaces. It does say that the low latency
method may be needed anyway, but provides a scenario
where it could be avoided (depending on coverage areas).
It is more to do with applicability of low latency in
general. I think it should stay somewhere in the doc.
Anyone have strong opinions regarding Appendix vs. main
text?

> 
> 2) pg. 4, definition of bi-directional edge tunneling-
> This still includes text implying that bicasting is
> required. I would suggest changing the first and
> second sentences to:
> 
> "A set of unidirectional tunnels established between
> two FAs for purposes of temporarily routing a MN's
> traffic to/from  it on a new subnet without requiring
> the MN to change CoA."

Missed that one. I'll change it.

> 
> 3) pg. 22, point 4c
> The requirements language needs tightening (specific
> case of general comment.) How about:
> 
> "c) When the MN receives the L2-LU, it MAY initiate
> the Mobile IP Registration process by soliciting an
> Agent Advertisement as described in [1]. If the
> Registration is successful, the nFA takes over the
> role of anchor FA (aFA) from the oFA. The MN MAY also
> choose to defer nCoA establishment, if real time
> traffic is occuring (see Section 4.4)."

We don't have any traffic considerations in the draft, but
apart from that it makes sense.

> 
> 4) pg. 24, Section 4.2, paragraph 1.
> The requirement level of MAY for HTT is too weak.
> There are some radio protocols where HTT is required,
> others where it may not be. It needs tightening. I
> would suggest the following wording:
> 
> "For radio L2 protocols in which it is possible for
> the MN to move so rapidly from one FA to another that
> that a probability exists that nCoA establishment on
> the initial nFA will not complete, HTT MUST be
> implemented. For other radio L2 protocols with
> sufficient L2 trigger support, HTT SHOULD be
> implemented as it provides the opportunity for the MN
> to optimize handover of real time traffic at the
> expense of a certain amount of header overhead on the
> backbone network."

MUST cannot be used in this way. From RFC 2119:

   MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Since HTT is only applicable in certain cases where the MN moves too fast,
it is not an absolute requirement of this spec. What I would propose is
just to use the first part of your text modified along these lines:

"For radio L2 protocols in which it is possible for the MN to move so rapidly
from one FA to another such that a probability exists that the Mobile IP
Registration with nFA will not complete before the MN moves on, HTT SHOULD be
implemented."

> 
> 5) pg. 30, Section 4.4, point 1)
> "...sending the an Agent Advertisement to the MN..."
> ->
> "...sending an Agent Advertisement to the MN"

OK.

> 
> 6) pg. 30, Section 4.4
> The discussion in this section is valuable and useful,
> but too restrictive IMHO and also does not consider a
> couple of other cases. First off, is the FA
> necessarily
> always the default router? Secondly, if not, then the
> FA registration, and, in addition, the HA registration
> need to be renewed as well. Thirdly, since the routing
> through the tunnel for POST-REG is already set up,
> what is the problem with simply renewing down the
> tunnel to the old default router and/or FA, and to the
> HA?

I think the assumption is that the FA is the default
router, but this can be changed if the WG thinks it is
too restrictive. If the FA is not the default router then
reverse tunneling MN traffic to oFA would be complex. Also,
renewing oFA as default router can be done only if the nFA
reverse tunnels traffic to oFA so it does not apply to all
POST-REG. If the FA as default router assumption is valid we could
add a few lines on the specific nFA to oFA reverse tunneling case
where oFA RAs are tunneled through nFA to the MN (in a similar
way to PRE-REG but in the opposite direction).

> 
> As a practical matter, I think most BETs will be
> terminated well before the 30 min. lifetime of the
> default router advert (phone calls reputedly last on
> the average about 3 minutes). But unless there are any
> specific issues affecting interoperability, I believe
> exactly when the network or MN should demand
> termination of the BET should be left up to the
> implementation. One such case obviously is if HTT is
> not implemented, in that case, the MN must terminate
> the BET after the first handoff.
> 

I also think that the 30 min. lifetime is not a major
limitation since MNs wouldn't delay registrations that long.

> 7) pg. 32, definition of Lifetime, pg. 33 definition
> of Lifetime:
> 0xffff should be defined as "good until canceled",
> not "infinite".

That is what is meant by "infinity". From RFC2002 on
Registration lifetime: "A value of 0xffff indicates infinity"
Of course the registration can be terminated using lifetime zero.

> 
> 8) pg. 36, Section 6, first paragraph
> This paragraph is trying to say that for particular
> radio protocols, deployment situations, and
> implementations, smoothing techniques may be required,
> but it is very ambiguous and hard to figure out what
> is being said, IMHO. The title of the section should
> be changed to "Handoff Smoothing Considerations" and
> the language should be tightened to address the issue
> directly. 

It's not only handoff smoothing this section considers,
it's also other issues related to the trigger and handoff
timing. I'll read through to see if I can clarify things.

> 
> 9) Appendix A, also reference [2]
> During IETF 51, there was some discussion about not
> wanting to put a reference in to the abstract L2
> triggers draft in order not to end up with a reference
> to a draft that was not close to RFC, to avoid slowing
> down the progress of low latency. Yet, here is a
> potential reference to exactly such a draft. How close
> to RFC is the regional registration draft? Would it
> make sense to remove the reference, since, while
> extremely useful in the global picture of optimizing
> MIP signalling, the relationship between regional
> registration and low latency handover is somewhat
> tenuous.

I think we should be safe in referring to Regional, but
the chairs can help with this one.
The relationship between PRE-REG and Regional is quite clear
so there is benefit in keeping it as an option since it reduces
latency. It is less useful to POST-REG. 

Rgds,
/Karim


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 06:06:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16931
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 06:06:17 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12085;
	Wed, 17 Oct 2001 04:05:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11688;
	Wed, 17 Oct 2001 03:05:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HA4aOI007387
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 03:04:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HA4aZq007386
	for mobile-ip-dist; Wed, 17 Oct 2001 03:04:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HA4XOI007379
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 03:04:33 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23979
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 03:04:34 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA10649
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 04:24:28 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9HA4Ui15744
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:04:30 +0300
Date: Wed, 17 Oct 2001 13:04:30 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Mobile IP Working Group Mailing List <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Comments on security requirements draft
In-Reply-To: <3BCC9540.66113EFD@iprg.nokia.com>
Message-ID: <Pine.LNX.4.33.0110171242170.15596-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I'll comment on two issues only, both are rather generic.

On Tue, 16 Oct 2001, Charlie Perkins wrote:
> Use of the word "introduce" means that the threat did not
> exist before Mobile IPv6, and that the threat does exist
> now.  This is clearly wrong, because mostly Mobile IPv6
> does not introduce or even enable the threats that are
> described.  Most often, the discussion centers around the
> threat introduced by "remote redirection", terminology
> predating even Mobile IPv4 (see RFC 2002).  Mobile IPv6 does
> not enable this threat, and certainly does not introduce it.
> Every use of the word "introduce" should be carefully
> considered in this light.  I checked on this, and it's
> not just in the existing title where the mistake is made.

(a more general comment)

I've noted that a few people here have a dangerous way of thinking
(perhaps unbeknownst to them), that it is enough to specify how Mobile
IPv6, _as specified_, can be secured.  That is, HA<->MN, MN<->CN etc. are
secure.

There is a lot more to it.

MIPv6 introduces Home Address option, takes Routing Header into very 
widespread use, assumes a lot about Binding Updates, specifies new ICMP 
types, etc.

In my book, it's also the (at least a major part of the) responsibility of
mobile-ip wg to see that these enhancements to the core protocols are
secure and proper.

The latter is a reason I tried to raise awareness with my rh-ha-security
draft.
 
> Plus, every time it is mentioned, it MUST be made very
> clear that the threat DOES NOT EXIST in current (or past!)
> Mobile IPv6 specification revisions.  Otherwise I fear
> we will be diverted towards chasing problems that are not
> there.

How do you expect the implementors to handle this?  To make MIPv6 useful,
binding updates are pretty much needed (or are they?).  They must be
authenticated by the spec.  In practise authentication cannot be done, and
thus no binding updates are possible in general case.

We've seen previously that this may lead to "hmm.. we're just testing now,
and there isn't so much harm to it.. I'll just ignore that point of the
spec, and accept unauthenticated BU's for now.. after all, we have
deadlines to meet, and we'd like to get MIPv6 out very soon for the good
of the everyone.  We can worry about BU's later."

Ie. it's good to remind of these issues lest we'd adapt too weak security 
measures to cope for the lack of scalability of IKE.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 08:04:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19560
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 08:04:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01036;
	Wed, 17 Oct 2001 05:04:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21596;
	Wed, 17 Oct 2001 05:04:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HC3aOI007644
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 05:03:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HC3ZU1007643
	for mobile-ip-dist; Wed, 17 Oct 2001 05:03:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HC3WOI007636
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 05:03:32 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04113
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 05:03:34 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17496
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 05:03:34 -0700 (PDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id FAA21104 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 05:03:33 -0700 (MST)]
Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA26522 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 04:54:27 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Wed, 17 Oct 2001 07:03:31 -0500
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id AE9B82ED2F; Wed, 17 Oct 2001 13:58:57 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: charliep@iprg.nokia.com
Subject: Re: [mobile-ip] Comments on security requirements draft
References: <3BCC9540.66113EFD@iprg.nokia.com>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 17 Oct 2001 14:03:09 +0200
In-Reply-To: <3BCC9540.66113EFD@iprg.nokia.com>
Message-Id: <m3u1wytqwy.fsf@test9.crm.mot.com>
Lines: 20
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Charlie Perkins <charliep@iprg.nokia.com> writes:
> Requirement B.4: replace "ensure it trusts the sender of" by
> "authenticate".

Hi Charlie,

I think the way it's currently formulated it allows for more than
crypto solutions.  If Binding Acks must be "authenticated" then some
authentication data exchange should take place between sender and
receiver.  On the other hand, if receiver of Binding Acks only
"trusts" the sender, then receiver might rely on other things than
crypto (for example return routability) to "trust" the sender.  Maybe
"trust" is too strong of a word, then something else.

If needed, I can give two different solutions each one satisfying one
of the versions of this requirement.

Just an oppinion, thanks for your remark,

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 11:10:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26995
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 11:10:37 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14114;
	Wed, 17 Oct 2001 08:10:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02658;
	Wed, 17 Oct 2001 08:09:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HF8xOI007918
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 08:08:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HF8x9q007917
	for mobile-ip-dist; Wed, 17 Oct 2001 08:08:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HF8tOI007910
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 08:08:55 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21116
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 08:08:57 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15299
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 08:08:57 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA11044;
	Wed, 17 Oct 2001 08:08:56 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9HF8tU02867;
	Wed, 17 Oct 2001 08:08:55 -0700
X-mProtect:  Wed, 17 Oct 2001 08:08:55 -0700 Nokia Silicon Valley Messaging Protection
Received: from maxdialin6.iprg.nokia.com (205.226.20.236, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdDOHj0T; Wed, 17 Oct 2001 08:08:53 PDT
Message-ID: <3BCD9F0C.20C2EECB@iprg.nokia.com>
Date: Wed, 17 Oct 2001 08:09:00 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Comments on security requirements draft
References: <Pine.LNX.4.33.0110171242170.15596-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Pekka,

Some clarifications/comments below...

Pekka Savola wrote:

> I've noted that a few people here have a dangerous way of thinking
> (perhaps unbeknownst to them), that it is enough to specify how Mobile
> IPv6, _as specified_, can be secured.  That is, HA<->MN, MN<->CN etc. are
> secure.

I think the point would be to point out the areas for concern, and
point out Mobile IPv6 features should be designed to avoid problems.
My specific issue that I raised was with the wording, used several
times within the draft, that indicated to a fresh reader that Mobile IPv6
"introduces" problems enabling remote redirection attacks.

> There is a lot more to it.

But my remark was specific to that issue.  I do not claim that is the
only issue.

> MIPv6 introduces Home Address option, takes Routing Header into very
> widespread use, assumes a lot about Binding Updates, specifies new ICMP
> types, etc.
>
> In my book, it's also the (at least a major part of the) responsibility of
> mobile-ip wg to see that these enhancements to the core protocols are
> secure and proper.

Your book seems to be a lot like my book in this respect.

> > Plus, every time it is mentioned, it MUST be made very
> > clear that the threat DOES NOT EXIST in current (or past!)
> > Mobile IPv6 specification revisions.  Otherwise I fear
> > we will be diverted towards chasing problems that are not
> > there.
>
> How do you expect the implementors to handle this?

Pretty much the way they did handle it.  Our implementations
have handled it in ways that weren't too beautiful for configuring
security associations, but the protocol was right and the authentication
was done correctly.

>                                                                      To make
> MIPv6 useful,
> binding updates are pretty much needed (or are they?).

They are needed, unequivocably.  The only way you could argue
otherwise is for the case when someone is building a system in which
the mobile nodes cannot send packets to arbitrary IPv6 correspondent
nodes.  I think such systems would be very rare.

>
> They must be
> authenticated by the spec.  In practise authentication cannot be done, and
> thus no binding updates are possible in general case.

In practice, authentication can be done, but the ways of setting up
security associations are currently not scalable.  That is a much different
statement, and I think it is a good idea to keep track of the difference.

> We've seen previously that this may lead to "hmm.. we're just testing now,
> and there isn't so much harm to it.. I'll just ignore that point of the
> spec, and accept unauthenticated BU's for now.. after all, we have
> deadlines to meet, and we'd like to get MIPv6 out very soon for the good
> of the everyone.  We can worry about BU's later."

Maybe there are examples in other working groups, but I would
be surprised if anyone following the discussion over the last two
years in this working grop would come to that conclusion.  Plus,
it would be almost impossible to imagine vendors with roaming
agreements believing such a thing.

What I had expected was that after the base protocol was done,
there would be room for people to develop follow-on security
protocols to address the scalability issues.  Plus there would be
a lot of usefulness for initial deployments that would work even
suffering the disadvantages of triangle routing -- witness Mobile IPv4.
The additional security protocols for key exchange would then
look like scalability upgrades, and over time more and more of
the original correspondent nodes would have gotten upgraded.

> Ie. it's good to remind of these issues lest we'd adapt too weak security
> measures to cope for the lack of scalability of IKE.

I still think that would have been a better idea to issue Mobile IPv6 as a
Proposed Standard with non-scalable key exchange, rather than to have
this long delay (no secret).  One result has been to put at least an equally
long delay in the process of adopting Mobile IPv6 as part of the mobility
management solution for 3G telephony.  But that doesn't mean I am going
to sit around complaining about it.  Instead, I hope to be part of the
solution
towards designing a scalable answer for establishing the appropriate security
associations.

Regards,
Charlie P.



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 12:09:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28692
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 12:09:35 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28679;
	Wed, 17 Oct 2001 10:08:16 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02812;
	Wed, 17 Oct 2001 09:08:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HG7ROI008116
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 09:07:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HG7Rk3008115
	for mobile-ip-dist; Wed, 17 Oct 2001 09:07:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HG7OOI008108
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 09:07:24 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16829
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 09:07:26 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22195
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 09:07:26 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9HG5IC26768
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 09:05:19 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAH09019;
	Wed, 17 Oct 2001 09:07:01 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08309; Wed, 17 Oct 2001 09:07:25 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15309.44220.939281.224131@thomasm-u1.cisco.com>
Date: Wed, 17 Oct 2001 09:07:24 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Comments on security requirements draft
In-Reply-To: <Pine.LNX.4.33.0110171242170.15596-100000@netcore.fi>
References: <3BCC9540.66113EFD@iprg.nokia.com>
	<Pine.LNX.4.33.0110171242170.15596-100000@netcore.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola writes:
 > > Plus, every time it is mentioned, it MUST be made very
 > > clear that the threat DOES NOT EXIST in current (or past!)
 > > Mobile IPv6 specification revisions.  Otherwise I fear
 > > we will be diverted towards chasing problems that are not
 > > there.
 > 
 > How do you expect the implementors to handle this?  To make MIPv6 useful,
 > binding updates are pretty much needed (or are they?).  They must be
 > authenticated by the spec.  In practise authentication cannot be done, and
 > thus no binding updates are possible in general case.

   Right. This is unhelpful at best, and an
   equivocation at worst. Trying to play spin
   control on the draft serves no purpose.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 13:09:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00434
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 13:09:41 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28938;
	Wed, 17 Oct 2001 11:09:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03053;
	Wed, 17 Oct 2001 10:09:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HH81OI008306
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:08:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HH81Wn008305
	for mobile-ip-dist; Wed, 17 Oct 2001 10:08:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HH7wOI008298
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:07:58 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21347
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:08:01 -0700 (PDT)
Received: from web13907.mail.yahoo.com (web13907.mail.yahoo.com [216.136.175.70])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA29678
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:28:26 -0600 (MDT)
Message-ID: <20011017170757.82853.qmail@web13907.mail.yahoo.com>
Received: from [216.98.102.225] by web13907.mail.yahoo.com via HTTP; Wed, 17 Oct 2001 10:07:57 PDT
Date: Wed, 17 Oct 2001 10:07:57 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof fs-v4-02.txt
To: mobile-ip@sunroof.eng.sun.com
Cc: james@docomolabs-usa.com
In-Reply-To: <795A014AF92DD21182AF0008C7A404320C5205BF@esealnt117>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Karim,

> The Appendix used to be in the main text. It is only
> meant
> to give an example of a simple way to do handoffs
> over
> multiple interfaces. It does say that the low
> latency
> method may be needed anyway, but provides a scenario
> where it could be avoided (depending on coverage
> areas).
> It is more to do with applicability of low latency
> in
> general. I think it should stay somewhere in the
> doc.
> Anyone have strong opinions regarding Appendix vs.
> main
> text?
> 

Well, to avoid thrash, let's keep it in the Appendix
then. I actually think there is need for another draft
that clearly specifies how to do intertechnology
handoff, for interoperability purposes, and that this
text would be a good start, but unless the chairs or
another WG member have other ideas, I think we can
send it to the IESG with the Appendix and see whether
or not they feel it is necessary.

> MUST cannot be used in this way. From RFC 2119:
> 
>    MUST   This word, or the terms "REQUIRED" or
> "SHALL", mean that the
>    definition is an absolute requirement of the
> specification.
> 
> Since HTT is only applicable in certain cases where
> the MN moves too fast,

I actually don't agree that this is the case. It is
also applicable to a low bandwidth radio protocol if
the MN wants to delay changing its CoA because it has
real time traffic and the MIP signaling would steal
bandwidth from the real time traffic.

> it is not an absolute requirement of this spec. What
> I would propose is
> just to use the first part of your text modified
> along these lines:
> 
> "For radio L2 protocols in which it is possible for
> the MN to move so rapidly
> from one FA to another such that a probability
> exists that the Mobile IP
> Registration with nFA will not complete before the
> MN moves on, HTT SHOULD be
> implemented."
> 

I would prefer that the second part be included as
well. If you want, it could also be clarified:

"In addition, HTT SHOULD be implemented for low
bandwidth radio protocols in which MIP signaling may
cause a disruption in real time traffic, since it
allows the MN to seamlessly continue real time traffic
onto a third FA during handover without any MIP
signaling."


>I think the assumption is that the FA is the default
>router, but this can be changed if the WG thinks it
is
>too restrictive. If the FA is not the default router
>then
>reverse tunneling MN traffic to oFA would be complex.
>Also,
>renewing oFA as default router can be done only if
>the nFA
>reverse tunnels traffic to oFA so it does not apply
>to all
>POST-REG. If the FA as default router assumption is
>valid we could
>add a few lines on the specific nFA to oFA reverse
>tunneling case
>where oFA RAs are tunneled through nFA to the MN (in
>a similar
>way to PRE-REG but in the opposite direction).


OK.

>I also think that the 30 min. lifetime is not a major
>limitation since MNs wouldn't delay registrations
>that long.

Agree, but I would leave the actual time out of the
text.

In some respects, since the MN will have to do
signaling over the radio channel to renew its
registrations, it's a tossup whether it terminates use
of the old CoA or not, but I still think it should be
left open as a policy issue. The FA can always demand
termination of the BET if the MN's registration is
reaching the end of its lifetime.

>That is what is meant by "infinity". From RFC2002 on
>Registration lifetime: "A value of 0xffff indicates
>infinity"
>Of course the registration can be terminated using
>lifetime zero.

If there is precedent for the terminology, then let's
leave it as is.

>It's not only handoff smoothing this section
>considers,
>it's also other issues related to the trigger and
>handoff
>timing. I'll read through to see if I can clarify
>things.

OK. I really couldn't figure it out, sorry.

>I think we should be safe in referring to Regional,
>but
>the chairs can help with this one.
>The relationship between PRE-REG and Regional is
>quite clear
>so there is benefit in keeping it as an option since
>it reduces
>latency. It is less useful to POST-REG. 

Far as I can tell, the WG wants to fast track low
latency, so I think we need to be careful about what
we include in the references. I agree that there is a
clear relationship, and even benefit should Regional
get some deployment momentum, but I think we want to
limit our exposure to possible delays. We could send
it to the IESG with a specific question about whether
or not the reference to Regional should be kept.

Raj, Phil, what do you think?

                     jak


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 13:43:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01268
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 13:43:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00099;
	Wed, 17 Oct 2001 11:42:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00942;
	Wed, 17 Oct 2001 10:42:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HHfmOI008441
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:41:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HHfmH4008440
	for mobile-ip-dist; Wed, 17 Oct 2001 10:41:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HHfiOI008433
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:41:44 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11643
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:41:45 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23358
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:41:45 -0700 (PDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HHfmQ19803
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:41:48 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56a7173a33ac12f256126@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Wed, 17 Oct 2001 12:41:44 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 17 Oct 2001 12:41:57 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Comments on security requirements draft
Date: Wed, 17 Oct 2001 12:41:44 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCE9B@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Comments on security requirements draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFXKEjahktkOcMbEdWBTQBQi2X+DwACqmtg
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 17 Oct 2001 17:41:57.0872 (UTC) FILETIME=[04CF2F00:01C15733]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9HHfjOI008434
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Michael Thomas [mat@cisco.com] wrote:
>Pekka Savola writes:
> > > Plus, every time it is mentioned, it MUST be made very
> > > clear that the threat DOES NOT EXIST in current (or past!)
> > > Mobile IPv6 specification revisions.  Otherwise I fear
> > > we will be diverted towards chasing problems that are not
> > > there.
> > 
> > How do you expect the implementors to handle this?  To make MIPv6
useful,
> > binding updates are pretty much needed (or are they?).  They must be
> > authenticated by the spec.  In practise authentication cannot be
done, and
> > thus no binding updates are possible in general case.
>
>   Right. This is unhelpful at best, and an
>   equivocation at worst. Trying to play spin
>   control on the draft serves no purpose.
>

I believe we are working on engineering (iEtf) a solution to the
problem. "Spin control" (at least the way I understand it) is not
something that this WG should be spending cycles on. Please do not
(mis)read someones valid comments as being anything else. Lets keep
the discussion on finding a solution to the BU problem. Everyone is
entitled to their opinions, but this discussion list is for debating
the technical aspects of Mobile IP.
  
>	   Mike
>

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 13:59:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01732
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 13:59:19 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14865;
	Wed, 17 Oct 2001 11:58:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06593;
	Wed, 17 Oct 2001 10:58:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HHvdOI008587
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:57:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HHvd0b008586
	for mobile-ip-dist; Wed, 17 Oct 2001 10:57:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HHvZOI008579
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:57:35 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06141
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:57:36 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04285
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:57:35 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9HHvfg01220
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 10:57:41 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAH12102;
	Wed, 17 Oct 2001 10:57:11 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08339; Wed, 17 Oct 2001 10:57:34 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15309.50830.584253.146235@thomasm-u1.cisco.com>
Date: Wed, 17 Oct 2001 10:57:34 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Comments on security requirements draft
In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CCE9B@daebe007.NOE.Nokia.com>
References: <697DAA22C5004B4596E033803A7CEF444CCE9B@daebe007.NOE.Nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Patil Basavaraj (NET/Dallas) writes:
 > Michael Thomas [mat@cisco.com] wrote:
 > >Pekka Savola writes:
 > > > > Plus, every time it is mentioned, it MUST be made very
 > > > > clear that the threat DOES NOT EXIST in current (or past!)
 > > > > Mobile IPv6 specification revisions.  Otherwise I fear
 > > > > we will be diverted towards chasing problems that are not
 > > > > there.
 > > > 
 > > > How do you expect the implementors to handle this?  To make MIPv6
 > useful,
 > > > binding updates are pretty much needed (or are they?).  They must be
 > > > authenticated by the spec.  In practise authentication cannot be
 > done, and
 > > > thus no binding updates are possible in general case.
 > >
 > >   Right. This is unhelpful at best, and an
 > >   equivocation at worst. Trying to play spin
 > >   control on the draft serves no purpose.
 > >
 > 
 > I believe we are working on engineering (iEtf) a solution to the
 > problem. "Spin control" (at least the way I understand it) is not
 > something that this WG should be spending cycles on. Please do not
 > (mis)read someones valid comments as being anything else. Lets keep
 > the discussion on finding a solution to the BU problem. Everyone is
 > entitled to their opinions, but this discussion list is for debating
 > the technical aspects of Mobile IP.

   Uh, I'm not the one who's trying to play the
   spin control game here. I'm saying that the
   current requirements draft is fine as-is in
   this respect. If you have a problem with this,
   you should take it up with the person who
   insists on obscuring the fact that the current
   MIPv6 draft isn't problematic on the BU
   authentication/authorization front. I'm not 
   the only one who has commented on this.

   And I've already sent comments on the draft
   about two weeks ago, for which the authors
   have not replied.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 14:20:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02447
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 14:20:55 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05008;
	Wed, 17 Oct 2001 12:20:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12356;
	Wed, 17 Oct 2001 11:20:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HIIqOI008704
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:18:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HIIqEl008703
	for mobile-ip-dist; Wed, 17 Oct 2001 11:18:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HIImOI008696
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:18:49 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11922
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:18:50 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18122
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:18:49 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9HIJ3u01047
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:19:03 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAH12753;
	Wed, 17 Oct 2001 11:18:23 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA08343; Wed, 17 Oct 2001 11:18:47 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15309.52102.939120.538717@thomasm-u1.cisco.com>
Date: Wed, 17 Oct 2001 11:18:46 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <Pine.LNX.4.33.0110151328370.31771-100000@netcore.fi>
References: <m3ofna6jsi.fsf@test9.crm.mot.com>
	<Pine.LNX.4.33.0110151328370.31771-100000@netcore.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola writes:
 > But the _real problem_, one could say caused by MIPv6, is that all nodes
 > (at least all mobile nodes) _must_ have this Routing Header processing
 > enabled.  One could say MIPv6, as defined, may open every mobile node for
 > abuse.
 > 
 > If there was no MIPv6, there would be no strong need to be able to process 
 > routing headers in hosts, only a few, possibly hand-picked, routers.  The 
 > risks would be manageable.

   Couldn't there be different requirements for hosts
   vs. routers? Ie, a node MUST process a packet with
   a routing header, but MAY drop packets for which the
   next destination address is not a valid destination
   address for the host?

   Ie, the host will forward to its stack, but not
   out another interface? This seems pretty consistant
   with the definition of hosts and routers.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 14:28:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02739
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 14:28:43 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12632;
	Wed, 17 Oct 2001 12:28:11 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15271;
	Wed, 17 Oct 2001 11:28:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HIRSOI008827
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:27:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HIRRoL008826
	for mobile-ip-dist; Wed, 17 Oct 2001 11:27:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HIROOI008819
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:27:24 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25170
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:27:26 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20341
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:48:40 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9HIP6C24008;
	Wed, 17 Oct 2001 11:25:07 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAH13085;
	Wed, 17 Oct 2001 11:26:49 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA08346; Wed, 17 Oct 2001 11:27:13 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15309.52609.209715.621661@thomasm-u1.cisco.com>
Date: Wed, 17 Oct 2001 11:27:13 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: Catharina Linnea Candolin <candolin@tml.hut.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
In-Reply-To: <Pine.LNX.4.33.0110161237260.7307-100000@netcore.fi>
References: <Pine.SOL.4.10.10110161027170.1627-100000@morphine.tml.hut.fi>
	<Pine.LNX.4.33.0110161237260.7307-100000@netcore.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola writes:
 > Let me phrase it this way:
 > 
 > If a CN does not have a binding for the MN, would there be any need for CN
 > to process HA option?
 > 
 > I don't think so, but I may be wrong.

   I believe it does. Even if the CN ignores the
   BU, it needs to process the HA option so that
   it can properly receive datagrams from a topologically
   incorrect address (ie, at the new CoA). Otherwise
   TCP, etc, would fail since it looks up the src/port
   normally, which wouldn't find a TCB for the CoA.

	     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 14:47:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03512
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 14:47:40 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04526;
	Wed, 17 Oct 2001 11:46:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20118;
	Wed, 17 Oct 2001 11:45:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HIicOI008955
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:44:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HIicGA008954
	for mobile-ip-dist; Wed, 17 Oct 2001 11:44:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HIiYOI008947
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:44:34 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19688
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:44:36 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04925
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:44:35 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9HIikm00459;
	Wed, 17 Oct 2001 11:44:47 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAH13592;
	Wed, 17 Oct 2001 11:44:06 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA08351; Wed, 17 Oct 2001 11:44:29 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15309.53645.716228.547790@thomasm-u1.cisco.com>
Date: Wed, 17 Oct 2001 11:44:29 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: lpetande@tml.hut.fi, Catharina Linnea Candolin <candolin@tml.hut.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)
In-Reply-To: <Roam.SIMC.2.0.6.1003244044.19675.nordmark@bebop.france>
References: <Pine.SOL.4.10.10110161027170.1627-100000@morphine.tml.hut.fi>
	<Roam.SIMC.2.0.6.1003244044.19675.nordmark@bebop.france>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Erik Nordmark writes:
 > Only if you believe there will be pre-existing security associations between
 > the MN and all possible default routers it uses while moving around ,
 > does it make sense to treat them the same.

Erik, 

I brought this point up in my comments as well
Currently, the draft is silent about any
differences between "home" HA's and other kinds of
HA's (basically tunnel drop off points). My
general inclination is that given the permanent
DoS, MITM, etc, kinds of attacks that can be
mounted by an illegitimate HA of any kind, it
would be prudent to require strong authentication
all the time.

Also: I'm not sure I buy your induction of
non-Home-HA's (<-- ick!) to CN's at large.  While
it's not always the case, it's fairly clear that
you could create cross realm relationships to deal
with MN/HA(FA) keying. Since there is likely to be
admission control on the foreign network in many
cases, it's not really the any-to-any keying
problem that MN/CN presents. Since these localized
HA's are just an optimization for fast/smooth
handoffs, I don't really see them as being in the
same class: there's probably a lot of implicit
assumptions about QoS, security, context transfer,
etc to affect that, and the probably means a
fair amount of linkage to AAA-like subsystems,
unlike the MN/CN communication.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 15:01:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03933
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 15:01:39 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11232;
	Wed, 17 Oct 2001 12:01:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24898;
	Wed, 17 Oct 2001 12:01:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HJ03OI009102
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:00:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HJ03BN009101
	for mobile-ip-dist; Wed, 17 Oct 2001 12:00:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HIxxOI009094
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:59:59 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24358
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:00:00 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11907
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 11:59:59 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9HIxv719020;
	Wed, 17 Oct 2001 21:59:57 +0300
Date: Wed, 17 Oct 2001 21:59:57 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Catharina Linnea Candolin <candolin@tml.hut.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6 (fwd)
In-Reply-To: <15309.52609.209715.621661@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.33.0110172157130.19013-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 17 Oct 2001, Michael Thomas wrote:
> Pekka Savola writes:
>  > Let me phrase it this way:
>  > 
>  > If a CN does not have a binding for the MN, would there be any need for CN
>  > to process HA option?
>  > 
>  > I don't think so, but I may be wrong.
> 
>    I believe it does. Even if the CN ignores the
>    BU, it needs to process the HA option so that
>    it can properly receive datagrams from a topologically
>    incorrect address (ie, at the new CoA). Otherwise
>    TCP, etc, would fail since it looks up the src/port
>    normally, which wouldn't find a TCB for the CoA.

True.

But this should also be true:  if neither HA nor BU are processed, mobile
node can still communicate with everyone.

Only, the connections will break if MN moves so that IP address changes.

So the worst case appears to be like with normal IPv6.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 15:08:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04183
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 15:08:17 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13716;
	Wed, 17 Oct 2001 12:07:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26787;
	Wed, 17 Oct 2001 12:07:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HJ6ZOI009206
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:06:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HJ6ZLh009205
	for mobile-ip-dist; Wed, 17 Oct 2001 12:06:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HJ6WOI009198
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:06:32 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06522
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:06:34 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15043
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:27:54 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9HJ6UW19076
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:06:30 +0300
Date: Wed, 17 Oct 2001 22:06:30 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
 for MIP v6
In-Reply-To: <15309.52102.939120.538717@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.33.0110172200080.19013-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 17 Oct 2001, Michael Thomas wrote:
> Pekka Savola writes:
>  > But the _real problem_, one could say caused by MIPv6, is that all nodes
>  > (at least all mobile nodes) _must_ have this Routing Header processing
>  > enabled.  One could say MIPv6, as defined, may open every mobile node for
>  > abuse.
>  > 
>  > If there was no MIPv6, there would be no strong need to be able to process 
>  > routing headers in hosts, only a few, possibly hand-picked, routers.  The 
>  > risks would be manageable.
> 
>    Couldn't there be different requirements for hosts
>    vs. routers? Ie, a node MUST process a packet with
>    a routing header, but MAY drop packets for which the
>    next destination address is not a valid destination
>    address for the host?
> 
>    Ie, the host will forward to its stack, but not
>    out another interface? This seems pretty consistant
>    with the definition of hosts and routers.

Yes, this is one approach (alternative would be to define "Type-2"  
routing header, so RH's used would be distinguishable in the network.  
This has some significant benefits wrt. packet filtering) I'm suggesting
in draft-savola-ipv6-rh-ha-security-00.txt, to be exact:

--8<--
   If a node would have to process the Routing Header (that is,
   destination address equals the node and segments left > 0), it SHOULD
   check whether segments left equals 1, and if both the current
   destination address and to-be-swapped destination address in the
   Routing Header are both assigned to the same interface of the node
   and are both of the same zone [ADDRSCOPE], the Routing Header is here
   referred to as "Interface-local Routing Header".

   On Routers, further processing of Routing Headers SHOULD be
   configurable and SHOULD be enabled by default.

   On Hosts, further processing of Routing Headers MAY be configurable
   and MUST be disabled by default.

   Regardless of the general Routing Header processing setting, all
   nodes SHOULD still process "Interface-local" Routing Headers.
   Disabling this exception MAY also be configurable.
--8<--

I was pretty conserative with SHOULD/MUST, could have been stricter.

Please also see the security implication of this "interface-local" 
property:

--8<--
   One should note that note that "Interface-local" property of Routing
   Headers is important to be, indeed interface-specific, not node-
   specific.  Consider a node with two interfaces, one public, and one
   completely private.  Even if a private service would be bound to the
   private interface only, one should not be able to use this private
   service from anywhere in the Internet.

   Even the interface-locality is not bulletproof, as some addresses
   assigned to the interface may be more private and public than others;
   at least this way the potential harm can be minimized.

   The same zone requirement is also important (how this is observed is
   implementation dependent; the check doesn't need to be explicit in
   Routing Header processing) so one cannot reach e.g. link- or site-
   local addresses through Internet.

   More fine-grained control of the two addresses could be obtained via
   access lists if they support Routing Header processing.
--8<--

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 15:13:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04383
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 15:13:47 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23308;
	Wed, 17 Oct 2001 13:12:36 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28643;
	Wed, 17 Oct 2001 12:12:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HJBkOI009308
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:11:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HJBkQG009307
	for mobile-ip-dist; Wed, 17 Oct 2001 12:11:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HJBgOI009300
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:11:42 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28270
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 12:11:44 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22277
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:11:24 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9HJBgr19129
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:11:42 +0300
Date: Wed, 17 Oct 2001 22:11:42 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Comments on security requirements draft
In-Reply-To: <3BCD9F0C.20C2EECB@iprg.nokia.com>
Message-ID: <Pine.LNX.4.33.0110172206490.19013-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 17 Oct 2001, Charlie Perkins wrote:
> Some clarifications/comments below...

Thanks.  We seem to be very much in agreement.  One comment below.

> > We've seen previously that this may lead to "hmm.. we're just testing now,
> > and there isn't so much harm to it.. I'll just ignore that point of the
> > spec, and accept unauthenticated BU's for now.. after all, we have
> > deadlines to meet, and we'd like to get MIPv6 out very soon for the good
> > of the everyone.  We can worry about BU's later."
> 
[snip]
>
> What I had expected was that after the base protocol was done,
> there would be room for people to develop follow-on security
> protocols to address the scalability issues.  Plus there would be
> a lot of usefulness for initial deployments that would work even
> suffering the disadvantages of triangle routing -- witness Mobile IPv4.
> The additional security protocols for key exchange would then
> look like scalability upgrades, and over time more and more of
> the original correspondent nodes would have gotten upgraded.

I see a potential problem with this approach: if, when developing these
follow-on security protocols, we found out we have to change X, Y and Z in
the MIPv6 standard (which may or may not be doable backwards-compatibly),
we'd be "locked" to the design we chose earlier, or have to develop
MIPv6.2.

If more or less significant changes will be required, in the end, it
should be easier to do them now.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 16:06:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06217
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 16:06:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05052;
	Wed, 17 Oct 2001 14:05:32 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20987;
	Wed, 17 Oct 2001 13:05:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HK3iOI009489
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:03:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HK3ipp009488
	for mobile-ip-dist; Wed, 17 Oct 2001 13:03:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HK3eOI009481
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:03:40 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25097
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:03:37 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03160
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:03:22 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9HK3Zk01199
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:03:35 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA29518
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:03:35 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9HK3YD68936
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:03:34 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110172003.f9HK3YD68936@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Wed, 10 Oct 2001 11:46:52 +1000.
             <4B6BC00CD15FD2119E5F0008C7A419A51308ED26@eaubrnt018.epa.ericsson.se> 
Date: Wed, 17 Oct 2001 22:03:34 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   > Getting a new extension header is hardly a minor change. It needs
   > _every_ IPv6 forwarding engine to be changed, thus affecting the
   > ipv6 WG's scope. 

   	=> Huh ?? Are you saying routers have to be upgraded
   	every time we have a new DST-option addressed to the
   	end host ?
   	Thats news to me.
   
=> some remarks:
 - the change is a new final header, not an extension one (ie it will
   be always the last one) nor a destination option
 - no IPv6 forwarding engine needs to be changed, the only header
   processings are for the IPv6 header and for an optional hop-by-hop
   header (so it must be just after the IPv6 header and unique).
   The forwarding engine verifies the next header field is not zero,
   it should not check if it knows it (i.e. you have not to upgrade
   your router in order to support SCTP for instance).

   > IMHO, people suggesting such a change should first
   > go to ipv6 WG to get their opinion on the issue. For the record,
   > I believe Francis bravely once already tried this - and, regrettably,
   > got rejected.
   > 
   	=> Francis can speak for himself but I've *never* seen a
   	proposal for this in IPng. Probably for a good reason. 
   	Francis did propose rearranging all ext headers in general
   	and that was not agreed on for reasons that have nothing to
   	do with routers.
   
=> my purpose was to clarify the different destination option header
stuff and to manage them in the advanced API. The conclusion was
the advanced API has to be fixed and RFC 2460 is near perfect (:-).
As some clarifications seem to be still useful my plan is to publish
a -01 version including the meeting decision.
BTW a consequence of my first remark is that we don't need to go
to the IPv6 WG in order to get the next header value.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 16:17:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06409
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 16:17:44 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14982;
	Wed, 17 Oct 2001 14:17:16 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23692;
	Wed, 17 Oct 2001 13:17:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKGSOI009635
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:16:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HKGRx0009634
	for mobile-ip-dist; Wed, 17 Oct 2001 13:16:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKGOOI009627
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:16:24 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27920
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:16:14 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23075
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:16:19 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9HKGIU19533
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:16:18 +0300
Date: Wed, 17 Oct 2001 23:16:18 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-Reply-To: <200110172003.f9HK3YD68936@givry.rennes.enst-bretagne.fr>
Message-ID: <Pine.LNX.4.33.0110172312020.19507-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 17 Oct 2001, Francis Dupont wrote:
>    > Getting a new extension header is hardly a minor change. It needs
>    > _every_ IPv6 forwarding engine to be changed, thus affecting the
>    > ipv6 WG's scope. 
> 
>    	=> Huh ?? Are you saying routers have to be upgraded
>    	every time we have a new DST-option addressed to the
>    	end host ?
>    	Thats news to me.
>    
> => some remarks:
>  - the change is a new final header, not an extension one (ie it will
>    be always the last one) nor a destination option
>  - no IPv6 forwarding engine needs to be changed, the only header
>    processings are for the IPv6 header and for an optional hop-by-hop
>    header (so it must be just after the IPv6 header and unique).
>    The forwarding engine verifies the next header field is not zero,
>    it should not check if it knows it (i.e. you have not to upgrade
>    your router in order to support SCTP for instance).

True.

But the sending node will have to know that the destination will support 
this new header, else the packet is discarded.

Especially if destination is CN, this may or may not be possible.

Yesterday, I posted a related note to on ipng list with subject:
"Extension Header Capability Discovery needed?", which may be of interest.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 16:17:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06421
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 16:17:54 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14398;
	Wed, 17 Oct 2001 14:16:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23508;
	Wed, 17 Oct 2001 13:16:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKEiOI009615
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:14:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HKEi4w009614
	for mobile-ip-dist; Wed, 17 Oct 2001 13:14:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKEeOI009607
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:14:40 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27550
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:14:37 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25686
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:14:37 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA05656
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:14:33 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9HKEXQ19751
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:14:33 -0700
X-mProtect:  Wed, 17 Oct 2001 13:14:33 -0700 Nokia Silicon Valley Messaging Protection
Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdnlwVTR; Wed, 17 Oct 2001 13:14:31 PDT
Message-ID: <3BCDE6A7.EB5D848A@Kniveton.com>
Date: Wed, 17 Oct 2001 13:14:31 -0700
From: "T.J. Kniveton" <TJ@Kniveton.com>
Organization: NOKIA Research
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Comments on security requirements draft
References: <697DAA22C5004B4596E033803A7CEF444CCE9B@daebe007.NOE.Nokia.com> <15309.50830.584253.146235@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
>    Uh, I'm not the one who's trying to play the
>    spin control game here. I'm saying that the
>    current requirements draft is fine as-is in
>    this respect. If you have a problem with this,
>    you should take it up with the person who
>    insists on obscuring the fact that the current
>    MIPv6 draft isn't problematic on the BU
>    authentication/authorization front. I'm not
>    the only one who has commented on this.
> 
>    And I've already sent comments on the draft
>    about two weeks ago, for which the authors
>    have not replied.
> 
>             Mike

Is there anyone who disagrees with this self-evident fact that there are
problems and challenges with doing authentication and authorization in a
mobile environment? I haven't heard any argument on this point. No one
is trying to "obscure" this facet of our engineering work or put spin
control on it.

There seems to be a question on whether we should try and solve every
problem associated with strong, scalable encryption technology, key
distribution, IPsec, etc., and create a perfect, rock-solid, ideal
system which solves all of the problems the Security-oriented engineers
have been working on for years (or paddle toward that end indefinitely),
or we should instead get a good solution that works, is implementable
and deployable, and doesn't screw up other parts of IPv6. The consensus
is NO, we do not want to do the former, we want to do the latter, as is
shown by the eagerness of various members in the group who have done a
lot of constructive work to reach a compromise solution that is as good
as possible using current security technology and practices (and a
couple of novel ones). And by the way, let's do it some time this
decade.

Solving all the key distribution, trust, and strong encryption problems
is a really interesting question, and I will personally dance around the
room and host a jubilant party once they are solved. So let's bring
these research tasks to the IRTF, or somewhere there is  some chance
they could get properly addressed without derailing their current work.

-TJ

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 16:18:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06473
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 16:18:57 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15572;
	Wed, 17 Oct 2001 14:17:51 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23899;
	Wed, 17 Oct 2001 13:17:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKGsOI009645
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:16:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HKGsud009644
	for mobile-ip-dist; Wed, 17 Oct 2001 13:16:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKGmOI009637
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:16:48 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14627
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:16:50 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14313
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:16:30 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9HKGkk02636
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:16:47 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA29728
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:16:47 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9HKGlD69022
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:16:47 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110172016.f9HKGlD69022@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Wed, 10 Oct 2001 06:17:17 PDT.
             <3BC44A5D.3AEC0166@iprg.nokia.com> 
Date: Wed, 17 Oct 2001 22:16:47 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   I believe his proposal also included a "nice-to-have" suggestion to
   introduce a new header type for one of the options currently carried
   in destination headers.
   
=> my idea was to clean up the 3 (at least :-) different positions
for destionation option headers. As the last (aka note 3) one is used
only for BU, BA and BR I proposed to get a new type for it.
But the proposal was for an extension header so it didn't address
the IPsec selector problem: to solve this issue the header must be
a final one, i.e. piggybacking must be killed.

BTW I have a question about Binding Requests: they have no strong
security requirements but to deal with them as BUs and BAs seems
to be simpler and without overhead (arguments: to put them in
the last destionation option header saves nothing (without piggybacking
consideration) and SAs should be there if BRs can be sent).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 16:33:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06779
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 16:33:01 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27814;
	Wed, 17 Oct 2001 14:32:20 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28686;
	Wed, 17 Oct 2001 13:32:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKVTOI009963
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:31:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HKVTlt009962
	for mobile-ip-dist; Wed, 17 Oct 2001 13:31:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKVQOI009955
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:31:26 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28389
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:31:28 -0700 (PDT)
Received: from smtp7.andrew.cmu.edu (SMTP7.ANDREW.CMU.EDU [128.2.10.87])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01300
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:31:27 -0700 (PDT)
Received: from UNIX4.ANDREW.CMU.EDU (UNIX4.ANDREW.CMU.EDU [128.2.11.204])
	(user=asamar mech=KERBEROS_V4 (0 bits))
	by smtp7.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f9HKVOUi019049;
	Wed, 17 Oct 2001 16:31:24 -0400
Date: Wed, 17 Oct 2001 16:31:25 -0400 (EDT)
From: Asad Samar <asamar@andrew.cmu.edu>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Humayun Latif <hlatif@andrew.cmu.edu>, Brenda Liu <bhliu@andrew.cmu.edu>,
        Asad Samar <asamar@andrew.cmu.edu>
Subject: [mobile-ip] DDOS attacks and mobile-ip
Message-ID: <Pine.GSO.4.33L-022.0110171622240.7393-100000@unix4.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi All

We are a group of students at the Carnegie Mellon University and are
thinking about modeling DDOS (distributed denial of service) attacks in
the mobile environment, specifically in the context of mobile IP for our
semster project.

The main goals would be to:

--get a feel of how launching a DDOS attack in this environment (based on
mobile-ip) is easier/more difficult than a traditional static network and
why?

--are there new ways of launching/preventing DDOS attacks in such an
environment which havent been explored in the static scope.

--can we propose some changes in the protocol itself or maybe in the
higher layers that would prevent against such attacks

We just joined the mailing list but seems like there is a lot of activity
these days on security issues in the protocol...that might help us.

Is there anyone working on the DDOS specific issues?  Something really
useful for us would be a way to setup some sort of a testbed where we can
possibly emulate such an attack. If you have any
code/development-kits/pointers on previous work/testbed facilities that we
can use in this respect, that will be very useful.

We will greatly appreciate any hints.
Thanks
Asad~Brenda~Humayun



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 16:36:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06832
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 16:36:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00111;
	Wed, 17 Oct 2001 14:34:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29435;
	Wed, 17 Oct 2001 13:35:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKYEOI010011
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:34:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HKYD2n010008
	for mobile-ip-dist; Wed, 17 Oct 2001 13:34:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKYAOI010000
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:34:10 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17033
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:34:13 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07106
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:34:11 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA07268
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:34:11 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9HKYAq21292
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:34:10 -0700
X-mProtect:  Wed, 17 Oct 2001 13:34:10 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpd7BZXnS; Wed, 17 Oct 2001 13:34:08 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA21399 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:34:09 -0700 (PDT)
Message-ID: <3BCDEB40.132D3888@iprg.nokia.com>
Date: Wed, 17 Oct 2001 13:34:08 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <200110172003.f9HK3YD68936@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Francis Dupont wrote:
> 
>    > Getting a new extension header is hardly a minor change. It needs
>    > _every_ IPv6 forwarding engine to be changed, thus affecting the
>    > ipv6 WG's scope.
> 
>         => Huh ?? Are you saying routers have to be upgraded
>         every time we have a new DST-option addressed to the
>         end host ?
>         Thats news to me.

I was too categorical with this remark, the issue was discussed on
the list and a more refined view, I guess, emerged. I refered to headers,
in general, not options of current destination header type.

> => some remarks:
>  - the change is a new final header, not an extension one (ie it will
>    be always the last one) nor a destination option
>  - no IPv6 forwarding engine needs to be changed, the only header
>    processings are for the IPv6 header and for an optional hop-by-hop
>    header (so it must be just after the IPv6 header and unique).
>    The forwarding engine verifies the next header field is not zero,
>    it should not check if it knows it (i.e. you have not to upgrade
>    your router in order to support SCTP for instance).
> 
>    > IMHO, people suggesting such a change should first
>    > go to ipv6 WG to get their opinion on the issue. For the record,
>    > I believe Francis bravely once already tried this - and, regrettably,
>    > got rejected.
>    >
>         => Francis can speak for himself but I've *never* seen a
>         proposal for this in IPng. Probably for a good reason.
>         Francis did propose rearranging all ext headers in general
>         and that was not agreed on for reasons that have nothing to
>         do with routers.
> 
> => my purpose was to clarify the different destination option header
> stuff and to manage them in the advanced API. The conclusion was
> the advanced API has to be fixed and RFC 2460 is near perfect (:-).

Sorry about being imprecise on the proposal, I attempted to refer only
to the discussion after your proposal where having new header types was
discussed, I remember (maybe incorrectly) Deering's comments on
not hearing good reasons now.

> As some clarifications seem to be still useful my plan is to publish
> a -01 version including the meeting decision.
> BTW a consequence of my first remark is that we don't need to go
> to the IPv6 WG in order to get the next header value.

Hopefully this is the case. I would like just to remark it does affect
some nodes and having a conservative amount of change could be reasonable
when weighing alternatives. Even though new header would be mandatory,
and since mobility standardization lags after other IPv6, there will
be boxes not immediately knowing the new headers.

> Regards
> 
> Francis.Dupont@enst-bretagne.fr

BR,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 16:58:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07322
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 16:58:50 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19391;
	Wed, 17 Oct 2001 14:58:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06128;
	Wed, 17 Oct 2001 13:58:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKvTOI010219
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:57:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HKvT9c010218
	for mobile-ip-dist; Wed, 17 Oct 2001 13:57:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HKvQOI010211
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:57:26 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25285
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:57:29 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15776
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 13:57:28 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA16338
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 15:57:28 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 17 Oct 2001 15:50:32 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L5S6D>; Wed, 17 Oct 2001 15:56:41 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E6FF4C4@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 17 Oct 2001 15:56:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1574E.334D15C0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1574E.334D15C0
Content-Type: text/plain;
	charset="iso-8859-1"

Francis,

Do you believe there might ever be a need to send a binding update in the
same packet as an RSVP or something similar message?


-----Original Message-----
From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
Sent: Wednesday, October 17, 2001 3:17 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion


   I believe his proposal also included a "nice-to-have" suggestion to
   introduce a new header type for one of the options currently carried
   in destination headers.
   
=> my idea was to clean up the 3 (at least :-) different positions
for destionation option headers. As the last (aka note 3) one is used
only for BU, BA and BR I proposed to get a new type for it.
But the proposal was for an extension header so it didn't address
the IPsec selector problem: to solve this issue the header must be
a final one, i.e. piggybacking must be killed.

BTW I have a question about Binding Requests: they have no strong
security requirements but to deal with them as BUs and BAs seems
to be simpler and without overhead (arguments: to put them in
the last destionation option header saves nothing (without piggybacking
consideration) and SAs should be there if BRs can be sent).

Regards

Francis.Dupont@enst-bretagne.fr

------_=_NextPart_001_01C1574E.334D15C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Francis,</FONT>
</P>

<P><FONT SIZE=3D2>Do you believe there might ever be a need to send a =
binding update in the same packet as an RSVP or something similar =
message?</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Francis Dupont [<A =
HREF=3D"mailto:Francis.Dupont@enst-bretagne.fr">mailto:Francis.Dupont@en=
st-bretagne.fr</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, October 17, 2001 3:17 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [mobile-ip] MIPv6 - Focus of the =
security discussion</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp; I believe his proposal also included a =
&quot;nice-to-have&quot; suggestion to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; introduce a new header type for one of =
the options currently carried</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; in destination headers.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>=3D&gt; my idea was to clean up the 3 (at least :-) =
different positions</FONT>
<BR><FONT SIZE=3D2>for destionation option headers. As the last (aka =
note 3) one is used</FONT>
<BR><FONT SIZE=3D2>only for BU, BA and BR I proposed to get a new type =
for it.</FONT>
<BR><FONT SIZE=3D2>But the proposal was for an extension header so it =
didn't address</FONT>
<BR><FONT SIZE=3D2>the IPsec selector problem: to solve this issue the =
header must be</FONT>
<BR><FONT SIZE=3D2>a final one, i.e. piggybacking must be =
killed.</FONT>
</P>

<P><FONT SIZE=3D2>BTW I have a question about Binding Requests: they =
have no strong</FONT>
<BR><FONT SIZE=3D2>security requirements but to deal with them as BUs =
and BAs seems</FONT>
<BR><FONT SIZE=3D2>to be simpler and without overhead (arguments: to =
put them in</FONT>
<BR><FONT SIZE=3D2>the last destionation option header saves nothing =
(without piggybacking</FONT>
<BR><FONT SIZE=3D2>consideration) and SAs should be there if BRs can be =
sent).</FONT>
</P>

<P><FONT SIZE=3D2>Regards</FONT>
</P>

<P><FONT SIZE=3D2>Francis.Dupont@enst-bretagne.fr</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1574E.334D15C0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 17:41:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07958
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 17:41:18 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22416;
	Wed, 17 Oct 2001 14:41:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06787;
	Wed, 17 Oct 2001 14:40:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HLdpOI010382
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:39:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HLdpR2010381
	for mobile-ip-dist; Wed, 17 Oct 2001 14:39:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HLdmOI010374
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:39:48 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20280
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:39:43 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09813
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:39:49 -0700 (PDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HLdqQ13316
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 16:39:52 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56a7f12f16ac12f256126@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Wed, 17 Oct 2001 16:39:48 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 17 Oct 2001 16:40:01 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Comments on security requirements draft
Date: Wed, 17 Oct 2001 16:39:47 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCEA0@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Comments on security requirements draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFXNWD60OZbKcMlEdWxLwAIx6TWeAAHtOlw
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 17 Oct 2001 21:40:01.0060 (UTC) FILETIME=[4640B640:01C15754]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9HLdmOI010375
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Michael Thomas [mat@cisco.com] Wrote:
>Patil Basavaraj (NET/Dallas) writes:
> > 
> > I believe we are working on engineering (iEtf) a solution to the
> > problem. "Spin control" (at least the way I understand it) is not
> > something that this WG should be spending cycles on. Please do not
> > (mis)read someones valid comments as being anything else. Lets keep
> > the discussion on finding a solution to the BU problem. Everyone is
> > entitled to their opinions, but this discussion list is for debating
> > the technical aspects of Mobile IP.
>
>   Uh, I'm not the one who's trying to play the
>   spin control game here. I'm saying that the

Sorry about that. 

>   current requirements draft is fine as-is in
>   this respect. If you have a problem with this,
>   you should take it up with the person who
>   insists on obscuring the fact that the current
>   MIPv6 draft isn't problematic on the BU
>   authentication/authorization front. I'm not 
>   the only one who has commented on this.
>
>   And I've already sent comments on the draft
>   about two weeks ago, for which the authors
>   have not replied.
>

Will try to get to some responses to your comments soon. 

>	    Mike
>

-Basavaraj


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 17:44:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07999
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 17:44:28 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27674;
	Wed, 17 Oct 2001 15:43:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07729;
	Wed, 17 Oct 2001 14:43:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HLgbOI010451
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:42:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HLgbWp010450
	for mobile-ip-dist; Wed, 17 Oct 2001 14:42:37 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HLgXOI010443
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:42:33 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17740
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:42:35 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA19312
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 16:03:51 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA13192
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:42:30 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9HLgU621423
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:42:30 -0700
X-mProtect:  Wed, 17 Oct 2001 14:42:30 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdfKUptg; Wed, 17 Oct 2001 14:42:29 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA21466 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 14:42:29 -0700 (PDT)
Message-ID: <3BCDFB45.A42BD2D@iprg.nokia.com>
Date: Wed, 17 Oct 2001 14:42:29 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <200110172016.f9HKGlD69022@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Francis Dupont wrote:
> 
>    I believe his proposal also included a "nice-to-have" suggestion to
>    introduce a new header type for one of the options currently carried
>    in destination headers.
> 
> => my idea was to clean up the 3 (at least :-) different positions
> for destionation option headers. As the last (aka note 3) one is used
> only for BU, BA and BR I proposed to get a new type for it.
> But the proposal was for an extension header so it didn't address
> the IPsec selector problem: to solve this issue the header must be
> a final one, i.e. piggybacking must be killed.

I would like to ask a clarification: What happens if the sender omits
the upper layer (this also makes the packet non-piggybacked), doesn't
this expose any header to potentially be the last one? Wouldn't this
mean that with a new header type for one or more of the current destination
options one could introduce a policy of protecting exactly this signaling?
But, as said, using a well-known UDP port has been suggested as an
alternative.

Also on piggybacking, what would be the consequence, if, say, piggybacking
is not killed, but only disabled at sender when using IPsec?

> BTW I have a question about Binding Requests: they have no strong
> security requirements but to deal with them as BUs and BAs seems
> to be simpler and without overhead (arguments: to put them in
> the last destionation option header saves nothing (without piggybacking
> consideration) and SAs should be there if BRs can be sent).

Given the recent interest on DOS attacks, wouldn't insecure BRs also
help mounting these, even though BR has weaker requirements? Hence,
if they can be dealt the same way as BUs and BAs, wouldn't this be ok?

> Regards
> 
> Francis.Dupont@enst-bretagne.fr

BR,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 18:01:27 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08246
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 18:01:26 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12286;
	Wed, 17 Oct 2001 16:01:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12696;
	Wed, 17 Oct 2001 15:01:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HM0EOI010647
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 15:00:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HM0ExI010646
	for mobile-ip-dist; Wed, 17 Oct 2001 15:00:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HM0AOI010639
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 15:00:10 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22084
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 15:00:12 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00625
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 16:21:00 -0600 (MDT)
Received: from auds951.usa.alcatel.com ([143.209.238.80])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA12804
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 16:59:39 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9HLxcO14562
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 16:59:38 -0500 (CDT)
Message-ID: <3BCDEFEB.2DB2F4B8@alcatel.com>
Date: Wed, 17 Oct 2001 16:54:03 -0400
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110162119420.10452-100000@netcore.fi> <3BCC83D7.515CBB0@sun.com> <3BCC9963.E5623AB2@iprg.nokia.com> <3BCCA025.E02CD109@alcatel.com> <3BCCA1EA.9A52A94B@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Charlie,
  Thanks for your reply.
Maybe 6.4 is also OK but to be on the safe side I still favor 6.2. The advantage is, then we can count on any future
breakthrough on IP security to apply on MIPv6 as well, e.g. an update of RFC 2401 will one day come out and solve all
the so-called attacks.

  Looking forward to your reply to Arkko's draft.

Regards,

Charlie Perkins wrote:

> Hello Behcet,
>
> I didn't yet get around to transcribing my comments on Jari's
> draft, but if I may offer an incomplete opinion I think it is a
> fine piece of work.  I would favor the approach outlined
> in section 6.4, with the proviso that:
> - If IPsec is agreeably configured to authenticate
>    Binding Update, it can be used instead of the BU
>    authentication data option.  In other words, sometimes
>    a Binding Update could be authenticated by a method
>    that depends on some future IPsec mechanism, instead
>    of requiring the authentication data suboption to be present
>    anyway even if IPsec were already somehow enabled to
>    to do the job.
>
> But as I said this is an incompletely formed opinion, and
> I have to finish studying the document to figure it out more.
> Plus, I definitely don't intend to say that we have to figure
> out how to do all the IPsec stuff right now.
>
> Regards,
> Charlie P.
>
> Behcet Sarikaya wrote:
>
> > Hi Charlie,
> >   You seem to favor the solution 6.1 in Arkko's draft?
> > I kind of like 6.2 as well, it is also simple. Maybe problem with present implementations, but correcting a design
> > flaw early is better, IMHO.
> >   Appreciate if you can clarify.
> > Regards,
> >
> > Charlie Perkins wrote:
> >

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 21:50:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11723
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 21:50:57 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09779;
	Wed, 17 Oct 2001 18:49:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27219;
	Wed, 17 Oct 2001 18:49:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I1mVOI011035
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:48:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I1mVXq011034
	for mobile-ip-dist; Wed, 17 Oct 2001 18:48:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I1mROI011027
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:48:28 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25201
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:48:30 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06248
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:48:28 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA29958
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:47:18 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA17024
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:48:26 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXP3ZL>; Thu, 18 Oct 2001 11:48:25 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED89@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] WG Last Call on Threat Model and Security Require
	ments for MIP v6
Date: Thu, 18 Oct 2001 11:48:24 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15776.F923E080"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15776.F923E080
Content-Type: text/plain

> Pekka Savola writes:
>  > But the _real problem_, one could say caused by MIPv6, is that all
> nodes
>  > (at least all mobile nodes) _must_ have this Routing Header processing
>  > enabled.  One could say MIPv6, as defined, may open every mobile node
> for
>  > abuse.
>  > 
>  > If there was no MIPv6, there would be no strong need to be able to
> process 
>  > routing headers in hosts, only a few, possibly hand-picked, routers.
> The 
>  > risks would be manageable.
> 
>    Couldn't there be different requirements for hosts
>    vs. routers? Ie, a node MUST process a packet with
>    a routing header, but MAY drop packets for which the
>    next destination address is not a valid destination
>    address for the host?
> 
>    Ie, the host will forward to its stack, but not
>    out another interface? This seems pretty consistant
>    with the definition of hosts and routers.
> 
	=> Exactly ! That's why I don't see the problem here. 
	In fact, this is what was done for the cellular host draft
	and it certainly does not break RFC 2460. It's an internal
	policy decision for those IPv6 nodes that do not want
	to act as reflectors. 

> 	   Mike
> 
	Hesham

------_=_NextPart_001_01C15776.F923E080
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">Pekka Savola writes:</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; But the _real problem_, one could say caused by MIPv6, is that all nodes</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; (at least all mobile nodes) _must_ have this Routing Header processing</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; enabled.&nbsp; One could say MIPv6, as defined, may open every mobile node for</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; abuse.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; If there was no MIPv6, there would be no strong need to be able to process </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; routing headers in hosts, only a few, possibly hand-picked, routers.&nbsp; The </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; risks would be manageable.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; Couldn't there be different requirements for hosts</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; vs. routers? Ie, a node MUST process a packet with</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; a routing header, but MAY drop packets for which the</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; next destination address is not a valid destination</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; address for the host?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; Ie, the host will forward to its stack, but not</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; out another interface? This seems pretty consistant</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; with the definition of hosts and routers.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Exactly ! That's why I don't see the problem here. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">In fact, this is what was done for the cellular host draft</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">and it certainly does not break RFC 2460. It's an internal</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">policy decision for those IPv6 nodes that do not want</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">to act as reflectors. </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; Mike</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15776.F923E080--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 21:55:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11766
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 21:55:30 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28016;
	Wed, 17 Oct 2001 19:54:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28026;
	Wed, 17 Oct 2001 18:55:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I1sAOI011151
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:54:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I1sA56011150
	for mobile-ip-dist; Wed, 17 Oct 2001 18:54:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I1s6OI011143
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:54:06 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26122
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:54:09 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29205
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 18:54:08 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA00499
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:52:58 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA18102
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:54:06 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXP39T>; Thu, 18 Oct 2001 11:54:05 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED8A@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion 
Date: Thu, 18 Oct 2001 11:54:02 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15777.C30F7760"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15777.C30F7760
Content-Type: text/plain

	Pekka, 

> >    > Getting a new extension header is hardly a minor change. It needs
> >    > _every_ IPv6 forwarding engine to be changed, thus affecting the
> >    > ipv6 WG's scope. 
> > 
> >    	=> Huh ?? Are you saying routers have to be upgraded
> >    	every time we have a new DST-option addressed to the
> >    	end host ?
> >    	Thats news to me.
> >    
> > => some remarks:
> >  - the change is a new final header, not an extension one (ie it will
> >    be always the last one) nor a destination option
> >  - no IPv6 forwarding engine needs to be changed, the only header
> >    processings are for the IPv6 header and for an optional hop-by-hop
> >    header (so it must be just after the IPv6 header and unique).
> >    The forwarding engine verifies the next header field is not zero,
> >    it should not check if it knows it (i.e. you have not to upgrade
> >    your router in order to support SCTP for instance).
> 
> True.
> 
> But the sending node will have to know that the destination will support 
> this new header, else the packet is discarded.
> 
> Especially if destination is CN, this may or may not be possible.
> 
	=> Agreed. Hence the need for a standard ! 
	The Home Address option MUST be supported by 
	all IPv6 nodes. This solves your concerns. 
	The BU option and potentially the new ext header
	SHOULD be supported .... voila. 

> Yesterday, I posted a related note to on ipng list with subject:
> "Extension Header Capability Discovery needed?", which may be of interest.
> 
	=> In this case this adds another unnecessary round trip
	that is already made redundant by the KEYWORDS. 
	But perhaps this proposal can be useful for other 
	applications of ext headers.

	Hesham


------_=_NextPart_001_01C15777.C30F7760
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion </TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Pekka, </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; &gt; Getting a new extension header is hardly a minor change. It needs</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; &gt; _every_ IPv6 forwarding engine to be changed, thus affecting the</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; &gt; ipv6 WG's scope. </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; =&gt; Huh ?? Are you saying routers have to be upgraded</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; every time we have a new DST-option addressed to the</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; end host ?</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; Thats news to me.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; =&gt; some remarks:</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp; - the change is a new final header, not an extension one (ie it will</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; be always the last one) nor a destination option</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp; - no IPv6 forwarding engine needs to be changed, the only header</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; processings are for the IPv6 header and for an optional hop-by-hop</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; header (so it must be just after the IPv6 header and unique).</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; The forwarding engine verifies the next header field is not zero,</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; it should not check if it knows it (i.e. you have not to upgrade</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp; your router in order to support SCTP for instance).</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">True.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">But the sending node will have to know that the destination will support </FONT>
<BR><FONT SIZE=2 FACE="Arial">this new header, else the packet is discarded.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Especially if destination is CN, this may or may not be possible.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Agreed. Hence the need for a standard ! </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The Home Address option MUST be supported by </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">all IPv6 nodes. This solves your concerns. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The BU option and potentially the new ext header</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">SHOULD be supported .... voila.</FONT> 
</P>

<P><FONT SIZE=2 FACE="Arial">Yesterday, I posted a related note to on ipng list with subject:</FONT>
<BR><FONT SIZE=2 FACE="Arial">&quot;Extension Header Capability Discovery needed?&quot;, which may be of interest.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; In this case this adds another unnecessary round trip</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">that is already made redundant by the KEYWORDS. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">But perhaps this proposal can be useful for other </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">applications of ext headers.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15777.C30F7760--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 22:10:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11865
	for <mobileip-archive@lists.ietf.org>; Wed, 17 Oct 2001 22:10:35 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14157;
	Wed, 17 Oct 2001 19:10:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29969;
	Wed, 17 Oct 2001 19:10:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I29GOI011305
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 19:09:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I29GgV011304
	for mobile-ip-dist; Wed, 17 Oct 2001 19:09:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I29DOI011294
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 19:09:13 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29886
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 19:09:08 -0700 (PDT)
Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03979
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:08:54 -0600 (MDT)
Received: from cc.hut.fi (root@gamma.hut.fi [130.233.228.23])
	by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id FAA59483;
	Thu, 18 Oct 2001 05:09:12 +0300 (EEST)
Message-ID: <3BCE3D2D.969859DF@cc.hut.fi>
Date: Thu, 18 Oct 2001 05:23:41 +0300
From: Tom =?iso-8859-1?Q?Weckstr=F6m?= <tweckstr@cc.hut.fi>
Organization: HUT/TKK
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: fi,sv,de
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Mobile Nodes for Testing
References: <A1170612471BD21185B90008C7FA0A0D01F1FA7E@idcpa4.pa.interdigital.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello.

You should try Lifix Go! Mobile Node on Windows platforms. Lifix Go!
supports Win 2000 and Win 98/ME/XP versions are available as betas.
Naturally, Linux is supported as well. :-) Standards compliance has been
tested against Cisco's IOS and Dynamics - HUT Mobile IP. More
information is available at http://www.lifix.fi

Regards, Tom



"Shahrier, Sharif M." wrote:
> 
> I am also interested in this, with respect to Visual C running on Windows
> 2000. Thanks.
> 
> -Sharif.
> 
> -----Original Message-----
> From: Kishore Asarpota [mailto:kishore@xedia.com]
> Sent: Tuesday, October 16, 2001 11:05 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Mobile Nodes for Testing
> 
> Hi,
> 
> Is there a Mobile Node product out there that I can use for
> testing my HA and FA routers. I am just curious to find out
> what is everyone using as their MN for testing. I have the Linux
> version running, is there anything else.
> 
> thx, kishore

-- 
        Tom Weckström           tweckstr@cc.hut.fi


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 23:10:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13348
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 23:10:56 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04587;
	Wed, 17 Oct 2001 21:10:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA24881;
	Wed, 17 Oct 2001 20:10:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I39QOI011489
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:09:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I39QZI011488
	for mobile-ip-dist; Wed, 17 Oct 2001 20:09:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I39MOI011481
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:09:22 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26464
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:09:25 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22834
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:09:25 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA05630
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:09:24 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I39OV03023
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:09:24 -0700
X-mProtect:  Wed, 17 Oct 2001 20:09:24 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdFy7SxA; Wed, 17 Oct 2001 20:09:23 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id UAA21823 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:09:23 -0700 (PDT)
Message-ID: <3BCE47E3.A0DA7BEB@iprg.nokia.com>
Date: Wed, 17 Oct 2001 20:09:23 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED8A@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>      But the sending node will have to know that the destination will
>      support this new header, else the packet is discarded.
> 
>      Especially if destination is CN, this may or may not be possible.
> 
>      => Agreed. Hence the need for a standard !
>      The Home Address option MUST be supported by
>      all IPv6 nodes. This solves your concerns.
>      The BU option and potentially the new ext header
>      SHOULD be supported .... voila.

If both BU and the new header are optional, header type of BU
is recognized, that of the new header is not. Filtering forwarders
not knowing these options will possibly let the BU go through (knowing
at least the destination header type), but they do not know the new
header, most likely dropping it. This may be a problem.

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 23:18:26 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13414
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 23:18:26 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07219;
	Wed, 17 Oct 2001 21:18:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27350;
	Wed, 17 Oct 2001 20:18:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I3HYOI011600
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:17:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I3HXCn011599
	for mobile-ip-dist; Wed, 17 Oct 2001 20:17:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I3HUOI011592
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:17:30 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07747
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:17:26 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06893
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:17:12 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA07708
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:16:23 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA17168
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:17:30 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXPRFY>; Thu, 18 Oct 2001 13:17:28 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED8E@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 18 Oct 2001 13:17:27 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15783.6A057780"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15783.6A057780
Content-Type: text/plain


> >      But the sending node will have to know that the destination will
> >      support this new header, else the packet is discarded.
> > 
> >      Especially if destination is CN, this may or may not be possible.
> > 
> >      => Agreed. Hence the need for a standard !
> >      The Home Address option MUST be supported by
> >      all IPv6 nodes. This solves your concerns.
> >      The BU option and potentially the new ext header
> >      SHOULD be supported .... voila.
> 
> If both BU and the new header are optional, header type of BU
> is recognized, that of the new header is not. Filtering forwarders
> not knowing these options will possibly let the BU go through (knowing
> at least the destination header type), but they do not know the new
> header, most likely dropping it. This may be a problem.
> 
	=> The point raised by Pekka was reagarding the understanding 
	of headers e2e. How intemediate filters treat the headers is a
separate
	issue. However to answer your question, filters can typically 
	be configured to let / stop cetain ext headers from passing 
	through.
	I'm guessing that's what you mean by "filtering forwarders"
	or do you just mean "routers" ?
	If you mean routers, then I think it's quite clear now that
	they don't need to be aware of these new headers.

	Whether the new ext header is optional or not, has not
	been discussed. 

	Hesham

------_=_NextPart_001_01C15783.6A057780
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; But the sending node will have to know that the destination will</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support this new header, else the packet is discarded.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Especially if destination is CN, this may or may not be possible.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =&gt; Agreed. Hence the need for a standard !</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Home Address option MUST be supported by</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all IPv6 nodes. This solves your concerns.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The BU option and potentially the new ext header</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SHOULD be supported .... voila.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">If both BU and the new header are optional, header type of BU</FONT>
<BR><FONT SIZE=2 FACE="Arial">is recognized, that of the new header is not. Filtering forwarders</FONT>
<BR><FONT SIZE=2 FACE="Arial">not knowing these options will possibly let the BU go through (knowing</FONT>
<BR><FONT SIZE=2 FACE="Arial">at least the destination header type), but they do not know the new</FONT>
<BR><FONT SIZE=2 FACE="Arial">header, most likely dropping it. This may be a problem.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; The point raised by Pekka was reagarding the understanding </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">of headers e2e. How intemediate filters treat the headers is a separate</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">issue. However to answer your question, filters can typically </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">be configured to let / stop cetain ext headers from passing </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">through.</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I'm guessing that's what you mean by &quot;filtering forwarders&quot;</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">or do you just mean &quot;routers&quot; ?</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">If you mean routers, then I think it's quite clear now that</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">they don't need to be aware of these new headers.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Whether the new ext header is optional or not, has not</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">been discussed. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15783.6A057780--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 17 23:22:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13466
	for <mobileip-archive@odin.ietf.org>; Wed, 17 Oct 2001 23:22:48 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09359;
	Wed, 17 Oct 2001 21:22:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27916;
	Wed, 17 Oct 2001 20:22:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I3LkOI011713
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:21:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I3LkHP011712
	for mobile-ip-dist; Wed, 17 Oct 2001 20:21:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I3LhOI011705
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:21:43 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27817
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:21:46 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09950
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 20:21:44 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA08124
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:20:36 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA18068
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:21:43 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXPRJ2>; Thu, 18 Oct 2001 13:21:42 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED8F@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Comments on security requirements draft
Date: Thu, 18 Oct 2001 13:21:39 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15784.000C4BF0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15784.000C4BF0
Content-Type: text/plain

	TJ, 

> Is there anyone who disagrees with this self-evident fact that there are
> problems and challenges with doing authentication and authorization in a
> mobile environment? I haven't heard any argument on this point. No one
> is trying to "obscure" this facet of our engineering work or put spin
> control on it.
> 
> There seems to be a question on whether we should try and solve every
> problem associated with strong, scalable encryption technology, key
> distribution, IPsec, etc., and create a perfect, rock-solid, ideal
> system which solves all of the problems the Security-oriented engineers
> have been working on for years (or paddle toward that end indefinitely),
> or we should instead get a good solution that works, is implementable
> and deployable, and doesn't screw up other parts of IPv6. The consensus
> is NO, 
> 
	=> I appreciate all of the above, but please be very clear on 
	using the word "concensus". I don't recall one concensus call
	made by the chairs on this mailing list to decide what 
	needs to be done in terms of IPsec, probably for a very 
	wise reason. Now that we have a draft to base the discussion
	on, we can start that,  and hopefully the discussions 
	will result in some concensus call. 
	Until then one can not assume what the concensus is. 

	Hesham


------_=_NextPart_001_01C15784.000C4BF0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] Comments on security requirements draft</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">TJ, </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Is there anyone who disagrees with this self-evident fact that there are</FONT>
<BR><FONT SIZE=2 FACE="Arial">problems and challenges with doing authentication and authorization in a</FONT>
<BR><FONT SIZE=2 FACE="Arial">mobile environment? I haven't heard any argument on this point. No one</FONT>
<BR><FONT SIZE=2 FACE="Arial">is trying to &quot;obscure&quot; this facet of our engineering work or put spin</FONT>
<BR><FONT SIZE=2 FACE="Arial">control on it.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">There seems to be a question on whether we should try and solve every</FONT>
<BR><FONT SIZE=2 FACE="Arial">problem associated with strong, scalable encryption technology, key</FONT>
<BR><FONT SIZE=2 FACE="Arial">distribution, IPsec, etc., and create a perfect, rock-solid, ideal</FONT>
<BR><FONT SIZE=2 FACE="Arial">system which solves all of the problems the Security-oriented engineers</FONT>
<BR><FONT SIZE=2 FACE="Arial">have been working on for years (or paddle toward that end indefinitely),</FONT>
<BR><FONT SIZE=2 FACE="Arial">or we should instead get a good solution that works, is implementable</FONT>
<BR><FONT SIZE=2 FACE="Arial">and deployable, and doesn't screw up other parts of IPv6. The consensus</FONT>
<BR><FONT SIZE=2 FACE="Arial">is NO,</FONT> 
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; I appreciate all of the above, but please be very clear on </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">using the word &quot;concensus&quot;. I don't recall one concensus call</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">made by the chairs on this mailing list to decide what </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">needs to be done in terms of IPsec, probably for a very </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">wise reason. Now that we have a draft to base the discussion</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">on, we can start that,&nbsp; and hopefully the discussions </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">will result in some concensus call. </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Until then one can not assume what the concensus is. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15784.000C4BF0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 00:15:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14387
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 00:15:29 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28568;
	Wed, 17 Oct 2001 22:15:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03670;
	Wed, 17 Oct 2001 21:15:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4ELOI011842
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:14:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I4EKQX011841
	for mobile-ip-dist; Wed, 17 Oct 2001 21:14:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4EHOI011834
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:14:17 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03500
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:14:20 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10891
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:14:19 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA13221;
	Thu, 18 Oct 2001 14:13:05 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA05263;
	Thu, 18 Oct 2001 14:14:11 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXPS5A>; Thu, 18 Oct 2001 14:14:10 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED92@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: james@docomolabs-usa.com
Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof
	 fs-v4-02.txt
Date: Thu, 18 Oct 2001 14:14:07 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1578B.549DC160"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1578B.549DC160
Content-Type: text/plain


	Hi James, 

> >I think we should be safe in referring to Regional,
> >but
> >the chairs can help with this one.
> >The relationship between PRE-REG and Regional is
> >quite clear
> >so there is benefit in keeping it as an option since
> >it reduces
> >latency. It is less useful to POST-REG. 
> 
> Far as I can tell, the WG wants to fast track low
> latency, so I think we need to be careful about what
> we include in the references. I agree that there is a
> clear relationship, and even benefit should Regional
> get some deployment momentum, but I think we want to
> limit our exposure to possible delays. We could send
> it to the IESG with a specific question about whether
> or not the reference to Regional should be kept.
> 
	=> I think it's safe in the appendix. As long as it is not 
	in the body of the draft, there is no harm in mentioning 
	it in the appendix. That should not delay the progress of 
	the draft as it is clearly not a normative reference. 

	Hesham


------_=_NextPart_001_01C1578B.549DC160
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof fs-v4-02.txt</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hi James, </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&gt;I think we should be safe in referring to Regional,</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;but</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;the chairs can help with this one.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;The relationship between PRE-REG and Regional is</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;quite clear</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;so there is benefit in keeping it as an option since</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;it reduces</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;latency. It is less useful to POST-REG. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Far as I can tell, the WG wants to fast track low</FONT>
<BR><FONT SIZE=2 FACE="Arial">latency, so I think we need to be careful about what</FONT>
<BR><FONT SIZE=2 FACE="Arial">we include in the references. I agree that there is a</FONT>
<BR><FONT SIZE=2 FACE="Arial">clear relationship, and even benefit should Regional</FONT>
<BR><FONT SIZE=2 FACE="Arial">get some deployment momentum, but I think we want to</FONT>
<BR><FONT SIZE=2 FACE="Arial">limit our exposure to possible delays. We could send</FONT>
<BR><FONT SIZE=2 FACE="Arial">it to the IESG with a specific question about whether</FONT>
<BR><FONT SIZE=2 FACE="Arial">or not the reference to Regional should be kept.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; I think it's safe in the appendix. As long as it is not </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">in the body of the draft, there is no harm in mentioning </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">it in the appendix. That should not delay the progress of </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">the draft as it is clearly not a normative reference. </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C1578B.549DC160--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 00:25:47 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14555
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 00:25:47 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12410;
	Wed, 17 Oct 2001 21:24:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04831;
	Wed, 17 Oct 2001 21:24:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4O4OI011958
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:24:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I4O4tg011957
	for mobile-ip-dist; Wed, 17 Oct 2001 21:24:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4O0OI011950
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:24:00 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12563
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:24:04 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00782
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:24:03 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA09813;
	Wed, 17 Oct 2001 21:24:02 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I4O1f01109;
	Wed, 17 Oct 2001 21:24:01 -0700
X-mProtect:  Wed, 17 Oct 2001 21:24:01 -0700 Nokia Silicon Valley Messaging Protection
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdSRkhzh; Wed, 17 Oct 2001 21:23:59 PDT
Message-ID: <3BCE5953.75E16A4D@iprg.nokia.com>
Date: Wed, 17 Oct 2001 21:23:47 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110172200080.19013-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Pekka,

Pekka Savola wrote:

> Yes, this is one approach (alternative would be to define "Type-2"
> routing header, so RH's used would be distinguishable in the network.
> This has some significant benefits wrt. packet filtering) I'm suggesting
> in draft-savola-ipv6-rh-ha-security-00.txt, to be exact:

After reading your draft, which has many good points, I started
to believe that there is a good solution to the problems with
unrestrained use of routing headers.   In every case I could think
of, the problem could be characterized as one node following
an external directive to forward data to another "next" node without
authorization by that next node.  Maybe that's almost a tautology,
but it does point in a good direction towards a solution.  Namely,
a node shouldn't follow the routing header unless it has somehow
gotten this authorization.

In the case of interest, the mobile node certainly has authorization
to send packets from one of its addresses to another one of its
addresses, so there isn't much to be done here.  However, I
believe it would be valuable to formulate this as a more general
result -- namely, that the process of establishing routes along
the intermediate nodes in the routing header has to bring with
it the necessary authorization for each node to use the next
hop.  I like this rule because it seems to get exactly at the source
of the problem, and on the other hand in some ways it is a lot
less restrictive than the rules you suggested in your draft.

Regards,
Charlie P.

PS. I will type in the rest of my comments on your draft soon.



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 00:28:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14581
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 00:28:09 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13028;
	Wed, 17 Oct 2001 21:28:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05325;
	Wed, 17 Oct 2001 21:27:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4RFOI012054
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:27:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I4RFDg012053
	for mobile-ip-dist; Wed, 17 Oct 2001 21:27:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4RBOI012043
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:27:12 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12887
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:27:15 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01760
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:27:14 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA10002
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:27:14 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I4RDw06308
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:27:13 -0700
X-mProtect:  Wed, 17 Oct 2001 21:27:13 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpd4BSaHC; Wed, 17 Oct 2001 21:27:11 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id VAA21934 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:27:12 -0700 (PDT)
Message-ID: <3BCE5A20.9C2AE91C@iprg.nokia.com>
Date: Wed, 17 Oct 2001 21:27:12 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED8E@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> "Hesham Soliman (EPA)" wrote:
> 
>      >      But the sending node will have to know that the destination will
>      >      support this new header, else the packet is discarded.
>      >
>      >      Especially if destination is CN, this may or may not be possible.
>      >
>      >      => Agreed. Hence the need for a standard !
>      >      The Home Address option MUST be supported by
>      >      all IPv6 nodes. This solves your concerns.
>      >      The BU option and potentially the new ext header
>      >      SHOULD be supported .... voila.
> 
>      If both BU and the new header are optional, header type of BU
>      is recognized, that of the new header is not. Filtering forwarders
>      not knowing these options will possibly let the BU go through (knowing
>      at least the destination header type), but they do not know the new
>      header, most likely dropping it. This may be a problem.
> 
>      => The point raised by Pekka was reagarding the understanding
>      of headers e2e. How intemediate filters treat the headers is a separate
>      issue. However to answer your question, filters can typically
>      be configured to let / stop cetain ext headers from passing
>      through.

I was considering the issue of filters, where following 2460, having a
filter that does not wish to implement the header has hard time scanning
past it. There are headers with different length field semantics, even
though we would define it to follow that of the destination header, the box
does not know this when not implementing the header. Hence, I am not sure
it is as simple as configure it to ignore it; it most likely drops the
packet with no alternative to this.

>      Whether the new ext header is optional or not, has not
>      been discussed.

So let us discuss.. The optionality may be what one can hope in practice,
however leaving a new header optional may lead to the problem described
above. Secondly, an end node (CN) may send an ICMP or just drop the packet.
I guess these cases all can fall back to non-route optimized traffic,
but many CNs may end up being without route optimization.
A second question is the complexity of having a new header and the old BU,
is this a problem?

>      Hesham

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 00:38:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14658
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 00:38:19 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07246;
	Wed, 17 Oct 2001 22:37:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06793;
	Wed, 17 Oct 2001 21:38:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4bIOI012194
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:37:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I4bH6s012193
	for mobile-ip-dist; Wed, 17 Oct 2001 21:37:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I4bEOI012186
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:37:14 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04623
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 21:37:17 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA20793
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:59:44 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA15407
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:36:07 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA16543
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:37:14 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXPT3K>; Thu, 18 Oct 2001 14:37:13 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED94@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 18 Oct 2001 14:37:12 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1578E.8E2B27D0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1578E.8E2B27D0
Content-Type: text/plain

> > 
> >      >      But the sending node will have to know that the destination
> will
> >      >      support this new header, else the packet is discarded.
> >      >
> >      >      Especially if destination is CN, this may or may not be
> possible.
> >      >
> >      >      => Agreed. Hence the need for a standard !
> >      >      The Home Address option MUST be supported by
> >      >      all IPv6 nodes. This solves your concerns.
> >      >      The BU option and potentially the new ext header
> >      >      SHOULD be supported .... voila.
> > 
> >      If both BU and the new header are optional, header type of BU
> >      is recognized, that of the new header is not. Filtering forwarders
> >      not knowing these options will possibly let the BU go through
> (knowing
> >      at least the destination header type), but they do not know the new
> >      header, most likely dropping it. This may be a problem.
> > 
> >      => The point raised by Pekka was reagarding the understanding
> >      of headers e2e. How intemediate filters treat the headers is a
> separate
> >      issue. However to answer your question, filters can typically
> >      be configured to let / stop cetain ext headers from passing
> >      through.
> 
> I was considering the issue of filters, where following 2460, having a
> filter that does not wish to implement the header has hard time scanning
> past it. There are headers with different length field semantics, even
> though we would define it to follow that of the destination header, the
> box
> does not know this when not implementing the header. 
> 
	=> Jari, it is fairly simple to configure the firewall to pass
certain
	header numbers. If an implementor/adminstrator chooses not 
	to do so then they are effectively choosing not to support 
	mobility. Just like  an implementor may choose not to
	support the BU at all.
	The same issue appears with new transport protocol 
	headers. 

> Hence, I am not sure
> it is as simple as configure it to ignore it; it most likely drops the
> packet with no alternative to this.
> 
	=> There are alternatives, people also suggested reserving
	a UDP port. 

> So let us discuss.. The optionality may be what one can hope in practice,
> however leaving a new header optional may lead to the problem described
> above. Secondly, an end node (CN) may send an ICMP or just drop the
> packet.
> I guess these cases all can fall back to non-route optimized traffic,
> 
	=> Yes, just like a CN that does not support route opt at all.

> but many CNs may end up being without route optimization.
> A second question is the complexity of having a new header and the old BU,
> is this a problem?
> 
	=> Well, if we choose to have a new header number, we can
	simply copy the current header and just give it a new
	number. It becomes an IANA issue really. 
	I'm obviously only considering the issue of getting a 
	new ext header as I understood your question. 

	Also let's not forget the scond option: A UDP port.

	Hesham

------_=_NextPart_001_01C1578E.8E2B27D0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; But the sending node will have to =
know that the destination will</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support this new header, else the =
packet is discarded.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Especially if destination is CN, =
this may or may not be possible.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D&gt; Agreed. Hence the need for a =
standard !</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Home Address option MUST be =
supported by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all IPv6 nodes. This solves your =
concerns.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The BU option and potentially the =
new ext header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SHOULD be supported .... =
voila.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
both BU and the new header are optional, header type of BU</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is =
recognized, that of the new header is not. Filtering forwarders</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
not knowing these options will possibly let the BU go through =
(knowing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at =
least the destination header type), but they do not know the new</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
header, most likely dropping it. This may be a problem.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; The point raised by Pekka was reagarding the =
understanding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
headers e2e. How intemediate filters treat the headers is a =
separate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
issue. However to answer your question, filters can typically</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be =
configured to let / stop cetain ext headers from passing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
through.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I was considering the issue of =
filters, where following 2460, having a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">filter that does not wish to =
implement the header has hard time scanning</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">past it. There are headers with =
different length field semantics, even</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">though we would define it to follow =
that of the destination header, the box</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does not know this when not =
implementing the header.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Jari, it is =
fairly simple to configure the firewall to pass certain</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">header numbers. If =
an implementor/adminstrator chooses not </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">to do so then they =
are effectively choosing not to support </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">mobility. Just =
like&nbsp; an implementor may choose not to</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">support the BU at =
all.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The same issue =
appears with new transport protocol </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">headers. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hence, I am not sure</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it is as simple as configure it to =
ignore it; it most likely drops the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">packet with no alternative to =
this.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; There are =
alternatives, people also suggested reserving</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">a UDP port.</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So let us discuss.. The optionality =
may be what one can hope in practice,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">however leaving a new header optional =
may lead to the problem described</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">above. Secondly, an end node (CN) may =
send an ICMP or just drop the packet.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I guess these cases all can fall back =
to non-route optimized traffic,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Yes, just =
like a CN that does not support route opt at all.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">but many CNs may end up being without =
route optimization.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">A second question is the complexity =
of having a new header and the old BU,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is this a problem?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Well, if we =
choose to have a new header number, we can</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">simply copy the =
current header and just give it a new</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">number. It becomes =
an IANA issue really. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I'm obviously only =
considering the issue of getting a </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">new ext header as I =
understood your question. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Also let's not =
forget the scond option: A UDP port.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C1578E.8E2B27D0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 01:17:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15719
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 01:17:41 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22091;
	Wed, 17 Oct 2001 23:17:11 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08728;
	Wed, 17 Oct 2001 22:17:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5G7OI012328
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:16:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I5G7Ar012327
	for mobile-ip-dist; Wed, 17 Oct 2001 22:16:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5G3OI012320
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:16:03 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10793
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:16:05 -0700 (PDT)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.64.129])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA02881
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:38:31 -0600 (MDT)
Received: from MOBILEIP.qualcomm.com (mobileip.qualcomm.com [129.46.216.133])
	by adept.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f9I5FZR24992;
	Wed, 17 Oct 2001 22:15:35 -0700 (PDT)
Message-Id: <4.3.1.2.20011017221148.01f78f00@clea.qualcomm.com>
X-Sender: nabrol@clea.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 17 Oct 2001 22:13:34 -0700
To: charliep@iprg.nokia.com, pcalhoun@diameter.org,
        mobile-ip@sunroof.eng.sun.com
From: Nish Abrol <nabrol@qualcomm.com>
Subject: [mobile-ip] URGENT - rfc3012 interpretation question
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1150523635==_.ALT"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--=====================_1150523635==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Pat/Charlie,

Really appreciate any insights into this really important interop issue for 
cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This 
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the 
high order byte which was already used in the MD5 calculation  be included 
again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator be 
calculated  as:
     (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

       where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems  that 
calculating the MD5 authenticator with the same information(high order 
byte) at different locations of the payload weakens the authenticator.

So, what was the intention of the RFC and how should it be implemented? 
Also, do you know if RFC3012 implementations have participated in any 
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.





--=====================_1150523635==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Pat/Charlie,<br>
<br>
Really appreciate any insights into this really important interop issue
for cdma2000:<br>
<br>
A question regarding the&nbsp; interpretation of section 8 of rfc3012.
This section specifies how to calculate the MN-AAA authenticator. It
says:<br>
<br>
&quot; To compute the authenticator, apply MD5 [11] computed on the<br>
following data, in the order shown:<br>
<br>
High-order byte from Challenge || Key ||<br>
MD5(Preceding Mobile IP data ||<br>
Type, Subtype (if present), Length, SPI) ||<br>
Least-order 237 bytes from Challenge &quot;<br>
<br>
The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation&nbsp; be
included again as part of the&nbsp; &quot;least-order 237 bytes from
Challenge&quot;?<br>
<br>
e.g. if the challenge is 50 bytes in length - should the authenticator be
calculated&nbsp; as:<br>
&nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator = md5(byte0 || key.......||
byte1 through byte49)<br>
<br>
or (b) authenticator = md5(byte0 || key ......|| <u>byte0 </u>through
byte49).<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the most significant byte
of the challenge.<br>
<br>
A strict reading of the RFC seems to suggest (b). However, it seems&nbsp;
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.<br>
<br>
So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?<br>
<br>
Your help will be really appreciated.<br>
<br>
Thanks<br>
Nish Abrol<br>
Qualcomm, Inc.<br>
<br>
<br>
<br>
<br>
</html>

--=====================_1150523635==_.ALT--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 01:36:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17098
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 01:36:52 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29513;
	Wed, 17 Oct 2001 23:36:15 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10493;
	Wed, 17 Oct 2001 22:36:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5ZROI012479
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:35:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I5ZRjc012478
	for mobile-ip-dist; Wed, 17 Oct 2001 22:35:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5ZNOI012471
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:35:23 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21454
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:35:19 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23017
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:35:25 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA13410
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:35:24 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I5ZOU21938
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:35:24 -0700
X-mProtect:  Wed, 17 Oct 2001 22:35:24 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdzQbdWW; Wed, 17 Oct 2001 22:35:22 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id WAA21989 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:35:22 -0700 (PDT)
Message-ID: <3BCE6A1A.E996ED6E@iprg.nokia.com>
Date: Wed, 17 Oct 2001 22:35:22 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED94@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham,

>      >      issue. However to answer your question, filters can typically
>      >      be configured to let / stop cetain ext headers from passing
>      >      through.
> 
>      I was considering the issue of filters, where following 2460, having a
>      filter that does not wish to implement the hdr has hard time scanning
>      past it. There are headers with different length field semantics, even
>      though we would define it to follow that of the destination header, the
>      box does not know this when not implementing the header.
> 
>      => Jari, it is fairly simple to configure the firewall to pass certain
>      header numbers. If an implementor/adminstrator chooses not
>      to do so then they are effectively choosing not to support
>      mobility. Just like  an implementor may choose not to
>      support the BU at all.
>      The same issue appears with new transport protocol
>      headers.

If not strictly 2460, a legacy firewall may have implementation
which lets packets with some unknown header go through, but this depends
really what one means by support; knowing it is an end header that can
safely be let through and having the possiblity and willingness to
configure letting this header through can be called filtering support
for the new header. I am not sure this support is always there.

>      Hence, I am not sure
>      it is as simple as configure it to ignore it; it most likely drops the
>      packet with no alternative to this.
> 
>      => There are alternatives, people also suggested reserving
>      a UDP port.

Actually, from the other dimension of alternatives you refer to here,
the UDP could be a better one than a new header; it can be known to be
supported also by all old and new firewalls, and even by all end nodes.

>      So let us discuss.. The optionality may be what one can hope in practice,
>      however leaving a new header optional may lead to the problem described
>      above. Secondly, an end node (CN) may send an ICMP or just drop the packet.
>      I guess these cases all can fall back to non-route optimized traffic,
> 
>      => Yes, just like a CN that does not support route opt at all.
> 
>      but many CNs may end up being without route optimization.
>      A second question is the complexity of having a new header and the old BU,
>      is this a problem?
> 
>      => Well, if we choose to have a new header number, we can
>      simply copy the current header and just give it a new
>      number. It becomes an IANA issue really.
>      I'm obviously only considering the issue of getting a
>      new ext header as I understood your question.

Actually, it might be good to look at all the complexity
this may introduce.
 
>      Also let's not forget the scond option: A UDP port.

I agree with this one, with new hdr, implementations need to have protocol
switches to two headers. And while one accepts all destination options,
another does not accept the same set of options, introducing some
extra logic. Then, the UDP, though a bit artificial, does not seem
very complex.

>      Hesham

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 01:43:55 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17390
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 01:43:54 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25820;
	Wed, 17 Oct 2001 22:43:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22557;
	Wed, 17 Oct 2001 22:43:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5gfOI012632
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:42:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I5gfuI012630
	for mobile-ip-dist; Wed, 17 Oct 2001 22:42:41 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5gbOI012615
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:42:37 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10961
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 22:42:39 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01986
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:42:18 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA21321
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:41:29 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA08330
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:42:36 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXPVJK>; Thu, 18 Oct 2001 15:42:35 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED96@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 18 Oct 2001 15:42:34 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15797.B00EE950"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15797.B00EE950
Content-Type: text/plain

> >      => Jari, it is fairly simple to configure the firewall to pass
> certain
> >      header numbers. If an implementor/adminstrator chooses not
> >      to do so then they are effectively choosing not to support
> >      mobility. Just like  an implementor may choose not to
> >      support the BU at all.
> >      The same issue appears with new transport protocol
> >      headers.
> 
> If not strictly 2460, a legacy firewall may have implementation
> which lets packets with some unknown header go through, but this depends
> really what one means by support; knowing it is an end header that can
> safely be let through and having the possiblity and willingness to
> configure letting this header through can be called filtering support
> for the new header. I am not sure this support is always there.
> 
	=> Ok, so what would these "old" firewalls do about SCTP ?


> >      So let us discuss.. The optionality may be what one can hope in
> practice,
> >      however leaving a new header optional may lead to the problem
> described
> >      above. Secondly, an end node (CN) may send an ICMP or just drop the
> packet.
> >      I guess these cases all can fall back to non-route optimized
> traffic,
> > 
> >      => Yes, just like a CN that does not support route opt at all.
> > 
> >      but many CNs may end up being without route optimization.
> >      A second question is the complexity of having a new header and the
> old BU,
> >      is this a problem?
> > 
> >      => Well, if we choose to have a new header number, we can
> >      simply copy the current header and just give it a new
> >      number. It becomes an IANA issue really.
> >      I'm obviously only considering the issue of getting a
> >      new ext header as I understood your question.
> 
> Actually, it might be good to look at all the complexity
> this may introduce.
> 
	=> Are you referring to the IANA process ? I guess
	you're referring to your earlier statement about firewalls.
	If so my answer above applies. 
>  
> >      Also let's not forget the scond option: A UDP port.
> 
> I agree with this one, with new hdr, implementations need to have protocol
> switches to two headers. And while one accepts all destination options,
> another does not accept the same set of options, introducing some
> extra logic. Then, the UDP, though a bit artificial, does not seem
> very complex.
> 
	=> I don't have a problem with the UDP solution either.

	Hesham

------_=_NextPart_001_01C15797.B00EE950
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; Jari, it is fairly simple to configure the firewall to pass =
certain</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
header numbers. If an implementor/adminstrator chooses not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
do so then they are effectively choosing not to support</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mobility. Just like&nbsp; an implementor may choose not to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
support the BU at all.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The same issue appears with new transport protocol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
headers.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If not strictly 2460, a legacy =
firewall may have implementation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">which lets packets with some unknown =
header go through, but this depends</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">really what one means by support; =
knowing it is an end header that can</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">safely be let through and having the =
possiblity and willingness to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">configure letting this header through =
can be called filtering support</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for the new header. I am not sure =
this support is always there.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Ok, so what =
would these &quot;old&quot; firewalls do about SCTP ?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So =
let us discuss.. The optionality may be what one can hope in =
practice,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
however leaving a new header optional may lead to the problem =
described</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
above. Secondly, an end node (CN) may send an ICMP or just drop the =
packet.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I =
guess these cases all can fall back to non-route optimized =
traffic,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; Yes, just like a CN that does not support route opt at =
all.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
but many CNs may end up being without route optimization.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A =
second question is the complexity of having a new header and the old =
BU,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is =
this a problem?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; Well, if we choose to have a new header number, we can</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
simply copy the current header and just give it a new</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
number. It becomes an IANA issue really.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I'm obviously only considering the issue of getting a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
new ext header as I understood your question.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Actually, it might be good to look at =
all the complexity</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this may introduce.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Are you =
referring to the IANA process ? I guess</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">you're referring to =
your earlier statement about firewalls.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If so my answer =
above applies.</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Also let's not forget the scond option: A UDP port.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree with this one, with new hdr, =
implementations need to have protocol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">switches to two headers. And while =
one accepts all destination options,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">another does not accept the same set =
of options, introducing some</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">extra logic. Then, the UDP, though a =
bit artificial, does not seem</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">very complex.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; I don't have =
a problem with the UDP solution either.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15797.B00EE950--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 02:44:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29507
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 02:44:23 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06515;
	Wed, 17 Oct 2001 23:43:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25473;
	Wed, 17 Oct 2001 23:43:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6giOI012807
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:42:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I6giLQ012806
	for mobile-ip-dist; Wed, 17 Oct 2001 23:42:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6geOI012799
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:42:40 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16394
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:42:43 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25722
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:42:23 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA16951
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:42:42 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I6gf803058
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:42:41 -0700
X-mProtect:  Wed, 17 Oct 2001 23:42:41 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdptRTRB; Wed, 17 Oct 2001 23:42:38 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id XAA22042 for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:42:08 -0700 (PDT)
Message-ID: <3BCE79C0.E7F7A25E@iprg.nokia.com>
Date: Wed, 17 Oct 2001 23:42:08 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED96@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham,

>      If not strictly 2460, a legacy firewall may have implementation
>      which lets packets with some unknown header go through, but it depends
>      really what one means by support; knowing it is an end header that can
>      safely be let through and having the possiblity and willingness to
>      configure letting this header through can be called filtering support
>      for the new header. I am not sure this support is always there.
> 
>      => Ok, so what would these "old" firewalls do about SCTP ?

Even though SCTP would be allowed through, a new extension header may
be problematic, if it just very straightforwardly re-uses dst.hdr logic
at end points, as I understood you were suggesting.

Suppose the following: A firewall simply lets a new header with some
protocol number through. Entering an empty header to a packet sent to
the header-aware end node would let the rest of the packet pass unchecked.
That is, if the firewall has filtering rules, e.g., TCP port -based,
it can no longer enforce these since not scanning past the unknown
header. If the receiver inside the corporate network scans past the
empty header, any new-header -aware node inside would be wide open
since the sender could then just add the upper layer such as TCP.
Hence, in case of a new header type, also the receiver MUST enforce
not to allow piggybacking with it, adding a bit of complexity.

Even while disallowing piggybacking, any unknown header can be used
to set up an open channel between cooperating nodes. This to motivate
why some may have reservations letting any unknown headr thru. Hence,
with a known header type, such as with the UDP port alternative, all
firewalls can more precisely be configured to let only signaling go
through.

>      >      => Well, if we choose to have a new header number, we can
>      >      simply copy the current header and just give it a new
>      >      number. It becomes an IANA issue really.
>      >      I'm obviously only considering the issue of getting a
>      >      new ext header as I understood your question.
> 
>      Actually, it might be good to look at all the complexity
>      this may introduce.
> 
>      => Are you referring to the IANA process ?

It would be good to know implementation complexities of each solution
to help choosing one (my remark above).

>      >      Also let's not forget the scond option: A UDP port.
> 
> Then, the UDP, though a bit artificial, does not seem very complex.
> 
>      => I don't have a problem with the UDP solution either.
> 
>      Hesham

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 02:54:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00103
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 02:54:03 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01348;
	Thu, 18 Oct 2001 00:53:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26627;
	Wed, 17 Oct 2001 23:53:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6qsOI012991
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:52:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I6qsUO012990
	for mobile-ip-dist; Wed, 17 Oct 2001 23:52:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6qpOI012983
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:52:51 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28993
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 17 Oct 2001 23:52:47 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00870
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:52:33 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA29274
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 16:51:43 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA28197
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 16:52:51 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXPXSX>; Thu, 18 Oct 2001 16:52:50 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED99@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 18 Oct 2001 16:52:46 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C157A1.7EB09F20"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C157A1.7EB09F20
Content-Type: text/plain


> >      If not strictly 2460, a legacy firewall may have implementation
> >      which lets packets with some unknown header go through, but it
> depends
> >      really what one means by support; knowing it is an end header that
> can
> >      safely be let through and having the possiblity and willingness to
> >      configure letting this header through can be called filtering
> support
> >      for the new header. I am not sure this support is always there.
> > 
> >      => Ok, so what would these "old" firewalls do about SCTP ?
> 
> Even though SCTP would be allowed through, a new extension header may
> be problematic, 
> 
	=> This might be a thick question, but what's the difference ?
	Isn't SCTP a NEW header ? Why would that be allowed. 

> if it just very straightforwardly re-uses dst.hdr logic
> at end points, as I understood you were suggesting.
> 
> Suppose the following: A firewall simply lets a new header with some
> protocol number through. Entering an empty header to a packet sent to
> the header-aware end node would let the rest of the packet pass unchecked.
> That is, if the firewall has filtering rules, e.g., TCP port -based,
> it can no longer enforce these since not scanning past the unknown
> header. If the receiver inside the corporate network scans past the
> empty header, any new-header -aware node inside would be wide open
> since the sender could then just add the upper layer such as TCP.
> Hence, in case of a new header type, also the receiver MUST enforce
> not to allow piggybacking with it, adding a bit of complexity.
> 
> Even while disallowing piggybacking, any unknown header can be used
> to set up an open channel between cooperating nodes. 
> 
	=> I understand your logic but I can't see the difference between

	- an "unpiggybacked" BU with a new ext header and 
	- an SCTP payload.  
	Could you tell me why these two are different ?

	If you drop the former then you'd drop the latter ...right ?
	Sounds like a firewall that needs an upgrade. 


> This to motivate
> why some may have reservations letting any unknown headr thru. 
> 
	=> Ok, but so far I heard this from you only :) 
	If more people see this problem then I'm glad you brought
	it up so we can clarify it. 

> Hence,
> with a known header type, such as with the UDP port alternative, all
> firewalls can more precisely be configured to let only signaling go
> through.
> 
	=> Again I have no problem with using UDP either, but 
	for very different reasons. 

	Hesham



------_=_NextPart_001_01C157A1.7EB09F20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
not strictly 2460, a legacy firewall may have implementation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
which lets packets with some unknown header go through, but it =
depends</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
really what one means by support; knowing it is an end header that =
can</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
safely be let through and having the possiblity and willingness =
to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
configure letting this header through can be called filtering =
support</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
for the new header. I am not sure this support is always there.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; Ok, so what would these &quot;old&quot; firewalls do about SCTP =
?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Even though SCTP would be allowed =
through, a new extension header may</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be problematic,</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; This might =
be a thick question, but what's the difference ?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Isn't SCTP a NEW =
header ? Why would that be allowed. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">if it just very straightforwardly =
re-uses dst.hdr logic</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">at end points, as I understood you =
were suggesting.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Suppose the following: A firewall =
simply lets a new header with some</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">protocol number through. Entering an =
empty header to a packet sent to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the header-aware end node would let =
the rest of the packet pass unchecked.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">That is, if the firewall has =
filtering rules, e.g., TCP port -based,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it can no longer enforce these since =
not scanning past the unknown</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">header. If the receiver inside the =
corporate network scans past the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">empty header, any new-header -aware =
node inside would be wide open</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">since the sender could then just add =
the upper layer such as TCP.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Hence, in case of a new header type, =
also the receiver MUST enforce</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not to allow piggybacking with it, =
adding a bit of complexity.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Even while disallowing piggybacking, =
any unknown header can be used</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to set up an open channel between =
cooperating nodes.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; I understand =
your logic but I can't see the difference between</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- an =
&quot;unpiggybacked&quot; BU with a new ext header and </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- an SCTP =
payload.&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Could you tell me =
why these two are different ?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If you drop the =
former then you'd drop the latter ...right ?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Sounds like a =
firewall that needs an upgrade. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">This to motivate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">why some may have reservations =
letting any unknown headr thru.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Ok, but so =
far I heard this from you only :) </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If more people see =
this problem then I'm glad you brought</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">it up so we can =
clarify it. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hence,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with a known header type, such as =
with the UDP port alternative, all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">firewalls can more precisely be =
configured to let only signaling go</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">through.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Again I have =
no problem with using UDP either, but </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">for very different =
reasons. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C157A1.7EB09F20--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 03:15:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01392
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 03:15:39 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA14802;
	Thu, 18 Oct 2001 00:14:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29066;
	Thu, 18 Oct 2001 00:14:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7DpOI013166
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:13:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I7DpSQ013165
	for mobile-ip-dist; Thu, 18 Oct 2001 00:13:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7DmOI013158
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:13:48 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21969
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:13:51 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11609
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:13:31 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA18951
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:13:50 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I7DnK22942
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:13:49 -0700
X-mProtect:  Thu, 18 Oct 2001 00:13:49 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdM9sXf2; Thu, 18 Oct 2001 00:13:47 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id AAA22074 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:13:48 -0700 (PDT)
Message-ID: <3BCE812C.9A29F1D3@iprg.nokia.com>
Date: Thu, 18 Oct 2001 00:13:48 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED99@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham,

>      Even while disallowing piggybacking, any unknown header can be used
>      to set up an open channel between cooperating nodes.
> 
>      => I understand your logic but I can't see the difference between
> 
>      - an "unpiggybacked" BU with a new ext header and
>      - an SCTP payload.
>      Could you tell me why these two are different ?

If protecting boxes "inside" one might want to be sure unknown protocols
passed through are end headers as compared to allowing any (arbitrary)
protocols through. SCTP: end header, "unpiggybacked" BU: ok as long it
is impossible to make a box "inside" also accept it with piggybacking.
Hence a BU with a new header may be more dangerous depending on how it
is specified/implemented (you may send it unpiggybacked, the attacker
tries with piggybacking).

>      Hesham

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 03:18:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01426
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 03:18:00 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15691;
	Thu, 18 Oct 2001 00:17:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20412;
	Thu, 18 Oct 2001 00:17:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7GCOI013216
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:16:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I7GBbb013215
	for mobile-ip-dist; Thu, 18 Oct 2001 00:16:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7G5OI013202
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:16:07 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9I7Fpq01134;
	Thu, 18 Oct 2001 09:15:52 +0200 (MET DST)
Date: Thu, 18 Oct 2001 09:10:25 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)
To: Henrik Petander <lpetande@tml.hut.fi>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <Pine.SOL.4.10.10110171103300.7311-100000@morphine.tml.hut.fi>
Message-ID: <Roam.SIMC.2.0.6.1003389025.4352.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> MN and the ISP providing the access via the router are likely to have a
> trust relationship, since MN is allowed to use the resources of the ISP.
> This trust relationship could be used also between the (acccess) routers
> acting as HAs and MN to authorize the use of the HA service.
> 
> I think that the problem of authorizing the home registration is twofold,
> on one hand MN needs to prove that it is allowed to use the service of HA,
> and on the other it needs to prove that it "owns" the possibly temporary
> address it is trying to register with the HA. The trust relationship
> between MN and the default router could easily be used for the first
> purpose, but for the second purpose something else is needed. 
> 
> One possible solution is that MN creates the SA with the "foreign" HA when
> it is in the same network as the HA and, if the HA does not have an
> existing registration / SA for that address it accepts the SA, provided
> that MN is authorized to use the HA service. If the registration fails MN
> creates a new CoA with a random host identifier and tries to establish a
> SA for it. DAD would guarantee that there would not be two nodes with the
> same address.
> 
> MN presents its credentials to the HA to gain access to the HA service, so
> only nodes authorized to use the service of the HA could establish SAs and
> do home registrations for the addresses. This should protect the system
> against DoS attacks effectively. The same system could perhaps be used
> also for "normal" home registration with dynamic DNS. 
> 
> What do you think?

I think you've, perhaps non-intentionally, just shown that you agree with
my original point which was that the security and trust issues with
a previous default router accepting BUs from an MN for the MNs previous CoA
(in the "previous-default-router-HA-for-CoA" case)
requires quite different security mechanisms than what is needed
between the MN and its "normal" HA.

Hence it makes sense to discuss them separately in the security-reqs document.

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 03:38:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01701
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 03:38:28 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24518;
	Thu, 18 Oct 2001 01:37:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22809;
	Thu, 18 Oct 2001 00:38:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7ZeOI013420
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:35:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I7Zdqi013419
	for mobile-ip-dist; Thu, 18 Oct 2001 00:35:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7ZaOI013412
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:35:36 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02089
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:35:39 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19692
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:58:24 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9I7ZUk20526
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:35:31 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA04429
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:35:30 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9I7ZUD71090
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:35:30 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110180735.f9I7ZUD71090@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Wed, 17 Oct 2001 15:56:32 CDT.
             <933FADF5E673D411B8A30002A5608A0E6FF4C4@zrc2c012.us.nortel.com> 
Date: Thu, 18 Oct 2001 09:35:30 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   Do you believe there might ever be a need to send a binding update in the
   same packet as an RSVP or something similar message?
   
=> I don't fully understand your question but:
 - I really believe that piggybacking is a bad idea
 - if your example is RSVP because of the router alert option in
   a hop-by-hop header, a BU as a (final) destination option should
   be processed correctly (i.e. the whole extension skipped) by every
   intermediate routers
 - the burden is not so high (when you put a hop-by-hop extension,
   you definitely ask for the slow and hard path :-)

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 03:41:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01758
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 03:41:14 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26464;
	Thu, 18 Oct 2001 01:40:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23240;
	Thu, 18 Oct 2001 00:40:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7eFOI013548
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:40:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I7eFh6013547
	for mobile-ip-dist; Thu, 18 Oct 2001 00:40:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7eBOI013536
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:40:11 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23171
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:40:14 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16120
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:40:13 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9I7eCu23357
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:40:12 +0300
Date: Thu, 18 Oct 2001 10:40:12 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED99@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110181028170.23178-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 18 Oct 2001, Hesham Soliman (EPA) wrote:
> 	- an "unpiggybacked" BU with a new ext header and 
> 	- an SCTP payload.  
> 	Could you tell me why these two are different ?
> 
> 	If you drop the former then you'd drop the latter ...right ?
> 	Sounds like a firewall that needs an upgrade. 

The difference is significant.  Perhaps I can help to clarify the 
situation.

 SCTP header would be like:

  IPv6 HDR - SCTP header

 BU with new Ext Header would be like (if I get this right):

  IPv6 HDR - UnknownHeaderBU - TCP/UDP/... header
 
Now consider a firewall filtering traffic.  It may have rules like:

 [...]
 allow proto tcp from any to any established
 allow proto tcp from any to any dst port 22
 deny  proto tcp from any to any

Furthermore, a first rule could be 'allow proto sctp from any to any'
(note: the firewall does not need to know anything about SCTP, just the
protocol number) but that's not necessary.

With UnknownHeaderBU, the real payload is TCP and should be subjected to
firewall's _TCP_ filtering rules, but it cannot.  If the firewall cannot
parse the header, the packet would pass only if:

 - UnknownHeaderBU is explicitly allowed
 - default is to allow all

But in this case, the security could be penetrated as one cannot perform 
the TCP/UDP/... checks for the headers after the unknown header.

With SCTP, the firewall administrator _can_ make a _conscious_ decision to
pass SCTP protocol through (as there are no unknowns before it!),
thinking "those people can protect themselves".

I intend to write an I-D on these issues one of these days...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 03:50:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01865
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 03:50:46 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00955;
	Thu, 18 Oct 2001 01:50:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24396;
	Thu, 18 Oct 2001 00:50:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7mmOI013680
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:48:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I7ml5W013679
	for mobile-ip-dist; Thu, 18 Oct 2001 00:48:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7miOI013672
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:48:44 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03587
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 00:48:47 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24032
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 02:11:31 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9I7mik22973
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:48:44 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA04737
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:48:44 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9I7miD71145
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:48:44 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110180748.f9I7miD71145@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Wed, 17 Oct 2001 14:42:29 PDT.
             <3BCDFB45.A42BD2D@iprg.nokia.com> 
Date: Thu, 18 Oct 2001 09:48:44 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   I would like to ask a clarification: What happens if the sender omits
   the upper layer (this also makes the packet non-piggybacked), doesn't
   this expose any header to potentially be the last one?

=> this is impossible because extension headers have a next header
field and you have to put something in it (and if you put "no next header"
then the last logical header is "no next header" :-).

   Wouldn't this
   mean that with a new header type for one or more of the current destination
   options one could introduce a policy of protecting exactly this signaling?

=> for a final header this is true (the selector problem comes from the
fact that by definition there is one and only one final header per packet
and a very variable number (zero to many) of extension headers).

   But, as said, using a well-known UDP port has been suggested as an
   alternative.
   
=> UDP port 434? This is the cheap alternative to burn a next header value.

   Also on piggybacking, what would be the consequence, if, say, piggybacking
   is not killed, but only disabled at sender when using IPsec?
   
=> there are many reasons to kill piggybacking, IPsec incompability
is only one of them... And a new header (or a well-known UDP port)
doesn't work with piggybacking.

   Given the recent interest on DOS attacks, wouldn't insecure BRs also
   help mounting these, even though BR has weaker requirements? Hence,
   if they can be dealt the same way as BUs and BAs, wouldn't this be ok?
   
=> this is exactly what I think.

Thanks

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 04:21:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02274
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 04:21:50 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19225;
	Thu, 18 Oct 2001 02:21:03 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07806;
	Thu, 18 Oct 2001 01:20:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I8JTOI013924
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:19:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I8JTZM013923
	for mobile-ip-dist; Thu, 18 Oct 2001 01:19:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I8JQOI013916
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:19:26 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29482
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:19:29 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01303
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:19:29 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id BAA22574
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:19:29 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I8JS629015
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:19:28 -0700
X-mProtect:  Thu, 18 Oct 2001 01:19:28 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdlk0zAw; Thu, 18 Oct 2001 01:19:27 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id BAA22133 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:19:27 -0700 (PDT)
Message-ID: <3BCE908F.82AD5CFC@iprg.nokia.com>
Date: Thu, 18 Oct 2001 01:19:27 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <200110180748.f9I7miD71145@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>    Also on piggybacking, what would be the consequence, if, say,
>    piggybacking is not killed, but only disabled at sender when
>    using IPsec?
> 
> => there are many reasons to kill piggybacking, IPsec incompability
> is only one of them... And a new header (or a well-known UDP port)
> doesn't work with piggybacking.

Rephrasing: if we mutually exclude IPsec and piggybacking, this would
also mean we use it only with the old style BU (not with the new header
nor UDP). For the "tight pipe" bandwidth reason, it seems like a broken
link whose general applicability to variable-length IP (e.g. browsing)
is questionable. If QoS cannot resolve this or such L2 cannot transparently
mask piggybacking, one could consider introducing a negotiation with a
"don't piggyback" bit in BAck. MN closer to the "tight pipe" when
receiving a BU would know when to discourage piggybacking. If the first
piggybacked BU packet would be so unfortunate as to be dropped at
the entrance to the "tight pipe", the sending MN would then not
piggyback on resends and then get the BAck with "don't piggyback".

What other significant reasons would there be to kill it?

> Francis.Dupont@enst-bretagne.fr

BR,

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 04:46:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02490
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 04:46:38 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA10675;
	Thu, 18 Oct 2001 01:46:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10165;
	Thu, 18 Oct 2001 01:45:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I8j5OI014088
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:45:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I8j5aj014087
	for mobile-ip-dist; Thu, 18 Oct 2001 01:45:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I8j1OI014080
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:45:02 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02365
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 01:45:05 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA18968
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:07:51 -0600 (MDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9I8ixj29806
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:44:59 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Oct 18 10:44:35 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TH2KWPLX>; Thu, 18 Oct 2001 10:37:13 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320C5205C4@esealnt117>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof
	 fs-v4-02.txt
Date: Thu, 18 Oct 2001 10:44:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi James,

I think there's only one issue left. Two of your
comments below say that a low bandwidth channel on
which there is real time traffic cannot be used by
a MN to send Mobile IP signalling without disrupting
its communication. This assumes a few things:

- that the MIP signalling takes up significant bandwidth
  and disrupts real time traffic
- that there is not enough extra bandwidth for the
  MIP signalling on that channel
- that there is no reserved signalling bandwidth or
  dedicated signalling channel.

Don't think these are assumptions we should rely on.
If we talk about real-time and channel access we need to
consider QoS, radio realisations etc. but this is
complex and varies between wireless systems. I'd prefer
if we kept low latency generic and left this work for
the radio network implementors.

Rgds
/Karim

> -----Original Message-----
> From: James Kempf [mailto:kempf42@yahoo.com]
> Sent: den 17 oktober 2001 19:08
> To: mobile-ip@sunroof.eng.sun.com
> Cc: james@docomolabs-usa.com
> Subject: RE: [mobile-ip] Comments on
> draft-ietf-mobileip-lowlatency-handof fs-v4-02.txt
> 
> 
> Hi Karim,
> 
> > The Appendix used to be in the main text. It is only
> > meant
> > to give an example of a simple way to do handoffs
> > over
> > multiple interfaces. It does say that the low
> > latency
> > method may be needed anyway, but provides a scenario
> > where it could be avoided (depending on coverage
> > areas).
> > It is more to do with applicability of low latency
> > in
> > general. I think it should stay somewhere in the
> > doc.
> > Anyone have strong opinions regarding Appendix vs.
> > main
> > text?
> > 
> 
> Well, to avoid thrash, let's keep it in the Appendix
> then. I actually think there is need for another draft
> that clearly specifies how to do intertechnology
> handoff, for interoperability purposes, and that this
> text would be a good start, but unless the chairs or
> another WG member have other ideas, I think we can
> send it to the IESG with the Appendix and see whether
> or not they feel it is necessary.
> 
> > MUST cannot be used in this way. From RFC 2119:
> > 
> >    MUST   This word, or the terms "REQUIRED" or
> > "SHALL", mean that the
> >    definition is an absolute requirement of the
> > specification.
> > 
> > Since HTT is only applicable in certain cases where
> > the MN moves too fast,
> 
> I actually don't agree that this is the case. It is
> also applicable to a low bandwidth radio protocol if
> the MN wants to delay changing its CoA because it has
> real time traffic and the MIP signaling would steal
> bandwidth from the real time traffic.
> 
> > it is not an absolute requirement of this spec. What
> > I would propose is
> > just to use the first part of your text modified
> > along these lines:
> > 
> > "For radio L2 protocols in which it is possible for
> > the MN to move so rapidly
> > from one FA to another such that a probability
> > exists that the Mobile IP
> > Registration with nFA will not complete before the
> > MN moves on, HTT SHOULD be
> > implemented."
> > 
> 
> I would prefer that the second part be included as
> well. If you want, it could also be clarified:
> 
> "In addition, HTT SHOULD be implemented for low
> bandwidth radio protocols in which MIP signaling may
> cause a disruption in real time traffic, since it
> allows the MN to seamlessly continue real time traffic
> onto a third FA during handover without any MIP
> signaling."
> 
> 
> >I think the assumption is that the FA is the default
> >router, but this can be changed if the WG thinks it
> is
> >too restrictive. If the FA is not the default router
> >then
> >reverse tunneling MN traffic to oFA would be complex.
> >Also,
> >renewing oFA as default router can be done only if
> >the nFA
> >reverse tunnels traffic to oFA so it does not apply
> >to all
> >POST-REG. If the FA as default router assumption is
> >valid we could
> >add a few lines on the specific nFA to oFA reverse
> >tunneling case
> >where oFA RAs are tunneled through nFA to the MN (in
> >a similar
> >way to PRE-REG but in the opposite direction).
> 
> 
> OK.
> 
> >I also think that the 30 min. lifetime is not a major
> >limitation since MNs wouldn't delay registrations
> >that long.
> 
> Agree, but I would leave the actual time out of the
> text.
> 
> In some respects, since the MN will have to do
> signaling over the radio channel to renew its
> registrations, it's a tossup whether it terminates use
> of the old CoA or not, but I still think it should be
> left open as a policy issue. The FA can always demand
> termination of the BET if the MN's registration is
> reaching the end of its lifetime.
> 
> >That is what is meant by "infinity". From RFC2002 on
> >Registration lifetime: "A value of 0xffff indicates
> >infinity"
> >Of course the registration can be terminated using
> >lifetime zero.
> 
> If there is precedent for the terminology, then let's
> leave it as is.
> 
> >It's not only handoff smoothing this section
> >considers,
> >it's also other issues related to the trigger and
> >handoff
> >timing. I'll read through to see if I can clarify
> >things.
> 
> OK. I really couldn't figure it out, sorry.
> 
> >I think we should be safe in referring to Regional,
> >but
> >the chairs can help with this one.
> >The relationship between PRE-REG and Regional is
> >quite clear
> >so there is benefit in keeping it as an option since
> >it reduces
> >latency. It is less useful to POST-REG. 
> 
> Far as I can tell, the WG wants to fast track low
> latency, so I think we need to be careful about what
> we include in the references. I agree that there is a
> clear relationship, and even benefit should Regional
> get some deployment momentum, but I think we want to
> limit our exposure to possible delays. We could send
> it to the IESG with a specific question about whether
> or not the reference to Regional should be kept.
> 
> Raj, Phil, what do you think?
> 
>                      jak
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 05:54:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03181
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 05:54:20 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29902;
	Thu, 18 Oct 2001 02:51:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16710;
	Thu, 18 Oct 2001 02:51:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I9oKOI014307
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 02:50:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I9oKl7014306
	for mobile-ip-dist; Thu, 18 Oct 2001 02:50:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I9oHOI014299
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 02:50:17 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14513
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 02:50:19 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15789
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 04:14:01 -0600 (MDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9I9oGC08138
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:50:17 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id LAA25540; Thu, 18 Oct 2001 11:50:16 +0200
Message-ID: <3BCEA53F.EBC991BC@era.ericsson.se>
Date: Thu, 18 Oct 2001 11:47:43 +0200
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110172200080.19013-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Pekka,

Pekka Savola wrote:
> 
> On Wed, 17 Oct 2001, Michael Thomas wrote:
> > Pekka Savola writes:
> >  > But the _real problem_, one could say caused by MIPv6, is that all nodes
> >  > (at least all mobile nodes) _must_ have this Routing Header processing
> >  > enabled.  One could say MIPv6, as defined, may open every mobile node for
> >  > abuse.
> >  >
> >  > If there was no MIPv6, there would be no strong need to be able to process
> >  > routing headers in hosts, only a few, possibly hand-picked, routers.  The
> >  > risks would be manageable.
> >
> >    Couldn't there be different requirements for hosts
> >    vs. routers? Ie, a node MUST process a packet with
> >    a routing header, but MAY drop packets for which the
> >    next destination address is not a valid destination
> >    address for the host?
> >
> >    Ie, the host will forward to its stack, but not
> >    out another interface? This seems pretty consistant
> >    with the definition of hosts and routers.
> 
> Yes, this is one approach (alternative would be to define "Type-2"
> routing header, so RH's used would be distinguishable in the network.
> This has some significant benefits wrt. packet filtering) I'm suggesting
> in draft-savola-ipv6-rh-ha-security-00.txt, to be exact:
> 
> --8<--
>    If a node would have to process the Routing Header (that is,
>    destination address equals the node and segments left > 0), it SHOULD
>    check whether segments left equals 1, and if both the current
>    destination address and to-be-swapped destination address in the
>    Routing Header are both assigned to the same interface of the node
>    and are both of the same zone [ADDRSCOPE], the Routing Header is here
>    referred to as "Interface-local Routing Header".
> 
>    On Routers, further processing of Routing Headers SHOULD be
>    configurable and SHOULD be enabled by default.
> 
>    On Hosts, further processing of Routing Headers MAY be configurable
>    and MUST be disabled by default.
> 
>    Regardless of the general Routing Header processing setting, all
>    nodes SHOULD still process "Interface-local" Routing Headers.
>    Disabling this exception MAY also be configurable.
> --8<--
> 
> I was pretty conserative with SHOULD/MUST, could have been stricter.
> 
> Please also see the security implication of this "interface-local"
> property:
> 
> --8<--
>    One should note that note that "Interface-local" property of Routing
>    Headers is important to be, indeed interface-specific, not node-
>    specific.  Consider a node with two interfaces, one public, and one
>    completely private.  Even if a private service would be bound to the
>    private interface only, one should not be able to use this private
>    service from anywhere in the Internet.
> 
>    Even the interface-locality is not bulletproof, as some addresses
>    assigned to the interface may be more private and public than others;
>    at least this way the potential harm can be minimized.
> 
>    The same zone requirement is also important (how this is observed is
>    implementation dependent; the check doesn't need to be explicit in
>    Routing Header processing) so one cannot reach e.g. link- or site-
>    local addresses through Internet.
> 
>    More fine-grained control of the two addresses could be obtained via
>    access lists if they support Routing Header processing.
> --8<--

I tend to agree with your analysis here. I do however have a problem
combining this with the discussion Ryuji and I had earlier regarding an
MN with multiple interfaces. We discussed implementation issues, like
which interface to assign the home address to. We both agreed that a
virtual interface would be best. We believed in this because a home
address should be able to make use of care-of addresses on different
interfaces and to not have it bound to a specific card that might be
removed. This view collides with your routing-header rules.

Maybe it's no big deal, the home address could be assigned to _all_
physical interfaces. Anyway, I just wanted to bring this up.

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 06:13:27 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03403
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 06:13:26 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22323;
	Thu, 18 Oct 2001 04:12:47 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18483;
	Thu, 18 Oct 2001 03:12:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IABwOI014438
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:11:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IABwXf014437
	for mobile-ip-dist; Thu, 18 Oct 2001 03:11:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IABrOI014430
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:11:54 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16373
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:11:52 -0700 (PDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21761
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 04:11:32 -0600 (MDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9IABoj04080
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:11:50 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id MAA26060; Thu, 18 Oct 2001 12:11:50 +0200
Message-ID: <3BCEAA4D.DF5685D5@era.ericsson.se>
Date: Thu, 18 Oct 2001 12:09:17 +0200
From: Mattias Pettersson <mattias.pettersson@era.ericsson.se>
Organization: Ericsson Research
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6 (fwd)
References: <Pine.LNX.4.33.0110161551280.8342-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Pekka Savola wrote:
>  - with Home Address, without BU: the route will be suboptimal, but
> mobility (connections break if MN changes IP address) will still work.
>  - with Home Address, with BU: route will be optimal and mobility works.
>  - without Home Address, without BU: the route will be optimal and
> mobility will not work

>  - without Home Address, with BU: route will be optimal but mobility will
> not work.
As a note: this is how Homeless MIPv6 (and SCTP) works. First, you
register valid addresses to use, next you can use any of them as source
address.

> >From above, the only reason why HA should be useful for a dummy node not
> implementing BU is mobility (non-breaking connections).  Is that scenario
> relevant enough to justify non-authorized HA usage?

Finally, I'd like to point out the issue of location privacy again.
Maybe have a second thought about this when we find ourselves having a
lot of problems with practically everything that has something to do
with route optimization.

Using bi-directional tunnels between MN and HA basically
+ provides location privacy
+ will work today
+ will be secure
- longer RTT
- slightly lower PMTU

What if we spend another five versions on this I-D trying to fix RO and
the luxury and then people come asking for solutions for location
hiding? Will that not kill RO anyway?

I'm sorry for sounding so negative but I see my list of advantages of
MIPv6 getting shorter for each day we learn something about security. I
don't want to underrate the work you people are doing but I think at
times one should look at things in a different light.

Why not take the tricky parts to IRTF as someone said?

/Mattias


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 06:45:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03677
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 06:45:19 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15554;
	Thu, 18 Oct 2001 03:44:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21556;
	Thu, 18 Oct 2001 03:43:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IAh5OI014559
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:43:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IAh59e014558
	for mobile-ip-dist; Thu, 18 Oct 2001 03:43:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IAh2OI014551
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:43:02 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21451
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:42:56 -0700 (PDT)
Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24295
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 03:43:02 -0700 (PDT)
Received: from piuha.net (ws4.piuha.net [195.165.196.4])
	by ws2.piuha.net (Postfix) with ESMTP id 46EA86A904
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:42:54 +0300 (EEST)
Message-ID: <3BCEB383.3090106@piuha.net>
Date: Thu, 18 Oct 2001 13:48:35 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Re: dangers of new headers (was: something else)
References: <Pine.LNX.4.33.0110181028170.23178-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola wrote:

> On Thu, 18 Oct 2001, Hesham Soliman (EPA) wrote:
> 
>> 	- an "unpiggybacked" BU with a new ext header and 
>> 	- an SCTP payload.  
>> 	Could you tell me why these two are different ?
>> 
>> 	If you drop the former then you'd drop the latter ...right ?
>> 	Sounds like a firewall that needs an upgrade. 
> 
> 
> The difference is significant.  Perhaps I can help to clarify the 
> situation.

I would like to point out of few things:

1) We propably shouldn't discuss the combination
    of a new header and piggybacking. If we keep
    piggybacking, we can pretty much live with
    the current DO model.

2) Pekka's analysis of the differences between
    BUs and SCTP is correct, but it assumes that
    a priori knowledge of the nature of the BU
    and the SCTP. I.e., they are different because
    Pekka believes one is certain to not be followed
    by more payloads, and the other one is not.
    A router that receives a packet with an unknown
    protocol number has no such knowledge! So it
    can't know all is well even for SCTP.

3) We should propably give some thought not just
    for how the BUs and their MACs are carried, but
    also for how the "weak" authentication protocols
    are carried. Some of these protocols suggest public
    key crypto operations, some protocols might be
    broken in the future and new ones developed.
    Does this point to the direction of UDP ports?
    Maybe, maybe not. Discussion would be helpful
    also on this issue. And should the BUs+MACs be
    carried in the same protocol as e.g. BAKE or
    SUCV? Or in a different protocol? Current
    proposals all seem to be BU suboptions...

Jari



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 07:10:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04032
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 07:10:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25996;
	Thu, 18 Oct 2001 04:10:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24048;
	Thu, 18 Oct 2001 04:10:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IB9KOI014708
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 04:09:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IB9JCB014707
	for mobile-ip-dist; Thu, 18 Oct 2001 04:09:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IB9FOI014700
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 04:09:15 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21749
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 04:09:16 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03701
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 04:09:16 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03887;
	Thu, 18 Oct 2001 07:09:11 -0400 (EDT)
Message-Id: <200110181109.HAA03887@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: mobile-ip@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Subject: [mobile-ip] I-D ACTION:draft-song-mobileip-mipv6-user-mobility-00.txt
Date: Thu, 18 Oct 2001 07:09:10 -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: MIPv6 IP User mobility support through DNS
	Author(s)	: J. Song, C. Chong, D. Lee
	Filename	: draft-song-mobileip-mipv6-user-mobility-00.txt
	Pages		: 17
	Date		: 17-Oct-01
	
The Mobile IP can provide IP mobility. The mobile node identified by 
its Home Address can have transparent home IP routing service 
regardless of attaching point.  However the need for the user 
mobility support has identified by wireless operators so as to 
provide IP routing service, based on the user identifier not based on 
home IP address.  This document specifies the user mobility support 
for Mobile IPv6 through DNS, while providing semi-secure binding 
update mechanism for the route optimization between MN and CN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-song-mobileip-mipv6-user-mobility-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-song-mobileip-mipv6-user-mobility-00.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-song-mobileip-mipv6-user-mobility-00.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:	<20011017113555.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-song-mobileip-mipv6-user-mobility-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-song-mobileip-mipv6-user-mobility-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 08:09:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05406
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 08:09:48 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27119;
	Thu, 18 Oct 2001 06:08:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29006;
	Thu, 18 Oct 2001 05:08:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IC7YOI014883
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:07:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IC7Yj9014882
	for mobile-ip-dist; Thu, 18 Oct 2001 05:07:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IC7VOI014875
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:07:31 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28727
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:07:26 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26305
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 06:07:12 -0600 (MDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id FAA19373 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:07:30 -0700 (MST)]
Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA13190 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:07:29 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Thu, 18 Oct 2001 05:07:26 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 396A52ED2F; Thu, 18 Oct 2001 14:02:50 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Catharina Linnea Candolin <candolin@tml.hut.fi>,
        Henrik Petander <lpetande@tml.hut.fi>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)
References: <Pine.SOL.4.10.10110161027170.1627-100000@morphine.tml.hut.fi>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 18 Oct 2001 14:07:24 +0200
In-Reply-To: <Pine.SOL.4.10.10110161027170.1627-100000@morphine.tml.hut.fi>
Message-Id: <m3u1wx883n.fsf@test9.crm.mot.com>
Lines: 17
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Henrik Petander <lpetande@tml.hut.fi> writes:
> 1) 7.3 Requirement B.4 is ambiguous. It should be ...mobile node
> SHOULD ensure the sender of the BA was authorized to send it.  Now
> the text gives the impression that MN should generally trust the
> sender, whereas MN should actually trust that the sender of the BA
> was the node to which MN sent the BU and which is authorized to send
> the BA.

Ok, I would better like to see "mobile node SHOULD ensure the Binding
Acknowledgment it receives comes from the legitimate node to which the
corresponding Binding Update has been sent".

Also, Charles proposed to use "MN should authenticated the sender of
the Binding Acknowledgment", but I feel this implies too much the use
of crypto exchanges, while other mechanisms could be used instead.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 08:18:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05783
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 08:18:51 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03280;
	Thu, 18 Oct 2001 06:18:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28244;
	Thu, 18 Oct 2001 05:18:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ICHkOI015000
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:17:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9ICHkE9014999
	for mobile-ip-dist; Thu, 18 Oct 2001 05:17:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ICHhOI014992
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:17:43 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20266
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:17:44 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02724
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 06:17:24 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9ICHf421318
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:17:41 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA11141
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:17:41 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9ICHeD71879
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:17:40 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110181217.f9ICHeD71879@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Wed, 17 Oct 2001 21:27:12 PDT.
             <3BCE5A20.9C2AE91C@iprg.nokia.com> 
Date: Thu, 18 Oct 2001 14:17:40 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   it most likely drops the packet with no alternative to this.

=> I don't believe that firewall vendors are so silly they don't
provide an extension hook for filtering of new next header/protocols...
or do you argue that SCTP is unusable because 132 is new in tables?
   
   >      Whether the new ext header is optional or not, has not
   >      been discussed.
   
   So let us discuss.. The optionality may be what one can hope in practice,
   however leaving a new header optional may lead to the problem described
   above. Secondly, an end node (CN) may send an ICMP or just drop the packet.

=> it should send an ICMP. Both an unknown option or an unknown header
should give ICMPs.

   I guess these cases all can fall back to non-route optimized traffic,
   but many CNs may end up being without route optimization.

=> I can't see a difference between options and headers for that.

   A second question is the complexity of having a new header and the old BU,
   is this a problem?
   
=> complexity is always a problem. I'd like to get only the more general
solution. BTW the IPsec issue doesn't apply only end-to-end, i.e.
a security gateway can get the same kind of problem if it is used
with a fine granularity.

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 08:32:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06290
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 08:32:10 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11029;
	Thu, 18 Oct 2001 06:30:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29630;
	Thu, 18 Oct 2001 05:31:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ICUJOI015146
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:30:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9ICUJVt015145
	for mobile-ip-dist; Thu, 18 Oct 2001 05:30:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ICUFOI015138
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:30:15 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29540
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:30:17 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28227
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:30:16 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9ICUE423245
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:30:14 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA11434
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:30:14 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9ICUED71993
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:30:14 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110181230.f9ICUED71993@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Thu, 18 Oct 2001 16:52:46 +1000.
             <4B6BC00CD15FD2119E5F0008C7A419A51308ED99@eaubrnt018.epa.ericsson.se> 
Date: Thu, 18 Oct 2001 14:30:14 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   	=> I understand your logic but I can't see the difference between
   
   	- an "unpiggybacked" BU with a new ext header and 
   	- an SCTP payload.  
   	Could you tell me why these two are different ?
   
=> a minor point: a new extension header has no benefit,
the proposal should be a new final/payload/... header
(and has no difference with SCTP).

   	=> Again I have no problem with using UDP either, but 
   	for very different reasons. 
   
=> UDP is a valid alternative, this is just a trade-off between
to involve IANA (easy according to our area director) and to reuse
Mobile IPv4 way. Personally I prefer a new final header but I can
live with UDP.

Thanks

Francis.Dupont@enst-bretagne.fr

PS: it seems we have to wait the face-to-face meeting in order to
choose between all options, doesn't it?


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 08:33:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06322
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 08:33:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12230;
	Thu, 18 Oct 2001 06:32:32 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29863;
	Thu, 18 Oct 2001 05:32:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ICW4OI015192
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:32:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9ICW4hq015190
	for mobile-ip-dist; Thu, 18 Oct 2001 05:32:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ICW0OI015177
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:32:00 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21717
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:32:01 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02154
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:32:01 -0700 (PDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id FAA05896 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:32:00 -0700 (MST)]
Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA25248 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 05:31:58 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Thu, 18 Oct 2001 05:31:56 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 6EC212ED2F; Thu, 18 Oct 2001 14:27:20 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: lpetande@tml.hut.fi, Catharina Linnea Candolin <candolin@tml.hut.fi>,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)
References: <Roam.SIMC.2.0.6.1003244044.19675.nordmark@bebop.france>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 18 Oct 2001 14:31:54 +0200
In-Reply-To: <Roam.SIMC.2.0.6.1003244044.19675.nordmark@bebop.france>
Message-Id: <m3pu7l86yt.fsf@test9.crm.mot.com>
Lines: 31
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Erik Nordmark <Erik.Nordmark@eng.sun.com> writes:
> > 1) Replay protection : MN and HA are assumed to have an existing security
> > association. If it is a manually configured shared secret, i.e., not
> > created dynamically, replay protection becomes an issue in the subnets of
> > MN and HA. Still replay protection is not mentioned in the requirements
> > and neither is replay attacks in the threats section. 
> 
> Agreed that the document should talk about replay threats.

Replay threats have been mentioned several times in the discussions.
I feel they are too generic to be treated separately in a Mobile IPv6
- specific document.

I can list 21 generic threats in computer communications (from a book)
and then find embodiments for each of them in Mobile IPv6.  Is this
what is wanted?

Take replay.  Replay of BU's only?  Why not replay of ack's?

Take repudiation.  An MN could decline to respond to Binding Requests
coming from a CN (those binding requests are sent to MN _after_ MN has
sent an initial BU, so now MN denies it has sent that initial BU:
repudiation).  What's the likely effect of this?  Probably not big
deal.  This is why it's good to quantify the realization of each
threat and then decide which of them is worth defending against and
which is not.  But it looks nobody is sensitive to this.

All we have to this point is only _rough_ evaluations to what it's
worth protecting: do no harm, no worse than current Internet, etc.

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 09:29:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09005
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 09:28:59 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20190;
	Thu, 18 Oct 2001 07:27:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28093;
	Thu, 18 Oct 2001 06:27:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IDQiOI015443
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 06:26:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IDQiN9015442
	for mobile-ip-dist; Thu, 18 Oct 2001 06:26:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IDQfOI015435
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 06:26:41 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06510
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 06:26:37 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25733
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 06:26:42 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9IDQb431397
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:26:37 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA12799
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:26:37 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9IDQbD72710
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:26:37 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110181326.f9IDQbD72710@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: Your message of Wed, 10 Oct 2001 14:15:36 EDT.
             <3BC49048.68C64687@alcatel.com> 
Date: Thu, 18 Oct 2001 15:26:37 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   This must a political way of moving drafts fast. I thought that IPv6 had
   a requirement on all IPv6 nodes to support CN functionality of MIPv6,
   and I could not locate the document that stated this!

=> requirements (for all nodes) are:
 - MUST support the home address option
 - SHOULD support CN functionality
They should be in an old proceeding (the presentation was done by
David Johnson many years ago at the IPng WG).

Regards

Francis.Dupont@enst-bretagne.fr

PS: with (*not-optional*) security it seems the best way to refuse
BUs is to refuse Mobile SA establishment attempts, doesn't it?


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 10:35:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11212
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 10:35:40 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17713;
	Thu, 18 Oct 2001 08:35:02 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19217;
	Thu, 18 Oct 2001 07:35:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IEYEOI015610
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 07:34:14 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IEYEme015609
	for mobile-ip-dist; Thu, 18 Oct 2001 07:34:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IEYAOI015602
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 07:34:10 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19069
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 07:34:05 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26804
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:58:55 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id AAA22894
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 00:33:00 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id AAA12577
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 00:34:08 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXP98G>; Fri, 19 Oct 2001 00:34:08 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED9E@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 19 Oct 2001 00:34:07 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C157E1.F14B5A30"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C157E1.F14B5A30
Content-Type: text/plain


> On Thu, 18 Oct 2001, Hesham Soliman (EPA) wrote:
> > 	- an "unpiggybacked" BU with a new ext header and 
> > 	- an SCTP payload.  
> > 	Could you tell me why these two are different ?
> > 
> > 	If you drop the former then you'd drop the latter ...right ?
> > 	Sounds like a firewall that needs an upgrade. 
> 
> The difference is significant.  Perhaps I can help to clarify the 
> situation.
> 
>  SCTP header would be like:
> 
>   IPv6 HDR - SCTP header
> 
>  BU with new Ext Header would be like (if I get this right):
> 
>   IPv6 HDR - UnknownHeaderBU - TCP/UDP/... header
> 
	=> No it's not like that. The _whole discussion was about 
	introducing a new ext header for IPsec and removing
	piggybacking. .... Please.... the 2 go hand in hand !

	Sigh 

	Hesham
>  
> 

------_=_NextPart_001_01C157E1.F14B5A30
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=2 FACE="Arial">On Thu, 18 Oct 2001, Hesham Soliman (EPA) wrote:</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - an &quot;unpiggybacked&quot; BU with a new ext header and </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - an SCTP payload.&nbsp; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Could you tell me why these two are different ?</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you drop the former then you'd drop the latter ...right ?</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sounds like a firewall that needs an upgrade. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">The difference is significant.&nbsp; Perhaps I can help to clarify the </FONT>
<BR><FONT SIZE=2 FACE="Arial">situation.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;SCTP header would be like:</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp; IPv6 HDR - SCTP header</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;BU with new Ext Header would be like (if I get this right):</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp; IPv6 HDR - UnknownHeaderBU - TCP/UDP/... header</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; No it's not like that. The _whole discussion was about </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">introducing a new ext header for IPsec and removing</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">piggybacking. .... Please.... the 2 go hand in hand !</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Sigh </FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C157E1.F14B5A30--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 10:56:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11888
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 10:56:03 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05578;
	Thu, 18 Oct 2001 08:54:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22326;
	Thu, 18 Oct 2001 07:54:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IErfOI015745
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 07:53:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IErf2A015744
	for mobile-ip-dist; Thu, 18 Oct 2001 07:53:41 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IErcOI015737
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 07:53:38 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23963
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 07:53:39 -0700 (PDT)
Received: from atlsnmx1.nextel.com (nat-167-20.nextel.com [168.73.245.70])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04054
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:53:19 -0600 (MDT)
Received: from atlntgw02.nextel.com (atlntgw02.nextel.com [10.8.79.186])
	by atlsnmx1.nextel.com (8.8.8+Sun/8.8.6) with ESMTP id KAA09322
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:53:47 -0400 (EDT)
Received: by atlntgw02.nextel.com with Internet Mail Service (5.5.2650.21)
	id <VDFM3D0T>; Thu, 18 Oct 2001 10:51:32 -0400
Message-ID: <D456C897C3DBD311816F0008C716D05107BBC192@NHQNTEX02.nextel.com>
From: "Bui, Hung" <Hung.Bui@Nextel.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
Date: Thu, 18 Oct 2001 10:53:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

1. Nextel's network uses Motorola's iDEN technology which includes support
for a
native packet service, not PPP over cellular.
2. Mobile IP is used to provide macro mobility. iDEN technology handles the
cell
to cell handover, Mobile IP is used for "Location Area" handovers as well as
inter-market roaming.
3. A standard Mobile IP home agent is used.
4. All "+" phones have Mobile IP client stack functionality built in.
5. All addressing is static.
6. The implementation is nearly standards compliant with RFC 2002, but some
modifications were made to the advertisement algorithms minimize the over
the
air traffic.
7. The service has been commercially available for over two years.

______________________________________
Hung Bui
Sr. Manager
Technology Development
NEXTEL Communications, Inc.
? desk: 703-433 8111
? mobile: 703-932 9895
? email: hung.bui@nextel.com
? text messaging: 7039329895@messaging.nextel.com
______________________________________
? The above view is of my own and may not reflect those of NEXTEL
Communications, Inc.

-----Original Message-----
From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com]
Sent: Tuesday, October 16, 2001 11:02 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Commercial deployment o Mobile IP

Along these thoughts, I was also wondering if the Mobile IP protocol is
deployed to provide
end-to-end mobility management in these systems.

With such a scanario, I was wondering what kind of bit-rates are attainable
in pedestrian and fast moving vehicular situations?

What is the proportion of administritive messages in the networks -- with
respect to scalability?

And, also what is the hand off speed?

It would also be helpful if these companies can make presentations on these
issues at MIP WG sessions.


-Sharif.

-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Tuesday, October 16, 2001 10:33 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Commercial deployment o Mobile IP


We constantly hear MIP being deployed but we have never heard of any usage
statistics, the info as you asked, etc.

Anssi Porttikivi wrote:

> I don't quite understand, what kind of system yours is. Are the some
> dual-mode handsets commercially available, that can roam from one radio
> standard/network to another (satellite, CPDP, PCS, GSM,..) based on
> Mobile IP foreign agent reachability? I doubt that! If the mobile node
> only roams within base stations / access points of your one (satellite?)
> radio network, how does it even know when to re-register its new IP
> location to the HA, and why should it in the first place?
>
> >From: Bui, Hung [mailto:Hung.Bui@Nextel.com]
> >Sent: 15. lokakuuta 2001 20:54
> >To: 'mobile-ip@sunroof.eng.sun.com'
> >Subject: RE: [mobile-ip] Commercial deployment o Mobile IP
> >
> >Our mobile IP implementation is according to RFC2002.
> >
> >This service is available nationwide, so it is available in San Diego.
> You
> >need any handset which is internet ready (the I-Plus model).
>
> >Cheers,
> >Hung

--
Behcet


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 11:19:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12563
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 11:19:20 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29036;
	Thu, 18 Oct 2001 08:19:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27284;
	Thu, 18 Oct 2001 08:18:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFHIOI015908
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IFHIHC015907
	for mobile-ip-dist; Thu, 18 Oct 2001 08:17:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFHEOI015900
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:14 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18416
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:15 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23258
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:15 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9IFEma01174
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:15:07 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAI04110;
	Thu, 18 Oct 2001 08:16:31 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08755; Thu, 18 Oct 2001 08:16:55 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15310.62055.152298.808986@thomasm-u1.cisco.com>
Date: Thu, 18 Oct 2001 08:16:55 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] WG Last Call on Threat Model and Security Require
	ments for MIP v6
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED89@eaubrnt018.epa.ericsson.se>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED89@eaubrnt018.epa.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham Soliman (EPA) writes:
 > >    Ie, the host will forward to its stack, but not
 > >    out another interface? This seems pretty consistant
 > >    with the definition of hosts and routers.
 > > 
 > 	=> Exactly ! That's why I don't see the problem here. 
 > 	In fact, this is what was done for the cellular host draft
 > 	and it certainly does not break RFC 2460. It's an internal
 > 	policy decision for those IPv6 nodes that do not want
 > 	to act as reflectors. 

   Not having looked recently, I'm not sure that
   I'd say that it's purely a policy knob on the
   host that is needed here. We should have clear
   requirements for both hosts and routers, and in
   this case the behavior of how hosts treat routing
   headers may be needed. It would be pretty unfortunate,
   for example, if hosts just didn't implement routing
   headers _at all_, which seems like a pretty likely
   outcome unless there's something that says you MUST
   if they will be forwarded to your stack...

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 11:20:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12585
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 11:20:00 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28866;
	Thu, 18 Oct 2001 08:18:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27337;
	Thu, 18 Oct 2001 08:18:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFHVOI015918
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IFHV89015917
	for mobile-ip-dist; Thu, 18 Oct 2001 08:17:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFHROI015910
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:27 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28279
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:28 -0700 (PDT)
Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27346
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:17:27 -0700 (PDT)
Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138])
	by smtpgw5.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id f9IFHPe28042;
	Thu, 18 Oct 2001 10:17:25 -0500 (CDT)
Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <4YSD2DAB>; Thu, 18 Oct 2001 10:17:25 -0500
Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B1C@pkcexv018.sprintspectrum.com>
From: "Lipford, Mark" <MLipfo01@sprintspectrum.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        charliep@iprg.nokia.com, pcalhoun@diameter.org
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Thu, 18 Oct 2001 10:17:23 -0500
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

We would like to hear a response to this question.  We are in the process of
interop testing and have run into a probllem and would also like to hear the
groups thoughts on this.

-----Original Message-----
From: Nish Abrol [mailto:nabrol@qualcomm.com]
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue for
cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the high
order byte which was already used in the MD5 calculation  be included again
as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator be
calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems  that
calculating the MD5 authenticator with the same information(high order byte)
at different locations of the payload weakens the authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.








From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 11:24:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12721
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 11:24:43 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01562;
	Thu, 18 Oct 2001 08:23:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28337;
	Thu, 18 Oct 2001 08:22:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFLaOI016078
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:21:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IFLZlT016077
	for mobile-ip-dist; Thu, 18 Oct 2001 08:21:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFLVOI016061
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:21:31 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19266
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:21:32 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28124
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:46:01 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9IFLaY25706
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:21:36 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAI04189;
	Thu, 18 Oct 2001 08:21:07 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08758; Thu, 18 Oct 2001 08:21:30 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15310.62330.590417.481111@thomasm-u1.cisco.com>
Date: Thu, 18 Oct 2001 08:21:30 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BCE47E3.A0DA7BEB@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED8A@eaubrnt018.epa.ericsson.se>
	<3BCE47E3.A0DA7BEB@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > >      But the sending node will have to know that the destination will
 > >      support this new header, else the packet is discarded.
 > > 
 > >      Especially if destination is CN, this may or may not be possible.
 > > 
 > >      => Agreed. Hence the need for a standard !
 > >      The Home Address option MUST be supported by
 > >      all IPv6 nodes. This solves your concerns.
 > >      The BU option and potentially the new ext header
 > >      SHOULD be supported .... voila.
 > 
 > If both BU and the new header are optional, header type of BU
 > is recognized, that of the new header is not. Filtering forwarders
 > not knowing these options will possibly let the BU go through (knowing
 > at least the destination header type), but they do not know the new
 > header, most likely dropping it. This may be a problem.

   This is a problem with any new protocol or well
   known port. If we are constrained by fascist firewall
   administrators, we have exactly two choices:

   1) Tunnel everything through port 80
   2) Shut down the IETF

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 11:30:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12903
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 11:30:55 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10389;
	Thu, 18 Oct 2001 09:30:17 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00239;
	Thu, 18 Oct 2001 08:30:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFTFOI016306
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:29:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IFTFkn016305
	for mobile-ip-dist; Thu, 18 Oct 2001 08:29:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFTBOI016298
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:29:11 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29921
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:29:06 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00402
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:29:12 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id BAA24327
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:28:02 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id BAA19695
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:29:10 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXP0MZ>; Fri, 19 Oct 2001 01:29:10 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDA4@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] WG Last Call on Threat Model and Security Require
	 ments for MIP v6
Date: Fri, 19 Oct 2001 01:29:09 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C157E9.A1BA9280"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C157E9.A1BA9280
Content-Type: text/plain

>  > >    Ie, the host will forward to its stack, but not
>  > >    out another interface? This seems pretty consistant
>  > >    with the definition of hosts and routers.
>  > > 
>  > 	=> Exactly ! That's why I don't see the problem here. 
>  > 	In fact, this is what was done for the cellular host draft
>  > 	and it certainly does not break RFC 2460. It's an internal
>  > 	policy decision for those IPv6 nodes that do not want
>  > 	to act as reflectors. 
> 
>    Not having looked recently, I'm not sure that
>    I'd say that it's purely a policy knob on the
>    host that is needed here. We should have clear
>    requirements for both hosts and routers, and in
>    this case the behavior of how hosts treat routing
>    headers may be needed. It would be pretty unfortunate,
>    for example, if hosts just didn't implement routing
>    headers _at all_, which seems like a pretty likely
>    outcome unless there's something that says you MUST
>    if they will be forwarded to your stack...
> 
	=> Well, I think the only MUST we need to solve 
	this issue is to have something in RFC2460 saying 
	that it MUST be possible to configure nodes to 
	avoid forwarding packets to other hosts based on a 
	routing header. Wouldn't this knob be enough and 
	satisfy MIPv6 requirements and RFC2460 ?

	Hesham

------_=_NextPart_001_01C157E9.A1BA9280
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] WG Last Call on Threat Model and Security Require ments for MIP v6</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; Ie, the host will forward to its stack, but not</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; out another interface? This seems pretty consistant</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; with the definition of hosts and routers.</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; =&gt; Exactly ! That's why I don't see the problem here. </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; In fact, this is what was done for the cellular host draft</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; and it certainly does not break RFC 2460. It's an internal</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; policy decision for those IPv6 nodes that do not want</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; to act as reflectors. </FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; Not having looked recently, I'm not sure that</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; I'd say that it's purely a policy knob on the</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; host that is needed here. We should have clear</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; requirements for both hosts and routers, and in</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; this case the behavior of how hosts treat routing</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; headers may be needed. It would be pretty unfortunate,</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; for example, if hosts just didn't implement routing</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; headers _at all_, which seems like a pretty likely</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; outcome unless there's something that says you MUST</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; if they will be forwarded to your stack...</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; Well, I think the only MUST we need to solve </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">this issue is to have something in RFC2460 saying </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">that it MUST be possible to configure nodes to </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">avoid forwarding packets to other hosts based on a </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">routing header. Wouldn't this knob be enough and </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">satisfy MIPv6 requirements and RFC2460 ?</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C157E9.A1BA9280--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 11:39:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13110
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 11:39:49 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09517;
	Thu, 18 Oct 2001 08:37:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03356;
	Thu, 18 Oct 2001 08:37:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFaVOI016454
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:36:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IFaVhK016453
	for mobile-ip-dist; Thu, 18 Oct 2001 08:36:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFaSOI016446
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:36:28 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03126
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:36:29 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16018
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:36:09 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9IFaWU27066
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:36:32 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAI04458;
	Thu, 18 Oct 2001 08:36:03 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08763; Thu, 18 Oct 2001 08:36:26 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15310.63226.407370.685539@thomasm-u1.cisco.com>
Date: Thu, 18 Oct 2001 08:36:26 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BCE6A1A.E996ED6E@iprg.nokia.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED94@eaubrnt018.epa.ericsson.se>
	<3BCE6A1A.E996ED6E@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > If not strictly 2460, a legacy firewall may have implementation
 > which lets packets with some unknown header go through, but this depends
 > really what one means by support; 

   I think that the legacy firewall is going to
   choke on the 0110 in the version field :-)
  
 > knowing it is an end header that can
 > safely be let through and having the possiblity and willingness to
 > configure letting this header through can be called filtering support
 > for the new header. I am not sure this support is always there.

   Jari,

   What you are in effect pointing out is a tautology:
   end to end suffers when there are L3 non-transparent
   boxes in the middle. This is true of all firewalls,
   and most especially application layer gateways and
   their NAT henchmen. There is really nothing we can
   do about this because the IP architecture make no
   such assumptions about translucent middle boxes. I
   would suggest that people who use these things have
   already made their deal with the devil, and that 
   it's really their problem to sort it out. If we
   want to embrace this kind of architecture, this is
   the tiniest tip of the iceberg; for starters, IP
   is a lousy architecture for an intelligent network.

 > Actually, from the other dimension of alternatives you refer to here,
 > the UDP could be a better one than a new header; it can be known to be
 > supported also by all old and new firewalls, and even by all end nodes.

   I'm sort of in favor of UDP mainly because I'm
   parsimonious about doling out new protocol numbers.
   Also, UDP inherits checksums and ECN, along with
   the advantages you point out.

		      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 11:51:31 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13348
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 11:51:30 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16712;
	Thu, 18 Oct 2001 08:50:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06318;
	Thu, 18 Oct 2001 08:47:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFl1OI016603
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:47:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IFl1kL016602
	for mobile-ip-dist; Thu, 18 Oct 2001 08:47:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFkvOI016595
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:46:57 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06077
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:46:59 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14452
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:10:56 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9IFl2Y12707
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:47:02 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAI04654;
	Thu, 18 Oct 2001 08:46:31 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08766; Thu, 18 Oct 2001 08:46:55 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15310.63855.208209.242534@thomasm-u1.cisco.com>
Date: Thu, 18 Oct 2001 08:46:55 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED9E@eaubrnt018.epa.ericsson.se>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED9E@eaubrnt018.epa.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham Soliman (EPA) writes:
 > 	=> No it's not like that. The _whole discussion was about 
 > 	introducing a new ext header for IPsec and removing
 > 	piggybacking. .... Please.... the 2 go hand in hand !

                           ^
                           |
   s/ext/final-------------+

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 11:55:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13487
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 11:55:44 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05130;
	Thu, 18 Oct 2001 09:54:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08094;
	Thu, 18 Oct 2001 08:53:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFqqOI016738
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:52:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IFqqhx016737
	for mobile-ip-dist; Thu, 18 Oct 2001 08:52:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IFqmOI016728
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:52:48 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07865
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:52:50 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02727
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:52:30 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9IFqrU09216
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 08:52:53 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAI04784;
	Thu, 18 Oct 2001 08:52:24 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08769; Thu, 18 Oct 2001 08:52:48 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15310.64208.54049.89684@thomasm-u1.cisco.com>
Date: Thu, 18 Oct 2001 08:52:48 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] WG Last Call on Threat Model and Security Require
	 ments for MIP v6
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308EDA4@eaubrnt018.epa.ericsson.se>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308EDA4@eaubrnt018.epa.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hesham Soliman (EPA) writes:
 > 	=> Well, I think the only MUST we need to solve 
 > 	this issue is to have something in RFC2460 saying 
 > 	that it MUST be possible to configure nodes to 
 > 	avoid forwarding packets to other hosts based on a 
 > 	routing header. Wouldn't this knob be enough and 
 > 	satisfy MIPv6 requirements and RFC2460 ?

   No, I think there needs to be some verbiage
   (if not already present!) that says that a
   host MUST be able to forward to itself. Otherwise
   MIP and other uses of CoA's might not be
   implemented (eg, multihoming). That would be
   unfortunate. I think this is mainly an issue
   of MUST implement. Policy knobs are always an
   option beyond that :-)

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 12:15:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14092
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 12:15:15 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00532;
	Thu, 18 Oct 2001 09:14:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14170;
	Thu, 18 Oct 2001 09:14:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGDrOI016887
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:13:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IGDrug016886
	for mobile-ip-dist; Thu, 18 Oct 2001 09:13:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGDnOI016879
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:13:49 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02772
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:13:51 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03704
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:13:49 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id CAA25543
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 02:12:30 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id CAA25480
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 02:13:38 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXP05J>; Fri, 19 Oct 2001 02:13:38 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDA6@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] WG Last Call on Threat Model and Security Require
	 ments for MIP v6
Date: Fri, 19 Oct 2001 02:13:36 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C157EF.D76734F0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C157EF.D76734F0
Content-Type: text/plain

> Hesham Soliman (EPA) writes:
>  > 	=> Well, I think the only MUST we need to solve 
>  > 	this issue is to have something in RFC2460 saying 
>  > 	that it MUST be possible to configure nodes to 
>  > 	avoid forwarding packets to other hosts based on a 
>  > 	routing header. Wouldn't this knob be enough and 
>  > 	satisfy MIPv6 requirements and RFC2460 ?
> 
>    No, I think there needs to be some verbiage
>    (if not already present!) that says that a
>    host MUST be able to forward to itself. Otherwise
>    MIP and other uses of CoA's might not be
>    implemented (eg, multihoming). That would be
>    unfortunate. I think this is mainly an issue
>    of MUST implement. Policy knobs are always an
>    option beyond that :-)
> 
	=> I guess I wanted to say the same thing but 
	you have the time difference advatange so you're
	saying it better :)
	MUST forward to itself, 
	MUST have a knob for forwarding to other nodes 
	OK ?

	hesham

------_=_NextPart_001_01C157EF.D76734F0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [mobile-ip] WG Last Call on Threat Model and Security Require ments for MIP v6</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=2 FACE="Arial">Hesham Soliman (EPA) writes:</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; =&gt; Well, I think the only MUST we need to solve </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; this issue is to have something in RFC2460 saying </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; that it MUST be possible to configure nodes to </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; avoid forwarding packets to other hosts based on a </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; routing header. Wouldn't this knob be enough and </FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &nbsp;&nbsp;&nbsp;&nbsp; satisfy MIPv6 requirements and RFC2460 ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; No, I think there needs to be some verbiage</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; (if not already present!) that says that a</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; host MUST be able to forward to itself. Otherwise</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MIP and other uses of CoA's might not be</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; implemented (eg, multihoming). That would be</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; unfortunate. I think this is mainly an issue</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; of MUST implement. Policy knobs are always an</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; option beyond that :-)</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">=&gt; I guess I wanted to say the same thing but </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">you have the time difference advatange so you're</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">saying it better :)</FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">MUST forward to itself, </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">MUST have a knob for forwarding to other nodes </FONT>
<BR><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">OK ?</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C157EF.D76734F0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 12:22:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14354
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 12:22:39 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02297;
	Thu, 18 Oct 2001 10:22:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16342;
	Thu, 18 Oct 2001 09:22:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGLaOI017000
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:21:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IGLaui016999
	for mobile-ip-dist; Thu, 18 Oct 2001 09:21:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGLVOI016992
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:21:31 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16162
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:21:32 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01259
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:21:12 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA13301
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:21:30 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 18 Oct 2001 11:19:50 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L594F>; Thu, 18 Oct 2001 11:20:46 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E75BDBA@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 18 Oct 2001 11:20:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C157F0.D934D390"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C157F0.D934D390
Content-Type: text/plain;
	charset="iso-8859-1"

Francis,

>    Do you believe there might ever be a need to send a 
> binding update in the
>    same packet as an RSVP or something similar message?
>    
> => I don't fully understand your question but:
>  - I really believe that piggybacking is a bad idea

GM] I'm not so sure. I will try to explain why below.

>  - if your example is RSVP because of the router alert option in
>    a hop-by-hop header, a BU as a (final) destination option should
>    be processed correctly (i.e. the whole extension skipped) by every
>    intermediate routers

GM] My example is RSVP because I think RSVP would have to know about the
binding in order to operate properly. If you get rid of piggybacking you
have pretty much nuked the non-vertical solution and will force solutions
that put address bindings in RSVP (i.e. vertical).

GM] Piggybacking seems to allow both the vertical model and horizontal
models. I.e. I can still do RSVP without mobility and I can still do
mobility without RSVP and with piggybacking I can do both in a synergistic
manner.

GM] I don't think that the RSVP processing would operate correctly if it we
not aware of the address binding. 

This brings up another point; namely, that it is highly likely that the
credentials used by an MN for the SAs of RSVP on the first hop would be
exactly the same as the credentials for MIP binding updates. I think it
would be pointless to include two sets of credentials and/or digests in the
same packet and perhaps even do integrity checks twice in some
implementations.

And this brings up my final point - perhaps MIP BU integrity checking and
mechanisms should be more like the trust model used with RSVP and active
networks. If RSVP bandwidth/DS signalling (not int-serv) integrity works and
scales then MIP integrity should work and scale. If MIP was changed to begin
using the router alert then the authentication objects of RSVP might be able
to be re-used as a new common h-b-h header that could be used by many tools
and network-layer service functions.



>  - the burden is not so high (when you put a hop-by-hop extension,
>    you definitely ask for the slow and hard path :-)

I think it is just a matter of time before someone starts saying let's use
RSVP signaling for route optimized macro mobility. I'd prefer to use both
pre-existing works as best we can to come up with a good horizontal
solution.

I'm just trying to get people to look ahead a bit in their proposed
solutions to realize the ramifications. I would like it all (layer 5, MIP,
RSVP) to work together and be a clean unencumbered design that function
synergisticly to acheive (personal mobility, network node mobility and
network resource signaling). Killing piggybacking seems to me to be in the
wrong direction for this goal.


Regards,


Glenn 

------_=_NextPart_001_01C157F0.D934D390
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Francis,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Do you believe there might =
ever be a need to send a </FONT>
<BR><FONT SIZE=3D2>&gt; binding update in the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; same packet as an RSVP or =
something similar message?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =3D&gt; I don't fully understand your question =
but:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - I really believe that piggybacking is a =
bad idea</FONT>
</P>

<P><FONT SIZE=3D2>GM] I'm not so sure. I will try to explain why =
below.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; - if your example is RSVP because of the =
router alert option in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; a hop-by-hop header, a BU as =
a (final) destination option should</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; be processed correctly (i.e. =
the whole extension skipped) by every</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; intermediate routers</FONT>
</P>

<P><FONT SIZE=3D2>GM] My example is RSVP because I think RSVP would =
have to know about the binding in order to operate properly. If you get =
rid of piggybacking you have pretty much nuked the non-vertical =
solution and will force solutions that put address bindings in RSVP =
(i.e. vertical).</FONT></P>

<P><FONT SIZE=3D2>GM] Piggybacking seems to allow both the vertical =
model and horizontal models. I.e. I can still do RSVP without mobility =
and I can still do mobility without RSVP and with piggybacking I can do =
both in a synergistic manner.</FONT></P>

<P><FONT SIZE=3D2>GM] I don't think that the RSVP processing would =
operate correctly if it we not aware of the address binding. </FONT>
</P>

<P><FONT SIZE=3D2>This brings up another point; namely, that it is =
highly likely that the credentials used by an MN for the SAs of RSVP on =
the first hop would be exactly the same as the credentials for MIP =
binding updates. I think it would be pointless to include two sets of =
credentials and/or digests in the same packet and perhaps even do =
integrity checks twice in some implementations.</FONT></P>

<P><FONT SIZE=3D2>And this brings up my final point - perhaps MIP BU =
integrity checking and mechanisms should be more like the trust model =
used with RSVP and active networks. If RSVP bandwidth/DS signalling =
(not int-serv) integrity works and scales then MIP integrity should =
work and scale. If MIP was changed to begin using the router alert then =
the authentication objects of RSVP might be able to be re-used as a new =
common h-b-h header that could be used by many tools and network-layer =
service functions.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;&nbsp; - the burden is not so high (when you put =
a hop-by-hop extension,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; you definitely ask for the =
slow and hard path :-)</FONT>
</P>

<P><FONT SIZE=3D2>I think it is just a matter of time before someone =
starts saying let's use RSVP signaling for route optimized macro =
mobility. I'd prefer to use both pre-existing works as best we can to =
come up with a good horizontal solution.</FONT></P>

<P><FONT SIZE=3D2>I'm just trying to get people to look ahead a bit in =
their proposed solutions to realize the ramifications. I would like it =
all (layer 5, MIP, RSVP) to work together and be a clean unencumbered =
design that function synergisticly to acheive (personal mobility, =
network node mobility and network resource signaling). Killing =
piggybacking seems to me to be in the wrong direction for this =
goal.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Glenn </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C157F0.D934D390--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 12:33:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14611
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 12:33:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11657;
	Thu, 18 Oct 2001 10:32:24 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18840;
	Thu, 18 Oct 2001 09:32:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGVcOI017114
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:31:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IGVcZv017113
	for mobile-ip-dist; Thu, 18 Oct 2001 09:31:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGVZOI017106
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:31:35 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13644
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:31:26 -0700 (PDT)
Received: from web13902.mail.yahoo.com (web13902.mail.yahoo.com [216.136.175.28])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA13397
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:56:13 -0600 (MDT)
Message-ID: <20011018163130.96932.qmail@web13902.mail.yahoo.com>
Received: from [216.98.102.225] by web13902.mail.yahoo.com via HTTP; Thu, 18 Oct 2001 09:31:30 PDT
Date: Thu, 18 Oct 2001 09:31:30 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof  fs-v4-02.txt
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: <795A014AF92DD21182AF0008C7A404320C5205C4@esealnt117>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Karim,


> I think there's only one issue left. Two of your
> comments below say that a low bandwidth channel on
> which there is real time traffic cannot be used by
> a MN to send Mobile IP signalling without disrupting
> its communication.

The comments were not meant to imply that such a
channel cannot be used for signalling, just that IF
such a situation exists, THEN HTT provides a solution
and SHOULD be implemented. It is the same situation as
with a radio protocol that allows fast movement.

 This assumes a few things:
> 
> - that the MIP signalling takes up significant
> bandwidth
>   and disrupts real time traffic
> - that there is not enough extra bandwidth for the
>   MIP signalling on that channel
> - that there is no reserved signalling bandwidth or
>   dedicated signalling channel.
> 
> Don't think these are assumptions we should rely on.

Please see my posting earlier this year, in which
calculations for low bandwidth channels of the
overhead introduced by MIP signalling run upwards
of 100 ms or more. This would be enough to introduce a
noticable disruption in voice traffic. The assumptions
are based on calculated channel blocking times, and
are not completely groundless. I can repost the
numbers if you want, or you can check the archive for
yourself.

> If we talk about real-time and channel access we
> need to
> consider QoS, radio realisations etc. but this is
> complex and varies between wireless systems. I'd
> prefer
> if we kept low latency generic and left this work
> for
> the radio network implementors.
> 

I don't think any of this is necessary. One simply has
to look at how big the signaling messages are, how
fast the channel is, and how long the L2 handover
latency is. If the sum of the latency due to L3
signaling and L2 handover exceeds user perception,
then there will be a glitch. QoS doesn't figure
because the channel is low bandwidth and cannot be
expanded, as is the case for 3GPP2 voice traffic I
believe, but the change in the spec I sent in the
previous message was explicitly limited to such
situations. As for radio realizations, I agree that
will have an effect, but, again, the text was
explicitly limited to cases where the radio protocol
required it, just as for the case where fast movement
would require HTT.

So I still maintain that there needs to be a sentence
saying that a radio protocol with a fixed low
bandwidth SHOULD implement HTT if it wants to maintain
good quality multimedia traffic.


                    jak


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 12:38:36 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14688
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 12:38:36 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12420;
	Thu, 18 Oct 2001 09:37:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14778;
	Thu, 18 Oct 2001 09:36:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGZqOI017202
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:35:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IGZpCQ017201
	for mobile-ip-dist; Thu, 18 Oct 2001 09:35:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGZmOI017194
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:35:48 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14672
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 09:35:44 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14479
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:35:30 -0600 (MDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA04040
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:35:49 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9IGZnC06436
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:35:49 -0500 (CDT)
Message-ID: <3BCF0660.61F6DA1D@alcatel.com>
Date: Thu, 18 Oct 2001 11:42:08 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75BDBA@zrc2c012.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------65F03D58D30D262778B50819"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------65F03D58D30D262778B50819
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Glenn,
  I read your long email, talking about vertical and horizontal
solutions. I do not quite get what you are referring to (any drafts,
RFCs, books, papers, etc)?
  A simple question: you are saying that RSVP would not work with MIPv4,
aren't you?
  BTW, QoS issues to my knowledge will go to NSIS WG yet to be formed.
Regards,

Glenn Morrow wrote:

>
>
> Francis,
>
> >    Do you believe there might ever be a need to send a
> > binding update in the
> >    same packet as an RSVP or something similar message?
> >
> > => I don't fully understand your question but:
> >  - I really believe that piggybacking is a bad idea
>
> GM] I'm not so sure. I will try to explain why below.
>
> >  - if your example is RSVP because of the router alert option in
> >    a hop-by-hop header, a BU as a (final) destination option should
> >    be processed correctly (i.e. the whole extension skipped) by
> every
> >    intermediate routers
>
> GM] My example is RSVP because I think RSVP would have to know about
> the binding in order to operate properly. If you get rid of
> piggybacking you have pretty much nuked the non-vertical solution and
> will force solutions that put address bindings in RSVP (i.e.
> vertical).
>
> GM] Piggybacking seems to allow both the vertical model and horizontal
> models. I.e. I can still do RSVP without mobility and I can still do
> mobility without RSVP and with piggybacking I can do both in a
> synergistic manner.
>
> GM] I don't think that the RSVP processing would operate correctly if
> it we not aware of the address binding.
>
> This brings up another point; namely, that it is highly likely that
> the credentials used by an MN for the SAs of RSVP on the first hop
> would be exactly the same as the credentials for MIP binding updates.
> I think it would be pointless to include two sets of credentials
> and/or digests in the same packet and perhaps even do integrity checks
> twice in some implementations.
>
> And this brings up my final point - perhaps MIP BU integrity checking
> and mechanisms should be more like the trust model used with RSVP and
> active networks. If RSVP bandwidth/DS signalling (not int-serv)
> integrity works and scales then MIP integrity should work and scale.
> If MIP was changed to begin using the router alert then the
> authentication objects of RSVP might be able to be re-used as a new
> common h-b-h header that could be used by many tools and network-layer
> service functions.
>
>
> >  - the burden is not so high (when you put a hop-by-hop extension,
> >    you definitely ask for the slow and hard path :-)
>
> I think it is just a matter of time before someone starts saying let's
> use RSVP signaling for route optimized macro mobility. I'd prefer to
> use both pre-existing works as best we can to come up with a good
> horizontal solution.
>
> I'm just trying to get people to look ahead a bit in their proposed
> solutions to realize the ramifications. I would like it all (layer 5,
> MIP, RSVP) to work together and be a clean unencumbered design that
> function synergisticly to acheive (personal mobility, network node
> mobility and network resource signaling). Killing piggybacking seems
> to me to be in the wrong direction for this goal.
>
> Regards,
>
> Glenn

--
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S CTO2
1201 E. Campbell Rd.
Richardson, TX 75081-1936 USA
Email : behcet.sarikaya@alcatel.com
Phone : (972) 996-5075 Fax : (972) 996-5174


--------------65F03D58D30D262778B50819
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Glenn,
<br>&nbsp; I read your long email, talking about vertical and horizontal
solutions. I do not quite get what you are referring to (any drafts, RFCs,
books, papers, etc)?
<br>&nbsp; A simple question: you are saying that RSVP would not work with
MIPv4, aren't you?
<br>&nbsp; BTW, QoS issues to my knowledge will go to NSIS WG yet to be
formed.
<br>Regards,
<p>Glenn Morrow wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>Francis,</font>
<p><font size=-1>>&nbsp;&nbsp;&nbsp; Do you believe there might ever be
a need to send a</font>
<br><font size=-1>> binding update in the</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp; same packet as an RSVP or something
similar message?</font>
<br><font size=-1>></font>
<br><font size=-1>> => I don't fully understand your question but:</font>
<br><font size=-1>>&nbsp; - I really believe that piggybacking is a bad
idea</font>
<p><font size=-1>GM] I'm not so sure. I will try to explain why below.</font>
<p><font size=-1>>&nbsp; - if your example is RSVP because of the router
alert option in</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp; a hop-by-hop header, a BU as a (final)
destination option should</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp; be processed correctly (i.e. the
whole extension skipped) by every</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp; intermediate routers</font>
<p><font size=-1>GM] My example is RSVP because I think RSVP would have
to know about the binding in order to operate properly. If you get rid
of piggybacking you have pretty much nuked the non-vertical solution and
will force solutions that put address bindings in RSVP (i.e. vertical).</font>
<p><font size=-1>GM] Piggybacking seems to allow both the vertical model
and horizontal models. I.e. I can still do RSVP without mobility and I
can still do mobility without RSVP and with piggybacking I can do both
in a synergistic manner.</font>
<p><font size=-1>GM] I don't think that the RSVP processing would operate
correctly if it we not aware of the address binding.</font>
<p><font size=-1>This brings up another point; namely, that it is highly
likely that the credentials used by an MN for the SAs of RSVP on the first
hop would be exactly the same as the credentials for MIP binding updates.
I think it would be pointless to include two sets of credentials and/or
digests in the same packet and perhaps even do integrity checks twice in
some implementations.</font>
<p><font size=-1>And this brings up my final point - perhaps MIP BU integrity
checking and mechanisms should be more like the trust model used with RSVP
and active networks. If RSVP bandwidth/DS signalling (not int-serv) integrity
works and scales then MIP integrity should work and scale. If MIP was changed
to begin using the router alert then the authentication objects of RSVP
might be able to be re-used as a new common h-b-h header that could be
used by many tools and network-layer service functions.</font>
<br>&nbsp;
<p><font size=-1>>&nbsp; - the burden is not so high (when you put a hop-by-hop
extension,</font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp; you definitely ask for the slow and
hard path :-)</font>
<p><font size=-1>I think it is just a matter of time before someone starts
saying let's use RSVP signaling for route optimized macro mobility. I'd
prefer to use both pre-existing works as best we can to come up with a
good horizontal solution.</font>
<p><font size=-1>I'm just trying to get people to look ahead a bit in their
proposed solutions to realize the ramifications. I would like it all (layer
5, MIP, RSVP) to work together and be a clean unencumbered design that
function synergisticly to acheive (personal mobility, network node mobility
and network resource signaling). Killing piggybacking seems to me to be
in the wrong direction for this goal.</font>
<p><font size=-1>Regards,</font>
<p><font size=-1>Glenn</font></blockquote>

<p>--
<br>Behcet Sarikaya
<br>Network Strategy Group, Mobile Networking Team
<br>Alcatel USA M/S CTO2
<br>1201 E. Campbell Rd.
<br>Richardson, TX 75081-1936 USA
<br>Email : behcet.sarikaya@alcatel.com
<br>Phone : (972) 996-5075 Fax : (972) 996-5174
<br>&nbsp;</html>

--------------65F03D58D30D262778B50819--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 13:05:04 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15423
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 13:05:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27215;
	Thu, 18 Oct 2001 10:03:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21523;
	Thu, 18 Oct 2001 10:01:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IH0MOI017411
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:00:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IH0K6M017410
	for mobile-ip-dist; Thu, 18 Oct 2001 10:00:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IH0HOI017403
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:00:17 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26471
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:00:19 -0700 (PDT)
Received: from web13906.mail.yahoo.com (web13906.mail.yahoo.com [216.136.175.69])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA24931
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:00:19 -0700 (PDT)
Message-ID: <20011018170019.9642.qmail@web13906.mail.yahoo.com>
Received: from [216.98.102.225] by web13906.mail.yahoo.com via HTTP; Thu, 18 Oct 2001 10:00:19 PDT
Date: Thu, 18 Oct 2001 10:00:19 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi folks,

I have not been following this discussion very closely
but several people here at DoCoMo Labs have and they
have requested I post comments on the document.
Apologies if this note duplicates comments from
others.

In general, the document seems very heavily weighed
towards MN/CN security threats and very lightly
weighted towards MN/AR threats. Some of the MN/CN
threats are redundant. There are 18 threats
identified for the MN/CN and only two for the MN/AR.
This is perhaps understandable, given the attention
the IETF security folks have been focussing on the BU
security problem, but the MN/AR relationship is, in
some sense, equally if not more important (it is, for
example, a MUST and not a SHOULD).

The particular threats that we feel need to be added
are the following:

1) A malicious AR could hijack traffic from a trusting
MN. This was partially identified in the document.

2) A theaving MN could gain network access without
authorization by soliciting a Router Advert, then
setting up a CoA.

3) Similar to 2), a theaving MN could gain network
access without authorization through responding to an
unsolicited Router Advert, then setting up a CoA.

There are a variety of places within the process of
network access where these threats could be addressed,
but I assume since this document is concerned with
threat analysis, the solutions will be in another
document.

                 jak


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 13:39:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16432
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 13:39:38 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15508;
	Thu, 18 Oct 2001 10:39:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21874;
	Thu, 18 Oct 2001 10:37:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IHb2OI017581
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:37:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IHb1f4017580
	for mobile-ip-dist; Thu, 18 Oct 2001 10:37:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IHawOI017573
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:36:58 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21706
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:37:01 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13625
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:36:40 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9IHaw026852
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 20:36:58 +0300
Date: Thu, 18 Oct 2001 20:36:57 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Last Call Comments on
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
In-Reply-To: <20011018170019.9642.qmail@web13906.mail.yahoo.com>
Message-ID: <Pine.LNX.4.33.0110182031040.26685-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 18 Oct 2001, James Kempf wrote:
> In general, the document seems very heavily weighed
> towards MN/CN security threats and very lightly
> weighted towards MN/AR threats. Some of the MN/CN
> threats are redundant. There are 18 threats
> identified for the MN/CN and only two for the MN/AR.
> This is perhaps understandable, given the attention
> the IETF security folks have been focussing on the BU
> security problem, but the MN/AR relationship is, in
> some sense, equally if not more important (it is, for
> example, a MUST and not a SHOULD).

I'm not sure if 'AR' means 'Access Router', but assuming so..

Hmm?

Am I mistaken but from the draft:
--8<--
   The goal is to determine which of those threats are of concern and
   should be defended against.  While the basic goal is "no worse than
   IPv4," the prevalence of wireless and the likely deployment of MIPv6
   in that space means the basic goal should aim at being "no worse than
   IPv4 with switched Ethernets", although the intent is not to try to
   solve the security problems of shared/broadcast wireless mediums.
   The threat model is used to generate a list of requirements to make
   the MIPv6 protocol secure against likely threats. These requirements,
   interspersed with the threats and also listed at the end of this
   document are aimed at providing guidelines in developing a solution
   for MIPv6 security.
--8<--

Based on this:

> 1) A malicious AR could hijack traffic from a trusting
> MN. This was partially identified in the document.

This is no different from any secure IPv4/6 environment.  If you don't use
AH/ESP or equivalent, any upstream router can do that.  This is not in the
scope of MIPv6, I think.

> 2) A theaving MN could gain network access without
> authorization by soliciting a Router Advert, then
> setting up a CoA.
> 
> 3) Similar to 2), a theaving MN could gain network
> access without authorization through responding to an
> unsolicited Router Advert, then setting up a CoA.

This is no different from IPv6; it doesn't provide access controls on who 
can or can not autoconfigure an address and use it.

One should assume that if you can phycially get into a LAN, WLAN, a cell, 
... or whatever, you're authorized to use the network.

So these may also be outside of the scope.



One _could_ list a few "known" issues in the draft, of course.  (About 
one-two lines per non-issue).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 13:48:57 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16662
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 13:48:57 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20068;
	Thu, 18 Oct 2001 10:48:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24965;
	Thu, 18 Oct 2001 10:47:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IHl3OI017686
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:47:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IHl3RM017685
	for mobile-ip-dist; Thu, 18 Oct 2001 10:47:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IHl0OI017678
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:47:00 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24672
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:47:00 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23382
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 10:47:00 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28397;
	Thu, 18 Oct 2001 10:47:00 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9IHkx618038;
	Thu, 18 Oct 2001 10:46:59 -0700
X-mProtect:  Thu, 18 Oct 2001 10:46:59 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdowts87; Thu, 18 Oct 2001 10:46:57 PDT
Message-ID: <3BCF1592.110B1B9F@iprg.nokia.com>
Date: Thu, 18 Oct 2001 10:46:58 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hesham Soliman (EPA)" <Hesham.Soliman@ERICSSON.COM.AU>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements 
 for MIP v6
References: <4B6BC00CD15FD2119E5F0008C7A419A51308EDA6@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Hesham,

>         No, I think there needs to be some verbiage
>         (if not already present!) that says that a
>         host MUST be able to forward to itself. Otherwise
>         MIP and other uses of CoA's might not be
>         implemented (eg, multihoming). That would be
>         unfortunate. I think this is mainly an issue
>         of MUST implement. Policy knobs are always an
>         option beyond that :-)
> 
>      => I guess I wanted to say the same thing but
>      you have the time difference advatange so you're
>      saying it better :)
>      MUST forward to itself,
>      MUST have a knob for forwarding to other nodes
>      OK ?

I tried to point out in a note last night that it is enough
for relay nodes to follow directives about forwarding to
the next node in the list.  In the case needed for Mobile IPv6,
this is simple.  A node can authorize itself to forward
packets to itself.  In the general case, more persuasion
may be needed, but the principle would remain the same.

OK?

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 14:03:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16989
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 14:03:58 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10175;
	Thu, 18 Oct 2001 12:03:26 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29363;
	Thu, 18 Oct 2001 11:03:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9II2qOI017902
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:02:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9II2q9u017901
	for mobile-ip-dist; Thu, 18 Oct 2001 11:02:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9II2nOI017894
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:02:49 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13418
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:02:50 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07356
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:02:48 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9II2j427011
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:02:45 +0300
Date: Thu, 18 Oct 2001 21:02:45 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Re: dangers of new headers (was: something else)
In-Reply-To: <3BCEB383.3090106@piuha.net>
Message-ID: <Pine.LNX.4.33.0110182101170.26862-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 18 Oct 2001, Jari Arkko wrote:
> 2) Pekka's analysis of the differences between
>     BUs and SCTP is correct, but it assumes that
>     a priori knowledge of the nature of the BU
>     and the SCTP. I.e., they are different because
>     Pekka believes one is certain to not be followed
>     by more payloads, and the other one is not.
>     A router that receives a packet with an unknown
>     protocol number has no such knowledge! So it
>     can't know all is well even for SCTP.

The router could have a list of known payload headers, which it knows are 
always final, but doesn't have an idea how to process.

So identification is at least theoretically possible (to some extent), but 
not so probable.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 14:06:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17062
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 14:06:18 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29276;
	Thu, 18 Oct 2001 11:04:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28986;
	Thu, 18 Oct 2001 11:01:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9II16OI017840
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:01:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9II15ac017839
	for mobile-ip-dist; Thu, 18 Oct 2001 11:01:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9II12OI017832
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:01:02 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00088
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:01:03 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09275
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:26:17 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9II0w326997
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:00:58 +0300
Date: Thu, 18 Oct 2001 21:00:57 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
In-Reply-To: <3BCEA53F.EBC991BC@era.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110182059310.26862-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 18 Oct 2001, Mattias Pettersson wrote:
> I tend to agree with your analysis here. I do however have a problem
> combining this with the discussion Ryuji and I had earlier regarding an
> MN with multiple interfaces. We discussed implementation issues, like
> which interface to assign the home address to. We both agreed that a
> virtual interface would be best. We believed in this because a home
> address should be able to make use of care-of addresses on different
> interfaces and to not have it bound to a specific card that might be
> removed. This view collides with your routing-header rules.
> 
> Maybe it's no big deal, the home address could be assigned to _all_
> physical interfaces. Anyway, I just wanted to bring this up.

Yes, I had thought of this.  I took it as too implementation-specific 
issue ("logical interface" or "a feature of a physical interface") to 
mention it.  Perhaps I should add a note there.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 14:20:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17454
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 14:19:59 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05150;
	Thu, 18 Oct 2001 11:15:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02901;
	Thu, 18 Oct 2001 11:15:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIEQOI018144
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:14:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IIEQds018143
	for mobile-ip-dist; Thu, 18 Oct 2001 11:14:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIEMOI018136
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:14:22 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03960
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:14:23 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20486
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:14:03 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA29762;
	Thu, 18 Oct 2001 11:00:24 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9II0Nw20530;
	Thu, 18 Oct 2001 11:00:23 -0700
X-mProtect:  Thu, 18 Oct 2001 11:00:23 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdwu5dLJ; Thu, 18 Oct 2001 11:00:21 PDT
Message-ID: <3BCF18B5.50A5D6D6@iprg.nokia.com>
Date: Thu, 18 Oct 2001 11:00:21 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: Glenn Morrow <gmorrow@nortelnetworks.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E5D9AC7@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello folks,

Glenn Morrow said something which has resonated with me during
the last week.

> I guess people just don't agree on the value of piggybacking, the affect of
> delays incurred by segmentation and whether the access network should drive
> the IP definitions or the access networks should adapt to the IP definitions.

This seems to hit the spot exactly.  We have disagreements, but I would
like to suggest that we should make the IP definitions based on what's
good for IP instead of the restrictions imposed by the unadapted access
networks (or, worse yet, the least common denominator of all access
networks!).

Applied to the discussion about whether Binding Update should be carried
along with payload, this would mean that we should have the feature if
it fits naturally in IP, and if there are going to be networks which can
use the feature to good advantage.  The reasons why this feature are
advantageous are outlined in the draft from Jari Arkko, along with the
costs of the feature.  Some networks will gladly pay the cost, and some
won't, for a myriad of reasons.

I am very much in favor of making the best IP definition, and along the
way making sure that it can be used to fit well with existing access
networks.  The current proposal with Destination Options does do that.
There is no requirement that any implementation MUST supply payload
in packets that contain a Binding Update, and almost all of the
complication from processing payload with a Destination Option comes
on the sending side.  So I don't agree with arguments based on the
extra complexity.  If some implementations don't want to undertake
the extra complexity, that is fine, but those groups should not be
allowed to penalize the implementations that wish to offer the better
performance by the magic of making it illegal to do so.  That is not
fair in my book.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 14:20:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17474
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 14:20:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07183;
	Thu, 18 Oct 2001 11:19:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00549;
	Thu, 18 Oct 2001 11:07:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9II6dOI018024
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:06:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9II6dHG018023
	for mobile-ip-dist; Thu, 18 Oct 2001 11:06:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9II6ZOI018013
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:06:35 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10266
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:06:30 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06033
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:06:32 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9II6UO27059
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:06:31 +0300
Date: Thu, 18 Oct 2001 21:06:30 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED9E@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110182104130.26862-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Fri, 19 Oct 2001, Hesham Soliman (EPA) wrote:
> > On Thu, 18 Oct 2001, Hesham Soliman (EPA) wrote:
> > > 	- an "unpiggybacked" BU with a new ext header and 
> > > 	- an SCTP payload.  
> > > 	Could you tell me why these two are different ?
> > > 
> > > 	If you drop the former then you'd drop the latter ...right ?
> > > 	Sounds like a firewall that needs an upgrade. 
> > 
> > The difference is significant.  Perhaps I can help to clarify the 
> > situation.
> > 
> >  SCTP header would be like:
> > 
> >   IPv6 HDR - SCTP header
> > 
> >  BU with new Ext Header would be like (if I get this right):
> > 
> >   IPv6 HDR - UnknownHeaderBU - TCP/UDP/... header
> > 
> 	=> No it's not like that. The _whole discussion was about 
> 	introducing a new ext header for IPsec and removing
> 	piggybacking. .... Please.... the 2 go hand in hand !

Sorry, I didn't know what you meant, exactly, with:

'an "unpiggybacked" BU with a new ext header'

I took this as a BU dst option moved to a new, non-final extention header.  
If this would have been the case, my discussion would have applied.  
Perhaps you meant something else (a final BU ext header).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 14:21:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17498
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 14:21:43 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26354;
	Thu, 18 Oct 2001 12:20:28 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05950;
	Thu, 18 Oct 2001 11:20:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIJMOI018254
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:19:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IIJMRN018253
	for mobile-ip-dist; Thu, 18 Oct 2001 11:19:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIJJOI018246
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:19:19 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05509
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:19:20 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24782
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:18:59 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9IIJHA27137
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:19:17 +0300
Date: Thu, 18 Oct 2001 21:19:16 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements
  for MIP v6
In-Reply-To: <3BCF1592.110B1B9F@iprg.nokia.com>
Message-ID: <Pine.LNX.4.33.0110182108360.26862-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 18 Oct 2001, Charles E. Perkins wrote:
> >      => I guess I wanted to say the same thing but
> >      you have the time difference advatange so you're
> >      saying it better :)
> >      MUST forward to itself,
> >      MUST have a knob for forwarding to other nodes
> >      OK ?
> 
> I tried to point out in a note last night that it is enough
> for relay nodes to follow directives about forwarding to
> the next node in the list.  In the case needed for Mobile IPv6,
> this is simple.  A node can authorize itself to forward
> packets to itself.  In the general case, more persuasion
> may be needed, but the principle would remain the same.

I just had an idea which might be used to "authenticate" this for _hosts_:

if segments left == 1
 if both addresses are assigned on the node (possibly on the same interface)
  if both addresses are of the same zone (e.g. no global->site/link)
    if there exists a /128 host route to the to-be-swapped address
      assume forwarding to it is allowed

Of course, this would be only one, implementation-dependant way of showing 
this "trust".

Host route inside a node _could_ be something that could be easily used --
MIPv6 could set one up for Home Address no problems.

Thoughts?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 14:55:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17994
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 14:55:31 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28249;
	Thu, 18 Oct 2001 12:54:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15328;
	Thu, 18 Oct 2001 11:55:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIraOI018658
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IIraqm018657
	for mobile-ip-dist; Thu, 18 Oct 2001 11:53:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIrWOI018650
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:32 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27054
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:34 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04420
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:32 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA04988;
	Thu, 18 Oct 2001 11:53:30 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9IIrUw12584;
	Thu, 18 Oct 2001 11:53:30 -0700
X-mProtect:  Thu, 18 Oct 2001 11:53:30 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdZzAQ1z; Thu, 18 Oct 2001 11:53:28 PDT
Message-ID: <3BCF2528.C8C97AC9@iprg.nokia.com>
Date: Thu, 18 Oct 2001 11:53:28 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110182108360.26862-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Pekka Savola wrote (>), in response to my suggestion (>>):

>> I tried to point out in a note last night that it is enough
>> for relay nodes to follow directives about forwarding to
>> the next node in the list.  In the case needed for Mobile IPv6,
>> this is simple.  A node can authorize itself to forward
>> packets to itself.  In the general case, more persuasion
>> may be needed, but the principle would remain the same.
> 
> I just had an idea which might be used to "authenticate" this for _hosts_:
> 
> if segments left == 1
>  if both addresses are assigned on the node (possibly on the same interface)
>   if both addresses are of the same zone (e.g. no global->site/link)
>     if there exists a /128 host route to the to-be-swapped address
>       assume forwarding to it is allowed
> 
> Of course, this would be only one, implementation-dependant way of showing
> this "trust".

What you are describing is a rule for forwarding a routing header
along paths inside a single host.  I'm trying to get at it from a
somewhat different angle, as follows.

Suppose there is a protocol by which the following state is inserted
at a forwarding node (host or router):
- If my address is in a routing header, and I am requested to forward
  the packet to a _particular_ next address when it arrives with my
  address in the routing header, I will agree to do so.

This has to be done individually for all such "next addresses" that
might show up in a routing header.  Agreement to forward to one
particular next address doesn't imply full agreement for all possible
next addresses, or even for any other next address at all.

I like this rule.  The point is that you can't just forward blindly,
but only after agreement by way of some protocol which essentially
does the setup.

For mobile nodes, there's nothing to do except for keeping track of
its own addresses, which is appropriate for this case.  The act of
disseminating the Binding Update can be viewed, in this context, as
"advertising" a mobile node's (internal) agreement to forward packets
to its home address.  This does not at all mean that the mobile node
agrees to act as a forwarding node for all possible routing headers.

> Host route inside a node _could_ be something that could be easily used --
> MIPv6 could set one up for Home Address no problems.

I agree it could be done inside a mobile node by way of an explicit
host route, but I don't think that has to be put into the Mobile IPv6
specification.  There are other ways to do it that have the same
external effect.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 14:56:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18017
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 14:56:17 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28255;
	Thu, 18 Oct 2001 12:55:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15334;
	Thu, 18 Oct 2001 11:55:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIrrOI018675
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IIrrp1018674
	for mobile-ip-dist; Thu, 18 Oct 2001 11:53:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIrmOI018660
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:48 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12401
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:49 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06030
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 11:53:48 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9IIrk419164
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 20:53:46 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA20492
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 20:53:46 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9IIrjD74789
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 20:53:45 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110181853.f9IIrjD74789@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 
In-reply-to: Your message of Mon, 15 Oct 2001 20:35:04 +0300.
             <Pine.LNX.4.33.0110152002340.1930-100000@netcore.fi> 
Date: Thu, 18 Oct 2001 20:53:45 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   Thus MIPv6 is "responsible" for this behaviour (ie: security of
   home address option).
   
=> is H.3 enough for you (I've privately sent a comment about this
and I'll resend it if the thread doesn't give a solution I like) ?
BTW I agree this is a MIPv6 issue.

   This was discussed (rather duologous conversation between me and Francis 
   Dupont) on ipng last month under subject "Routing Header Considered 
   Harmful".
   
=> my opinion is there should be a knob about host behavior and
the default should be "don't forward a packet with a routing header
outside of the node". This closes the security issue and works with
mobile hosts. The problem is more that the issue is an IPv6 WG one
(again I'll look at further in the thread, I've seen Eric Nordmark's
name so I believe I've just to find time :-).

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 15:13:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18260
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 15:13:57 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14942;
	Thu, 18 Oct 2001 13:12:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28151;
	Thu, 18 Oct 2001 12:12:29 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IJBUOI018958
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:11:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IJBU9U018957
	for mobile-ip-dist; Thu, 18 Oct 2001 12:11:30 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IJBROI018950
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:11:27 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02103
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:11:28 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17481
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:11:26 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9IJBPe27454
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 22:11:25 +0300
Date: Thu, 18 Oct 2001 22:11:25 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
In-Reply-To: <3BCF2528.C8C97AC9@iprg.nokia.com>
Message-ID: <Pine.LNX.4.33.0110182159210.27368-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 18 Oct 2001, Charles E. Perkins wrote:
> What you are describing is a rule for forwarding a routing header
> along paths inside a single host.  I'm trying to get at it from a
> somewhat different angle, as follows.

True.
 
> Suppose there is a protocol by which the following state is inserted
> at a forwarding node (host or router):
> - If my address is in a routing header, and I am requested to forward
>   the packet to a _particular_ next address when it arrives with my
>   address in the routing header, I will agree to do so.
> 
> This has to be done individually for all such "next addresses" that
> might show up in a routing header.  Agreement to forward to one
> particular next address doesn't imply full agreement for all possible
> next addresses, or even for any other next address at all.
> 
> I like this rule.  The point is that you can't just forward blindly,
> but only after agreement by way of some protocol which essentially
> does the setup.
> 
> For mobile nodes, there's nothing to do except for keeping track of
> its own addresses, which is appropriate for this case.  The act of
> disseminating the Binding Update can be viewed, in this context, as
> "advertising" a mobile node's (internal) agreement to forward packets
> to its home address.  This does not at all mean that the mobile node
> agrees to act as a forwarding node for all possible routing headers.

I see a practical problem with this.  

Assume a non-MIPv6 scenario, where the sending node should establish this
permission on the first destination towards some next destination.

There would indeed need to be a real protocol for this.

Sounds awafully heavy for something as simple as this (much like Binding 
Update, indeed, actually!)

It works in the restricted scenario you described just fine.

> > Host route inside a node _could_ be something that could be easily used --
> > MIPv6 could set one up for Home Address no problems.
> 
> I agree it could be done inside a mobile node by way of an explicit
> host route, but I don't think that has to be put into the Mobile IPv6
> specification.  There are other ways to do it that have the same
> external effect.

Indeed, it's too implementation-specific.

Problem with this is that it has to be done (usually) inside the OS
kernel.  Is it prudent to keep a list of home addresses there?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 15:30:56 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18481
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 15:30:56 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01166;
	Thu, 18 Oct 2001 13:30:25 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02646;
	Thu, 18 Oct 2001 12:30:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IJTCOI019084
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:29:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IJTC5h019083
	for mobile-ip-dist; Thu, 18 Oct 2001 12:29:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IJT9OI019076
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:29:09 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05788
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:29:10 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06116
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:54:31 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA08382
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:29:09 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9IJT8W18476
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:29:08 -0700
X-mProtect:  Thu, 18 Oct 2001 12:29:08 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdUArkHu; Thu, 18 Oct 2001 12:29:06 PDT
Message-ID: <3BCF2D83.1C2B2E17@iprg.nokia.com>
Date: Thu, 18 Oct 2001 12:29:07 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security 
 Requirementsfor MIP v6
References: <Pine.LNX.4.33.0110182159210.27368-100000@netcore.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Pekka,

Pekka Savola wrote:

>> Suppose there is a protocol by which the following state is inserted
>> at a forwarding node (host or router):
>> - If my address is in a routing header, and I am requested to forward
>>   the packet to a _particular_ next address when it arrives with my
>>   address in the routing header, I will agree to do so.

             ..........

> I see a practical problem with this.
> 
> Assume a non-MIPv6 scenario, where the sending node should establish this
> permission on the first destination towards some next destination.
> 
> There would indeed need to be a real protocol for this.
> 
> Sounds awafully heavy for something as simple as this (much like Binding
> Update, indeed, actually!)

It could certainly require protocol in the general case.  But:
- Setting up routing headers should properly be considered a routing protocol.
- Setting up routing headers is "like" setting up encapsulation, and in the
  applications which I am familiar with for setting up encapsulation, such a
  protocol exists.
- You have adequately pointed out the dangers which ensue unless explicit
  agreement exists.

I think that Francis, you, and I all agree that some controls need to be in
place, and that the controls are essentially automatically fulfilled when
the routing header is used for addresses on the same node.  I can imagine
some further discussion on the last point, but not for care-of addresses.

I thought that my formulation captured some of the essence of the problem,
and pointed towards the properties that such a setup protocol would need,
and that I could get my mind wrapped around it a little more simply.  In a
way, all we need to agree here is that (a) routing headers need to be
controlled and agreed beforehand, and (b) Mobile IPv6 use of care-of
addresses satisfies the necessary control and agreement.  Further expansion
on this theme may properly reside in the IPv6 working group.

> Problem with this is that it has to be done (usually) inside the OS
> kernel.  Is it prudent to keep a list of home addresses there?

It's not absolutely necessary to do that, but on the other hand
the IP addresses are in the kernel, and likely some of them are
already marked as home addresses.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 15:57:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18879
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 15:57:29 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23060;
	Thu, 18 Oct 2001 12:56:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08770;
	Thu, 18 Oct 2001 12:56:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IJsiOI019269
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:54:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IJsiN9019268
	for mobile-ip-dist; Thu, 18 Oct 2001 12:54:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IJsfOI019261
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:54:41 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00547
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:54:42 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12946
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 12:54:41 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9IJseB27663
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 22:54:40 +0300
Date: Thu, 18 Oct 2001 22:54:40 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] MIPv6 HA wording and H.3 of SecReqs [...]
In-Reply-To: <200110181853.f9IIrjD74789@givry.rennes.enst-bretagne.fr>
Message-ID: <Pine.LNX.4.33.0110182234070.27572-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I'll change the subject a bit .. it's getting too swamped. :-)

On Thu, 18 Oct 2001, Francis Dupont wrote:
>    Thus MIPv6 is "responsible" for this behaviour (ie: security of
>    home address option).
>    
> => is H.3 enough for you (I've privately sent a comment about this
> and I'll resend it if the thread doesn't give a solution I like) ?
> BTW I agree this is a MIPv6 issue.

The threat is basically okay for Home Address.

I'm not satisfied with the details though.

--8<--
   Scenario H.3:

   According to the Mobile IPv6 spec: "A node receiving a packet that
   includes a Home Address option MAY
    implement the processing of this option by physically exchanging the
    Home Address option field with the source IPv6 address in the IPv6
    header."
--8<--

So it does read in mipv6 -14.

I see a problem with MIPv6 draft.  Nowhere is it defined how Home Address
Option must be processed (at least I couldn't find it).  Only mentioned as
a MAY in security considerations.

Has anyone implemented this differently?
The end-result is probably always the same, and that should be reflected 
in the wording in secreqs.

--8<--
 the following requirements apply to ALL
   IPv6 nodes (whether host or router, whether mobile or stationary):

    -  Every IPv6 node MUST be able to process a Home Address option
       received in any IPv6 packet
--8<--

what does 'be able to process' mean in this context?  Recognize and be 
able to parse it?  Parse it and MUST have the processing enabled?

Both drafts should be updated on this one, I think.

--8<--
   Requirement H.3:

   CNs SHOULD NOT/MAY NOT process any packet (BU or not) containing a
   Home Address option unless they have verified that that the node
   sending the packets is authorized to use the home address in the
   destination option.
--8<--

Combined with the problems above, it seems, whether conscious or not, that 
the threat is being down-played.

I don't think I could accept any other wording than: 
'CNs MUST NOT process any packet [...]'

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 16:19:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19179
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 16:19:02 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10536;
	Thu, 18 Oct 2001 14:17:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13584;
	Thu, 18 Oct 2001 13:17:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKGuOI019397
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:16:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IKGuxP019396
	for mobile-ip-dist; Thu, 18 Oct 2001 13:16:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKGqOI019389
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:16:52 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13151
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:16:43 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09284
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:16:29 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA05272
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:16:47 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Thu, 18 Oct 2001 15:09:50 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L61VY>; Thu, 18 Oct 2001 15:16:00 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E75C1C2@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 18 Oct 2001 15:16:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15811.B5465BE0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15811.B5465BE0
Content-Type: text/plain;
	charset="iso-8859-1"

Behcet,
 
>  I read your long email, talking about vertical and horizontal solutions.
I do not quite get what you are referring to (any drafts, RFCs, books,
papers, etc)?   

GM] I think there has been some discussion on numerous mailing lists inside
and outside of the IETF, some have done drafts, some have done papers.
SIGLITE, Active Networking, MIP and derivative lists have discussed this for
over 3 years now. I could try to dig up some references.

>  A simple question: you are saying that RSVP would not work with MIPv4,
aren't you?

GM] No. Perhaps one could say, "as currently defined they are not
compatible".  I think they could be made to be compatible even with route
optimization.
 
> BTW, QoS issues to my knowledge will go to NSIS WG yet to be formed. 

GM] And NSIS is also supposed to handle the mobility interactions as well.
Perhaps we should try to help that effort out by allowing the two to work
synergistically. 

Regards, 

Glenn
 
  

------_=_NextPart_001_01C15811.B5465BE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Behcet,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; I read your long email, talking about =
vertical and horizontal solutions. I do not quite get what you are =
referring to (any drafts, RFCs, books, papers, etc)?&nbsp;&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>GM] I think there has been some discussion on =
numerous mailing lists inside and outside of the IETF, some have done =
drafts, some have done papers. SIGLITE, Active Networking, MIP and =
derivative lists have discussed this for over 3 years now. I could try =
to dig up some references.</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp; A simple question: you are saying that =
RSVP would not work with MIPv4, aren't you?</FONT>
</P>

<P><FONT SIZE=3D2>GM] No. Perhaps one could say, &quot;as currently =
defined they are not compatible&quot;.&nbsp; I think they could be made =
to be compatible even with route optimization.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; BTW, QoS issues to my knowledge will go to NSIS =
WG yet to be formed. </FONT>
</P>

<P><FONT SIZE=3D2>GM] And NSIS is also supposed to handle the mobility =
interactions as well. Perhaps we should try to help that effort out by =
allowing the two to work synergistically. </FONT></P>

<P><FONT SIZE=3D2>Regards, </FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15811.B5465BE0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 16:24:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19237
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 16:24:11 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15032;
	Thu, 18 Oct 2001 14:23:40 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15259;
	Thu, 18 Oct 2001 13:23:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKN0OI019531
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:23:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IKN0bW019530
	for mobile-ip-dist; Thu, 18 Oct 2001 13:23:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKMuOI019523
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:22:57 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03273
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:22:59 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25689
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:22:58 -0700 (PDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA07199
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:22:57 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 18 Oct 2001 15:21:24 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L6162>; Thu, 18 Oct 2001 15:22:12 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E75C1D7@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Thu, 18 Oct 2001 15:22:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15812.934AE820"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15812.934AE820
Content-Type: text/plain;
	charset="iso-8859-1"

I agree - of course.

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Thursday, October 18, 2001 1:00 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Morrow, Glenn [RICH2:C330:EXCH]
> Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
> 
> 
> Hello folks,
> 
> Glenn Morrow said something which has resonated with me during
> the last week.
> 
> > I guess people just don't agree on the value of 
> piggybacking, the affect of
> > delays incurred by segmentation and whether the access 
> network should drive
> > the IP definitions or the access networks should adapt to 
> the IP definitions.
> 
> This seems to hit the spot exactly.  We have disagreements, 
> but I would
> like to suggest that we should make the IP definitions based on what's
> good for IP instead of the restrictions imposed by the 
> unadapted access
> networks (or, worse yet, the least common denominator of all access
> networks!).
> 
> Applied to the discussion about whether Binding Update should 
> be carried
> along with payload, this would mean that we should have the feature if
> it fits naturally in IP, and if there are going to be 
> networks which can
> use the feature to good advantage.  The reasons why this feature are
> advantageous are outlined in the draft from Jari Arkko, along with the
> costs of the feature.  Some networks will gladly pay the 
> cost, and some
> won't, for a myriad of reasons.
> 
> I am very much in favor of making the best IP definition, and 
> along the
> way making sure that it can be used to fit well with existing access
> networks.  The current proposal with Destination Options does do that.
> There is no requirement that any implementation MUST supply payload
> in packets that contain a Binding Update, and almost all of the
> complication from processing payload with a Destination Option comes
> on the sending side.  So I don't agree with arguments based on the
> extra complexity.  If some implementations don't want to undertake
> the extra complexity, that is fine, but those groups should not be
> allowed to penalize the implementations that wish to offer the better
> performance by the magic of making it illegal to do so.  That is not
> fair in my book.
> 
> Regards,
> Charlie P.
> 

------_=_NextPart_001_01C15812.934AE820
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I agree - of course.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Charles E. Perkins [<A HREF="mailto:charliep@iprg.nokia.com">mailto:charliep@iprg.nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, October 18, 2001 1:00 PM</FONT>
<BR><FONT SIZE=2>&gt; To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: Morrow, Glenn [RICH2:C330:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello folks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Glenn Morrow said something which has resonated with me during</FONT>
<BR><FONT SIZE=2>&gt; the last week.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I guess people just don't agree on the value of </FONT>
<BR><FONT SIZE=2>&gt; piggybacking, the affect of</FONT>
<BR><FONT SIZE=2>&gt; &gt; delays incurred by segmentation and whether the access </FONT>
<BR><FONT SIZE=2>&gt; network should drive</FONT>
<BR><FONT SIZE=2>&gt; &gt; the IP definitions or the access networks should adapt to </FONT>
<BR><FONT SIZE=2>&gt; the IP definitions.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This seems to hit the spot exactly.&nbsp; We have disagreements, </FONT>
<BR><FONT SIZE=2>&gt; but I would</FONT>
<BR><FONT SIZE=2>&gt; like to suggest that we should make the IP definitions based on what's</FONT>
<BR><FONT SIZE=2>&gt; good for IP instead of the restrictions imposed by the </FONT>
<BR><FONT SIZE=2>&gt; unadapted access</FONT>
<BR><FONT SIZE=2>&gt; networks (or, worse yet, the least common denominator of all access</FONT>
<BR><FONT SIZE=2>&gt; networks!).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Applied to the discussion about whether Binding Update should </FONT>
<BR><FONT SIZE=2>&gt; be carried</FONT>
<BR><FONT SIZE=2>&gt; along with payload, this would mean that we should have the feature if</FONT>
<BR><FONT SIZE=2>&gt; it fits naturally in IP, and if there are going to be </FONT>
<BR><FONT SIZE=2>&gt; networks which can</FONT>
<BR><FONT SIZE=2>&gt; use the feature to good advantage.&nbsp; The reasons why this feature are</FONT>
<BR><FONT SIZE=2>&gt; advantageous are outlined in the draft from Jari Arkko, along with the</FONT>
<BR><FONT SIZE=2>&gt; costs of the feature.&nbsp; Some networks will gladly pay the </FONT>
<BR><FONT SIZE=2>&gt; cost, and some</FONT>
<BR><FONT SIZE=2>&gt; won't, for a myriad of reasons.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I am very much in favor of making the best IP definition, and </FONT>
<BR><FONT SIZE=2>&gt; along the</FONT>
<BR><FONT SIZE=2>&gt; way making sure that it can be used to fit well with existing access</FONT>
<BR><FONT SIZE=2>&gt; networks.&nbsp; The current proposal with Destination Options does do that.</FONT>
<BR><FONT SIZE=2>&gt; There is no requirement that any implementation MUST supply payload</FONT>
<BR><FONT SIZE=2>&gt; in packets that contain a Binding Update, and almost all of the</FONT>
<BR><FONT SIZE=2>&gt; complication from processing payload with a Destination Option comes</FONT>
<BR><FONT SIZE=2>&gt; on the sending side.&nbsp; So I don't agree with arguments based on the</FONT>
<BR><FONT SIZE=2>&gt; extra complexity.&nbsp; If some implementations don't want to undertake</FONT>
<BR><FONT SIZE=2>&gt; the extra complexity, that is fine, but those groups should not be</FONT>
<BR><FONT SIZE=2>&gt; allowed to penalize the implementations that wish to offer the better</FONT>
<BR><FONT SIZE=2>&gt; performance by the magic of making it illegal to do so.&nbsp; That is not</FONT>
<BR><FONT SIZE=2>&gt; fair in my book.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; Charlie P.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15812.934AE820--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 16:32:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19347
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 16:32:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21545;
	Thu, 18 Oct 2001 14:30:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16956;
	Thu, 18 Oct 2001 13:30:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKTaOI019661
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:29:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IKTars019660
	for mobile-ip-dist; Thu, 18 Oct 2001 13:29:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKTYOI019653
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:29:34 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06697
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 16:29:35 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA11832
	for mobile-ip@sunroof.eng.sun.com; Thu, 18 Oct 2001 16:30:05 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I9ocOI014309
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 02:50:38 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16589
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 02:50:34 -0700 (PDT)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05201
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 02:50:40 -0700 (PDT)
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id f9I9ljQ17805;
	Thu, 18 Oct 2001 11:47:46 +0200 (MEST)
Message-ID: <3BCF175C.3CA436C7@inrialpes.fr>
Date: Thu, 18 Oct 2001 19:54:36 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: Humayun Latif <hlatif@andrew.cmu.edu>, Brenda Liu <bhliu@andrew.cmu.edu>,
        Asad Samar <asamar@andrew.cmu.edu>
Subject: Re: [mobile-ip] DDOS attacks and mobile-ip
References: <Pine.GSO.4.33L-022.0110171622240.7393-100000@unix4.andrew.cmu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Asad Samar wrote:

> --get a feel of how launching a DDOS attack in this environment (based on
> mobile-ip) is easier/more difficult than a traditional static network and
> why?
>
> --are there new ways of launching/preventing DDOS attacks in such an
> environment which havent been explored in the static scope.

The following I-D might interest you. There is a section on DoS attacks,
which explains how they can be amplified and distributed by the IP paging
process in the cellular Internet (also in rfc3154).

http://search.ietf.org/internet-drafts/draft-mutaf-paging-security-requirements-00.txt



pars



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 16:33:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19382
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 16:33:29 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09146;
	Thu, 18 Oct 2001 13:33:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17298;
	Thu, 18 Oct 2001 13:31:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKUhOI019687
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:30:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IKUhHo019686
	for mobile-ip-dist; Thu, 18 Oct 2001 13:30:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKUcOI019679
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:30:38 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16888
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:30:34 -0700 (PDT)
Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16367
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:56:06 -0600 (MDT)
Received: from jariws1 ([62.248.238.156]) by fep01-app.kolumbus.fi
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP
          id <20011018203038.VUQC18920.fep01-app.kolumbus.fi@jariws1>;
          Thu, 18 Oct 2001 23:30:38 +0300
Message-ID: <00be01c15813$c14f30e0$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Pekka Savola" <pekkas@netcore.fi>
References: <Pine.LNX.4.33.0110182104130.26862-100000@netcore.fi>
Subject: Re: [mobile-ip] Re: dangers of new headers (was: something else)
Date: Thu, 18 Oct 2001 23:30:40 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> I took this as a BU dst option moved to a new, non-final extention header.  
> If this would have been the case, my discussion would have applied.  
> Perhaps you meant something else (a final BU ext header).

I believe the discussion started from the possibility of defining a
new final BU extension header, in order to satisfy current IPsec
SPDs. I don't think we need to discuss the case of a new middle
extension header. For that, we already have a solution and it is
called Destination Options header.

Let me try to see if we could agree on a few conclusions here.
Yell if you don't agree:

* New middle headers could get messy. (But, as discussed
  above we do not need them either.)

* If a new payload header (= final extension header) would be
  used, then its introduction would create problems similar to
  the introduction of SCTP. There might be some firewalls (not
  sure if there are any yet for IPv6) that can only process fixed set
  of protocols. But the hope is that most products would have
  the possibility to enter protocol numbers etc.

* If a UDP port number were used instead, this would create
  no such problems.

* I detect slight preference here towards UDP port rather than
  a new header, if we decide to abandon the current DO approach.

* No conclusion yet on piggybacking being kept or not issue!

* And the same in the DO vs. separate BU issue.

Jari





From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 16:57:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19655
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 16:57:19 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12951;
	Thu, 18 Oct 2001 14:56:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15342;
	Thu, 18 Oct 2001 13:57:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKtXOI019988
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:55:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IKtXFA019987
	for mobile-ip-dist; Thu, 18 Oct 2001 13:55:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IKtTOI019980
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:55:30 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23237
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:55:25 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13817
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 13:55:31 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9IKtT827998
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 23:55:29 +0300
Date: Thu, 18 Oct 2001 23:55:29 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Re: dangers of new headers (was: something else)
In-Reply-To: <00be01c15813$c14f30e0$8a1b6e0a@arenanet.fi>
Message-ID: <Pine.LNX.4.33.0110182350190.27959-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, 18 Oct 2001, Jari Arkko wrote:

> > I took this as a BU dst option moved to a new, non-final extention header.  
> > If this would have been the case, my discussion would have applied.  
> > Perhaps you meant something else (a final BU ext header).
> 
> I believe the discussion started from the possibility of defining a
> new final BU extension header, in order to satisfy current IPsec
> SPDs. I don't think we need to discuss the case of a new middle
> extension header. For that, we already have a solution and it is
> called Destination Options header.
> 
> Let me try to see if we could agree on a few conclusions here.
> Yell if you don't agree:
> 
> * New middle headers could get messy. (But, as discussed
>   above we do not need them either.)
> 
> * If a new payload header (= final extension header) would be
>   used, then its introduction would create problems similar to
>   the introduction of SCTP. There might be some firewalls (not
>   sure if there are any yet for IPv6) that can only process fixed set
>   of protocols. But the hope is that most products would have
>   the possibility to enter protocol numbers etc.
> 
> * If a UDP port number were used instead, this would create
>   no such problems.

.. but at least low-range (privileged) ports might very often be filtered 
(looking back at IPv4).

There's not so much filtering yet for IPv6, though, so I think if we go
this route, this probably won't be a problem (consider with filtering
UDP/500).

So I don't think this would be an unsurmountable problem.
 
> * I detect slight preference here towards UDP port rather than
>   a new header, if we decide to abandon the current DO approach.
> 
> * No conclusion yet on piggybacking being kept or not issue!
> 
> * And the same in the DO vs. separate BU issue.

From my viewpoint, this seems rather good characterization (I can't really
tell of the piggybacking argument).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords





From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 17:29:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20133
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 17:29:20 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08708;
	Thu, 18 Oct 2001 15:28:14 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22849;
	Thu, 18 Oct 2001 14:28:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ILRAOI020164
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:27:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9ILRAhs020163
	for mobile-ip-dist; Thu, 18 Oct 2001 14:27:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ILR6OI020156
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:27:06 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00404
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:27:02 -0700 (PDT)
Received: from mail.cambianetworks.com (osh200-140.onshore.com [66.54.200.140] (may be forged))
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04980
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 14:27:07 -0700 (PDT)
Received: by mail.cambianetworks.com (Postfix, from userid 1063)
	id 5DCF38AE93; Thu, 18 Oct 2001 16:22:09 -0500 (CDT)
Received: from USAROSRMARKS1 (ip-216-73-138-20.vantas.net [216.73.138.20])
	by mail.cambianetworks.com (Postfix) with ESMTP
	id 229D1B298C; Thu, 18 Oct 2001 16:22:06 -0500 (CDT)
From: "Robert J Marks" <rjmarks@cambianetworks.com>
To: <mobile-ip@sunroof.eng.sun.com>, <charliep@iprg.nokia.com>,
        <pcalhoun@diameter.org>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Thu, 18 Oct 2001 16:27:49 -0500
Organization: Cambia Networks
Message-ID: <006c01c1581b$bd1cb120$b801a8c0@cambianetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006D_01C157F1.D446A920"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <4.3.1.2.20011017221148.01f78f00@clea.qualcomm.com>
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

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

Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.
 
Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.







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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D848450921-18102001><FONT face=3DArial color=3D#0000ff =

size=3D2>Although I am not sure of the intention in the RFC, I agree =
that the byte=20
should not be duplicated in 2 places. I also seem to remember that known =

duplication tends to weaken the security.</FONT></SPAN></DIV>
<DIV><SPAN class=3D848450921-18102001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D848450921-18102001><FONT face=3DArial color=3D#0000ff =

size=3D2>Bob</FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  owner-mobile-ip@sunroof.eng.sun.com=20
  [mailto:owner-mobile-ip@sunroof.eng.sun.com] <B>On Behalf Of </B>Nish=20
  Abrol<BR><B>Sent:</B> Thursday, October 18, 2001 12:14 =
AM<BR><B>To:</B>=20
  charliep@iprg.nokia.com; pcalhoun@diameter.org;=20
  mobile-ip@sunroof.eng.sun.com<BR><B>Subject:</B> [mobile-ip] URGENT - =
rfc3012=20
  interpretation question<BR><BR></FONT></DIV>Pat/Charlie,<BR><BR>Really =

  appreciate any insights into this really important interop issue for=20
  cdma2000:<BR><BR>A question regarding the&nbsp; interpretation of =
section 8 of=20
  rfc3012. This section specifies how to calculate the MN-AAA =
authenticator. It=20
  says:<BR><BR>" To compute the authenticator, apply MD5 [11] computed =
on=20
  the<BR>following data, in the order shown:<BR><BR>High-order byte from =

  Challenge || Key ||<BR>MD5(Preceding Mobile IP data ||<BR>Type, =
Subtype (if=20
  present), Length, SPI) ||<BR>Least-order 237 bytes from Challenge =
"<BR><BR>The=20
  question is - if the challenge has less than 237 bytes - should the =
high order=20
  byte which was already used in the MD5 calculation&nbsp; be included =
again as=20
  part of the&nbsp; "least-order 237 bytes from Challenge"?<BR><BR>e.g. =
if the=20
  challenge is 50 bytes in length - should the authenticator be =
calculated&nbsp;=20
  as:<BR>&nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator =3D md5(byte0 || =
key.......||=20
  byte1 through byte49)<BR><BR>or (b) authenticator =3D md5(byte0 || key =
......||=20
  <U>byte0 </U>through byte49).<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
where=20
  byte0 is the most significant byte of the challenge.<BR><BR>A strict =
reading=20
  of the RFC seems to suggest (b). However, it seems&nbsp; that =
calculating the=20
  MD5 authenticator with the same information(high order byte) at =
different=20
  locations of the payload weakens the authenticator.<BR><BR>So, what =
was the=20
  intention of the RFC and how should it be implemented? Also, do you =
know if=20
  RFC3012 implementations have participated in any bakeoffs/interops. If =
so, how=20
  have they interpreted this section?<BR><BR>Your help will be really=20
  appreciated.<BR><BR>Thanks<BR>Nish Abrol<BR>Qualcomm,=20
Inc.<BR><BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_006D_01C157F1.D446A920--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 18:55:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21073
	for <mobileip-archive@lists.ietf.org>; Thu, 18 Oct 2001 18:55:09 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11542;
	Thu, 18 Oct 2001 16:54:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09490;
	Thu, 18 Oct 2001 15:54:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IMrwOI020468
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:53:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IMrwvc020467
	for mobile-ip-dist; Thu, 18 Oct 2001 15:53:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IMrtOI020460
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:53:55 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22289
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:53:56 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17720
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 15:53:56 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9IMsPQ19766
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 17:54:25 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56ad5b64b9ac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Thu, 18 Oct 2001 17:53:55 -0500
Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 18 Oct 2001 17:54:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Improving BETH: Tunnel Negotiation
Date: Thu, 18 Oct 2001 17:54:08 -0500
Message-ID: <07EE0E021034014F99A57B032BC9C0E50BDB23@daebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [mobile-ip] Improving BETH: Tunnel Negotiation
Thread-Index: AcFTbmCu3gAZ0b9gEdWBTQBQi2X+DwEuG7BA
From: "Sreemanthula Srinivas (NRC/Dallas)" <Srinivas.Sreemanthula@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 18 Oct 2001 22:54:09.0190 (UTC) FILETIME=[CBF53C60:01C15827]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9IMrtOI020461
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hi James, 

Thanks for accepting the proposals. I will draft the text accordingly
and send it.

Regards,
Srini

-----Original Message-----
From: ext James Kempf [mailto:James.Kempf@Sun.COM]
Sent: 12 October, 2001 5:34 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: kempf42@yahoo.com
Subject: Re: [mobile-ip] Improving BETH: Tunnel Negotiation


Sreemanthula, 

Thanx for these proposals. Sorry it took so long to get back to
you, I was on vacation.

>Proposal 1: 
>Allow negotiation of lifetime of the BET between the oAR and
>the nAR. The smaller of the two timers (Tunnel requester or responder)
>should be the one that determines the lifetime of the
>tunnel. Negotiation does not mean multiple exchange of messages
>between the tunnel end-points. 
>
>Reason: 
>Flexibility of deployments especially wherein you have different
>domains with differing policies for the way they deal with traffic
>coming from within or an external network. 
> 

I think the current draft has aAR controlling the tunnel
lifetime, but I agree that the above proposal would be desirable. The
intent
of having the aAR control the tunnel lifetime is that an
aAR may be serving as an anchor for many tunnels, and so
it may have need to limit the lifetime of tunnels that
it can support. But one could make the same argument for the
other end of the tunnel.


>Proposal 2: The support for tunnel refresh or renewal of the lifetime 
>of the tunnel should be made known at the time of tunnel setup via 
>a flag which indicates whether the tunnel originator or terminator 
>allows it. In case either router does not support tunnel refresh, the 
>other router needs to react appropriately.
>
>Reason: Prevents subsequent signaling in the network to try to refresh 
>the tunnel and discover at that point that the refresh is not possible,

>thus introducing possible latency in the MN handoff. As soon as BETH 
>is completed and the MN has moved at L2, the nAR can instruct the 
>MN to do get a nCoA. The proposal also provides a mechanism for the 
>network of either oAR or nAR to somehow indicate to the MN to HO to 
>the nAR at a certain time based on local network policies.
>

This sounds reasonable to me as well.

Unless anyone else in the WG has objections, can you send specific
proposed 
wording changes in the draft to Gopal (cc'ing me at kempf42@yahoo.com)?

		jak


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 19:40:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21432
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 19:40:08 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20818;
	Thu, 18 Oct 2001 16:39:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19011;
	Thu, 18 Oct 2001 16:39:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9INcGOI020663
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 16:38:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9INcG6q020662
	for mobile-ip-dist; Thu, 18 Oct 2001 16:38:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9INcDOI020655
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 16:38:13 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18911
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 16:38:15 -0700 (PDT)
Received: from web13902.mail.yahoo.com (web13902.mail.yahoo.com [216.136.175.28])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA03338
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 16:38:14 -0700 (PDT)
Message-ID: <20011018233814.86182.qmail@web13902.mail.yahoo.com>
Received: from [216.98.102.225] by web13902.mail.yahoo.com via HTTP; Thu, 18 Oct 2001 16:38:14 PDT
Date: Thu, 18 Oct 2001 16:38:14 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: Re: [mobile-ip] Last Call Comments draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: mobile-ip@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Pekkka,

Comments embedded.
> 
> > > In general, the document seems very heavily
> weighed
> > > towards MN/CN security threats and very lightly
> > > weighted towards MN/AR threats. Some of the
> MN/CN
> > > threats are redundant. There are 18 threats
> > > identified for the MN/CN and only two for the
> MN/AR.
> > > This is perhaps understandable, given the
> attention
> > > the IETF security folks have been focussing on
> the
> BU
> > > security problem, but the MN/AR relationship is,
> in
> > > some sense, equally if not more important (it
> is,
> for
> > > example, a MUST and not a SHOULD).
> >
> > I'm not sure if 'AR' means 'Access Router', but
> assuming so..
> >
> > Hmm?
> >
> 
Yes.
> 
> > Am I mistaken but from the draft:
> > --8<--
> >    The goal is to determine which of those threats
> are of concern and
> >    should be defended against.  While the basic
> goal
> is "no worse than
> >    IPv4," the prevalence of wireless and the
> likely
> deployment of MIPv6
> >    in that space means the basic goal should aim
> at
> being "no worse than
> >    IPv4 with switched Ethernets", although the
> intent is not to try to
> >    solve the security problems of shared/broadcast
> wireless mediums.
> >    The threat model is used to generate a list of
> requirements to make
> >    the MIPv6 protocol secure against likely
> threats.
> These requirements,
> >    interspersed with the threats and also listed
> at
> the end of this
> >    document are aimed at providing guidelines in
> developing a solution
> >    for MIPv6 security.
> > --8<--
> >
> > Based on this:
> >
> > > 1) A malicious AR could hijack traffic from a
> trusting
> > > MN. This was partially identified in the
> document.
> >
> > This is no different from any secure IPv4/6
> environment.  If you don't use
> > AH/ESP or equivalent, any upstream router can do
> that.  This is not in the
> > scope of MIPv6, I think.
> >
> > > 2) A theaving MN could gain network access
> without
> > > authorization by soliciting a Router Advert,
> then
> > > setting up a CoA.
> > >
> > > 3) Similar to 2), a theaving MN could gain
> network
> > > access without authorization through responding
> to
> an
> > > unsolicited Router Advert, then setting up a
> CoA.
> >
> > This is no different from IPv6; it doesn't provide
> access controls on who
> > can or can not autoconfigure an address and use
> it.
> >
> > One should assume that if you can phycially get
> into
> a LAN, WLAN, a cell,
> > ... or whatever, you're authorized to use the
> network.
> >
> > So these may also be outside of the scope.
> >
> 
I agree that these will be threats in a wired
network
as well. The problem is that mobility can make them
worse because a mobile host can move quickly into an
out of a subnet without actually gaining physical
access to wired port. It is much easier to control
security when physical access is required (locked
doors, guards, etc.).

While in general I think it is a good tactic to
limit
the scope of Internet Drafts, in this case, we need
some kind of vehicle for identifying these threats
and
taking them to the right WG (IPNG? URP, should it
become a WG?). These security holes exist with IPv6
now, and even if we come up with the perfect
solution
to the BU security problem, if no other working
group
addresses them, MIPv6 will still not be secure, and
thus not deployable, IMHO.
> 
> >
> >
> > One _could_ list a few "known" issues in the
> draft,
> of course.  (About
> > one-two lines per non-issue).
> >
> 
Yes, I think this would be appropriate. There need
not
be a comprehensive discussion, just a place where we
can say "go look at RFC XYZ for a list of issues
that
already exist in IPv6 which become worse with
mobility." Unless, of course, some other WG has
already collected a list of these issues and all we
need to do is point to their draft?

                jak


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 21:45:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23380
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 21:45:58 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10119;
	Thu, 18 Oct 2001 19:44:44 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09636;
	Thu, 18 Oct 2001 18:44:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J1hhOI021254
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 18:43:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J1hhe4021253
	for mobile-ip-dist; Thu, 18 Oct 2001 18:43:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J1hdOI021246
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 18:43:39 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19342
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 18:43:34 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09440
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 19:43:18 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA26840
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:42:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA02264
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:43:38 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXQJHL>; Fri, 19 Oct 2001 11:43:37 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDA8@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Charles E. Perkins'" <charliep@iprg.nokia.com>
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] WG Last Call on Threat Model and Security Require
	ments  for MIP v6
Date: Fri, 19 Oct 2001 11:43:35 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

	Hello Charlie, 

> >         No, I think there needs to be some verbiage
> >         (if not already present!) that says that a
> >         host MUST be able to forward to itself. Otherwise
> >         MIP and other uses of CoA's might not be
> >         implemented (eg, multihoming). That would be
> >         unfortunate. I think this is mainly an issue
> >         of MUST implement. Policy knobs are always an
> >         option beyond that :-)
> > 
> >      => I guess I wanted to say the same thing but
> >      you have the time difference advatange so you're
> >      saying it better :)
> >      MUST forward to itself,
> >      MUST have a knob for forwarding to other nodes
> >      OK ?
> 
> I tried to point out in a note last night that it is enough
> for relay nodes to follow directives about forwarding to
> the next node in the list.  In the case needed for Mobile IPv6,
> this is simple.  A node can authorize itself to forward
> packets to itself.  In the general case, more persuasion
> may be needed, but the principle would remain the same.
> 
> OK?
> 
	=> Yes I think we're basically saying the same thing. 
	To make this more concrete I was suggesting that 
	RFC 2460 states that a node forwarding to itself 
	is a MUST (as a default behaviour) but forwarding 
	to other nodes, based on a routing header, 
	MUST be configurable. 
	We did this for the cellular host draft and I think 
	it is compliant with RFC 2460, but the MUSTs 
	I was suggesting would ensure that implementors
	follow this rule. 
	To answer your question I agree with you and Mike. 

	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 21:47:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23397
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 21:47:07 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10906;
	Thu, 18 Oct 2001 19:46:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09932;
	Thu, 18 Oct 2001 18:46:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J1jqOI021278
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 18:45:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J1jpSD021277
	for mobile-ip-dist; Thu, 18 Oct 2001 18:45:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J1jmOI021270
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 18:45:48 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23802
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 18:45:49 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10415
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 19:45:27 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA27039
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:44:40 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA02743
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:45:47 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXQJJJ>; Fri, 19 Oct 2001 11:45:46 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDA9@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 19 Oct 2001 11:45:45 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1583F.C4FF63A0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1583F.C4FF63A0
Content-Type: text/plain

> > > > 	- an "unpiggybacked" BU with a new ext header and 
> > > > 	- an SCTP payload.  
> > > > 	Could you tell me why these two are different ?
> > > > 
> > > > 	If you drop the former then you'd drop the latter ...right ?
> > > > 	Sounds like a firewall that needs an upgrade. 
> > > 
> > > The difference is significant.  Perhaps I can help to clarify the 
> > > situation.
> > > 
> > >  SCTP header would be like:
> > > 
> > >   IPv6 HDR - SCTP header
> > > 
> > >  BU with new Ext Header would be like (if I get this right):
> > > 
> > >   IPv6 HDR - UnknownHeaderBU - TCP/UDP/... header
> > > 
> > 	=> No it's not like that. The _whole discussion was about 
> > 	introducing a new ext header for IPsec and removing
> > 	piggybacking. .... Please.... the 2 go hand in hand !
> 
> Sorry, I didn't know what you meant, exactly, with:
> 
> 'an "unpiggybacked" BU with a new ext header'
> 
> I took this as a BU dst option moved to a new, non-final extention header.
> 
> If this would have been the case, my discussion would have applied.  
> Perhaps you meant something else (a final BU ext header).
> 
	=> Yes (to the last sentence), sorry if I wasn't clear, it 
	was getting late :)

	Hesham

> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

------_=_NextPart_001_01C1583F.C4FF63A0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &nbsp; - an =
&quot;unpiggybacked&quot; BU with a new ext header and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &nbsp; - an SCTP =
payload.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &nbsp; Could you tell =
me why these two are different ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &nbsp; If you drop the =
former then you'd drop the latter ...right ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &nbsp; Sounds like a =
firewall that needs an upgrade. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; The difference is =
significant.&nbsp; Perhaps I can help to clarify the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; situation.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&nbsp; SCTP header would be =
like:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&nbsp;&nbsp; IPv6 HDR - SCTP =
header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&nbsp; BU with new Ext =
Header would be like (if I get this right):</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&nbsp;&nbsp; IPv6 HDR - =
UnknownHeaderBU - TCP/UDP/... header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; No it's not like that. The _whole discussion was about </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
introducing a new ext header for IPsec and removing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
piggybacking. .... Please.... the 2 go hand in hand !</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sorry, I didn't know what you meant, =
exactly, with:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">'an &quot;unpiggybacked&quot; BU with =
a new ext header'</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I took this as a BU dst option moved =
to a new, non-final extention header.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">If this would have been the case, my =
discussion would have applied.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Perhaps you meant something else (a =
final BU ext header).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Yes (to the =
last sentence), sorry if I wasn't clear, it </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">was getting late =
:)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Pekka =
Savola&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Tell me of difficulties =
surmounted,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Netcore =
Oy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not those you stumble over and =
fall&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Systems. Networks. Security.&nbsp; -- =
Robert Jordan: A Crown of Swords</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C1583F.C4FF63A0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 18 22:10:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23681
	for <mobileip-archive@odin.ietf.org>; Thu, 18 Oct 2001 22:10:01 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20208;
	Thu, 18 Oct 2001 20:08:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12921;
	Thu, 18 Oct 2001 19:08:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J27mOI021496
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 19:07:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J27mfK021495
	for mobile-ip-dist; Thu, 18 Oct 2001 19:07:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J27iOI021488
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 19:07:44 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26770
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 19:07:46 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA01613
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 20:33:40 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA29338;
	Fri, 19 Oct 2001 12:06:29 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA10111;
	Fri, 19 Oct 2001 12:07:35 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXQJ9L>; Fri, 19 Oct 2001 12:07:34 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDAA@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: Glenn Morrow <gmorrow@nortelnetworks.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 19 Oct 2001 12:07:31 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15842.CF97C340"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15842.CF97C340
Content-Type: text/plain


	Hello Charlie,

> Glenn Morrow said something which has resonated with me during
> the last week.
> 
> > I guess people just don't agree on the value of piggybacking, the affect
> of
> > delays incurred by segmentation and whether the access network should
> drive
> > the IP definitions or the access networks should adapt to the IP
> definitions.
> 
> This seems to hit the spot exactly.  We have disagreements, but I would
> like to suggest that we should make the IP definitions based on what's
> good for IP instead of the restrictions imposed by the unadapted access
> networks (or, worse yet, the least common denominator of all access
> networks!).
> 
> Applied to the discussion about whether Binding Update should be carried
> along with payload, this would mean that we should have the feature if
> it fits naturally in IP, and if there are going to be networks which can
> use the feature to good advantage.  The reasons why this feature are
> advantageous are outlined in the draft from Jari Arkko, along with the
> costs of the feature.  Some networks will gladly pay the cost, and some
> won't, for a myriad of reasons.
> 
> I am very much in favor of making the best IP definition, and along the
> way making sure that it can be used to fit well with existing access
> networks. 
> 
	=> Sounds good. but below is where the problems begin IMHO. 

>  The current proposal with Destination Options does do that.
> There is no requirement that any implementation MUST supply payload
> in packets that contain a Binding Update, and almost all of the
> complication from processing payload with a Destination Option comes
> on the sending side.  So I don't agree with arguments based on the
> extra complexity.  If some implementations don't want to undertake
> the extra complexity, that is fine, but those groups should not be
> allowed to penalize the implementations that wish to offer the better
> performance by the magic of making it illegal to do so.  That is not
> fair in my book.
> 
	=> Well the problem is that IP is access independant :)
	So while my IPv6 MN may refuse to piggyback, my HA
	or CN might decide that piggybacking is a good idea
	and by that decision it is harming me. 
	This is despite the fact that my MN does not piggyback. 
	So the problem can not be solved based on a decision
	made by one side. 
	This is the main problem, keeping /removing piggybacking
	is an issue that will affect the sender and the receiver, 
	regardless of the design choices that each node may
	make. 


	Hesham


------_=_NextPart_001_01C15842.CF97C340
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hello =
Charlie,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Glenn Morrow said something which has =
resonated with me during</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the last week.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I guess people just don't agree =
on the value of piggybacking, the affect of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; delays incurred by segmentation =
and whether the access network should drive</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the IP definitions or the access =
networks should adapt to the IP definitions.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This seems to hit the spot =
exactly.&nbsp; We have disagreements, but I would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">like to suggest that we should make =
the IP definitions based on what's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">good for IP instead of the =
restrictions imposed by the unadapted access</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">networks (or, worse yet, the least =
common denominator of all access</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">networks!).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Applied to the discussion about =
whether Binding Update should be carried</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">along with payload, this would mean =
that we should have the feature if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it fits naturally in IP, and if there =
are going to be networks which can</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">use the feature to good =
advantage.&nbsp; The reasons why this feature are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">advantageous are outlined in the =
draft from Jari Arkko, along with the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">costs of the feature.&nbsp; Some =
networks will gladly pay the cost, and some</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">won't, for a myriad of =
reasons.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am very much in favor of making the =
best IP definition, and along the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">way making sure that it can be used =
to fit well with existing access</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">networks.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Sounds good. =
but below is where the problems begin IMHO. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;The current proposal with =
Destination Options does do that.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">There is no requirement that any =
implementation MUST supply payload</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in packets that contain a Binding =
Update, and almost all of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">complication from processing payload =
with a Destination Option comes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on the sending side.&nbsp; So I don't =
agree with arguments based on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">extra complexity.&nbsp; If some =
implementations don't want to undertake</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the extra complexity, that is fine, =
but those groups should not be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">allowed to penalize the =
implementations that wish to offer the better</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">performance by the magic of making it =
illegal to do so.&nbsp; That is not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">fair in my book.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Well the =
problem is that IP is access independant :)</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So while my IPv6 MN =
may refuse to piggyback, my HA</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">or CN might decide =
that piggybacking is a good idea</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">and by that =
decision it is harming me. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This is despite the =
fact that my MN does not piggyback. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So the problem can =
not be solved based on a decision</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">made by one side. =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This is the main =
problem, keeping /removing piggybacking</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is an issue that =
will affect the sender and the receiver, </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">regardless of the =
design choices that each node may</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">make. </FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15842.CF97C340--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 00:02:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25828
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 00:02:23 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA15222;
	Thu, 18 Oct 2001 21:02:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03805;
	Thu, 18 Oct 2001 21:01:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J40tOI021733
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:00:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J40tAJ021732
	for mobile-ip-dist; Thu, 18 Oct 2001 21:00:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J40pOI021725
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:00:51 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03690
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:00:47 -0700 (PDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26756
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:00:53 -0700 (PDT)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id EAA03630
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 04:00:53 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.42.28])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101821000906920
 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:00:09 -0700
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <VDTKGK14>; Thu, 18 Oct 2001 21:01:10 -0700
Message-ID: <8A9A5F4E6576D511B98F00508B68C20A1111D3@orsmsx106.jf.intel.com>
From: "Das, Kaustubh" <kaustubh.das@intel.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "Das, Kaustubh" <kaustubh.das@intel.com>
Subject: [mobile-ip] MN-FA authentication - appropriate behavior
Date: Thu, 18 Oct 2001 21:00:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi All,
I needed some clarification on the desired FA behavior in the following
situation
The setup is 

MN------------Router-------------------HA
        |
        |
        |
      FA

The MN wishes to register through the FA and is configured to use MN-FA
authentication extension.
The FA however is not configured to use MN-FA authentication extension. This
may perhaps be a misconfiguration.
Now The MN sends out a packet with a MN-FA authentication to the FA. What
should the FA do?

Should it:
1. Silently discard the packet.
OR
2. Send back a reply to the MN with a reject code. What reject code?
OR
3. Ignore the MN-FA authentication extension, but strip the extension off
and forward the request to the HA. 
When a reply comes around it should relay the reply to the MN "without a
MN-FA authentication extension"
OR
4. Some other behavior.

Any clarification/ thoughts are greatly appreciated.
Thanks and regards,
Kaustubh



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 00:14:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25923
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 00:14:12 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04433;
	Thu, 18 Oct 2001 22:13:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06128;
	Thu, 18 Oct 2001 21:13:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J4CPOI021852
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:12:25 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J4CP0r021851
	for mobile-ip-dist; Thu, 18 Oct 2001 21:12:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J4CLOI021844
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:12:21 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09181
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:12:24 -0700 (PDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA10704
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 22:38:47 -0600 (MDT)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id EAA06347
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 04:12:22 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101821113820811
 for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:11:38 -0700
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <VBAZJFXG>; Thu, 18 Oct 2001 21:10:31 -0700
Message-ID: <8A9A5F4E6576D511B98F00508B68C20A1111D4@orsmsx106.jf.intel.com>
From: "Das, Kaustubh" <kaustubh.das@intel.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "Das, Kaustubh" <kaustubh.das@intel.com>
Subject: RE: [mobile-ip] MN-FA authentication - appropriate behavior
Date: Thu, 18 Oct 2001 21:12:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi All,
I needed some clarification on the desired FA behavior in the following
situation
The setup is 

MN------------Router-------------------HA
        |
        |
        |
      FA

The MN wishes to register through the FA and is configured to use MN-FA
authentication extension.
The FA however is not configured to use MN-FA authentication extension. This
may perhaps be a misconfiguration.
Now The MN sends out a packet with a MN-FA authentication to the FA. What
should the FA do?

Should it:
1. Silently discard the packet.
OR
2. Send back a reply to the MN with a reject code. What reject code?
OR
3. Ignore the MN-FA authentication extension, but strip the extension off
and forward the request to the HA. 
When a reply comes around it should relay the reply to the MN "without a
MN-FA authentication extension"
OR
4. Some other behavior.

Any clarification/ thoughts are greatly appreciated.
Thanks and regards,
Kaustubh



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 00:57:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26365
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 00:57:29 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20088;
	Thu, 18 Oct 2001 22:56:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA00326;
	Thu, 18 Oct 2001 21:57:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J4uROI022058
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:56:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J4uQoQ022057
	for mobile-ip-dist; Thu, 18 Oct 2001 21:56:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J4uNOI022050
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:56:23 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05063
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 21:56:26 -0700 (PDT)
Received: from telesoft.indts.com ([164.164.71.52])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA25938
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 23:22:31 -0600 (MDT)
Received: from indts_fs.indts.com (indts_fs [201.64.64.29])
	by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id KAA25725
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:52:36 +0530
Received: by INDTS_FS with Internet Mail Service (5.5.2650.21)
	id <VAVVJGD2>; Fri, 19 Oct 2001 10:42:13 +0530
Message-ID: <F73B646FCC01D5118F530002B32C33724C7056@INDTS_FS>
From: Amit Shakya <amits@indts.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MN-FA authentication - appropriate behavior
Date: Fri, 19 Oct 2001 10:42:05 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

hi Das
wat i feel abt this is that the MN-FA authenctication is valid only if both
the parties are aware of that. 
Moreover if u go thru. RFC 2977  that is the AAA requirements for Mobile IP,
it says that the extension values are provided dynamically to FA and MN so
that they can use it for future references, till the lifetime of the keys.
So when a MN sends a MN-FA authentication value to FA, thats a fault on the
MN side. RFC 2002 is quite clear abt. this that FA wont process MN-FA auth.
ext., if Mobile security association does not exists between them and wat i
fell is that the Request shud be rejected with code as 70 (poorly formed
request).
Hope this helps u...
Amit


-----Original Message-----
From: Das, Kaustubh [mailto:kaustubh.das@intel.com]
Sent: Friday, October 19, 2001 9:31 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Cc: Das, Kaustubh
Subject: [mobile-ip] MN-FA authentication - appropriate behavior


Hi All,
I needed some clarification on the desired FA behavior in the following
situation
The setup is 

MN------------Router-------------------HA
        |
        |
        |
      FA

The MN wishes to register through the FA and is configured to use MN-FA
authentication extension.
The FA however is not configured to use MN-FA authentication extension. This
may perhaps be a misconfiguration.
Now The MN sends out a packet with a MN-FA authentication to the FA. What
should the FA do?

Should it:
1. Silently discard the packet.
OR
2. Send back a reply to the MN with a reject code. What reject code?
OR
3. Ignore the MN-FA authentication extension, but strip the extension off
and forward the request to the HA. 
When a reply comes around it should relay the reply to the MN "without a
MN-FA authentication extension"
OR
4. Some other behavior.

Any clarification/ thoughts are greatly appreciated.
Thanks and regards,
Kaustubh


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 01:05:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26529
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 01:05:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22498;
	Thu, 18 Oct 2001 23:03:57 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA01394;
	Thu, 18 Oct 2001 22:04:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J53ZOI022162
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 18 Oct 2001 22:03:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J53ZdH022161
	for mobile-ip-dist; Thu, 18 Oct 2001 22:03:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J53WOI022154
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 22:03:32 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA01343
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 22:03:35 -0700 (PDT)
Received: from telecom.samsung.co.kr ([165.213.221.4])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14198
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 18 Oct 2001 22:03:33 -0700 (PDT)
Received: from cychong (a22421 [165.213.224.21])
	by telecom.samsung.co.kr (8.11.6/8.11.6) with SMTP id f9J4xQ519395;
	Fri, 19 Oct 2001 13:59:26 +0900 (KST)
Message-ID: <02e101c1585c$091d8690$15e0d5a5@cychong>
From: "Chae-yong Chong" <cychong@metro.telecom.samsung.co.kr>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Das, Kaustubh" <kaustubh.das@intel.com>
References: <8A9A5F4E6576D511B98F00508B68C20A1111D3@orsmsx106.jf.intel.com>
Subject: Re: [mobile-ip] MN-FA authentication - appropriate behavior
Date: Fri, 19 Oct 2001 14:08:04 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9J53WOI022155
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hi.

I think authentication means that the initiator request its validity to the authenticator.
In this case, the authenticator does not care to check the initiator's validity but initiator wants.
As you know the RFC2002 does not state about this case. 
I think the current spec does not have any solution for this case.

If FA selects first solution, just silently discard, there is no way to inform MN that
FA does not want to authenticate the MN. So, the registration would fail over and over.

If FA selects second solution, reject the Request, FA maybe send reply with code 67 "authenticaion failed".
This is not the clear explanation to MN why the FA reject the registration request. 
But I think this is the best solution for this case because the authentication fail mean a 

If FA selects final solution, MN should discard the reply from FA whether it is acceptance or reject. It is 
due to the MN's requirement for processing the Registration Reply. MN just think MN and FA have a
Security association. So if MN got a reply without MN-FA authentication, it should just discard the reply.

But as you know the MN-FA authentication is not really applicable for the real world, I think. 
In the commercial case like 3GPP2, the MN-FA authenticaiton is not mandatory.

Chae-yong

----- Original Message ----- 
From: "Das, Kaustubh" <kaustubh.das@intel.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "Das, Kaustubh" <kaustubh.das@intel.com>
Sent: Friday, October 19, 2001 1:00 PM
Subject: [mobile-ip] MN-FA authentication - appropriate behavior


> Hi All,
> I needed some clarification on the desired FA behavior in the following
> situation
> The setup is 
> 
> MN------------Router-------------------HA
>         |
>         |
>         |
>       FA
> 
> The MN wishes to register through the FA and is configured to use MN-FA
> authentication extension.
> The FA however is not configured to use MN-FA authentication extension. This
> may perhaps be a misconfiguration.
> Now The MN sends out a packet with a MN-FA authentication to the FA. What
> should the FA do?
> 
> Should it:
> 1. Silently discard the packet.
> OR
> 2. Send back a reply to the MN with a reject code. What reject code?
> OR
> 3. Ignore the MN-FA authentication extension, but strip the extension off
> and forward the request to the HA. 
> When a reply comes around it should relay the reply to the MN "without a
> MN-FA authentication extension"
> OR
> 4. Some other behavior.
> 
> Any clarification/ thoughts are greatly appreciated.
> Thanks and regards,
> Kaustubh
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 03:56:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12208
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 03:56:08 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02996;
	Fri, 19 Oct 2001 01:54:57 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18218;
	Fri, 19 Oct 2001 00:54:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J7rwOI022483
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 00:53:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J7rwP3022482
	for mobile-ip-dist; Fri, 19 Oct 2001 00:53:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J7rtOI022475
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 00:53:55 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03612
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 00:53:58 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA23569
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 02:21:27 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9J7rtL31594
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:53:55 +0300
Date: Fri, 19 Oct 2001 10:53:55 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] specific comments/text for RH/HA in SecReqs
Message-ID: <Pine.LNX.4.33.0110191043330.31544-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hello all.

I've tried to put up some specific text on how SecReqs could be enhanced.  
This is not meant to be exclusive of other comments on the subject here, 
just a start.

(btw. I tend to agree with Chalie that the draft is not as clear as it 
could be typographically.  For example, I had no idea whether 
"Classification of attackers" (both parts), threats, the summary table, 
the threat letters and numbers etc. were supposed to correlate somehow).

Most of this would probably need some enhancements, but it's a start I 
hope.

--8<--
3.  Threats on a broad scope introduced by Mobile IPv6
   
==>

Home Address option introduces mostly DoS-related threats against all IPv6
nodes whether mobile or not.  Threat H.3 discusses these.

All MN's must process routing header.  Routing header processing rules   
[RFC2460] implementation should be refined to account for "node-local" 
routing headers.  Unless this is done, it is probable that the processing
of all routing headers is enabled on MN's, possibly on stationary nodes
too.  This is discussed in H.4.

5.  Classification of Attackers

   The following classes of attackers, and threats caused by them, are
   considered:

   -  an arbitrary node, anywhere in the Internet, launching an attack 
      gainst a MN, a CN, or a HA
==>
   -  an arbitrary node, anywhere in the Internet, launching an attack
      against a MN/CN/HA or any IPv6 node implementing MIPv6 features
      (e.g. Home Address option processing)
   
   -  an arbitrary node, anywhere in the Internet, launching an attack
      abusing MIPv6 features against any node in the Internet using a
      MN/CN/HA or any IPv6 node implementing MIPv6 features as a proxy

   Furthermore, we consider the following threats separately:
   
   -  using a previous router as a temporary HA
   
   -  DoS attacks against a CN
   
   -  DoS attacks against a MN

   -  DoS attacks against a HA
   
==>
   -  DoS attacks against any IPv6 node implementing MIPv6 features (like
      Home Address option processing)
   
   -  (DoS attacks against any IPv6 node in the Internet, abusing a node
       which implements MIPv6 features)

6.8.  Other threats, including those that target the Home Agent

H.3.  Use any IPv6 node as a packet reflector

s/CN/any IPv6 node/.

+ and comments in thread ' MIPv6 HA wording and H.3 of SecReqs' earlier.

H.4.  Use MN or any IPv6 node to avoid firewalls and reflect traffic

Scenario H.4:

All mobile nodes must process routing header.  Having to enable routing
header processing for everyone in the Internet is dangerous as it can be
used to reflect traffic and to get around packet filters' access lists
[RHHASEC].

Requirement H.4:

To enable routing header processing for the Home Address assigned on the
same node, it MUST NOT be required for MN to require all routing headers
would be processed and corresponding packets forwarded.

There SHOULD be some form of authorization in the node to forward to the  
specified addresses in the routing header if global routing header
forwarding is disabled.

Threat H.4:

Especially DoS attacks could be routed through CN to lay false trails
which would be it easier for the attacker to hide itself.

Packet filter access lists can be exploited as the destination address is
being rewritten when the packet traverses the network.  This could lead to
security disclosures and unauthorized access.
--8<--

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 04:16:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12322
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 04:16:17 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04996;
	Fri, 19 Oct 2001 01:15:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21055;
	Fri, 19 Oct 2001 01:15:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J8E0OI022675
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:14:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J8E0Zc022674
	for mobile-ip-dist; Fri, 19 Oct 2001 01:14:00 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J8DvOI022667
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:13:57 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20835
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:14:00 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA03228
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 02:41:28 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9J8Dqg12623
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:13:52 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA28985
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:13:52 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9J8DqD77161
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:13:52 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110190813.f9J8DqD77161@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 
In-reply-to: Your message of Thu, 18 Oct 2001 21:19:16 +0300.
             <Pine.LNX.4.33.0110182108360.26862-100000@netcore.fi> 
Date: Fri, 19 Oct 2001 10:13:52 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   > I tried to point out in a note last night that it is enough
   > for relay nodes to follow directives about forwarding to
   > the next node in the list.  In the case needed for Mobile IPv6,
   > this is simple.  A node can authorize itself to forward
   > packets to itself.  In the general case, more persuasion
   > may be needed, but the principle would remain the same.
   
   I just had an idea which might be used to "authenticate" this for _hosts_:
   
   if segments left == 1
    if both addresses are assigned on the node (possibly on the same interface)
     if both addresses are of the same zone (e.g. no global->site/link)
       if there exists a /128 host route to the to-be-swapped address
         assume forwarding to it is allowed
   
=> I believed this was enough but you gave a strong argument
in your answer to Gabriel in favor of a stronger check: address should be
in order a care-of and a home addresses (the binding update list should
give all the needed informations).
BTW as soon as we know exactly what we need, we should go to the IPv6 WG
mailing list, perhaps with a specific document, and of course we should
ask for a slot for the next meeting.

Regards

Francis.Dupont@enst-bretagne.fr

PS: the reference is the Security Considerations of your draft.
PPS: I believe the Interface-local rule is not very applicable
for a mobile multi-homed/multi-interface host: we have to jump
into specific/specialized rules.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 04:32:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12427
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 04:32:04 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09696;
	Fri, 19 Oct 2001 01:32:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22590;
	Fri, 19 Oct 2001 01:31:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J8V6OI022813
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:31:06 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J8V5ll022812
	for mobile-ip-dist; Fri, 19 Oct 2001 01:31:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J8V2OI022805
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:31:02 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04345
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:30:58 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23934
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:31:03 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id SAA29700
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:29:53 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA08253
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:31:02 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <T8RXQTT9>; Fri, 19 Oct 2001 18:31:00 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDB7@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof
	  fs-v4-02.txt
Date: Fri, 19 Oct 2001 18:30:59 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15878.61586F70"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15878.61586F70
Content-Type: text/plain

>  This assumes a few things:
> > 
> > - that the MIP signalling takes up significant
> > bandwidth
> >   and disrupts real time traffic
> > - that there is not enough extra bandwidth for the
> >   MIP signalling on that channel
> > - that there is no reserved signalling bandwidth or
> >   dedicated signalling channel.
> > 
> > Don't think these are assumptions we should rely on.
> 
> Please see my posting earlier this year, in which
> calculations for low bandwidth channels of the
> overhead introduced by MIP signalling run upwards
> of 100 ms or more. This would be enough to introduce a
> noticable disruption in voice traffic. The assumptions
> are based on calculated channel blocking times, and
> are not completely groundless. I can repost the
> numbers if you want, or you can check the archive for
> yourself.
> 
	=> Those calculations also assumed that the 
	voice traffic and the MIP signalling were sharing the 
	same channel, which goes back to the third assumption
	on Karim's list above. 

> > If we talk about real-time and channel access we
> > need to
> > consider QoS, radio realisations etc. but this is
> > complex and varies between wireless systems. I'd
> > prefer
> > if we kept low latency generic and left this work
> > for
> > the radio network implementors.
> > 
> 
> I don't think any of this is necessary. One simply has
> to look at how big the signaling messages are, how
> fast the channel is, and how long the L2 handover
> latency is. If the sum of the latency due to L3
> signaling and L2 handover exceeds user perception,
> then there will be a glitch. 
> 
	=> The point is, these calculations can not be 
	done in IETF for _all_ link layers and future ones.
	The draft offers different levels of support that are
	suited to different mobility scenarios. System 
	and radio interface designers can pick the appropriate 
	solutions accordingly. I believe the draft abstracts 
	the radio limitations to the extent that allows designers to 
	pick the right solution for their system.

	Hesham


------_=_NextPart_001_01C15878.61586F70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] Comments on =
draft-ietf-mobileip-lowlatency-handof  fs-v4-02.txt</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;This assumes a few =
things:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; - that the MIP signalling takes =
up significant</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; bandwidth</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp; and disrupts real =
time traffic</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; - that there is not enough extra =
bandwidth for the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp; MIP signalling on =
that channel</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; - that there is no reserved =
signalling bandwidth or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp; dedicated signalling =
channel.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Don't think these are =
assumptions we should rely on.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please see my posting earlier this =
year, in which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">calculations for low bandwidth =
channels of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">overhead introduced by MIP signalling =
run upwards</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of 100 ms or more. This would be =
enough to introduce a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">noticable disruption in voice =
traffic. The assumptions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are based on calculated channel =
blocking times, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are not completely groundless. I can =
repost the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">numbers if you want, or you can check =
the archive for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">yourself.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Those =
calculations also assumed that the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">voice traffic and =
the MIP signalling were sharing the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">same channel, which =
goes back to the third assumption</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">on Karim's list =
above.</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; If we talk about real-time and =
channel access we</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; need to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; consider QoS, radio realisations =
etc. but this is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; complex and varies between =
wireless systems. I'd</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; prefer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; if we kept low latency generic =
and left this work</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the radio network =
implementors.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't think any of this is =
necessary. One simply has</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to look at how big the signaling =
messages are, how</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">fast the channel is, and how long the =
L2 handover</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">latency is. If the sum of the latency =
due to L3</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signaling and L2 handover exceeds =
user perception,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">then there will be a glitch.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; The point =
is, these calculations can not be </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">done in IETF for =
_all_ link layers and future ones.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The draft offers =
different levels of support that are</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">suited to different =
mobility scenarios. System </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">and radio interface =
designers can pick the appropriate </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">solutions =
accordingly. I believe the draft abstracts </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the radio =
limitations to the extent that allows designers to </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">pick the right =
solution for their system.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15878.61586F70--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 04:56:15 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12746
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 04:56:14 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA16641;
	Fri, 19 Oct 2001 01:55:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25143;
	Fri, 19 Oct 2001 01:55:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J8saOI022968
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:54:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J8sZ7H022967
	for mobile-ip-dist; Fri, 19 Oct 2001 01:54:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J8sVOI022960
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 01:54:32 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9J8sXq11895
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:54:33 +0200 (MET DST)
Date: Fri, 19 Oct 2001 10:49:11 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <20011018170019.9642.qmail@web13906.mail.yahoo.com>
Message-ID: <Roam.SIMC.2.0.6.1003481351.1073.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> In general, the document seems very heavily weighed
> towards MN/CN security threats and very lightly
> weighted towards MN/AR threats. Some of the MN/CN
> threats are redundant. There are 18 threats
> identified for the MN/CN and only two for the MN/AR.
> This is perhaps understandable, given the attention
> the IETF security folks have been focussing on the BU
> security problem, but the MN/AR relationship is, in
> some sense, equally if not more important (it is, for
> example, a MUST and not a SHOULD).

I think Charlie argued that the generic IPv6 threats (which is
what I think you call MN/AR threats) should be removed instead.

The reason the few are present was intended to be examples
where e.g. Neighbor Discovery makes certain attacks possible
and point out that MIPv6 is not expected to solve those.
But if we can get closer to completeness on for those types of
threats I personally think it would make sense to add more of
them. Then we can send the document to the IPNGWG and point
out that e.g. ND needs to be secured better for public access networks.

> The particular threats that we feel need to be added
> are the following:
> 
> 1) A malicious AR could hijack traffic from a trusting
> MN. This was partially identified in the document.
> 
> 2) A theaving MN could gain network access without
> authorization by soliciting a Router Advert, then
> setting up a CoA.

I don't quite understand. Is the MN sending a Router Solicitation or
a Router Advertisement?

> 3) Similar to 2), a theaving MN could gain network
> access without authorization through responding to an
> unsolicited Router Advert, then setting up a CoA.

Also, 

4) a MN could launch a DoS attack against other MNs on the link
by responding to all duplicate address detection probes.

5) any MN could redirect traffic from other MNs by sending one Router
Advertisement announcing itself and sending periodic Router Advertisements
with AR as the source address and a lifetime of zero. This will make
all MNs on the link use the attacker as the default router.

> There are a variety of places within the process of
> network access where these threats could be addressed,
> but I assume since this document is concerned with
> threat analysis, the solutions will be in another
> document.

Yes, and it makes sense pointing of which threats are possible due to
the mechanisms in ND vs. MIPv6 vs. ???

  Erik
 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 07:07:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13865
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 07:07:42 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10310;
	Fri, 19 Oct 2001 05:07:11 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10702;
	Fri, 19 Oct 2001 04:07:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JB6AOI023254
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 04:06:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JB6Afn023253
	for mobile-ip-dist; Fri, 19 Oct 2001 04:06:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JB66OI023246
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 04:06:06 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06481
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 04:06:07 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09739
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 05:05:41 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9JB65B32627
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:06:05 +0300
Date: Fri, 19 Oct 2001 14:06:05 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] Routing Header ipng update? [...]
In-Reply-To: <200110190813.f9J8DqD77161@givry.rennes.enst-bretagne.fr>
Message-ID: <Pine.LNX.4.33.0110191340360.32477-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Fri, 19 Oct 2001, Francis Dupont wrote:
> BTW as soon as we know exactly what we need, we should go to the IPv6 WG
> mailing list, perhaps with a specific document, and of course we should
> ask for a slot for the next meeting.

How does this sound, in pricinple:

--8<--
On Hosts, Routing Header processing MUST be supported, but the processing
MUST NOT be enabled by default.  The enabling of the processing SHOULD be
configurable.

Regardless of the processing setting above, routing headers destined to
the host are further processed if the following applies:

 type == 0 and segments left == 1 and,

 if the to-be-swapped address in Routing Header is either:

   1) a Home Address assigned to the node,
 
     the Routing Header MUST be processed in full. 
 
   2) an address which has been authorized in some way to be a valid 
      target of routing header processing [this is a superset of 1)],

      the Routing Header MAY be processed in full.
--8<--

Problem with this approach is, that the packet filter (without state about 
mobility) cannot know whether the destination address is valid or not if 
someone wants to perform such tests.

IMO, it might be much simpler to just define "Type-2" routing header which
would require property 1) and nothing else.

Note that 1) disregards a pretty theoretical situation where one would
have e.g. separate site-local and global home addresses, and you'd like
more fine-grained control on what is allowed.

This omits (on purpose) the more general case of "node-local routing 
header", because:

 1) it's a complex issue which can't be solved without problems
 2) I don't see any valid need for it :-), does anyone?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 10:07:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19566
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 10:07:32 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14622;
	Fri, 19 Oct 2001 07:07:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10146;
	Fri, 19 Oct 2001 07:06:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JE5ROI023632
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:05:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JE5ROv023631
	for mobile-ip-dist; Fri, 19 Oct 2001 07:05:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JE5NOI023624
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:05:24 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09688
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:05:25 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03129
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:05:24 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA00717;
	Fri, 19 Oct 2001 07:05:24 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JE5NA26081;
	Fri, 19 Oct 2001 07:05:23 -0700
X-mProtect:  Fri, 19 Oct 2001 07:05:23 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdrHZcF6; Fri, 19 Oct 2001 07:05:21 PDT
Message-ID: <3BD03322.D2E6AA69@iprg.nokia.com>
Date: Fri, 19 Oct 2001 07:05:22 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call Comments on 
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
References: <Roam.SIMC.2.0.6.1003481351.1073.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Erik Nordmark wrote:

> I think Charlie argued that the generic IPv6 threats (which is
> what I think you call MN/AR threats) should be removed instead.

I didn't go quite that far.  I agree with you that there is
value in providing information related to mobility somewhere
in the document.

I thought that the generic IPv6 threats should be clearly
labeled as such, and in the case of Neighbor Discovery I
would gather them into either an introductory section,
or else put a more detailed description into an appendix.
Maybe it's best to do both, with the introductory section
pointing to the appendix for details.


Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 10:48:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20504
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 10:48:48 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28228;
	Fri, 19 Oct 2001 08:47:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09698;
	Fri, 19 Oct 2001 07:47:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JEkbOI023797
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:46:37 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JEkboM023796
	for mobile-ip-dist; Fri, 19 Oct 2001 07:46:37 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JEkXOI023789
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:46:33 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01976
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:46:34 -0700 (PDT)
Received: from kestrel.xedia.com (kestrel.xedia.com [198.202.232.189])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27039
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 08:46:09 -0600 (MDT)
Received: from xedia.com ([10.198.100.16])
	by kestrel.xedia.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA60712
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:46:30 -0400 (EDT)
Message-ID: <3BD03C03.3913C795@xedia.com>
Date: Fri, 19 Oct 2001 10:43:15 -0400
From: Kishore Asarpota <kishore@xedia.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mobile-ip@sunroof.eng.sun.com" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Next Connectathon
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I last attended the mobileip Connectathon in CA in March, 01.
Are there plans for next one like that. Who is the contact for that.

kishore



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 10:56:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20675
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 10:56:03 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04709;
	Fri, 19 Oct 2001 08:55:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11477;
	Fri, 19 Oct 2001 07:55:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JEtBOI023901
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:55:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JEtAXD023900
	for mobile-ip-dist; Fri, 19 Oct 2001 07:55:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JEt7OI023893
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:55:07 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16727
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:55:09 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01902
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 07:55:08 -0700 (PDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9JElrm10497;
	Fri, 19 Oct 2001 07:47:53 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn2-603.cisco.com [10.21.114.91])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABE59969;
	Fri, 19 Oct 2001 07:47:37 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011019092443.00b88660@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 19 Oct 2001 10:45:40 -0400
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Cc: Glenn Morrow <gmorrow@nortelnetworks.com>, mramalho@cisco.com
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308EDAA@eaubrnt018.epa.er
 icsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Charlie,

I agree with Hesham's bottom line - that a decision to piggyback
at the sender has implications on the receiver (or the link to the
receiver is on if it too is on a weird L2).

In my email volleys to Rajeev last week ... I demonstrated that
if the other end was also a MN on a similarly constrained
L2 ... that it would be a bad practice to piggyback
*AT LAYER 3* onto a (real-time) media packet.

It seemed like most of the justification (by Rajeev anyway) was
the he wanted the piggyback to "fit" on the (cellular-like,
TDM structured) MAC layer during opportunistic times
(e.g., where ROHC gave significant compression and he
could fit a BU with the media packets). There is probably
a worst-case delay advantage for the BU for doing this in
comparison to the non-media IP traffic on the L2 link.

But this piggybacking is not persuasive for many reasons
(please read the archive .. but it comes down to Hesham's
bottom line that the far-end receiver and other L2s can have
problems with it)

Fundamentally - a BU is end-to-end signalling. Thus, an
ideal packet to piggyback onto is one that has similar
QoS characteristics.

Thus, the ideal piggyback would be to something like a session
signalling packet -  probably characterized by an assured
forwarding type PHB - where you generally desire low
loss and reasonable delay through the network hops. Someone
mentioned a piggyback onto a RSVP packet ... but those
packets undergo additional delay by QoS processing on the
hops (intserv) or COPS queries (diffserv) or both (for mixed
environments) .. so although RSVP is end-to-end signalling,
it can undergo additional delays so as to make it unattractive.

A "bad packet" to piggyback onto would be a media
packet  - probably characterized by an expedited forwarding
type PHB - where you tolerate an occasional loss ( 1 ~ 5%,
but I don't want to get into that debate) but you need *really
low* delay through the hops. This is the type of packet
that some have petitioned for the piggyback - I think
this is a really bad idea and not a healthy L3 argument
for piggybacking.

Thus ... choosing a packet to piggyback onto can be
difficult ... and I have argued is not worth the effort
(again, see the archive).

Besides, if you really desire piggybacking for your L2
link ... there is an opportunity to have your cake and eat
it too. Design a L2 piggyback of the non-piggybacked L3 BU
for your link ... and specify it in L2 bodies (e.g., IEEE,
3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... ).

That is ... specify that if you are queuing a real-time
packet and you have room for the BU on your L2
timeslot (perhaps due to ROHC compressing of
a real-time packet) ... fit the BU and the media
packet on the L2 link timeslot! But be sure to
de-piggyback the L3 BU at the other end of your
L2 link!

By doing this you de-couple the piggyback debate out of
the IETF ... yet still accomplish your ends (efficiency
and delay on the L2 link). And it works for both sides ... if
the other end has a similarly constrained link. Please
comment if you (or anyone on the list) can think of a
reason why this is not a good approach (other than
efficiency arguments on the non-access links - given
average BU frequencies the gain is not significant).

Additionally, Mike Thomas (and others) have argued for
not piggybacking for security related reasons. These
arguments effectively plea for de-coupling of the problems
(a non-piggybacked L3 BU).

In closing, I'd say that the mobile-ip list debates of the last
week or so have effectively argued that the end-link efficiencies
gained by piggybacking are at worst harmful and at
best gain the QoS characteristics of the packet piggybacked
onto (which is not  what you want for some potential
piggybacks). Thus, I'd say the "best IP definition" (your
words) would argue for *not* piggybacking. The arguments
are technical ... but not the complexity-related, as your
previous email seemed to infer.

As I stated in my previous email, I think I am being a
realist here ... and I do not especially care to be
argumentative or divisive ... and have stated my
technical objections to L3 piggybacking.

And unlike those who only complain on the list,  provided
a way for those who desire piggybacking on arbitrary
L2s a way to accomplish the efficiency or delay advantage
(on the L2 link) they desire ... in a way that is not harmful
to the packets that would have been piggybacked onto.

Please respond to the technical issues before further
pursuing the pro-piggybacking case.

Regards,

Michael Ramalho


At 12:07 PM 10/19/2001 +1000, Hesham Soliman (EPA) wrote:
>Hello Charlie,
>
>Glenn Morrow said something which has resonated with me during  the last 
>week.
>
> > I guess people just don't agree on the value of piggybacking, the 
> affect of  > delays incurred by segmentation and whether the access 
> network should drive  > the IP definitions or the access networks should 
> adapt to the IP definitions.
>
>This seems to hit the spot exactly.  We have disagreements, but I 
>would  like to suggest that we should make the IP definitions based on 
>what's  good for IP instead of the restrictions imposed by the unadapted 
>access  networks (or, worse yet, the least common denominator of all 
>access  networks!).
>
>Applied to the discussion about whether Binding Update should be 
>carried  along with payload, this would mean that we should have the 
>feature if  it fits naturally in IP, and if there are going to be networks 
>which can  use the feature to good advantage.  The reasons why this 
>feature are  advantageous are outlined in the draft from Jari Arkko, along 
>with the  costs of the feature.  Some networks will gladly pay the cost, 
>and some  won't, for a myriad of reasons.
>
>I am very much in favor of making the best IP definition, and along 
>the  way making sure that it can be used to fit well with existing 
>access  networks.
>
>=> Sounds good. but below is where the problems begin IMHO.   The current 
>proposal with Destination Options does do that.  There is no requirement 
>that any implementation MUST supply payload  in packets that contain a 
>Binding Update, and almost all of the  complication from processing 
>payload with a Destination Option comes  on the sending side.  So I don't 
>agree with arguments based on the  extra complexity.  If some 
>implementations don't want to undertake  the extra complexity, that is 
>fine, but those groups should not be  allowed to penalize the 
>implementations that wish to offer the better  performance by the magic of 
>making it illegal to do so.  That is not  fair in my book.
>
>=> Well the problem is that IP is access independant :)  So while my IPv6 
>MN may refuse to piggyback, my HA  or CN might decide that piggybacking is 
>a good idea  and by that decision it is harming me.  This is despite the 
>fact that my MN does not piggyback.  So the problem can not be solved 
>based on a decision  made by one side.  This is the main problem, keeping 
>/removing piggybacking  is an issue that will affect the sender and the 
>receiver,  regardless of the design choices that each node may  make.
The key point is *the receiver* can be adversely affected by the decision.
>   Hesham


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:11:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22348
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:11:05 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08144;
	Fri, 19 Oct 2001 09:10:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01613;
	Fri, 19 Oct 2001 09:10:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JG9JOI024257
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:09:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JG9IGw024256
	for mobile-ip-dist; Fri, 19 Oct 2001 09:09:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JG9FOI024249
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:09:15 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00620
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:09:17 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08881
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:09:17 -0700 (PDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA14002;
	Fri, 19 Oct 2001 11:03:37 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9JG3ZC25462;
	Fri, 19 Oct 2001 11:03:35 -0500 (CDT)
Message-ID: <3BD05056.C911BA49@alcatel.com>
Date: Fri, 19 Oct 2001 11:09:58 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: Glenn Morrow <gmorrow@nortelnetworks.com>, mramalho@cisco.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4.3.2.7.2.20011019092443.00b88660@mira-sjc5-9.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Agreed almost entirely.
IMHO piggpacking on RSVP is another issue, yes there might be advantages of
doing it, so it is dealt with separately, as in
draft-ietf-aaa-diameter-mobileip-07.txt.

Regards,


"Michael A. Ramalho" wrote:

> Charlie,
>
> I agree with Hesham's bottom line - that a decision to piggyback
> at the sender has implications on the receiver (or the link to the
> receiver is on if it too is on a weird L2).
>
> In my email volleys to Rajeev last week ... I demonstrated that
> if the other end was also a MN on a similarly constrained
> L2 ... that it would be a bad practice to piggyback
> *AT LAYER 3* onto a (real-time) media packet.
>
> It seemed like most of the justification (by Rajeev anyway) was
> the he wanted the piggyback to "fit" on the (cellular-like,
> TDM structured) MAC layer during opportunistic times
> (e.g., where ROHC gave significant compression and he
> could fit a BU with the media packets). There is probably
> a worst-case delay advantage for the BU for doing this in
> comparison to the non-media IP traffic on the L2 link.
>
> But this piggybacking is not persuasive for many reasons
> (please read the archive .. but it comes down to Hesham's
> bottom line that the far-end receiver and other L2s can have
> problems with it)
>
> Fundamentally - a BU is end-to-end signalling. Thus, an
> ideal packet to piggyback onto is one that has similar
> QoS characteristics.
>
> Thus, the ideal piggyback would be to something like a session
> signalling packet -  probably characterized by an assured
> forwarding type PHB - where you generally desire low
> loss and reasonable delay through the network hops. Someone
> mentioned a piggyback onto a RSVP packet ... but those
> packets undergo additional delay by QoS processing on the
> hops (intserv) or COPS queries (diffserv) or both (for mixed
> environments) .. so although RSVP is end-to-end signalling,
> it can undergo additional delays so as to make it unattractive.
>
> A "bad packet" to piggyback onto would be a media
> packet  - probably characterized by an expedited forwarding
> type PHB - where you tolerate an occasional loss ( 1 ~ 5%,
> but I don't want to get into that debate) but you need *really
> low* delay through the hops. This is the type of packet
> that some have petitioned for the piggyback - I think
> this is a really bad idea and not a healthy L3 argument
> for piggybacking.
>
> Thus ... choosing a packet to piggyback onto can be
> difficult ... and I have argued is not worth the effort
> (again, see the archive).
>
> Besides, if you really desire piggybacking for your L2
> link ... there is an opportunity to have your cake and eat
> it too. Design a L2 piggyback of the non-piggybacked L3 BU
> for your link ... and specify it in L2 bodies (e.g., IEEE,
> 3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... ).
>
> That is ... specify that if you are queuing a real-time
> packet and you have room for the BU on your L2
> timeslot (perhaps due to ROHC compressing of
> a real-time packet) ... fit the BU and the media
> packet on the L2 link timeslot! But be sure to
> de-piggyback the L3 BU at the other end of your
> L2 link!
>
> By doing this you de-couple the piggyback debate out of
> the IETF ... yet still accomplish your ends (efficiency
> and delay on the L2 link). And it works for both sides ... if
> the other end has a similarly constrained link. Please
> comment if you (or anyone on the list) can think of a
> reason why this is not a good approach (other than
> efficiency arguments on the non-access links - given
> average BU frequencies the gain is not significant).
>
> Additionally, Mike Thomas (and others) have argued for
> not piggybacking for security related reasons. These
> arguments effectively plea for de-coupling of the problems
> (a non-piggybacked L3 BU).
>
> In closing, I'd say that the mobile-ip list debates of the last
> week or so have effectively argued that the end-link efficiencies
> gained by piggybacking are at worst harmful and at
> best gain the QoS characteristics of the packet piggybacked
> onto (which is not  what you want for some potential
> piggybacks). Thus, I'd say the "best IP definition" (your
> words) would argue for *not* piggybacking. The arguments
> are technical ... but not the complexity-related, as your
> previous email seemed to infer.
>
> As I stated in my previous email, I think I am being a
> realist here ... and I do not especially care to be
> argumentative or divisive ... and have stated my
> technical objections to L3 piggybacking.
>
> And unlike those who only complain on the list,  provided
> a way for those who desire piggybacking on arbitrary
> L2s a way to accomplish the efficiency or delay advantage
> (on the L2 link) they desire ... in a way that is not harmful
> to the packets that would have been piggybacked onto.
>
> Please respond to the technical issues before further
> pursuing the pro-piggybacking case.
>
> Regards,
>
> Michael Ramalho
>
> --

Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:13:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22434
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:13:56 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10466;
	Fri, 19 Oct 2001 10:12:44 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02287;
	Fri, 19 Oct 2001 09:12:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGC8OI024329
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:12:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGC8WI024328
	for mobile-ip-dist; Fri, 19 Oct 2001 09:12:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGC4OI024316
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:12:04 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01115
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:12:06 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11842
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:40:46 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9JGC2g27709
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:12:02 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA08846
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:12:02 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9JGC2D80126
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:12:02 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110191612.f9JGC2D80126@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Multi-homing MIPv6??? 
In-reply-to: Your message of Thu, 11 Oct 2001 12:41:08 +0200.
             <3BC57744.1166BAE4@era.ericsson.se> 
Date: Fri, 19 Oct 2001 18:12:02 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:
   
   Seriously, multihoming comes in two flavors:
    - One interface that is connected to a multihomed site

=> I proposed to use mobility mechanisms for this case (the idea
is mobility provides a way to use an alternate address when an
uplink of the multihomed site fails: resilience for already opened
connections).

    - Multiple interfaces connected to different sites
   
=> my purpose when I implemented mobile IPv6 was to support switch
between different link technologies, for instance (my favourite :-)
replace my expensive 9600bits/s GSM data by a free 100Mbits/s Ethernet.
So not only there is an issue in the choice of the best interface,
but the availability is highly dynamic. BTW simultaneous usage is
even more complex (I know some research works about this).

   In the first case the MN has one default router (could be multiple
   routers too)                                              ^^^^^^^^

=> likely (i.e. if you have need/money to get many uplinks you should
duplicate internal routers too :-).

   and receives RAs with multiple prefixes in them. The MN
   would have to choose the correct source and destination address
   according to draft-ietf-ipngwg-default-addr-select-06.txt.
   
   In the second case the MN for sure has more than one default router. It
   will have a hard time choosing an appropriate next hop just following
   RFC2461. Mobile IPv6 gives the implementer free hands, while
   draft-ietf-ipngwg-router-selection-00.txt provides some useful
   guidelines.
   
=> this is not enough because the issue is the choice of the
"default link" (which drives the whole thing) between independent sites.
For instance if an interface is connected to the home link you should
prefer it (a simple rule but this has to be explicitely in a policy).

   The problems we had were related to that regular ND is not defined for
   multiple interfaces.
   
=> I disagree: ND is defined for routers which have commonly multiple
interfaces. The problem is for hosts with multiple interfaces.
And for instance (not a criticism) the router selection draft doesn't
help when a host is attached to independent sites, i.e. an extra policy
is needed (but there already are a lot of multi-interface hosts so
the problem is more no-spec/no-common-solution than no good solution
is known).
   
   >      For the second point, there are some implementations
   >      out there that allow attaching the Home address to
   >      a "virtual" interface, hence giving hosts the flexibility
   >      of splitting their flows on different interfaces.
   
=> I believe this is the best way (i.e. I advice all new implementors
to do that).

   Using different care-of addresses on different interfaces is one aspect
   of multihoming with MIPv6.
   
=> this is the defaut in the second case.

   Another is when the home subnet is multihomed and you will have multiple
   home addresses.
   
=> i.e. when can get second and first cases together.

   Yet another is when you have multiple home networks (because you have
   multiple interfaces or for some other reason) and each is generating a
   set of home addresses.
   
=> you don't need multiple home networks in order to get a very complex
situation (:-).

   I figure SCTP could be made to do similar things, but it is not designed
   for mobility.
   
=> I didn't read last address management in SCTP drafts but if SCTP has
(or shall have) address list management it has no fallback (e.g.
home agent) mechanism so mobile to mobile is not fully supported.

   Mobile IPv6 is very different because it focuses on a static home
   address that is visible to the upper layers while the actual addresses
   used are hidden.
   
=> Mobile IPv6 is more a two level (identifier/routing) beast than SCTP.

   BTW, has anyone tried Mobile IPv6 together with home network multihoming

=> yes, a colleague of mine seems to believe more prefixes you have,
better it is (:-).

   or renumbering?
   
=> my first answer describes something that you should like (PS:
real life renumbering takes days so has no fun :-).

Thanks

Francis.Dupont@enst-bretagne.fr

PS: Mattias, you should come or send someone to the ETSI IPv6 plugtest
in order to test codes in these interesting cases (BTW there will be
a lot of IEEE 802.11b for cellular addicts too).


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:34:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23288
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:34:10 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28969;
	Fri, 19 Oct 2001 10:33:44 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07723;
	Fri, 19 Oct 2001 09:33:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGWrOI024498
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:32:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGWrsc024497
	for mobile-ip-dist; Fri, 19 Oct 2001 09:32:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGWnOI024490
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:32:49 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24334
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:32:52 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25750
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:01:33 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9JGWlg32457
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:32:47 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA09148
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:32:47 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9JGWlD80356
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:32:47 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110191632.f9JGWlD80356@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Requirements for non-MIPv6 implementations [MIPv6 - Focus of the security discussion] 
In-reply-to: Your message of Wed, 10 Oct 2001 21:58:12 +0300.
             <Pine.LNX.4.33.0110102118200.16576-100000@netcore.fi> 
Date: Fri, 19 Oct 2001 18:32:47 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   There's a lot of life outside mobile-ip.  A lot of IPv6 implementations
   will very probably never process Binding Updates, Home Address options and
                                                     ^^^^^^^^^^^^^^^^^^^^
   what not unless they are verifiably secure.  No amount of MUST would
   change this, (hopefully) only make the draft harder to pass in the IESG if
   they're acting responsibly.

=> if you really believe that you should ask for a knob per CN
which falls back to the bidir MN-HA tunnel so:
 - many current Mobile IPv6 implementation are able to send traffic
   without H@ options (mine for instance because H@ support was
   (and still is) very far from to be ubiquous
 - this is very easy to implement in case there is not (yet) supported
 - Charlie Perkins still asks for some lines describing the
   ultra-safe/ultra-not-optimized option. Help needed!

   Please do not try to enforce (unsound) MUST rules on non-mipv6
   implementations.  What's done with MIPv6 with no requirements for
   non-mobile nodes might be viewed as a "mobile-ip wg problem", but the
   pollution of all the IPv6 is a more general worry :-).
   
   .. I most definitely hope I misunderstood something in the idea ..
   
=> you have just asked us to choose between the MIPv6 >> MIPv4 dream
and to make MIPv6 as poor as MIPv4 (no route optimization + reverse tunnels)
in the global Internet...

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:41:10 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23572
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:41:09 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22060;
	Fri, 19 Oct 2001 09:40:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07560;
	Fri, 19 Oct 2001 09:38:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGb5OI024594
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:37:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGb5vm024593
	for mobile-ip-dist; Fri, 19 Oct 2001 09:37:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGb2OI024586
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:37:02 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25405
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:37:04 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01951
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:36:38 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9JGb1g00472
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:37:01 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA09251
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:37:01 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9JGb1D80390
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 18:37:01 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110191637.f9JGb1D80390@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Requirements for non-MIPv6 implementations [MIPv6 - Focus of thesecurity discussion] 
In-reply-to: Your message of Thu, 11 Oct 2001 10:48:15 CDT.
             <933FADF5E673D411B8A30002A5608A0E5D951C@zrc2c012.us.nortel.com> 
Date: Fri, 19 Oct 2001 18:37:01 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
 In your previous mail you wrote:

   In relation to changing the BU processing to a MUST from a SHOULD for CN's:
   
=> to try to force one's hand is a last chance solution (i.e. in general
not a solution at all :-).

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:42:50 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23662
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:42:50 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07294;
	Fri, 19 Oct 2001 10:41:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08915;
	Fri, 19 Oct 2001 09:41:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGf2OI024761
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:41:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGf2RY024760
	for mobile-ip-dist; Fri, 19 Oct 2001 09:41:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGevOI024753
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:40:58 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09054
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:41:00 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02651
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:41:00 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA08401;
	Fri, 19 Oct 2001 09:40:57 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JGevj22484;
	Fri, 19 Oct 2001 09:40:57 -0700
X-mProtect:  Fri, 19 Oct 2001 09:40:57 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdD3TpDp; Fri, 19 Oct 2001 09:40:55 PDT
Message-ID: <3BD05797.FBA8FECA@iprg.nokia.com>
Date: Fri, 19 Oct 2001 09:40:55 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Michael A. Ramalho" <mramalho@cisco.com>
CC: mobile-ip@sunroof.eng.sun.com, Rajeev Koodli <rajeev.koodli@nokia.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4.3.2.7.2.20011019092443.00b88660@mira-sjc5-9.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Michael,

Thanks for your note.

> I agree with Hesham's bottom line - that a decision to piggyback
> at the sender has implications on the receiver (or the link to the
> receiver is on if it too is on a weird L2).

I want to characterize this as the result of another decision.

Forget piggybacking for a moment.  What if someone sends an
ICMP message to the receiver?  What if another application sends
a TCP SYN to the receiver?

In the scenarios you refer to, the decision has been taken to design
the bandwith-constained link to only handle connection-oriented
traffic.  One could argue that this goes against some basic
Internet principle or another, but instead I would just like to
emphasize that we shouldn't be pushed to shoehorn IP for _all_
links into restrictions that are motivated by _some_ links.
Furthermore, it is my belief that future links with the same
bandwidth constraints as are driving the current discussion will
still beneficially allow IP traffic without such heavy penalties
against non-uniform higher-level protocol packetization.

> It seemed like most of the justification (by Rajeev anyway) was
> the he wanted the piggyback to "fit" on the (cellular-like,
> TDM structured) MAC layer during opportunistic times
> (e.g., where ROHC gave significant compression and he
> could fit a BU with the media packets). There is probably
> a worst-case delay advantage for the BU for doing this in
> comparison to the non-media IP traffic on the L2 link.

I read this as a particular response to the suggestion that
highly structured MACs couldn't handle the Binding Update.
I found his response to be reasonable, which is to say that
reasonable engineers could make it work.

> But this piggybacking is not persuasive for many reasons
> (please read the archive .. but it comes down to Hesham's
> bottom line that the far-end receiver and other L2s can have
> problems with it)

I agree that they _can_ have problems with it.  I also believe
that these problems will be overcome, and that some L2s do
not have the same problems.

> Fundamentally - a BU is end-to-end signalling. Thus, an
> ideal packet to piggyback onto is one that has similar
> QoS characteristics.

But we aren't supposed to be designing purely for the QoS case.
Furthermore, I think that the QoS story for radio access networks
still has a few unwritten chapters.  When they're written, I also
think that including a Binding Update along with the payload will
be considered a very useful feature.  In face, we're trying to
draft out some ideas for those unwritten chapters in our group
already, and we do see the benefits.  For instance, it matters
for context transfer whether we can use Destination Options
or not.
            ...........

> Thus ... choosing a packet to piggyback onto can be
> difficult ... and I have argued is not worth the effort
> (again, see the archive).

Maybe it's not so hard, if the correspondent node provides a
hint.  For instance, this could be done as part of the setup
for the Mobility Security Association.  If the correspondent
node is communicating over a link that has the constraints you
have described, then it can request that the mobile node should
send Binding Updates in separate packets.  If the correspondent
node _begins_, at some point during its communication (*), to
encounter link constaints that disfavor any destination
options along with data (notice this is a more general problem
anyway, regardless of Binding Updates), then we could arrange
for this information to come back as a status for the Binding
Acknowledgement.

(*) -- we should keep in mind that IP-level solutions SHOULD
       (MUST, even?) allow for changing care-of addresses between
       different media, not just the same medium at a different
       point of attachment.  And, that correspondent nodes are
       also likely to be mobile nodes.

The point is not to design the solution here, but to point out
that it's a more general problem, and that solutions are at hand.

> Besides, if you really desire piggybacking for your L2
> link ... there is an opportunity to have your cake and eat
> it too. Design a L2 piggyback of the non-piggybacked L3 BU
> for your link ... and specify it in L2 bodies (e.g., IEEE,
> 3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... ).

             ...........

Your suggestion implies that there are no benefits at the
receiving end, but I think that the benefits at the receiving
end pretty much mirror those at the sender -- as long as we
can protect against disadvantages as have been pointed out.

> In closing, I'd say that the mobile-ip list debates of the last
> week or so have effectively argued that the end-link efficiencies
> gained by piggybacking are at worst harmful and at
> best gain the QoS characteristics of the packet piggybacked
> onto (which is not  what you want for some potential
> piggybacks). Thus, I'd say the "best IP definition" (your
> words) would argue for *not* piggybacking. The arguments
> are technical ... but not the complexity-related, as your
> previous email seemed to infer.

Some people have made arguments from complexity.  My arguments
are in favor of using Destination Options as designed -- as
information useful for the receiver that belongs in packets
with payload.  All of the arguments so far on this subject are
really arguments against Destination Options, motivated by the
constraints placed by links designed for connection-oriented
operation quite some years ago.  I don't suggest we should ignore
such links -- far from it!!  I am naturally very responsive to
the needs to have excellent performance across such links.

I think it is obvious that for bandwidth-constrained,
RTS/CTS-style links, that we should minimize the number
of times that each mobile node (among possibly many thousands)
has to acquire the media.  Plus we should remain sensitive to
minimizing the total data volume and the additional overheads
for extra packets (retuning, etc.).  There has been a marked
tendency to disregard these details in many IETF protocols,
and each bit of overhead does add up, eventually to a significant
performance loss.

> As I stated in my previous email, I think I am being a
> realist here ... and I do not especially care to be
> argumentative or divisive ... and have stated my
> technical objections to L3 piggybacking.

Yes, I find that your notes are eminently reasonable, and I will
try to live up to the same standards.  I have tried to do so
in my discussion about the benefits for using Destination Options.

> Please respond to the technical issues before further
> pursuing the pro-piggybacking case.

I hope this counts!

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:45:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23743
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:45:00 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23933;
	Fri, 19 Oct 2001 09:43:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08296;
	Fri, 19 Oct 2001 09:40:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGdQOI024648
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGdPXe024647
	for mobile-ip-dist; Fri, 19 Oct 2001 09:39:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGdKOI024640
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:20 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09365
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:15 -0700 (PDT)
Received: from fridge.docomo-usa.com ([216.98.102.228])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04158
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:38:54 -0600 (MDT)
Received: from DOCOMOALPER (dhcp98.docomo-usa.com [172.21.96.98])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9JGdOv21092
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:24 -0700 (PDT)
Message-ID: <097c01c15921$1df06090$626015ac@DOCOMOALPER>
From: "Alper Yegin" <alper@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <3BD03C03.3913C795@xedia.com>
Subject: Re: [mobile-ip] Next Connectathon
Date: Fri, 19 Oct 2001 21:38:51 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Kishore,

Please contact Samita.Chakrabarti@sun.com.

alper
DoCoMo USA Labs

----- Original Message ----- 
From: "Kishore Asarpota" <kishore@xedia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Friday, October 19, 2001 7:43 AM
Subject: [mobile-ip] Next Connectathon


> I last attended the mobileip Connectathon in CA in March, 01.
> Are there plans for next one like that. Who is the contact for that.
> 
> kishore
> 
> 



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:45:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23787
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:45:50 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24271;
	Fri, 19 Oct 2001 09:44:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07942;
	Fri, 19 Oct 2001 09:40:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGdAOI024638
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGdA93024637
	for mobile-ip-dist; Fri, 19 Oct 2001 09:39:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGd7OI024630
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:07 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08742
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:09 -0700 (PDT)
Received: from web13901.mail.yahoo.com (web13901.mail.yahoo.com [216.136.175.27])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA24969
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:39:09 -0700 (PDT)
Message-ID: <20011019163909.50762.qmail@web13901.mail.yahoo.com>
Received: from [216.98.102.225] by web13901.mail.yahoo.com via HTTP; Fri, 19 Oct 2001 09:39:09 PDT
Date: Fri, 19 Oct 2001 09:39:09 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: <Roam.SIMC.2.0.6.1003481351.1073.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Erik,

> But if we can get closer to completeness on for
> those types of
> threats I personally think it would make sense to
> add more of
> them. Then we can send the document to the IPNGWG
> and point
> out that e.g. ND needs to be secured better for
> public access networks.
> 

Agreed. Charlie's proposal to put them in an appendix 
seems like the best route.

> 
> > 2) A theaving MN could gain network access without
> > authorization by soliciting a Router Advert, then
> > setting up a CoA.
> 
> I don't quite understand. Is the MN sending a Router
> Solicitation or
> a Router Advertisement?
> 

It is sending a Solicitation. If the access router
is not required to authenticate the Solicitation, then
an unauthorized MN could gain access.

> > 3) Similar to 2), a theaving MN could gain network
> > access without authorization through responding to
> an
> > unsolicited Router Advert, then setting up a CoA.
> 
 

In this case, the MN is responding to an unsolicited
Router Advert by performing address autoconfiguration.
With stateful address configuration, I would assume
that DHCP security could be used to determine
whether the MN is authorized for an address. So
the issue here is that there needs to be some way to
perform authentication on address autoconfiguration
messaging.

> 4) a MN could launch a DoS attack against other MNs
> on the link
> by responding to all duplicate address detection
> probes.
> 
> 5) any MN could redirect traffic from other MNs by
> sending one Router
> Advertisement announcing itself and sending periodic
> Router Advertisements
> with AR as the source address and a lifetime of
> zero. This will make
> all MNs on the link use the attacker as the default
> router.
> 
> > There are a variety of places within the process
> of
> > network access where these threats could be
> addressed,
> > but I assume since this document is concerned with
> > threat analysis, the solutions will be in another
> > document.
> 
> Yes, and it makes sense pointing of which threats
> are possible due to
> the mechanisms in ND vs. MIPv6 vs. ???
> 

I think the threats you've outlined above are clearly
not MIPv6 related, but, as I mentioned in an earlier
response, they are made worse by mobility because you
cannot secure a physical network access point.

There are some threats that require authentication on
the MN/AR exchange (1 and 2 in my original message,
also something similar to 1 is dicusssed in the
draft).
There are others, which you outline above, that
involve ND and address autoconfig. In addition, there
is a need to more thoroughly think through security if
stateful address config is needed.

A short summary of the threats in an appendix would be
useful. In addition to IPNG, I think URP will need to
be involved (presuming it gets chartered). Prior to
the authentication of any ND or address autoconfig
messaging, there needs to be some kind of AAA exchange
in order for the proper initial conditions to be set
up.

                 jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:48:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23916
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:48:39 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25978;
	Fri, 19 Oct 2001 09:47:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09828;
	Fri, 19 Oct 2001 09:44:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGhROI024942
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:43:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGhQUX024941
	for mobile-ip-dist; Fri, 19 Oct 2001 09:43:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGhNOI024928
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:43:23 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09554
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:43:25 -0700 (PDT)
Received: from web13907.mail.yahoo.com (web13907.mail.yahoo.com [216.136.175.70])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA27780
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:43:25 -0700 (PDT)
Message-ID: <20011019164325.75455.qmail@web13907.mail.yahoo.com>
Received: from [216.98.102.225] by web13907.mail.yahoo.com via HTTP; Fri, 19 Oct 2001 09:43:25 PDT
Date: Fri, 19 Oct 2001 09:43:25 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof   fs-v4-02.txt
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308EDB7@eaubrnt018.epa.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hesham,

> 	=> Those calculations also assumed that the 
> 	voice traffic and the MIP signalling were sharing
> the 
> 	same channel, which goes back to the third
> assumption
> 	on Karim's list above. 
> 

Not to belabor the point, but that is exactly what the
wording in my proposal was attempting to address.
If the voice traffic and MIP signaling are not
sharing the same channel, then there is no point in
implementing HTT. If you think the wording does not
capture that, then by all means please propose
something that is more precise.


> 	=> The point is, these calculations can not be 
> 	done in IETF for _all_ link layers and future ones.
> 	The draft offers different levels of support that
> are
> 	suited to different mobility scenarios. System 
> 	and radio interface designers can pick the
> appropriate 
> 	solutions accordingly. I believe the draft
> abstracts 
> 	the radio limitations to the extent that allows
> designers to 
> 	pick the right solution for their system.
> 

Precisely. Which is why I believe that it is important
to specify that a radio protocol should implement HTT
if there is a problem with signaling obstructing real
time traffic.

It sounds as if we are in violent agreement. :-)

                    jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 12:57:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24410
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 12:57:45 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00648;
	Fri, 19 Oct 2001 09:57:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13164;
	Fri, 19 Oct 2001 09:56:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGt2OI025190
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:55:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JGt21h025189
	for mobile-ip-dist; Fri, 19 Oct 2001 09:55:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JGswOI025182
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:54:58 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12706
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:55:01 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18705
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:54:31 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9JGt9m12532
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 09:55:09 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM06754;
	Fri, 19 Oct 2001 09:54:19 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09163; Fri, 19 Oct 2001 09:54:41 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.23249.441570.571164@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 09:54:41 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
In-Reply-To: <20011019163909.50762.qmail@web13901.mail.yahoo.com>
References: <Roam.SIMC.2.0.6.1003481351.1073.nordmark@bebop.france>
	<20011019163909.50762.qmail@web13901.mail.yahoo.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

James Kempf writes:
 > Hi Erik,
 > 
 > > But if we can get closer to completeness on for
 > > those types of
 > > threats I personally think it would make sense to
 > > add more of
 > > them. Then we can send the document to the IPNGWG
 > > and point
 > > out that e.g. ND needs to be secured better for
 > > public access networks.
 > > 
 > 
 > Agreed. Charlie's proposal to put them in an appendix 
 > seems like the best route.
 > 
 > > 
 > > > 2) A theaving MN could gain network access without
 > > > authorization by soliciting a Router Advert, then
 > > > setting up a CoA.
 > > 
 > > I don't quite understand. Is the MN sending a Router
 > > Solicitation or
 > > a Router Advertisement?
 > > 
 > 
 > It is sending a Solicitation. If the access router
 > is not required to authenticate the Solicitation, then
 > an unauthorized MN could gain access.

Um, not necessarily. You _could_ overlay admission
control onto RA/RS, but it isn't the only way to
produce a choke point. I don't know where URP
landed after last IETF, but it's not inconceivable
that the RA could just advertise the authentication 
mechanism/realm and that another protocol could do
the actual authentication work. The router just
needs to enforce a fairly restricted ACL in the
mean time. 

The nice thing about doing this is that you can
use normal mechanisms to enroll people for casual
use (eg, allow traffic to your enrollment web
site), and other things by granting limited IP
connectivity.

 > In this case, the MN is responding to an unsolicited
 > Router Advert by performing address autoconfiguration.
 > With stateful address configuration, I would assume
 > that DHCP security could be used to determine
 > whether the MN is authorized for an address.

There is no "DHCP security" that I'm aware of.
Maybe that's changed recently, but it's certainly
not common. Also: you've factored out L2
authentication mechanisms. 802.1x(f?) and DOCSIS
are two examples of admission control that take
place at L2 on ethernet-like MAC's. That's another
approach, though truth be told, I'd be happier
with a common IP solution so all those folks can
do something else with their time (cf WEP).

	     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 13:11:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24738
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 13:11:48 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04287;
	Fri, 19 Oct 2001 11:11:21 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17237;
	Fri, 19 Oct 2001 10:11:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JHA5OI025545
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:10:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JHA5KZ025544
	for mobile-ip-dist; Fri, 19 Oct 2001 10:10:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JHA2OI025537
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:10:02 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17339
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:09:57 -0700 (PDT)
Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA20864
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:39:21 -0600 (MDT)
Message-ID: <20011019171002.71509.qmail@web13905.mail.yahoo.com>
Received: from [216.98.102.225] by web13905.mail.yahoo.com via HTTP; Fri, 19 Oct 2001 10:10:02 PDT
Date: Fri, 19 Oct 2001 10:10:02 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: <15312.23249.441570.571164@thomasm-u1.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Michael,

> Um, not necessarily. You _could_ overlay admission
> control onto RA/RS, but it isn't the only way to
> produce a choke point. I don't know where URP
> landed after last IETF, but it's not inconceivable
> that the RA could just advertise the authentication 
> mechanism/realm and that another protocol could do
> the actual authentication work. The router just
> needs to enforce a fairly restricted ACL in the
> mean time. 
> 
> The nice thing about doing this is that you can
> use normal mechanisms to enroll people for casual
> use (eg, allow traffic to your enrollment web
> site), and other things by granting limited IP
> connectivity.
> 

Good point. 

> There is no "DHCP security" that I'm aware of.
> Maybe that's changed recently, but it's certainly
> not common. Also: you've factored out L2
> authentication mechanisms. 802.1x(f?) and DOCSIS
> are two examples of admission control that take
> place at L2 on ethernet-like MAC's. That's another
> approach, though truth be told, I'd be happier
> with a common IP solution so all those folks can
> do something else with their time (cf WEP).
> 

I believe the DHCP group has been working on something
involving security, at least, I recall seeing a draft
go by awhile ago. I don't know where it is at.

I also think that having a common IP solution is
preferable to having a collection of L2 mechanisms,
though I think there are cases where L2 mechanisms may
also be desirable, for performance or other reasons
(fast handoff for example). Certainly, for admission
to network access an URP-like solution is more
desirable than having each L2 specify their own. 

                     jak



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 13:17:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24941
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 13:17:50 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10547;
	Fri, 19 Oct 2001 10:17:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19082;
	Fri, 19 Oct 2001 10:17:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JHGBOI025644
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:16:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JHGBam025643
	for mobile-ip-dist; Fri, 19 Oct 2001 10:16:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JHG8OI025636
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:16:08 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06321
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:16:10 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24733
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:45:32 -0600 (MDT)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA16415;
	Fri, 19 Oct 2001 12:16:08 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9JHG2O13696;
	Fri, 19 Oct 2001 12:16:02 -0500 (CDT)
Message-ID: <3BD06151.A85C60EE@alcatel.com>
Date: Fri, 19 Oct 2001 12:22:25 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby <seamoby@cdma-2000.org>,
        "mobile-ip@sunroof.eng.sun.com" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] draft-guri-seamoby-paging-triggers-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello,
  We submitted an I-D on Layer 2 API for Paging, until it is posted at
the IETF drafts directory, you can access it from:
http://www.geocities.com/bsarikaya/draft-guri-seamoby-paging-triggers-00.txt

  We hereby volunteer to combine this one with handover triggers defined
in
draft-kempf-beth-ipv6-02.txt and
draft-manyfolks-l2-mobilereq-00.txt

if requested in order to contribute towards defining  an Layer 2 API for
Mobility.

  Comments are welcome.
Regards,

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 13:20:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25004
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 13:20:08 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11398;
	Fri, 19 Oct 2001 10:19:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19410;
	Fri, 19 Oct 2001 10:17:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JHGtOI025661
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:16:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JHGtut025660
	for mobile-ip-dist; Fri, 19 Oct 2001 10:16:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JHGpOI025653
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:16:51 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19907
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:16:47 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23832
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 10:16:53 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9JHD7a12752;
	Fri, 19 Oct 2001 10:14:37 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM07425;
	Fri, 19 Oct 2001 10:14:38 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA09167; Fri, 19 Oct 2001 10:14:56 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.24464.125541.403955@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 10:14:56 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Michael A. Ramalho" <mramalho@cisco.com>,
        Rajeev Koodli <rajeev.koodli@nokia.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD05797.FBA8FECA@iprg.nokia.com>
References: <4.3.2.7.2.20011019092443.00b88660@mira-sjc5-9.cisco.com>
	<3BD05797.FBA8FECA@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Charles E. Perkins writes:
 > In the scenarios you refer to, the decision has been taken to design
 > the bandwith-constained link to only handle connection-oriented
 > traffic.  One could argue that this goes against some basic
 > Internet principle or another, but instead I would just like to
 > emphasize that we shouldn't be pushed to shoehorn IP for _all_
 > links into restrictions that are motivated by _some_ links.
 > Furthermore, it is my belief that future links with the same
 > bandwidth constraints as are driving the current discussion will
 > still beneficially allow IP traffic without such heavy penalties
 > against non-uniform higher-level protocol packetization.

   This is, in fact, a good reason to keep things
   modular. The fact that piggybacking is problematic
   for many extant links, and not especially useful
   for others (ie, 802.11) says to me that the KISS
   principle probably applies.
  
   Also: I've asked Rajeev several times for an 
   example of a L2 on a shared media which delivers
   different QoS than BE which doesn't suffer from
   either excessive bandwidth utilization or undue
   latency/jitter for real time traffic, and thus
   far he hasn't provided me a pointer. Maybe he
   just can't talk about it, but if there exists
   such a beast I'd _love_ to hear about it (seriously).

 > > It seemed like most of the justification (by Rajeev anyway) was
 > > the he wanted the piggyback to "fit" on the (cellular-like,
 > > TDM structured) MAC layer during opportunistic times
 > > (e.g., where ROHC gave significant compression and he
 > > could fit a BU with the media packets). There is probably
 > > a worst-case delay advantage for the BU for doing this in
 > > comparison to the non-media IP traffic on the L2 link.
 > 
 > I read this as a particular response to the suggestion that
 > highly structured MACs couldn't handle the Binding Update.
 > I found his response to be reasonable, which is to say that
 > reasonable engineers could make it work.

   Uh, how? Until details are provided, I remain
   skeptical.

 > I think it is obvious that for bandwidth-constrained,
 > RTS/CTS-style links, that we should minimize the number
 > of times that each mobile node (among possibly many thousands)
 > has to acquire the media.  

   RTS/CTS-style links produce unacceptible latency
   and jitter for real time traffic, especially at
   slow link speeds.

 > Plus we should remain sensitive to
 > minimizing the total data volume and the additional overheads
 > for extra packets (retuning, etc.).  There has been a marked
 > tendency to disregard these details in many IETF protocols,
 > and each bit of overhead does add up, eventually to a significant
 > performance loss.

   A custom engineered, single application network
   is always going to be far more bit-efficient than
   a general purpose network. It has its cost though:
   it's single purpose. At some level that price must
   be paid; trying to have the best of both worlds
   is very likely to yield the worst of both worlds.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 14:10:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26439
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 14:10:14 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25754;
	Fri, 19 Oct 2001 12:09:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04609;
	Fri, 19 Oct 2001 11:09:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JI7ZOI025980
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:07:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JI7ZLA025979
	for mobile-ip-dist; Fri, 19 Oct 2001 11:07:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JI7VOI025972
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:07:31 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03094
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:07:25 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23709
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:07:06 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA14312
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:07:31 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 19 Oct 2001 13:00:33 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L6S72>; Fri, 19 Oct 2001 13:06:40 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: "Michael A. Ramalho" <mramalho@cisco.com>,
        "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 19 Oct 2001 13:06:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C158C8.CC969A50"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C158C8.CC969A50
Content-Type: text/plain;
	charset="iso-8859-1"

Michael and All,

I suggest an unencumbered compromise to the wierd L2 issues and respond to
the arguments below:

> -----Original Message-----
> From: Michael A. Ramalho [mailto:mramalho@cisco.com]
> Sent: Friday, October 19, 2001 9:46 AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Cc: Morrow, Glenn [RICH2:C330:EXCH]; mramalho@cisco.com
> Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
> 
> 
> Charlie,
> 
> I agree with Hesham's bottom line - that a decision to piggyback
> at the sender has implications on the receiver (or the link to the
> receiver is on if it too is on a weird L2).

GM] This is true that both sides are affected; however, the weird L2 should
be adapted to handle the piggybacking in its weird way for downstream
traffic. Just as it does other weird things for certain downstream traffic
such as layer 5 signaling. 

If we start worrying about weird L2's in the IETF definition of L3
protocols, we will have to change almost every piece of signaling there is.
Trying to remove something from MIP, using as the argument, some wierd L2,
sets a horrible precedence. Don't you agree?

To see this point - let's take HTTP. Now if I had to worry about these wierd
L2's, then the IETF would have made HTTP more like WAP. Is that the
precedence you want to set? I don't think so. We should also note that the
L2's adapted by inventing WAP to deal with the wierd L2 problems. I am
perfectly confident that these L2's can be adapted to handle piggybacking
for downstream traffic coupled with anything.

> 
> In my email volleys to Rajeev last week ... I demonstrated that
> if the other end was also a MN on a similarly constrained
> L2 ... that it would be a bad practice to piggyback
> *AT LAYER 3* onto a (real-time) media packet.

GM] O.K. Here's a compromise. How about we say that binding updates SHOULD
NOT ever be piggybacked with unencrypted RTP packets because there are some
wierd L2s? 

This would allow the quite useful piggybacking to be used with the medias
transported with TCP and UDP. I think this would fix the issue for these
wierd L2s that do optimization for voice and perhaps other media. I also
don't see a big problem with implement complexity. 

I am really hoping this compromise works for everyone.

> 
> It seemed like most of the justification (by Rajeev anyway) was
> the he wanted the piggyback to "fit" on the (cellular-like,
> TDM structured) MAC layer during opportunistic times
> (e.g., where ROHC gave significant compression and he
> could fit a BU with the media packets). There is probably
> a worst-case delay advantage for the BU for doing this in
> comparison to the non-media IP traffic on the L2 link.

The ROHC is sniffiing the packets and doing all sorts of stripping etc..
Because the sniffer is present, special L2 things can be done. There are
other channels across the L2 that these packets can be delivered on. The
delay induced by this would probably not be that significant. The
specification of this does not belong in the IETF. It belongs in the wierd
L2 standards groups; however, the compromise above should negate the work
from having to be done; however, I still think it is wrong to have the IETF
L3 protocols worry about wierd L2s.

> 
> But this piggybacking is not persuasive for many reasons
> (please read the archive .. but it comes down to Hesham's
> bottom line that the far-end receiver and other L2s can have
> problems with it)
> 
> Fundamentally - a BU is end-to-end signalling. Thus, an
> ideal packet to piggyback onto is one that has similar
> QoS characteristics.
> 
> Thus, the ideal piggyback would be to something like a session
> signalling packet -  probably characterized by an assured
> forwarding type PHB - where you generally desire low
> loss and reasonable delay through the network hops. Someone
> mentioned a piggyback onto a RSVP packet ... but those
> packets undergo additional delay by QoS processing on the
> hops (intserv) or COPS queries (diffserv) or both (for mixed
> environments) .. so although RSVP is end-to-end signalling,
> it can undergo additional delays so as to make it unattractive.

GM] Well one could argue that a layer 5 packet goes though proxies and
registars that also do authorization checks and lookups, perhaps MIDCOM
interactions which have significant delay as well. It should also be noted
that session messages and session servers don't typically have routing
topology information which would be needed to enforce QoS at the bearer
stream for the flows which are being operated on. Dispersion and maintenance
of routing topology information to layer 5 proxies would be a nightmare,
IMHO.


> 
> A "bad packet" to piggyback onto would be a media
> packet  - probably characterized by an expedited forwarding
> type PHB - where you tolerate an occasional loss ( 1 ~ 5%,
> but I don't want to get into that debate) but you need *really
> low* delay through the hops. This is the type of packet
> that some have petitioned for the piggyback - I think
> this is a really bad idea and not a healthy L3 argument
> for piggybacking.

GM] I'm hoping the SHOULD NOT compromise above to not piggyback with
unencrypted RTP packets will settle this once and for all.

> 
> Thus ... choosing a packet to piggyback onto can be
> difficult ... and I have argued is not worth the effort
> (again, see the archive).

GM] And others are also argued that it is worth it.


> 
> Besides, if you really desire piggybacking for your L2
> link ... there is an opportunity to have your cake and eat
> it too. Design a L2 piggyback of the non-piggybacked L3 BU
> for your link ... and specify it in L2 bodies (e.g., IEEE,
> 3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... ).

I think the work to do this is the same as handling it at L2 using the L3
BU. Because of this I think your point is not valid and is not an excuse to
change the L3 protocol; however, the compromise above should alleviate your
concerns.

> 
> That is ... specify that if you are queuing a real-time
> packet and you have room for the BU on your L2
> timeslot (perhaps due to ROHC compressing of
> a real-time packet) ... fit the BU and the media
> packet on the L2 link timeslot! But be sure to
> de-piggyback the L3 BU at the other end of your
> L2 link!

GM] Again, the work is the same - point fails.

> 
> By doing this you de-couple the piggyback debate out of
> the IETF ... yet still accomplish your ends (efficiency
> and delay on the L2 link). And it works for both sides ... if
> the other end has a similarly constrained link. Please
> comment if you (or anyone on the list) can think of a
> reason why this is not a good approach (other than
> efficiency arguments on the non-access links - given
> average BU frequencies the gain is not significant).
>

GM] The work and gain is the same to interwork the L2 with the L3 BU

 
> Additionally, Mike Thomas (and others) have argued for
> not piggybacking for security related reasons. These
> arguments effectively plea for de-coupling of the problems
> (a non-piggybacked L3 BU).

GM] The current security mechanisms in the MIP draft alleviate the problems
that were used to warrant Mike Thomas' claims. In short, the current
definition of the spec fixes the problem. It just doesn't do it with only
IPSEC and IKE. This argument was simply - I want to use IPSEC only. There
were choices on trying to fullfill this:

1> Change IPSEC to do some new things
2> Get rid of piggybacking

My take is that <1> was rejected at this time because people want to
progress the draft without the delay induced via inter-WG politics and
operations. 

And <2> was rejected because I think people have some forsight that
piggybacking is needed if you ever want to get the bearer path sensitive
IETF protocols to work together synergistically.

> 
> In closing, I'd say that the mobile-ip list debates of the last
> week or so have effectively argued that the end-link efficiencies
> gained by piggybacking are at worst harmful and at
> best gain the QoS characteristics of the packet piggybacked
> onto (which is not  what you want for some potential
> piggybacks). Thus, I'd say the "best IP definition" (your
> words) would argue for *not* piggybacking. The arguments
> are technical ... but not the complexity-related, as your
> previous email seemed to infer.

GM] Due my arguments above, I do not agree with your technical assessment;
however, I have offered a compromise that hopefully all can agree with. It
only requires a simple check to see if an un-encrypted packet contains RTP. 

> 
> As I stated in my previous email, I think I am being a
> realist here ... and I do not especially care to be
> argumentative or divisive ... and have stated my
> technical objections to L3 piggybacking.
> 

I think we are all trying to be realistic and respectfull of others
concerns, desires, backgrounds and current resources. I offer an
unencumbered compromise that hopefully all can agree with and we can move
forward on.

> And unlike those who only complain on the list,  provided
> a way for those who desire piggybacking on arbitrary
> L2s a way to accomplish the efficiency or delay advantage
> (on the L2 link) they desire ... in a way that is not harmful
> to the packets that would have been piggybacked onto.

GM] I agree you have been logical in your arguments.

Highest regards to all,

Glenn

---- Glenn DONE ----

------_=_NextPart_001_01C158C8.CC969A50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Michael and All,</FONT>
</P>

<P><FONT SIZE=3D2>I suggest an unencumbered compromise to the wierd L2 =
issues and respond to the arguments below:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Michael A. Ramalho [<A =
HREF=3D"mailto:mramalho@cisco.com">mailto:mramalho@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Friday, October 19, 2001 9:46 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'mobile-ip@sunroof.eng.sun.com'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Morrow, Glenn [RICH2:C330:EXCH]; =
mramalho@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [mobile-ip] MIPv6 - Focus of the =
security discussion</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Charlie,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree with Hesham's bottom line - that a =
decision to piggyback</FONT>
<BR><FONT SIZE=3D2>&gt; at the sender has implications on the receiver =
(or the link to the</FONT>
<BR><FONT SIZE=3D2>&gt; receiver is on if it too is on a weird =
L2).</FONT>
</P>

<P><FONT SIZE=3D2>GM] This is true that both sides are affected; =
however, the weird L2 should be adapted to handle the piggybacking in =
its weird way for downstream traffic. Just as it does other weird =
things for certain downstream traffic such as layer 5 signaling. =
</FONT></P>

<P><FONT SIZE=3D2>If we start worrying about weird L2's in the IETF =
definition of L3 protocols, we will have to change almost every piece =
of signaling there is. Trying to remove something from MIP, using as =
the argument, some wierd L2, sets a horrible precedence. Don't you =
agree?</FONT></P>

<P><FONT SIZE=3D2>To see this point - let's take HTTP. Now if I had to =
worry about these wierd L2's, then the IETF would have made HTTP more =
like WAP. Is that the precedence you want to set? I don't think so. We =
should also note that the L2's adapted by inventing WAP to deal with =
the wierd L2 problems. I am perfectly confident that these L2's can be =
adapted to handle piggybacking for downstream traffic coupled with =
anything.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In my email volleys to Rajeev last week ... I =
demonstrated that</FONT>
<BR><FONT SIZE=3D2>&gt; if the other end was also a MN on a similarly =
constrained</FONT>
<BR><FONT SIZE=3D2>&gt; L2 ... that it would be a bad practice to =
piggyback</FONT>
<BR><FONT SIZE=3D2>&gt; *AT LAYER 3* onto a (real-time) media =
packet.</FONT>
</P>

<P><FONT SIZE=3D2>GM] O.K. Here's a compromise. How about we say that =
binding updates SHOULD NOT ever be piggybacked with unencrypted RTP =
packets because there are some wierd L2s? </FONT></P>

<P><FONT SIZE=3D2>This would allow the quite useful piggybacking to be =
used with the medias transported with TCP and UDP. I think this would =
fix the issue for these wierd L2s that do optimization for voice and =
perhaps other media. I also don't see a big problem with implement =
complexity. </FONT></P>

<P><FONT SIZE=3D2>I am really hoping this compromise works for =
everyone.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It seemed like most of the justification (by =
Rajeev anyway) was</FONT>
<BR><FONT SIZE=3D2>&gt; the he wanted the piggyback to &quot;fit&quot; =
on the (cellular-like,</FONT>
<BR><FONT SIZE=3D2>&gt; TDM structured) MAC layer during opportunistic =
times</FONT>
<BR><FONT SIZE=3D2>&gt; (e.g., where ROHC gave significant compression =
and he</FONT>
<BR><FONT SIZE=3D2>&gt; could fit a BU with the media packets). There =
is probably</FONT>
<BR><FONT SIZE=3D2>&gt; a worst-case delay advantage for the BU for =
doing this in</FONT>
<BR><FONT SIZE=3D2>&gt; comparison to the non-media IP traffic on the =
L2 link.</FONT>
</P>

<P><FONT SIZE=3D2>The ROHC is sniffiing the packets and doing all sorts =
of stripping etc.. Because the sniffer is present, special L2 things =
can be done. There are other channels across the L2 that these packets =
can be delivered on. The delay induced by this would probably not be =
that significant. The specification of this does not belong in the =
IETF. It belongs in the wierd L2 standards groups; however, the =
compromise above should negate the work from having to be done; =
however, I still think it is wrong to have the IETF L3 protocols worry =
about wierd L2s.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But this piggybacking is not persuasive for =
many reasons</FONT>
<BR><FONT SIZE=3D2>&gt; (please read the archive .. but it comes down =
to Hesham's</FONT>
<BR><FONT SIZE=3D2>&gt; bottom line that the far-end receiver and other =
L2s can have</FONT>
<BR><FONT SIZE=3D2>&gt; problems with it)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Fundamentally - a BU is end-to-end signalling. =
Thus, an</FONT>
<BR><FONT SIZE=3D2>&gt; ideal packet to piggyback onto is one that has =
similar</FONT>
<BR><FONT SIZE=3D2>&gt; QoS characteristics.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thus, the ideal piggyback would be to something =
like a session</FONT>
<BR><FONT SIZE=3D2>&gt; signalling packet -&nbsp; probably =
characterized by an assured</FONT>
<BR><FONT SIZE=3D2>&gt; forwarding type PHB - where you generally =
desire low</FONT>
<BR><FONT SIZE=3D2>&gt; loss and reasonable delay through the network =
hops. Someone</FONT>
<BR><FONT SIZE=3D2>&gt; mentioned a piggyback onto a RSVP packet ... =
but those</FONT>
<BR><FONT SIZE=3D2>&gt; packets undergo additional delay by QoS =
processing on the</FONT>
<BR><FONT SIZE=3D2>&gt; hops (intserv) or COPS queries (diffserv) or =
both (for mixed</FONT>
<BR><FONT SIZE=3D2>&gt; environments) .. so although RSVP is end-to-end =
signalling,</FONT>
<BR><FONT SIZE=3D2>&gt; it can undergo additional delays so as to make =
it unattractive.</FONT>
</P>

<P><FONT SIZE=3D2>GM] Well one could argue that a layer 5 packet goes =
though proxies and registars that also do authorization checks and =
lookups, perhaps MIDCOM interactions which have significant delay as =
well. It should also be noted that session messages and session servers =
don't typically have routing topology information which would be needed =
to enforce QoS at the bearer stream for the flows which are being =
operated on. Dispersion and maintenance of routing topology information =
to layer 5 proxies would be a nightmare, IMHO.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A &quot;bad packet&quot; to piggyback onto =
would be a media</FONT>
<BR><FONT SIZE=3D2>&gt; packet&nbsp; - probably characterized by an =
expedited forwarding</FONT>
<BR><FONT SIZE=3D2>&gt; type PHB - where you tolerate an occasional =
loss ( 1 ~ 5%,</FONT>
<BR><FONT SIZE=3D2>&gt; but I don't want to get into that debate) but =
you need *really</FONT>
<BR><FONT SIZE=3D2>&gt; low* delay through the hops. This is the type =
of packet</FONT>
<BR><FONT SIZE=3D2>&gt; that some have petitioned for the piggyback - I =
think</FONT>
<BR><FONT SIZE=3D2>&gt; this is a really bad idea and not a healthy L3 =
argument</FONT>
<BR><FONT SIZE=3D2>&gt; for piggybacking.</FONT>
</P>

<P><FONT SIZE=3D2>GM] I'm hoping the SHOULD NOT compromise above to not =
piggyback with unencrypted RTP packets will settle this once and for =
all.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thus ... choosing a packet to piggyback onto =
can be</FONT>
<BR><FONT SIZE=3D2>&gt; difficult ... and I have argued is not worth =
the effort</FONT>
<BR><FONT SIZE=3D2>&gt; (again, see the archive).</FONT>
</P>

<P><FONT SIZE=3D2>GM] And others are also argued that it is worth =
it.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Besides, if you really desire piggybacking for =
your L2</FONT>
<BR><FONT SIZE=3D2>&gt; link ... there is an opportunity to have your =
cake and eat</FONT>
<BR><FONT SIZE=3D2>&gt; it too. Design a L2 piggyback of the =
non-piggybacked L3 BU</FONT>
<BR><FONT SIZE=3D2>&gt; for your link ... and specify it in L2 bodies =
(e.g., IEEE,</FONT>
<BR><FONT SIZE=3D2>&gt; 3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... =
).</FONT>
</P>

<P><FONT SIZE=3D2>I think the work to do this is the same as handling =
it at L2 using the L3 BU. Because of this I think your point is not =
valid and is not an excuse to change the L3 protocol; however, the =
compromise above should alleviate your concerns.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That is ... specify that if you are queuing a =
real-time</FONT>
<BR><FONT SIZE=3D2>&gt; packet and you have room for the BU on your =
L2</FONT>
<BR><FONT SIZE=3D2>&gt; timeslot (perhaps due to ROHC compressing =
of</FONT>
<BR><FONT SIZE=3D2>&gt; a real-time packet) ... fit the BU and the =
media</FONT>
<BR><FONT SIZE=3D2>&gt; packet on the L2 link timeslot! But be sure =
to</FONT>
<BR><FONT SIZE=3D2>&gt; de-piggyback the L3 BU at the other end of =
your</FONT>
<BR><FONT SIZE=3D2>&gt; L2 link!</FONT>
</P>

<P><FONT SIZE=3D2>GM] Again, the work is the same - point fails.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; By doing this you de-couple the piggyback =
debate out of</FONT>
<BR><FONT SIZE=3D2>&gt; the IETF ... yet still accomplish your ends =
(efficiency</FONT>
<BR><FONT SIZE=3D2>&gt; and delay on the L2 link). And it works for =
both sides ... if</FONT>
<BR><FONT SIZE=3D2>&gt; the other end has a similarly constrained link. =
Please</FONT>
<BR><FONT SIZE=3D2>&gt; comment if you (or anyone on the list) can =
think of a</FONT>
<BR><FONT SIZE=3D2>&gt; reason why this is not a good approach (other =
than</FONT>
<BR><FONT SIZE=3D2>&gt; efficiency arguments on the non-access links - =
given</FONT>
<BR><FONT SIZE=3D2>&gt; average BU frequencies the gain is not =
significant).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>GM] The work and gain is the same to interwork the L2 =
with the L3 BU</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; Additionally, Mike Thomas (and others) have =
argued for</FONT>
<BR><FONT SIZE=3D2>&gt; not piggybacking for security related reasons. =
These</FONT>
<BR><FONT SIZE=3D2>&gt; arguments effectively plea for de-coupling of =
the problems</FONT>
<BR><FONT SIZE=3D2>&gt; (a non-piggybacked L3 BU).</FONT>
</P>

<P><FONT SIZE=3D2>GM] The current security mechanisms in the MIP draft =
alleviate the problems that were used to warrant Mike Thomas' claims. =
In short, the current definition of the spec fixes the problem. It just =
doesn't do it with only IPSEC and IKE. This argument was simply - I =
want to use IPSEC only. There were choices on trying to fullfill =
this:</FONT></P>

<P><FONT SIZE=3D2>1&gt; Change IPSEC to do some new things</FONT>
<BR><FONT SIZE=3D2>2&gt; Get rid of piggybacking</FONT>
</P>

<P><FONT SIZE=3D2>My take is that &lt;1&gt; was rejected at this time =
because people want to progress the draft without the delay induced via =
inter-WG politics and operations. </FONT></P>

<P><FONT SIZE=3D2>And &lt;2&gt; was rejected because I think people =
have some forsight that piggybacking is needed if you ever want to get =
the bearer path sensitive IETF protocols to work together =
synergistically.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In closing, I'd say that the mobile-ip list =
debates of the last</FONT>
<BR><FONT SIZE=3D2>&gt; week or so have effectively argued that the =
end-link efficiencies</FONT>
<BR><FONT SIZE=3D2>&gt; gained by piggybacking are at worst harmful and =
at</FONT>
<BR><FONT SIZE=3D2>&gt; best gain the QoS characteristics of the packet =
piggybacked</FONT>
<BR><FONT SIZE=3D2>&gt; onto (which is not&nbsp; what you want for some =
potential</FONT>
<BR><FONT SIZE=3D2>&gt; piggybacks). Thus, I'd say the &quot;best IP =
definition&quot; (your</FONT>
<BR><FONT SIZE=3D2>&gt; words) would argue for *not* piggybacking. The =
arguments</FONT>
<BR><FONT SIZE=3D2>&gt; are technical ... but not the =
complexity-related, as your</FONT>
<BR><FONT SIZE=3D2>&gt; previous email seemed to infer.</FONT>
</P>

<P><FONT SIZE=3D2>GM] Due my arguments above, I do not agree with your =
technical assessment; however, I have offered a compromise that =
hopefully all can agree with. It only requires a simple check to see if =
an un-encrypted packet contains RTP. </FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As I stated in my previous email, I think I am =
being a</FONT>
<BR><FONT SIZE=3D2>&gt; realist here ... and I do not especially care =
to be</FONT>
<BR><FONT SIZE=3D2>&gt; argumentative or divisive ... and have stated =
my</FONT>
<BR><FONT SIZE=3D2>&gt; technical objections to L3 piggybacking.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I think we are all trying to be realistic and =
respectfull of others concerns, desires, backgrounds and current =
resources. I offer an unencumbered compromise that hopefully all can =
agree with and we can move forward on.</FONT></P>

<P><FONT SIZE=3D2>&gt; And unlike those who only complain on the =
list,&nbsp; provided</FONT>
<BR><FONT SIZE=3D2>&gt; a way for those who desire piggybacking on =
arbitrary</FONT>
<BR><FONT SIZE=3D2>&gt; L2s a way to accomplish the efficiency or delay =
advantage</FONT>
<BR><FONT SIZE=3D2>&gt; (on the L2 link) they desire ... in a way that =
is not harmful</FONT>
<BR><FONT SIZE=3D2>&gt; to the packets that would have been piggybacked =
onto.</FONT>
</P>

<P><FONT SIZE=3D2>GM] I agree you have been logical in your =
arguments.</FONT>
</P>

<P><FONT SIZE=3D2>Highest regards to all,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>---- Glenn DONE ----</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C158C8.CC969A50--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 14:32:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27244
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 14:32:43 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15843;
	Fri, 19 Oct 2001 12:31:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08718;
	Fri, 19 Oct 2001 11:31:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JIV7OI026195
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:31:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JIV74Z026194
	for mobile-ip-dist; Fri, 19 Oct 2001 11:31:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JIV4OI026187
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:31:04 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08533
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:31:05 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14933
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:30:40 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9JIV9U14080;
	Fri, 19 Oct 2001 11:31:09 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM09917;
	Fri, 19 Oct 2001 11:30:40 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09180; Fri, 19 Oct 2001 11:31:04 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.29031.946504.371470@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 11:31:03 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Glenn Morrow writes:
 > GM] This is true that both sides are affected; however, the weird L2 should
 > be adapted to handle the piggybacking in its weird way for downstream
 > traffic. Just as it does other weird things for certain downstream traffic
 > such as layer 5 signaling. 

   Can you point out a non-weird L2 which would 
   substantially benefit from piggybacking? I'm
   pretty sure that my decidedly non-weird ethernet
   at home wouldn't realize any substantial benefit.

	   Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 14:55:28 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27911
	for <mobileip-archive@lists.ietf.org>; Fri, 19 Oct 2001 14:55:28 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26008;
	Fri, 19 Oct 2001 11:55:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15246;
	Fri, 19 Oct 2001 11:54:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JIrrOI026416
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:53:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JIrrFI026415
	for mobile-ip-dist; Fri, 19 Oct 2001 11:53:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JIroOI026408
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:53:50 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14829
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:53:47 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04274
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:53:18 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18940
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:53:42 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JIrfu15615
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:53:41 -0700
X-mProtect:  Fri, 19 Oct 2001 11:53:41 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdbnzplO; Fri, 19 Oct 2001 11:53:40 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id LAA16365 for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 11:53:10 -0700 (PDT)
Message-ID: <3BD07696.C217D41E@iprg.nokia.com>
Date: Fri, 19 Oct 2001 11:53:10 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I agree on the principle of not re-designing IP too much to weird
behavior in the middle, in addition to NAT-like boxes, this should
also cover weird links. Should QoS negotiations and link characteristics
not allow for piggybacking, and this re-design of IP is really desired,
how about a negotiation in MIPv6:

Add a "don't piggyback" bit in BAck. MN closer to the weird link when
receiving a BU would know when to discourage piggybacking. If the first
piggybacked BU packet would be so unfortunate as to be dropped at
the entrance to the weird link, the sending MN would then not
piggyback on resends and then get the BAck with "don't piggyback".
Special devices using e.g. RTP over some cellular links would also
know to add this bit to BAcks.

This should address Hesham's note on the far end not knowing when
to not piggyback?

-Jari

> Glenn Morrow wrote:
> 
> Michael and All,
> 
> I suggest an unencumbered compromise to the wierd L2 issues and respond to the arguments below:
> 
> > -----Original Message-----
> > From: Michael A. Ramalho [mailto:mramalho@cisco.com]
> > Sent: Friday, October 19, 2001 9:46 AM
> > To: 'mobile-ip@sunroof.eng.sun.com'
> > Cc: Morrow, Glenn [RICH2:C330:EXCH]; mramalho@cisco.com
> > Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
> >
> >
> > Charlie,
> >
> > I agree with Hesham's bottom line - that a decision to piggyback
> > at the sender has implications on the receiver (or the link to the
> > receiver is on if it too is on a weird L2).
> 
> GM] This is true that both sides are affected; however, the weird L2 should be adapted to handle the piggybacking in its weird way for downstream traffic. Just as it does other weird things for certain downstream traffic such as layer 5 signaling.
> 
> If we start worrying about weird L2's in the IETF definition of L3 protocols, we will have to change almost every piece of signaling there is. Trying to remove something from MIP, using as the argument, some wierd L2, sets a horrible precedence. Don't you agree?
> 
> To see this point - let's take HTTP. Now if I had to worry about these wierd L2's, then the IETF would have made HTTP more like WAP. Is that the precedence you want to set? I don't think so. We should also note that the L2's adapted by inventing WAP to deal with the wierd L2 problems. I am perfectly confident that these L2's can be adapted to handle piggybacking for downstream traffic coupled with anything.
> 
> >
> > In my email volleys to Rajeev last week ... I demonstrated that
> > if the other end was also a MN on a similarly constrained
> > L2 ... that it would be a bad practice to piggyback
> > *AT LAYER 3* onto a (real-time) media packet.
> 
> GM] O.K. Here's a compromise. How about we say that binding updates SHOULD NOT ever be piggybacked with unencrypted RTP packets because there are some wierd L2s?
> 
> This would allow the quite useful piggybacking to be used with the medias transported with TCP and UDP. I think this would fix the issue for these wierd L2s that do optimization for voice and perhaps other media. I also don't see a big problem with implement complexity.
> 
> I am really hoping this compromise works for everyone.
> 
> >
> > It seemed like most of the justification (by Rajeev anyway) was
> > the he wanted the piggyback to "fit" on the (cellular-like,
> > TDM structured) MAC layer during opportunistic times
> > (e.g., where ROHC gave significant compression and he
> > could fit a BU with the media packets). There is probably
> > a worst-case delay advantage for the BU for doing this in
> > comparison to the non-media IP traffic on the L2 link.
> 
> The ROHC is sniffiing the packets and doing all sorts of stripping etc.. Because the sniffer is present, special L2 things can be done. There are other channels across the L2 that these packets can be delivered on. The delay induced by this would probably not be that significant. The specification of this does not belong in the IETF. It belongs in the wierd L2 standards groups; however, the compromise above should negate the work from having to be done; however, I still think it is wrong to have the IETF L3 protocols worry about wierd L2s.
> 
> >
> > But this piggybacking is not persuasive for many reasons
> > (please read the archive .. but it comes down to Hesham's
> > bottom line that the far-end receiver and other L2s can have
> > problems with it)
> >
> > Fundamentally - a BU is end-to-end signalling. Thus, an
> > ideal packet to piggyback onto is one that has similar
> > QoS characteristics.
> >
> > Thus, the ideal piggyback would be to something like a session
> > signalling packet -  probably characterized by an assured
> > forwarding type PHB - where you generally desire low
> > loss and reasonable delay through the network hops. Someone
> > mentioned a piggyback onto a RSVP packet ... but those
> > packets undergo additional delay by QoS processing on the
> > hops (intserv) or COPS queries (diffserv) or both (for mixed
> > environments) .. so although RSVP is end-to-end signalling,
> > it can undergo additional delays so as to make it unattractive.
> 
> GM] Well one could argue that a layer 5 packet goes though proxies and registars that also do authorization checks and lookups, perhaps MIDCOM interactions which have significant delay as well. It should also be noted that session messages and session servers don't typically have routing topology information which would be needed to enforce QoS at the bearer stream for the flows which are being operated on. Dispersion and maintenance of routing topology information to layer 5 proxies would be a nightmare, IMHO.
> 
> >
> > A "bad packet" to piggyback onto would be a media
> > packet  - probably characterized by an expedited forwarding
> > type PHB - where you tolerate an occasional loss ( 1 ~ 5%,
> > but I don't want to get into that debate) but you need *really
> > low* delay through the hops. This is the type of packet
> > that some have petitioned for the piggyback - I think
> > this is a really bad idea and not a healthy L3 argument
> > for piggybacking.
> 
> GM] I'm hoping the SHOULD NOT compromise above to not piggyback with unencrypted RTP packets will settle this once and for all.
> 
> >
> > Thus ... choosing a packet to piggyback onto can be
> > difficult ... and I have argued is not worth the effort
> > (again, see the archive).
> 
> GM] And others are also argued that it is worth it.
> 
> >
> > Besides, if you really desire piggybacking for your L2
> > link ... there is an opportunity to have your cake and eat
> > it too. Design a L2 piggyback of the non-piggybacked L3 BU
> > for your link ... and specify it in L2 bodies (e.g., IEEE,
> > 3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... ).
> 
> I think the work to do this is the same as handling it at L2 using the L3 BU. Because of this I think your point is not valid and is not an excuse to change the L3 protocol; however, the compromise above should alleviate your concerns.
> 
> >
> > That is ... specify that if you are queuing a real-time
> > packet and you have room for the BU on your L2
> > timeslot (perhaps due to ROHC compressing of
> > a real-time packet) ... fit the BU and the media
> > packet on the L2 link timeslot! But be sure to
> > de-piggyback the L3 BU at the other end of your
> > L2 link!
> 
> GM] Again, the work is the same - point fails.
> 
> >
> > By doing this you de-couple the piggyback debate out of
> > the IETF ... yet still accomplish your ends (efficiency
> > and delay on the L2 link). And it works for both sides ... if
> > the other end has a similarly constrained link. Please
> > comment if you (or anyone on the list) can think of a
> > reason why this is not a good approach (other than
> > efficiency arguments on the non-access links - given
> > average BU frequencies the gain is not significant).
> >
> 
> GM] The work and gain is the same to interwork the L2 with the L3 BU
> 
> 
> > Additionally, Mike Thomas (and others) have argued for
> > not piggybacking for security related reasons. These
> > arguments effectively plea for de-coupling of the problems
> > (a non-piggybacked L3 BU).
> 
> GM] The current security mechanisms in the MIP draft alleviate the problems that were used to warrant Mike Thomas' claims. In short, the current definition of the spec fixes the problem. It just doesn't do it with only IPSEC and IKE. This argument was simply - I want to use IPSEC only. There were choices on trying to fullfill this:
> 
> 1> Change IPSEC to do some new things
> 2> Get rid of piggybacking
> 
> My take is that <1> was rejected at this time because people want to progress the draft without the delay induced via inter-WG politics and operations.
> 
> And <2> was rejected because I think people have some forsight that piggybacking is needed if you ever want to get the bearer path sensitive IETF protocols to work together synergistically.
> 
> >
> > In closing, I'd say that the mobile-ip list debates of the last
> > week or so have effectively argued that the end-link efficiencies
> > gained by piggybacking are at worst harmful and at
> > best gain the QoS characteristics of the packet piggybacked
> > onto (which is not  what you want for some potential
> > piggybacks). Thus, I'd say the "best IP definition" (your
> > words) would argue for *not* piggybacking. The arguments
> > are technical ... but not the complexity-related, as your
> > previous email seemed to infer.
> 
> GM] Due my arguments above, I do not agree with your technical assessment; however, I have offered a compromise that hopefully all can agree with. It only requires a simple check to see if an un-encrypted packet contains RTP.
> 
> >
> > As I stated in my previous email, I think I am being a
> > realist here ... and I do not especially care to be
> > argumentative or divisive ... and have stated my
> > technical objections to L3 piggybacking.
> >
> 
> I think we are all trying to be realistic and respectfull of others concerns, desires, backgrounds and current resources. I offer an unencumbered compromise that hopefully all can agree with and we can move forward on.
> 
> > And unlike those who only complain on the list,  provided
> > a way for those who desire piggybacking on arbitrary
> > L2s a way to accomplish the efficiency or delay advantage
> > (on the L2 link) they desire ... in a way that is not harmful
> > to the packets that would have been piggybacked onto.
> 
> GM] I agree you have been logical in your arguments.
> 
> Highest regards to all,
> 
> Glenn
> 
> ---- Glenn DONE ----


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:06:01 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28118
	for <mobileip-archive@lists.ietf.org>; Fri, 19 Oct 2001 15:06:00 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00230;
	Fri, 19 Oct 2001 12:04:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18079;
	Fri, 19 Oct 2001 12:03:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJ2OOI026530
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:02:24 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJ2OI4026529
	for mobile-ip-dist; Fri, 19 Oct 2001 12:02:24 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJ2KOI026522
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:02:20 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04797
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:02:22 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23716
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:31:47 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA19481
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:02:19 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JJ2Ir27839
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:02:18 -0700
X-mProtect:  Fri, 19 Oct 2001 12:02:18 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdvmrOMx; Fri, 19 Oct 2001 12:02:17 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id MAA16379 for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:02:17 -0700 (PDT)
Message-ID: <3BD078B9.2DD35233@iprg.nokia.com>
Date: Fri, 19 Oct 2001 12:02:17 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com> <15312.29031.946504.371470@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Glenn Morrow writes:
>  > GM] This is true that both sides are affected; however, the weird L2 
>  > should
>  > be adapted to handle the piggybacking in its weird way for downstream
>  > traffic. Just as it does other weird things for certain downstream 
>  > traffic
>  > such as layer 5 signaling.
> 
>    Can you point out a non-weird L2 which would
>    substantially benefit from piggybacking? I'm
>    pretty sure that my decidedly non-weird ethernet
>    at home wouldn't realize any substantial benefit.
> 
>            Mike

Any narrow-band link where there is substantial overhead in separating
one packet into two would potentially benefit from piggybacking. This
overhead can include channel reservation, L2 framing, etc. The overhead
can be both bandwidth and time.

For example, consider some old technologies, like (A)X.25. 
If you have 300-1200 bps link you'd like to avoid sending any extra
packet. Especially when having multiple receivers over
variable-characteristics band (short-wave 300bps AX-25).

This example just to remind L3 should work also on other links we
do not think of right now..

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:14:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28467
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 15:14:56 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04282;
	Fri, 19 Oct 2001 12:14:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20731;
	Fri, 19 Oct 2001 12:14:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJDcOI026681
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:13:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJDcrC026680
	for mobile-ip-dist; Fri, 19 Oct 2001 12:13:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJDXOI026673
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:13:33 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21909
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:13:35 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20159
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:13:10 -0600 (MDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9JJE3Q09566
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:14:04 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56b1b7ff0bac12f257079@davir04nok.americas.nokia.com>;
 Fri, 19 Oct 2001 14:13:33 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 19 Oct 2001 14:13:32 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 19 Oct 2001 15:13:06 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [mobile-ip] MIPv6 - Focus of the security discussion
Thread-Index: AcFYwdreyhibv8SzEdWpXgBQi2kYTQACsd3g
From: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>
To: "'ext Michael Thomas'" <mat@cisco.com>, <mobile-ip@sunroof.eng.sun.com>
Cc: "Michael A. Ramalho" <mramalho@cisco.com>
X-OriginalArrivalTime: 19 Oct 2001 19:13:32.0749 (UTC) FILETIME=[24D65FD0:01C158D2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9JJDYOI026674
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello,

I see my name popped up in the discussion. So, I have some comments
below. 

Regards,

-Rajeev


Michael Ramalho: 
>> It seemed like most of the justification (by Rajeev anyway) was
>> the he wanted the piggyback to "fit" on the (cellular-like,
>> TDM structured) MAC layer during opportunistic times
>> (e.g., where ROHC gave significant compression and he
>> could fit a BU with the media packets). There is probably
>> a worst-case delay advantage for the BU for doing this in
>> comparison to the non-media IP traffic on the L2 link.

My discussion with you pertained piggybacking and header compression
interworking. Looking at the concluding e-mail from you in that thread,
you admit that header compression would work when piggybacking is used.
More specifically, I showed that the near-end compressor need not know
in which state the far-end compressor is prior to piggybacking. So,
regardless of how you view the problem now, admitting in more positive
terms the outcome of the previous thread would only enhance the
credibility of your current input.

Now, onto Michael Thomas:

>Charles E. Perkins writes:
> > In the scenarios you refer to, the decision has been taken to design
> > the bandwith-constained link to only handle connection-oriented
> > traffic.  One could argue that this goes against some basic
> > Internet principle or another, but instead I would just like to
> > emphasize that we shouldn't be pushed to shoehorn IP for _all_
> > links into restrictions that are motivated by _some_ links.
> > Furthermore, it is my belief that future links with the same
> > bandwidth constraints as are driving the current discussion will
> > still beneficially allow IP traffic without such heavy penalties
> > against non-uniform higher-level protocol packetization.
>
>   This is, in fact, a good reason to keep things
>   modular. The fact that piggybacking is problematic
>   for many extant links, and not especially useful
>   for others (ie, 802.11) says to me that the KISS
>   principle probably applies.
>  

I am sorry: I don't see the flow of logic here.. BTW, I would have
agreed to the modularity  principle if you stated that one must not
strike out destination option because a particular link, yet
unspecified, does not know how to handle it.


>   Also: I've asked Rajeev several times for an 
>   example of a L2 on a shared media which delivers
>   different QoS than BE which doesn't suffer from
>   either excessive bandwidth utilization or undue
>   latency/jitter for real time traffic, and thus
>   far he hasn't provided me a pointer. Maybe he
>   just can't talk about it, but if there exists
>   such a beast I'd _love_ to hear about it (seriously).
>

This brings back the question of whether destination option must have
been specified in the first place because some weird link does not know
how to support it! What's the logic in saying IP cannot have
variable-sized packets because a link would have performance issues ?

If you are true to your modularity argument, then you should have not
any problems accepting destination option on any link!


> > > It seemed like most of the justification (by Rajeev anyway) was
> > > the he wanted the piggyback to "fit" on the (cellular-like,
> > > TDM structured) MAC layer during opportunistic times
> > > (e.g., where ROHC gave significant compression and he
> > > could fit a BU with the media packets). There is probably
> > > a worst-case delay advantage for the BU for doing this in
> > > comparison to the non-media IP traffic on the L2 link.
> > 
> > I read this as a particular response to the suggestion that
> > highly structured MACs couldn't handle the Binding Update.
> > I found his response to be reasonable, which is to say that
> > reasonable engineers could make it work.
>
>   Uh, how? Until details are provided, I remain
>   skeptical.
>


Well, please check the recent archives for header compression and
piggybacking interworking.


> > I think it is obvious that for bandwidth-constrained,
> > RTS/CTS-style links, that we should minimize the number
> > of times that each mobile node (among possibly many thousands)
> > has to acquire the media.  
>
>   RTS/CTS-style links produce unacceptible latency
>   and jitter for real time traffic, especially at
>   slow link speeds.
>

So what ? If IP was designed looking into every possible link's
idiosyncrasies, you and I would probably not having this conversation!
hmm..


> > Plus we should remain sensitive to
> > minimizing the total data volume and the additional overheads
> > for extra packets (retuning, etc.).  There has been a marked
> > tendency to disregard these details in many IETF protocols,
> > and each bit of overhead does add up, eventually to a significant
> > performance loss.
>
>   A custom engineered, single application network
>   is always going to be far more bit-efficient than
>   a general purpose network. It has its cost though:
>   it's single purpose. At some level that price must
>   be paid; trying to have the best of both worlds
>   is very likely to yield the worst of both worlds.
>

Huh, the same reverse engineering point again.. This is _really_ an
issue of how to carry IPv6 over certain links. I would think that we
would have an RFC similar to 2464, 2467, 2470 for the link you have in
mind. Perhaps you should volunteer to specify that, so that your current
(performance) problem would go away.



>	   Mike
>


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:19:36 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28707
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 15:19:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06029;
	Fri, 19 Oct 2001 12:18:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21966;
	Fri, 19 Oct 2001 12:18:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJHCOI026795
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:17:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJHC7i026794
	for mobile-ip-dist; Fri, 19 Oct 2001 12:17:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJH8OI026787
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:17:08 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22771
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:17:10 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22877
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:16:45 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA21043
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:17:09 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JJH9A17463
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:17:09 -0700
X-mProtect:  Fri, 19 Oct 2001 12:17:09 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdbUXud2; Fri, 19 Oct 2001 12:17:06 PDT
Message-ID: <3BD07C33.5A70C996@iprg.nokia.com>
Date: Fri, 19 Oct 2001 12:17:07 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com> <15312.29031.946504.371470@thomasm-u1.cisco.com> <3BD078B9.2DD35233@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Jari,

"Jari T. Malinen" wrote:

> Any narrow-band link where there is substantial overhead in separating
> one packet into two would potentially benefit from piggybacking. This
> overhead can include channel reservation, L2 framing, etc. The overhead
> can be both bandwidth and time.
> 
> For example, consider some old technologies, like (A)X.25.
> If you have 300-1200 bps link you'd like to avoid sending any extra
> packet. Especially when having multiple receivers over
> variable-characteristics band (short-wave 300bps AX-25).
> 
> This example just to remind L3 should work also on other links we
> do not think of right now..

Definitely.  Plus we have a lot of ideas about making Mobile IPv6
work with ad hoc wireless networks.  There, it's even more important
to avoid extraneous packets, and synchronizing the whole ad hoc
network to fit into the channelization requirements imposed at the
access router is ... well ... challenging to say the least.  That's
just another example -- I don't claim that we need to design the
ad hoc network before getting Mobile IPv6 finished.

Current cellular networks are not necessarily representative of
future wireless networks, and thus they should to dictate the
requirements for Mobile IPv6 over the expected lifetime of IPv6.
At the same time, we have to view existing wireless systems as
a major immediate customer for our specifications, and thus make
sure things do work well.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:24:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28848
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 15:24:39 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27767;
	Fri, 19 Oct 2001 13:23:07 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23727;
	Fri, 19 Oct 2001 12:23:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJMiOI026905
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:22:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJMiqh026904
	for mobile-ip-dist; Fri, 19 Oct 2001 12:22:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJMeOI026897
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:22:41 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23875
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:22:42 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22704
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:22:42 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA21515
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:22:42 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JJMfD30215
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:22:41 -0700
X-mProtect:  Fri, 19 Oct 2001 12:22:41 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdpITGId; Fri, 19 Oct 2001 12:22:39 PDT
Message-ID: <3BD07D80.F8DF8B10@iprg.nokia.com>
Date: Fri, 19 Oct 2001 12:22:40 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com> <15312.29031.946504.371470@thomasm-u1.cisco.com> <3BD078B9.2DD35233@iprg.nokia.com> <3BD07C33.5A70C996@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

oops... typo below corrected, in case it isn't clear ...  (darn)

"Charles E. Perkins" wrote:

          ............

> Current cellular networks are not necessarily representative of
> future wireless networks, and thus they should to dictate the
         should be  --------------------> ^^^^^^^^^ "should not"
> requirements for Mobile IPv6 over the expected lifetime of IPv6.
> At the same time, we have to view existing wireless systems as
> a major immediate customer for our specifications, and thus make
> sure things do work well.
> 
> Regards,
> Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:31:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28990
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 15:31:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05012;
	Fri, 19 Oct 2001 13:31:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25788;
	Fri, 19 Oct 2001 12:31:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJTlOI027016
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:29:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJTkGb027015
	for mobile-ip-dist; Fri, 19 Oct 2001 12:29:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJThOI027008
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:29:43 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25437
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:29:41 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03192
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:29:16 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9JJTpm00580;
	Fri, 19 Oct 2001 12:29:51 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM11735;
	Fri, 19 Oct 2001 12:29:12 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA09187; Fri, 19 Oct 2001 12:29:36 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.32543.923529.72106@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 12:29:35 -0700 (PDT)
To: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>
Cc: "'ext Michael Thomas'" <mat@cisco.com>, <mobile-ip@sunroof.eng.sun.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Koodli Rajeev (NRC/MtView) writes:
 > >   This is, in fact, a good reason to keep things
 > >   modular. The fact that piggybacking is problematic
 > >   for many extant links, and not especially useful
 > >   for others (ie, 802.11) says to me that the KISS
 > >   principle probably applies.
 > >  
 > 
 > I am sorry: I don't see the flow of logic here.. BTW, I would have
 > agreed to the modularity  principle if you stated that one must not
 > strike out destination option because a particular link, yet
 > unspecified, does not know how to handle it.

   Modularity would dictate that a packet with two
   separate functions should be divided into two
   packets. It's quite obvious that a great deal of
   the current set of problems with MIPv6 security
   suffers from the law of unintended consequences
   directly related to trying to avoid modularity.

 > >   Also: I've asked Rajeev several times for an 
 > >   example of a L2 on a shared media which delivers
 > >   different QoS than BE which doesn't suffer from
 > >   either excessive bandwidth utilization or undue
 > >   latency/jitter for real time traffic, and thus
 > >   far he hasn't provided me a pointer. Maybe he
 > >   just can't talk about it, but if there exists
 > >   such a beast I'd _love_ to hear about it (seriously).
 > 
 > This brings back the question of whether destination option must have
 > been specified in the first place because some weird link does not know
 > how to support it! What's the logic in saying IP cannot have
 > variable-sized packets because a link would have performance issues?

   The current BU design is not modular. It claims
   that it did that because of bandwidth/latency
   gains. You have not presented a *single* MAC/PHY 
   where that claim can be tested. Here you dodge 
   my direct question yet again.

 > > > I read this as a particular response to the suggestion that
 > > > highly structured MACs couldn't handle the Binding Update.
 > > > I found his response to be reasonable, which is to say that
 > > > reasonable engineers could make it work.
 > >
 > >   Uh, how? Until details are provided, I remain
 > >   skeptical.
 > 
 > Well, please check the recent archives for header compression and
 > piggybacking interworking.

   I did. You haven't answered my question.

 > >   RTS/CTS-style links produce unacceptible latency
 > >   and jitter for real time traffic, especially at
 > >   slow link speeds.
 > >
 > 
 > So what ? If IP was designed looking into every possible link's
 > idiosyncrasies, you and I would probably not having this conversation!
 > hmm..

   I'm only looking for a single link layer which
   benefits. You haven't provided an example.

		 Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:35:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29092
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 15:35:28 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07438;
	Fri, 19 Oct 2001 13:34:21 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26754;
	Fri, 19 Oct 2001 12:34:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJXXOI027109
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:33:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJXXMN027108
	for mobile-ip-dist; Fri, 19 Oct 2001 12:33:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJXTOI027101
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:33:29 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26375
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:33:31 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09677
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:33:31 -0700 (PDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA18904
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:33:30 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9JJXUC23783
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:33:30 -0500 (CDT)
Message-ID: <3BD08188.A604AF79@alcatel.com>
Date: Fri, 19 Oct 2001 14:39:52 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com> <15312.29031.946504.371470@thomasm-u1.cisco.com> <3BD078B9.2DD35233@iprg.nokia.com> <3BD07C33.5A70C996@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Charlie,


"Charles E. Perkins" wrote:

>
>
> Definitely.  Plus we have a lot of ideas about making Mobile IPv6
> work with ad hoc wireless networks.  There, it's even more important
> to avoid extraneous packets, and synchronizing the whole ad hoc
> network to fit into the channelization requirements imposed at the
> access router is ... well ... challenging to say the least.  That's
> just another example -- I don't claim that we need to design the
> ad hoc network before getting Mobile IPv6 finished.
>

Well, mipv6 already allows generating extraneous packets.
I have a feeling that we  are getting into a religious debate
instead of a logical or an engineering one.

>
> Current cellular networks are not necessarily representative of
> future wireless networks, and thus they should to dictate the
> requirements for Mobile IPv6 over the expected lifetime of IPv6.
> At the same time, we have to view existing wireless systems as
> a major immediate customer for our specifications, and thus make
> sure things do work well.
>
> Regards,
> Charlie P.

Honestly, I think that there is enough and rough consensus already, why don't
we move ahead?
Kind regards,


--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:38:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29202
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 15:38:23 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14402;
	Fri, 19 Oct 2001 12:38:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27222;
	Fri, 19 Oct 2001 12:36:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJYfOI027151
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:34:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJYfim027149
	for mobile-ip-dist; Fri, 19 Oct 2001 12:34:41 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJYbOI027142
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:34:37 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23635
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:34:32 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28874
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:34:38 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9JJYqm03584
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:34:52 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM11875;
	Fri, 19 Oct 2001 12:34:14 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA09190; Fri, 19 Oct 2001 12:34:37 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.32845.275169.722977@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 12:34:37 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD078B9.2DD35233@iprg.nokia.com>
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
	<15312.29031.946504.371470@thomasm-u1.cisco.com>
	<3BD078B9.2DD35233@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > Michael Thomas wrote:
 > > 
 > > Glenn Morrow writes:
 > >  > GM] This is true that both sides are affected; however, the weird L2 
 > >  > should
 > >  > be adapted to handle the piggybacking in its weird way for downstream
 > >  > traffic. Just as it does other weird things for certain downstream 
 > >  > traffic
 > >  > such as layer 5 signaling.
 > > 
 > >    Can you point out a non-weird L2 which would
 > >    substantially benefit from piggybacking? I'm
 > >    pretty sure that my decidedly non-weird ethernet
 > >    at home wouldn't realize any substantial benefit.
 > > 
 > >            Mike
 > 
 > Any narrow-band link where there is substantial overhead in separating
 > one packet into two would potentially benefit from piggybacking. This
 > overhead can include channel reservation, L2 framing, etc. The overhead
 > can be both bandwidth and time.

   I specifically asked for an example on a shared media,
   with better than best effort QoS, and in particular
   suitable for real time traffic. The quoted note was
   an abbreviated form of that question.

   Also: header compression/suppression and layer two
   blocking mitigates many of the bandwidth issues,
   and does it for far more than just binding updates.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 15:41:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29292
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 15:41:00 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12273;
	Fri, 19 Oct 2001 13:40:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28309;
	Fri, 19 Oct 2001 12:40:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJdpOI027333
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:39:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JJdpYr027332
	for mobile-ip-dist; Fri, 19 Oct 2001 12:39:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JJdmOI027325
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:39:48 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24696
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:39:43 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13139
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:39:50 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9JJe3m06899
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 12:40:03 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM12008;
	Fri, 19 Oct 2001 12:39:25 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA09193; Fri, 19 Oct 2001 12:39:48 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.33156.386348.333799@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 12:39:48 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD07C33.5A70C996@iprg.nokia.com>
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
	<15312.29031.946504.371470@thomasm-u1.cisco.com>
	<3BD078B9.2DD35233@iprg.nokia.com>
	<3BD07C33.5A70C996@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Charles E. Perkins writes:
 > Current cellular networks are not necessarily representative of
 > future wireless networks, and thus they should to dictate the
 > requirements for Mobile IPv6 over the expected lifetime of IPv6.

   Right. They'll be a lot faster, and thus not care
   very much about piggybacking any more than my home
   802.11 network cares. Yet another reason to not
   engineer unmodular designs into MIPv6.

		      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 16:22:03 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00223
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 16:22:03 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13080;
	Fri, 19 Oct 2001 14:20:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05563;
	Fri, 19 Oct 2001 13:20:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKJlOI027676
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:19:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JKJlsd027675
	for mobile-ip-dist; Fri, 19 Oct 2001 13:19:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKJhOI027668
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:19:43 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05144
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:19:39 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20522
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:19:46 -0700 (PDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA26560
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:19:45 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 19 Oct 2001 15:18:02 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L6WGT>; Fri, 19 Oct 2001 15:19:00 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E75CCC6@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 19 Oct 2001 15:18:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C158DB.489EBFD0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C158DB.489EBFD0
Content-Type: text/plain;
	charset="iso-8859-1"

Mike,

I'm sorry no one ever responded to this before. Here is an example I hope
meets your criteria:

WI-FI enhanced with priority contingence and an SBM such a media. 

- Seems to meet the shared media requirement
- Seems to meet the better than best effort
- Seems reasonable for all types traffic as well

I guess we could add regular ethernet with 802.1p and an SBM as well i.e. 
I think it would be very useful if the WAN component for these media is
something like a good old T1, cable modem or DSL, 802.16 etc.. etc.. etc..
to manage bandwidth for all (layer 5 protocols) accross this WAN link and
WAN links on the other side. RSVP with a binding update piggybacked would be
very useful for managing bandwidth for both real-time and other
communications with handoff as a component.

For the ROHC, ROHC is doing special things already. It is a middle-box
technology - similar to a NAT in some ways. It can do special things with a
binding update, too - just like it does for everything else.

I'm sorry - I'm just not buying your arguments.

regards,

Glenn

> 
>    I specifically asked for an example on a shared media,
>    with better than best effort QoS, and in particular
>    suitable for real time traffic. The quoted note was
>    an abbreviated form of that question.
> 
>    Also: header compression/suppression and layer two
>    blocking mitigates many of the bandwidth issues,
>    and does it for far more than just binding updates.
> 
> 	    Mike
> 

------_=_NextPart_001_01C158DB.489EBFD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Mike,</FONT>
</P>

<P><FONT SIZE=3D2>I'm sorry no one ever responded to this before. Here =
is an example I hope meets your criteria:</FONT>
</P>

<P><FONT SIZE=3D2>WI-FI enhanced with priority contingence and an SBM =
such a media. </FONT>
</P>

<P><FONT SIZE=3D2>- Seems to meet the shared media requirement</FONT>
<BR><FONT SIZE=3D2>- Seems to meet the better than best effort</FONT>
<BR><FONT SIZE=3D2>- Seems reasonable for all types traffic as =
well</FONT>
</P>

<P><FONT SIZE=3D2>I guess we could add regular ethernet with 802.1p and =
an SBM as well i.e. </FONT>
<BR><FONT SIZE=3D2>I think it would be very useful if the WAN component =
for these media is something like a good old T1, cable modem or DSL, =
802.16 etc.. etc.. etc.. to manage bandwidth for all (layer 5 =
protocols) accross this WAN link and WAN links on the other side. RSVP =
with a binding update piggybacked would be very useful for managing =
bandwidth for both real-time and other communications with handoff as a =
component.</FONT></P>

<P><FONT SIZE=3D2>For the ROHC, ROHC is doing special things already. =
It is a middle-box technology - similar to a NAT in some ways. It can =
do special things with a binding update, too - just like it does for =
everything else.</FONT></P>

<P><FONT SIZE=3D2>I'm sorry - I'm just not buying your =
arguments.</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; I specifically asked for an =
example on a shared media,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; with better than best effort =
QoS, and in particular</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; suitable for real time =
traffic. The quoted note was</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; an abbreviated form of that =
question.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Also: header =
compression/suppression and layer two</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; blocking mitigates many of =
the bandwidth issues,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; and does it for far more than =
just binding updates.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; Mike</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C158DB.489EBFD0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 16:31:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00571
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 16:31:26 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07451;
	Fri, 19 Oct 2001 13:30:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10323;
	Fri, 19 Oct 2001 13:29:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKSoOI027813
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:28:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JKSoAH027812
	for mobile-ip-dist; Fri, 19 Oct 2001 13:28:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKSkOI027805
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:28:46 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12571
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:28:49 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10320
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:58:20 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA28943
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:28:48 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 19 Oct 2001 15:27:11 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L6W3R>; Fri, 19 Oct 2001 15:28:09 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E7B4CF8@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Fri, 19 Oct 2001 15:28:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C158DC.915DFD70"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C158DC.915DFD70
Content-Type: text/plain;
	charset="iso-8859-1"

Modularity is achieved with logical demarcation via statistical multiplexing
of options within headers and headers themselves. Piggybacking is modular.
Modularity is achieved the same way that modularity is acheived in a packet
containing IP, TCP and HTTP. These things are doing separate functions and
yet they work synergistically. They are all contained in the same packet,
however.

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, October 19, 2001 2:30 PM
> To: Koodli Rajeev (NRC/MtView)
> Cc: 'ext Michael Thomas'; mobile-ip; Michael A. Ramalho
> Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
> 
> 
> Koodli Rajeev (NRC/MtView) writes:
>  > >   This is, in fact, a good reason to keep things
>  > >   modular. The fact that piggybacking is problematic
>  > >   for many extant links, and not especially useful
>  > >   for others (ie, 802.11) says to me that the KISS
>  > >   principle probably applies.
>  > >  
>  > 
>  > I am sorry: I don't see the flow of logic here.. BTW, I would have
>  > agreed to the modularity  principle if you stated that one must not
>  > strike out destination option because a particular link, yet
>  > unspecified, does not know how to handle it.
> 
>    Modularity would dictate that a packet with two
>    separate functions should be divided into two
>    packets. It's quite obvious that a great deal of
>    the current set of problems with MIPv6 security
>    suffers from the law of unintended consequences
>    directly related to trying to avoid modularity.
> 
>  > >   Also: I've asked Rajeev several times for an 
>  > >   example of a L2 on a shared media which delivers
>  > >   different QoS than BE which doesn't suffer from
>  > >   either excessive bandwidth utilization or undue
>  > >   latency/jitter for real time traffic, and thus
>  > >   far he hasn't provided me a pointer. Maybe he
>  > >   just can't talk about it, but if there exists
>  > >   such a beast I'd _love_ to hear about it (seriously).
>  > 
>  > This brings back the question of whether destination 
> option must have
>  > been specified in the first place because some weird link 
> does not know
>  > how to support it! What's the logic in saying IP cannot have
>  > variable-sized packets because a link would have 
> performance issues?
> 
>    The current BU design is not modular. It claims
>    that it did that because of bandwidth/latency
>    gains. You have not presented a *single* MAC/PHY 
>    where that claim can be tested. Here you dodge 
>    my direct question yet again.
> 
>  > > > I read this as a particular response to the suggestion that
>  > > > highly structured MACs couldn't handle the Binding Update.
>  > > > I found his response to be reasonable, which is to say that
>  > > > reasonable engineers could make it work.
>  > >
>  > >   Uh, how? Until details are provided, I remain
>  > >   skeptical.
>  > 
>  > Well, please check the recent archives for header compression and
>  > piggybacking interworking.
> 
>    I did. You haven't answered my question.
> 
>  > >   RTS/CTS-style links produce unacceptible latency
>  > >   and jitter for real time traffic, especially at
>  > >   slow link speeds.
>  > >
>  > 
>  > So what ? If IP was designed looking into every possible link's
>  > idiosyncrasies, you and I would probably not having this 
> conversation!
>  > hmm..
> 
>    I'm only looking for a single link layer which
>    benefits. You haven't provided an example.
> 
> 		 Mike
> 

------_=_NextPart_001_01C158DC.915DFD70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Modularity is achieved with logical demarcation via =
statistical multiplexing of options within headers and headers =
themselves. Piggybacking is modular. Modularity is achieved the same =
way that modularity is acheived in a packet containing IP, TCP and =
HTTP. These things are doing separate functions and yet they work =
synergistically. They are all contained in the same packet, =
however.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Michael Thomas [<A =
HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, October 19, 2001 2:30 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Koodli Rajeev (NRC/MtView)</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'ext Michael Thomas'; mobile-ip; Michael A. =
Ramalho</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [mobile-ip] MIPv6 - Focus of the =
security discussion</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Koodli Rajeev (NRC/MtView) writes:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; This is, in fact, a =
good reason to keep things</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; modular. The fact =
that piggybacking is problematic</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; for many extant =
links, and not especially useful</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; for others (ie, =
802.11) says to me that the KISS</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; principle probably =
applies.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; I am sorry: I don't see the flow of =
logic here.. BTW, I would have</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; agreed to the modularity&nbsp; =
principle if you stated that one must not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; strike out destination option =
because a particular link, yet</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; unspecified, does not know how to =
handle it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Modularity would dictate that =
a packet with two</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; separate functions should be =
divided into two</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; packets. It's quite obvious =
that a great deal of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the current set of problems =
with MIPv6 security</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; suffers from the law of =
unintended consequences</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; directly related to trying to =
avoid modularity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; Also: I've asked =
Rajeev several times for an </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; example of a L2 on =
a shared media which delivers</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; different QoS than =
BE which doesn't suffer from</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; either excessive =
bandwidth utilization or undue</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; latency/jitter for =
real time traffic, and thus</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; far he hasn't =
provided me a pointer. Maybe he</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; just can't talk =
about it, but if there exists</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; such a beast I'd =
_love_ to hear about it (seriously).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; This brings back the question of =
whether destination </FONT>
<BR><FONT SIZE=3D2>&gt; option must have</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; been specified in the first place =
because some weird link </FONT>
<BR><FONT SIZE=3D2>&gt; does not know</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; how to support it! What's the logic =
in saying IP cannot have</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; variable-sized packets because a =
link would have </FONT>
<BR><FONT SIZE=3D2>&gt; performance issues?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; The current BU design is not =
modular. It claims</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; that it did that because of =
bandwidth/latency</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; gains. You have not presented =
a *single* MAC/PHY </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; where that claim can be =
tested. Here you dodge </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; my direct question yet =
again.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt; &gt; I read this as a =
particular response to the suggestion that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt; &gt; highly structured MACs =
couldn't handle the Binding Update.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt; &gt; I found his response to be =
reasonable, which is to say that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt; &gt; reasonable engineers could =
make it work.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; Uh, how? Until =
details are provided, I remain</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; skeptical.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Well, please check the recent =
archives for header compression and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; piggybacking interworking.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; I did. You haven't answered =
my question.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; RTS/CTS-style links =
produce unacceptible latency</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; and jitter for real =
time traffic, especially at</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;&nbsp;&nbsp; slow link =
speeds.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; So what ? If IP was designed looking =
into every possible link's</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; idiosyncrasies, you and I would =
probably not having this </FONT>
<BR><FONT SIZE=3D2>&gt; conversation!</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; hmm..</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; I'm only looking for a single =
link layer which</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; benefits. You haven't =
provided an example.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C158DC.915DFD70--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 16:45:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00994
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 16:45:56 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02065;
	Fri, 19 Oct 2001 14:45:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14166;
	Fri, 19 Oct 2001 13:45:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKiTOI027971
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:44:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JKiTKP027970
	for mobile-ip-dist; Fri, 19 Oct 2001 13:44:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKiQOI027963
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:44:26 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15726
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:44:29 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15418
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:08:45 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA24413;
	Fri, 19 Oct 2001 13:08:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JK8cZ03681;
	Fri, 19 Oct 2001 13:08:38 -0700
X-mProtect:  Fri, 19 Oct 2001 13:08:38 -0700 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141130.americas.nokia.com (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdujDB8G; Fri, 19 Oct 2001 13:08:36 PDT
Message-ID: <3BD0883E.3AC7252@iprg.nokia.com>
Date: Fri, 19 Oct 2001 13:08:30 -0700
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'ext Michael Thomas'" <mat@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com> <15312.32543.923529.72106@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Mike,

Michael Thomas wrote:

> Koodli Rajeev (NRC/MtView) writes:
>  > >   This is, in fact, a good reason to keep things
>  > >   modular. The fact that piggybacking is problematic
>  > >   for many extant links, and not especially useful
>  > >   for others (ie, 802.11) says to me that the KISS
>  > >   principle probably applies.
>  > >
>  >
>  > I am sorry: I don't see the flow of logic here.. BTW, I would have
>  > agreed to the modularity  principle if you stated that one must not
>  > strike out destination option because a particular link, yet
>  > unspecified, does not know how to handle it.
>
>    Modularity would dictate that a packet with two
>    separate functions should be divided into two
>    packets. It's quite obvious that a great deal of
>    the current set of problems with MIPv6 security
>    suffers from the law of unintended consequences
>    directly related to trying to avoid modularity.

Modularity means flexibility. So any modularity principle would
dictate -dictate is probably a bad choice of word: we would have
a 'flexible dictator'- if anything, that separate functions COULD be divided
into two packets, or COULD be integrated in one. That's modularity for you.

Point is: do not call upon modularity to dismiss a perfectly good idea that
precisely adds modularity to the network.

Cedric.

ps: Your 'modular dictator' is a softy, because it edicts 'should's instead of
'must's,
as any self respecting dictator would.

>
>
>  > >   Also: I've asked Rajeev several times for an
>  > >   example of a L2 on a shared media which delivers
>  > >   different QoS than BE which doesn't suffer from
>  > >   either excessive bandwidth utilization or undue
>  > >   latency/jitter for real time traffic, and thus
>  > >   far he hasn't provided me a pointer. Maybe he
>  > >   just can't talk about it, but if there exists
>  > >   such a beast I'd _love_ to hear about it (seriously).
>  >
>  > This brings back the question of whether destination option must have
>  > been specified in the first place because some weird link does not know
>  > how to support it! What's the logic in saying IP cannot have
>  > variable-sized packets because a link would have performance issues?
>
>    The current BU design is not modular. It claims
>    that it did that because of bandwidth/latency
>    gains. You have not presented a *single* MAC/PHY
>    where that claim can be tested. Here you dodge
>    my direct question yet again.
>
>  > > > I read this as a particular response to the suggestion that
>  > > > highly structured MACs couldn't handle the Binding Update.
>  > > > I found his response to be reasonable, which is to say that
>  > > > reasonable engineers could make it work.
>  > >
>  > >   Uh, how? Until details are provided, I remain
>  > >   skeptical.
>  >
>  > Well, please check the recent archives for header compression and
>  > piggybacking interworking.
>
>    I did. You haven't answered my question.
>
>  > >   RTS/CTS-style links produce unacceptible latency
>  > >   and jitter for real time traffic, especially at
>  > >   slow link speeds.
>  > >
>  >
>  > So what ? If IP was designed looking into every possible link's
>  > idiosyncrasies, you and I would probably not having this conversation!
>  > hmm..
>
>    I'm only looking for a single link layer which
>    benefits. You haven't provided an example.
>
>                  Mike



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 16:48:47 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01083
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 16:48:47 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03870;
	Fri, 19 Oct 2001 14:47:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14833;
	Fri, 19 Oct 2001 13:47:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKkxOI028027
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:47:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JKkxir028025
	for mobile-ip-dist; Fri, 19 Oct 2001 13:46:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKkuOI028015
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:46:56 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16120
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:46:58 -0700 (PDT)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21529
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:16:29 -0600 (MDT)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9JKi8117649
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:44:08 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9JKkuS20015
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:46:56 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256AEA.007223EC ; Fri, 19 Oct 2001 13:46:43 -0700
X-Lotus-FromDomain: 3COM
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <88256AEA.00722252.00@hqoutbound.ops.3com.com>
Date: Fri, 19 Oct 2001 15:47:24 -0500
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=LJ34Tz5u7IXI47oyY0zsJ5zjAcunkpGxLNz3omdAG8PcL54HlogW0P3Z"
Content-Disposition: inline
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--0__=LJ34Tz5u7IXI47oyY0zsJ5zjAcunkpGxLNz3omdAG8PcL54HlogW0P3Z
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.








--0__=LJ34Tz5u7IXI47oyY0zsJ5zjAcunkpGxLNz3omdAG8PcL54HlogW0P3Z
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF
Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41MC40MTM0LjYwMCIgbmFtZT1HRU5FUkFUT1I+
PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxTUEFOIGNsYXNzPTg0ODQ1MDkyMS0xODEwMjAwMT48Rk9O
VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+QWx0aG91Z2ggSSBhbSBub3Qgc3Vy
ZSBvZiB0aGUgaW50ZW50aW9uIGluIHRoZSBSRkMsIEkgYWdyZWUgdGhhdCB0aGUgYnl0ZSANCnNo
b3VsZCBub3QgYmUgZHVwbGljYXRlZCBpbiAyIHBsYWNlcy4gSSBhbHNvIHNlZW0gdG8gcmVtZW1i
ZXIgdGhhdCBrbm93biANCmR1cGxpY2F0aW9uIHRlbmRzIHRvIHdlYWtlbiB0aGUgc2VjdXJpdHku
PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9ODQ4NDUwOTIxLTE4MTAyMDAx
PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZu
YnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz04NDg0NTA5MjEtMTgxMDIwMDE+PEZPTlQgZmFj
ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPkJvYjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8
QkxPQ0tRVU9URSBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWPjwvRElWPg0KICA8
RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1s
ZWZ0PjxGT05UIA0KICBmYWNlPVRhaG9tYSBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08QlI+PEI+RnJvbTo8L0I+IA0KICBvd25lci1tb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNv
bSANCiAgW21haWx0bzpvd25lci1tb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbV0gPEI+T24g
QmVoYWxmIE9mIDwvQj5OaXNoIA0KICBBYnJvbDxCUj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIE9j
dG9iZXIgMTgsIDIwMDEgMTI6MTQgQU08QlI+PEI+VG86PC9CPiANCiAgY2hhcmxpZXBAaXByZy5u
b2tpYS5jb207IHBjYWxob3VuQGRpYW1ldGVyLm9yZzsgDQogIG1vYmlsZS1pcEBzdW5yb29mLmVu
Zy5zdW4uY29tPEJSPjxCPlN1YmplY3Q6PC9CPiBbbW9iaWxlLWlwXSBVUkdFTlQgLSByZmMzMDEy
IA0KICBpbnRlcnByZXRhdGlvbiBxdWVzdGlvbjxCUj48QlI+PC9GT05UPjwvRElWPlBhdC9DaGFy
bGllLDxCUj48QlI+UmVhbGx5IA0KICBhcHByZWNpYXRlIGFueSBpbnNpZ2h0cyBpbnRvIHRoaXMg
cmVhbGx5IGltcG9ydGFudCBpbnRlcm9wIGlzc3VlIGZvciANCiAgY2RtYTIwMDA6PEJSPjxCUj5B
IHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUmbmJzcDsgaW50ZXJwcmV0YXRpb24gb2Ygc2VjdGlvbiA4
IG9mIA0KICByZmMzMDEyLiBUaGlzIHNlY3Rpb24gc3BlY2lmaWVzIGhvdyB0byBjYWxjdWxhdGUg
dGhlIE1OLUFBQSBhdXRoZW50aWNhdG9yLiBJdCANCiAgc2F5czo8QlI+PEJSPiIgVG8gY29tcHV0
ZSB0aGUgYXV0aGVudGljYXRvciwgYXBwbHkgTUQ1IFsxMV0gY29tcHV0ZWQgb24gDQogIHRoZTxC
Uj5mb2xsb3dpbmcgZGF0YSwgaW4gdGhlIG9yZGVyIHNob3duOjxCUj48QlI+SGlnaC1vcmRlciBi
eXRlIGZyb20gDQogIENoYWxsZW5nZSB8fCBLZXkgfHw8QlI+TUQ1KFByZWNlZGluZyBNb2JpbGUg
SVAgZGF0YSB8fDxCUj5UeXBlLCBTdWJ0eXBlIChpZiANCiAgcHJlc2VudCksIExlbmd0aCwgU1BJ
KSB8fDxCUj5MZWFzdC1vcmRlciAyMzcgYnl0ZXMgZnJvbSBDaGFsbGVuZ2UgIjxCUj48QlI+VGhl
IA0KICBxdWVzdGlvbiBpcyAtIGlmIHRoZSBjaGFsbGVuZ2UgaGFzIGxlc3MgdGhhbiAyMzcgYnl0
ZXMgLSBzaG91bGQgdGhlIGhpZ2ggb3JkZXIgDQogIGJ5dGUgd2hpY2ggd2FzIGFscmVhZHkgdXNl
ZCBpbiB0aGUgTUQ1IGNhbGN1bGF0aW9uJm5ic3A7IGJlIGluY2x1ZGVkIGFnYWluIGFzIA0KICBw
YXJ0IG9mIHRoZSZuYnNwOyAibGVhc3Qtb3JkZXIgMjM3IGJ5dGVzIGZyb20gQ2hhbGxlbmdlIj88
QlI+PEJSPmUuZy4gaWYgdGhlIA0KICBjaGFsbGVuZ2UgaXMgNTAgYnl0ZXMgaW4gbGVuZ3RoIC0g
c2hvdWxkIHRoZSBhdXRoZW50aWNhdG9yIGJlIGNhbGN1bGF0ZWQmbmJzcDsgDQogIGFzOjxCUj4m
bmJzcDsmbmJzcDsmbmJzcDsgKGEpJm5ic3A7IGF1dGhlbmljYXRvciA9IG1kNShieXRlMCB8fCBr
ZXkuLi4uLi4ufHwgDQogIGJ5dGUxIHRocm91Z2ggYnl0ZTQ5KTxCUj48QlI+b3IgKGIpIGF1dGhl
bnRpY2F0b3IgPSBtZDUoYnl0ZTAgfHwga2V5IC4uLi4uLnx8IA0KICA8VT5ieXRlMCA8L1U+dGhy
b3VnaCBieXRlNDkpLjxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJl
IA0KICBieXRlMCBpcyB0aGUgbW9zdCBzaWduaWZpY2FudCBieXRlIG9mIHRoZSBjaGFsbGVuZ2Uu
PEJSPjxCUj5BIHN0cmljdCByZWFkaW5nIA0KICBvZiB0aGUgUkZDIHNlZW1zIHRvIHN1Z2dlc3Qg
KGIpLiBIb3dldmVyLCBpdCBzZWVtcyZuYnNwOyB0aGF0IGNhbGN1bGF0aW5nIHRoZSANCiAgTUQ1
IGF1dGhlbnRpY2F0b3Igd2l0aCB0aGUgc2FtZSBpbmZvcm1hdGlvbihoaWdoIG9yZGVyIGJ5dGUp
IGF0IGRpZmZlcmVudCANCiAgbG9jYXRpb25zIG9mIHRoZSBwYXlsb2FkIHdlYWtlbnMgdGhlIGF1
dGhlbnRpY2F0b3IuPEJSPjxCUj5Tbywgd2hhdCB3YXMgdGhlIA0KICBpbnRlbnRpb24gb2YgdGhl
IFJGQyBhbmQgaG93IHNob3VsZCBpdCBiZSBpbXBsZW1lbnRlZD8gQWxzbywgZG8geW91IGtub3cg
aWYgDQogIFJGQzMwMTIgaW1wbGVtZW50YXRpb25zIGhhdmUgcGFydGljaXBhdGVkIGluIGFueSBi
YWtlb2Zmcy9pbnRlcm9wcy4gSWYgc28sIGhvdyANCiAgaGF2ZSB0aGV5IGludGVycHJldGVkIHRo
aXMgc2VjdGlvbj88QlI+PEJSPllvdXIgaGVscCB3aWxsIGJlIHJlYWxseSANCiAgYXBwcmVjaWF0
ZWQuPEJSPjxCUj5UaGFua3M8QlI+TmlzaCBBYnJvbDxCUj5RdWFsY29tbSwgDQpJbmMuPEJSPjxC
Uj48QlI+PEJSPjxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg==

--0__=LJ34Tz5u7IXI47oyY0zsJ5zjAcunkpGxLNz3omdAG8PcL54HlogW0P3Z--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 16:50:51 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01120
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 16:50:50 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05925;
	Fri, 19 Oct 2001 14:50:25 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15865;
	Fri, 19 Oct 2001 13:50:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKnqOI028175
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:49:52 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JKnqUe028174
	for mobile-ip-dist; Fri, 19 Oct 2001 13:49:52 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JKnmOI028164
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:49:48 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03037
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:49:51 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17593
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:49:46 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA27878
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:49:45 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JKnig09441
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:49:44 -0700
X-mProtect:  Fri, 19 Oct 2001 13:49:44 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdAV7T0c; Fri, 19 Oct 2001 13:49:43 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA16472 for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 13:49:39 -0700 (PDT)
Message-ID: <3BD091E3.1D3E2C21@iprg.nokia.com>
Date: Fri, 19 Oct 2001 13:49:39 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
		<15312.29031.946504.371470@thomasm-u1.cisco.com>
		<3BD078B9.2DD35233@iprg.nokia.com> <15312.32845.275169.722977@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

>  > >    Can you point out a non-weird L2 which would
>  > >    substantially benefit from piggybacking? I'm
>  > >    pretty sure that my decidedly non-weird ethernet
>  > >    at home wouldn't realize any substantial benefit.
>  > >
>  > >            Mike
>  >
>  > Any narrow-band link where there is substantial overhead in separating
>  > one packet into two would potentially benefit from piggybacking. This
>  > overhead can include channel reservation, L2 framing, etc. The overhead
>  > can be both bandwidth and time.
> 
>    I specifically asked for an example on a shared media,
>    with better than best effort QoS, and in particular
>    suitable for real time traffic. The quoted note was
>    an abbreviated form of that question.

So you are saying best effort shared links should be disregarded?
What if the traffic is mostly control traffic and one wants to
maximize throughput over a narrow-band best effort shared link?

>    Also: header compression/suppression and layer two
>    blocking mitigates many of the bandwidth issues,
>    and does it for far more than just binding updates.

HC is not going to be available/solve these for legacy L2s and
not necessarily all future L2s either. There are media with collision
detection vs. collision avoidance schemes, too. Also, latency savings
could be of importance, e.g., with high-power links, L1 switching times
may be an issue on some legacy links (non-QSK RF). Just to give
a counter-example that there is variance in design parameters
below L3.

Also, speaking of modularity with piggybacking, the IPv6 extension
header structure seems to be designed to be natural for piggybacking,
in order to run separate protocols in a modular way over the same
packets. To be consistent, disallowing piggybacking has implications
over Mobile IPv6. No variable length packets, extensions, or upper layer,
would be tolerated, since such a link is not a fully-capable IPv6 link
and this has to be communicated to the endpoints, e.g. usin some QoS
signaling. I do not see why just disabling piggybacking over such a
link is not an option.

>             Mike

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:02:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01435
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:02:44 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20707;
	Fri, 19 Oct 2001 14:02:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18422;
	Fri, 19 Oct 2001 14:02:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JL1GOI028399
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:01:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JL1Gg7028398
	for mobile-ip-dist; Fri, 19 Oct 2001 14:01:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JL1COI028391
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:01:12 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18148
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:01:15 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13675
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:00:50 -0600 (MDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA13037
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 16:01:14 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9JL1ED11271
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 16:01:14 -0500 (CDT)
Message-ID: <3BD09618.82CA170D@alcatel.com>
Date: Fri, 19 Oct 2001 16:07:36 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CCC6@zrc2c012.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------4DAEA676C8998370DEFBA684"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------4DAEA676C8998370DEFBA684
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi again Glenn,
  I am going to reply to your two consecutive mails, just on RSVP and
layering:
1. RSVP. Firstly mipv6 allows sending BUs separately (as I said in my
email yesterday, mipv4 mandates, i.e. not only allows but requires, this
already for registration requests), i.e. not piggybacked, so how are
going to achieve what you wish to have as a required behaviour?
This answer is you need to standardize. An example such thing is in
AAA-mipv4 application defined in draft-ietf-aaa-diameter-mobileip-07.txt
(nicely defined by Pat and Charlie!)
2. You said in your mail:
Modularity is achieved the same way that modularity is acheived in a
packet containing IP, TCP and HTTP.

This is because HTTP is an application layer protocol, it uses TCP as
the transport layer, i.e. L4 which in turn uses IP as the network layer,
i.e. L3.
A bit of lesson on OSI layering, please.

Kind regards,

Glenn Morrow wrote:

>
>
> Mike,
>
> I'm sorry no one ever responded to this before. Here is an example I
> hope meets your criteria:

--
Behcet

--------------4DAEA676C8998370DEFBA684
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi again Glenn,
<br>&nbsp; I am going to reply to your two consecutive mails, just on RSVP
and layering:
<br>1. RSVP. Firstly mipv6 allows sending BUs separately (as I said in
my email yesterday, mipv4 mandates, i.e. not only allows but requires,
this already for registration requests), i.e. not piggybacked, so how are
going to achieve what you wish to have as a required behaviour?
<br>This answer is you need to standardize. An example such thing is in
AAA-mipv4 application defined in draft-ietf-aaa-diameter-mobileip-07.txt
(nicely defined by Pat and Charlie!)
<br>2. You said in your mail:
<br>Modularity is achieved the same way that modularity is acheived in
a
<br>packet containing IP, TCP and HTTP.
<p>This is because HTTP is an application layer protocol, it uses TCP as
the transport layer, i.e. L4 which in turn uses IP as the network layer,
i.e. L3.
<br>A bit of lesson on OSI layering, please.
<p>Kind regards,
<p>Glenn Morrow wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>Mike,</font>
<p><font size=-1>I'm sorry no one ever responded to this before. Here is
an example I hope meets your criteria:</font></blockquote>
--
<br>Behcet</html>

--------------4DAEA676C8998370DEFBA684--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:04:30 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01532
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:04:30 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15748;
	Fri, 19 Oct 2001 15:03:24 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18771;
	Fri, 19 Oct 2001 14:03:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JL2cOI028437
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:02:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JL2cxK028436
	for mobile-ip-dist; Fri, 19 Oct 2001 14:02:38 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JL2XOI028425
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:02:33 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19658
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:02:36 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10948
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:02:35 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9JL2fY03880;
	Fri, 19 Oct 2001 14:02:41 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM14230;
	Fri, 19 Oct 2001 14:02:10 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09215; Fri, 19 Oct 2001 14:02:33 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.38121.546181.679532@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 14:02:33 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'ext Michael Thomas'" <mat@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD0883E.3AC7252@iprg.nokia.com>
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
	<15312.32543.923529.72106@thomasm-u1.cisco.com>
	<3BD0883E.3AC7252@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Cedric Westphal writes:
 > Modularity means flexibility. So any modularity principle would
 > dictate -dictate is probably a bad choice of word: we would have
 > a 'flexible dictator'- if anything, that separate functions COULD be divided
 > into two packets, or COULD be integrated in one. That's modularity for you.
 > 
 > Point is: do not call upon modularity to dismiss a perfectly good idea that
 > precisely adds modularity to the network.

   Does putting SMTP datagrams into HTTP datagrams
   increase network modularity?

		    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:10:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01706
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:10:57 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21039;
	Fri, 19 Oct 2001 15:10:32 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20671;
	Fri, 19 Oct 2001 14:10:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLA2OI028743
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:10:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLA1VU028742
	for mobile-ip-dist; Fri, 19 Oct 2001 14:10:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JL9wOI028735
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:09:58 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20428
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:10:01 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14444
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:10:01 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA29312;
	Fri, 19 Oct 2001 14:09:54 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JL9sJ14793;
	Fri, 19 Oct 2001 14:09:54 -0700
X-mProtect:  Fri, 19 Oct 2001 14:09:54 -0700 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141130.americas.nokia.com (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdNtb7vf; Fri, 19 Oct 2001 14:09:51 PDT
Message-ID: <3BD09695.8E145AE4@iprg.nokia.com>
Date: Fri, 19 Oct 2001 14:09:42 -0700
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'ext Michael Thomas'" <mat@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
		<15312.32543.923529.72106@thomasm-u1.cisco.com>
		<3BD0883E.3AC7252@iprg.nokia.com> <15312.38121.546181.679532@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael Thomas wrote:

> Cedric Westphal writes:
>  > Modularity means flexibility. So any modularity principle would
>  > dictate -dictate is probably a bad choice of word: we would have
>  > a 'flexible dictator'- if anything, that separate functions COULD be divided
>  > into two packets, or COULD be integrated in one. That's modularity for you.
>  >
>  > Point is: do not call upon modularity to dismiss a perfectly good idea that
>  > precisely adds modularity to the network.
>
>    Does putting SMTP datagrams into HTTP datagrams
>    increase network modularity?
>
>                     Mike

Don't you think this is beside the point?

Cedric.



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:17:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01934
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:17:33 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26294;
	Fri, 19 Oct 2001 15:17:08 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22425;
	Fri, 19 Oct 2001 14:17:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLFIOI028905
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLFHMU028904
	for mobile-ip-dist; Fri, 19 Oct 2001 14:15:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLFEOI028897
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:14 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22640
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:17 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16843
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:17 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9JLFLU12944
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:21 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM14558;
	Fri, 19 Oct 2001 14:14:14 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09218; Fri, 19 Oct 2001 14:14:37 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.38845.863907.180480@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 14:14:37 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD091E3.1D3E2C21@iprg.nokia.com>
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
	<15312.29031.946504.371470@thomasm-u1.cisco.com>
	<3BD078B9.2DD35233@iprg.nokia.com>
	<15312.32845.275169.722977@thomasm-u1.cisco.com>
	<3BD091E3.1D3E2C21@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > >    I specifically asked for an example on a shared media,
 > >    with better than best effort QoS, and in particular
 > >    suitable for real time traffic. The quoted note was
 > >    an abbreviated form of that question.
 > 
 > So you are saying best effort shared links should be disregarded?

   Where did I imply that? I'd like to see an example
   for a situation that I think we can all agree would
   benefit if it were achievable. Thus far, nobody's 
   come up with a link layer/techology where it actually
   would be useful in that situation.

 > What if the traffic is mostly control traffic and one wants to
 > maximize throughput over a narrow-band best effort shared link?

   It should implement L2 header compression.

 > 
 > >    Also: header compression/suppression and layer two
 > >    blocking mitigates many of the bandwidth issues,
 > >    and does it for far more than just binding updates.
 > 
 > HC is not going to be available/solve these for legacy L2s and
 > not necessarily all future L2s either. 

   If this is the case, then it obviously doesn't much
   matter for that L2 because binding updates are an
   extremely small percentage of overall traffic. Even
   less when you consider that not all BU's would be
   piggyback candidates.

 > Also, speaking of modularity with piggybacking, the IPv6 extension
 > header structure seems to be designed to be natural for piggybacking,
 > in order to run separate protocols in a modular way over the same
 > packets.

   I have never claimed that the extension headers
   are modular; some are, some aren't.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:18:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01975
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:18:14 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26226;
	Fri, 19 Oct 2001 15:17:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22423;
	Fri, 19 Oct 2001 14:17:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLFuOI028921
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLFu0L028920
	for mobile-ip-dist; Fri, 19 Oct 2001 14:15:56 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLFqOI028910
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:52 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19574
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:33 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29445
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:15:39 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9JLFhU13237;
	Fri, 19 Oct 2001 14:15:43 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM14590;
	Fri, 19 Oct 2001 14:15:05 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09222; Fri, 19 Oct 2001 14:15:28 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.38896.76146.978934@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 14:15:28 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'ext Michael Thomas'" <mat@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD09695.8E145AE4@iprg.nokia.com>
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
	<15312.32543.923529.72106@thomasm-u1.cisco.com>
	<3BD0883E.3AC7252@iprg.nokia.com>
	<15312.38121.546181.679532@thomasm-u1.cisco.com>
	<3BD09695.8E145AE4@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Cedric Westphal writes:
 > 
 > Michael Thomas wrote:
 > 
 > > Cedric Westphal writes:
 > >  > Modularity means flexibility. So any modularity principle would
 > >  > dictate -dictate is probably a bad choice of word: we would have
 > >  > a 'flexible dictator'- if anything, that separate functions COULD be divided
 > >  > into two packets, or COULD be integrated in one. That's modularity for you.
 > >  >
 > >  > Point is: do not call upon modularity to dismiss a perfectly good idea that
 > >  > precisely adds modularity to the network.
 > >
 > >    Does putting SMTP datagrams into HTTP datagrams
 > >    increase network modularity?
 > >
 > >                     Mike
 > 
 > Don't you think this is beside the point?

   It's exactly the point.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:23:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02105
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:23:12 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00252;
	Fri, 19 Oct 2001 15:22:07 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23981;
	Fri, 19 Oct 2001 14:22:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLLIOI029153
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:21:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLLIoI029152
	for mobile-ip-dist; Fri, 19 Oct 2001 14:21:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLLEOI029145
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:21:14 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23737
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:21:17 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02249
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:21:17 -0700 (PDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA12694
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 16:21:15 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 19 Oct 2001 16:14:20 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L6X40>; Fri, 19 Oct 2001 16:20:28 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF4D7@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Fri, 19 Oct 2001 16:20:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C158E3.E12AE5F0"
X-Orig: <amuhanna@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C158E3.E12AE5F0
Content-Type: text/plain;
	charset="iso-8859-1"


I have never heard of any implementation which generates a Challenge value
of 238 bytes or more.
I believe that the whole idea of mentioning the number of least-order bytes
of Challenge (237) in section 8 of RFC3012 is very simply to avoid having
the PDSN sending more than 253 bytes in the CHAP-CHALLENGE attribute to
RADIUS during MN-AAA authentication.
In reality, no one is producing a CHALLENGE value that Huge.

On the other hand, whatever amount of extra security introduced by avoiding
having two exact bytes of the Challenge at two different location is an
ABSOLUTE PLUS.


Ahmad Muhanna

-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 3:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general
concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.








------_=_NextPart_001_01C158E3.E12AE5F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I have never heard of any implementation which =
generates a Challenge value of 238 bytes or more.</FONT>
<BR><FONT SIZE=3D2>I believe that the whole idea of mentioning the =
number of least-order bytes of Challenge (237) in section 8 of RFC3012 =
is very simply to avoid having the PDSN sending more than 253 bytes in =
the CHAP-CHALLENGE attribute to RADIUS during MN-AAA =
authentication.</FONT></P>

<P><FONT SIZE=3D2>In reality, no one is producing a CHALLENGE value =
that Huge.</FONT>
</P>

<P><FONT SIZE=3D2>On the other hand, whatever amount of extra security =
introduced by avoiding having two exact bytes of the Challenge at two =
different location is an ABSOLUTE PLUS.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Ahmad Muhanna</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mike_Borella@3com.com [<A =
HREF=3D"mailto:Mike_Borella@3com.com">mailto:Mike_Borella@3com.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 19, 2001 3:47 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>I don't think that one can conclude that there is a =
security problem unless</FONT>
<BR><FONT SIZE=3D2>it is documented.&nbsp; A quick search of the web =
finds plenty of general concerns</FONT>
<BR><FONT SIZE=3D2>with</FONT>
<BR><FONT SIZE=3D2>MD5 but nothing about this particular issue.&nbsp; =
Does copying a byte in an n byte</FONT>
<BR><FONT SIZE=3D2>hash make it any less secure than the other =
interpretation which is an n-1</FONT>
<BR><FONT SIZE=3D2>byte hash?</FONT>
</P>

<P><FONT SIZE=3D2>It is very clear that a literal reading of RFC3012 =
indicates that the byte</FONT>
<BR><FONT SIZE=3D2>should</FONT>
<BR><FONT SIZE=3D2>be copied.&nbsp; There are commercial deployments =
that already do it this way.</FONT>
</P>

<P><FONT SIZE=3D2>-Mike</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Robert J Marks&quot; =
&lt;rjmarks@cambianetworks.com&gt; on 10/18/2001 04:27:49 PM</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp; &quot;Robert J Marks&quot; =
&lt;rjmarks@cambianetworks.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; mobile-ip@sunroof.eng.sun.com, =
charliep@iprg.nokia.com,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; (Mike =
Borella/MW/US/3Com)</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Although I am not sure of the intention in the RFC, I =
agree that the</FONT>
<BR><FONT SIZE=3D2>byte should not be duplicated in 2 places. I also =
seem to remember that</FONT>
<BR><FONT SIZE=3D2>known duplication tends to weaken the =
security.</FONT>
</P>

<P><FONT SIZE=3D2>Bob</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: owner-mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:owner-mobile-ip@sunroof.eng.sun.com">mailto:owner-mobile-=
ip@sunroof.eng.sun.com</A>] On Behalf Of Nish Abrol</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, October 18, 2001 12:14 AM</FONT>
<BR><FONT SIZE=3D2>To: charliep@iprg.nokia.com; =
pcalhoun@diameter.org;</FONT>
<BR><FONT SIZE=3D2>mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] URGENT - rfc3012 interpretation =
question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Pat/Charlie,</FONT>
</P>

<P><FONT SIZE=3D2>Really appreciate any insights into this really =
important interop issue</FONT>
<BR><FONT SIZE=3D2>for cdma2000:</FONT>
</P>

<P><FONT SIZE=3D2>A question regarding the&nbsp; interpretation of =
section 8 of rfc3012. This</FONT>
<BR><FONT SIZE=3D2>section specifies how to calculate the MN-AAA =
authenticator. It says:</FONT>
</P>

<P><FONT SIZE=3D2>&quot; To compute the authenticator, apply MD5 [11] =
computed on the</FONT>
<BR><FONT SIZE=3D2>following data, in the order shown:</FONT>
</P>

<P><FONT SIZE=3D2>High-order byte from Challenge || Key ||</FONT>
<BR><FONT SIZE=3D2>MD5(Preceding Mobile IP data ||</FONT>
<BR><FONT SIZE=3D2>Type, Subtype (if present), Length, SPI) ||</FONT>
<BR><FONT SIZE=3D2>Least-order 237 bytes from Challenge &quot;</FONT>
</P>

<P><FONT SIZE=3D2>The question is - if the challenge has less than 237 =
bytes - should the</FONT>
<BR><FONT SIZE=3D2>high order byte which was already used in the MD5 =
calculation&nbsp; be</FONT>
<BR><FONT SIZE=3D2>included again as part of the&nbsp; =
&quot;least-order 237 bytes from Challenge&quot;?</FONT>
</P>

<P><FONT SIZE=3D2>e.g. if the challenge is 50 bytes in length - should =
the authenticator</FONT>
<BR><FONT SIZE=3D2>be calculated&nbsp; as:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator =3D =
md5(byte0 || key.......|| byte1 through byte49)</FONT>
</P>

<P><FONT SIZE=3D2>or (b) authenticator =3D md5(byte0 || key ......|| =
byte0 through byte49).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the =
most significant byte of the challenge.</FONT>
</P>

<P><FONT SIZE=3D2>A strict reading of the RFC seems to suggest (b). =
However, it seems</FONT>
<BR><FONT SIZE=3D2>that calculating the MD5 authenticator with the same =
information(high</FONT>
<BR><FONT SIZE=3D2>order byte) at different locations of the payload =
weakens the</FONT>
<BR><FONT SIZE=3D2>authenticator.</FONT>
</P>

<P><FONT SIZE=3D2>So, what was the intention of the RFC and how should =
it be implemented?</FONT>
<BR><FONT SIZE=3D2>Also, do you know if RFC3012 implementations have =
participated in any</FONT>
<BR><FONT SIZE=3D2>bakeoffs/interops. If so, how have they interpreted =
this section?</FONT>
</P>

<P><FONT SIZE=3D2>Your help will be really appreciated.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Nish Abrol</FONT>
<BR><FONT SIZE=3D2>Qualcomm, Inc.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C158E3.E12AE5F0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:28:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02247
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:27:59 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01207;
	Fri, 19 Oct 2001 14:27:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25559;
	Fri, 19 Oct 2001 14:27:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLPpOI029306
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:25:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLPpt6029305
	for mobile-ip-dist; Fri, 19 Oct 2001 14:25:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLPkOI029295
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:25:46 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24738
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:25:49 -0700 (PDT)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21814
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:25:49 -0700 (PDT)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9JLN1123004
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:23:01 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9JLPnS00799
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:25:49 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256AEA.0075B475 ; Fri, 19 Oct 2001 14:25:39 -0700
X-Lotus-FromDomain: 3COM
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <88256AEA.0075B2AB.00@hqoutbound.ops.3com.com>
Date: Fri, 19 Oct 2001 16:26:18 -0500
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=kfj9Vy5oBLqRyeTqyAN0CWJI5FqhWyyYkQaYCz9fmCxCfgldyoREu4FT"
Content-Disposition: inline
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--0__=kfj9Vy5oBLqRyeTqyAN0CWJI5FqhWyyYkQaYCz9fmCxCfgldyoREu4FT
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Please provide a reference to exactly how security is reduced by having
the extra byte.  Until such a refernce or argument is made, the security issue
is null and void.

Mike





"Ahmad Muhanna" <amuhanna@nortelnetworks.com> on 10/19/2001 04:20:30 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Ahmad Muhanna" <amuhanna@nortelnetworks.com>


To:   "'mobile-ip @sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question




I have never heard of any implementation which generates a Challenge value
of 238 bytes or more.
I believe that the whole idea of mentioning the number of least-order bytes
of Challenge (237) in section 8 of RFC3012 is very simply to avoid having
the PDSN sending more than 253 bytes in the CHAP-CHALLENGE attribute to
RADIUS during MN-AAA authentication.
In reality, no one is producing a CHALLENGE value that Huge.

On the other hand, whatever amount of extra security introduced by avoiding
having two exact bytes of the Challenge at two different location is an
ABSOLUTE PLUS.


Ahmad Muhanna

-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 3:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general
concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.









--0__=kfj9Vy5oBLqRyeTqyAN0CWJI5FqhWyyYkQaYCz9fmCxCfgldyoREu4FT
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC44OSI+DQo8VElUTEU+UkU6IFtt
b2JpbGUtaXBdIFVSR0VOVCAtIHJmYzMwMTIgaW50ZXJwcmV0YXRpb24gcXVlc3Rpb248L1RJVExF
Pg0KPC9IRUFEPg0KPEJPRFk+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5JIGhhdmUgbmV2ZXIg
aGVhcmQgb2YgYW55IGltcGxlbWVudGF0aW9uIHdoaWNoIGdlbmVyYXRlcyBhIENoYWxsZW5nZSB2
YWx1ZSBvZiAyMzggYnl0ZXMgb3IgbW9yZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkkgYmVs
aWV2ZSB0aGF0IHRoZSB3aG9sZSBpZGVhIG9mIG1lbnRpb25pbmcgdGhlIG51bWJlciBvZiBsZWFz
dC1vcmRlciBieXRlcyBvZiBDaGFsbGVuZ2UgKDIzNykgaW4gc2VjdGlvbiA4IG9mIFJGQzMwMTIg
aXMgdmVyeSBzaW1wbHkgdG8gYXZvaWQgaGF2aW5nIHRoZSBQRFNOIHNlbmRpbmcgbW9yZSB0aGFu
IDI1MyBieXRlcyBpbiB0aGUgQ0hBUC1DSEFMTEVOR0UgYXR0cmlidXRlIHRvIFJBRElVUyBkdXJp
bmcgTU4tQUFBIGF1dGhlbnRpY2F0aW9uLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5J
biByZWFsaXR5LCBubyBvbmUgaXMgcHJvZHVjaW5nIGEgQ0hBTExFTkdFIHZhbHVlIHRoYXQgSHVn
ZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5PbiB0aGUgb3RoZXIgaGFuZCwgd2hh
dGV2ZXIgYW1vdW50IG9mIGV4dHJhIHNlY3VyaXR5IGludHJvZHVjZWQgYnkgYXZvaWRpbmcgaGF2
aW5nIHR3byBleGFjdCBieXRlcyBvZiB0aGUgQ2hhbGxlbmdlIGF0IHR3byBkaWZmZXJlbnQgbG9j
YXRpb24gaXMgYW4gQUJTT0xVVEUgUExVUy48L0ZPTlQ+PC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBT
SVpFPTI+QWhtYWQgTXVoYW5uYTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBNaWtl
X0JvcmVsbGFAM2NvbS5jb20gWzxBIEhSRUY9Im1haWx0bzpNaWtlX0JvcmVsbGFAM2NvbS5jb20i
Pm1haWx0bzpNaWtlX0JvcmVsbGFAM2NvbS5jb208L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+U2VudDogRnJpZGF5LCBPY3RvYmVyIDE5LCAyMDAxIDM6NDcgUE08L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPlRvOiBtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+U3ViamVjdDogUkU6IFttb2JpbGUtaXBdIFVSR0VOVCAtIHJmYzMwMTIgaW50
ZXJwcmV0YXRpb24gcXVlc3Rpb248L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQo8QlI+DQoNCjxQ
PjxGT05UIFNJWkU9Mj5JIGRvbid0IHRoaW5rIHRoYXQgb25lIGNhbiBjb25jbHVkZSB0aGF0IHRo
ZXJlIGlzIGEgc2VjdXJpdHkgcHJvYmxlbSB1bmxlc3M8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
Pml0IGlzIGRvY3VtZW50ZWQuJm5ic3A7IEEgcXVpY2sgc2VhcmNoIG9mIHRoZSB3ZWIgZmluZHMg
cGxlbnR5IG9mIGdlbmVyYWwgY29uY2VybnM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPndpdGg8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk1ENSBidXQgbm90aGluZyBhYm91dCB0aGlzIHBhcnRp
Y3VsYXIgaXNzdWUuJm5ic3A7IERvZXMgY29weWluZyBhIGJ5dGUgaW4gYW4gbiBieXRlPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj5oYXNoIG1ha2UgaXQgYW55IGxlc3Mgc2VjdXJlIHRoYW4gdGhl
IG90aGVyIGludGVycHJldGF0aW9uIHdoaWNoIGlzIGFuIG4tMTwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+Ynl0ZSBoYXNoPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkl0IGlzIHZl
cnkgY2xlYXIgdGhhdCBhIGxpdGVyYWwgcmVhZGluZyBvZiBSRkMzMDEyIGluZGljYXRlcyB0aGF0
IHRoZSBieXRlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5zaG91bGQ8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPmJlIGNvcGllZC4mbmJzcDsgVGhlcmUgYXJlIGNvbW1lcmNpYWwgZGVwbG95bWVu
dHMgdGhhdCBhbHJlYWR5IGRvIGl0IHRoaXMgd2F5LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg
U0laRT0yPi1NaWtlPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48
Rk9OVCBTSVpFPTI+JnF1b3Q7Um9iZXJ0IEogTWFya3MmcXVvdDsgJmx0O3JqbWFya3NAY2FtYmlh
bmV0d29ya3MuY29tJmd0OyBvbiAxMC8xOC8yMDAxIDA0OjI3OjQ5IFBNPC9GT05UPg0KPC9QPg0K
DQo8UD48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gbW9iaWxlLWlwQHN1bnJvb2YuZW5n
LnN1bi5jb208L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiZuYnNwOyAm
cXVvdDtSb2JlcnQgSiBNYXJrcyZxdW90OyAmbHQ7cmptYXJrc0BjYW1iaWFuZXR3b3Jrcy5jb20m
Z3Q7PC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTI+VG86Jm5ic3A7Jm5ic3A7
IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tLCBjaGFybGllcEBpcHJnLm5va2lhLmNvbSw8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBw
Y2FsaG91bkBkaWFtZXRlci5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNjOiZuYnNwOyZu
YnNwOyZuYnNwOyAoTWlrZSBCb3JlbGxhL01XL1VTLzNDb20pPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj5TdWJqZWN0OiZuYnNwOyBSRTogW21vYmlsZS1pcF0gVVJHRU5UIC0gcmZjMzAxMiBpbnRl
cnByZXRhdGlvbiBxdWVzdGlvbjwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQg
U0laRT0yPkFsdGhvdWdoIEkgYW0gbm90IHN1cmUgb2YgdGhlIGludGVudGlvbiBpbiB0aGUgUkZD
LCBJIGFncmVlIHRoYXQgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5ieXRlIHNob3VsZCBu
b3QgYmUgZHVwbGljYXRlZCBpbiAyIHBsYWNlcy4gSSBhbHNvIHNlZW0gdG8gcmVtZW1iZXIgdGhh
dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+a25vd24gZHVwbGljYXRpb24gdGVuZHMgdG8gd2Vh
a2VuIHRoZSBzZWN1cml0eS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Cb2I8L0ZP
TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJvbTogb3duZXItbW9iaWxlLWlwQHN1bnJvb2YuZW5n
LnN1bi5jb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPls8QSBIUkVGPSJtYWlsdG86b3duZXIt
bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20iPm1haWx0bzpvd25lci1tb2JpbGUtaXBAc3Vu
cm9vZi5lbmcuc3VuLmNvbTwvQT5dIE9uIEJlaGFsZiBPZiBOaXNoIEFicm9sPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj5TZW50OiBUaHVyc2RheSwgT2N0b2JlciAxOCwgMjAwMSAxMjoxNCBBTTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+VG86IGNoYXJsaWVwQGlwcmcubm9raWEuY29tOyBwY2Fs
aG91bkBkaWFtZXRlci5vcmc7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5tb2JpbGUtaXBAc3Vu
cm9vZi5lbmcuc3VuLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U3ViamVjdDogW21vYmls
ZS1pcF0gVVJHRU5UIC0gcmZjMzAxMiBpbnRlcnByZXRhdGlvbiBxdWVzdGlvbjwvRk9OVD4NCjwv
UD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yPlBhdC9DaGFybGllLDwvRk9OVD4NCjwvUD4NCg0K
PFA+PEZPTlQgU0laRT0yPlJlYWxseSBhcHByZWNpYXRlIGFueSBpbnNpZ2h0cyBpbnRvIHRoaXMg
cmVhbGx5IGltcG9ydGFudCBpbnRlcm9wIGlzc3VlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5m
b3IgY2RtYTIwMDA6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QSBxdWVzdGlvbiBy
ZWdhcmRpbmcgdGhlJm5ic3A7IGludGVycHJldGF0aW9uIG9mIHNlY3Rpb24gOCBvZiByZmMzMDEy
LiBUaGlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5zZWN0aW9uIHNwZWNpZmllcyBob3cgdG8g
Y2FsY3VsYXRlIHRoZSBNTi1BQUEgYXV0aGVudGljYXRvci4gSXQgc2F5czo8L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIFNJWkU9Mj4mcXVvdDsgVG8gY29tcHV0ZSB0aGUgYXV0aGVudGljYXRvciwg
YXBwbHkgTUQ1IFsxMV0gY29tcHV0ZWQgb24gdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5m
b2xsb3dpbmcgZGF0YSwgaW4gdGhlIG9yZGVyIHNob3duOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP
TlQgU0laRT0yPkhpZ2gtb3JkZXIgYnl0ZSBmcm9tIENoYWxsZW5nZSB8fCBLZXkgfHw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPk1ENShQcmVjZWRpbmcgTW9iaWxlIElQIGRhdGEgfHw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPlR5cGUsIFN1YnR5cGUgKGlmIHByZXNlbnQpLCBMZW5ndGgsIFNQ
SSkgfHw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkxlYXN0LW9yZGVyIDIzNyBieXRlcyBmcm9t
IENoYWxsZW5nZSAmcXVvdDs8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGUgcXVl
c3Rpb24gaXMgLSBpZiB0aGUgY2hhbGxlbmdlIGhhcyBsZXNzIHRoYW4gMjM3IGJ5dGVzIC0gc2hv
dWxkIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+aGlnaCBvcmRlciBieXRlIHdoaWNoIHdh
cyBhbHJlYWR5IHVzZWQgaW4gdGhlIE1ENSBjYWxjdWxhdGlvbiZuYnNwOyBiZTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTI+aW5jbHVkZWQgYWdhaW4gYXMgcGFydCBvZiB0aGUmbmJzcDsgJnF1b3Q7
bGVhc3Qtb3JkZXIgMjM3IGJ5dGVzIGZyb20gQ2hhbGxlbmdlJnF1b3Q7PzwvRk9OVD4NCjwvUD4N
Cg0KPFA+PEZPTlQgU0laRT0yPmUuZy4gaWYgdGhlIGNoYWxsZW5nZSBpcyA1MCBieXRlcyBpbiBs
ZW5ndGggLSBzaG91bGQgdGhlIGF1dGhlbnRpY2F0b3I8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PmJlIGNhbGN1bGF0ZWQmbmJzcDsgYXM6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsm
bmJzcDsmbmJzcDsgKGEpJm5ic3A7IGF1dGhlbmljYXRvciA9IG1kNShieXRlMCB8fCBrZXkuLi4u
Li4ufHwgYnl0ZTEgdGhyb3VnaCBieXRlNDkpPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF
PTI+b3IgKGIpIGF1dGhlbnRpY2F0b3IgPSBtZDUoYnl0ZTAgfHwga2V5IC4uLi4uLnx8IGJ5dGUw
IHRocm91Z2ggYnl0ZTQ5KS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hlcmUgYnl0ZTAgaXMgdGhlIG1vc3Qgc2lnbmlmaWNh
bnQgYnl0ZSBvZiB0aGUgY2hhbGxlbmdlLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y
PkEgc3RyaWN0IHJlYWRpbmcgb2YgdGhlIFJGQyBzZWVtcyB0byBzdWdnZXN0IChiKS4gSG93ZXZl
ciwgaXQgc2VlbXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRoYXQgY2FsY3VsYXRpbmcgdGhl
IE1ENSBhdXRoZW50aWNhdG9yIHdpdGggdGhlIHNhbWUgaW5mb3JtYXRpb24oaGlnaDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+b3JkZXIgYnl0ZSkgYXQgZGlmZmVyZW50IGxvY2F0aW9ucyBvZiB0
aGUgcGF5bG9hZCB3ZWFrZW5zIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YXV0aGVudGlj
YXRvci48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Tbywgd2hhdCB3YXMgdGhlIGlu
dGVudGlvbiBvZiB0aGUgUkZDIGFuZCBob3cgc2hvdWxkIGl0IGJlIGltcGxlbWVudGVkPzwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+QWxzbywgZG8geW91IGtub3cgaWYgUkZDMzAxMiBpbXBsZW1l
bnRhdGlvbnMgaGF2ZSBwYXJ0aWNpcGF0ZWQgaW4gYW55PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj5iYWtlb2Zmcy9pbnRlcm9wcy4gSWYgc28sIGhvdyBoYXZlIHRoZXkgaW50ZXJwcmV0ZWQgdGhp
cyBzZWN0aW9uPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPllvdXIgaGVscCB3aWxs
IGJlIHJlYWxseSBhcHByZWNpYXRlZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5U
aGFua3M8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPk5pc2ggQWJyb2w8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPlF1YWxjb21tLCBJbmMuPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0K
PEJSPg0KPEJSPg0KPEJSPg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo=

--0__=kfj9Vy5oBLqRyeTqyAN0CWJI5FqhWyyYkQaYCz9fmCxCfgldyoREu4FT--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:31:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02319
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:31:10 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06355;
	Fri, 19 Oct 2001 15:30:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27236;
	Fri, 19 Oct 2001 14:31:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLU7OI029536
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:30:07 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLU7cI029535
	for mobile-ip-dist; Fri, 19 Oct 2001 14:30:07 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLU2OI029528
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:30:03 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12252
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:30:01 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05482
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:29:35 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA01109;
	Fri, 19 Oct 2001 14:29:51 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JLTo412413;
	Fri, 19 Oct 2001 14:29:50 -0700
X-mProtect:  Fri, 19 Oct 2001 14:29:50 -0700 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141130.americas.nokia.com (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdMmjIwf; Fri, 19 Oct 2001 14:29:48 PDT
Message-ID: <3BD09B41.722754AD@iprg.nokia.com>
Date: Fri, 19 Oct 2001 14:29:38 -0700
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'ext Michael Thomas'" <mat@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
		<15312.32543.923529.72106@thomasm-u1.cisco.com>
		<3BD0883E.3AC7252@iprg.nokia.com>
		<15312.38121.546181.679532@thomasm-u1.cisco.com>
		<3BD09695.8E145AE4@iprg.nokia.com> <15312.38896.76146.978934@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael Thomas wrote:

> Cedric Westphal writes:
>  >
>  > Michael Thomas wrote:
>  >
>  > > Cedric Westphal writes:
>  > >  > Modularity means flexibility. So any modularity principle would
>  > >  > dictate -dictate is probably a bad choice of word: we would have
>  > >  > a 'flexible dictator'- if anything, that separate functions COULD be divided
>  > >  > into two packets, or COULD be integrated in one. That's modularity for you.
>  > >  >
>  > >  > Point is: do not call upon modularity to dismiss a perfectly good idea that
>  > >  > precisely adds modularity to the network.
>  > >
>  > >    Does putting SMTP datagrams into HTTP datagrams
>  > >    increase network modularity?
>  > >
>  > >                     Mike
>  >
>  > Don't you think this is beside the point?
>
>    It's exactly the point.

My point was a point of English language. You write:
'Modularity dictates': it's an oxymoron. You write:
'...dictates that it should....'; here's another one. Don't get me wrong,
oxymorons are nice, but when you write poetry. And you draw some
rather firm conclusions based on a sentence that's quite shaky.
Now you can shift the debate and advocate SMTP into HTTP, be
my guest.

Cedric.

>
>
>         Mike



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:36:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02407
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:36:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04998;
	Fri, 19 Oct 2001 14:36:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28281;
	Fri, 19 Oct 2001 14:36:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLZAOI029665
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:35:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLZA1m029664
	for mobile-ip-dist; Fri, 19 Oct 2001 14:35:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLZ6OI029657
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:35:06 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28050
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:35:03 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09129
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:34:38 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA01470
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:35:02 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JLYwv22742
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:34:58 -0700
X-mProtect:  Fri, 19 Oct 2001 14:34:58 -0700 Nokia Silicon Valley Messaging Protection
Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdser8kY; Fri, 19 Oct 2001 14:34:56 PDT
Message-ID: <3BD09C80.E6B6651D@Kniveton.com>
Date: Fri, 19 Oct 2001 14:34:56 -0700
From: "T.J. Kniveton" <TJ@Kniveton.com>
Organization: NOKIA Research
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
		<15312.32543.923529.72106@thomasm-u1.cisco.com>
		<3BD0883E.3AC7252@iprg.nokia.com>
		<15312.38121.546181.679532@thomasm-u1.cisco.com>
		<3BD09695.8E145AE4@iprg.nokia.com> <15312.38896.76146.978934@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Cedric Westphal writes:
>  >
>  > Michael Thomas wrote:
>  >
>  > > Cedric Westphal writes:
>  > >  > Point is: do not call upon modularity to dismiss a perfectly good idea that
>  > >  > precisely adds modularity to the network.
>  > >
>  > >    Does putting SMTP datagrams into HTTP datagrams
>  > >    increase network modularity?
>  > >
>  > >                     Mike
>  >
>  > Don't you think this is beside the point?
> 
>    It's exactly the point.
> 
>         Mike

Then why don't you go post your point in a group that cares about SMTP
and HTTP datagrams?

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:49:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02575
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:49:19 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18788;
	Fri, 19 Oct 2001 15:48:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27472;
	Fri, 19 Oct 2001 14:48:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLlMOI029894
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:47:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLlMHD029893
	for mobile-ip-dist; Fri, 19 Oct 2001 14:47:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLlIOI029883
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:47:18 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00389
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:47:19 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02412
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:47:19 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA02545
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:47:19 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JLlIY14732
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:47:18 -0700
X-mProtect:  Fri, 19 Oct 2001 14:47:18 -0700 Nokia Silicon Valley Messaging Protection
Received: from jmalinen.iprg.nokia.com (205.226.2.98)
	by darkstar.iprg.nokia.com(P1.5 smtpdfYGaQN; Fri, 19 Oct 2001 14:47:16 PDT
Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA16540 for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:47:16 -0700 (PDT)
Message-ID: <3BD09F64.593C5DC7@iprg.nokia.com>
Date: Fri, 19 Oct 2001 14:47:16 -0700
From: "Jari T. Malinen" <jmalinen@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
		<15312.29031.946504.371470@thomasm-u1.cisco.com>
		<3BD078B9.2DD35233@iprg.nokia.com>
		<15312.32845.275169.722977@thomasm-u1.cisco.com>
		<3BD091E3.1D3E2C21@iprg.nokia.com> <15312.38845.863907.180480@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

>  > >    I specifically asked for an example on a shared media,
>  > >    with better than best effort QoS, and in particular
>  > >    suitable for real time traffic. The quoted note was
>  > >    an abbreviated form of that question.
>  >
>  > So you are saying best effort shared links should be disregarded?
> 
>    Where did I imply that? I'd like to see an example
>    for a situation that I think we can all agree would
>    benefit if it were achievable. Thus far, nobody's
>    come up with a link layer/techology where it actually
>    would be useful in that situation.

HC or not, removing piggybacking increases the number of separate
packets sent. If this is a non-issue for all links, narrowband
wireless included, I guess I just must trust you on this :)

>         Mike

-Jari


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:52:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02618
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:52:10 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20980;
	Fri, 19 Oct 2001 15:51:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28484;
	Fri, 19 Oct 2001 14:51:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLp4OI000006
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:51:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLp4rU000005
	for mobile-ip-dist; Fri, 19 Oct 2001 14:51:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLp1OI029994
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:51:01 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01246
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:51:02 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20275
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:50:37 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9JLmqa18788
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:48:53 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM15653;
	Fri, 19 Oct 2001 14:50:20 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09225; Fri, 19 Oct 2001 14:50:42 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.41010.516328.253947@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 14:50:42 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD09C80.E6B6651D@Kniveton.com>
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
	<15312.32543.923529.72106@thomasm-u1.cisco.com>
	<3BD0883E.3AC7252@iprg.nokia.com>
	<15312.38121.546181.679532@thomasm-u1.cisco.com>
	<3BD09695.8E145AE4@iprg.nokia.com>
	<15312.38896.76146.978934@thomasm-u1.cisco.com>
	<3BD09C80.E6B6651D@Kniveton.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

T.J. Kniveton writes:
 > Michael Thomas wrote:
 > > 
 > > Cedric Westphal writes:
 > >  >
 > >  > Michael Thomas wrote:
 > >  >
 > >  > > Cedric Westphal writes:
 > >  > >  > Point is: do not call upon modularity to dismiss a perfectly good idea that
 > >  > >  > precisely adds modularity to the network.
 > >  > >
 > >  > >    Does putting SMTP datagrams into HTTP datagrams
 > >  > >    increase network modularity?
 > >  > >
 > >  > >                     Mike
 > >  >
 > >  > Don't you think this is beside the point?
 > > 
 > >    It's exactly the point.
 > > 
 > >         Mike
 > 
 > Then why don't you go post your point in a group that cares about SMTP
 > and HTTP datagrams?

   Maybe you and your coworkers should take a deep
   breath and look up what modularity means rather
   than making ad hominem attacks, and claiming
   false oxymorons on my part.

   Modularity is a generally good thing, but it
   has its limits. Piggybacking is expressly making
   a tradeoff against modularity. The only issue is
   whether that tradeoff is a reasonable one. That
   case has yet to be made.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 17:54:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02652
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 17:54:11 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22028;
	Fri, 19 Oct 2001 15:53:05 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28930;
	Fri, 19 Oct 2001 14:53:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLqLOI000044
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:52:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JLqLdE000042
	for mobile-ip-dist; Fri, 19 Oct 2001 14:52:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JLqGOI000035
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:52:17 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28577
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:52:11 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22473
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 16:21:50 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9JLqNY05237
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 14:52:23 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM15697;
	Fri, 19 Oct 2001 14:51:46 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09228; Fri, 19 Oct 2001 14:52:10 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.41098.125106.273400@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 14:52:10 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD09F64.593C5DC7@iprg.nokia.com>
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
	<15312.29031.946504.371470@thomasm-u1.cisco.com>
	<3BD078B9.2DD35233@iprg.nokia.com>
	<15312.32845.275169.722977@thomasm-u1.cisco.com>
	<3BD091E3.1D3E2C21@iprg.nokia.com>
	<15312.38845.863907.180480@thomasm-u1.cisco.com>
	<3BD09F64.593C5DC7@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari T. Malinen writes:
 > Michael Thomas wrote:
 > >    Where did I imply that? I'd like to see an example
 > >    for a situation that I think we can all agree would
 > >    benefit if it were achievable. Thus far, nobody's
 > >    come up with a link layer/techology where it actually
 > >    would be useful in that situation.
 > 
 > HC or not, removing piggybacking increases the number of separate
 > packets sent.

   Not necessarily. Use of L2 blocking -- as with
   DOCSIS concatenation -- allows two IP datagrams
   to be sent in one MAC frame.

	 Mike


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 18:07:52 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02817
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 18:07:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16561;
	Fri, 19 Oct 2001 15:07:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02311;
	Fri, 19 Oct 2001 15:06:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JM5xOI000314
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:05:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JM5xuY000313
	for mobile-ip-dist; Fri, 19 Oct 2001 15:05:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JM5tOI000303
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:05:56 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04141
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:05:57 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11009
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:05:56 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA04204
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:05:56 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JM5tC15845
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:05:55 -0700
X-mProtect:  Fri, 19 Oct 2001 15:05:55 -0700 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141130.americas.nokia.com (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd8caDV1; Fri, 19 Oct 2001 15:05:53 PDT
Message-ID: <3BD0A3B1.9F612BFA@iprg.nokia.com>
Date: Fri, 19 Oct 2001 15:05:38 -0700
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
		<15312.32543.923529.72106@thomasm-u1.cisco.com>
		<3BD0883E.3AC7252@iprg.nokia.com>
		<15312.38121.546181.679532@thomasm-u1.cisco.com>
		<3BD09695.8E145AE4@iprg.nokia.com>
		<15312.38896.76146.978934@thomasm-u1.cisco.com>
		<3BD09C80.E6B6651D@Kniveton.com> <15312.41010.516328.253947@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Mike,

Michael Thomas wrote:

> T.J. Kniveton writes:
>  > Michael Thomas wrote:
>  > >
>  > > Cedric Westphal writes:
>  > >  >
>  > >  > Michael Thomas wrote:
>  > >  >
>  > >  > > Cedric Westphal writes:
>  > >  > >  > Point is: do not call upon modularity to dismiss a perfectly good idea that
>  > >  > >  > precisely adds modularity to the network.
>  > >  > >
>  > >  > >    Does putting SMTP datagrams into HTTP datagrams
>  > >  > >    increase network modularity?
>  > >  > >
>  > >  > >                     Mike
>  > >  >
>  > >  > Don't you think this is beside the point?
>  > >
>  > >    It's exactly the point.
>  > >
>  > >         Mike
>  >
>  > Then why don't you go post your point in a group that cares about SMTP
>  > and HTTP datagrams?
>
>    Maybe you and your coworkers should take a deep
>    breath and look up what modularity means rather
>    than making ad hominem attacks, and claiming
>    false oxymorons on my part.

please do not disrespect me as an individual and bundle me in your
reply as a somebody's coworker. I did not make any ad hominem statement.
(however, it seems to me that: 'ad hominem attack' is a pleonasm).
Modularity means, 'constructed with standardized units or dimensions for flexibility and
variety in use'. I do not read: do not piggyback, but, quite on the contrary:
think flexible. By the way, telling me I don't know what modularity means,
when I am involved in this exchange, sounds ad hominem to me. I raise my
flag too.
Piggyback would not be modular if you could not switched it off. Turn out, you
can. Thus it is modular, qed.

Cedric.

>
>    Modularity is a generally good thing, but it
>    has its limits. Piggybacking is expressly making
>    a tradeoff against modularity. The only issue is
>    whether that tradeoff is a reasonable one. That
>    case has yet to be made.
>
>         Mike



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 18:13:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02941
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 18:13:56 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06482;
	Fri, 19 Oct 2001 16:13:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04255;
	Fri, 19 Oct 2001 15:13:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMCgOI000439
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JMCgNs000438
	for mobile-ip-dist; Fri, 19 Oct 2001 15:12:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMCcOI000429
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:38 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22089
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:40 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13886
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:40 -0700 (PDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA03894
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 17:12:39 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9JMCcD20971
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 17:12:38 -0500 (CDT)
Message-ID: <3BD0A6D4.746604ED@alcatel.com>
Date: Fri, 19 Oct 2001 17:19:00 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CCC6@zrc2c012.us.nortel.com> <3BD09618.82CA170D@alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Charlie, Mike,Glenn, Hesham, Pekka, Jari, et al.

Let me summarize the discussion on piggbacking BUs.
Unlike mipv4, mipv6 allows BU/Back to be piggybacked with data and with
higher layer traffic using extension headers of IPv6.
This has been all OK until security problem has been discovered in route
optimization which happens to start with a BU sent to a CN.
It seems that the security experts (not me) will be able to secure
BU/Backs more easily if they are not piggybacked (solution 6.2 in Arkko
draft).

  If there are no security problems in mipv6 (solution 6.4 in Arkko
draft) then status quo is good enough. Some people seem to be strongly
on this side.
Count me on this, provided that you can convince the chairs Phil and
Raj.

  Otherwise, we seem to have not much choice but to modify a bit the
draft and make BU/Backs more visible in the packet, just like mipv4 (the
details to be worked out).
I can provide conceptual arguments for this choice: BU/Back are
registration/control messages so they'd better be separated from the
data traffic. If they need to be piggybacked with some higher layer
packets (as in AAA mipv4 extension, and as some people argue for RSVP)
then we need to specify this.
Therefore, count me on this too.

  My 0.02 euros.

--
Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 18:14:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02952
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 18:14:03 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18903;
	Fri, 19 Oct 2001 15:14:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04271;
	Fri, 19 Oct 2001 15:13:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMCkOI000447
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JMCktB000446
	for mobile-ip-dist; Fri, 19 Oct 2001 15:12:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMCfOI000436
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:41 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05897
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:43 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05566
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 16:12:17 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA04937;
	Fri, 19 Oct 2001 15:12:31 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JMCUY24548;
	Fri, 19 Oct 2001 15:12:30 -0700
X-mProtect:  Fri, 19 Oct 2001 15:12:30 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdiOeQIN; Fri, 19 Oct 2001 15:12:28 PDT
Message-ID: <3BD0A54C.843E21A9@iprg.nokia.com>
Date: Fri, 19 Oct 2001 15:12:28 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com> <15312.32543.923529.72106@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

> Koodli Rajeev (NRC/MtView) writes:

> > I am sorry: I don't see the flow of logic here.. BTW, I would have

>  > agreed to the modularity  principle if you stated that one must not
>  > strike out destination option because a particular link, yet
>  > unspecified, does not know how to handle it.
>
>    Modularity would dictate that a packet with two
>    separate functions should be divided into two
>    packets. It's quite obvious that a great deal of
>    the current set of problems with MIPv6 security
>    suffers from the law of unintended consequences
>    directly related to trying to avoid modularity.
>

Basically, you are arguing against IPv6 destination option. 2460 allows a
destination option to be sent as long as the destination option is meant for
the node identified in destination address of the base IPv6 header! So, if
there is a _UDP_ payload and a destination option for _IP_ to process at the
receiver, I see no break in modularity. Beyond this, you should really take
this issue with the authors of 2460, who BTW, could already be aware of this
usage (I assume).



>
>  > >   Also: I've asked Rajeev several times for an
>  > >   example of a L2 on a shared media which delivers
>  > >   different QoS than BE which doesn't suffer from
>  > >   either excessive bandwidth utilization or undue
>  > >   latency/jitter for real time traffic, and thus
>  > >   far he hasn't provided me a pointer. Maybe he
>  > >   just can't talk about it, but if there exists
>  > >   such a beast I'd _love_ to hear about it (seriously).
>  >
>  > This brings back the question of whether destination option must have
>  > been specified in the first place because some weird link does not know
>  > how to support it! What's the logic in saying IP cannot have
>  > variable-sized packets because a link would have performance issues?
>
>    The current BU design is not modular. It claims
>    that it did that because of bandwidth/latency
>    gains. You have not presented a *single* MAC/PHY
>    where that claim can be tested. Here you dodge
>    my direct question yet again.
>

Actually, I mentioned previously that the use of [rohc] over cellular is one
reference for you. See http://www.ludd.luth.se/users/larsman/rocco and follow
the references.
Note: use of [rohc] would require support for variable packet sizes on the
link (perhaps the same kind of link you are considering).

Any link where media access latency and/or channel interleaving is a
significant portion of the total transmission delay would benefit from the
ability to piggyback.


>
>  > > > I read this as a particular response to the suggestion that
>  > > > highly structured MACs couldn't handle the Binding Update.
>  > > > I found his response to be reasonable, which is to say that
>  > > > reasonable engineers could make it work.
>  > >
>  > >   Uh, how? Until details are provided, I remain
>  > >   skeptical.
>  >
>  > Well, please check the recent archives for header compression and
>  > piggybacking interworking.
>
>    I did. You haven't answered my question.
>

You were looking at/for something else I guess. Anyway, the essence of _that_
discussion was piggybacking and header compression would work fine.


>
>  > >   RTS/CTS-style links produce unacceptible latency
>  > >   and jitter for real time traffic, especially at
>  > >   slow link speeds.
>  > >
>  >
>  > So what ? If IP was designed looking into every possible link's
>  > idiosyncrasies, you and I would probably not having this conversation!
>  > hmm..
>
>    I'm only looking for a single link layer which
>    benefits. You haven't provided an example.
>

Again, any link where channel acquisition and interleaving would be onerous.

I am glad that you have turned your attention towards the benefit of
piggybacking!

Regards,

-Rajeev


>
>                  Mike



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 18:14:59 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03026
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 18:14:58 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06804;
	Fri, 19 Oct 2001 16:13:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04370;
	Fri, 19 Oct 2001 15:13:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMCwOI000457
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JMCwSV000456
	for mobile-ip-dist; Fri, 19 Oct 2001 15:12:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMCpOI000449
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:51 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06604
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:53 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05716
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 16:12:28 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA04988
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:52 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JMCpd25328
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:12:51 -0700
X-mProtect:  Fri, 19 Oct 2001 15:12:51 -0700 Nokia Silicon Valley Messaging Protection
Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdf8lp2f; Fri, 19 Oct 2001 15:12:49 PDT
Message-ID: <3BD0A562.C053EAC2@Kniveton.com>
Date: Fri, 19 Oct 2001 15:12:50 -0700
From: "T.J. Kniveton" <TJ@Kniveton.com>
Organization: NOKIA Research
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
		<15312.32543.923529.72106@thomasm-u1.cisco.com>
		<3BD0883E.3AC7252@iprg.nokia.com>
		<15312.38121.546181.679532@thomasm-u1.cisco.com>
		<3BD09695.8E145AE4@iprg.nokia.com>
		<15312.38896.76146.978934@thomasm-u1.cisco.com>
		<3BD09C80.E6B6651D@Kniveton.com> <15312.41010.516328.253947@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> T.J. Kniveton writes:
>  > Michael Thomas wrote:
>  > >
>  > > Cedric Westphal writes:
>  > >  >
>  > >  > Michael Thomas wrote:
>  > >  >
>  > >  > > Cedric Westphal writes:
>  > >  > >  > Point is: do not call upon modularity to dismiss a perfectly good idea that
>  > >  > >  > precisely adds modularity to the network.
>  > >  > >
>  > >  > >    Does putting SMTP datagrams into HTTP datagrams
>  > >  > >    increase network modularity?
>  > >  > >
>  > >  > >                     Mike
>  > >  >
>  > >  > Don't you think this is beside the point?
>  > >
>  > >    It's exactly the point.
>  > >
>  > >         Mike
>  >
>  > Then why don't you go post your point in a group that cares about SMTP
>  > and HTTP datagrams?
> 
>    Maybe you and your coworkers should take a deep
>    breath and look up what modularity means rather
>    than making ad hominem attacks, and claiming
>    false oxymorons on my part.

I simply suggested that you take your point which, according to you, was
"exactly," whether "putting SMTP datagrams into HTTP datagrams increases
network modularity" somewhere people care about SMTP and HTTP datagrams.
If, instead, it was supposed to be a simile or illustrate the point you
and Cedric were previously discussing, then my comment wouldn't
apply..nor would yours. 

I'll assume that you are joking when you tell me to look up "modularity"
in the same breath as accusing me of attacking your character (that's
what "ad hominem" means). Believe me, I *do* take a deep breath every
time my inbox fills up with messages like this.

> 
>    Modularity is a generally good thing, but it
>    has its limits. Piggybacking is expressly making
>    a tradeoff against modularity. The only issue is
>    whether that tradeoff is a reasonable one. That
>    case has yet to be made.
> 
>         Mike

The case probably hasn't been made because no one buys your premise..but
yourself.

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 18:24:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03250
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 18:24:06 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13823;
	Fri, 19 Oct 2001 16:23:40 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07442;
	Fri, 19 Oct 2001 15:23:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMMoOI000782
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:22:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JMMo7b000781
	for mobile-ip-dist; Fri, 19 Oct 2001 15:22:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMMkOI000774
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:22:46 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07095
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:22:41 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12957
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 16:22:23 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA05883
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:22:47 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9JMMls08236
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:22:47 -0700
X-mProtect:  Fri, 19 Oct 2001 15:22:47 -0700 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141130.americas.nokia.com (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdbGIjZd; Fri, 19 Oct 2001 15:22:44 PDT
Message-ID: <3BD0A79D.B47A8645@iprg.nokia.com>
Date: Fri, 19 Oct 2001 15:22:21 -0700
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E75CA91@zrc2c012.us.nortel.com>
		<15312.29031.946504.371470@thomasm-u1.cisco.com>
		<3BD078B9.2DD35233@iprg.nokia.com>
		<15312.32845.275169.722977@thomasm-u1.cisco.com>
		<3BD091E3.1D3E2C21@iprg.nokia.com>
		<15312.38845.863907.180480@thomasm-u1.cisco.com>
		<3BD09F64.593C5DC7@iprg.nokia.com> <15312.41098.125106.273400@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael Thomas wrote:

> Jari T. Malinen writes:
>  > Michael Thomas wrote:
>  > >    Where did I imply that? I'd like to see an example
>  > >    for a situation that I think we can all agree would
>  > >    benefit if it were achievable. Thus far, nobody's
>  > >    come up with a link layer/techology where it actually
>  > >    would be useful in that situation.
>  >
>  > HC or not, removing piggybacking increases the number of separate
>  > packets sent.
>
>    Not necessarily. Use of L2 blocking -- as with
>    DOCSIS concatenation -- allows two IP datagrams
>    to be sent in one MAC frame.

See, you agree that concatenation, such as piggybacking, is a good
thing.
Welcome home,

Cedric.

>
>
>          Mike



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 19 18:30:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03470
	for <mobileip-archive@odin.ietf.org>; Fri, 19 Oct 2001 18:30:45 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17561;
	Fri, 19 Oct 2001 16:29:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08713;
	Fri, 19 Oct 2001 15:29:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMSvOI000902
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:28:58 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JMSvDC000901
	for mobile-ip-dist; Fri, 19 Oct 2001 15:28:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JMSsOI000894
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:28:54 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08491
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:28:49 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01684
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:28:55 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9JMT8m00448
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 19 Oct 2001 15:29:08 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAM16733;
	Fri, 19 Oct 2001 15:28:24 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA09238; Fri, 19 Oct 2001 15:28:48 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15312.43295.935713.869314@thomasm-u1.cisco.com>
Date: Fri, 19 Oct 2001 15:28:47 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD0A562.C053EAC2@Kniveton.com>
References: <A6D9D7495456414BA08DB655C2AC671207813E@bsebe001.NOE.Nokia.com>
	<15312.32543.923529.72106@thomasm-u1.cisco.com>
	<3BD0883E.3AC7252@iprg.nokia.com>
	<15312.38121.546181.679532@thomasm-u1.cisco.com>
	<3BD09695.8E145AE4@iprg.nokia.com>
	<15312.38896.76146.978934@thomasm-u1.cisco.com>
	<3BD09C80.E6B6651D@Kniveton.com>
	<15312.41010.516328.253947@thomasm-u1.cisco.com>
	<3BD0A562.C053EAC2@Kniveton.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

T.J. Kniveton writes:
 > Michael Thomas wrote:
 > I'll assume that you are joking when you tell me to look up "modularity"

   No, I wasn't. This point is hardly
   controversial even though it seems to have
   struck a nerve.

 > >    Modularity is a generally good thing, but it
 > >    has its limits. Piggybacking is expressly making
 > >    a tradeoff against modularity. The only issue is
 > >    whether that tradeoff is a reasonable one. That
 > >    case has yet to be made.
 > 
 > The case probably hasn't been made because no one buys your premise..but
 > yourself.

   I think you should speak for yourself. I'm not
   the only one around here who has serious reservations
   about whether piggybacking is worth the trouble. In
   dismissing my concerns as irrelevant or off-topic, 
   you are also dismissing a lot of people who are
   probably just tired of this merry-go-round.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 21 11:49:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14611
	for <mobileip-archive@odin.ietf.org>; Sun, 21 Oct 2001 11:49:37 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19562;
	Sun, 21 Oct 2001 08:49:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29044;
	Sun, 21 Oct 2001 08:49:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9LFmROI004176
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 21 Oct 2001 08:48:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9LFmQ8F004175
	for mobile-ip-dist; Sun, 21 Oct 2001 08:48:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9LFmMOI004168
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 08:48:22 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18728
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 08:48:24 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05335
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 09:47:58 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA04038
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 10:48:23 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Sun, 21 Oct 2001 10:41:47 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L674M>; Sun, 21 Oct 2001 10:47:56 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E7B4FE3@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Sun, 21 Oct 2001 10:48:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15A47.C52F8C10"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15A47.C52F8C10
Content-Type: text/plain;
	charset="iso-8859-1"

Behcet,
 
I have read the draft; however, there are some issues with that solution as
well (the AAA battle) - not that I am apposed to someone implementing and
deploying it in the situations where they could. For now, I think it is best
to focus on the cleaner slate and then retrofit, dealing with BW
compatibility.
 
Thanks for your input and please continue.
 
Glenn

-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, October 19, 2001 4:08 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion


Hi again Glenn, 
  I am going to reply to your two consecutive mails, just on RSVP and
layering: 
1. RSVP. Firstly mipv6 allows sending BUs separately (as I said in my email
yesterday, mipv4 mandates, i.e. not only allows but requires, this already
for registration requests), i.e. not piggybacked, so how are going to
achieve what you wish to have as a required behaviour? 
This answer is you need to standardize. An example such thing is in
AAA-mipv4 application defined in draft-ietf-aaa-diameter-mobileip-07.txt
(nicely defined by Pat and Charlie!) 
2. You said in your mail: 
Modularity is achieved the same way that modularity is acheived in a 
packet containing IP, TCP and HTTP. 

This is because HTTP is an application layer protocol, it uses TCP as the
transport layer, i.e. L4 which in turn uses IP as the network layer, i.e.
L3. 
A bit of lesson on OSI layering, please. 


Kind regards, 


Glenn Morrow wrote: 


  

Mike, 


I'm sorry no one ever responded to this before. Here is an example I hope
meets your criteria:

-- 
Behcet 


------_=_NextPart_001_01C15A47.C52F8C10
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=725504015-21102001>Behcet,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=725504015-21102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=725504015-21102001>I have 
read the draft; however, there&nbsp;are some issues with that solution as well 
(the AAA battle) - not that I am apposed to someone implementing and deploying 
it in the situations where they could. For now, I think it is best to focus on 
the cleaner slate and then retrofit, dealing with BW 
compatibility.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=725504015-21102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=725504015-21102001>Thanks 
for your input and please continue.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=725504015-21102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=725504015-21102001>Glenn</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Behcet Sarikaya 
  [mailto:behcet.sarikaya@alcatel.com]<BR><B>Sent:</B> Friday, October 19, 2001 
  4:08 PM<BR><B>To:</B> mobile-ip@sunroof.eng.sun.com<BR><B>Subject:</B> Re: 
  [mobile-ip] MIPv6 - Focus of the security discussion<BR><BR></DIV></FONT>Hi 
  again Glenn, <BR>&nbsp; I am going to reply to your two consecutive mails, 
  just on RSVP and layering: <BR>1. RSVP. Firstly mipv6 allows sending BUs 
  separately (as I said in my email yesterday, mipv4 mandates, i.e. not only 
  allows but requires, this already for registration requests), i.e. not 
  piggybacked, so how are going to achieve what you wish to have as a required 
  behaviour? <BR>This answer is you need to standardize. An example such thing 
  is in AAA-mipv4 application defined in draft-ietf-aaa-diameter-mobileip-07.txt 
  (nicely defined by Pat and Charlie!) <BR>2. You said in your mail: 
  <BR>Modularity is achieved the same way that modularity is acheived in a 
  <BR>packet containing IP, TCP and HTTP. 
  <P>This is because HTTP is an application layer protocol, it uses TCP as the 
  transport layer, i.e. L4 which in turn uses IP as the network layer, i.e. L3. 
  <BR>A bit of lesson on OSI layering, please. 
  <P>Kind regards, 
  <P>Glenn Morrow wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp; 
    <P><FONT size=-1>Mike,</FONT> 
    <P><FONT size=-1>I'm sorry no one ever responded to this before. Here is an 
    example I hope meets your criteria:</FONT></P></BLOCKQUOTE>-- <BR>Behcet 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15A47.C52F8C10--


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 21 23:06:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21803
	for <mobileip-archive@lists.ietf.org>; Sun, 21 Oct 2001 23:06:11 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13192;
	Sun, 21 Oct 2001 21:05:42 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28230;
	Sun, 21 Oct 2001 20:05:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M34iOI005438
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 21 Oct 2001 20:04:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M34inM005437
	for mobile-ip-dist; Sun, 21 Oct 2001 20:04:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M34eOI005430
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 20:04:41 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07641
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 20:04:43 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12718
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 21:04:17 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id WAA02174
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 22:04:41 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Sun, 21 Oct 2001 22:02:59 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L69C5>; Sun, 21 Oct 2001 22:04:08 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF4DF@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Sun, 21 Oct 2001 22:04:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15AA6.3BD30280"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15AA6.3BD30280
Content-Type: text/plain;
	charset="iso-8859-1"


I hope that this discussion is for the purpose of ensuring a secure and
robust Mobile IP protocol rather than defending certain implementation.

Having said that, I would like to confess that, at the moment, I can not
provide a reference for the reduced security or the introduced weakness,
because of using the High-Order byte of the Challenge at two fixed different
locations of the payload in calculating the MN-AAA authenticator.

However, as most of us know, MD5 is not very strong in calculating digital
signature. In other words the MD5 collision resistance is not impossibly
immune as per the following references.

RFC1321 says in conclusion:
"The MD5 message-digest algorithm is simple to implement, and provides a
"fingerprint" or message digest of a message of arbitrary length. It is
conjectured that the difficulty of coming up with two messages having the
same message digest is on the order of 2^64 operations, and that the
difficulty of coming up with any message having a given message digest is on
the order of 2^128 operations. The MD5 algorithm has been carefully
scrutinized for weaknesses. ...."

Please, let us remember this RFC was written on April 1992, at the age of 35
MHZ PC's.

ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf (1996)

"... customers should note that while the continued suitability of MD5 for
applications requiring collision-resistance is in question, the use of MD5
in other roles, for example as part of a mechanism for random number
generation, is still considered safe. ..."

http://www.math.fu-berlin.de/~guckes/md5/

".... In 1996, MD5 was all but broken by a German cryptographer, Hans
Dobbertin. Although MD5 was not completely broken at that time, it was
discovered to have such serious weaknesses that no one should keep using it
to generate signatures..."

It may need a special investigation to find out the weakness introduced by
the literal implementation of section 8 in RFC3012. However, we know for
fact that the other interpretation does not introduce any new form of
weakness or patterns.

Therefore, taking all of this and the fact that the (Least-order 237 bytes
from Challenge) mentioned in section 8 of RFC 3012 was there to make sure
that no more than 253 bytes can be sent by PDSN/FA to RADIUS in a RADIUS
attribute, I strongly believe that any wise implementation should not
intentionally aid the Crypto analytical attacker and make his/her job a
little easier by introducing a pattern in the hashed payload.

Regards;

Ahmad Muhanna



-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 4:26 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




Please provide a reference to exactly how security is reduced by having
the extra byte.  Until such a refernce or argument is made, the security
issue
is null and void.

Mike





"Ahmad Muhanna" <amuhanna@nortelnetworks.com> on 10/19/2001 04:20:30 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Ahmad Muhanna" <amuhanna@nortelnetworks.com>


To:   "'mobile-ip @sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question




I have never heard of any implementation which generates a Challenge value
of 238 bytes or more.
I believe that the whole idea of mentioning the number of least-order bytes
of Challenge (237) in section 8 of RFC3012 is very simply to avoid having
the PDSN sending more than 253 bytes in the CHAP-CHALLENGE attribute to
RADIUS during MN-AAA authentication.
In reality, no one is producing a CHALLENGE value that Huge.

On the other hand, whatever amount of extra security introduced by avoiding
having two exact bytes of the Challenge at two different location is an
ABSOLUTE PLUS.


Ahmad Muhanna

-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 3:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general
concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.







 << File: Internet HTML >> 

------_=_NextPart_001_01C15AA6.3BD30280
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I hope that this discussion is for the =
purpose of ensuring a secure and robust Mobile IP protocol rather than =
defending certain implementation.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Having said that, I would like to =
confess that, at the moment, I can not provide a reference for the =
reduced security or the introduced weakness, because of using the =
High-Order byte of the Challenge at two fixed different locations of =
the payload in calculating the MN-AAA authenticator.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">However, as most of us know, MD5 is =
not very strong in calculating digital signature. In other words the =
MD5 collision resistance is not impossibly immune as per the following =
references.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">RFC1321 says in conclusion:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">"The MD5 message-digest algorithm is =
simple to implement, and provides a &quot;fingerprint&quot; or message =
digest of a message of arbitrary length. It is conjectured that the =
difficulty of coming up with two messages having the same message =
digest is on the order of 2^64 operations, and that the difficulty of =
coming up with any message having a given message digest is on the =
order of 2^128 operations. The MD5 algorithm has been carefully =
scrutinized for weaknesses. ...."</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Please, let us remember this RFC =
was written on April 1992, at the age of 35 MHZ PC's.</FONT></B>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf" =
TARGET=3D"_blank">ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf</A> =
(1996)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">"... customers should note that while =
the continued suitability of MD5 for applications requiring =
collision-resistance is in question, the use of MD5 in other roles, for =
example as part of a mechanism for random number generation, is still =
considered safe. ..."</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.math.fu-berlin.de/~guckes/md5/" =
TARGET=3D"_blank">http://www.math.fu-berlin.de/~guckes/md5/</A></FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;.... In 1996, MD5 was all but =
broken by a German cryptographer, Hans Dobbertin. Although MD5 was not =
completely broken at that time, it was discovered to have such serious =
weaknesses that no one should keep using it to generate =
signatures...&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It may need a special investigation to =
find out the weakness introduced by the literal implementation of =
section 8 in RFC3012. However, we know for fact that the other =
interpretation does not introduce any new form of weakness or =
patterns.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Therefore, taking all of this and the =
fact that the (Least-order 237 bytes from Challenge) mentioned in =
section 8 of RFC 3012 was there to make sure that no more than 253 =
bytes can be sent by PDSN/FA to RADIUS in a RADIUS attribute, I =
strongly believe that any wise implementation should not intentionally =
aid the Crypto analytical attacker and make his/her job a little easier =
by introducing a pattern in the hashed payload.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Mike_Borella@3com.com [<A =
HREF=3D"mailto:Mike_Borella@3com.com">mailto:Mike_Borella@3com.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Friday, October 19, 2001 4:26 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: RE: [mobile-ip] URGENT - =
rfc3012 interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please provide a reference to exactly =
how security is reduced by having</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the extra byte.&nbsp; Until such a =
refernce or argument is made, the security issue</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is null and void.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Mike</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;Ahmad Muhanna&quot; =
&lt;amuhanna@nortelnetworks.com&gt; on 10/19/2001 04:20:30 PM</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sent by:&nbsp; &quot;Ahmad =
Muhanna&quot; &lt;amuhanna@nortelnetworks.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">To:&nbsp;&nbsp; &quot;'mobile-ip =
@sunroof.eng.sun.com'&quot; =
&lt;mobile-ip@sunroof.eng.sun.com&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cc:&nbsp;&nbsp;&nbsp; (Mike =
Borella/MW/US/3Com)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject:&nbsp; RE: [mobile-ip] URGENT =
- rfc3012 interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have never heard of any =
implementation which generates a Challenge value</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of 238 bytes or more.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I believe that the whole idea of =
mentioning the number of least-order bytes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of Challenge (237) in section 8 of =
RFC3012 is very simply to avoid having</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the PDSN sending more than 253 bytes =
in the CHAP-CHALLENGE attribute to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RADIUS during MN-AAA =
authentication.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">In reality, no one is producing a =
CHALLENGE value that Huge.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On the other hand, whatever amount of =
extra security introduced by avoiding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">having two exact bytes of the =
Challenge at two different location is an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ABSOLUTE PLUS.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Mike_Borella@3com.com [<A =
HREF=3D"mailto:Mike_Borella@3com.com">mailto:Mike_Borella@3com.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Friday, October 19, 2001 3:47 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: RE: [mobile-ip] URGENT - =
rfc3012 interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't think that one can conclude =
that there is a security problem unless</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it is documented.&nbsp; A quick =
search of the web finds plenty of general</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">concerns</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MD5 but nothing about this particular =
issue.&nbsp; Does copying a byte in an n</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">byte</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">hash make it any less secure than the =
other interpretation which is an n-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">byte hash?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is very clear that a literal =
reading of RFC3012 indicates that the byte</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be copied.&nbsp; There are commercial =
deployments that already do it this way.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Mike</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;Robert J Marks&quot; =
&lt;rjmarks@cambianetworks.com&gt; on 10/18/2001 04:27:49 PM</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sent by:&nbsp; &quot;Robert J =
Marks&quot; &lt;rjmarks@cambianetworks.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">To:&nbsp;&nbsp; =
mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cc:&nbsp;&nbsp;&nbsp; (Mike =
Borella/MW/US/3Com)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject:&nbsp; RE: [mobile-ip] URGENT =
- rfc3012 interpretation question</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Although I am not sure of the =
intention in the RFC, I agree that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">byte should not be duplicated in 2 =
places. I also seem to remember that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">known duplication tends to weaken the =
security.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Bob</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: =
owner-mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[<A =
HREF=3D"mailto:owner-mobile-ip@sunroof.eng.sun.com">mailto:owner-mobile-=
ip@sunroof.eng.sun.com</A>] On Behalf Of Nish Abrol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Thursday, October 18, 2001 =
12:14 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: charliep@iprg.nokia.com; =
pcalhoun@diameter.org;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Pat/Charlie,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Really appreciate any insights into =
this really important interop issue</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for cdma2000:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A question regarding the&nbsp; =
interpretation of section 8 of rfc3012. This</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">section specifies how to calculate =
the MN-AAA authenticator. It says:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot; To compute the authenticator, =
apply MD5 [11] computed on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">following data, in the order =
shown:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">High-order byte from Challenge || Key =
||</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MD5(Preceding Mobile IP data =
||</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Type, Subtype (if present), Length, =
SPI) ||</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Least-order 237 bytes from Challenge =
&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The question is - if the challenge has =
less than 237 bytes - should the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">high order byte which was already =
used in the MD5 calculation&nbsp; be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">included again as part of the&nbsp; =
&quot;least-order 237 bytes from Challenge&quot;?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">e.g. if the challenge is 50 bytes in =
length - should the authenticator</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be calculated&nbsp; as:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; (a)&nbsp; =
authenicator =3D md5(byte0 || key.......|| byte1 through byte49)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">or (b) authenticator =3D md5(byte0 || =
key ......|| byte0 through byte49).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where =
byte0 is the most significant byte of the challenge.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A strict reading of the RFC seems to =
suggest (b). However, it seems</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that calculating the MD5 =
authenticator with the same information(high</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">order byte) at different locations of =
the payload weakens the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">authenticator.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, what was the intention of the RFC =
and how should it be implemented?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Also, do you know if RFC3012 =
implementations have participated in any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">bakeoffs/interops. If so, how have =
they interpreted this section?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Your help will be really =
appreciated.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nish Abrol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Qualcomm, Inc.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&lt;&lt; File: Internet HTML =
&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15AA6.3BD30280--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 01:32:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24575
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 01:32:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA05250;
	Sun, 21 Oct 2001 22:32:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07713;
	Sun, 21 Oct 2001 22:32:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M5VIOI005668
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 21 Oct 2001 22:31:18 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M5VIbp005667
	for mobile-ip-dist; Sun, 21 Oct 2001 22:31:18 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M5VEOI005660
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 22:31:14 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22537
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 22:31:07 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18103
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 22:31:15 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA25534;
	Mon, 22 Oct 2001 15:29:57 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA01473;
	Mon, 22 Oct 2001 15:31:06 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VGPN2WJF>; Mon, 22 Oct 2001 15:31:04 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho"
	 <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Mon, 22 Oct 2001 15:30:57 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15ABA.BA534200"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15ABA.BA534200
Content-Type: text/plain


	Hello Rajeev and all, 

> > Koodli Rajeev (NRC/MtView) writes:
> 
> >  > This brings back the question of whether destination option must have
> >  > been specified in the first place because some weird link does not
> know
> >  > how to support it! What's the logic in saying IP cannot have
> >  > variable-sized packets because a link would have performance issues?
> >
> >    The current BU design is not modular. It claims
> >    that it did that because of bandwidth/latency
> >    gains. You have not presented a *single* MAC/PHY
> >    where that claim can be tested. Here you dodge
> >    my direct question yet again.
> >
> 
> Actually, I mentioned previously that the use of [rohc] over cellular is
> one
> reference for you. See http://www.ludd.luth.se/users/larsman/rocco and
> follow
> the references.
> Note: use of [rohc] would require support for variable packet sizes on the
> link (perhaps the same kind of link you are considering).
> 
	=> I'm not sure why the discussion has gone towards header
	compression, but anyway, the point I was raising was that 
	piggybacking can have negative effects on the MN/CN if they
	are attached to a tight channel. Obviously the channel is tight
	because it''s expensive so there is a very limited potential
	of reserving a "just in case" extra BW for piggybacking. 

	Now, I'm not saying ROHC can't handle it, all I was saying is 
	that this "larger" packet will likely take double the time 
	to be sent over the air since it may not fit into one radio
	frame. If it does, then the end to end delay will be significantly
	increased (the air link delays are -by far- the largest part
	of the e2e delay in a cellular environment) and it may be dropped. 
	ROHC is not reallt relevant here.

	So the result of the scenario above is a degradation in service. 
	Now we can argue for a long time about whether these links
	are "IP friendly" and whether we should design IP for 
	these interfaces, but the fact is this is what we have _today_. 

	Also BTW these systems are the ones deploying IPv6 first !
	So we just have to deal with the real case here and try to
	solve it. 

	Unfortunately, we can not assume that the problem can be solved
	at one end only. So what can we do ?

	1.  Keep piggybacking and just say to the designers of these
	     systems "tough luck". ? Doesn't look good for MIPv6.

		Pro: - The draft doesn't change
		con: - Adds another reason for not deploying MIPv6 in
cellular
	               systems. 
	             - The IPsec problem still stands

	2.  Remove piggybacking ?
	       
	    pros: - End of this thread (can't wait :))
	            - End of the IPsec problems. IPsec can be used
	            - MIPv6 becomes more "cellular friendly"

	     Con: whatever advantages people see for piggybacking 
	             (in Jari's draft) will disappear. 

	3.  Have some negotiation mechanism in MIPv6 between 
	     the MN/CN. I'm not sure how this would work yet
	     but I could imagine having something in the Home Address
	     option or the BU option to indicate whether piggybacking 
	     should be used or not. 
	     If we use the Home address option, we would need to 
	     account for the fact that it will not necessarily be secure. 
	     Meaning, it can be modified en route. 
	     
	     If we use the BU, we will still get some service degradation
	     for the first BU. 
	     Regardless of the chosen method for this option, this 
	     new "flag" or "indication" MUST be supported by all 
	     MNs and CNs to avoid any service degradation due to 
	     piggybacking. 

	I'd be more inclined to 2 or 3 .... Comments ?

	Hesham


------_=_NextPart_001_01C15ABA.BA534200
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hello Rajeev and =
all, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Koodli Rajeev (NRC/MtView) =
writes:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; &gt; This brings back the =
question of whether destination option must have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; &gt; been specified in the =
first place because some weird link does not know</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; &gt; how to support it! =
What's the logic in saying IP cannot have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; &gt; variable-sized =
packets because a link would have performance issues?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; The current BU =
design is not modular. It claims</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; that it did =
that because of bandwidth/latency</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; gains. You =
have not presented a *single* MAC/PHY</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; where that =
claim can be tested. Here you dodge</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp; my direct =
question yet again.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Actually, I mentioned previously that =
the use of [rohc] over cellular is one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">reference for you. See</FONT><U> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ludd.luth.se/users/larsman/rocco" =
TARGET=3D"_blank">http://www.ludd.luth.se/users/larsman/rocco</A></FONT>=
</U><FONT SIZE=3D2 FACE=3D"Arial"> and follow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the references.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Note: use of [rohc] would require =
support for variable packet sizes on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">link (perhaps the same kind of link =
you are considering).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; I'm not sure =
why the discussion has gone towards header</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">compression, but =
anyway, the point I was raising was that </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">piggybacking can =
have negative effects on the MN/CN if they</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">are attached to a =
tight channel. Obviously the channel is tight</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">because it''s =
expensive so there is a very limited potential</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">of reserving a =
&quot;just in case&quot; extra BW for piggybacking. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Now, I'm not saying =
ROHC can't handle it, all I was saying is </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">that this =
&quot;larger&quot; packet will likely take double the time </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">to be sent over the =
air since it may not fit into one radio</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">frame. If it does, =
then the end to end delay will be significantly</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">increased (the air =
link delays are -by far- the largest part</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">of the e2e delay in =
a cellular environment) and it may be dropped. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">ROHC is not reallt =
relevant here.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So the result of the =
scenario above is a degradation in service. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Now we can argue =
for a long time about whether these links</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">are &quot;IP =
friendly&quot; and whether we should design IP for </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">these interfaces, =
but the fact is this is what we have _today_. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Also BTW these =
systems are the ones deploying IPv6 first !</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So we just have to =
deal with the real case here and try to</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">solve it. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Unfortunately, we =
can not assume that the problem can be solved</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">at one end only. So =
what can we do ?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">1.&nbsp; Keep =
piggybacking and just say to the designers of these</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; systems &quot;tough luck&quot;. =
? Doesn't look good for MIPv6.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">Pro: - The draft doesn't change</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">con: - Adds another reason for not deploying =
MIPv6 in cellular</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; systems. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; - The IPsec problem still stands</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">2.&nbsp; Remove =
piggybacking ?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
pros: - End of this thread (can't wait :))</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; - End of the IPsec problems. IPsec can be used</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; - MIPv6 becomes more &quot;cellular friendly&quot;</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Con: whatever advantages people =
see for piggybacking </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; (in Jari's draft) will disappear. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">3.&nbsp; Have some =
negotiation mechanism in MIPv6 between </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; the MN/CN. I'm not sure how =
this would work yet</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; but I could imagine having =
something in the Home Address</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; option or the BU option to =
indicate whether piggybacking </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; should be used or not. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; If we use the Home address =
option, we would need to </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; account for the fact that it =
will not necessarily be secure. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Meaning, it can be modified en =
route. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; If we use the BU, we will still =
get some service degradation</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; for the first BU. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Regardless of the chosen method =
for this option, this </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; new &quot;flag&quot; or =
&quot;indication&quot; MUST be supported by all </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; MNs and CNs to avoid any =
service degradation due to </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; piggybacking. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I'd be more inclined =
to 2 or 3 .... Comments ?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15ABA.BA534200--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 02:17:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05242
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 02:17:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA14600;
	Sun, 21 Oct 2001 23:17:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13692;
	Sun, 21 Oct 2001 23:16:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M6FKOI005898
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 21 Oct 2001 23:15:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M6FKht005897
	for mobile-ip-dist; Sun, 21 Oct 2001 23:15:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M6FGOI005890
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 23:15:16 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26753
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 23:15:10 -0700 (PDT)
Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20006
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 21 Oct 2001 23:15:18 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f9M6FG121565
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:15:16 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id IAA00499
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:15:16 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f9M6FFD91131
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:15:15 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200110220615.f9M6FFD91131@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion 
In-reply-to: (arbitrary reference for MUA thread detection)
      Your message of Mon, 22 Oct 2001 15:30:57 +1000.
      <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se> 
Date: Mon, 22 Oct 2001 08:15:15 +0200
X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Here are my comment about the H.3 section of the first draft,
I resend them to the list taking advantage of some minutes in my office:
 - 6.8: Scenario H.3: the quote is not the best one (this quote is
   an implementation hint, the definition should be better but I agree
   there is no formal definition of the home address option in a general
   context. Someone should ask for it...)
 - same: same: "on nodes whose home addresses may be known": remove home,
   the attack works as soon as an address of the final target is known.
   This is a real problem and as you know the defense against is not easy.
 - same: Requirement H.3: SHOULD/MAY NOT -> SHOULD NOT/MAY NOT
   (the threat is important enough for careful wording).
 - same: same: I disagree with the requirement because as this is
   an ingress filtering defeat attack there can (should! or we'll be
   in deep trouble) be some defenses based on smart ingress filtering
   (for instance a clever access control can ask MNs to register their
    home addresses before accepting to forward packets with home address
    options on the firewall between the access network and the rest of
    the world). Something needs to be done because the trivial way to
    fix the issue on a firewall is just to drop any packet with HoA options
    and this is *not* what we want.)

Regards

Francis.Dupont@enst-bretagne.fr


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 05:01:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09245
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 05:01:20 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02810;
	Mon, 22 Oct 2001 03:00:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08023;
	Mon, 22 Oct 2001 02:01:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M90AOI006132
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:00:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M90ABB006131
	for mobile-ip-dist; Mon, 22 Oct 2001 02:00:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M905OI006124
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:00:06 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9M903q11772;
	Mon, 22 Oct 2001 11:00:03 +0200 (MET DST)
Date: Mon, 22 Oct 2001 10:54:34 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: kempf42@yahoo.com
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <20011019163909.50762.qmail@web13901.mail.yahoo.com>
Message-ID: <Roam.SIMC.2.0.6.1003740874.29682.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> > > 2) A theaving MN could gain network access without
> > > authorization by soliciting a Router Advert, then
> > > setting up a CoA.
> > 
> > I don't quite understand. Is the MN sending a Router
> > Solicitation or
> > a Router Advertisement?
> > 
> 
> It is sending a Solicitation. If the access router
> is not required to authenticate the Solicitation, then
> an unauthorized MN could gain access.

What do you mean by "access"?
The MN will receive a Router Advertisement packet, but that in itself
doesn't imply access to anything.
The RA just carries parameters to the host.

> > > 3) Similar to 2), a theaving MN could gain network
> > > access without authorization through responding to
> > an
> > > unsolicited Router Advert, then setting up a CoA.
> > 
>  
> 
> In this case, the MN is responding to an unsolicited
> Router Advert by performing address autoconfiguration.
> With stateful address configuration, I would assume
> that DHCP security could be used to determine
> whether the MN is authorized for an address. So
> the issue here is that there needs to be some way to
> perform authentication on address autoconfiguration
> messaging.

Are you concerned that the ability to assign an address implicitly
allows the node to consume network resources?
Or are you concerned about the node being able to prevent others
from using their (perhaps more legimate) addresses?


> I think the threats you've outlined above are clearly
> not MIPv6 related, but, as I mentioned in an earlier
> response, they are made worse by mobility because you
> cannot secure a physical network access point.

The threats are made worse by computers moving around (i.e. the most
fundamental notion of "mobility") but also by the desire
to provide public access network infrastructure, whether in the form
of Ethernet wires in a hotel or some wireless technology.
Such public access networks could be used e.g. for residential
network access i.e. in cases where mobility isn't the key descriminant.

In order to reduce the likely confusion between "mobility" and "mobile IP"
I prefer to attach these types of threats to the "public access network"
term or something similar, since I think that captures the essential
element. 

  Erik

> There are some threats that require authentication on
> the MN/AR exchange (1 and 2 in my original message,
> also something similar to 1 is dicusssed in the
> draft).
> There are others, which you outline above, that
> involve ND and address autoconfig. In addition, there
> is a need to more thoroughly think through security if
> stateful address config is needed.
> 
> A short summary of the threats in an appendix would be
> useful. In addition to IPNG, I think URP will need to
> be involved (presuming it gets chartered). Prior to
> the authentication of any ND or address autoconfig
> messaging, there needs to be some kind of AAA exchange
> in order for the proper initial conditions to be set
> up.
> 
>                  jak
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com




From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 05:24:44 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09417
	for <mobileip-archive@lists.ietf.org>; Mon, 22 Oct 2001 05:24:44 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07017;
	Mon, 22 Oct 2001 02:24:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10361;
	Mon, 22 Oct 2001 02:24:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M9NgOI006304
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:23:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M9Ngrj006303
	for mobile-ip-dist; Mon, 22 Oct 2001 02:23:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M9NcOI006296
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:23:38 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9M9Ncq15257
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 11:23:38 +0200 (MET DST)
Date: Mon, 22 Oct 2001 11:18:09 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
To: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <88256AEA.00722252.00@hqoutbound.ops.3com.com>
Message-ID: <Roam.SIMC.2.0.6.1003742289.31324.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Whatever the best interpretation will be, the fact that this is subject
to interpretation tells me that RFC 3012 needs to be revised ASAP
with a description which is clear on this point.

Are there other issues that aren't (or weren't) clear to implementors
of RFC 3012? Any issues that required sending a question on a mailing
list or to the authors would seem like a good reason to get the
spec clarified.

  Erik


>----- Begin Included Message -----<

Date: Fri, 19 Oct 2001 15:47:24 -0500
From: Mike_Borella@3com.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
To: mobile-ip@sunroof.eng.sun.com



I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.








>----- End Included Message -----<



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 05:34:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09470
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 05:34:16 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21447;
	Mon, 22 Oct 2001 03:33:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11633;
	Mon, 22 Oct 2001 02:34:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M9XROI006419
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:33:27 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M9XRLW006418
	for mobile-ip-dist; Mon, 22 Oct 2001 02:33:27 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M9XNOI006411
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:33:23 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11491
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:33:25 -0700 (PDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26754
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:33:25 -0700 (PDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id CAA02128 for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:24:37 -0700 (MST)]
Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id CAA12817 for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 02:33:24 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 22 Oct 2001 02:33:12 -0700
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id DA77B2ED3D; Mon, 22 Oct 2001 11:28:30 +0200 (CEST)
To: mobile-ip@sunroof.eng.sun.com
Cc: James Kempf <kempf42@yahoo.com>, Michael Thomas <mat@cisco.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
References: <20011019171002.71509.qmail@web13905.mail.yahoo.com>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 22 Oct 2001 11:33:20 +0200
In-Reply-To: <20011019171002.71509.qmail@web13905.mail.yahoo.com>
Message-Id: <m37ktorpcv.fsf@test9.crm.mot.com>
Lines: 14
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Michael Thomas:
> > There is no "DHCP security" that I'm aware of.
> > Maybe that's changed recently, but it's certainly
> > not common.

James Kempf <kempf42@yahoo.com> writes:
> I believe the DHCP group has been working on something
> involving security, at least, I recall seeing a draft
> go by awhile ago. I don't know where it is at.

Maybe the DHCP Threats draft?
draft-prigent-dhcpv6-threats-00.txt

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 09:08:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15096
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 09:08:23 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18306;
	Mon, 22 Oct 2001 06:07:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17749;
	Mon, 22 Oct 2001 06:04:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MD3NOI006703
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:03:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MD3MEb006702
	for mobile-ip-dist; Mon, 22 Oct 2001 06:03:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MD3JOI006692
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:03:19 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17631
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:03:21 -0700 (PDT)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11628
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:47:50 -0600 (MDT)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9MD0V303945
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:00:31 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9MD3KS19465
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:03:20 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256AED.0047B11E ; Mon, 22 Oct 2001 06:03:03 -0700
X-Lotus-FromDomain: 3COM
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <88256AED.0047B0C8.00@hqoutbound.ops.3com.com>
Date: Mon, 22 Oct 2001 08:03:04 -0500
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>


Agreed, however we have to consider legacy code exists and two different
code bases may already be in the field.

We'll be able to provide more feedback once we get beyond this issue.
AFAIK, this is the only RFC3012 problem so far.

Mike





Erik Nordmark <Erik.Nordmark@eng.sun.com> on 10/22/2001 04:18:09 AM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  Erik Nordmark <Erik.Nordmark@eng.sun.com>


To:   mobile-ip@sunroof.eng.sun.com
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Whatever the best interpretation will be, the fact that this is subject
to interpretation tells me that RFC 3012 needs to be revised ASAP
with a description which is clear on this point.

Are there other issues that aren't (or weren't) clear to implementors
of RFC 3012? Any issues that required sending a question on a mailing
list or to the authors would seem like a good reason to get the
spec clarified.

  Erik


>----- Begin Included Message -----<

Date: Fri, 19 Oct 2001 15:47:24 -0500
From: Mike_Borella@3com.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
To: mobile-ip@sunroof.eng.sun.com



I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.








>----- End Included Message -----<







From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 09:09:03 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15228
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 09:09:02 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18409;
	Mon, 22 Oct 2001 06:07:52 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17416;
	Mon, 22 Oct 2001 06:02:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MD1oOI006679
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:01:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MD1onV006678
	for mobile-ip-dist; Mon, 22 Oct 2001 06:01:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MD1lOI006671
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:01:47 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17309
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:01:49 -0700 (PDT)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17104
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:01:23 -0600 (MDT)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9MCwx303867
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 05:58:59 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f9MD1lS18986
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 06:01:47 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256AED.00475913 ; Mon, 22 Oct 2001 05:59:18 -0700
X-Lotus-FromDomain: 3COM
To: mobile-ip@sunroof.eng.sun.com
Message-ID: <88256AED.00474F63.00@hqoutbound.ops.3com.com>
Date: Mon, 22 Oct 2001 07:58:43 -0500
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=vRBLHuRnk9eOyAQBNFhzRdp913H6wpK5iuFGkTvUUF9U8hQmp4XPcEOe"
Content-Disposition: inline
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--0__=vRBLHuRnk9eOyAQBNFhzRdp913H6wpK5iuFGkTvUUF9U8hQmp4XPcEOe
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



And I hope that you are not spreading FUD to protect an implementation.
When you claim that there is a security problem in a protocol or algorithm,
you need to back it up with solid evidence, which no one has done yet.

If there is a genuine security problem with my interpretation, I would like to
know and
will make the appropriate apologies then.

However I do agree that concensus in the crypto community is that using MD5
is risky.  That is another problem.  If MD5 has such issues we should be using
a better hash, such a SHA-1, I suppose.

Mike





"Ahmad Muhanna" <amuhanna@nortelnetworks.com> on 10/21/2001 10:04:15 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Ahmad Muhanna" <amuhanna@nortelnetworks.com>


To:   "'mobile-ip @sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question




I hope that this discussion is for the purpose of ensuring a secure and
robust Mobile IP protocol rather than defending certain implementation.

Having said that, I would like to confess that, at the moment, I can not
provide a reference for the reduced security or the introduced weakness,
because of using the High-Order byte of the Challenge at two fixed different
locations of the payload in calculating the MN-AAA authenticator.

However, as most of us know, MD5 is not very strong in calculating digital
signature. In other words the MD5 collision resistance is not impossibly
immune as per the following references.

RFC1321 says in conclusion:
"The MD5 message-digest algorithm is simple to implement, and provides a
"fingerprint" or message digest of a message of arbitrary length. It is
conjectured that the difficulty of coming up with two messages having the
same message digest is on the order of 2^64 operations, and that the
difficulty of coming up with any message having a given message digest is on
the order of 2^128 operations. The MD5 algorithm has been carefully
scrutinized for weaknesses. ...."

Please, let us remember this RFC was written on April 1992, at the age of 35
MHZ PC's.

ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf (1996)

"... customers should note that while the continued suitability of MD5 for
applications requiring collision-resistance is in question, the use of MD5
in other roles, for example as part of a mechanism for random number
generation, is still considered safe. ..."

http://www.math.fu-berlin.de/~guckes/md5/

".... In 1996, MD5 was all but broken by a German cryptographer, Hans
Dobbertin. Although MD5 was not completely broken at that time, it was
discovered to have such serious weaknesses that no one should keep using it
to generate signatures..."

It may need a special investigation to find out the weakness introduced by
the literal implementation of section 8 in RFC3012. However, we know for
fact that the other interpretation does not introduce any new form of
weakness or patterns.

Therefore, taking all of this and the fact that the (Least-order 237 bytes
from Challenge) mentioned in section 8 of RFC 3012 was there to make sure
that no more than 253 bytes can be sent by PDSN/FA to RADIUS in a RADIUS
attribute, I strongly believe that any wise implementation should not
intentionally aid the Crypto analytical attacker and make his/her job a
little easier by introducing a pattern in the hashed payload.

Regards;

Ahmad Muhanna



-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 4:26 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




Please provide a reference to exactly how security is reduced by having
the extra byte.  Until such a refernce or argument is made, the security
issue
is null and void.

Mike





"Ahmad Muhanna" <amuhanna@nortelnetworks.com> on 10/19/2001 04:20:30 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Ahmad Muhanna" <amuhanna@nortelnetworks.com>


To:   "'mobile-ip @sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question




I have never heard of any implementation which generates a Challenge value
of 238 bytes or more.
I believe that the whole idea of mentioning the number of least-order bytes
of Challenge (237) in section 8 of RFC3012 is very simply to avoid having
the PDSN sending more than 253 bytes in the CHAP-CHALLENGE attribute to
RADIUS during MN-AAA authentication.
In reality, no one is producing a CHALLENGE value that Huge.

On the other hand, whatever amount of extra security introduced by avoiding
having two exact bytes of the Challenge at two different location is an
ABSOLUTE PLUS.


Ahmad Muhanna

-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 3:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general
concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.







 << File: Internet HTML >>


--0__=vRBLHuRnk9eOyAQBNFhzRdp913H6wpK5iuFGkTvUUF9U8hQmp4XPcEOe
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC44OSI+DQo8VElUTEU+UkU6IFtt
b2JpbGUtaXBdIFVSR0VOVCAtIHJmYzMwMTIgaW50ZXJwcmV0YXRpb24gcXVlc3Rpb248L1RJVExF
Pg0KPC9IRUFEPg0KPEJPRFk+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
SSBob3BlIHRoYXQgdGhpcyBkaXNjdXNzaW9uIGlzIGZvciB0aGUgcHVycG9zZSBvZiBlbnN1cmlu
ZyBhIHNlY3VyZSBhbmQgcm9idXN0IE1vYmlsZSBJUCBwcm90b2NvbCByYXRoZXIgdGhhbiBkZWZl
bmRpbmcgY2VydGFpbiBpbXBsZW1lbnRhdGlvbi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPkhhdmluZyBzYWlkIHRoYXQsIEkgd291bGQgbGlrZSB0byBjb25mZXNz
IHRoYXQsIGF0IHRoZSBtb21lbnQsIEkgY2FuIG5vdCBwcm92aWRlIGEgcmVmZXJlbmNlIGZvciB0
aGUgcmVkdWNlZCBzZWN1cml0eSBvciB0aGUgaW50cm9kdWNlZCB3ZWFrbmVzcywgYmVjYXVzZSBv
ZiB1c2luZyB0aGUgSGlnaC1PcmRlciBieXRlIG9mIHRoZSBDaGFsbGVuZ2UgYXQgdHdvIGZpeGVk
IGRpZmZlcmVudCBsb2NhdGlvbnMgb2YgdGhlIHBheWxvYWQgaW4gY2FsY3VsYXRpbmcgdGhlIE1O
LUFBQSBhdXRoZW50aWNhdG9yLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+SG93ZXZlciwgYXMgbW9zdCBvZiB1cyBrbm93LCBNRDUgaXMgbm90IHZlcnkgc3Ryb25n
IGluIGNhbGN1bGF0aW5nIGRpZ2l0YWwgc2lnbmF0dXJlLiBJbiBvdGhlciB3b3JkcyB0aGUgTUQ1
IGNvbGxpc2lvbiByZXNpc3RhbmNlIGlzIG5vdCBpbXBvc3NpYmx5IGltbXVuZSBhcyBwZXIgdGhl
IGZvbGxvd2luZyByZWZlcmVuY2VzLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+UkZDMTMyMSBzYXlzIGluIGNvbmNsdXNpb246PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+IlRoZSBNRDUgbWVzc2FnZS1kaWdlc3QgYWxnb3JpdGhtIGlzIHNp
bXBsZSB0byBpbXBsZW1lbnQsIGFuZCBwcm92aWRlcyBhICZxdW90O2ZpbmdlcnByaW50JnF1b3Q7
IG9yIG1lc3NhZ2UgZGlnZXN0IG9mIGEgbWVzc2FnZSBvZiBhcmJpdHJhcnkgbGVuZ3RoLiBJdCBp
cyBjb25qZWN0dXJlZCB0aGF0IHRoZSBkaWZmaWN1bHR5IG9mIGNvbWluZyB1cCB3aXRoIHR3byBt
ZXNzYWdlcyBoYXZpbmcgdGhlIHNhbWUgbWVzc2FnZSBkaWdlc3QgaXMgb24gdGhlIG9yZGVyIG9m
IDJeNjQgb3BlcmF0aW9ucywgYW5kIHRoYXQgdGhlIGRpZmZpY3VsdHkgb2YgY29taW5nIHVwIHdp
dGggYW55IG1lc3NhZ2UgaGF2aW5nIGEgZ2l2ZW4gbWVzc2FnZSBkaWdlc3QgaXMgb24gdGhlIG9y
ZGVyIG9mIDJeMTI4IG9wZXJhdGlvbnMuIFRoZSBNRDUgYWxnb3JpdGhtIGhhcyBiZWVuIGNhcmVm
dWxseSBzY3J1dGluaXplZCBmb3Igd2Vha25lc3Nlcy4gLi4uLiI8L0ZPTlQ+PC9QPg0KDQo8UD48
Qj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlBsZWFzZSwgbGV0IHVzIHJlbWVtYmVyIHRoaXMg
UkZDIHdhcyB3cml0dGVuIG9uIEFwcmlsIDE5OTIsIGF0IHRoZSBhZ2Ugb2YgMzUgTUhaIFBDJ3Mu
PC9GT05UPjwvQj4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj48QSBIUkVG
PSJmdHA6Ly9mdHAucnNhLmNvbS9wdWIvcGRmcy9idWxsZXRuNC5wZGYiIFRBUkdFVD0iX2JsYW5r
Ij5mdHA6Ly9mdHAucnNhLmNvbS9wdWIvcGRmcy9idWxsZXRuNC5wZGY8L0E+ICgxOTk2KTwvRk9O
VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4iLi4uIGN1c3RvbWVycyBz
aG91bGQgbm90ZSB0aGF0IHdoaWxlIHRoZSBjb250aW51ZWQgc3VpdGFiaWxpdHkgb2YgTUQ1IGZv
ciBhcHBsaWNhdGlvbnMgcmVxdWlyaW5nIGNvbGxpc2lvbi1yZXNpc3RhbmNlIGlzIGluIHF1ZXN0
aW9uLCB0aGUgdXNlIG9mIE1ENSBpbiBvdGhlciByb2xlcywgZm9yIGV4YW1wbGUgYXMgcGFydCBv
ZiBhIG1lY2hhbmlzbSBmb3IgcmFuZG9tIG51bWJlciBnZW5lcmF0aW9uLCBpcyBzdGlsbCBjb25z
aWRlcmVkIHNhZmUuIC4uLiI8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPjxBIEhSRUY9Imh0dHA6Ly93d3cubWF0aC5mdS1iZXJsaW4uZGUvfmd1Y2tlcy9tZDUvIiBU
QVJHRVQ9Il9ibGFuayI+aHR0cDovL3d3dy5tYXRoLmZ1LWJlcmxpbi5kZS9+Z3Vja2VzL21kNS88
L0E+PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZxdW90Oy4u
Li4gSW4gMTk5NiwgTUQ1IHdhcyBhbGwgYnV0IGJyb2tlbiBieSBhIEdlcm1hbiBjcnlwdG9ncmFw
aGVyLCBIYW5zIERvYmJlcnRpbi4gQWx0aG91Z2ggTUQ1IHdhcyBub3QgY29tcGxldGVseSBicm9r
ZW4gYXQgdGhhdCB0aW1lLCBpdCB3YXMgZGlzY292ZXJlZCB0byBoYXZlIHN1Y2ggc2VyaW91cyB3
ZWFrbmVzc2VzIHRoYXQgbm8gb25lIHNob3VsZCBrZWVwIHVzaW5nIGl0IHRvIGdlbmVyYXRlIHNp
Z25hdHVyZXMuLi4mcXVvdDs8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPkl0IG1heSBuZWVkIGEgc3BlY2lhbCBpbnZlc3RpZ2F0aW9uIHRvIGZpbmQgb3V0IHRoZSB3
ZWFrbmVzcyBpbnRyb2R1Y2VkIGJ5IHRoZSBsaXRlcmFsIGltcGxlbWVudGF0aW9uIG9mIHNlY3Rp
b24gOCBpbiBSRkMzMDEyLiBIb3dldmVyLCB3ZSBrbm93IGZvciBmYWN0IHRoYXQgdGhlIG90aGVy
IGludGVycHJldGF0aW9uIGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IGZvcm0gb2Ygd2Vha25l
c3Mgb3IgcGF0dGVybnMuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij5UaGVyZWZvcmUsIHRha2luZyBhbGwgb2YgdGhpcyBhbmQgdGhlIGZhY3QgdGhhdCB0aGUgKExl
YXN0LW9yZGVyIDIzNyBieXRlcyBmcm9tIENoYWxsZW5nZSkgbWVudGlvbmVkIGluIHNlY3Rpb24g
OCBvZiBSRkMgMzAxMiB3YXMgdGhlcmUgdG8gbWFrZSBzdXJlIHRoYXQgbm8gbW9yZSB0aGFuIDI1
MyBieXRlcyBjYW4gYmUgc2VudCBieSBQRFNOL0ZBIHRvIFJBRElVUyBpbiBhIFJBRElVUyBhdHRy
aWJ1dGUsIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IGFueSB3aXNlIGltcGxlbWVudGF0aW9uIHNo
b3VsZCBub3QgaW50ZW50aW9uYWxseSBhaWQgdGhlIENyeXB0byBhbmFseXRpY2FsIGF0dGFja2Vy
IGFuZCBtYWtlIGhpcy9oZXIgam9iIGEgbGl0dGxlIGVhc2llciBieSBpbnRyb2R1Y2luZyBhIHBh
dHRlcm4gaW4gdGhlIGhhc2hlZCBwYXlsb2FkLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+UmVnYXJkczs8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+QWhtYWQgTXVoYW5uYTwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZyb206IE1pa2VfQm9yZWxsYUAzY29t
LmNvbSBbPEEgSFJFRj0ibWFpbHRvOk1pa2VfQm9yZWxsYUAzY29tLmNvbSI+bWFpbHRvOk1pa2Vf
Qm9yZWxsYUAzY29tLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+U2VudDogRnJpZGF5LCBPY3RvYmVyIDE5LCAyMDAxIDQ6MjYgUE08L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzogbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb208
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TdWJqZWN0OiBSRTogW21vYmls
ZS1pcF0gVVJHRU5UIC0gcmZjMzAxMiBpbnRlcnByZXRhdGlvbiBxdWVzdGlvbjwvRk9OVD4NCjwv
UD4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5QbGVh
c2UgcHJvdmlkZSBhIHJlZmVyZW5jZSB0byBleGFjdGx5IGhvdyBzZWN1cml0eSBpcyByZWR1Y2Vk
IGJ5IGhhdmluZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnRoZSBleHRy
YSBieXRlLiZuYnNwOyBVbnRpbCBzdWNoIGEgcmVmZXJuY2Ugb3IgYXJndW1lbnQgaXMgbWFkZSwg
dGhlIHNlY3VyaXR5IGlzc3VlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
aXMgbnVsbCBhbmQgdm9pZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+TWlrZTwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mcXVvdDtBaG1hZCBNdWhhbm5hJnF1b3Q7ICZsdDthbXVo
YW5uYUBub3J0ZWxuZXR3b3Jrcy5jb20mZ3Q7IG9uIDEwLzE5LzIwMDEgMDQ6MjA6MzAgUE08L0ZP
TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UGxlYXNlIHJlc3BvbmQg
dG8gbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb208L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+U2VudCBieTombmJzcDsgJnF1b3Q7QWhtYWQgTXVoYW5uYSZx
dW90OyAmbHQ7YW11aGFubmFAbm9ydGVsbmV0d29ya3MuY29tJmd0OzwvRk9OVD4NCjwvUD4NCjxC
Uj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzombmJzcDsmbmJzcDsgJnF1b3Q7
J21vYmlsZS1pcCBAc3Vucm9vZi5lbmcuc3VuLmNvbScmcXVvdDsgJmx0O21vYmlsZS1pcEBzdW5y
b29mLmVuZy5zdW4uY29tJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PmNjOiZuYnNwOyZuYnNwOyZuYnNwOyAoTWlrZSBCb3JlbGxhL01XL1VTLzNDb20pPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U3ViamVjdDombmJzcDsgUkU6IFttb2JpbGUt
aXBdIFVSR0VOVCAtIHJmYzMwMTIgaW50ZXJwcmV0YXRpb24gcXVlc3Rpb248L0ZPTlQ+DQo8L1A+
DQo8QlI+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SSBoYXZl
IG5ldmVyIGhlYXJkIG9mIGFueSBpbXBsZW1lbnRhdGlvbiB3aGljaCBnZW5lcmF0ZXMgYSBDaGFs
bGVuZ2UgdmFsdWU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vZiAyMzgg
Ynl0ZXMgb3IgbW9yZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIGJl
bGlldmUgdGhhdCB0aGUgd2hvbGUgaWRlYSBvZiBtZW50aW9uaW5nIHRoZSBudW1iZXIgb2YgbGVh
c3Qtb3JkZXIgYnl0ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vZiBD
aGFsbGVuZ2UgKDIzNykgaW4gc2VjdGlvbiA4IG9mIFJGQzMwMTIgaXMgdmVyeSBzaW1wbHkgdG8g
YXZvaWQgaGF2aW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGhlIFBE
U04gc2VuZGluZyBtb3JlIHRoYW4gMjUzIGJ5dGVzIGluIHRoZSBDSEFQLUNIQUxMRU5HRSBhdHRy
aWJ1dGUgdG88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5SQURJVVMgZHVy
aW5nIE1OLUFBQSBhdXRoZW50aWNhdGlvbi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5JbiByZWFsaXR5LCBubyBvbmUgaXMgcHJvZHVjaW5nIGEgQ0hBTExFTkdFIHZhbHVl
IHRoYXQgSHVnZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
T24gdGhlIG90aGVyIGhhbmQsIHdoYXRldmVyIGFtb3VudCBvZiBleHRyYSBzZWN1cml0eSBpbnRy
b2R1Y2VkIGJ5IGF2b2lkaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
aGF2aW5nIHR3byBleGFjdCBieXRlcyBvZiB0aGUgQ2hhbGxlbmdlIGF0IHR3byBkaWZmZXJlbnQg
bG9jYXRpb24gaXMgYW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5BQlNP
TFVURSBQTFVTLjwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5BaG1hZCBNdWhhbm5hPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+RnJvbTogTWlrZV9Cb3JlbGxhQDNjb20uY29tIFs8QSBIUkVGPSJtYWls
dG86TWlrZV9Cb3JlbGxhQDNjb20uY29tIj5tYWlsdG86TWlrZV9Cb3JlbGxhQDNjb20uY29tPC9B
Pl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TZW50OiBGcmlkYXksIE9j
dG9iZXIgMTksIDIwMDEgMzo0NyBQTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPlRvOiBtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPlN1YmplY3Q6IFJFOiBbbW9iaWxlLWlwXSBVUkdFTlQgLSByZmMz
MDEyIGludGVycHJldGF0aW9uIHF1ZXN0aW9uPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJS
Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkkgZG9uJ3QgdGhpbmsgdGhhdCBvbmUg
Y2FuIGNvbmNsdWRlIHRoYXQgdGhlcmUgaXMgYSBzZWN1cml0eSBwcm9ibGVtIHVubGVzczwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPml0IGlzIGRvY3VtZW50ZWQuJm5ic3A7
IEEgcXVpY2sgc2VhcmNoIG9mIHRoZSB3ZWIgZmluZHMgcGxlbnR5IG9mIGdlbmVyYWw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jb25jZXJuczwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPndpdGg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5NRDUgYnV0IG5vdGhpbmcgYWJvdXQgdGhpcyBwYXJ0aWN1bGFyIGlzc3VlLiZuYnNw
OyBEb2VzIGNvcHlpbmcgYSBieXRlIGluIGFuIG48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj5ieXRlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aGFz
aCBtYWtlIGl0IGFueSBsZXNzIHNlY3VyZSB0aGFuIHRoZSBvdGhlciBpbnRlcnByZXRhdGlvbiB3
aGljaCBpcyBhbiBuLTE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5ieXRl
IGhhc2g/PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkl0IGlz
IHZlcnkgY2xlYXIgdGhhdCBhIGxpdGVyYWwgcmVhZGluZyBvZiBSRkMzMDEyIGluZGljYXRlcyB0
aGF0IHRoZSBieXRlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+c2hvdWxk
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YmUgY29waWVkLiZuYnNwOyBU
aGVyZSBhcmUgY29tbWVyY2lhbCBkZXBsb3ltZW50cyB0aGF0IGFscmVhZHkgZG8gaXQgdGhpcyB3
YXkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPi1NaWtlPC9G
T05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPiZxdW90O1JvYmVydCBKIE1hcmtzJnF1b3Q7ICZsdDtyam1hcmtzQGNhbWJpYW5l
dHdvcmtzLmNvbSZndDsgb24gMTAvMTgvMjAwMSAwNDoyNzo0OSBQTTwvRk9OVD4NCjwvUD4NCg0K
PFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5QbGVhc2UgcmVzcG9uZCB0byBtb2JpbGUtaXBA
c3Vucm9vZi5lbmcuc3VuLmNvbTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5TZW50IGJ5OiZuYnNwOyAmcXVvdDtSb2JlcnQgSiBNYXJrcyZxdW90OyAmbHQ7cmpt
YXJrc0BjYW1iaWFuZXR3b3Jrcy5jb20mZ3Q7PC9GT05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRvOiZuYnNwOyZuYnNwOyBtb2JpbGUtaXBAc3Vucm9vZi5l
bmcuc3VuLmNvbSwgY2hhcmxpZXBAaXByZy5ub2tpYS5jb20sPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBjYWxob3Vu
QGRpYW1ldGVyLm9yZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmNjOiZu
YnNwOyZuYnNwOyZuYnNwOyAoTWlrZSBCb3JlbGxhL01XL1VTLzNDb20pPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U3ViamVjdDombmJzcDsgUkU6IFttb2JpbGUtaXBdIFVS
R0VOVCAtIHJmYzMwMTIgaW50ZXJwcmV0YXRpb24gcXVlc3Rpb248L0ZPTlQ+DQo8L1A+DQo8QlI+
DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QWx0aG91Z2ggSSBhbSBub3Qg
c3VyZSBvZiB0aGUgaW50ZW50aW9uIGluIHRoZSBSRkMsIEkgYWdyZWUgdGhhdCB0aGU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5ieXRlIHNob3VsZCBub3QgYmUgZHVwbGlj
YXRlZCBpbiAyIHBsYWNlcy4gSSBhbHNvIHNlZW0gdG8gcmVtZW1iZXIgdGhhdDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmtub3duIGR1cGxpY2F0aW9uIHRlbmRzIHRvIHdl
YWtlbiB0aGUgc2VjdXJpdHkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPkJvYjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPkZyb206IG93bmVyLW1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+WzxBIEhSRUY9Im1haWx0bzpvd25lci1tb2Jp
bGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSI+bWFpbHRvOm93bmVyLW1vYmlsZS1pcEBzdW5yb29m
LmVuZy5zdW4uY29tPC9BPl0gT24gQmVoYWxmIE9mIE5pc2ggQWJyb2w8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TZW50OiBUaHVyc2RheSwgT2N0b2JlciAxOCwgMjAwMSAx
MjoxNCBBTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRvOiBjaGFybGll
cEBpcHJnLm5va2lhLmNvbTsgcGNhbGhvdW5AZGlhbWV0ZXIub3JnOzwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPm1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U3ViamVjdDogW21vYmlsZS1pcF0gVVJH
RU5UIC0gcmZjMzAxMiBpbnRlcnByZXRhdGlvbiBxdWVzdGlvbjwvRk9OVD4NCjwvUD4NCjxCUj4N
Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5QYXQvQ2hhcmxpZSw8L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVhbGx5IGFwcHJlY2lhdGUgYW55IGlu
c2lnaHRzIGludG8gdGhpcyByZWFsbHkgaW1wb3J0YW50IGludGVyb3AgaXNzdWU8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5mb3IgY2RtYTIwMDA6PC9GT05UPg0KPC9QPg0K
DQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSZu
YnNwOyBpbnRlcnByZXRhdGlvbiBvZiBzZWN0aW9uIDggb2YgcmZjMzAxMi4gVGhpczwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnNlY3Rpb24gc3BlY2lmaWVzIGhvdyB0byBj
YWxjdWxhdGUgdGhlIE1OLUFBQSBhdXRoZW50aWNhdG9yLiBJdCBzYXlzOjwvRk9OVD4NCjwvUD4N
Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mcXVvdDsgVG8gY29tcHV0ZSB0aGUgYXV0
aGVudGljYXRvciwgYXBwbHkgTUQ1IFsxMV0gY29tcHV0ZWQgb24gdGhlPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Zm9sbG93aW5nIGRhdGEsIGluIHRoZSBvcmRlciBzaG93
bjo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SGlnaC1vcmRl
ciBieXRlIGZyb20gQ2hhbGxlbmdlIHx8IEtleSB8fDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPk1ENShQcmVjZWRpbmcgTW9iaWxlIElQIGRhdGEgfHw8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UeXBlLCBTdWJ0eXBlIChpZiBwcmVzZW50KSwgTGVu
Z3RoLCBTUEkpIHx8PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+TGVhc3Qt
b3JkZXIgMjM3IGJ5dGVzIGZyb20gQ2hhbGxlbmdlICZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgcXVlc3Rpb24gaXMgLSBpZiB0aGUgY2hhbGxl
bmdlIGhhcyBsZXNzIHRoYW4gMjM3IGJ5dGVzIC0gc2hvdWxkIHRoZTwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPmhpZ2ggb3JkZXIgYnl0ZSB3aGljaCB3YXMgYWxyZWFkeSB1
c2VkIGluIHRoZSBNRDUgY2FsY3VsYXRpb24mbmJzcDsgYmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj5pbmNsdWRlZCBhZ2FpbiBhcyBwYXJ0IG9mIHRoZSZuYnNwOyAmcXVv
dDtsZWFzdC1vcmRlciAyMzcgYnl0ZXMgZnJvbSBDaGFsbGVuZ2UmcXVvdDs/PC9GT05UPg0KPC9Q
Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmUuZy4gaWYgdGhlIGNoYWxsZW5nZSBp
cyA1MCBieXRlcyBpbiBsZW5ndGggLSBzaG91bGQgdGhlIGF1dGhlbnRpY2F0b3I8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5iZSBjYWxjdWxhdGVkJm5ic3A7IGFzOjwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAoYSkm
bmJzcDsgYXV0aGVuaWNhdG9yID0gbWQ1KGJ5dGUwIHx8IGtleS4uLi4uLi58fCBieXRlMSB0aHJv
dWdoIGJ5dGU0OSk8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
b3IgKGIpIGF1dGhlbnRpY2F0b3IgPSBtZDUoYnl0ZTAgfHwga2V5IC4uLi4uLnx8IGJ5dGUwIHRo
cm91Z2ggYnl0ZTQ5KS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJlIGJ5dGUwIGlzIHRoZSBtb3N0
IHNpZ25pZmljYW50IGJ5dGUgb2YgdGhlIGNoYWxsZW5nZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QSBzdHJpY3QgcmVhZGluZyBvZiB0aGUgUkZDIHNlZW1z
IHRvIHN1Z2dlc3QgKGIpLiBIb3dldmVyLCBpdCBzZWVtczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPnRoYXQgY2FsY3VsYXRpbmcgdGhlIE1ENSBhdXRoZW50aWNhdG9yIHdp
dGggdGhlIHNhbWUgaW5mb3JtYXRpb24oaGlnaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPm9yZGVyIGJ5dGUpIGF0IGRpZmZlcmVudCBsb2NhdGlvbnMgb2YgdGhlIHBheWxv
YWQgd2Vha2VucyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5hdXRo
ZW50aWNhdG9yLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5T
bywgd2hhdCB3YXMgdGhlIGludGVudGlvbiBvZiB0aGUgUkZDIGFuZCBob3cgc2hvdWxkIGl0IGJl
IGltcGxlbWVudGVkPzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkFsc28s
IGRvIHlvdSBrbm93IGlmIFJGQzMwMTIgaW1wbGVtZW50YXRpb25zIGhhdmUgcGFydGljaXBhdGVk
IGluIGFueTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmJha2VvZmZzL2lu
dGVyb3BzLiBJZiBzbywgaG93IGhhdmUgdGhleSBpbnRlcnByZXRlZCB0aGlzIHNlY3Rpb24/PC9G
T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPllvdXIgaGVscCB3aWxs
IGJlIHJlYWxseSBhcHByZWNpYXRlZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+VGhhbmtzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
TmlzaCBBYnJvbDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlF1YWxjb21t
LCBJbmMuPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0K
DQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZsdDsmbHQ7IEZpbGU6IEludGVy
bmV0IEhUTUwgJmd0OyZndDsgPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo=

--0__=vRBLHuRnk9eOyAQBNFhzRdp913H6wpK5iuFGkTvUUF9U8hQmp4XPcEOe--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 10:05:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17287
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 10:05:18 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16345;
	Mon, 22 Oct 2001 07:05:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28955;
	Mon, 22 Oct 2001 07:04:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ME2eOI006989
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:02:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9ME2erZ006988
	for mobile-ip-dist; Mon, 22 Oct 2001 07:02:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ME2bOI006981
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:02:37 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28695
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:02:34 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11502
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:02:33 -0700 (PDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA00795
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:02:31 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 22 Oct 2001 09:00:31 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L7BFZ>; Mon, 22 Oct 2001 09:01:37 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF4E1@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Mon, 22 Oct 2001 09:01:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15B02.0F185680"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15B02.0F185680
Content-Type: text/plain;
	charset="iso-8859-1"

I agree. 
I believe there is a couple of issues need to be clarified.
One regarding Stale Challenge.
The other regarding MN using the CHALLENGE received in the RRP with error
code and the meaning of successful Registration Request.

I will provide details at later time. 

Regards;

Ahmad Muhanna


-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
Sent: Monday, October 22, 2001 4:18 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question


Whatever the best interpretation will be, the fact that this is subject
to interpretation tells me that RFC 3012 needs to be revised ASAP
with a description which is clear on this point.

Are there other issues that aren't (or weren't) clear to implementors
of RFC 3012? Any issues that required sending a question on a mailing
list or to the authors would seem like a good reason to get the
spec clarified.

  Erik


>----- Begin Included Message -----<

Date: Fri, 19 Oct 2001 15:47:24 -0500
From: Mike_Borella@3com.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
To: mobile-ip@sunroof.eng.sun.com



I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general
concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.








>----- End Included Message -----<


------_=_NextPart_001_01C15B02.0F185680
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree. </FONT>
<BR><FONT SIZE=3D2>I believe there is a couple of issues need to be =
clarified.</FONT>
<BR><FONT SIZE=3D2>One regarding Stale Challenge.</FONT>
<BR><FONT SIZE=3D2>The other regarding MN using the CHALLENGE received =
in the RRP with error code and the meaning of successful Registration =
Request.</FONT></P>

<P><FONT SIZE=3D2>I will provide details at later time. </FONT>
</P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Ahmad Muhanna</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Erik Nordmark [<A =
HREF=3D"mailto:Erik.Nordmark@eng.sun.com">mailto:Erik.Nordmark@eng.sun.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, October 22, 2001 4:18 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Whatever the best interpretation will be, the fact =
that this is subject</FONT>
<BR><FONT SIZE=3D2>to interpretation tells me that RFC 3012 needs to be =
revised ASAP</FONT>
<BR><FONT SIZE=3D2>with a description which is clear on this =
point.</FONT>
</P>

<P><FONT SIZE=3D2>Are there other issues that aren't (or weren't) clear =
to implementors</FONT>
<BR><FONT SIZE=3D2>of RFC 3012? Any issues that required sending a =
question on a mailing</FONT>
<BR><FONT SIZE=3D2>list or to the authors would seem like a good reason =
to get the</FONT>
<BR><FONT SIZE=3D2>spec clarified.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; Erik</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;----- Begin Included Message -----&lt;</FONT>
</P>

<P><FONT SIZE=3D2>Date: Fri, 19 Oct 2001 15:47:24 -0500</FONT>
<BR><FONT SIZE=3D2>From: Mike_Borella@3com.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>I don't think that one can conclude that there is a =
security problem unless</FONT>
<BR><FONT SIZE=3D2>it is documented.&nbsp; A quick search of the web =
finds plenty of general concerns</FONT>
<BR><FONT SIZE=3D2>with</FONT>
<BR><FONT SIZE=3D2>MD5 but nothing about this particular issue.&nbsp; =
Does copying a byte in an n byte</FONT>
<BR><FONT SIZE=3D2>hash make it any less secure than the other =
interpretation which is an n-1</FONT>
<BR><FONT SIZE=3D2>byte hash?</FONT>
</P>

<P><FONT SIZE=3D2>It is very clear that a literal reading of RFC3012 =
indicates that the byte</FONT>
<BR><FONT SIZE=3D2>should</FONT>
<BR><FONT SIZE=3D2>be copied.&nbsp; There are commercial deployments =
that already do it this way.</FONT>
</P>

<P><FONT SIZE=3D2>-Mike</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Robert J Marks&quot; =
&lt;rjmarks@cambianetworks.com&gt; on 10/18/2001 04:27:49 PM</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp; &quot;Robert J Marks&quot; =
&lt;rjmarks@cambianetworks.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; mobile-ip@sunroof.eng.sun.com, =
charliep@iprg.nokia.com,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; (Mike =
Borella/MW/US/3Com)</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Although I am not sure of the intention in the RFC, I =
agree that the</FONT>
<BR><FONT SIZE=3D2>byte should not be duplicated in 2 places. I also =
seem to remember that</FONT>
<BR><FONT SIZE=3D2>known duplication tends to weaken the =
security.</FONT>
</P>

<P><FONT SIZE=3D2>Bob</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: owner-mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:owner-mobile-ip@sunroof.eng.sun.com">mailto:owner-mobile-=
ip@sunroof.eng.sun.com</A>] On Behalf Of Nish Abrol</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, October 18, 2001 12:14 AM</FONT>
<BR><FONT SIZE=3D2>To: charliep@iprg.nokia.com; =
pcalhoun@diameter.org;</FONT>
<BR><FONT SIZE=3D2>mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] URGENT - rfc3012 interpretation =
question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Pat/Charlie,</FONT>
</P>

<P><FONT SIZE=3D2>Really appreciate any insights into this really =
important interop issue</FONT>
<BR><FONT SIZE=3D2>for cdma2000:</FONT>
</P>

<P><FONT SIZE=3D2>A question regarding the&nbsp; interpretation of =
section 8 of rfc3012. This</FONT>
<BR><FONT SIZE=3D2>section specifies how to calculate the MN-AAA =
authenticator. It says:</FONT>
</P>

<P><FONT SIZE=3D2>&quot; To compute the authenticator, apply MD5 [11] =
computed on the</FONT>
<BR><FONT SIZE=3D2>following data, in the order shown:</FONT>
</P>

<P><FONT SIZE=3D2>High-order byte from Challenge || Key ||</FONT>
<BR><FONT SIZE=3D2>MD5(Preceding Mobile IP data ||</FONT>
<BR><FONT SIZE=3D2>Type, Subtype (if present), Length, SPI) ||</FONT>
<BR><FONT SIZE=3D2>Least-order 237 bytes from Challenge &quot;</FONT>
</P>

<P><FONT SIZE=3D2>The question is - if the challenge has less than 237 =
bytes - should the</FONT>
<BR><FONT SIZE=3D2>high order byte which was already used in the MD5 =
calculation&nbsp; be</FONT>
<BR><FONT SIZE=3D2>included again as part of the&nbsp; =
&quot;least-order 237 bytes from Challenge&quot;?</FONT>
</P>

<P><FONT SIZE=3D2>e.g. if the challenge is 50 bytes in length - should =
the authenticator</FONT>
<BR><FONT SIZE=3D2>be calculated&nbsp; as:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator =3D =
md5(byte0 || key.......|| byte1 through byte49)</FONT>
</P>

<P><FONT SIZE=3D2>or (b) authenticator =3D md5(byte0 || key ......|| =
byte0 through byte49).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the =
most significant byte of the challenge.</FONT>
</P>

<P><FONT SIZE=3D2>A strict reading of the RFC seems to suggest (b). =
However, it seems</FONT>
<BR><FONT SIZE=3D2>that calculating the MD5 authenticator with the same =
information(high</FONT>
<BR><FONT SIZE=3D2>order byte) at different locations of the payload =
weakens the</FONT>
<BR><FONT SIZE=3D2>authenticator.</FONT>
</P>

<P><FONT SIZE=3D2>So, what was the intention of the RFC and how should =
it be implemented?</FONT>
<BR><FONT SIZE=3D2>Also, do you know if RFC3012 implementations have =
participated in any</FONT>
<BR><FONT SIZE=3D2>bakeoffs/interops. If so, how have they interpreted =
this section?</FONT>
</P>

<P><FONT SIZE=3D2>Your help will be really appreciated.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Nish Abrol</FONT>
<BR><FONT SIZE=3D2>Qualcomm, Inc.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;----- End Included Message -----&lt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15B02.0F185680--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 10:07:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17322
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 10:07:25 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17264;
	Mon, 22 Oct 2001 07:07:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29264;
	Mon, 22 Oct 2001 07:05:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ME4xOI007019
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:05:00 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9ME4xPL007018
	for mobile-ip-dist; Mon, 22 Oct 2001 07:04:59 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9ME4tOI007011
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:04:55 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08103
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:04:56 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08636
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:04:30 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA01782
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:04:53 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 22 Oct 2001 08:57:16 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L7BH7>; Mon, 22 Oct 2001 09:03:22 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF4E2@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] RE: [mobile-mip] URGENT - rfc3012 interpretation question
Date: Mon, 22 Oct 2001 09:03:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15B02.4D04D8B0"
X-Orig: <amuhanna@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15B02.4D04D8B0
Content-Type: text/plain;
	charset="iso-8859-1"


I am definitely not trying to protect a certain implementation here. 
Those who are familiar with this issue's implementation know that it is less
than one or two lines of code change. 
Unless certain implementation needs a huge change!


Regards;

Ahmad Muhanna



-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Monday, October 22, 2001 7:59 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




And I hope that you are not spreading FUD to protect an implementation.
When you claim that there is a security problem in a protocol or algorithm,
you need to back it up with solid evidence, which no one has done yet.

If there is a genuine security problem with my interpretation, I would like
to
know and
will make the appropriate apologies then.

However I do agree that concensus in the crypto community is that using MD5
is risky.  That is another problem.  If MD5 has such issues we should be
using
a better hash, such a SHA-1, I suppose.

Mike





"Ahmad Muhanna" <amuhanna@nortelnetworks.com> on 10/21/2001 10:04:15 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Ahmad Muhanna" <amuhanna@nortelnetworks.com>


To:   "'mobile-ip @sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question




I hope that this discussion is for the purpose of ensuring a secure and
robust Mobile IP protocol rather than defending certain implementation.

Having said that, I would like to confess that, at the moment, I can not
provide a reference for the reduced security or the introduced weakness,
because of using the High-Order byte of the Challenge at two fixed different
locations of the payload in calculating the MN-AAA authenticator.

However, as most of us know, MD5 is not very strong in calculating digital
signature. In other words the MD5 collision resistance is not impossibly
immune as per the following references.

RFC1321 says in conclusion:
"The MD5 message-digest algorithm is simple to implement, and provides a
"fingerprint" or message digest of a message of arbitrary length. It is
conjectured that the difficulty of coming up with two messages having the
same message digest is on the order of 2^64 operations, and that the
difficulty of coming up with any message having a given message digest is on
the order of 2^128 operations. The MD5 algorithm has been carefully
scrutinized for weaknesses. ...."

Please, let us remember this RFC was written on April 1992, at the age of 35
MHZ PC's.

ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf (1996)

"... customers should note that while the continued suitability of MD5 for
applications requiring collision-resistance is in question, the use of MD5
in other roles, for example as part of a mechanism for random number
generation, is still considered safe. ..."

http://www.math.fu-berlin.de/~guckes/md5/

".... In 1996, MD5 was all but broken by a German cryptographer, Hans
Dobbertin. Although MD5 was not completely broken at that time, it was
discovered to have such serious weaknesses that no one should keep using it
to generate signatures..."

It may need a special investigation to find out the weakness introduced by
the literal implementation of section 8 in RFC3012. However, we know for
fact that the other interpretation does not introduce any new form of
weakness or patterns.

Therefore, taking all of this and the fact that the (Least-order 237 bytes
from Challenge) mentioned in section 8 of RFC 3012 was there to make sure
that no more than 253 bytes can be sent by PDSN/FA to RADIUS in a RADIUS
attribute, I strongly believe that any wise implementation should not
intentionally aid the Crypto analytical attacker and make his/her job a
little easier by introducing a pattern in the hashed payload.

Regards;

Ahmad Muhanna



-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 4:26 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




Please provide a reference to exactly how security is reduced by having
the extra byte.  Until such a refernce or argument is made, the security
issue
is null and void.

Mike





"Ahmad Muhanna" <amuhanna@nortelnetworks.com> on 10/19/2001 04:20:30 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Ahmad Muhanna" <amuhanna@nortelnetworks.com>


To:   "'mobile-ip @sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question




I have never heard of any implementation which generates a Challenge value
of 238 bytes or more.
I believe that the whole idea of mentioning the number of least-order bytes
of Challenge (237) in section 8 of RFC3012 is very simply to avoid having
the PDSN sending more than 253 bytes in the CHAP-CHALLENGE attribute to
RADIUS during MN-AAA authentication.
In reality, no one is producing a CHALLENGE value that Huge.

On the other hand, whatever amount of extra security introduced by avoiding
having two exact bytes of the Challenge at two different location is an
ABSOLUTE PLUS.


Ahmad Muhanna

-----Original Message-----
From: Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
Sent: Friday, October 19, 2001 3:47 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question




I don't think that one can conclude that there is a security problem unless
it is documented.  A quick search of the web finds plenty of general
concerns
with
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte
hash make it any less secure than the other interpretation which is an n-1
byte hash?

It is very clear that a literal reading of RFC3012 indicates that the byte
should
be copied.  There are commercial deployments that already do it this way.

-Mike





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com>


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
      pcalhoun@diameter.org
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question



Although I am not sure of the intention in the RFC, I agree that the
byte should not be duplicated in 2 places. I also seem to remember that
known duplication tends to weaken the security.

Bob

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com
[mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Nish Abrol
Sent: Thursday, October 18, 2001 12:14 AM
To: charliep@iprg.nokia.com; pcalhoun@diameter.org;
mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question


Pat/Charlie,

Really appreciate any insights into this really important interop issue
for cdma2000:

A question regarding the  interpretation of section 8 of rfc3012. This
section specifies how to calculate the MN-AAA authenticator. It says:

" To compute the authenticator, apply MD5 [11] 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 "

The question is - if the challenge has less than 237 bytes - should the
high order byte which was already used in the MD5 calculation  be
included again as part of the  "least-order 237 bytes from Challenge"?

e.g. if the challenge is 50 bytes in length - should the authenticator
be calculated  as:
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).

      where byte0 is the most significant byte of the challenge.

A strict reading of the RFC seems to suggest (b). However, it seems
that calculating the MD5 authenticator with the same information(high
order byte) at different locations of the payload weakens the
authenticator.

So, what was the intention of the RFC and how should it be implemented?
Also, do you know if RFC3012 implementations have participated in any
bakeoffs/interops. If so, how have they interpreted this section?

Your help will be really appreciated.

Thanks
Nish Abrol
Qualcomm, Inc.







 << File: Internet HTML >>


------_=_NextPart_001_01C15B02.4D04D8B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-mip] URGENT - rfc3012 interpretation =
question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I am definitely not trying to protect a certain =
implementation here. </FONT>
<BR><FONT SIZE=3D2>Those who are familiar with this issue's =
implementation know that it is less than one or two lines of code =
change. </FONT>
<BR><FONT SIZE=3D2>Unless certain implementation needs a huge =
change!</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Ahmad Muhanna</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mike_Borella@3com.com [<A =
HREF=3D"mailto:Mike_Borella@3com.com">mailto:Mike_Borella@3com.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, October 22, 2001 7:59 AM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>And I hope that you are not spreading FUD to protect =
an implementation.</FONT>
<BR><FONT SIZE=3D2>When you claim that there is a security problem in a =
protocol or algorithm,</FONT>
<BR><FONT SIZE=3D2>you need to back it up with solid evidence, which no =
one has done yet.</FONT>
</P>

<P><FONT SIZE=3D2>If there is a genuine security problem with my =
interpretation, I would like to</FONT>
<BR><FONT SIZE=3D2>know and</FONT>
<BR><FONT SIZE=3D2>will make the appropriate apologies then.</FONT>
</P>

<P><FONT SIZE=3D2>However I do agree that concensus in the crypto =
community is that using MD5</FONT>
<BR><FONT SIZE=3D2>is risky.&nbsp; That is another problem.&nbsp; If =
MD5 has such issues we should be using</FONT>
<BR><FONT SIZE=3D2>a better hash, such a SHA-1, I suppose.</FONT>
</P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Ahmad Muhanna&quot; =
&lt;amuhanna@nortelnetworks.com&gt; on 10/21/2001 10:04:15 PM</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp; &quot;Ahmad Muhanna&quot; =
&lt;amuhanna@nortelnetworks.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; &quot;'mobile-ip =
@sunroof.eng.sun.com'&quot; =
&lt;mobile-ip@sunroof.eng.sun.com&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; (Mike =
Borella/MW/US/3Com)</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>I hope that this discussion is for the purpose of =
ensuring a secure and</FONT>
<BR><FONT SIZE=3D2>robust Mobile IP protocol rather than defending =
certain implementation.</FONT>
</P>

<P><FONT SIZE=3D2>Having said that, I would like to confess that, at =
the moment, I can not</FONT>
<BR><FONT SIZE=3D2>provide a reference for the reduced security or the =
introduced weakness,</FONT>
<BR><FONT SIZE=3D2>because of using the High-Order byte of the =
Challenge at two fixed different</FONT>
<BR><FONT SIZE=3D2>locations of the payload in calculating the MN-AAA =
authenticator.</FONT>
</P>

<P><FONT SIZE=3D2>However, as most of us know, MD5 is not very strong =
in calculating digital</FONT>
<BR><FONT SIZE=3D2>signature. In other words the MD5 collision =
resistance is not impossibly</FONT>
<BR><FONT SIZE=3D2>immune as per the following references.</FONT>
</P>

<P><FONT SIZE=3D2>RFC1321 says in conclusion:</FONT>
<BR><FONT SIZE=3D2>&quot;The MD5 message-digest algorithm is simple to =
implement, and provides a</FONT>
<BR><FONT SIZE=3D2>&quot;fingerprint&quot; or message digest of a =
message of arbitrary length. It is</FONT>
<BR><FONT SIZE=3D2>conjectured that the difficulty of coming up with =
two messages having the</FONT>
<BR><FONT SIZE=3D2>same message digest is on the order of 2^64 =
operations, and that the</FONT>
<BR><FONT SIZE=3D2>difficulty of coming up with any message having a =
given message digest is on</FONT>
<BR><FONT SIZE=3D2>the order of 2^128 operations. The MD5 algorithm has =
been carefully</FONT>
<BR><FONT SIZE=3D2>scrutinized for weaknesses. ....&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Please, let us remember this RFC was written on April =
1992, at the age of 35</FONT>
<BR><FONT SIZE=3D2>MHZ PC's.</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf" =
TARGET=3D"_blank">ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf</A> =
(1996)</FONT>
</P>

<P><FONT SIZE=3D2>&quot;... customers should note that while the =
continued suitability of MD5 for</FONT>
<BR><FONT SIZE=3D2>applications requiring collision-resistance is in =
question, the use of MD5</FONT>
<BR><FONT SIZE=3D2>in other roles, for example as part of a mechanism =
for random number</FONT>
<BR><FONT SIZE=3D2>generation, is still considered safe. =
...&quot;</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://www.math.fu-berlin.de/~guckes/md5/" =
TARGET=3D"_blank">http://www.math.fu-berlin.de/~guckes/md5/</A></FONT>
</P>

<P><FONT SIZE=3D2>&quot;.... In 1996, MD5 was all but broken by a =
German cryptographer, Hans</FONT>
<BR><FONT SIZE=3D2>Dobbertin. Although MD5 was not completely broken at =
that time, it was</FONT>
<BR><FONT SIZE=3D2>discovered to have such serious weaknesses that no =
one should keep using it</FONT>
<BR><FONT SIZE=3D2>to generate signatures...&quot;</FONT>
</P>

<P><FONT SIZE=3D2>It may need a special investigation to find out the =
weakness introduced by</FONT>
<BR><FONT SIZE=3D2>the literal implementation of section 8 in RFC3012. =
However, we know for</FONT>
<BR><FONT SIZE=3D2>fact that the other interpretation does not =
introduce any new form of</FONT>
<BR><FONT SIZE=3D2>weakness or patterns.</FONT>
</P>

<P><FONT SIZE=3D2>Therefore, taking all of this and the fact that the =
(Least-order 237 bytes</FONT>
<BR><FONT SIZE=3D2>from Challenge) mentioned in section 8 of RFC 3012 =
was there to make sure</FONT>
<BR><FONT SIZE=3D2>that no more than 253 bytes can be sent by PDSN/FA =
to RADIUS in a RADIUS</FONT>
<BR><FONT SIZE=3D2>attribute, I strongly believe that any wise =
implementation should not</FONT>
<BR><FONT SIZE=3D2>intentionally aid the Crypto analytical attacker and =
make his/her job a</FONT>
<BR><FONT SIZE=3D2>little easier by introducing a pattern in the hashed =
payload.</FONT>
</P>

<P><FONT SIZE=3D2>Regards;</FONT>
</P>

<P><FONT SIZE=3D2>Ahmad Muhanna</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mike_Borella@3com.com [<A =
HREF=3D"mailto:Mike_Borella@3com.com">mailto:Mike_Borella@3com.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 19, 2001 4:26 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Please provide a reference to exactly how security is =
reduced by having</FONT>
<BR><FONT SIZE=3D2>the extra byte.&nbsp; Until such a refernce or =
argument is made, the security</FONT>
<BR><FONT SIZE=3D2>issue</FONT>
<BR><FONT SIZE=3D2>is null and void.</FONT>
</P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Ahmad Muhanna&quot; =
&lt;amuhanna@nortelnetworks.com&gt; on 10/19/2001 04:20:30 PM</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp; &quot;Ahmad Muhanna&quot; =
&lt;amuhanna@nortelnetworks.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; &quot;'mobile-ip =
@sunroof.eng.sun.com'&quot; =
&lt;mobile-ip@sunroof.eng.sun.com&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; (Mike =
Borella/MW/US/3Com)</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>I have never heard of any implementation which =
generates a Challenge value</FONT>
<BR><FONT SIZE=3D2>of 238 bytes or more.</FONT>
<BR><FONT SIZE=3D2>I believe that the whole idea of mentioning the =
number of least-order bytes</FONT>
<BR><FONT SIZE=3D2>of Challenge (237) in section 8 of RFC3012 is very =
simply to avoid having</FONT>
<BR><FONT SIZE=3D2>the PDSN sending more than 253 bytes in the =
CHAP-CHALLENGE attribute to</FONT>
<BR><FONT SIZE=3D2>RADIUS during MN-AAA authentication.</FONT>
<BR><FONT SIZE=3D2>In reality, no one is producing a CHALLENGE value =
that Huge.</FONT>
</P>

<P><FONT SIZE=3D2>On the other hand, whatever amount of extra security =
introduced by avoiding</FONT>
<BR><FONT SIZE=3D2>having two exact bytes of the Challenge at two =
different location is an</FONT>
<BR><FONT SIZE=3D2>ABSOLUTE PLUS.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Ahmad Muhanna</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mike_Borella@3com.com [<A =
HREF=3D"mailto:Mike_Borella@3com.com">mailto:Mike_Borella@3com.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 19, 2001 3:47 PM</FONT>
<BR><FONT SIZE=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>I don't think that one can conclude that there is a =
security problem unless</FONT>
<BR><FONT SIZE=3D2>it is documented.&nbsp; A quick search of the web =
finds plenty of general</FONT>
<BR><FONT SIZE=3D2>concerns</FONT>
<BR><FONT SIZE=3D2>with</FONT>
<BR><FONT SIZE=3D2>MD5 but nothing about this particular issue.&nbsp; =
Does copying a byte in an n</FONT>
<BR><FONT SIZE=3D2>byte</FONT>
<BR><FONT SIZE=3D2>hash make it any less secure than the other =
interpretation which is an n-1</FONT>
<BR><FONT SIZE=3D2>byte hash?</FONT>
</P>

<P><FONT SIZE=3D2>It is very clear that a literal reading of RFC3012 =
indicates that the byte</FONT>
<BR><FONT SIZE=3D2>should</FONT>
<BR><FONT SIZE=3D2>be copied.&nbsp; There are commercial deployments =
that already do it this way.</FONT>
</P>

<P><FONT SIZE=3D2>-Mike</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Robert J Marks&quot; =
&lt;rjmarks@cambianetworks.com&gt; on 10/18/2001 04:27:49 PM</FONT>
</P>

<P><FONT SIZE=3D2>Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp; &quot;Robert J Marks&quot; =
&lt;rjmarks@cambianetworks.com&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; mobile-ip@sunroof.eng.sun.com, =
charliep@iprg.nokia.com,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp;&nbsp; (Mike =
Borella/MW/US/3Com)</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: [mobile-ip] URGENT - rfc3012 =
interpretation question</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Although I am not sure of the intention in the RFC, I =
agree that the</FONT>
<BR><FONT SIZE=3D2>byte should not be duplicated in 2 places. I also =
seem to remember that</FONT>
<BR><FONT SIZE=3D2>known duplication tends to weaken the =
security.</FONT>
</P>

<P><FONT SIZE=3D2>Bob</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: owner-mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:owner-mobile-ip@sunroof.eng.sun.com">mailto:owner-mobile-=
ip@sunroof.eng.sun.com</A>] On Behalf Of Nish Abrol</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, October 18, 2001 12:14 AM</FONT>
<BR><FONT SIZE=3D2>To: charliep@iprg.nokia.com; =
pcalhoun@diameter.org;</FONT>
<BR><FONT SIZE=3D2>mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2>Subject: [mobile-ip] URGENT - rfc3012 interpretation =
question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Pat/Charlie,</FONT>
</P>

<P><FONT SIZE=3D2>Really appreciate any insights into this really =
important interop issue</FONT>
<BR><FONT SIZE=3D2>for cdma2000:</FONT>
</P>

<P><FONT SIZE=3D2>A question regarding the&nbsp; interpretation of =
section 8 of rfc3012. This</FONT>
<BR><FONT SIZE=3D2>section specifies how to calculate the MN-AAA =
authenticator. It says:</FONT>
</P>

<P><FONT SIZE=3D2>&quot; To compute the authenticator, apply MD5 [11] =
computed on the</FONT>
<BR><FONT SIZE=3D2>following data, in the order shown:</FONT>
</P>

<P><FONT SIZE=3D2>High-order byte from Challenge || Key ||</FONT>
<BR><FONT SIZE=3D2>MD5(Preceding Mobile IP data ||</FONT>
<BR><FONT SIZE=3D2>Type, Subtype (if present), Length, SPI) ||</FONT>
<BR><FONT SIZE=3D2>Least-order 237 bytes from Challenge &quot;</FONT>
</P>

<P><FONT SIZE=3D2>The question is - if the challenge has less than 237 =
bytes - should the</FONT>
<BR><FONT SIZE=3D2>high order byte which was already used in the MD5 =
calculation&nbsp; be</FONT>
<BR><FONT SIZE=3D2>included again as part of the&nbsp; =
&quot;least-order 237 bytes from Challenge&quot;?</FONT>
</P>

<P><FONT SIZE=3D2>e.g. if the challenge is 50 bytes in length - should =
the authenticator</FONT>
<BR><FONT SIZE=3D2>be calculated&nbsp; as:</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator =3D =
md5(byte0 || key.......|| byte1 through byte49)</FONT>
</P>

<P><FONT SIZE=3D2>or (b) authenticator =3D md5(byte0 || key ......|| =
byte0 through byte49).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the =
most significant byte of the challenge.</FONT>
</P>

<P><FONT SIZE=3D2>A strict reading of the RFC seems to suggest (b). =
However, it seems</FONT>
<BR><FONT SIZE=3D2>that calculating the MD5 authenticator with the same =
information(high</FONT>
<BR><FONT SIZE=3D2>order byte) at different locations of the payload =
weakens the</FONT>
<BR><FONT SIZE=3D2>authenticator.</FONT>
</P>

<P><FONT SIZE=3D2>So, what was the intention of the RFC and how should =
it be implemented?</FONT>
<BR><FONT SIZE=3D2>Also, do you know if RFC3012 implementations have =
participated in any</FONT>
<BR><FONT SIZE=3D2>bakeoffs/interops. If so, how have they interpreted =
this section?</FONT>
</P>

<P><FONT SIZE=3D2>Your help will be really appreciated.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Nish Abrol</FONT>
<BR><FONT SIZE=3D2>Qualcomm, Inc.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&lt;&lt; File: Internet HTML &gt;&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15B02.4D04D8B0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 10:33:01 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18680
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 10:33:00 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28600;
	Mon, 22 Oct 2001 07:32:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05611;
	Mon, 22 Oct 2001 07:32:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MEVrOI007279
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:31:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MEVqon007278
	for mobile-ip-dist; Mon, 22 Oct 2001 07:31:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MEVnOI007271
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:31:49 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12357
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:31:51 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00790
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:31:24 -0600 (MDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA11171
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:31:48 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 22 Oct 2001 09:24:50 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L7CF9>; Mon, 22 Oct 2001 09:30:56 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E7B52D1@zrc2c012.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com
Cc: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Mon, 22 Oct 2001 09:30:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15B06.274CA3B0"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15B06.274CA3B0
Content-Type: text/plain;
	charset="iso-8859-1"

4. Don't piggyback on RTP streams that are not encrypted.

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Monday, October 22, 2001 12:31 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Cc: Koodli Rajeev (NRC/MtView); 'ext Michael Thomas'; Michael A. Ramalho
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion




	Hello Rajeev and all, 

	> Koodli Rajeev (NRC/MtView) writes: 

	>  > This brings back the question of whether destination option
must have 
>  > been specified in the first place because some weird link does not know

>  > how to support it! What's the logic in saying IP cannot have 
>  > variable-sized packets because a link would have performance issues? 
> 
>    The current BU design is not modular. It claims 
>    that it did that because of bandwidth/latency 
>    gains. You have not presented a *single* MAC/PHY 
>    where that claim can be tested. Here you dodge 
>    my direct question yet again. 
> 

	Actually, I mentioned previously that the use of [rohc] over
cellular is one 
reference for you. See http://www.ludd.luth.se/users/larsman/rocco
<http://www.ludd.luth.se/users/larsman/rocco>  and follow 
the references. 
Note: use of [rohc] would require support for variable packet sizes on the 
link (perhaps the same kind of link you are considering). 

	=> I'm not sure why the discussion has gone towards header 
compression, but anyway, the point I was raising was that 
piggybacking can have negative effects on the MN/CN if they 
are attached to a tight channel. Obviously the channel is tight 
because it''s expensive so there is a very limited potential 
of reserving a "just in case" extra BW for piggybacking. 

	Now, I'm not saying ROHC can't handle it, all I was saying is 
that this "larger" packet will likely take double the time 
to be sent over the air since it may not fit into one radio 
frame. If it does, then the end to end delay will be significantly 
increased (the air link delays are -by far- the largest part 
of the e2e delay in a cellular environment) and it may be dropped. 
ROHC is not reallt relevant here. 

	So the result of the scenario above is a degradation in service. 
Now we can argue for a long time about whether these links 
are "IP friendly" and whether we should design IP for 
these interfaces, but the fact is this is what we have _today_. 

	Also BTW these systems are the ones deploying IPv6 first ! 
So we just have to deal with the real case here and try to 
solve it. 

	Unfortunately, we can not assume that the problem can be solved 
at one end only. So what can we do ? 

	1.  Keep piggybacking and just say to the designers of these 
     systems "tough luck". ? Doesn't look good for MIPv6. 

	        Pro: - The draft doesn't change 
        con: - Adds another reason for not deploying MIPv6 in cellular 
               systems. 
             - The IPsec problem still stands 

	2.  Remove piggybacking ? 
       
    pros: - End of this thread (can't wait :)) 
            - End of the IPsec problems. IPsec can be used 
            - MIPv6 becomes more "cellular friendly" 

	     Con: whatever advantages people see for piggybacking 
             (in Jari's draft) will disappear. 

	3.  Have some negotiation mechanism in MIPv6 between 
     the MN/CN. I'm not sure how this would work yet 
     but I could imagine having something in the Home Address 
     option or the BU option to indicate whether piggybacking 
     should be used or not. 
     If we use the Home address option, we would need to 
     account for the fact that it will not necessarily be secure. 
     Meaning, it can be modified en route. 
     
     If we use the BU, we will still get some service degradation 
     for the first BU. 
     Regardless of the chosen method for this option, this 
     new "flag" or "indication" MUST be supported by all 
     MNs and CNs to avoid any service degradation due to 
     piggybacking. 

	I'd be more inclined to 2 or 3 .... Comments ? 

	Hesham 


------_=_NextPart_001_01C15B06.274CA3B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=295013014-22102001>4. 
Don't piggyback on RTP streams that are not encrypted.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hesham Soliman (EPA) 
  [mailto:Hesham.Soliman@ericsson.com.au]<BR><B>Sent:</B> Monday, October 22, 
  2001 12:31 AM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Cc:</B> 
  Koodli Rajeev (NRC/MtView); 'ext Michael Thomas'; Michael A. 
  Ramalho<BR><B>Subject:</B> RE: [mobile-ip] MIPv6 - Focus of the security 
  discussion<BR><BR></DIV></FONT><BR>
  <UL>
    <P><FONT color=#0000ff face=Arial size=2>Hello Rajeev and all, </FONT></P>
    <P><FONT face=Arial size=2>&gt; Koodli Rajeev (NRC/MtView) writes:</FONT> 
    </P>
    <P><FONT face=Arial size=2>&gt;&nbsp; &gt; This brings back the question of 
    whether destination option must have</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp; &gt; been specified in the first place because some weird 
    link does not know</FONT> <BR><FONT face=Arial size=2>&gt;&nbsp; &gt; how to 
    support it! What's the logic in saying IP cannot have</FONT> <BR><FONT 
    face=Arial size=2>&gt;&nbsp; &gt; variable-sized packets because a link 
    would have performance issues?</FONT> <BR><FONT face=Arial 
    size=2>&gt;</FONT> <BR><FONT face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp; The 
    current BU design is not modular. It claims</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp; that it did that because of 
    bandwidth/latency</FONT> <BR><FONT face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp; 
    gains. You have not presented a *single* MAC/PHY</FONT> <BR><FONT face=Arial 
    size=2>&gt;&nbsp;&nbsp;&nbsp; where that claim can be tested. Here you 
    dodge</FONT> <BR><FONT face=Arial size=2>&gt;&nbsp;&nbsp;&nbsp; my direct 
    question yet again.</FONT> <BR><FONT face=Arial size=2>&gt;</FONT> </P>
    <P><FONT face=Arial size=2>Actually, I mentioned previously that the use of 
    [rohc] over cellular is one</FONT> <BR><FONT face=Arial size=2>reference for 
    you. See</FONT><U> <FONT color=#0000ff face=Arial size=2><A 
    href="http://www.ludd.luth.se/users/larsman/rocco" 
    target=_blank>http://www.ludd.luth.se/users/larsman/rocco</A></FONT></U><FONT 
    face=Arial size=2> and follow</FONT> <BR><FONT face=Arial size=2>the 
    references.</FONT> <BR><FONT face=Arial size=2>Note: use of [rohc] would 
    require support for variable packet sizes on the</FONT> <BR><FONT face=Arial 
    size=2>link (perhaps the same kind of link you are considering).</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; I'm not sure why the 
    discussion has gone towards header</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>compression, but anyway, the point I was raising was that 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>piggybacking can have 
    negative effects on the MN/CN if they</FONT> <BR><FONT color=#0000ff 
    face=Arial size=2>are attached to a tight channel. Obviously the channel is 
    tight</FONT> <BR><FONT color=#0000ff face=Arial size=2>because it''s 
    expensive so there is a very limited potential</FONT> <BR><FONT 
    color=#0000ff face=Arial size=2>of reserving a "just in case" extra BW for 
    piggybacking. </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>Now, I'm not saying ROHC can't 
    handle it, all I was saying is </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>that this "larger" packet will likely take double the time 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>to be sent over the air 
    since it may not fit into one radio</FONT> <BR><FONT color=#0000ff 
    face=Arial size=2>frame. If it does, then the end to end delay will be 
    significantly</FONT> <BR><FONT color=#0000ff face=Arial size=2>increased 
    (the air link delays are -by far- the largest part</FONT> <BR><FONT 
    color=#0000ff face=Arial size=2>of the e2e delay in a cellular environment) 
    and it may be dropped. </FONT><BR><FONT color=#0000ff face=Arial size=2>ROHC 
    is not reallt relevant here.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>So the result of the scenario above 
    is a degradation in service. </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>Now we can argue for a long time about whether these links</FONT> 
    <BR><FONT color=#0000ff face=Arial size=2>are "IP friendly" and whether we 
    should design IP for </FONT><BR><FONT color=#0000ff face=Arial size=2>these 
    interfaces, but the fact is this is what we have _today_. </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>Also BTW these systems are the ones 
    deploying IPv6 first !</FONT> <BR><FONT color=#0000ff face=Arial size=2>So 
    we just have to deal with the real case here and try to</FONT> <BR><FONT 
    color=#0000ff face=Arial size=2>solve it. </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>Unfortunately, we can not assume 
    that the problem can be solved</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>at one end only. So what can we do ?</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>1.&nbsp; Keep piggybacking and just 
    say to the designers of these</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; systems "tough luck". ? Doesn't look good 
    for MIPv6.</FONT> </P>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#0000ff face=Arial 
    size=2>Pro: - The draft doesn't change</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT color=#0000ff 
    face=Arial size=2>con: - Adds another reason for not deploying MIPv6 in 
    cellular</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    systems. </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    - The IPsec problem still stands</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>2.&nbsp; Remove piggybacking 
    ?</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><BR><FONT color=#0000ff 
    face=Arial size=2>&nbsp;&nbsp;&nbsp; pros: - End of this thread (can't wait 
    :))</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
    End of the IPsec problems. IPsec can be used</FONT> <BR><FONT color=#0000ff 
    face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 
    MIPv6 becomes more "cellular friendly"</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; Con: 
    whatever advantages people see for piggybacking </FONT><BR><FONT 
    color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    (in Jari's draft) will disappear. </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>3.&nbsp; Have some negotiation 
    mechanism in MIPv6 between </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; the MN/CN. I'm not sure how this would work 
    yet</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; but I could imagine having something in the 
    Home Address</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; option or the BU option to indicate whether 
    piggybacking </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; should be used or not. </FONT><BR><FONT 
    color=#0000ff face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; If we use the Home 
    address option, we would need to </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; account for the fact that it will not 
    necessarily be secure. </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; Meaning, it can be modified en route. 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; If 
    we use the BU, we will still get some service degradation</FONT> <BR><FONT 
    color=#0000ff face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; for the first BU. 
    </FONT><BR><FONT color=#0000ff face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; 
    Regardless of the chosen method for this option, this </FONT><BR><FONT 
    color=#0000ff face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; new "flag" or 
    "indication" MUST be supported by all </FONT><BR><FONT color=#0000ff 
    face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; MNs and CNs to avoid any service 
    degradation due to </FONT><BR><FONT color=#0000ff face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp; piggybacking. </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>I'd be more inclined to 2 or 3 .... 
    Comments ?</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>Hesham</FONT> 
</P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15B06.274CA3B0--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 11:55:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20835
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 11:55:18 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08978;
	Mon, 22 Oct 2001 08:54:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25555;
	Mon, 22 Oct 2001 08:45:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MFieOI007579
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:44:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MFieoa007578
	for mobile-ip-dist; Mon, 22 Oct 2001 08:44:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MFiaOI007571
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:44:36 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20289
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:44:39 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21420
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:44:38 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9MFieU05990
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 08:44:40 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAP08078;
	Mon, 22 Oct 2001 08:44:08 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA10007; Mon, 22 Oct 2001 08:44:32 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15316.16095.940510.716248@thomasm-u1.cisco.com>
Date: Mon, 22 Oct 2001 08:44:31 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Route optimization method in Mobile IP
In-Reply-To: <20011003210342.2A14.OHNISHI.HIROYUKI@lab.ntt.co.jp>
References: <20011003210342.2A14.OHNISHI.HIROYUKI@lab.ntt.co.jp>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I have some questions about this draft:

1) How is it appreciatively different than HMIP?
   It sure seems to do similar things.

2) How does the MN discover the MBG? This is one
   of the things that last I checked wasn't one of
   HMIP's strong points.

3) The optimal placement of a MGB is at the join point 
   of a particular flow. If, for administrative reason say,
   you can't put the MBG there, it's still better to put
   the MGB as far along the path as possible. For all
   but the simplest topologies, there may be many such
   (close to) optimal points possible, and is clearly
   dependent on the CN you are talking to at any time.
   Have you considered this, or is this strictly static
   the way that HMIP works? 

4) Given the previous, MGB's at a peering point, say, 
   would end up proxying lots of MN's BU's. Can this
   scale? This is similar to the soft state that RSVP
   creates, and there's been a fair amount of concern
   about the scaling which has lead to the RSVP aggregation
   work. I expect that those same kinds of scaling 
   concerns would be relevant here too.
   
5) Related to 3 again, another of HMIP's
   weaknesses is redundancy. It seems to me that
   any scheme like this needs to be able to
   provide failover which is lockstep with the
   routing subsystem. That is, if the route 
   changes, the MN ought to be able to
   transparently discover the new MBR in the 
   path and reestablish the binding.

	  Mike

Hiroyuki OHNISHI writes:
 > Hi all,
 > 
 > We wrote a draft about a route optimization method in Mobile IP.
 > 
 > http://search.ietf.org/internet-drafts/draft-ohnishi-mobileip-mbg-00.txt
 > 
 > This method is proposed from the viewpoint of a career that will provide
 > mobile ip services.
 > To provide mobile ip services, we think route optimization is needed to use network efficiently and reduce data transmission delay.
 > 
 > But existing "Route optimization in Mobile IP" needs all the CNs have to have Mobile IP functions and we have no control over all of the CNs in the Internet. I know this problem can be solved if all CNs become IPv6 nodes
 > (if current problem will be solved).
 > But we think it takes long time before all the CNs become the IPv6 nodes.
 > So we need the some solution to achieve route optimization before all the CNs have not been IPv6 nodes yet.
 > And we also need route optimization method that does not tell CoA to CNs directly for maintaining the location privacy.
 > 
 > In our proposal, we introduce the new Mobile IP agents that are located between a mobile ISP and other networks. This agent is called as MBG (Mobile IP Border Gateway).
 > MBG sends the Binding Requests to HA when it received the packets for MNs. After receiving the Binding Updates from HA, it maintains a binding cache and forwarded following packets directly to CoA of MNs by using the binding caches.
 > These MBGs are fully under the control of mobile ISPs and have security asociations with HAs.
 > So this solution does not suffer from SA issues. We have already had a prototype and had tests.
 > Our hope is to have some solution for route optimization that can be deployed at early time and co-exist with the end-to-end route optimization method for the future Mobile IPv6 deployment time.
 > 
 > I am looking forward to having many comments about this approach for
 > route optimization.
 > 
 > Sincerely,
 > Hiroyuki 
 > 
 > 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 12:16:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21648
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 12:16:37 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23492;
	Mon, 22 Oct 2001 10:16:08 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01931;
	Mon, 22 Oct 2001 09:15:09 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MGEGOI007837
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:14:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MGEGSe007836
	for mobile-ip-dist; Mon, 22 Oct 2001 09:14:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MGECOI007829
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:14:13 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26268
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:14:15 -0700 (PDT)
Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA20382
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 10:13:49 -0600 (MDT)
Message-ID: <20011022161414.48564.qmail@web13905.mail.yahoo.com>
Received: from [216.98.102.225] by web13905.mail.yahoo.com via HTTP; Mon, 22 Oct 2001 09:14:14 PDT
Date: Mon, 22 Oct 2001 09:14:14 -0700 (PDT)
From: James Kempf <kempf42@yahoo.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: <Roam.SIMC.2.0.6.1003740874.29682.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi Erik,

 
> > It is sending a Solicitation. If the access router
> > is not required to authenticate the Solicitation,
> then
> > an unauthorized MN could gain access.
> 
> What do you mean by "access"?
> The MN will receive a Router Advertisement packet,
> but that in itself
> doesn't imply access to anything.
> The RA just carries parameters to the host.
> 

I means "access" in the sense of
draft-ietf-mobileip-ipv6-14.txt. I suppose to be more
generic, one could say last hop router. Default router
is another possibility, but the assumption is that at
this point, the host has not yet chosen a router,
there could be multiple RAs for a particular subnet if
there are multiple last hop routers, so the host
really has
no default yet.

> > In this case, the MN is responding to an
> unsolicited
> > Router Advert by performing address
> autoconfiguration.
> > With stateful address configuration, I would
> assume
> > that DHCP security could be used to determine
> > whether the MN is authorized for an address. So
> > the issue here is that there needs to be some way
> to
> > perform authentication on address
> autoconfiguration
> > messaging.
> 
> Are you concerned that the ability to assign an
> address implicitly
> allows the node to consume network resources?
> Or are you concerned about the node being able to
> prevent others
> from using their (perhaps more legimate) addresses?
> 

Primarily 1. With 1), the host could mount a DOS
attack or steal service once it has a legitimate
address, presuming the last hop router is willing to
co-operate and continue sending traffic. I have some
difficulty seeing that 2) could be a problem. Unless
addresses are in short supply (which should not be a
problem with IPv6), I can't see how one address could
be more legitmate or more valuable than another. Did
you have a particular case in mind?

There is an additional case involving mobility which
may be a problem, I don't know if it has been
discussed. Suppose a MN with a legitimate CoA moves
from one subnet to another and leaves behind a
still-legitimate CoA. An attacker or simply someone
wanting to steal service could start using that
address.
 
> The threats are made worse by computers moving
> around (i.e. the most
> fundamental notion of "mobility") but also by the
> desire
> to provide public access network infrastructure,
> whether in the form
> of Ethernet wires in a hotel or some wireless
> technology.
> Such public access networks could be used e.g. for
> residential
> network access i.e. in cases where mobility isn't
> the key descriminant.
> 

Yes, that's true. Many of these threats  with basic
access are fundamental to any public access network.

> In order to reduce the likely confusion between
> "mobility" and "mobile IP"
> I prefer to attach these types of threats to the
> "public access network"
> term or something similar, since I think that
> captures the essential
> element. 
> 

I think that's an excellent idea. 

                 jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 12:41:52 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22773
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 12:41:51 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02375;
	Mon, 22 Oct 2001 10:41:21 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15802;
	Mon, 22 Oct 2001 09:41:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MGeFOI008002
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:40:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MGeFsn008001
	for mobile-ip-dist; Mon, 22 Oct 2001 09:40:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MGeAOI007994
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:40:10 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08688
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:40:13 -0700 (PDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10641
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 09:40:12 -0700 (PDT)
Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9MGdWB00708;
	Mon, 22 Oct 2001 12:39:32 -0400 (EDT)
Received: from nwsgpa.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA22746; Mon, 22 Oct 2001 11:39:30 -0500 (CDT)
Received: by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2)
	id LAA05870; Mon, 22 Oct 2001 11:39:30 -0500 (CDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15316.19394.203611.988349@nwsgpa.ih.lucent.com>
Date: Mon, 22 Oct 2001 11:39:30 -0500 (CDT)
From: Pete McCann <mccap@lucent.com>
To: Nish Abrol <nabrol@qualcomm.com>
Cc: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com,
        pcalhoun@diameter.org
Subject: [mobile-ip] rfc3012 interpretation question
In-Reply-To: <4.3.1.2.20011015013521.01f7bb30@clea.qualcomm.com>
References: <4.3.1.2.20011015013521.01f7bb30@clea.qualcomm.com>
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi, Nish,

I think the language should be taken literally - you should include as 
much of the Challenge as is available, up to 237 bytes, even if that
includes data that was already used.

I don't know enough about the literature on MD5 to say whether
including a given byte twice weakens the security of the digest, but
offhand I don't see why this is necessarily so.  Note that the
"preceding Mobile IP data" is likely to include the Challenge itself
yet again, which is included as an extension to the Mobile IP message.
In any case, I don't think there is a good argument for going against
the plain wording of the document.

-Pete

Nish Abrol writes:
 > Pat/Charlie and other RFC3012 cognizant folks,
 > 
 > A question regarding the  interpretation of section 8 of rfc3012. This 
 > section specifies how to calculate the MN-AAA authenticator. It says:
 > 
 > " To compute the authenticator, apply MD5 [11] 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 "
 > 
 > The question is - if the challenge has less than 237 bytes - should the 
 > high order byte which was already used in the MD5 calculation  be included 
 > again as part of the  "least-order 237 bytes from Challenge"?
 > 
 > e.g. if the challenge is 50 bytes in length - should the authenticator be 
 > calculated  as:
 >      (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)
 > 
 > or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).
 > 
 >        where byte0 is the most significant byte of the challenge.
 > 
 > A strict reading of the RFC seems to suggest (b). However, it seems  that 
 > calculating the MD5 authenticator with the same information(high order 
 > byte) at different locations of the payload weakens the authenticator.
 > 
 > So, what was the intention of the RFC and how should it be implemented? 
 > Also, do you know if RFC3012 implementations have participated in any 
 > bakeoffs/interops. If so, how have they interpreted this section?
 > 
 > Your help will be really appreciated.
 > 
 > Thanks
 > Nish Abrol
 > Qualcomm, Inc.
 > 
 > 
 > 
 > 
 > <html>
 > Pat/Charlie and other RFC3012 cognizant folks,<br>
 > <br>
 > A question regarding the&nbsp; interpretation of section 8 of rfc3012.
 > This section specifies how to calculate the MN-AAA authenticator. It
 > says:<br>
 > <br>
 > &quot; To compute the authenticator, apply MD5 [11] computed on the<br>
 > following data, in the order shown:<br>
 > <br>
 > High-order byte from Challenge || Key ||<br>
 > MD5(Preceding Mobile IP data ||<br>
 > Type, Subtype (if present), Length, SPI) ||<br>
 > Least-order 237 bytes from Challenge &quot;<br>
 > <br>
 > The question is - if the challenge has less than 237 bytes - should the
 > high order byte which was already used in the MD5 calculation&nbsp; be
 > included again as part of the&nbsp; &quot;least-order 237 bytes from
 > Challenge&quot;?<br>
 > <br>
 > e.g. if the challenge is 50 bytes in length - should the authenticator be
 > calculated&nbsp; as:<br>
 > &nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator = md5(byte0 || key.......||
 > byte1 through byte49)<br>
 > <br>
 > or (b) authenticator = md5(byte0 || key ......|| <u>byte0 </u>through
 > byte49).<br>
 > <br>
 > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the most significant byte
 > of the challenge.<br>
 > <br>
 > A strict reading of the RFC seems to suggest (b). However, it seems&nbsp;
 > that calculating the MD5 authenticator with the same information(high
 > order byte) at different locations of the payload weakens the
 > authenticator.<br>
 > <br>
 > So, what was the intention of the RFC and how should it be implemented?
 > Also, do you know if RFC3012 implementations have participated in any
 > bakeoffs/interops. If so, how have they interpreted this section?<br>
 > <br>
 > Your help will be really appreciated.<br>
 > <br>
 > Thanks<br>
 > Nish Abrol<br>
 > Qualcomm, Inc.<br>
 > <br>
 > <br>
 > <br>
 > <br>
 > </html>


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 15:43:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28077
	for <mobileip-archive@lists.ietf.org>; Mon, 22 Oct 2001 15:43:34 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12143;
	Mon, 22 Oct 2001 13:43:05 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29646;
	Mon, 22 Oct 2001 12:42:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MJblOI008349
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 12:37:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MJblNE008348
	for mobile-ip-dist; Mon, 22 Oct 2001 12:37:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MJbgOI008341
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 12:37:43 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9MJbQq21380;
	Mon, 22 Oct 2001 21:37:26 +0200 (MET DST)
Date: Mon, 22 Oct 2001 21:31:47 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: James Kempf <kempf42@yahoo.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <20011022161414.48564.qmail@web13905.mail.yahoo.com>
Message-ID: <Roam.SIMC.2.0.6.1003779107.21247.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> Primarily 1. With 1), the host could mount a DOS
> attack or steal service once it has a legitimate
> address, presuming the last hop router is willing to
> co-operate and continue sending traffic.

It depends the model for how access control is implemented in the access 
network. One model is that access control is tied only to link-layer
authentication and authorization. Another is that it is done using
something akin to URP. In the latter case it will presumably be possible
to start off with a filter in the access router (or in some L2 device between
the AR and the host) that just allows the host to communicate with the URP 
agent. 
This is just an example to point out that the receipt of a RA doesn't imply
that the host has much of access.

> I have some
> difficulty seeing that 2) could be a problem. Unless
> addresses are in short supply (which should not be a
> problem with IPv6), I can't see how one address could
> be more legitmate or more valuable than another. Did
> you have a particular case in mind?

If a device uses RFC 2461 Duplicate Address Detection there is nothing
to prevent another device on the same multi-access link from responding
to each DAD probe. Hence the first device would not be able to allocate
any IPv6 link-local address. Without this it can't do anything. For instance,
it can't even talk to a DHCP server.

> There is an additional case involving mobility which
> may be a problem, I don't know if it has been
> discussed. Suppose a MN with a legitimate CoA moves
> from one subnet to another and leaves behind a
> still-legitimate CoA. An attacker or simply someone
> wanting to steal service could start using that
> address.

Sure.
And depending on the link layer the attacker might be able steal service
using that CoA even before the MN moves away from the link.
For multi-access links without per host link layer encryption this can be
done by just sending an unsolicited Neighbor Advertisement.

I think the "steal service" i.e. unauthorized use of network
resources fall under the scope of what URP has been talking about.
And other forms of attacks are related to RFC 2461.

Makes me wonder if we could start with a threat analysis for URP
as opposed to trying to do one at the end ...

   Erik



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 18:13:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00785
	for <mobileip-archive@lists.ietf.org>; Mon, 22 Oct 2001 18:13:18 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23144;
	Mon, 22 Oct 2001 15:13:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00550;
	Mon, 22 Oct 2001 15:12:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MMBgOI008630
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 15:11:42 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MMBgMX008629
	for mobile-ip-dist; Mon, 22 Oct 2001 15:11:42 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MMBcOI008622
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 15:11:38 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08484
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 15:11:40 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10330
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 15:11:38 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9MMCAQ00391
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 17:12:10 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56c1ce1a97ac12f255079@davir02nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Mon, 22 Oct 2001 17:11:37 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 22 Oct 2001 17:11:36 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: [mobile-ip] Timeslot requests for IETF 52
Date: Mon, 22 Oct 2001 17:11:29 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCEFA@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Timeslot requests for IETF 52
Thread-Index: AcFbRoPkA6Sc8sbrEdWxFQAAhj/HZA==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 22 Oct 2001 22:11:36.0723 (UTC) FILETIME=[8438AE30:01C15B46]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9MMBcOI008623
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello,

We are now taking requests for timeslots for the Mobile IP WG meeting
at IETF 52. We have requested one long time-slot (2.5 hours) to be
allocated for Mobile IP discussions at the upcoming meeting.
Please note that as usual we will be allocating timeslots to agenda
items that are critical to the Mobile IP WG. 
The primary intent is to use the meeting at SLC to resolve issues that
cannot be resolved over the mailing list.

Requests should contain:
1. I-D name/title
2. Amount of time required
3. Why is this I-D important for the MIP WG?

Regards,
Basavaraj
Phil

NOTE: There are two (2) Internet-Draft Cutoff dates

November 14th: Cutoff for Initial Submissions (new documents)
November 21st: FINAL Internet-Draft Cutoff


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 19:48:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01603
	for <mobileip-archive@lists.ietf.org>; Mon, 22 Oct 2001 19:48:00 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21443;
	Mon, 22 Oct 2001 17:47:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27099;
	Mon, 22 Oct 2001 16:47:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MNknOI008910
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 16:46:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MNkmku008909
	for mobile-ip-dist; Mon, 22 Oct 2001 16:46:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MNkjOI008902
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 16:46:45 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29962
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 16:46:36 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29948
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 16:46:44 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA03406;
	Mon, 22 Oct 2001 16:46:35 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9MNkZ632681;
	Mon, 22 Oct 2001 16:46:35 -0700
X-mProtect:  Mon, 22 Oct 2001 16:46:35 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdTP8mjs; Mon, 22 Oct 2001 16:46:33 PDT
Message-ID: <3BD4AFD9.17C3BB73@iprg.nokia.com>
Date: Mon, 22 Oct 2001 16:46:33 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Hello Hesham,

this is really the issue of carrying IPv6 over certain links.
Piggybacking happens to make use of destination option, that's all. So,
when you characterize not having piggybacking in MIPv6 as "cellular
friendly", you are inevitably referring to how to support destination
options in general. If these links are the first to carry IPv6, it
should be possible to support destination options in arbitrary packets,
don't you think ? [I realize home address option is a destination
option, BTW]. More generally, a link should be able to handle variable
packet sizes. Thus, removing piggybacking should not be an option.

I am in favor of option 1 you mention below. This is in line with
general IP protocol design. Any performance considerations could be
stated in the draft in some form.
For instance, we could state that "..if the BAck does not return after
transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
configurable parameter.

I am willing to live with option 3. As you suggest, in the home address
option, a flag might indicate the MN's intention to piggyback.
I however, don't know how the CN would be able to negate it unless it is
also using the home address option. In any case, if details cannot be
worked out, option 1 is my choice.

I have some more comments in-line below.

Regards,

-Rajeev





"Hesham Soliman (EPA)" wrote:

>
>
>      Hello Rajeev and all,
>
>      > Koodli Rajeev (NRC/MtView) writes:
>
>      >  > This brings back the question of whether destination option
>      must have
>      >  > been specified in the first place because some weird link
>      does not know
>      >  > how to support it! What's the logic in saying IP cannot have
>
>      >  > variable-sized packets because a link would have performance
>      issues?
>      >
>      >    The current BU design is not modular. It claims
>      >    that it did that because of bandwidth/latency
>      >    gains. You have not presented a *single* MAC/PHY
>      >    where that claim can be tested. Here you dodge
>      >    my direct question yet again.
>      >
>
>      Actually, I mentioned previously that the use of [rohc] over
>      cellular is one
>      reference for you. See
>      http://www.ludd.luth.se/users/larsman/rocco and follow
>      the references.
>      Note: use of [rohc] would require support for variable packet
>      sizes on the
>      link (perhaps the same kind of link you are considering).
>
>      => I'm not sure why the discussion has gone towards header
>      compression, but anyway, the point I was raising was that
>      piggybacking can have negative effects on the MN/CN if they
>      are attached to a tight channel. Obviously the channel is tight
>      because it''s expensive so there is a very limited potential
>      of reserving a "just in case" extra BW for piggybacking.
>
>
Rajeev: Since we were discussing a "tight channel", it is likely that
header compression is needed on such links. Hence the discussion on HC.

>
>      Now, I'm not saying ROHC can't handle it, all I was saying is
>      that this "larger" packet will likely take double the time
>      to be sent over the air since it may not fit into one radio
>      frame. If it does, then the end to end delay will be
>      significantly
>      increased (the air link delays are -by far- the largest part
>      of the e2e delay in a cellular environment) and it may be
>      dropped.
>      ROHC is not reallt relevant here.
>
>
Rajeev: chances of a piggybacked packet being large enough that it
creates the problem you mention above is not an issue when you use HC.
In the non-IR states, you already have 40 bytes of gain due to IPv6
compression which is more than the size of a BU. If it is in the
IR state (only when you init or when there is irrepairable failure), the
compressor has to re-establish the context anyway. Thus, using HC on a
tight channel is not only conceivable but also easily handles
piggybacking.



>
>      So the result of the scenario above is a degradation in service.
>      Now we can argue for a long time about whether these links
>      are "IP friendly" and whether we should design IP for
>      these interfaces, but the fact is this is what we have _today_.
>
>      Also BTW these systems are the ones deploying IPv6 first !
>      So we just have to deal with the real case here and try to
>      solve it.
>
>
Rajeev: this is a good reason to get it right in the first place! Don't
strike out piggybacking.


>
>      Unfortunately, we can not assume that the problem can be solved
>      at one end only. So what can we do ?
>
>      1.  Keep piggybacking and just say to the designers of these
>           systems "tough luck". ? Doesn't look good for MIPv6.
>
>              Pro: - The draft doesn't change
>              con: - Adds another reason for not deploying MIPv6 in
>      cellular
>                     systems.
>                   - The IPsec problem still stands
>
>      2.  Remove piggybacking ?
>
>          pros: - End of this thread (can't wait :))
>                  - End of the IPsec problems. IPsec can be used
>                  - MIPv6 becomes more "cellular friendly"
>
>           Con: whatever advantages people see for piggybacking
>                   (in Jari's draft) will disappear.
>
>      3.  Have some negotiation mechanism in MIPv6 between
>           the MN/CN. I'm not sure how this would work yet
>           but I could imagine having something in the Home Address
>           option or the BU option to indicate whether piggybacking
>           should be used or not.
>           If we use the Home address option, we would need to
>           account for the fact that it will not necessarily be secure.
>
>           Meaning, it can be modified en route.
>
>           If we use the BU, we will still get some service degradation
>
>           for the first BU.
>           Regardless of the chosen method for this option, this
>           new "flag" or "indication" MUST be supported by all
>           MNs and CNs to avoid any service degradation due to
>           piggybacking.
>
>      I'd be more inclined to 2 or 3 .... Comments ?
>
>      Hesham
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 21:29:00 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02462
	for <mobileip-archive@lists.ietf.org>; Mon, 22 Oct 2001 21:28:59 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28281;
	Mon, 22 Oct 2001 18:28:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12556;
	Mon, 22 Oct 2001 18:28:51 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N1RtOI009498
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:27:55 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9N1Rtbr009497
	for mobile-ip-dist; Mon, 22 Oct 2001 18:27:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N1RpOI009490
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:27:52 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14570
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:27:53 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01108
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:27:51 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA18143;
	Tue, 23 Oct 2001 11:26:34 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA22372;
	Tue, 23 Oct 2001 11:27:42 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VGPNJG2P>; Tue, 23 Oct 2001 11:27:41 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDD2@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho"
	 <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Tue, 23 Oct 2001 11:27:39 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15B61.E7ACEE70"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15B61.E7ACEE70
Content-Type: text/plain;
	charset="iso-8859-1"


	Hi Rajeev, 

> this is really the issue of carrying IPv6 over certain links.
> Piggybacking happens to make use of destination option, that's all. So,
> when you characterize not having piggybacking in MIPv6 as "cellular
> friendly", you are inevitably referring to how to support destination
> options in general. If these links are the first to carry IPv6, it
> should be possible to support destination options in arbitrary packets,
> don't you think ? 
> 
	=> I don't think you got my point, it doesn't matter what the 
	link "should" be doing. We're not radio link designers and 
	there is an existing reality that we have to deal with. There
	are lots of things that I'd like to see link layers do but that's
	not the issue.

> [I realize home address option is a destination
> option, BTW]. 
> 
	=> A static one in every packet, and is compressed. 

> More generally, a link should be able to handle variable
> packet sizes. Thus, removing piggybacking should not be an option.
> 
	=> Again "should", I'm talking about what they "do", not 
	"should do". 

> I am in favor of option 1 you mention below. This is in line with
> general IP protocol design. Any performance considerations could be
> stated in the draft in some form.
> For instance, we could state that "..if the BAck does not return after
> transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
> a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
> configurable parameter.
> 
	=> I don't think that's a good idea. It shouldn't take a few BUs
	and dropped packets for us to "guess" whether piggybacking 
	is needed or not.
	In fact I don't know why you say it's in line with general IP
protocol
	design ?? Could you explain what that is ? 
	In the Fast Handoffs work for v4 and v6, the design teams have 
	been modifying parts of MIP to -for example- get the AR to 
	start forwarding before receiving a BU, why was this acceptable ?
	Why didin't we just say link layers should be desinged to allow 
	for MIP signalling ?
	Well some of us did, but the WG decided that both philosophies 
	are needed to support existing link layers. BETH is one example. 
	So I don't think your logic is in line with the previous WG
decisions
	on similar topics.


> I am willing to live with option 3. As you suggest, in the home address
> option, a flag might indicate the MN's intention to piggyback.
> I however, don't know how the CN would be able to negate it unless it is
> also using the home address option. 
> 
	=> Well if it happens then it can't be negated.


> >
> >      Actually, I mentioned previously that the use of [rohc] over
> >      cellular is one
> >      reference for you. See
> >      http://www.ludd.luth.se/users/larsman/rocco and follow
> >      the references.
> >      Note: use of [rohc] would require support for variable packet
> >      sizes on the
> >      link (perhaps the same kind of link you are considering).
> >
> >      => I'm not sure why the discussion has gone towards header
> >      compression, but anyway, the point I was raising was that
> >      piggybacking can have negative effects on the MN/CN if they
> >      are attached to a tight channel. Obviously the channel is tight
> >      because it''s expensive so there is a very limited potential
> >      of reserving a "just in case" extra BW for piggybacking.
> >
> >
> Rajeev: Since we were discussing a "tight channel", it is likely that
> header compression is needed on such links. Hence the discussion on HC.
> 
	=> HC was not the issue, tight channels are. 
> >
> >      Now, I'm not saying ROHC can't handle it, all I was saying is
> >      that this "larger" packet will likely take double the time
> >      to be sent over the air since it may not fit into one radio
> >      frame. If it does, then the end to end delay will be
> >      significantly
> >      increased (the air link delays are -by far- the largest part
> >      of the e2e delay in a cellular environment) and it may be
> >      dropped.
> >      ROHC is not reallt relevant here.
> >
> >
> Rajeev: chances of a piggybacked packet being large enough that it
> creates the problem you mention above is not an issue when you use HC.
> In the non-IR states, you already have 40 bytes of gain due to IPv6
> compression which is more than the size of a BU. 
> 
	=> How do you know that the link was not designed with the 
	underlying assumption that header compression is used ?
	Hence no gain ! 

	Hesham

------_=_NextPart_001_01C15B61.E7ACEE70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi Rajeev, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">this is really the issue of carrying =
IPv6 over certain links.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Piggybacking happens to make use of =
destination option, that's all. So,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">when you characterize not having =
piggybacking in MIPv6 as &quot;cellular</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">friendly&quot;, you are inevitably =
referring to how to support destination</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">options in general. If these links =
are the first to carry IPv6, it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should be possible to support =
destination options in arbitrary packets,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">don't you think ?</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; I don't =
think you got my point, it doesn't matter what the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">link =
&quot;should&quot; be doing. We're not radio link designers and </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">there is an =
existing reality that we have to deal with. There</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">are lots of things =
that I'd like to see link layers do but that's</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">not the =
issue.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">[I realize home address option is a =
destination</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">option, BTW].</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; A static one =
in every packet, and is compressed. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">More generally, a link should be able =
to handle variable</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">packet sizes. Thus, removing =
piggybacking should not be an option.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Again =
&quot;should&quot;, I'm talking about what they &quot;do&quot;, not =
</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&quot;should =
do&quot;. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am in favor of option 1 you mention =
below. This is in line with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">general IP protocol design. Any =
performance considerations could be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">stated in the draft in some =
form.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">For instance, we could state that =
&quot;..if the BAck does not return after</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">transmitting a Binding Update =
BU_PIGGY_TIMES, the sending node must send</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a BU without piggybacking&quot;. =
BU_PIGGY_TIMES, a non-zero integer, is a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">configurable parameter.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; I don't =
think that's a good idea. It shouldn't take a few BUs</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">and dropped packets =
for us to &quot;guess&quot; whether piggybacking </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is needed or =
not.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In fact I don't =
know why you say it's in line with general IP protocol</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">design ?? Could you =
explain what that is ? </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In the Fast =
Handoffs work for v4 and v6, the design teams have </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">been modifying =
parts of MIP to -for example- get the AR to </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">start forwarding =
before receiving a BU, why was this acceptable ?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Why didin't we just =
say link layers should be desinged to allow </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">for MIP signalling =
?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Well some of us =
did, but the WG decided that both philosophies </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">are needed to =
support existing link layers. BETH is one example. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So I don't think =
your logic is in line with the previous WG decisions</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">on similar =
topics.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am willing to live with option 3. As =
you suggest, in the home address</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">option, a flag might indicate the =
MN's intention to piggyback.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I however, don't know how the CN =
would be able to negate it unless it is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">also using the home address =
option</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Well if it =
happens then it can't be negated.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Actually, I mentioned previously that the use of [rohc] over</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
cellular is one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
reference for you. See</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ludd.luth.se/users/larsman/rocco" =
TARGET=3D"_blank">http://www.ludd.luth.se/users/larsman/rocco</A></FONT>=
</U><FONT SIZE=3D2 FACE=3D"Arial"> and follow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the references.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Note: use of [rohc] would require support for variable packet</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sizes on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
link (perhaps the same kind of link you are considering).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D&gt; I'm not sure why the discussion has gone towards header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
compression, but anyway, the point I was raising was that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
piggybacking can have negative effects on the MN/CN if they</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
are attached to a tight channel. Obviously the channel is tight</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
because it''s expensive so there is a very limited potential</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
reserving a &quot;just in case&quot; extra BW for piggybacking.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Rajeev: Since we were discussing a =
&quot;tight channel&quot;, it is likely that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">header compression is needed on such =
links. Hence the discussion on HC.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; HC was not =
the issue, tight channels are.</FONT>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Now, I'm not saying ROHC can't handle it, all I was saying is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
that this &quot;larger&quot; packet will likely take double the =
time</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
be sent over the air since it may not fit into one radio</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
frame. If it does, then the end to end delay will be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
significantly</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
increased (the air link delays are -by far- the largest part</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
the e2e delay in a cellular environment) and it may be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
dropped.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ROHC is not reallt relevant here.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Rajeev: chances of a piggybacked =
packet being large enough that it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">creates the problem you mention above =
is not an issue when you use HC.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">In the non-IR states, you already =
have 40 bytes of gain due to IPv6</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">compression which is more than the =
size of a BU.</FONT>=20
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; How do you =
know that the link was not designed with the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">underlying =
assumption that header compression is used ?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hence no gain ! =
</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15B61.E7ACEE70--


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 22 21:50:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03624
	for <mobileip-archive@odin.ietf.org>; Mon, 22 Oct 2001 21:50:16 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21992;
	Mon, 22 Oct 2001 19:49:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20541;
	Mon, 22 Oct 2001 18:50:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N1n5OI009614
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:49:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9N1n5MA009613
	for mobile-ip-dist; Mon, 22 Oct 2001 18:49:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N1n2OI009606
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:49:02 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15040
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:49:04 -0700 (PDT)
Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07856
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 22 Oct 2001 18:49:02 -0700 (PDT)
Received: from kapow.its.monash.edu.au ([130.194.1.71])
 by vaxc.cc.monash.edu.au (PMDF V6.1 #39306)
 with ESMTP id <01K9U88T76J8AAV8TA@vaxc.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Tue, 23 Oct 2001 11:47:54 +1000
Received: from localhost (localhost [127.0.0.1])	by kapow.its.monash.edu.au
 (Postfix) with ESMTP	id 96C072DC02E; Tue, 23 Oct 2001 11:47:12 +1000 (EST)
Received: from eng.monash.edu.au
 (PC00004790.eng.monash.edu.au [130.194.137.189])	by kapow.its.monash.edu.au
 (Postfix) with ESMTP	id 789DD2DC013; Tue, 23 Oct 2001 11:47:10 +1000 (EST)
Date: Tue, 23 Oct 2001 11:52:29 +1000
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
To: mobile-ip@sunroof.eng.sun.com
Cc: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Message-id: <3BD4CD5D.2D7293EF@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-Virus-Scanned: by AMaViS perl-11
References: 
 <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se>
 <3BD4AFD9.17C3BB73@iprg.nokia.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
GD: Comment below:
Content-Transfer-Encoding: 7BIT

Rajeev Koodli wrote:
> 
> Hello Hesham,
> 
> this is really the issue of carrying IPv6 over certain links.
> Piggybacking happens to make use of destination option, that's all. So,
> when you characterize not having piggybacking in MIPv6 as "cellular
> friendly", you are inevitably referring to how to support destination
> options in general. If these links are the first to carry IPv6, it
> should be possible to support destination options in arbitrary packets,
> don't you think ? [I realize home address option is a destination
> option, BTW]. More generally, a link should be able to handle variable
> packet sizes. Thus, removing piggybacking should not be an option.
> 
> I am in favor of option 1 you mention below. This is in line with
> general IP protocol design. Any performance considerations could be
> stated in the draft in some form.
> For instance, we could state that "..if the BAck does not return after
> transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
> a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
> configurable parameter.
[GD: chop to option 1]
> >      1.  Keep piggybacking and just say to the designers of these
> >           systems "tough luck". ? Doesn't look good for MIPv6.
> >
> >              Pro: - The draft doesn't change
> >              con: - Adds another reason for not deploying MIPv6 in
> >      cellular
> >                     systems.
> >                   - The IPsec problem still stands
> >	

	For Option 1 this could neatly restate the entire sent piggyback
	mechanism by saying that BU_PIGGY_TIMES is a Non-negative integer.

	Configuring BU_PIGGY_TIMES to 0 would mean:
	'do not wait for BAck timeouts, send a separate datagram'

	coupled with the mechanism: Only send a piggybacked BAck if
	a piggybacked Binding Update is received, it would guarantee
	compliance of BU and Back with a particular bandwidth constrained
	medium adjacent to the MN.

	
		Greg Daley


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 04:55:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24084
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 04:55:32 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26669;
	Tue, 23 Oct 2001 02:54:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02094;
	Tue, 23 Oct 2001 01:55:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N8sDOI010070
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 01:54:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9N8sDBP010069
	for mobile-ip-dist; Tue, 23 Oct 2001 01:54:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N8s9OI010062
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 01:54:09 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06378
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 01:54:04 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25940
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 02:53:44 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id DAA23361
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 03:54:08 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 23 Oct 2001 03:52:21 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <SK3L7RM3>; Tue, 23 Oct 2001 03:53:32 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF4E7@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        Nish Abrol <nabrol@qualcomm.com>
Subject: RE: [mobile-ip] rfc3012 interpretation question
Date: Tue, 23 Oct 2001 03:53:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15BA0.2F8D7820"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15BA0.2F8D7820
Content-Type: text/plain;
	charset="iso-8859-1"


A close look at the payload used to calculate the MN-AAA Authenticator shows
the following:
1. The CHALLENGE value is used ONCE as the High-Order byte being byte 0 of
the payload and the Least-Order 237 bytes of challenge being the last bytes
of the payload.
2. The fact that the MN-FA challenge extension was passed to the INNER MD5
as part of the preceding MIP data is irrelevant since what is passed to the
OUTER MD5, used in calculating the MN-AAA authenticator, is JUST a digital
signature or in other words a RANDOM NUMBER.

Regards;

Ahmad Muhanna


-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: Monday, October 22, 2001 11:40 AM
To: Nish Abrol
Cc: mobile-ip@sunroof.eng.sun.com; charliep@iprg.nokia.com;
pcalhoun@diameter.org
Subject: [mobile-ip] rfc3012 interpretation question


Hi, Nish,

I think the language should be taken literally - you should include as 
much of the Challenge as is available, up to 237 bytes, even if that
includes data that was already used.

I don't know enough about the literature on MD5 to say whether
including a given byte twice weakens the security of the digest, but
offhand I don't see why this is necessarily so.  Note that the
"preceding Mobile IP data" is likely to include the Challenge itself
yet again, which is included as an extension to the Mobile IP message.
In any case, I don't think there is a good argument for going against
the plain wording of the document.

-Pete

Nish Abrol writes:
 > Pat/Charlie and other RFC3012 cognizant folks,
 > 
 > A question regarding the  interpretation of section 8 of rfc3012. This 
 > section specifies how to calculate the MN-AAA authenticator. It says:
 > 
 > " To compute the authenticator, apply MD5 [11] 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 "
 > 
 > The question is - if the challenge has less than 237 bytes - should the 
 > high order byte which was already used in the MD5 calculation  be
included 
 > again as part of the  "least-order 237 bytes from Challenge"?
 > 
 > e.g. if the challenge is 50 bytes in length - should the authenticator be

 > calculated  as:
 >      (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49)
 > 
 > or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49).
 > 
 >        where byte0 is the most significant byte of the challenge.
 > 
 > A strict reading of the RFC seems to suggest (b). However, it seems  that

 > calculating the MD5 authenticator with the same information(high order 
 > byte) at different locations of the payload weakens the authenticator.
 > 
 > So, what was the intention of the RFC and how should it be implemented? 
 > Also, do you know if RFC3012 implementations have participated in any 
 > bakeoffs/interops. If so, how have they interpreted this section?
 > 
 > Your help will be really appreciated.
 > 
 > Thanks
 > Nish Abrol
 > Qualcomm, Inc.
 > 
 > 
 > 
 > 
 > <html>
 > Pat/Charlie and other RFC3012 cognizant folks,<br>
 > <br>
 > A question regarding the&nbsp; interpretation of section 8 of rfc3012.
 > This section specifies how to calculate the MN-AAA authenticator. It
 > says:<br>
 > <br>
 > &quot; To compute the authenticator, apply MD5 [11] computed on the<br>
 > following data, in the order shown:<br>
 > <br>
 > High-order byte from Challenge || Key ||<br>
 > MD5(Preceding Mobile IP data ||<br>
 > Type, Subtype (if present), Length, SPI) ||<br>
 > Least-order 237 bytes from Challenge &quot;<br>
 > <br>
 > The question is - if the challenge has less than 237 bytes - should the
 > high order byte which was already used in the MD5 calculation&nbsp; be
 > included again as part of the&nbsp; &quot;least-order 237 bytes from
 > Challenge&quot;?<br>
 > <br>
 > e.g. if the challenge is 50 bytes in length - should the authenticator be
 > calculated&nbsp; as:<br>
 > &nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator = md5(byte0 || key.......||
 > byte1 through byte49)<br>
 > <br>
 > or (b) authenticator = md5(byte0 || key ......|| <u>byte0 </u>through
 > byte49).<br>
 > <br>
 > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the most significant byte
 > of the challenge.<br>
 > <br>
 > A strict reading of the RFC seems to suggest (b). However, it seems&nbsp;
 > that calculating the MD5 authenticator with the same information(high
 > order byte) at different locations of the payload weakens the
 > authenticator.<br>
 > <br>
 > So, what was the intention of the RFC and how should it be implemented?
 > Also, do you know if RFC3012 implementations have participated in any
 > bakeoffs/interops. If so, how have they interpreted this section?<br>
 > <br>
 > Your help will be really appreciated.<br>
 > <br>
 > Thanks<br>
 > Nish Abrol<br>
 > Qualcomm, Inc.<br>
 > <br>
 > <br>
 > <br>
 > <br>
 > </html>

------_=_NextPart_001_01C15BA0.2F8D7820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] rfc3012 interpretation question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">A close look at the payload used to =
calculate the MN-AAA Authenticator shows the following:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1. The CHALLENGE value is used<B> =
ONCE</B> as the<B> High-Order byte</B> being byte 0 of the payload and =
the<B> Least-Order 237 bytes of challenge</B> being the last bytes of =
the payload.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. The fact that the</FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">MN-FA</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">challenge</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">extension</FONT> <FONT SIZE=3D2 FACE=3D"Arial">was =
passed to the</FONT><B> <FONT SIZE=3D2 FACE=3D"Arial">INNER =
MD5</FONT></B> <FONT SIZE=3D2 FACE=3D"Arial">as part of the preceding =
MIP data</FONT> <FONT SIZE=3D2 FACE=3D"Arial">is irrelevant since what =
is passed to the</FONT><B></B><B> <FONT SIZE=3D2 =
FACE=3D"Arial">OUTER</FONT><FONT SIZE=3D2 FACE=3D"Arial"> =
MD5</FONT><FONT SIZE=3D2 FACE=3D"Arial">,</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"> used in calculating the MN-AAA =
authenticator</FONT><FONT SIZE=3D2 FACE=3D"Arial">,</FONT><FONT =
SIZE=3D2 FACE=3D"Arial"> is JUST a digital signature or in other words =
a RANDOM NUMBER.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Pete McCann [<A =
HREF=3D"mailto:mccap@lucent.com">mailto:mccap@lucent.com</A>]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Monday, October 22, 2001 11:40 =
AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Nish Abrol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: mobile-ip@sunroof.eng.sun.com; =
charliep@iprg.nokia.com;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: [mobile-ip] rfc3012 =
interpretation question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi, Nish,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think the language should be taken =
literally - you should include as </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">much of the Challenge as is =
available, up to 237 bytes, even if that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">includes data that was already =
used.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't know enough about the =
literature on MD5 to say whether</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">including a given byte twice weakens =
the security of the digest, but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">offhand I don't see why this is =
necessarily so.&nbsp; Note that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;preceding Mobile IP data&quot; =
is likely to include the Challenge itself</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">yet again, which is included as an =
extension to the Mobile IP message.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">In any case, I don't think there is a =
good argument for going against</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the plain wording of the =
document.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Pete</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Nish Abrol writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Pat/Charlie and other =
RFC3012 cognizant folks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; A question regarding =
the&nbsp; interpretation of section 8 of rfc3012. This </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; section specifies how to =
calculate the MN-AAA authenticator. It says:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &quot; To compute the =
authenticator, apply MD5 [11] computed on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; following data, in the =
order shown:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; High-order byte from =
Challenge || Key ||</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; MD5(Preceding Mobile IP =
data ||</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Type, Subtype (if =
present), Length, SPI) ||</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Least-order 237 bytes from =
Challenge &quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The question is - if the =
challenge has less than 237 bytes - should the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; high order byte which was =
already used in the MD5 calculation&nbsp; be included </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; again as part of the&nbsp; =
&quot;least-order 237 bytes from Challenge&quot;?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; e.g. if the challenge is =
50 bytes in length - should the authenticator be </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; calculated&nbsp; =
as:</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; =
authenicator =3D md5(byte0 || key.......|| byte1 through byte49)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; or (b) authenticator =3D =
md5(byte0 || key ......|| byte0 through byte49).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
where byte0 is the most significant byte of the challenge.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; A strict reading of the =
RFC seems to suggest (b). However, it seems&nbsp; that </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; calculating the MD5 =
authenticator with the same information(high order </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; byte) at different =
locations of the payload weakens the authenticator.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; So, what was the intention =
of the RFC and how should it be implemented? </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Also, do you know if =
RFC3012 implementations have participated in any </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; bakeoffs/interops. If so, =
how have they interpreted this section?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Your help will be really =
appreciated.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Thanks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Nish Abrol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Qualcomm, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;html&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Pat/Charlie and other =
RFC3012 cognizant folks,&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; A question regarding =
the&amp;nbsp; interpretation of section 8 of rfc3012.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; This section specifies how =
to calculate the MN-AAA authenticator. It</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; says:&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &amp;quot; To compute the =
authenticator, apply MD5 [11] computed on the&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; following data, in the =
order shown:&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; High-order byte from =
Challenge || Key ||&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; MD5(Preceding Mobile IP =
data ||&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Type, Subtype (if =
present), Length, SPI) ||&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Least-order 237 bytes from =
Challenge &amp;quot;&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The question is - if the =
challenge has less than 237 bytes - should the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; high order byte which was =
already used in the MD5 calculation&amp;nbsp; be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; included again as part of =
the&amp;nbsp; &amp;quot;least-order 237 bytes from</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; =
Challenge&amp;quot;?&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; e.g. if the challenge is =
50 bytes in length - should the authenticator be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; calculated&amp;nbsp; =
as:&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; =
&amp;nbsp;&amp;nbsp;&amp;nbsp; (a)&amp;nbsp; authenicator =3D md5(byte0 =
|| key.......||</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; byte1 through =
byte49)&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; or (b) authenticator =3D =
md5(byte0 || key ......|| &lt;u&gt;byte0 &lt;/u&gt;through</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; byte49).&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; =
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; where byte0 is the =
most significant byte</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; of the =
challenge.&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; A strict reading of the =
RFC seems to suggest (b). However, it seems&amp;nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; that calculating the MD5 =
authenticator with the same information(high</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; order byte) at different =
locations of the payload weakens the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; =
authenticator.&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; So, what was the intention =
of the RFC and how should it be implemented?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Also, do you know if =
RFC3012 implementations have participated in any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; bakeoffs/interops. If so, =
how have they interpreted this section?&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Your help will be really =
appreciated.&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Thanks&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Nish =
Abrol&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Qualcomm, =
Inc.&lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;br&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &lt;/html&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15BA0.2F8D7820--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 06:59:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25323
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 06:59:37 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06949;
	Tue, 23 Oct 2001 03:59:27 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19201;
	Tue, 23 Oct 2001 03:59:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NAwAOI010716
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 03:58:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NAwAEU010715
	for mobile-ip-dist; Tue, 23 Oct 2001 03:58:10 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NAw6OI010708
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 03:58:06 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17339
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 03:58:08 -0700 (PDT)
Received: from telecom.samsung.co.kr ([165.213.221.4])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01186
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 05:02:03 -0600 (MDT)
Received: from metro (a22414 [165.213.224.14])
	by telecom.samsung.co.kr (8.11.6/8.11.6) with SMTP id f9NArt500766;
	Tue, 23 Oct 2001 19:53:55 +0900 (KST)
Message-ID: <001c01c15bb1$d745cf20$0ee0d5a5@telecom.samsung.co.kr>
From: "junhyuk song" <junhyuk@metro.telecom.samsung.co.kr>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <tsgp@3gpp2.org>
Subject: [mobile-ip] NEW Internet Draft
Date: Tue, 23 Oct 2001 19:59:50 +0900
Organization: cdma2000 system
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9NAw6OI010709
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hi all,

There are two new Internet Draft are avilable, defining "IP user Mobility support" 
It can be accessable at below URL

http://www.ietf.org/internet-drafts/draft-song-mobileip-mipv6-user-mobility-01.txt
http://www.ietf.org/internet-drafts/draft-song-network-user-mobility-00.txt

Both Internet Drafts are defining IP user Mobility.
Especially, "draft-song-mobileip-mipv6-user-mobility-01.txt", is specifying IP user mobility support using MIPv6, while providing semi-secure binding update message using DNS.

Also, there is also another Internet Draft is available at PPPext group
http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-ppp-support-01.txt

This is defining the MIPv6 PPP IPCP option.


Thanks,
JH SONG


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 07:03:59 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25732
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 07:03:59 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04543;
	Tue, 23 Oct 2001 05:03:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19669;
	Tue, 23 Oct 2001 04:03:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NB3BOI010800
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 04:03:11 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NB3Bci010799
	for mobile-ip-dist; Tue, 23 Oct 2001 04:03:11 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NB37OI010792
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 04:03:07 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18358
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 04:03:00 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22252
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 04:03:08 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25558;
	Tue, 23 Oct 2001 07:03:04 -0400 (EDT)
Message-Id: <200110231103.HAA25558@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: mobile-ip@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Subject: [mobile-ip] I-D ACTION:draft-song-mobileip-mipv6-user-mobility-01.txt
Date: Tue, 23 Oct 2001 07:03:04 -0400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: MIPv6 IP User mobility support through DNS
	Author(s)	: J. Song, C. Chong, D. Lee
	Filename	: draft-song-mobileip-mipv6-user-mobility-01.txt
	Pages		: 8
	Date		: 22-Oct-01
	
The Mobile IP can provide IP mobility. The mobile node identified by 
its Home Address can have transparent home IP routing service 
regardless of attaching point.  However the need for the user 
mobility support has identified by wireless operators so as to 
provide IP routing service, based on the user identifier not based on 
home IP address.  This document specifies the user mobility support 
for Mobile IPv6 through DNS, while providing semi-secure binding 
update mechanism for the route optimization between MN and CN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-song-mobileip-mipv6-user-mobility-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-song-mobileip-mipv6-user-mobility-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-song-mobileip-mipv6-user-mobility-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:	<20011022135649.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-song-mobileip-mipv6-user-mobility-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-song-mobileip-mipv6-user-mobility-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 09:49:35 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02234
	for <mobileip-archive@lists.ietf.org>; Tue, 23 Oct 2001 09:49:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01291;
	Tue, 23 Oct 2001 06:49:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05997;
	Tue, 23 Oct 2001 06:49:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NDkpOI011189
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 06:46:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NDkofV011188
	for mobile-ip-dist; Tue, 23 Oct 2001 06:46:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NDklOI011181
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 06:46:47 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06563
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 06:46:41 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20515
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 06:46:50 -0700 (PDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9NDl4m04297
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 06:47:04 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (dhcp-wall-59-79.cisco.com [171.68.59.79])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABF09187;
	Tue, 23 Oct 2001 06:46:49 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011023093925.00b95a78@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 23 Oct 2001 09:44:48 -0400
To: mobile-ip@sunroof.eng.sun.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <3BD4CD5D.2D7293EF@eng.monash.edu.au>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se>
 <3BD4AFD9.17C3BB73@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

At 11:52 AM 10/23/2001 +1000, Greg Daley wrote:

<snip>


>         coupled with the mechanism: Only send a piggybacked BAck if
>         a piggybacked Binding Update is received, it would guarantee
>         compliance of BU and Back with a particular bandwidth constrained
>         medium adjacent to the MN.

Humm ... sounds like you are assuming a symmetrical link to the MN.

A lot of access technologies have a scarce bandwidth resource requiring
special treatment of real-time packets in only one direction (e.g., cable
access systems and some non-cellular wireless access).

>
>                 Greg Daley


Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 10:16:58 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03951
	for <mobileip-archive@lists.ietf.org>; Tue, 23 Oct 2001 10:16:57 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13953;
	Tue, 23 Oct 2001 07:16:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11365;
	Tue, 23 Oct 2001 07:16:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NEDYOI011329
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 07:13:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NEDYaC011328
	for mobile-ip-dist; Tue, 23 Oct 2001 07:13:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NEDUOI011321
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 07:13:30 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06708
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 07:13:28 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03468
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 08:13:02 -0600 (MDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA15305
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:13:27 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9NEDRD26734
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:13:27 -0500 (CDT)
Message-ID: <3BD56B9F.C051788E@alcatel.com>
Date: Tue, 23 Oct 2001 09:07:43 -0400
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------DACA9AC0362BE5130A1742D1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------DACA9AC0362BE5130A1742D1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Hesham,
  If you can work out the details I think that your point 2 certainly is
the right choice.
Keep up the good work.

"Hesham Soliman (EPA)" wrote:

>
>
>      1.  Keep piggybacking and just say to the designers of these
>           systems "tough luck". ? Doesn't look good for MIPv6.
>
>              Pro: - The draft doesn't change
>              con: - Adds another reason for not deploying MIPv6 in
>      cellular
>                     systems.
>                   - The IPsec problem still stands
>
>      2.  Remove piggybacking ?
>
>          pros: - End of this thread (can't wait :))
>                  - End of the IPsec problems. IPsec can be used
>                  - MIPv6 becomes more "cellular friendly"
>
>           Con: whatever advantages people see for piggybacking
>                   (in Jari's draft) will disappear.
>
>      3.  Have some negotiation mechanism in MIPv6 between
>           the MN/CN. I'm not sure how this would work yet
>           but I could imagine having something in the Home Address
>           option or the BU option to indicate whether piggybacking
>           should be used or not.
>           If we use the Home address option, we would need to
>           account for the fact that it will not necessarily be secure.
>
>           Meaning, it can be modified en route.
>
>           If we use the BU, we will still get some service degradation
>
>           for the first BU.
>           Regardless of the chosen method for this option, this
>           new "flag" or "indication" MUST be supported by all
>           MNs and CNs to avoid any service degradation due to
>           piggybacking.
>
>      I'd be more inclined to 2 or 3 .... Comments ?
>
>      Hesham
>

Regards,

--
Behcet

--------------DACA9AC0362BE5130A1742D1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Hesham,
<br>&nbsp; If you can work out the details I think that your point 2 certainly
is the right choice.
<br>Keep up the good work.
<p>"Hesham Soliman (EPA)" wrote:
<blockquote TYPE=CITE>
<ul><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>1.&nbsp; Keep
piggybacking and just say to the designers of these</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
systems "tough luck". ? Doesn't look good for MIPv6.</font></font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font color="#0000FF"><font size=-1>Pro:
- The draft doesn't change</font></font></font>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font color="#0000FF"><font size=-1>con:
- Adds another reason for not deploying MIPv6 in cellular</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
systems.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- The IPsec problem still stands</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>2.&nbsp; Remove
piggybacking ?</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;
pros: - End of this thread (can't wait :))</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- End of the IPsec problems. IPsec can be used</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- MIPv6 becomes more "cellular friendly"</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
Con: whatever advantages people see for piggybacking</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(in Jari's draft) will disappear.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>3.&nbsp; Have
some negotiation mechanism in MIPv6 between</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
the MN/CN. I'm not sure how this would work yet</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
but I could imagine having something in the Home Address</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
option or the BU option to indicate whether piggybacking</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
should be used or not.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
If we use the Home address option, we would need to</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
account for the fact that it will not necessarily be secure.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
Meaning, it can be modified en route.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
If we use the BU, we will still get some service degradation</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
for the first BU.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
Regardless of the chosen method for this option, this</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
new "flag" or "indication" MUST be supported by all</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
MNs and CNs to avoid any service degradation due to</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;
piggybacking.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>I'd be more inclined
to 2 or 3 .... Comments ?</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>Hesham</font></font></font></ul>
</blockquote>

<p><br>Regards,
<p>--
<br>Behcet</html>

--------------DACA9AC0362BE5130A1742D1--



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 11:32:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07774
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 11:32:46 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24717;
	Tue, 23 Oct 2001 08:32:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21274;
	Tue, 23 Oct 2001 08:32:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NFVJOI011642
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 08:31:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NFVJpU011641
	for mobile-ip-dist; Tue, 23 Oct 2001 08:31:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NFVFOI011634
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 08:31:15 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9NFV4q28152;
	Tue, 23 Oct 2001 17:31:05 +0200 (MET DST)
Date: Tue, 23 Oct 2001 17:25:25 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
To: Jari.Arkko@ericsson.com
Cc: mobile-ip@sunroof.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.1003850725.8873.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

The abstract to the draft says
     The Mobile IP working group is  currently  searching  for  a  security
     solution  that  enables  semi-secure, weak authentication between IPv6
     Mobile Nodes and Correspondent Nodes in the the global Internet.  Sub-
     sequent  Binding  Updates  messages  will  then  be  cryptographically
     integrity protected to prevent abuse of the mechanisms for route opti-
     mization.   

I don't recall seeing a requirement that all but the first BU be 
cryptographically protected. Is there such a requirement?

I was thinking that a possible "corner" in the design and solution space
was a mechanism that makes each binding update be done through a 3-way
handshake i.e. the return routability property is verified for each
BU. Folks might argue about the performance and performance tradeoffs for
such an approach - but I think it at least make sense to consider such
an approach.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 12:14:24 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09566
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 12:14:24 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17143;
	Tue, 23 Oct 2001 09:14:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14594;
	Tue, 23 Oct 2001 09:14:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGDCOI011772
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:13:12 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NGDC9A011771
	for mobile-ip-dist; Tue, 23 Oct 2001 09:13:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGD7OI011764
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:13:08 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04389
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:13:10 -0700 (PDT)
Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00377
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 10:13:09 -0600 (MDT)
Received: from jariws1 ([62.248.238.80]) by fep06-app.kolumbus.fi
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP
          id <20011023161307.NRQP1726.fep06-app.kolumbus.fi@jariws1>;
          Tue, 23 Oct 2001 19:13:07 +0300
Message-ID: <003201c15bdd$9c4bd500$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: <mobile-ip@sunroof.eng.sun.com>, <Jari.Arkko@ericsson.com>
Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
References: <Roam.SIMC.2.0.6.1003850725.8873.nordmark@bebop.france>
Subject: Re: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
Date: Tue, 23 Oct 2001 19:13:06 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> The abstract to the draft says
>      The Mobile IP working group is  currently  searching  for  a  security
>      solution  that  enables  semi-secure, weak authentication between IPv6
>      Mobile Nodes and Correspondent Nodes in the the global Internet.  Sub-
>      sequent  Binding  Updates  messages  will  then  be  cryptographically
>      integrity protected to prevent abuse of the mechanisms for route opti-
>      mization.   
> 
> I don't recall seeing a requirement that all but the first BU be 
> cryptographically protected. Is there such a requirement?

The intention was to say that e.g. a BAKE authentication takes
place and creates an SA, and then all BUs will be protected by
this SA. The first BU should of course be included in this protection

> I was thinking that a possible "corner" in the design and solution space
> was a mechanism that makes each binding update be done through a 3-way
> handshake i.e. the return routability property is verified for each
> BU. Folks might argue about the performance and performance tradeoffs for
> such an approach - but I think it at least make sense to consider such
> an approach.

This is indeed an important issue. Somewhere in the draft I think
I mentioned that we must first decide whether we want this authentication - SA
model. It has been proposed that each BU could perform the authentication,
and then no SA would be needed. Looking at the proposals, this produces
typically a 3-message BU rather than just a single BU. OTOH, if you don't
have long-lasting CN-MN relationships, you are bound to get this anyway.

It is important to realize that the authentication - SA model is just an
*optimization*. That is, it brings no added functionality beyond reducing
the number of messages. Most people that I've talked to seem to feel
that the optimization is a necessary one, though.

It is interesting to note that if the WG decides to adopt the authentication-only
model then there'd be an easy conclusion to the -14 vs. ah discussion: neither
option would be needed!

Another interesting note is that if we pick solution 6.4 then this could live
with the authentication-only solution in the global Internet (with 3 messages
per BU), and where local PKI is available this could be reduced to ipsec-only
(with 1 message per BU).

Question: how useful will route optimization be, if every movement must be
announced by three messages, not one?

Jari






From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 12:24:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10002
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 12:24:08 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11805;
	Tue, 23 Oct 2001 10:24:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17518;
	Tue, 23 Oct 2001 09:23:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGMsOI011870
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:22:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NGMsk7011869
	for mobile-ip-dist; Tue, 23 Oct 2001 09:22:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGMoOI011862
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:22:50 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03550
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:22:53 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA19865
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:22:53 -0700 (PDT)
Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.15665-0@bells.cs.ucl.ac.uk>; Tue, 23 Oct 2001 17:22:50 +0100
Message-ID: <3BD59958.18612698@cs.ucl.ac.uk>
Date: Tue, 23 Oct 2001 17:22:48 +0100
From: Theo Pagtzis <t.pagtzis@cs.ucl.ac.uk>
Organization: UCL/Mobile Systems Group
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E5548FB@zrc2c012.us.nortel.com> <3BC48542.76ED17CE@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi all,

  could I just ask again about the router advertisment interval. Is it
really intended to be a minimum of

0.05 seconds or 0.5 seconds?

thanks

Theo
UCL/Mobile Systems

"Charles E. Perkins" wrote:
> 
> Hello Glenn,
> 
> > Besides route optimized MIPv6 will never be ubiquitous anyway as long as the
> > binding update processing by CN's is only a SHOULD. The MN and HA will always
> > have to be complicated by back-off procedures to forward stream tunnel
> > mechanisms.
> 
> I think it's too late by more than a year to change this from
> a SHOULD to a MUST.  And, anyway, we can hope that by the time
> we're pushing multiple billions of IPv6 nodes, the benefits of
> routing directly to the care-of address are obvious enough, and
> the code well enough understood.  Then naturally, most nodes
> will process Binding Updates.
> 
> > In my opinion removing this complication is more important than removing the
> > piggyback complication for specific access technologies and compression
> > mechanisms.
> >
> > I would rather see the group focus on making the route optimized mobility
> > ubiquitous and removing the complications of it not being.
> 
> The complications of using Destination Options with payload are all
> on the sending side.  The receivers implementation is very natural.
> That's why it makes very much sense to me, to leave it as a possible
> option for _senders_ that want to maximize the performance of their
> communications.
> 
> Regards,
> Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 12:50:54 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11023
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 12:50:54 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06908;
	Tue, 23 Oct 2001 09:50:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13534;
	Tue, 23 Oct 2001 09:50:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGn5OI011973
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:49:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NGn4eW011972
	for mobile-ip-dist; Tue, 23 Oct 2001 09:49:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGn0OI011965
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:49:00 -0700 (PDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9NGmgq07370;
	Tue, 23 Oct 2001 18:48:42 +0200 (MET DST)
Date: Tue, 23 Oct 2001 18:42:53 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
To: jari.arkko@kolumbus.fi
Cc: mobile-ip@sunroof.eng.sun.com, Jari.Arkko@ericsson.com,
        Erik Nordmark <Erik.Nordmark@eng.sun.com>
In-Reply-To: "Your message with ID" <003201c15bdd$9c4bd500$8a1b6e0a@arenanet.fi>
Message-ID: <Roam.SIMC.2.0.6.1003855373.12071.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> This is indeed an important issue. Somewhere in the draft I think
> I mentioned that we must first decide whether we want this authentication -
> SA model. It has been proposed that each BU could perform the authentication,
> and then no SA would be needed. Looking at the proposals, this produces
> typically a 3-message BU rather than just a single BU. OTOH, if you don't
> have long-lasting CN-MN relationships, you are bound to get this anyway.

Yep. And a 3-way BU might incur different crypto algorithm compute cost
on the MN and CN than something which establishes a SA as part of
the 1st BU.

BTW: The draft (after reading some more) talks about authentication
and never about authorization aka address ownership of the home address. 
I think return routability is one presumed
source of authorization and SUCV like solutions provide another model
for authorization.

Clearly the WG needs to do something about both authorization and 
authentication and at some level the solutions to the two might be independent.
But the draft seems to state that the only problem is one of authentication
which isn't correct. (But perhaps the authorization discussion and tradeoffs
could be clarified by another I-D.)

> It is important to realize that the authentication - SA model is just an
> *optimization*. That is, it brings no added functionality beyond reducing
> the number of messages. Most people that I've talked to seem to feel
> that the optimization is a necessary one, though.

But the SA model is also likely to have different security properties that
an 3-way BU. Some of this is hard to discuss without a concrete 3-way proposal
to look at but it seems to me like in the SA case a node that was a MiTM at
some point in time but later, due to the MN moving, is no longer on the path,
can cause different damage in the 2 cases. With an SA approach that attacker 
could acquire the keying material and use that to affect communication
between the MN and CN until the keying material "times out".
In the 3-way BU model such an attacker could only affect the BUs as long as it
remains on the path.

> It is interesting to note that if the WG decides to adopt the
> authentication-only model then there'd be an easy conclusion to the -14 vs.
> ah discussion: neither option would be needed!
> 
> Another interesting note is that if we pick solution 6.4 then this could live
> with the authentication-only solution in the global Internet (with 3 messages
> per BU), and where local PKI is available this could be reduced to ipsec-only
> (with 1 message per BU).
> 
> Question: how useful will route optimization be, if every movement must be
> announced by three messages, not one?

It would be good to understand the performance aspects of BUs in general,
but I haven't seen any real data being exchanged in the WG.

One observation is if the MN doesn't move often, but talks to many CNs,
then there might be just one BU per CN (to tell the CN not to go through the 
HA). Thus this will be at least a 3-way handshake in all cases (and more if
IKE is used I think). In such cases establishing a SA is wasted effort.

If, for a given communication between a MN and CN, the MN moves multiple times
within the lifetime of the SA, then it would make sense to establish an SA.

But folks are likely to have different views at which "granularity" MIPv6
will be used which effects how many times a MN would move while communicating
with a given CN, so I don't see an easy way to resolve this.

  Erik
`` 



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 12:58:31 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11352
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 12:58:31 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11407;
	Tue, 23 Oct 2001 09:58:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15570;
	Tue, 23 Oct 2001 09:56:22 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGtaOI012092
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:55:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NGta34012091
	for mobile-ip-dist; Tue, 23 Oct 2001 09:55:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NGtWOI012084
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:55:32 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17470
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:55:35 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08317
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:55:34 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA15522
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:55:33 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9NGtWG31867
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 09:55:32 -0700
X-mProtect:  Tue, 23 Oct 2001 09:55:32 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd9ehUBT; Tue, 23 Oct 2001 09:55:30 PDT
Message-ID: <3BD5A103.4EE350D7@iprg.nokia.com>
Date: Tue, 23 Oct 2001 09:55:31 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: RESEND: [mobile-ip] MIPv6 - Focus of the security discussion
References: <933FADF5E673D411B8A30002A5608A0E5548FB@zrc2c012.us.nortel.com> <3BC48542.76ED17CE@iprg.nokia.com> <3BD59958.18612698@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

0.05 seconds.

Vijay

Theo Pagtzis wrote:
> 
> Hi all,
> 
>   could I just ask again about the router advertisment interval. Is it
> really intended to be a minimum of
> 
> 0.05 seconds or 0.5 seconds?
> 
> thanks
> 
> Theo
> UCL/Mobile Systems
> 
> "Charles E. Perkins" wrote:
> >
> > Hello Glenn,
> >
> > > Besides route optimized MIPv6 will never be ubiquitous anyway as long as the
> > > binding update processing by CN's is only a SHOULD. The MN and HA will always
> > > have to be complicated by back-off procedures to forward stream tunnel
> > > mechanisms.
> >
> > I think it's too late by more than a year to change this from
> > a SHOULD to a MUST.  And, anyway, we can hope that by the time
> > we're pushing multiple billions of IPv6 nodes, the benefits of
> > routing directly to the care-of address are obvious enough, and
> > the code well enough understood.  Then naturally, most nodes
> > will process Binding Updates.
> >
> > > In my opinion removing this complication is more important than removing the
> > > piggyback complication for specific access technologies and compression
> > > mechanisms.
> > >
> > > I would rather see the group focus on making the route optimized mobility
> > > ubiquitous and removing the complications of it not being.
> >
> > The complications of using Destination Options with payload are all
> > on the sending side.  The receivers implementation is very natural.
> > That's why it makes very much sense to me, to leave it as a possible
> > option for _senders_ that want to maximize the performance of their
> > communications.
> >
> > Regards,
> > Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 13:12:02 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11958
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 13:12:01 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19661;
	Tue, 23 Oct 2001 10:11:59 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20317;
	Tue, 23 Oct 2001 10:11:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NHAUOI012223
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 10:10:30 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NHAUlu012222
	for mobile-ip-dist; Tue, 23 Oct 2001 10:10:30 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NHAQOI012215
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 10:10:26 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00539;
	Tue, 23 Oct 2001 10:10:17 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18544;
	Tue, 23 Oct 2001 10:10:20 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9NHAVm24170;
	Tue, 23 Oct 2001 10:10:31 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAQ21620;
	Tue, 23 Oct 2001 10:09:40 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10369; Tue, 23 Oct 2001 10:10:02 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15317.42090.86593.25426@thomasm-u1.cisco.com>
Date: Tue, 23 Oct 2001 10:10:02 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: <Jari.Arkko@ericsson.com>, "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
In-Reply-To: <003201c15bdd$9c4bd500$8a1b6e0a@arenanet.fi>
References: <Roam.SIMC.2.0.6.1003850725.8873.nordmark@bebop.france>
	<003201c15bdd$9c4bd500$8a1b6e0a@arenanet.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari Arkko writes:
 > Question: how useful will route optimization be, if every movement must be
 > announced by three messages, not one?

Jari,

There's actually a third option that is in between
the simplicity of always performing a three way
handshake, and the overhead of performing
ephemeral Diffie Hellman's. Something to observe
about the DH exchange is that what it primarily
creates is shared state between the two nodes
which can be used for subsequent binding updates
to have some belief that they are from the same
sender.

Using strong cryptography, you'd ordinarily
exchange credentials at this point to eliminate
man in the middle attacks and positively verify
the peer. However, since we are foregoing that
protection in the name of scalabilty, the DH
exchange is _only_ being used as a means of
establishing shared state. The reason is that it
is only as strong as the initial return
routability test; if you don't believe that that
test is sufficient, djinning up a key based on
that test does not make subsequent transactions
any safer.

Where this leads me is to question why we need
something as expensive as a DH exchange. Why not,
instead, just exchange large random numbers which
can be kept in sync by the MN and CN. Essentially,
this would mimic TCP's use of SEQ/ACKSEQ, but
forgo the connection aspects of TCP (ie, what's
needed is "soft" connection state, rather than
"hard" state as with TCP). I believe that this too
meets all of the requirements, and would allow us
to have an initial 3 way handshake with subsequent
updates only requiring a single exchange. Indeed,
it is probably a better fit for the requirements
since it sidesteps the thorny issues surrounding
any use CPU intensive asymmetric cryptography.

	     Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 14:20:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14720
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 14:20:37 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07501;
	Tue, 23 Oct 2001 12:20:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11689;
	Tue, 23 Oct 2001 11:20:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NIJVOI012431
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 11:19:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NIJVn6012430
	for mobile-ip-dist; Tue, 23 Oct 2001 11:19:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NIJROI012423
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 11:19:27 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11067
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 11:19:29 -0700 (PDT)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04091
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 11:19:27 -0700 (PDT)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09Y4RA>; Tue, 23 Oct 2001 14:18:26 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA8C@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject:  [mobile-ip] QUESTION: RFC2002
Date: Tue, 23 Oct 2001 14:18:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi,

	I have a question on section 3.6.1.1. of RFC2002. It is stated that:

When registering in a foreign network with co-located care-of address, IP
source field MUST use the care-of address.
In all other circumstances IP source address MUST be the mobile node' home
address.

Does this mean that if the mobile node is in a foreign network, attached to
a foreign agent, it MUST use the mobile node's home address, and NOT the
foreign agent care-of address in the IP Source Address field? 

-Sharif.

p.s. If there is anyone who is very familar with the RFC2002 spec., and has
implementation experience, I would be grateful if they could send me e-mail
directly for some questions off -line. Thanks.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 16:14:25 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18677
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 16:14:24 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20203;
	Tue, 23 Oct 2001 14:14:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20238;
	Tue, 23 Oct 2001 13:13:44 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NKBpOI012783
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 13:11:51 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NKBpk2012782
	for mobile-ip-dist; Tue, 23 Oct 2001 13:11:51 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NKBlOI012775
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 13:11:47 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08830
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 13:11:49 -0700 (PDT)
Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18342
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 14:11:48 -0600 (MDT)
Received: from jariws1 ([62.248.238.80]) by fep01-app.kolumbus.fi
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP
          id <20011023201147.SPWV13228.fep01-app.kolumbus.fi@jariws1>;
          Tue, 23 Oct 2001 23:11:47 +0300
Message-ID: <008101c15bfe$f4abb8c0$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
Cc: <mobile-ip@sunroof.eng.sun.com>, <Jari.Arkko@ericsson.com>
References: <Roam.SIMC.2.0.6.1003855373.12071.nordmark@bebop.france>
Subject: Re: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
Date: Tue, 23 Oct 2001 23:11:52 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> BTW: The draft (after reading some more) talks about authentication
> and never about authorization aka address ownership of the home address. 
> I think return routability is one presumed
> source of authorization and SUCV like solutions provide another model
> for authorization.

The term 'authentication' was used in my draft to (inaccurately) describe
'all that BAKE and other proposals do' ;-) Depending on the proposal,
they use various kinds of schemes, such as return routability or pk hash
properties. Is the authorization a correct term to use here? What if in some
cases we have strong authentication and authorization? In the weak case
we don't seem to have any real authentication, only authorization.

As a side note, we'd also benefit from some terminology to replace 'weak
authentication' with something that doesn't sound so negative...

> But the SA model is also likely to have different security properties that
> an 3-way BU. Some of this is hard to discuss without a concrete 3-way proposal
> to look at but it seems to me like in the SA case a node that was a MiTM at
> some point in time but later, due to the MN moving, is no longer on the path,
> can cause different damage in the 2 cases. With an SA approach that attacker 
> could acquire the keying material and use that to affect communication
> between the MN and CN until the keying material "times out".
> In the 3-way BU model such an attacker could only affect the BUs as long as it
> remains on the path.

Yes, there may be some differences in the security properties as you point out.
After I sent my previous e-mail I started thinking about the various replay
attack scenarios and the effect of SA/no-SA on them; there may be differences
in that as well. It is not clear to me if the sequence number in a BCE is zeroed
when the entry is created or when the SA associated with it is created.

As to your specific example, there's a difference depending on whether the
MN makes an attempt to send a BU or not. If it sends a BU it will detect that
it didn't get an ACK, and will rerun BAKE, recreating the security association
and there is no problem. If the MN is not sending BUs (perhaps because it
is not communicating with the CN), then the attacker is "free" to use the SA
at will until it expires.

Jari





From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 16:41:08 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19359
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 16:41:08 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02153;
	Tue, 23 Oct 2001 13:41:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26031;
	Tue, 23 Oct 2001 13:40:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NKdlOI012925
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 13:39:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NKdk37012924
	for mobile-ip-dist; Tue, 23 Oct 2001 13:39:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NKdhOI012917
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 13:39:43 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14941;
	Tue, 23 Oct 2001 13:39:46 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21812;
	Tue, 23 Oct 2001 13:39:46 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9NKe0m27285;
	Tue, 23 Oct 2001 13:40:00 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAS00454;
	Tue, 23 Oct 2001 13:39:08 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA10487; Tue, 23 Oct 2001 13:39:31 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15317.54658.997046.885487@thomasm-u1.cisco.com>
Date: Tue, 23 Oct 2001 13:39:30 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>, <Jari.Arkko@ericsson.com>
Subject: Re: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
In-Reply-To: <008101c15bfe$f4abb8c0$8a1b6e0a@arenanet.fi>
References: <Roam.SIMC.2.0.6.1003855373.12071.nordmark@bebop.france>
	<008101c15bfe$f4abb8c0$8a1b6e0a@arenanet.fi>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jari Arkko writes:
 > > BTW: The draft (after reading some more) talks about authentication
 > > and never about authorization aka address ownership of the home address. 
 > > I think return routability is one presumed
 > > source of authorization and SUCV like solutions provide another model
 > > for authorization.
 > 
 > The term 'authentication' was used in my draft to (inaccurately) describe
 > 'all that BAKE and other proposals do' ;-) Depending on the proposal,
 > they use various kinds of schemes, such as return routability or pk hash
 > properties. Is the authorization a correct term to use here? What if in some
 > cases we have strong authentication and authorization? In the weak case
 > we don't seem to have any real authentication, only authorization.

With the weak version, we have both. It works as
follows: you claim to be at address ::w.x.y.z, and
the CN in order to authenticate you sends you off
on a return routability test. By completing the
test, you are authenticated as that address
(albeit weakly) and this in and of itself is
sufficient to authorize you to change that and
only that address's current binding (as opposed to
authorizing you to change the binding for any
address, etc).

 > As a side note, we'd also benefit from some terminology to replace 'weak
 > authentication' with something that doesn't sound so negative...

I feel the opposite. I think we should be very up
front about the fact that this doesn't use strong
authentication so that we don't look like yokels
who found the security equivalent of a perpetual
motion machine. Otherwise somebody like Bruce
Schneier is going to come along and point out the
obvious, implying that we were so stupid that we
actually believed that this was a strong
authentication alternatative...

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 17:17:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20486
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 17:17:11 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18846;
	Tue, 23 Oct 2001 14:16:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04571;
	Tue, 23 Oct 2001 14:15:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NLELOI013101
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 14:14:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NLELuc013100
	for mobile-ip-dist; Tue, 23 Oct 2001 14:14:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NLEHOI013093
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 14:14:17 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04273
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 14:14:10 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13978
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 15:14:53 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA04917;
	Tue, 23 Oct 2001 14:14:17 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9NLEH030823;
	Tue, 23 Oct 2001 14:14:17 -0700
X-mProtect:  Tue, 23 Oct 2001 14:14:17 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdsSNVE4; Tue, 23 Oct 2001 14:14:14 PDT
Message-ID: <3BD5DDA6.6CCEB1F6@iprg.nokia.com>
Date: Tue, 23 Oct 2001 14:14:14 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Sharif M. Shahrier" <Sharif.Shahrier@InterDigital.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] QUESTION: RFC2002
References: <A1170612471BD21185B90008C7FA0A0D01F1FA8C@idcpa4.pa.interdigital.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Sharif,

"Shahrier, Sharif M." wrote:

> Does this mean that if the mobile node is in a foreign network, attached to
> a foreign agent, it MUST use the mobile node's home address, and NOT the
> foreign agent care-of address in the IP Source Address field?

Yes, it does mean that.

> p.s. If there is anyone who is very familar with the RFC2002 spec., and has
> implementation experience, I would be grateful if they could send me e-mail
> directly for some questions off -line. Thanks.

I am familiar with the specification, and have implementation experience.
Now, if I could just find enough time...  But, I can try to answer
questions anyway, except not about Windows implementations.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 19:17:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22392
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 19:17:45 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06325;
	Tue, 23 Oct 2001 16:17:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23797;
	Tue, 23 Oct 2001 16:16:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NNFGOI013366
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:15:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NNFGNU013365
	for mobile-ip-dist; Tue, 23 Oct 2001 16:15:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NNFDOI013358
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:15:13 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAB21665
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:15:02 -0700 (PDT)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20988
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:15:01 -0700 (PDT)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9NNCBu17797
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:12:11 -0700 (PDT)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9NNF1S27522
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:15:01 -0700 (PDT)
Subject: [mobile-ip] RFC3012 interpretation yet again
To: mobile-ip@sunroof.eng.sun.com
Date: Tue, 23 Oct 2001 18:15:00 -0500
Message-ID: <OF99679EA0.A131A426-ON86256AEE.007F236B@3com.com>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I'd like to encourage the working group and/or
draft authors to come to some sort of official decision
about the proper interpretation of section 8 of this RFC,
and make this decision public.

Basically, this would involve an announcement on this list
and a publication of an errata on the RFC editor pages.

The sooner such an errata is made public and official
the better.  Otherwise there is a chance that both
interpretations may be deployed.

Thanks in advance,
Mike




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 19:44:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22918
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 19:44:18 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05326;
	Tue, 23 Oct 2001 17:43:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29272;
	Tue, 23 Oct 2001 16:43:21 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NNgNOI013483
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:42:23 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NNgNiu013482
	for mobile-ip-dist; Tue, 23 Oct 2001 16:42:23 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NNgKOI013475
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:42:20 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27735
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 16:42:22 -0700 (PDT)
Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11878
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 17:43:03 -0600 (MDT)
Received: from splat.its.monash.edu.au ([130.194.1.73])
 by vaxc.cc.monash.edu.au (PMDF V6.1 #39306)
 with ESMTP id <01K9VI5FL8TIA9QDP7@vaxc.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Wed, 24 Oct 2001 09:42:08 +1000
Received: from localhost (localhost [127.0.0.1])	by splat.its.monash.edu.au
 (Postfix) with ESMTP id 8606012C013	for <mobile-ip@sunroof.eng.sun.com>; Wed,
 24 Oct 2001 09:42:08 +1000 (EST)
Received: from eng.monash.edu.au
 (PC00004790.eng.monash.edu.au [130.194.137.189])	by splat.its.monash.edu.au
 (Postfix) with ESMTP id 4F52412C025	for <mobile-ip@sunroof.eng.sun.com>; Wed,
 24 Oct 2001 09:42:04 +1000 (EST)
Date: Wed, 24 Oct 2001 09:47:16 +1000
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
To: mobile-ip@sunroof.eng.sun.com
Message-id: <3BD60184.5BB91082@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-Virus-Scanned: by AMaViS perl-11
References: 
 <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se>
 <3BD4AFD9.17C3BB73@iprg.nokia.com>
 <4.3.2.7.2.20011023093925.00b95a78@mira-sjc5-9.cisco.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7BIT

GD: Hi Michael, Response is below.

"Michael A. Ramalho" wrote:
> 
> At 11:52 AM 10/23/2001 +1000, Greg Daley wrote:
> 
> <snip>
> 
> >         coupled with the mechanism: Only send a piggybacked BAck if
> >         a piggybacked Binding Update is received, it would guarantee
> >         compliance of BU and Back with a particular bandwidth constrained
> >         medium adjacent to the MN.
> 
> Humm ... sounds like you are assuming a symmetrical link to the MN.
> 
> A lot of access technologies have a scarce bandwidth resource requiring
> special treatment of real-time packets in only one direction (e.g., cable
> access systems and some non-cellular wireless access).

	Not strictly, but maybe I did not state myself explicitly...
	
	In order to not delay the (Possibly Critical) BU any longer than
	needs be, when the responding CN/HA does not have a-priori knowledge
	of the MN's Link conditions, if the BU packet arrives unpiggybacked,
	it is unsafe to assume that piggybacking will work.

	This is since the BU's may have been discarded/mangled/delayed 
	by their transit MN->HA/CN with Piggyback. For example this
unpiggybacked 
	BU may be the first datagram which reaches the CN/HA after
BU_PIGGY_TIMES.

	The role of the fall-back 'no piggybacking' is a mechanism which 
	most networks should be able to handle, at the expense of 
	additional datagram overhead and MAC access.  The Piggybacked 
	mechanism may be attempted if a Piggybacked BU is received, in order to 
	provide an optimal service.  

	If the BU is seen again though, it is possible that the return path 
	is misplacing the piggybacked BAcks...  This would mean sending 
	another datagram (possibly B_ACK_PIGGY_TIMES ;-) but another counter
for
	each Binding Cache Entry may be unnecessarily complicated..

	In the case where the CN prefers not to Piggyback (which may be because
	of configuration/knowledge about of the intervening network etc), this
is 
	possible.  The only requirement was not to send Unsolicited Piggyback
BU's.

	Just an idea which was triggered by Rajeev's

		Greg Daley


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 21:45:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25933
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 21:45:43 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06363;
	Tue, 23 Oct 2001 19:45:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18320;
	Tue, 23 Oct 2001 18:44:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O1hK6C013962
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:43:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O1hJxw013961
	for mobile-ip-dist; Tue, 23 Oct 2001 18:43:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O1hF6C013954
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:43:15 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00093
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:43:08 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15370
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:43:17 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9O1hmQ05355
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:43:48 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56c7b63a0fac12f255079@davir02nok.americas.nokia.com>;
 Tue, 23 Oct 2001 20:43:15 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 23 Oct 2001 20:43:15 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Tue, 23 Oct 2001 21:43:15 -0400
Message-ID: <A6D9D7495456414BA08DB655C2AC6712078141@bsebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15C2D.3FC4557B"
Thread-Topic: [mobile-ip] MIPv6 - Focus of the security discussion
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFbYhdDBZsQW8dTEdWBTgBQi2X+DwAfB2ZQ
From: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>
To: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        <mobile-ip@sunroof.eng.sun.com>
Cc: "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
X-OriginalArrivalTime: 24 Oct 2001 01:43:15.0429 (UTC) FILETIME=[3FA73150:01C15C2D]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C15C2D.3FC4557B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
Hello Hesham,
=20


	Hi Rajeev,=20

	this is really the issue of carrying IPv6 over certain links.=20
Piggybacking happens to make use of destination option, that's all. So,=20
when you characterize not having piggybacking in MIPv6 as "cellular=20
friendly", you are inevitably referring to how to support destination=20
options in general. If these links are the first to carry IPv6, it=20
should be possible to support destination options in arbitrary packets,=20
don't you think ?=20

	=3D> I don't think you got my point, it doesn't matter what the=20
link "should" be doing. We're not radio link designers and=20
there is an existing reality that we have to deal with. There=20
are lots of things that I'd like to see link layers do but that's=20
not the issue.=20


[Rajeev] Well, I am afraid that you did not get the essence of what I
said either: If a link claims it supports IPv6, it _is_ supporting
destination option in arbitrary packets.=20

[I realize home address option is a destination=20
option, BTW].=20

=3D> A static one in every packet, and is compressed.
[Rajeev]   Good. You acknowledge the presence of header compression.
That means there is no problem with piggybacking on such a link.=20

	More generally, a link should be able to handle variable=20
packet sizes. Thus, removing piggybacking should not be an option.=20

=3D> Again "should", I'm talking about what they "do", not=20
"should do".=20


[Rajeev] Please read the sentence. It says removing piggybacking should
not be an option. Actually, removing piggybacking MUST NOT be an option.
It only indicates to me that MIPv6 is expressly eliminating what is in
2460.=20

	I am in favor of option 1 you mention below. This is in line
with=20
general IP protocol design. Any performance considerations could be=20
stated in the draft in some form.=20
For instance, we could state that "..if the BAck does not return after=20
transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send

a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a=20
configurable parameter.=20

=3D> I don't think that's a good idea. It shouldn't take a few BUs=20
and dropped packets for us to "guess" whether piggybacking=20
is needed or not.=20

[Rajeev:]There was an e-mail earlier from Greg Daley on how to do this
better.


In fact I don't know why you say it's in line with general IP protocol=20
design ?? Could you explain what that is ?=20
In the Fast Handoffs work for v4 and v6, the design teams have=20
been modifying parts of MIP to -for example- get the AR to=20
start forwarding before receiving a BU, why was this acceptable ?=20
Why didin't we just say link layers should be desinged to allow=20
for MIP signalling ?=20


[Rajeev]  Well, do they eliminate piggybacking ? How do they violate
base IPv6 specification ?  Anyway, my point (which I have made few times
now in this thread) was that you don't design an IP protocol based on
each link's idiosyncrasies!

=20
Well some of us did, but the WG decided that both philosophies=20
are needed to support existing link layers. BETH is one example.=20
So I don't think your logic is in line with the previous WG decisions=20
on similar topics.=20


[Rajeev] Performance optimizations are fine as long as the base protocol
is not violated. Here, by saying that we will disallow piggybacking, you
are saying that we don't support IPv6 destination options in arbitrary
packets. =20


	I am willing to live with option 3. As you suggest, in the home
address=20
option, a flag might indicate the MN's intention to piggyback.=20
I however, don't know how the CN would be able to negate it unless it is

also using the home address option.=20

	=3D> Well if it happens then it can't be negated.=20


	>=20
>      Actually, I mentioned previously that the use of [rohc] over=20
>      cellular is one=20
>      reference for you. See=20
>      http://www.ludd.luth.se/users/larsman/rocco and follow=20
>      the references.=20
>      Note: use of [rohc] would require support for variable packet=20
>      sizes on the=20
>      link (perhaps the same kind of link you are considering).=20
>=20
>      =3D> I'm not sure why the discussion has gone towards header=20
>      compression, but anyway, the point I was raising was that=20
>      piggybacking can have negative effects on the MN/CN if they=20
>      are attached to a tight channel. Obviously the channel is tight=20
>      because it''s expensive so there is a very limited potential=20
>      of reserving a "just in case" extra BW for piggybacking.=20
>=20
>=20
Rajeev: Since we were discussing a "tight channel", it is likely that=20
header compression is needed on such links. Hence the discussion on HC.=20

=3D> HC was not the issue, tight channels are.=20

[Rajeev:] You seem to be contradicting yourself, and I see myself
repeating a lot..I said when the channel is tight, it is likely that HC
is used, and you mention above, wrt to home address option, compression
is in use.


>=20
>      Now, I'm not saying ROHC can't handle it, all I was saying is=20
>      that this "larger" packet will likely take double the time=20
>      to be sent over the air since it may not fit into one radio=20
>      frame. If it does, then the end to end delay will be=20
>      significantly=20
>      increased (the air link delays are -by far- the largest part=20
>      of the e2e delay in a cellular environment) and it may be=20
>      dropped.=20
>      ROHC is not reallt relevant here.=20
>=20
>=20
Rajeev: chances of a piggybacked packet being large enough that it=20
creates the problem you mention above is not an issue when you use HC.=20
In the non-IR states, you already have 40 bytes of gain due to IPv6=20
compression which is more than the size of a BU.=20

=3D> How do you know that the link was not designed with the=20
underlying assumption that header compression is used ?=20
Hence no gain !=20

[Rajeev:] You don't have to know. If the link supports IPv6, it handles
destination option regardless of HC.

BTW, no header compression on a _tight link_ that supposedly carries
IPv6 packets, piggybacking would not be the primary problem!=20

Regards,

-Rajeev

=20

=20

        Hesham=20


------_=_NextPart_001_01C15C2D.3FC4557B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>

<META content=3D"MSHTML 5.00.3013.2600" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D150271716-23102001>Hello=20
Hesham,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D150271716-23102001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px"><BR>
  <UL>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>Hi Rajeev, =
</FONT></P>
    <P><FONT face=3DArial size=3D2>this is really the issue of carrying =
IPv6 over=20
    certain links.</FONT> <BR><FONT face=3DArial size=3D2>Piggybacking =
happens to=20
    make use of destination option, that's all. So,</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>when you characterize not having piggybacking in MIPv6 as=20
    "cellular</FONT> <BR><FONT face=3DArial size=3D2>friendly", you are =
inevitably=20
    referring to how to support destination</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>options in general. If these links are the first to carry =
IPv6,=20
    it</FONT> <BR><FONT face=3DArial size=3D2>should be possible to =
support=20
    destination options in arbitrary packets,</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>don't you think ?</FONT> </P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; I don't think =
you got my=20
    point, it doesn't matter what the </FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>link "should" be doing. We're not radio link designers and=20
    </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>there is an =
existing=20
    reality that we have to deal with. There</FONT> <BR><FONT =
color=3D#0000ff=20
    face=3DArial size=3D2>are lots of things that I'd like to see link =
layers do but=20
    that's</FONT> <BR><FONT color=3D#0000ff face=3DArial size=3D2>not =
the=20
    issue.</FONT> </P></UL>
  <P><BR><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D150271716-23102001><FONT=20
  color=3D#0000ff>[Rajeev]&nbsp;Well, I am afraid that you did not get =
the essence=20
  of what I said either: If a link claims it supports IPv6, it _is_ =
supporting=20
  destination option in arbitrary packets. =
</FONT></SPAN></FONT></FONT></P>
  <P><FONT size=3D2><FONT face=3DArial><SPAN=20
  class=3D150271716-23102001></SPAN></FONT></FONT><FONT size=3D2><FONT =
face=3DArial>[I=20
  realize home address option is a destination</FONT></FONT> <BR><FONT=20
  face=3DArial size=3D2>option, BTW].</FONT> </P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial>=3D&gt; A =
static one in=20
  every packet, and is compressed.<BR></FONT></FONT></FONT><FONT =
size=3D2><FONT=20
  color=3D#0000ff><FONT face=3DArial><SPAN=20
  =
class=3D150271716-23102001>[Rajeev]&nbsp;&nbsp;</SPAN></FONT></FONT><FONT=
=20
  color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D150271716-23102001>&nbsp;Good. You=20
  acknowledge the presence of header compression. That means there is no =
problem=20
  with piggybacking on such a link. </SPAN></FONT></FONT></FONT></P>
  <UL>
    <P><FONT face=3DArial size=3D2>More generally, a link should be able =
to handle=20
    variable</FONT> <BR><FONT face=3DArial size=3D2>packet sizes. Thus, =
removing=20
    piggybacking should not be an option.</FONT> </P></UL>
  <P><FONT face=3DArial><FONT color=3D#0000ff size=3D2>=3D&gt; Again =
"should", I'm=20
  talking about what they "do", not <BR></FONT></FONT><FONT =
size=3D2><FONT=20
  color=3D#0000ff><FONT face=3DArial>"should do". <BR><SPAN=20
  class=3D150271716-23102001></SPAN></FONT></FONT></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D150271716-23102001>[Rajeev]&nbsp;Please read the sentence. It =
says=20
  removing piggybacking should not be an option. Actually, removing =
piggybacking=20
  MUST NOT be an option. It only indicates to me that MIPv6 is expressly =

  eliminating&nbsp;what is in 2460. </SPAN></FONT></FONT></FONT></P>
  <UL>
    <P><FONT face=3DArial size=3D2>I am in favor of option 1 you mention =
below. This=20
    is in line with</FONT> <BR><FONT face=3DArial size=3D2>general IP =
protocol=20
    design. Any performance considerations could be</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>stated in the draft in some form.</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>For instance, we could state that "..if the BAck does not =
return=20
    after</FONT> <BR><FONT face=3DArial size=3D2>transmitting a Binding =
Update=20
    BU_PIGGY_TIMES, the sending node must send</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>a BU without piggybacking". BU_PIGGY_TIMES, a non-zero =
integer, is=20
    a</FONT> <BR><FONT face=3DArial size=3D2>configurable =
parameter.</FONT> </P></UL>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; I don't think =
that's a good=20
  idea. It shouldn't take a few BUs</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>and dropped packets for us to "guess" whether piggybacking=20
  </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>is needed or =
not.</FONT>=20
  <FONT color=3D#0000ff face=3DArial size=3D2></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D150271716-23102001>[Rajeev:]</SPAN>There was an =
e-mail&nbsp;<SPAN=20
  class=3D150271716-23102001>earlier </SPAN>from Greg Daley on how to do =
this=20
  better.</FONT></FONT></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><BR>In fact =
I don't know=20
  why you say it's in line with general IP protocol</FONT></FONT></FONT> =

  <BR><FONT color=3D#0000ff face=3DArial size=3D2>design ?? Could you =
explain what=20
  that is ? </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>In =
the Fast=20
  Handoffs work for v4 and v6, the design teams have </FONT><BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2>been modifying parts of MIP to =
-for example-=20
  get the AR to </FONT><BR><FONT color=3D#0000ff face=3DArial =
size=3D2>start=20
  forwarding before receiving a BU, why was this acceptable ?</FONT> =
<BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2>Why didin't we just say link =
layers should be=20
  desinged to allow </FONT><BR><FONT color=3D#0000ff face=3DArial =
size=3D2>for MIP=20
  signalling ?</FONT> <BR></P><FONT size=3D2><FONT color=3D#0000ff><FONT =

  face=3DArial><SPAN =
class=3D150271716-23102001></SPAN></FONT></FONT></FONT>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D150271716-23102001>[Rajeev]&nbsp;&nbsp;Well, do they eliminate =

  piggybacking ? How do they violate base IPv6 specification=20
  ?</SPAN></FONT></FONT></FONT><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
  face=3DArial><SPAN class=3D150271716-23102001>&nbsp; Anyway, my point =
(which I=20
  have made few times now in this thread) was that you&nbsp;don't design =
an IP=20
  protocol based on each link's =
idiosyncrasies!</SPAN></FONT></FONT></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D150271716-23102001>&nbsp;</SPAN><BR>Well some of us did, but =
the WG=20
  decided that both philosophies <BR>are needed to support existing link =
layers.=20
  BETH is one example. <BR>So I don't think your logic is in line with =
the=20
  previous WG decisions</FONT></FONT></FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>on similar topics.</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2><SPAN class=3D150271716-23102001></SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D150271716-23102001>[Rajeev] Performance optimizations =
are&nbsp;fine as=20
  long as the base protocol is not violated.&nbsp;Here, by saying that =
we will=20
  disallow piggybacking, you are saying that we don't support IPv6 =
destination=20
  options in arbitrary packets. &nbsp;</SPAN></FONT></P>
  <UL><BR>
    <P><FONT face=3DArial size=3D2>I am willing to live with option 3. =
As you=20
    suggest, in the home address</FONT> <BR><FONT face=3DArial =
size=3D2>option, a=20
    flag might indicate the MN's intention to piggyback.</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>I however, don't know how the CN would be able =
to negate=20
    it unless it is</FONT> <BR><FONT face=3DArial size=3D2>also using =
the home=20
    address option</FONT><FONT color=3D#0000ff face=3DArial size=3D2>. =
</FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; Well if it =
happens then it=20
    can't be negated.</FONT> </P><BR>
    <P><FONT face=3DArial size=3D2>&gt;</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Actually, I mentioned =
previously=20
    that the use of [rohc] over</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cellular is one</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reference =
for you.=20
    See</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><U> <FONT =
color=3D#0000ff=20
    face=3DArial size=3D2><A =
href=3D"http://www.ludd.luth.se/users/larsman/rocco"=20
    =
target=3D_blank>http://www.ludd.luth.se/users/larsman/rocco</A></FONT></U=
><FONT=20
    face=3DArial size=3D2> and follow</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the references.</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: use =
of [rohc]=20
    would require support for variable packet</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sizes on the</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; link =
(perhaps the same=20
    kind of link you are considering).</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D&gt; I'm not sure why =
the=20
    discussion has gone towards header</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; compression, but anyway, =
the point=20
    I was raising was that</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; piggybacking can have =
negative=20
    effects on the MN/CN if they</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are attached to a tight =
channel.=20
    Obviously the channel is tight</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; because it''s expensive =
so there=20
    is a very limited potential</FONT> <BR><FONT face=3DArial=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of reserving a "just in =
case"=20
    extra BW for piggybacking.</FONT> <BR><FONT face=3DArial =
size=3D2>&gt;</FONT>=20
    <BR><FONT face=3DArial size=3D2>&gt;</FONT> <BR><FONT face=3DArial =
size=3D2>Rajeev:=20
    Since we were discussing a "tight channel", it is likely that</FONT> =

    <BR><FONT face=3DArial size=3D2>header compression is needed on such =
links.=20
    Hence the discussion on HC.</FONT> </P></UL>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; HC was not the =
issue, tight=20
  channels are.</FONT> </P>
  <P><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D150271716-23102001><FONT=20
  color=3D#0000ff>[Rajeev:] You seem to be contradicting yourself, and I =
see=20
  myself repeating a lot..I said when the channel is tight, it is likely =
that HC=20
  is used, and you mention above, wrt to home address option, =
compression is in=20
  use.</FONT></SPAN></FONT></FONT></P>
  <P><FONT size=3D2><FONT face=3DArial><SPAN=20
  class=3D150271716-23102001></SPAN><BR>&gt;</FONT></FONT> <BR><FONT =
face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Now, I'm not saying ROHC =
can't=20
  handle it, all I was saying is</FONT> <BR><FONT face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that this "larger" packet =
will=20
  likely take double the time</FONT> <BR><FONT face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to be sent over the air =
since it may=20
  not fit into one radio</FONT> <BR><FONT face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; frame. If it does, then =
the end to=20
  end delay will be</FONT> <BR><FONT face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; significantly</FONT> =
<BR><FONT=20
  face=3DArial size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; increased =
(the air link=20
  delays are -by far- the largest part</FONT> <BR><FONT face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the e2e delay in a =
cellular=20
  environment) and it may be</FONT> <BR><FONT face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dropped.</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ROHC is not reallt =
relevant=20
  here.</FONT> <BR><FONT face=3DArial size=3D2>&gt;</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>&gt;</FONT> <BR><FONT face=3DArial size=3D2>Rajeev: chances =
of a=20
  piggybacked packet being large enough that it</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>creates the problem you mention above is not an issue when =
you use=20
  HC.</FONT> <BR><FONT face=3DArial size=3D2>In the non-IR states, you =
already have=20
  40 bytes of gain due to IPv6</FONT> <BR><FONT face=3DArial =
size=3D2>compression=20
  which is more than the size of a BU.</FONT> </P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; How do you know =
that the link=20
  was not designed with the </FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>underlying assumption that header compression is used =
?</FONT>=20
  <BR><FONT color=3D#0000ff face=3DArial size=3D2>Hence no gain ! =
</FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D150271716-23102001>[Rajeev:] You don't have to know. If the =
link=20
  supports IPv6, it handles destination option regardless of=20
  HC.</SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D150271716-23102001>BTW,=20
  no header compression on a _tight link_ that supposedly carries IPv6 =
packets,=20
  piggybacking would not be the primary problem! </SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D150271716-23102001>Regards,</SPAN></FONT></P>
  <P><FONT face=3DArial size=3D2><SPAN=20
  class=3D150271716-23102001>-Rajeev</SPAN></FONT></P>
  <P><FONT face=3DArial size=3D2><SPAN=20
  class=3D150271716-23102001></SPAN></FONT>&nbsp;</P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D150271716-23102001></SPAN></FONT>&nbsp;</P>
  <P><SPAN class=3D150271716-23102001></SPAN><FONT size=3D2><FONT=20
  color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D150271716-23102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>Hesham</FONT></FONT></FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15C2D.3FC4557B--


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 21:53:38 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26114
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 21:53:37 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20594;
	Tue, 23 Oct 2001 18:52:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19440;
	Tue, 23 Oct 2001 18:52:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O1pd6C014078
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:51:39 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O1pdAI014077
	for mobile-ip-dist; Tue, 23 Oct 2001 18:51:39 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O1pa6C014070
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:51:36 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16414
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:51:38 -0700 (PDT)
Received: from smtpgw6.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08478
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 19:53:14 -0600 (MDT)
Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138])
	by smtpgw6.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id f9O1pbS12067
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:51:37 -0500 (CDT)
Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <4YSDXP8Z>; Tue, 23 Oct 2001 20:51:37 -0500
Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B99@pkcexv018.sprintspectrum.com>
From: "Lipford, Mark" <MLipfo01@sprintspectrum.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] RFC3012 interpretation yet again
Date: Tue, 23 Oct 2001 20:51:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

As someone that has to implement this we strongly support this
recommendation

		-----Original Message-----
		From:	Mike_Borella@3com.com [mailto:Mike_Borella@3com.com]
		Sent:	Tuesday, October 23, 2001 6:15 PM
		To:	mobile-ip@sunroof.eng.sun.com
		Subject:	[mobile-ip] RFC3012 interpretation yet again

		I'd like to encourage the working group and/or
		draft authors to come to some sort of official decision
		about the proper interpretation of section 8 of this RFC,
		and make this decision public.

		Basically, this would involve an announcement on this list
		and a publication of an errata on the RFC editor pages.

		The sooner such an errata is made public and official
		the better.  Otherwise there is a chance that both
		interpretations may be deployed.

		Thanks in advance,
		Mike
		


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 22:02:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26304
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 22:02:07 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13889;
	Tue, 23 Oct 2001 20:01:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20789;
	Tue, 23 Oct 2001 19:01:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O1xi6C014186
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:59:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O1xh3o014185
	for mobile-ip-dist; Tue, 23 Oct 2001 18:59:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O1xe6C014178
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:59:40 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22356
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:59:42 -0700 (PDT)
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00642
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 18:59:41 -0700 (PDT)
Received: from sooguan ([172.16.3.160])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id JAA26050
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:58:33 +0800 (SGT)
Message-ID: <007101c15c30$4272f420$a00310ac@cwc.nus.edu.sg>
From: "Eng Soo Guan" <engsg@cwc.nus.edu.sg>
To: <mobile-ip@sunroof.eng.sun.com>
References:  <4B6BC00CD15FD2119E5F0008C7A419A51308EDC5@eaubrnt018.epa.ericsson.se> <3BD4AFD9.17C3BB73@iprg.nokia.com> <4.3.2.7.2.20011023093925.00b95a78@mira-sjc5-9.cisco.com> <3BD60184.5BB91082@eng.monash.edu.au>
Subject: [mobile-ip] IPv4 and MIPv6 Transition
Date: Wed, 24 Oct 2001 10:04:13 +0800
Organization: CWC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Dear All,

I would like to know if any work has being done with regard to 'transiting'
to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a NAT.

The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks
based on Dual-Stack Model".

I read found the NGTRANS Shipworm draft attractive to be modified for MIPv6
in a IPv4 only network behind a NAT.

Warmest regards.

SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 23:10:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28651
	for <mobileip-archive@lists.ietf.org>; Tue, 23 Oct 2001 23:10:35 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13735;
	Tue, 23 Oct 2001 21:09:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28460;
	Tue, 23 Oct 2001 20:09:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O38X6C014322
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:08:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O38WmN014321
	for mobile-ip-dist; Tue, 23 Oct 2001 20:08:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O38T6C014314
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:08:29 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26667
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:08:32 -0700 (PDT)
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA08212
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 21:10:16 -0600 (MDT)
Received: from uf4xc (user-v3qsarl.dsl.mindspring.com [199.174.43.117])
	by mclean.mail.mindspring.net (8.9.3/8.8.5) with SMTP id XAA22934;
	Tue, 23 Oct 2001 23:08:30 -0400 (EDT)
From: "Basavaraj Patil" <bpatil@mindspring.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <pcalhoun@bstormnetworks.com>, <charliep@iprg.nokia.com>
Subject: RE: [mobile-ip] RFC3012 interpretation yet again
Date: Tue, 23 Oct 2001 22:08:40 -0500
Message-ID: <002d01c15c39$2efe6600$752baec7@uf4xc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B99@pkcexv018.sprintspectrum.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

We will go ahead with the revisions to the current RFC3012 to clarify
the issue (no ambiguities and scope for misinterpretation) about computing
the authenticator based on the challenge. 

If you believe there are other issues as well (based on implementation
experience) with this RFC, now would be the time to raise them.

We hope to have this done fairly quickly.

Regards,
-Basavaraj 


> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Lipford, Mark
> Sent: Tuesday, October 23, 2001 8:52 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] RFC3012 interpretation yet again
> 
> 
> As someone that has to implement this we strongly support this
> recommendation
> 
> 		-----Original Message-----
> 		From:	Mike_Borella@3com.com 
> [mailto:Mike_Borella@3com.com]
> 		Sent:	Tuesday, October 23, 2001 6:15 PM
> 		To:	mobile-ip@sunroof.eng.sun.com
> 		Subject:	[mobile-ip] RFC3012 
> interpretation yet again
> 
> 		I'd like to encourage the working group and/or
> 		draft authors to come to some sort of official decision
> 		about the proper interpretation of section 8 of 
> this RFC,
> 		and make this decision public.
> 
> 		Basically, this would involve an announcement 
> on this list
> 		and a publication of an errata on the RFC editor pages.
> 
> 		The sooner such an errata is made public and official
> 		the better.  Otherwise there is a chance that both
> 		interpretations may be deployed.
> 
> 		Thanks in advance,
> 		Mike
> 		


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 23 23:11:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28719
	for <mobileip-archive@odin.ietf.org>; Tue, 23 Oct 2001 23:11:55 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05781;
	Tue, 23 Oct 2001 20:11:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28805;
	Tue, 23 Oct 2001 20:11:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O3AK6C014373
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:10:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O3AK5U014372
	for mobile-ip-dist; Tue, 23 Oct 2001 20:10:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O3AG6C014359
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:10:16 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28585
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:10:19 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA26007
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 20:10:18 -0700 (PDT)
Received: (qmail 32257 invoked by uid 500); 24 Oct 2001 02:54:50 -0000
Date: Tue, 23 Oct 2001 19:54:49 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
Message-ID: <20011023195449.J30085@charizard.diameter.org>
References: <OF99679EA0.A131A426-ON86256AEE.007F236B@3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <OF99679EA0.A131A426-ON86256AEE.007F236B@3com.com>; from Mike_Borella@3com.com on Tue, Oct 23, 2001 at 06:15:00PM -0500
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I thought I had, but perhaps it was only through unformal discussions.
Nowhere in section 8 does it state that a particular byte should not be
repeated in the 237 challenge. The whole challenge is to be used, regardless
of the fact that the first byte is used in the initial hash computation.

Hope this helps,

PatC
On Tue, Oct 23, 2001 at 06:15:00PM -0500, Mike_Borella@3com.com wrote:
> I'd like to encourage the working group and/or
> draft authors to come to some sort of official decision
> about the proper interpretation of section 8 of this RFC,
> and make this decision public.
> 
> Basically, this would involve an announcement on this list
> and a publication of an errata on the RFC editor pages.
> 
> The sooner such an errata is made public and official
> the better.  Otherwise there is a chance that both
> interpretations may be deployed.
> 
> Thanks in advance,
> Mike
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 02:25:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14570
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 02:25:49 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04226;
	Wed, 24 Oct 2001 00:25:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA21446;
	Tue, 23 Oct 2001 23:25:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O6Nk6C014774
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 23 Oct 2001 23:23:46 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O6Nkuq014773
	for mobile-ip-dist; Tue, 23 Oct 2001 23:23:46 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O6Ng6C014766
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 23:23:42 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02199
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 23 Oct 2001 23:23:35 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA20903
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 00:25:57 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA06821
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:22:26 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA28191
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:23:33 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VGPNKG3K>; Wed, 24 Oct 2001 16:23:32 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDDC@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Koodli Rajeev (NRC/MtView)'" <rajeev.koodli@nokia.com>,
        "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>,
        mobile-ip@sunroof.eng.sun.com
Cc: "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho"
	 <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 24 Oct 2001 16:23:30 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
		Rajeev, 

		I don't know where I poorly explained my point, but 
		let me see if this works. 
		Let's assume we have a tight channel with a large 
		RTT delay and was designed with the assumption that HC 
		is used. Hence, there is no 40 byte slack in the channel
		because the assumption was always that HC exists
		and the IP header was not accounted for. This is 
		obviously for the case where this channel is "tight"
		due the low BW requirement of the service running on it.

		When a device starts sending an occasional (additional) ext
header
		that causes the payload to be split across more than
		one radio frame, then significant delays will be encountered
		for that payload. If this is a real time payload (like
voice)
		then the delays makes this datagram useless when it 
		arrives at the other end. Hence service disruption has 
		already taken place. 

		Note that I didn't say anything about the packet being 
		dropped above. I will assume that the implementation 
		of this channel will not drop the packet. So the packet
		will still (eventually) be delivered to the other end where 
		the BU is processed.

		Now In the above (_realistic_) scenario, 
		was the service disrupted due to the piggybacking ? Yes
		Will the BU be delivered to the other end ? Based on the
		assumption above: Yes
		Is this radio link breaking RFC2460 ? No because the 
		packet was not dropped. 
		Did the user gain anything from piggybacking ? No. 

		So I don't understand why you're in favour of mandating 
		piggybacking. 

		This covers some of your answers, more comments below:


> 		I am in favor of option 1 you mention below. This is in line
> with 
> 	general IP protocol design. Any performance considerations could be 
> 	stated in the draft in some form. 
> 	For instance, we could state that "..if the BAck does not return
> after 
> 	transmitting a Binding Update BU_PIGGY_TIMES, the sending node must
> send 
> 	a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
> 
> 	configurable parameter. 
> 
> => I don't think that's a good idea. It shouldn't take a few BUs 
> and dropped packets for us to "guess" whether piggybacking 
> is needed or not. 
> 
> [Rajeev:]There was an e-mail earlier from Greg Daley on how to do this
> better.
> 
	=> No that doesn't solve the problem. Michael already 
	responded to that. 


> In fact I don't know why you say it's in line with general IP protocol 
> design ?? Could you explain what that is ? 
> In the Fast Handoffs work for v4 and v6, the design teams have 
> been modifying parts of MIP to -for example- get the AR to 
> start forwarding before receiving a BU, why was this acceptable ? 
> Why didin't we just say link layers should be desinged to allow 
> for MIP signalling ? 
> 
> 
> [Rajeev]  Well, do they eliminate piggybacking ? How do they violate base
> IPv6 specification ?  
> 
	=> I didn't refer to piggybacking ! They violate MIPv6 which clearly

	states that forwarding to a new CoA must be done based on 
	the reception of an authenticated BU. They don't violate
	the base IPv6, but MIPv6. Is that allowed ? If so then I 
	don't understand the "violation" argument.

>  
> Well some of us did, but the WG decided that both philosophies 
> are needed to support existing link layers. BETH is one example. 
> So I don't think your logic is in line with the previous WG decisions 
> on similar topics. 
> 
> 
> [Rajeev] Performance optimizations are fine as long as the base protocol
> is not violated. Here, by saying that we will disallow piggybacking, you
> are saying that we don't support IPv6 destination options in arbitrary
> packets.  
> 
	=> The example I showed above does NOT disallow 
	piggybacking, but it shows that it can be disruptive to
	the services. Anyway, I don't think your charaterisation
	is accurate. Destination options are certainly supported
	(the Home address option is for one). The point is that, 
	the behaviour by which a node signals to the other end
	needs to be optimised to minimise service disruption. 
	In this case the optimisation is to send the MIPv6 signalling
	message on a separate channel, hence eliminate piggybacking. 

	There is nothing wrong with sending DST options in separate
	IP packets. RFC 2460 did not say that all the information
	MUST be piggybacked.

>         Hesham 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 03:14:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18087
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 03:14:21 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24358;
	Wed, 24 Oct 2001 01:13:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22186;
	Wed, 24 Oct 2001 00:13:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O7CJ6C014917
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 00:12:19 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O7CJ8o014916
	for mobile-ip-dist; Wed, 24 Oct 2001 00:12:19 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O7CG6C014909
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 00:12:16 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06468
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 00:12:09 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14257
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 01:14:36 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id RAA11706
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:11:08 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA22399
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:12:16 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VGPNK22V>; Wed, 24 Oct 2001 17:12:14 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDDE@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition
Date: Wed, 24 Oct 2001 17:12:13 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15C5B.34856020"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15C5B.34856020
Content-Type: text/plain

Hello Eng, 

There is another draft you can find at:
http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt

It's a WG draft in NGTRANS but it expired and I'll
resubmit it after adding some of the comments received. 

Cheers,
Hesham


> -----Original Message-----
> From:	Eng Soo Guan [SMTP:engsg@cwc.nus.edu.sg]
> Sent:	Wednesday, 24 October 2001 12:04
> To:	mobile-ip@sunroof.eng.sun.com
> Subject:	[mobile-ip] IPv4 and MIPv6 Transition
> 
> Dear All,
> 
> I would like to know if any work has being done with regard to
> 'transiting'
> to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a
> NAT.
> 
> The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
> Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks
> based on Dual-Stack Model".
> 
> I read found the NGTRANS Shipworm draft attractive to be modified for
> MIPv6
> in a IPv4 only network behind a NAT.
> 
> Warmest regards.
> 
> SG
> Soo Guan, Eng
> Centre for Wireless Communications, NUS
> http://www.cwc.nus.edu.sg
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

------_=_NextPart_001_01C15C5B.34856020
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] IPv4 and MIPv6 Transition</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hello Eng, </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">There is another =
draft you can find at:</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dst=
m-00.txt" =
TARGET=3D"_blank">http://standards.ericsson.net/hesham/draft-ietf-ngtran=
s-siit-dstm-00.txt</A></FONT></U>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It's a WG draft in =
NGTRANS but it expired and I'll</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">resubmit it after =
adding some of the comments received. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Eng Soo Guan [SMTP:engsg@cwc.nus.edu.sg]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, 24 October 2001 12:04</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mobile-ip@sunroof.eng.sun.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">[mobile-ip] IPv4 and MIPv6 =
Transition</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dear All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to know if any work has =
being done with regard to 'transiting'</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to Mobile IPv6 with IPv4 Internet, =
especially with Mobile Node behing a NAT.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The closet drafts I find are =
&quot;Mobile IPv4 Traversal Across NAT and VPN</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Gateways&quot; and &quot;Mobility =
Support for IPv4 and IPv6 Interconnected Networks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">based on Dual-Stack =
Model&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I read found the NGTRANS Shipworm =
draft attractive to be modified for MIPv6</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in a IPv4 only network behind a =
NAT.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Warmest regards.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SG</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Soo Guan, Eng</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Centre for Wireless Communications, =
NUS</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.cwc.nus.edu.sg" =
TARGET=3D"_blank">http://www.cwc.nus.edu.sg</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15C5B.34856020--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 05:03:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19377
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 05:03:45 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24174;
	Wed, 24 Oct 2001 03:03:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06017;
	Wed, 24 Oct 2001 02:02:49 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O91Z6C015154
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:01:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O91ZS2015153
	for mobile-ip-dist; Wed, 24 Oct 2001 02:01:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O91U6C015146
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:01:31 -0700 (PDT)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9O91Tq02802;
	Wed, 24 Oct 2001 11:01:30 +0200 (MET DST)
Date: Wed, 24 Oct 2001 10:55:53 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
To: Jari Arkko <jari.arkko@kolumbus.fi>
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <008101c15bfe$f4abb8c0$8a1b6e0a@arenanet.fi>
Message-ID: <Roam.SIMC.2.0.6.1003913753.12062.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

> The term 'authentication' was used in my draft to (inaccurately) describe
> 'all that BAKE and other proposals do' ;-) 

After reading the complete document I found the "address ownership" section 
which has some of what I was looking for. (BTW: It's a 
really good document summarizing the issues and options).

> Depending on the proposal,
> they use various kinds of schemes, such as return routability or pk hash
> properties. Is the authorization a correct term to use here? What if in some
> cases we have strong authentication and authorization? In the weak case
> we don't seem to have any real authentication, only authorization.

I think authorization is the best term for the general concept. (See RFC 2828)
In this case the question is whether a given nodes is authorized to
redirect packets for a given home address. This could be expressed as
"does the node own the address" but that might rat-hole into what
"ownership" means - ISPs only lend IP address prefixes to their customers etc.

Clearly the strength of the authorization and authentication can differ.
For instance, one could envision a (bad) solution which is to use IKE to
setup a SA between the CN and the CoA, and then have the MN at the CoA say
"trust me I'm really this home address". This would be a case with
no possible authorization check but with strong authentication.
If instead IKE is used between the home address and the CN
then the authorization ends up being return routability since IKE would send
packets to the home address.


I don't know whether the weak form should terminology-wise be viewed to
lacks authentication. RFC 2828:
    $ authenticate
      (I) Verify (i.e., establish the truth of) an identity claimed by
      or for a system entity. (See: authentication.)
One could view return routability as verifying (subject to MITM etc)
that the identity claimed in that of the MN at its home address.

Of course, the packets carrying the BU (or a BSA exchange before the BU)
might not be authentic since there is no strong integrity check 
(and "authentication" often includes the inegrity part).

Unless there is a better suggestion I think it makes sense to view
return routability as both providing weak authentication that the sender
is the MN at its home address, and as such being authorized.

But ... perhaps I'm out in the weeds.
If you can just authenticate the identity of the MN then of course the MN
is authorized to redirect its own packets. So we might not need
to use "authorization" but instead discuss how to verify the "identity" of the 
MN.  The weak identity check is: is capable of receiving packets addressed 
to the home address (which of course any node in the path between the CN
and home address are)
When binding part of the address to a public key the identity check becomes:
the entity can prove it posseses the private key.

One can also envision other approaches to establishing the identity
but they have deployment problems such as using certificates tied
to the IP address (which means that the CA needs to verify that
the entity indeed "is" or "owns" the IP address before handing out the CERT).
Or using a DNSsec secured in6.arpa tree which contain a public keys and
the MN holds the corresponding private key. Thus the fact that the admin 
creates this entry in the DNS means that the admin has assigned that home 
address to the MN. And the in6.arpa delegation tree provides authority to do
that from the IANA and down. (But this requires DNSsec to be deployed for
all of in6.arpa.)

> As a side note, we'd also benefit from some terminology to replace 'weak
> authentication' with something that doesn't sound so negative...

"MN identity verified using return routability"?
"MN identity verified using the routability to the home address"?


> Yes, there may be some differences in the security properties as you point
> out. After I sent my previous e-mail I started thinking about the various
> replay attack scenarios and the effect of SA/no-SA on them; there may be
> differences in that as well. It is not clear to me if the sequence number in
> a BCE is zeroed when the entry is created or when the SA associated with it
> is created.

I think you need a local timestamp on the CN in the no-SA case - but 
I should try to write this down. 

The SA case might be have differences depending on the details of such a 
protocol. For instance there is potentially two different cases: the initial 
SA created after the first BU, and what happens after the CN has
discard the BCE (and the SA) but the MN retains the SA in the binding update 
list.

> As to your specific example, there's a difference depending on whether the
> MN makes an attempt to send a BU or not. If it sends a BU it will detect that
> it didn't get an ACK, and will rerun BAKE, recreating the security
> association and there is no problem. If the MN is not sending BUs (perhaps
> because it is not communicating with the CN), then the attacker is "free" to
> use the SA at will until it expires.

Assuming that the BUs sent to CNs always ask for an ACK. The current spec
seems to say that the ACKs only only required for BUs sent to the HA.
Of course, if it turns out that HA options can be sent until it is known
that the CN has a BCE then all BUs need to be acked.

  Erik



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 05:04:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19408
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 05:04:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21123;
	Wed, 24 Oct 2001 02:03:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06080;
	Wed, 24 Oct 2001 02:03:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O92Q6C015187
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:02:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O92Ppq015186
	for mobile-ip-dist; Wed, 24 Oct 2001 02:02:25 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O92L6C015179
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:02:22 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15745
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:02:14 -0700 (PDT)
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23293
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 03:02:18 -0600 (MDT)
Received: from sooguan ([172.16.3.160])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id RAA00791
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:01:09 +0800 (SGT)
Message-ID: <008e01c15c6b$4af7e2a0$a00310ac@cwc.nus.edu.sg>
From: "Eng Soo Guan" <engsg@cwc.nus.edu.sg>
To: <mobile-ip@sunroof.eng.sun.com>
References: <4B6BC00CD15FD2119E5F0008C7A419A51308EDDE@eaubrnt018.epa.ericsson.se>
Subject: Re: [mobile-ip] IPv4 and MIPv6 Transition
Date: Wed, 24 Oct 2001 17:07:22 +0800
Organization: CWC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
RE: [mobile-ip] IPv4 and MIPv6 TransitionDear Hesham,
Content-Transfer-Encoding: 7bit

Thanx for your reply.

I read the SITT and DSTM draft. My question is that MN is using DSTM. But
there are possible cases where MN cannot obtain a "IPv4 Global Addresses".
As such, the SITT and DSTM solution is not what I am looking for.

If a MN visits a foreign IPv4 network running NAT and DHCP (and no 6to4,
Tunnel Broker or 6over4 stuff), how can the MN sends a Binding Update to its
Home Agent in IPv6? Can the MN uses some configuration information it has
when it was previously at home to access the 6Bone?

The best candidate I see it Shipworm. I'm wondering if anyone has come
across other proposals.

SG
Soo Guan, Eng
R&D Engineer (Software Lab)
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
Tel (65) 8709330
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- Original Message -----
From: Hesham Soliman (EPA)
To: 'mobile-ip@sunroof.eng.sun.com'
Sent: Wednesday, October 24, 2001 3:12 PM
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition


Hello Eng,
There is another draft you can find at:
http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt
It's a WG draft in NGTRANS but it expired and I'll
resubmit it after adding some of the comments received.
Cheers,
Hesham


-----Original Message-----
From:   Eng Soo Guan [SMTP:engsg@cwc.nus.edu.sg]
Sent:   Wednesday, 24 October 2001 12:04
To:     mobile-ip@sunroof.eng.sun.com
Subject:        [mobile-ip] IPv4 and MIPv6 Transition
Dear All,
I would like to know if any work has being done with regard to 'transiting'
to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a NAT.
The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks
based on Dual-Stack Model".
I read found the NGTRANS Shipworm draft attractive to be modified for MIPv6
in a IPv4 only network behind a NAT.
Warmest regards.
SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 05:10:05 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19478
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 05:10:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA23092;
	Wed, 24 Oct 2001 02:09:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06791;
	Wed, 24 Oct 2001 02:08:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O98H6C015410
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:08:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O98HMj015409
	for mobile-ip-dist; Wed, 24 Oct 2001 02:08:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O98D6C015402
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:08:13 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02025
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:08:16 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10120
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:08:14 -0700 (PDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9O98DX10229
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:08:13 +0300
Date: Wed, 24 Oct 2001 12:08:13 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308EDDE@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110241202590.10147-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Perhaps I shouldn't comment on this, but anyway...

On Wed, 24 Oct 2001, Hesham Soliman (EPA) wrote:
> There is another draft you can find at:
> http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt
> 
> It's a WG draft in NGTRANS but it expired and I'll
> resubmit it after adding some of the comments received. 

SIIT is regarded by many to be an abomination (redefining internal 
structure like mapped-addresses) from security point-of-view among others.

It can probably solve some problems efficiently though, or else it 
wouldn't have been introduced. :-)

But it should be kept in mind that it, alone, cannot be relied on to be
sufficient for (M)IPv4 -> (M)IPv6 transition.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 05:14:58 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19543
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 05:14:58 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00221;
	Wed, 24 Oct 2001 03:13:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07307;
	Wed, 24 Oct 2001 02:13:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O9CX6C015538
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:12:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9O9CX2v015537
	for mobile-ip-dist; Wed, 24 Oct 2001 02:12:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9O9CU6C015530
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:12:30 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06759
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 02:12:32 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07217
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 03:15:35 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9O9CTg10269
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:12:29 +0300
Date: Wed, 24 Oct 2001 12:12:29 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: Re: [mobile-ip] IPv4 and MIPv6 Transition
In-Reply-To: <008e01c15c6b$4af7e2a0$a00310ac@cwc.nus.edu.sg>
Message-ID: <Pine.LNX.4.33.0110241208300.10147-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Wed, 24 Oct 2001, Eng Soo Guan wrote:
> If a MN visits a foreign IPv4 network running NAT and DHCP (and no 6to4,
> Tunnel Broker or 6over4 stuff), how can the MN sends a Binding Update to its
> Home Agent in IPv6? Can the MN uses some configuration information it has
> when it was previously at home to access the 6Bone?
> 
> The best candidate I see it Shipworm. I'm wondering if anyone has come
> across other proposals.

If you want a generic approach, Shipworm is the only way (assuming that
with "no 6to4" you meant that the NAT box doesn't run IPv6; I believe dual
stacked NAT boxes may be common in the coming years though).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 09:33:39 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28073
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 09:33:38 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09606;
	Wed, 24 Oct 2001 06:31:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12675;
	Wed, 24 Oct 2001 06:31:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ODUF6C015780
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:30:15 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9ODUFIu015779
	for mobile-ip-dist; Wed, 24 Oct 2001 06:30:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ODUB6C015772
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:30:11 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02305
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:30:14 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA18419
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:30:10 -0700 (PDT)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Oct 24 09:24:12 EDT 2001
Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA16115
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:28:18 -0400 (EDT)
Received: (from salga@localhost)
	by valjean.dnrc.bell-labs.com (8.11.6/8.8.7) id f9ODSIn05164
	for mobile-ip@sunroof.eng.sun.com; Wed, 24 Oct 2001 09:28:18 -0400
Date: Wed, 24 Oct 2001 09:28:18 -0400
From: Luca Salgarelli <salga@bell-labs.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RFC3012 interpretation yet again
Message-ID: <20011024092818.A5151@bell-labs.com>
Mail-Followup-To: mobile-ip@sunroof.eng.sun.com
References: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B99@pkcexv018.sprintspectrum.com> <002d01c15c39$2efe6600$752baec7@uf4xc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002d01c15c39$2efe6600$752baec7@uf4xc>; from bpatil@mindspring.com on Tue, Oct 23, 2001 at 10:08:40PM -0500
X-Organization: Bell Laboratories
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Basavaraj, Pat, Charlie,

actually I do have a request for clarification on another point of RFC3012.

In secion 3.1, page 4 the RFC says:

   A successful Registration Reply from the Foreign Agent MAY include a
   new Challenge value (see section 3.3).  The Mobile Node MAY use
   either the value found in the latest Advertisement, or the one found
   in the last Registration Reply from the Foreign Agent.  This approach
   enables the Mobile Node to make use of the challenge without having
   to wait for advertisements.

   A Mobile Node might receive an UNKNOWN_CHALLENGE error (see section
   9) if it moves to a new Foreign Agent that cannot validate the
   challenge provided in the Registration Request.  In such instances,
   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.

So it states that the MN MUST use a Challenge from an unsuccessful Reply.

However, in section 3.2, page 5, it also says:

   The Foreign Agent MUST NOT accept any Challenge in the Registration
   Request unless it was offered in last successful Registration Reply
   issued to the Mobile Node, or else advertised as one of the last

Which seems to go against what stated above.

In general, I think that there is the need to clarify if the FA should or
should not include a Challenge in an unsuccessful Registration Reply. If
the FA should include it, than it should be clarified whether the MN is or
is not allowed to use a Challenge obtained from an unsuccessful Reg. Reply.

Thanks
Luca

On Tue, Oct 23, 2001 at 10:08:40PM -0500, Basavaraj Patil wrote:
> We will go ahead with the revisions to the current RFC3012 to clarify
> the issue (no ambiguities and scope for misinterpretation) about computing
> the authenticator based on the challenge. 
> 
> If you believe there are other issues as well (based on implementation
> experience) with this RFC, now would be the time to raise them.
> 
> We hope to have this done fairly quickly.
> 
> Regards,
> -Basavaraj 
> 
> 
> > -----Original Message-----
> > From: owner-mobile-ip@sunroof.eng.sun.com
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Lipford, Mark
> > Sent: Tuesday, October 23, 2001 8:52 PM
> > To: 'mobile-ip@sunroof.eng.sun.com'
> > Subject: RE: [mobile-ip] RFC3012 interpretation yet again
> > 
> > 
> > As someone that has to implement this we strongly support this
> > recommendation
> > 
> > 		-----Original Message-----
> > 		From:	Mike_Borella@3com.com 
> > [mailto:Mike_Borella@3com.com]
> > 		Sent:	Tuesday, October 23, 2001 6:15 PM
> > 		To:	mobile-ip@sunroof.eng.sun.com
> > 		Subject:	[mobile-ip] RFC3012 
> > interpretation yet again
> > 
> > 		I'd like to encourage the working group and/or
> > 		draft authors to come to some sort of official decision
> > 		about the proper interpretation of section 8 of 
> > this RFC,
> > 		and make this decision public.
> > 
> > 		Basically, this would involve an announcement 
> > on this list
> > 		and a publication of an errata on the RFC editor pages.
> > 
> > 		The sooner such an errata is made public and official
> > 		the better.  Otherwise there is a chance that both
> > 		interpretations may be deployed.
> > 
> > 		Thanks in advance,
> > 		Mike
> > 		


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 09:38:12 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28403
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 09:38:12 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01520;
	Wed, 24 Oct 2001 07:36:48 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13770;
	Wed, 24 Oct 2001 06:36:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ODYr6C015890
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:34:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9ODYrGf015889
	for mobile-ip-dist; Wed, 24 Oct 2001 06:34:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ODYo6C015882
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:34:50 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27434
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:34:49 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20571
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:34:49 -0700 (PDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9ODWe920572
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:32:40 -0700 (PDT)
Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn1-371.cisco.com [10.21.97.115])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABF32247;
	Wed, 24 Oct 2001 06:34:47 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011024085254.00b828f8@mira-sjc5-9.cisco.com>
X-Sender: mramalho@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 24 Oct 2001 09:32:46 -0400
To: mobile-ip@sunroof.eng.sun.com
From: "Michael A. Ramalho" <mramalho@cisco.com>
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308EDDC@eaubrnt018.epa.er
 icsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

At 04:23 PM 10/24/2001 +1000, Hesham Soliman (EPA) wrote:
>Rajeev,  I don't know where I poorly explained my point, but  let me see 
>if this works.  Let's assume we have a tight channel with a large  RTT 
>delay and was designed with the assumption that HC  is used. Hence, there 
>is no 40 byte slack in the channel  because the assumption was always that 
>HC exists  and the IP header was not accounted for. This is  obviously for 
>the case where this channel is "tight"  due the low BW requirement of the 
>service running on it.
>
>When a device starts sending an occasional (additional) ext header  that 
>causes the payload to be split across more than  one radio frame, then 
>significant delays will be encountered  for that payload. If this is a 
>real time payload (like voice)  then the delays makes this datagram 
>useless when it  arrives at the other end. Hence service disruption 
>has  already taken place.  Note that I didn't say anything about the 
>packet being  dropped above. I will assume that the implementation  of 
>this channel will not drop the packet. So the packet  will still 
>(eventually) be delivered to the other end where  the BU is processed.
>
>Now In the above (_realistic_) scenario,  was the service disrupted due to 
>the piggybacking ? Yes  Will the BU be delivered to the other end ? Based 
>on the  assumption above: Yes  Is this radio link breaking RFC2460 ? No 
>because the  packet was not dropped.  Did the user gain anything from 
>piggybacking ? No.

I think Hesham hit the nail on the head here.

Rajeev/Charlie/(other proponents of mandatory piggybacking) - please
re-read this and comment what is wrong with Hesham's explanation.

Note that this occurs on Hesham's so-called "tight channel" - where a
low latency hop is provided over the air via a TDM-like "slotting" of a
channel for the real-time information. When these real-time packets
(typically of the expedited forwarding class) obtain bandwidth on this
channel - they get that much and no more. In fact, if you desire to
encrypt the RTP stream - the application must request the added
bandwidth for the encryption overhead (if any) - otherwise it will suffer
the same fate as the "overly large" piggybacked BU packet.

Now note that a signalling packet (a best effort or assured forwarding
type) being conveyed typically does not have this MAC layer constraint.
I am not too worried about piggybacking BUs on these packets and the
effect on the MAC layer - although piggybacking here can cause
QoS degradation due to L3 policing/scheduling/queuing (see my
posts of last week).

Now to address a concern that Charlie made ... there are some
MAC layer wireless accesses that once you "seize" you want to
hold onto and piggyback as much as you can onto them. I think
that most people on this list understand this concern - and agree
that piggybacking *can* have some merit for this case *assuming
that the piggybacked packet is of an appropriate type* (i.e., not
a media packet). However, one must argue is the extra effort
worth the effort - given average BU frequencies, the gains are
minuscule. The small (lower) delay benefit (of the piggybacked BU)
is even more dubious if you have BET capability (no flames
please ... seamoby cannot count on speedy BU updates).

Thus if piggybacking becomes an option via a destination
option - the default behavior *for media packets* must be no
piggybacking. I (and others) have argued that the default
behavior should be no piggybacking (for any packet type).
Specifying otherwise limits applicability on many known
MAC-layer schedulers (many I would think would be of
interest to Nokia - many are cellular-based, fixed bandwidth
slotted channels!).

Lastly - I think a case should be made that the destination
option is not an appropriate option. It assumes that the
real-time constrained link is at one of the (MN) ends ... and
that the MN knows about it. In general, the (bothered by the
piggybacked BU) link *could* be in a middle hop. Thus
the endpoint cannot, in general, make a piggyback BU
decision correctly for the end-to-end flow. It will not know
the constraints of any particular hop on the expedited
forwarding path!

Thus, the case has not been made IMHO that piggybacking
BUs are worth the effort and that an intelligent decision
regarding piggybacking could be made by the end node.

Can we please move on.

Michael Ramalho



Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 09:57:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29496
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 09:57:33 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16375;
	Wed, 24 Oct 2001 07:56:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18554;
	Wed, 24 Oct 2001 06:56:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ODt16C016041
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:55:01 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9ODt1wh016040
	for mobile-ip-dist; Wed, 24 Oct 2001 06:55:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ODsw6C016033
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:54:58 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06319
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:54:54 -0700 (PDT)
From: Christopher.Carroll@VerizonWireless.com
Received: from mail.verizonwireless.com (mail2.verizonwireless.com [199.74.158.61])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18234
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 06:54:53 -0700 (PDT)
Received: from mail.verizonwireless.com 
	by mail.verizonwireless.com (414/1100) with ESMTP id f9ODsoP15498
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:54:50 -0400 (EDT)
Received: by hqbedjvgwy.corp.bam.com with Internet Mail Service (5.5.2654.89)
	id <VHRKSF5Z>; Wed, 24 Oct 2001 09:54:50 -0400
Message-ID: <43E8CCEAF148D211854C00805FA72E5808318FFF@rhqnneex1.corp.bam.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Wed, 24 Oct 2001 09:54:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15C93.729D8BC0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15C93.729D8BC0
Content-Type: text/plain

Hi,
 
I originally sent this message a couple days ago, but I'm not sure if it got
thru:
 
I believe that any potential vulnerability associated with repeating the
high order challenge byte is de minimus.  In fact, repeating the high order
byte may improve the security.
 
Depending on how often the MN-AAA Authenticator is used, the likely
Challenge (FAC) size (at least in 3GPP2 networks) will be between 4 bytes
(32-bits) and 16 bytes (128-bits).  For this reason, the high order byte
will always be repeated.  However, assuming that MD5 is a cryptographically
strong one-way function, repeating the high order byte is somewhat
irrelevant.  In fact, an argument is possible that repeating the high order
byte improves the MAC's security.  I have often seen algorithm registers
(typically encryption algorithms) loaded repeatedly with keys or randomness
- primarily to provide a value other than fixed 1s or 0s in unfilled
registers.
 
According to RFC 1321, a message MACed by MD5 must be a multiple of 512
bits.  Actually, the message must be 448-bits long (64-bits is reserved to
specify the message length).  If a message is less than 448-bits long, a "1"
and string of "0" is padded to the message to extend its length to 448-bits.
Let us assume the following:
 
MN-AAA key = 16 bytes (128-bits)
MD5 hash = 16 bytes (128-bits)
FAC = 16 bytes (128-bits)
 
Therefore, the total message (in RFC 3012) to MAC (including 1 high order
byte) is 49 bytes (392 bits).  448-bits - 392 bits = 56-bits.  Thus, every
MN-AAA authenticator will be computed with the least 120-bits always known
(56-bit padding and 64-bits message length field).  Without the high order
byte repeated, then 128-bits are always known to the cryptanalyst (at least
before he sees the FAC).  
 
One way of looking at the authentication process is that the security
strength resides in the length of the secret authentication key and strength
of the cryptographic algorithm.  The challenge randomness ensures that each
authenticator is unique (no replay).  If portions of the randomness are
copied into unused registers, you still retain the uniqueness of the
original randomness.
 
If we assume that MD5 is a secure one-way function, then this authenticator
calculation is acceptable.  If you're concerned about MD5, then I suggest
SHA-1, HMAC-MD5, or HMAC-SHA-1.
 
Regards,
 
Chris
 
 
**********************************************************
Christopher Carroll
Verizon Wireless
Advanced Technology Strategy and Standards
Chair TIA TR-45 AHAG
Ph: 508-330-3401
christopher.carroll@verizonwireless.com
<mailto:christopher.carroll@verizonwireless.com> 
**********************************************************
 

------_=_NextPart_001_01C15C93.729D8BC0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html 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=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C15C71.DBED33E0">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I originally sent this message a =
couple
days ago, but I'm not sure if it got thru:<o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I believe that any potential =
vulnerability
associated with repeating the high order challenge byte is de <span
class=3DSpellE>minimus</span>.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>In
fact, repeating the high order byte may improve the security.<o:p></o:p>=
</span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Depending on how often the MN-AAA
Authenticator is used, the likely Challenge (FAC) size (at least in =
3GPP2
networks) will be between 4 bytes (32-bits) and 16 bytes =
(128-bits).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>For this reason, the high =
order byte
will always be repeated.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>However,
assuming that MD5 is a cryptographically strong one-way function, =
repeating the
high order byte is somewhat irrelevant.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>In fact, an argument is possible that repeating the high order =
byte
improves the <span class=3DSpellE>MAC's</span> security.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I have often seen algorithm =
registers
(typically encryption algorithms) loaded repeatedly with keys or =
randomness
- primarily to provide a value other than fixed 1s or 0s in unfilled
registers.<o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>According to RFC 1321, a message =
<span
class=3DSpellE>MACed</span> by MD5 must be a multiple of 512 bits.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Actually, the message must be =
448-bits
long (64-bits is reserved to specify the message length).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>If a message is less than =
448-bits long,
a "1" and string of "0" is padded to the message to
extend its length to 448-bits.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Let
us assume the following:<o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>MN-AAA key =3D 16 bytes =
(128-bits)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>MD5 hash =3D 16 bytes =
(128-bits)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>FAC =3D 16 bytes =
(128-bits)<o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Therefore, the total message (in =
RFC 3012)
to MAC (including 1 high order byte) is 49 bytes (392 bits).<span
style=3D'mso-spacerun:yes'>&nbsp; </span>448-bits - 392 bits =3D
56-bits.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Thus, every =
MN-AAA
authenticator will be computed with the least 120-bits always known =
(56-bit
padding and 64-bits message length field).<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>Without the high order byte repeated, then 128-bits are always =
known to
the cryptanalyst (at least before he sees the FAC).<span
style=3D'mso-spacerun:yes'>&nbsp; </span><o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One way of looking at the =
authentication
process is that the security strength resides in the length of the =
secret authentication
key and strength of the cryptographic algorithm.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>The challenge randomness =
ensures that
each authenticator is unique (no replay).<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>If portions of the randomness are copied into unused registers, =
you
still retain the uniqueness of the original =
randomness.<o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If we assume that MD5 is a secure =
one-way
function, then this authenticator calculation is acceptable.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>If you're concerned about MD5,
then I suggest SHA-1, HMAC-MD5, or =
HMAC-SHA-1.<o:p></o:p></span></font></p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></=
p>

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


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Chris<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>************************************=
**********************</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>Christopher =
Carroll</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>Verizon Wireless</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>Advanced Technology Strategy and =
Standards</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>Chair TIA TR-45 =
</span></font><st1:PersonName><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;mso-no-proof:
 yes'>AHAG</span></font></st1:PersonName><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>Ph: 508-330-3401</span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'><a
href=3D"mailto:christopher.carroll@verizonwireless.com">christopher.carr=
oll@verizonwireless.com</a></span></font><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;mso-no-proof:yes'>************************************=
**********************</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C15C93.729D8BC0--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 10:31:11 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01390
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 10:31:10 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15163;
	Wed, 24 Oct 2001 08:29:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25568;
	Wed, 24 Oct 2001 07:29:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OESh6C016205
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 07:28:44 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OEShSh016204
	for mobile-ip-dist; Wed, 24 Oct 2001 07:28:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OESe6C016197
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 07:28:40 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06365
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 07:28:41 -0700 (PDT)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14076
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 08:28:40 -0600 (MDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA01556
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:28:40 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 24 Oct 2001 09:26:43 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <VPB2JDLW>; Wed, 24 Oct 2001 09:28:00 -0500
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF4EE@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] RFC3012 interpretation yet again
Date: Wed, 24 Oct 2001 09:27:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15C98.12DE0890"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15C98.12DE0890
Content-Type: text/plain;
	charset="iso-8859-1"

I believe this is a valid issue.

I think a change to section 3.2 page 5 may resolve the issue by removing the
word successful and it may read as follows:

	The Foreign Agent MUST NOT accept any Challenge in the Registration
   	Request unless it was offered in the last Registration Reply
   	issued to the Mobile Node, or else advertised as one of the last
........


Ahmad Muhanna


-----Original Message-----
From: Luca Salgarelli [mailto:salga@bell-labs.com]
Sent: Wednesday, October 24, 2001 8:28 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] RFC3012 interpretation yet again


Basavaraj, Pat, Charlie,

actually I do have a request for clarification on another point of RFC3012.

In secion 3.1, page 4 the RFC says:

   A successful Registration Reply from the Foreign Agent MAY include a
   new Challenge value (see section 3.3).  The Mobile Node MAY use
   either the value found in the latest Advertisement, or the one found
   in the last Registration Reply from the Foreign Agent.  This approach
   enables the Mobile Node to make use of the challenge without having
   to wait for advertisements.

   A Mobile Node might receive an UNKNOWN_CHALLENGE error (see section
   9) if it moves to a new Foreign Agent that cannot validate the
   challenge provided in the Registration Request.  In such instances,
   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.

So it states that the MN MUST use a Challenge from an unsuccessful Reply.

However, in section 3.2, page 5, it also says:

   The Foreign Agent MUST NOT accept any Challenge in the Registration
   Request unless it was offered in last successful Registration Reply
   issued to the Mobile Node, or else advertised as one of the last

Which seems to go against what stated above.

In general, I think that there is the need to clarify if the FA should or
should not include a Challenge in an unsuccessful Registration Reply. If
the FA should include it, than it should be clarified whether the MN is or
is not allowed to use a Challenge obtained from an unsuccessful Reg. Reply.

Thanks
Luca

On Tue, Oct 23, 2001 at 10:08:40PM -0500, Basavaraj Patil wrote:
> We will go ahead with the revisions to the current RFC3012 to clarify
> the issue (no ambiguities and scope for misinterpretation) about computing
> the authenticator based on the challenge. 
> 
> If you believe there are other issues as well (based on implementation
> experience) with this RFC, now would be the time to raise them.
> 
> We hope to have this done fairly quickly.
> 
> Regards,
> -Basavaraj 
> 
> 
> > -----Original Message-----
> > From: owner-mobile-ip@sunroof.eng.sun.com
> > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Lipford, Mark
> > Sent: Tuesday, October 23, 2001 8:52 PM
> > To: 'mobile-ip@sunroof.eng.sun.com'
> > Subject: RE: [mobile-ip] RFC3012 interpretation yet again
> > 
> > 
> > As someone that has to implement this we strongly support this
> > recommendation
> > 
> > 		-----Original Message-----
> > 		From:	Mike_Borella@3com.com 
> > [mailto:Mike_Borella@3com.com]
> > 		Sent:	Tuesday, October 23, 2001 6:15 PM
> > 		To:	mobile-ip@sunroof.eng.sun.com
> > 		Subject:	[mobile-ip] RFC3012 
> > interpretation yet again
> > 
> > 		I'd like to encourage the working group and/or
> > 		draft authors to come to some sort of official decision
> > 		about the proper interpretation of section 8 of 
> > this RFC,
> > 		and make this decision public.
> > 
> > 		Basically, this would involve an announcement 
> > on this list
> > 		and a publication of an errata on the RFC editor pages.
> > 
> > 		The sooner such an errata is made public and official
> > 		the better.  Otherwise there is a chance that both
> > 		interpretations may be deployed.
> > 
> > 		Thanks in advance,
> > 		Mike
> > 		

------_=_NextPart_001_01C15C98.12DE0890
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [mobile-ip] RFC3012 interpretation yet again</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I believe this is a valid</FONT><FONT =
SIZE=3D2 FACE=3D"Arial"> issue</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think a change to section 3.2 =
pag</FONT><FONT SIZE=3D2 FACE=3D"Arial">e</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> 5</FONT> <FONT SIZE=3D2 FACE=3D"Arial">may</FONT><FONT =
SIZE=3D2 FACE=3D"Arial"> resolve the issue</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> by removing the word successful and it may read as =
follows:</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">The Foreign Agent MUST NOT accept any Challenge in the =
Registration</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
Request unless it was offered in<B></B></FONT><B> <FONT SIZE=3D2 =
FACE=3D"Arial">the</FONT></B><FONT SIZE=3D2 FACE=3D"Arial"></FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">last</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">Registration =
Reply</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
issued to the Mobile Node, or else advertised as one of the =
last</FONT><FONT SIZE=3D2 FACE=3D"Arial"> ........</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ahmad Muhanna</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Luca Salgarelli [<A =
HREF=3D"mailto:salga@bell-labs.com">mailto:salga@bell-labs.com</A>]</FON=
T>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Wednesday, October 24, 2001 =
8:28 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: [mobile-ip] RFC3012 =
interpretation yet again</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Basavaraj, Pat, Charlie,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">actually I do have a request for =
clarification on another point of RFC3012.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In secion 3.1, page 4 the RFC =
says:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; A successful Registration =
Reply from the Foreign Agent MAY include a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; new Challenge value (see =
section 3.3).&nbsp; The Mobile Node MAY use</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; either the value found =
in the latest Advertisement, or the one found</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; in the last Registration =
Reply from the Foreign Agent.&nbsp; This approach</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; enables the Mobile Node =
to make use of the challenge without having</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; to wait for =
advertisements.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; A Mobile Node might =
receive an UNKNOWN_CHALLENGE error (see section</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; 9) if it moves to a new =
Foreign Agent that cannot validate the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; challenge provided in =
the Registration Request.&nbsp; In such instances,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; the Mobile Node MUST use =
a new Challenge value in any new</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; registration, obtained =
either from an Agent Advertisement, or from a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Challenge extension to =
the Registration Reply containing the error.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So it states that the MN MUST use a =
Challenge from an unsuccessful Reply.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">However, in section 3.2, page 5, it =
also says:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; The Foreign Agent MUST =
NOT accept any Challenge in the Registration</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Request unless it was =
offered in last successful Registration Reply</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; issued to the Mobile =
Node, or else advertised as one of the last</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Which seems to go against what stated =
above.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In general, I think that there is the =
need to clarify if the FA should or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should not include a Challenge in an =
unsuccessful Registration Reply. If</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the FA should include it, than it =
should be clarified whether the MN is or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is not allowed to use a Challenge =
obtained from an unsuccessful Reg. Reply.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Luca</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Tue, Oct 23, 2001 at 10:08:40PM =
-0500, Basavaraj Patil wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; We will go ahead with the =
revisions to the current RFC3012 to clarify</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the issue (no ambiguities and =
scope for misinterpretation) about computing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the authenticator based on the =
challenge. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; If you believe there are other =
issues as well (based on implementation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; experience) with this RFC, now =
would be the time to raise them.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; We hope to have this done fairly =
quickly.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; -Basavaraj </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; From: =
owner-mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; [<A =
HREF=3D"mailto:owner-mobile-ip@sunroof.eng.sun.com">mailto:owner-mobile-=
ip@sunroof.eng.sun.com</A>]On Behalf Of Lipford, Mark</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Sent: Tuesday, October 23, =
2001 8:52 PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; To: =
'mobile-ip@sunroof.eng.sun.com'</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Subject: RE: [mobile-ip] =
RFC3012 interpretation yet again</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; As someone that has to =
implement this we strongly support this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; recommendation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From:&nbsp;&nbsp; =
Mike_Borella@3com.com </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; [<A =
HREF=3D"mailto:Mike_Borella@3com.com">mailto:Mike_Borella@3com.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent:&nbsp;&nbsp; Tuesday, =
October 23, 2001 6:15 PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp; =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [mobile-ip] RFC3012 =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; interpretation yet =
again</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'd like to encourage the =
working group and/or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft authors to come to =
some sort of official decision</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; about the proper =
interpretation of section 8 of </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; this RFC,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and make this decision =
public.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Basically, this would =
involve an announcement </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; on this list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and a publication of an =
errata on the RFC editor pages.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The sooner such an errata is =
made public and official</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the better.&nbsp; Otherwise =
there is a chance that both</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interpretations may be =
deployed.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thanks in advance,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15C98.12DE0890--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 10:37:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01678
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 10:37:39 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08039;
	Wed, 24 Oct 2001 07:36:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27274;
	Wed, 24 Oct 2001 07:36:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OEZK6C016328
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 07:35:20 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OEZK7X016327
	for mobile-ip-dist; Wed, 24 Oct 2001 07:35:20 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OEZG6C016320
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 07:35:17 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12969
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 07:35:18 -0700 (PDT)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20070
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 07:35:17 -0700 (PDT)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09YW4Y>; Wed, 24 Oct 2001 10:34:19 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA90@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition
Date: Wed, 24 Oct 2001 10:34:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I also believe that this is an important work item to persue, in view of the
fact that 3GPP has mandated using IPv6 as transport over the UTRAN. IPv6 is
also considered by other SDO's in other cellular networks as well. Thus, in
order to interconnect these systems, to the IP backbone, which currently
runs IPv4, solutions like the "dual stack model" will be very important.

I wonder if anybody can provide information if these knids of protocols is
currently implemented commercially.

-Sharif.

-----Original Message-----
From: Eng Soo Guan [mailto:engsg@cwc.nus.edu.sg]
Sent: Tuesday, October 23, 2001 10:04 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] IPv4 and MIPv6 Transition


Dear All,

I would like to know if any work has being done with regard to 'transiting'
to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a NAT.

The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks
based on Dual-Stack Model".

I read found the NGTRANS Shipworm draft attractive to be modified for MIPv6
in a IPv4 only network behind a NAT.

Warmest regards.

SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 11:35:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04067
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 11:35:42 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14966;
	Wed, 24 Oct 2001 09:34:58 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23011;
	Wed, 24 Oct 2001 08:34:43 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OFXT6C016504
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 08:33:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OFXTSF016503
	for mobile-ip-dist; Wed, 24 Oct 2001 08:33:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OFXQ6C016496
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 08:33:26 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29363
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 08:33:28 -0700 (PDT)
From: Mike_Borella@3com.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16016
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:37:39 -0600 (MDT)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9OFUWu12020
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 08:30:32 -0700 (PDT)
Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9OFXLS05167
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 08:33:21 -0700 (PDT)
Subject: RE: [mobile-ip] RFC3012 interpretation yet again
To: mobile-ip@sunroof.eng.sun.com
Date: Wed, 24 Oct 2001 10:33:05 -0500
Message-ID: <OFB5B65262.98361C5B-ON86256AEF.0055467C@3com.com>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Well, since you asked...  This is not a purely technical issue, but
I think it would help a lot if RFC3012bis included a ladder diagram
of a canonical call flow.  Right now each element's processing
is discussed in isolation and I believe that an appendix showing the
order in which events typically occur would help.

Mike





"Basavaraj Patil" <bpatil@mindspring.com> on 10/23/2001 10:08:40 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  "Basavaraj Patil" <bpatil@mindspring.com>


To:   mobile-ip@sunroof.eng.sun.com
cc:   pcalhoun@bstormnetworks.com, charliep@iprg.nokia.com (Mike
      Borella/MW/US/3Com)
Subject:  RE: [mobile-ip] RFC3012 interpretation yet again



We will go ahead with the revisions to the current RFC3012 to clarify
the issue (no ambiguities and scope for misinterpretation) about computing
the authenticator based on the challenge.

If you believe there are other issues as well (based on implementation
experience) with this RFC, now would be the time to raise them.

We hope to have this done fairly quickly.

Regards,
-Basavaraj


> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com
> [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Lipford, Mark
> Sent: Tuesday, October 23, 2001 8:52 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] RFC3012 interpretation yet again
>
>
> As someone that has to implement this we strongly support this
> recommendation
>
>         -----Original Message-----
>         From:     Mike_Borella@3com.com
> [mailto:Mike_Borella@3com.com]
>         Sent:     Tuesday, October 23, 2001 6:15 PM
>         To:  mobile-ip@sunroof.eng.sun.com
>         Subject:  [mobile-ip] RFC3012
> interpretation yet again
>
>         I'd like to encourage the working group and/or
>         draft authors to come to some sort of official decision
>         about the proper interpretation of section 8 of
> this RFC,
>         and make this decision public.
>
>         Basically, this would involve an announcement
> on this list
>         and a publication of an errata on the RFC editor pages.
>
>         The sooner such an errata is made public and official
>         the better.  Otherwise there is a chance that both
>         interpretations may be deployed.
>
>         Thanks in advance,
>         Mike
>






From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 12:10:00 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05039
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 12:09:59 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19235;
	Wed, 24 Oct 2001 10:09:04 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17966;
	Wed, 24 Oct 2001 09:08:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OG7l6C016651
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:07:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OG7lQO016650
	for mobile-ip-dist; Wed, 24 Oct 2001 09:07:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OG7i6C016643
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:07:44 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00069
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:07:46 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17751
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 10:07:45 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA27078
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:07:45 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9OG7ic13299
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 09:07:44 -0700
X-mProtect:  Wed, 24 Oct 2001 09:07:44 -0700 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141130.americas.nokia.com (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd7V4lYd; Wed, 24 Oct 2001 09:07:42 PDT
Message-ID: <3BD6E74E.322BEC50@iprg.nokia.com>
Date: Wed, 24 Oct 2001 09:07:42 -0700
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion
References: <4.3.2.7.2.20011024085254.00b828f8@mira-sjc5-9.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Michael,

3 comments in line.

"Michael A. Ramalho" wrote:

> At 04:23 PM 10/24/2001 +1000, Hesham Soliman (EPA) wrote:
> >Rajeev,  I don't know where I poorly explained my point, but  let me see
> >if this works.  Let's assume we have a tight channel with a large  RTT
> >delay and was designed with the assumption that HC  is used. Hence, there
> >is no 40 byte slack in the channel  because the assumption was always that
> >HC exists  and the IP header was not accounted for. This is  obviously for
> >the case where this channel is "tight"  due the low BW requirement of the
> >service running on it.

This is a somewhat dubious set up. Hesham seems to forget that you have to
establish HC or re-establish it if you lose some packets and the compression
state due to fading in the air interface. Meaning that:
if you use HC on such a channel (and you would because of scarce bandwidth),
then you automatically have some slack in the channel.

>
> >
> >When a device starts sending an occasional (additional) ext header  that
> >causes the payload to be split across more than  one radio frame, then
> >significant delays will be encountered  for that payload. If this is a
> >real time payload (like voice)  then the delays makes this datagram
> >useless when it  arrives at the other end. Hence service disruption
> >has  already taken place.  Note that I didn't say anything about the
> >packet being  dropped above. I will assume that the implementation  of
> >this channel will not drop the packet. So the packet  will still
> >(eventually) be delivered to the other end where  the BU is processed.
> >
> >Now In the above (_realistic_) scenario,  was the service disrupted due to
> >the piggybacking ? Yes  Will the BU be delivered to the other end ? Based
> >on the  assumption above: Yes  Is this radio link breaking RFC2460 ? No
> >because the  packet was not dropped.  Did the user gain anything from
> >piggybacking ? No.
>
> I think Hesham hit the nail on the head here.

Well, you did not read all of Rajeev and Hesham's exchange. Had you kept going,

you would have notice that this argument (variability in packet sizes in tight
channels)
applies to IPv6 destination options. According to Hesham's assumption, you
cannot add a
destination option to a header to a CN behind such a channel. Destination
options
would be disruptive for the same
reason. For the sake of a connection-oriented channel that is allocated beyond
common
sense (so tight as not to allow HC re-establishment), should we disallow IPv6
in
packet networks?  Fixed packet size networks exist, it is called ATM. It did
not take
over the world because fixed packet size denies flexibility and modularity.


> Rajeev/Charlie/(other proponents of mandatory piggybacking) - please
> re-read this and comment what is wrong with Hesham's explanation.
>

Mandatory piggybacking? I was under the impression that most people in this
exchange where pro-choice. Disallow piggybacking if you have one of these
L2 issues Hesham/you/(other ATM proponents :-) mention, use piggybacking
when you can benefit from it.

As you say, let's please move on with the common sense solution.

Cedric.





From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 13:31:46 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07754
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 13:31:45 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06992;
	Wed, 24 Oct 2001 10:30:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22333;
	Wed, 24 Oct 2001 10:30:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OHT46C016891
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 10:29:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OHT4PV016890
	for mobile-ip-dist; Wed, 24 Oct 2001 10:29:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OHSx6C016883
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 10:28:59 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23861
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 10:29:01 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29871
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 11:34:02 -0600 (MDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9OHTTQ07950
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:29:32 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56cb17fff3ac12f257079@davir04nok.americas.nokia.com>;
 Wed, 24 Oct 2001 12:28:55 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 24 Oct 2001 12:27:53 -0500
content-class: urn:content-classes:message
Subject: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Wed, 24 Oct 2001 13:27:52 -0400
Message-ID: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15CB1.361548AC"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [mobile-ip] MIPv6 - Focus of the security discussion
Thread-Index: AcFcVG4f9c6S1MhFEdWxLwAIx6TWeAAVmrRA
From: "Koodli Rajeev (NRC/MtView)" <rajeev.koodli@nokia.com>
To: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        <mobile-ip@sunroof.eng.sun.com>
Cc: "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
X-OriginalArrivalTime: 24 Oct 2001 17:27:53.0018 (UTC) FILETIME=[3620F1A0:01C15CB1]
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C15CB1.361548AC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
Hello Hesham,
=20
this is continuing to be a long discussion. Anyway, I think we are
probably converging on some issues. Let me make a (bold) try in
summarizing the discussion.
=20
- "tight channel" is the main focus.=20
- I say on such a channel, HC is likely used. You have concurred. My
claim is HC will work with piggybacking. You seem to agree. However,
there is something below to iron out.
- My position is that if a link supports IPv6, destination option is a
given. You seem to agree. I say this means it is supporting
piggybacking. You say if it does, it has performance issues. I say we
don't design based on a link's performance..
- Service disruption is moot to me. See comments below.
=20
Finally, my position is that removing piggybacking is not an option.
However, including some text in the draft stating that some links MAY
have performance issues to consider when piggybacking is fine with me. I
think this may be the way forward.
=20
Please see additional comments below.
=20
Regards,
=20
-Rajeev
=20
=20


=20

	Rajeev,=20

I don't know where I poorly explained my point, but=20
let me see if this works.=20
Let's assume we have a tight channel with a large=20
RTT delay and was designed with the assumption that HC=20
is used. Hence, there is no 40 byte slack in the channel=20
because the assumption was always that HC exists=20
and the IP header was not accounted for. This is=20
obviously for the case where this channel is "tight"=20
due the low BW requirement of the service running on it.=20


[Rajeev] Since HC is used, how was the context initialized in the first
place ? You have to send IR packets first. So, the tight channel must
have means for initializing the context. Furthermore, it must have means
to re-establish it when necessary.=20

When a device starts sending an occasional (additional) ext header=20
that causes the payload to be split across more than=20
one radio frame, then significant delays will be encountered=20
for that payload. If this is a real time payload (like voice)=20
then the delays makes this datagram useless when it=20
arrives at the other end. Hence service disruption has=20
already taken place.=20


[Rajeev]  When HC is used, the payload should not be split. When it is
not used, what is the magnitude of this service disruption ? One
packetization interval ? Real-time applications work with play-back
adjustments schemes that account for the inherent jitter (i.e.,
variation in delay for back to back packets) in packet-switched
networks. So, your "performance" argument is moot.

=20

	Note that I didn't say anything about the packet being=20
dropped above. I will assume that the implementation=20
of this channel will not drop the packet. So the packet=20
will still (eventually) be delivered to the other end where=20
the BU is processed.=20

Now In the above (_realistic_) scenario,=20
was the service disrupted due to the piggybacking ? Yes=20
Will the BU be delivered to the other end ? Based on the=20
assumption above: Yes=20
Is this radio link breaking RFC2460 ? No because the=20
packet was not dropped.=20
Did the user gain anything from piggybacking ? No.=20


[Rajeev]  This is not a good enough reason to _remove_ piggybacking. I
see no quantifiably significant service disruption. By piggybacking, we
are only making use of base IPv6 which the link claims to support.

=20

	So I don't understand why you're in favour of mandating=20
piggybacking.=20

	This covers some of your answers, more comments below:=20


	        I am in favor of option 1 you mention below. This is in
line with
general IP protocol design. Any performance considerations could be
stated in the draft in some form.
For instance, we could state that "..if the BAck does not return after
transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
configurable parameter.=20

	=3D> I don't think that's a good idea. It shouldn't take a few BUs
and dropped packets for us to "guess" whether piggybacking
is needed or not.=20

	[Rajeev:]There was an e-mail earlier from Greg Daley on how to
do this better.=20

=3D> No that doesn't solve the problem. Michael already=20
responded to that.=20


[Rajeev]  I will have to look into it for more details. If channel
asymmetry is the issue, that channel should still consider if it is
supporting IPv6.

=20


	In fact I don't know why you say it's in line with general IP
protocol
design ?? Could you explain what that is ?
In the Fast Handoffs work for v4 and v6, the design teams have
been modifying parts of MIP to -for example- get the AR to
start forwarding before receiving a BU, why was this acceptable ?
Why didin't we just say link layers should be desinged to allow
for MIP signalling ?


	[Rajeev]  Well, do they eliminate piggybacking ? How do they
violate base IPv6 specification ? =20

=3D> I didn't refer to piggybacking ! They violate MIPv6 which clearly=20
states that forwarding to a new CoA must be done based on=20
the reception of an authenticated BU. They don't violate=20
the base IPv6, but MIPv6. Is that allowed ? If so then I=20
don't understand the "violation" argument.=20


[Rajeev]  This is a good argument to discuss. In FMIPv6 at least, if you
keep the old CoA, there is no requirement for BU. If the network does
host routing, it is not violating anything either. So, I am not sure
what they are violating.. On the other hand, if we remove piggybacking
on a link that claims to support IPv6, that is a violation. We are
designing protocols based _solely_ on _a_ link's idiosyncrasies. That
seems like violation to me..

=20

	=20
Well some of us did, but the WG decided that both philosophies
are needed to support existing link layers. BETH is one example.
So I don't think your logic is in line with the previous WG decisions
on similar topics.


	[Rajeev] Performance optimizations are fine as long as the base
protocol is not violated. Here, by saying that we will disallow
piggybacking, you are saying that we don't support IPv6 destination
options in arbitrary packets. =20

=3D> The example I showed above does NOT disallow=20
piggybacking, but it shows that it can be disruptive to=20
the services. Anyway, I don't think your charaterisation=20
is accurate. Destination options are certainly supported=20
(the Home address option is for one). The point is that,=20
the behaviour by which a node signals to the other end=20
needs to be optimised to minimise service disruption.=20
In this case the optimisation is to send the MIPv6 signalling=20
message on a separate channel, hence eliminate piggybacking.=20


[Rajeev]  If you are, by saying we do not disallow piggybacking,
referring to having piggybacking but make a recommendation that some
links MAY have performance issues, I can live with that. Regarding your
statement above concerning Destination Option: I specifically mentioned
that a link has to be able to support destination option in _arbitrary_
packets. I know I have a lot to learn, but please don't disrespect
whatever I already happen to know!

There is nothing wrong with sending DST options in separate=20
IP packets. RFC 2460 did not say that all the information=20
MUST be piggybacked.=20


[Rajeev]  Right. I am not saying DON'T send BU in separate packets. I
_am_ saying that that's not the only way to send a BU. Piggybacking is
use of destination option, and if a link supports IPv6, I see no reason
why I must not use it!

=20

	        Hesham=20


------_=_NextPart_001_01C15CB1.361548AC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>

<META content=3D"MSHTML 5.00.3013.2600" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D750194216-24102001>Hello=20
Hesham,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D750194216-24102001>this=20
is continuing to be a long discussion. Anyway, I think we are probably=20
converging on some issues. Let me make a (bold) try in summarizing the=20
discussion.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D750194216-24102001>-=20
"tight channel" is the main focus. </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D750194216-24102001>- I=20
say on such a channel, HC is likely used. You have concurred. My claim =
is HC=20
will work with piggybacking. You seem to agree. However, there is =
something=20
below to iron out.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D750194216-24102001>- My=20
position is that if a link supports IPv6, destination option is a given. =
You=20
seem to agree. I say this means it is supporting piggybacking. You say =
if it=20
does, it has performance issues. I say we don't design based on a link's =

performance..</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D750194216-24102001>-=20
Service disruption is moot to me. See&nbsp;comments =
below.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001>Finally, my position is that removing =
piggybacking is=20
not an option. However,&nbsp;including some text in the draft stating =
that some=20
links MAY have performance issues to consider when piggybacking is fine =
with me.=20
I think this may be the way forward.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D750194216-24102001>Please=20
see additional comments below.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001>-Rajeev</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D750194216-24102001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2><BR>&nbsp;</DIV></FONT>
  <UL>
    <UL>
      <P><FONT color=3D#0000ff face=3DArial size=3D2>Rajeev, =
</FONT></P></UL></UL>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>I don't know where I =
poorly explained=20
  my point, but </FONT><BR><FONT color=3D#0000ff face=3DArial =
size=3D2>let me see if=20
  this works. </FONT><BR><FONT color=3D#0000ff face=3DArial =
size=3D2>Let's assume we=20
  have a tight channel with a large </FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>RTT delay and was designed with the assumption that HC =
</FONT><BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2>is used. Hence, there is no 40 =
byte slack in=20
  the channel</FONT> <BR><FONT color=3D#0000ff face=3DArial =
size=3D2>because the=20
  assumption was always that HC exists</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>and the IP header was not accounted for. This is =
</FONT><BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2>obviously for the case where =
this channel is=20
  "tight"</FONT> <BR><FONT color=3D#0000ff face=3DArial size=3D2>due the =
low BW=20
  requirement of the service running on it.</FONT> <BR><FONT =
color=3D#0000ff=20
  face=3DArial size=3D2><SPAN =
class=3D750194216-24102001></SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001>[Rajeev]&nbsp;Since HC is used, how was the =
context=20
  initialized in the first place ? You have to send IR packets first. =
So, the=20
  tight channel must have means for initializing the context. =
Furthermore, it=20
  must have means to re-establish it=20
when&nbsp;necessary.&nbsp;</SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>When a device starts =
sending an=20
  occasional (additional) ext header</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>that causes the payload to be split across more than</FONT> =
<BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2>one radio frame, then =
significant delays will=20
  be encountered</FONT> <BR><FONT color=3D#0000ff face=3DArial =
size=3D2>for that=20
  payload. If this is a real time payload (like voice)</FONT> <BR><FONT=20
  face=3DArial><FONT color=3D#0000ff size=3D2>then the delays makes this =
datagram=20
  useless when it <BR>arrives at the other end. Hence service disruption =
has=20
  <BR></FONT></FONT><FONT size=3D2><FONT color=3D#0000ff><FONT =
face=3DArial>already=20
  taken place. <BR><SPAN=20
  class=3D750194216-24102001></SPAN></FONT></FONT></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D750194216-24102001>[Rajeev]&nbsp;&nbsp;When HC is used, the =
payload=20
  should not be split. When it is not used, what is the magnitude of =
this=20
  service disruption ? One packetization interval ? Real-time =
applications work=20
  with play-back adjustments schemes that account for the inherent =
jitter (i.e.,=20
  variation in delay for back to back packets) in packet-switched =
networks. So,=20
  your "performance" argument is moot.</SPAN></FONT></FONT></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
  <UL>
    <UL>
      <P><FONT color=3D#0000ff face=3DArial size=3D2>Note that I didn't =
say anything=20
      about the packet being </FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
      size=3D2>dropped above. I will assume that the implementation=20
      </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>of this =
channel will not=20
      drop the packet. So the packet</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
      size=3D2>will still (eventually) be delivered to the other end =
where=20
      </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>the BU is=20
      processed.</FONT> </P></UL></UL>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>Now In the above =
(_realistic_)=20
  scenario, </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>was =
the service=20
  disrupted due to the piggybacking ? Yes</FONT> <BR><FONT =
color=3D#0000ff=20
  face=3DArial size=3D2>Will the BU be delivered to the other end ? =
Based on=20
  the</FONT> <BR><FONT color=3D#0000ff face=3DArial size=3D2>assumption =
above:=20
  Yes</FONT> <BR><FONT face=3DArial><FONT color=3D#0000ff size=3D2>Is =
this radio link=20
  breaking RFC2460 ? No because the <BR>packet was not dropped.=20
  <BR></FONT></FONT><FONT size=3D2><FONT color=3D#0000ff><FONT =
face=3DArial>Did the=20
  user gain anything from piggybacking ? No. <BR><SPAN=20
  class=3D750194216-24102001></SPAN></FONT></FONT></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D750194216-24102001>[Rajeev]&nbsp;&nbsp;This is not a good =
enough reason=20
  to _remove_ piggybacking. I see no quantifiably significant service=20
  disruption. By piggybacking, we are only making use of base IPv6 which =
the=20
  link claims to support.</SPAN></FONT></FONT></FONT></P>
  <P><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
  <UL>
    <UL>
      <P><FONT color=3D#0000ff face=3DArial size=3D2>So I don't =
understand why you're=20
      in favour of mandating </FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
      size=3D2>piggybacking. </FONT></P>
      <P><FONT color=3D#0000ff face=3DArial size=3D2>This covers some of =
your answers,=20
      more comments below:</FONT> </P><BR>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial =
size=3D2>I am=20
      in favor of option 1 you mention below. This is in line =
with</FONT><FONT=20
      face=3DArial><BR></FONT><FONT face=3DArial size=3D2>general IP =
protocol design.=20
      Any performance considerations could be</FONT><FONT=20
      face=3DArial><BR></FONT><FONT face=3DArial size=3D2>stated in the =
draft in some=20
      form.</FONT><FONT face=3DArial><BR></FONT><FONT face=3DArial =
size=3D2>For=20
      instance, we could state that "..if the BAck does not return=20
      after</FONT><FONT face=3DArial><BR></FONT><FONT face=3DArial=20
      size=3D2>transmitting a Binding Update BU_PIGGY_TIMES, the sending =
node must=20
      send</FONT><FONT face=3DArial><BR></FONT><FONT face=3DArial =
size=3D2>a BU=20
      without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is=20
      a</FONT><FONT face=3DArial><BR></FONT><FONT face=3DArial =
size=3D2>configurable=20
      parameter.</FONT><FONT face=3DArial> </FONT></P></UL>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; I don't think =
that's a good=20
    idea. It shouldn't take a few BUs</FONT><FONT =
face=3DArial><BR></FONT><FONT=20
    color=3D#0000ff face=3DArial size=3D2>and dropped packets for us to =
"guess"=20
    whether piggybacking</FONT><BR><FONT color=3D#0000ff face=3DArial =
size=3D2>is=20
    needed or not.</FONT><FONT face=3DArial> </FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>[Rajeev:]There was an =

    e-mail&nbsp;earlier from Greg Daley on how to do this better.</FONT> =
</P></UL>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; No that doesn't =
solve the=20
  problem. Michael already </FONT><BR><FONT color=3D#0000ff face=3DArial =

  size=3D2>responded to that.</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2><SPAN class=3D750194216-24102001></SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001>[Rajeev]&nbsp;&nbsp;I will have to look =
into it for=20
  more details. If channel asymmetry is the issue, that channel should =
still=20
  consider if it is supporting IPv6.</SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001></SPAN></FONT>&nbsp;</P>
  <UL><BR>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>In fact I don't know =
why you say=20
    it's in line with general IP protocol</FONT><FONT=20
    face=3DArial><BR></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2>design ?? Could=20
    you explain what that is ?</FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>In the Fast Handoffs work for v4 and v6, the design teams=20
    have</FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>been =
modifying parts of=20
    MIP to -for example- get the AR to</FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>start forwarding before receiving a BU, why was this =
acceptable=20
    ?</FONT><FONT face=3DArial><BR></FONT><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>Why didin't we just say link layers should be desinged to=20
    allow</FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>for MIP =
signalling=20
    ?</FONT><FONT face=3DArial><BR></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial =
size=3D2>[Rajeev]&nbsp;&nbsp;Well, do they=20
    eliminate piggybacking ? How do they violate base IPv6 specification =
?&nbsp;=20
    </FONT></P></UL>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; I didn't refer =
to piggybacking=20
  ! They violate MIPv6 which clearly </FONT><BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>states that forwarding to a new CoA must be done based on=20
  </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>the reception =
of an=20
  authenticated BU. They don't violate</FONT> <BR><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>the base IPv6, but MIPv6. Is that allowed ? If so then I=20
  </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>don't =
understand the=20
  "violation" argument.</FONT> <BR><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
  class=3D750194216-24102001></SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001>[Rajeev]&nbsp;&nbsp;This is a good argument =
to=20
  discuss. In FMIPv6 at least, if you keep the old CoA, there is no =
requirement=20
  for BU. If the network does host routing, it is not violating anything =
either.=20
  So, I am not sure what they are violating.. On the other hand, if we =
remove=20
  piggybacking on a link that claims to support IPv6, that is a =
violation. We=20
  are designing protocols based _solely_ on _a_ link's idiosyncrasies. =
That=20
  seems like violation to me..</SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001></SPAN></FONT>&nbsp;</P>
  <UL>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>&nbsp;<BR>Well some =
of us did, but=20
    the WG decided that both philosophies<BR>are needed to support =
existing link=20
    layers. BETH is one example.<BR>So I don't think your logic is in =
line with=20
    the previous WG decisions</FONT><FONT face=3DArial><BR></FONT><FONT=20
    color=3D#0000ff face=3DArial size=3D2>on similar topics.</FONT><FONT =

    face=3DArial><BR></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2>[Rajeev] Performance =
optimizations=20
    are&nbsp;fine as long as the base protocol is not =
violated.&nbsp;Here, by=20
    saying that we will disallow piggybacking, you are saying that we =
don't=20
    support IPv6 destination options in arbitrary packets. =
&nbsp;</FONT></P></UL>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>=3D&gt; The example I =
showed above does=20
  NOT disallow </FONT><BR><FONT color=3D#0000ff face=3DArial =
size=3D2>piggybacking,=20
  but it shows that it can be disruptive to</FONT> <BR><FONT =
color=3D#0000ff=20
  face=3DArial size=3D2>the services. Anyway, I don't think your=20
  charaterisation</FONT> <BR><FONT color=3D#0000ff face=3DArial =
size=3D2>is accurate.=20
  Destination options are certainly supported</FONT> <BR><FONT =
color=3D#0000ff=20
  face=3DArial size=3D2>(the Home address option is for one). The point =
is that,=20
  </FONT><BR><FONT color=3D#0000ff face=3DArial size=3D2>the behaviour =
by which a node=20
  signals to the other end</FONT> <BR><FONT color=3D#0000ff face=3DArial =

  size=3D2>needs to be optimised to minimise service disruption. =
</FONT><BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2>In this case the optimisation is =
to send the=20
  MIPv6 signalling</FONT> <BR><FONT color=3D#0000ff face=3DArial =
size=3D2>message on a=20
  separate channel, hence eliminate piggybacking.</FONT> <BR><FONT =
color=3D#0000ff=20
  face=3DArial size=3D2><SPAN =
class=3D750194216-24102001></SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001>[Rajeev]&nbsp;&nbsp;If you are, by saying =
we do not=20
  disallow piggybacking, referring to having piggybacking but make a=20
  recommendation that some links MAY have performance issues, I can live =
with=20
  that. </SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001>Regarding your statement above concerning =
Destination=20
  Option: I specifically mentioned that a link has to be able to support =

  destination option in _arbitrary_ packets. I know I have a lot to =
learn, but=20
  please don't disrespect whatever I already happen to =
know!</SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>There is nothing wrong =
with sending=20
  DST options in separate</FONT> <BR><FONT color=3D#0000ff face=3DArial =
size=3D2>IP=20
  packets. RFC 2460 did not say that all the information</FONT> =
<BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2>MUST be piggybacked.</FONT> =
<BR><FONT=20
  color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001></SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001>[Rajeev]&nbsp;&nbsp;Right. I am not saying =
DON'T send=20
  BU in separate packets. I _am_ saying that that's not the only way to =
send a=20
  BU. Piggybacking is use of destination option, and if a link supports =
IPv6, I=20
  see no reason why I must not use it!</SPAN></FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D750194216-24102001></SPAN></FONT>&nbsp;</P>
  <UL>
    <P><FONT color=3D#0000ff face=3DArial=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Hesham</FONT><FONT=20
    face=3DArial> </FONT></P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15CB1.361548AC--


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 14:43:31 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11104
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 14:43:30 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11380;
	Wed, 24 Oct 2001 12:42:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10256;
	Wed, 24 Oct 2001 11:42:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OIfZ6C017136
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 11:41:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OIfZxB017135
	for mobile-ip-dist; Wed, 24 Oct 2001 11:41:35 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OIfV6C017128
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 11:41:31 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29691
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 11:41:23 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13670
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:46:32 -0600 (MDT)
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA28574;
	Wed, 24 Oct 2001 13:41:19 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9OIfID28919;
	Wed, 24 Oct 2001 13:41:18 -0500 (CDT)
Message-ID: <3BD70CDE.64C78548@alcatel.com>
Date: Wed, 24 Oct 2001 13:47:58 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of 
 the security discussion
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
Content-Type: multipart/alternative;
 boundary="------------1B402B30749FA5735C752FA2"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

--------------1B402B30749FA5735C752FA2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Rajeev,
  In your text, would it be OK to replace
piggybacking
with
piggybacking BU/Back?

Regards,

"Koodli Rajeev (NRC/MtView)" wrote:

>   Hello Hesham,this is continuing to be a long discussion. Anyway, I
> think we are probably converging on some issues. Let me make a (bold)
> try in summarizing the discussion.- "tight channel" is the main
> focus. - I say on such a channel, HC is likely used. You have
> concurred. My claim is HC will work with piggybacking. You seem to
> agree. However, there is something below to iron out.- My position is
> that if a link supports IPv6, destination option is a given. You seem
> to agree. I say this means it is supporting piggybacking. You say if
> it does, it has performance issues. I say we don't design based on a
> link's performance..- Service disruption is moot to me. See comments
> below.Finally, my position is that removing piggybacking is not an
> option. However, including some text in the draft stating that some
> links MAY have performance issues to consider when piggybacking is
> fine with me. I think this may be the way forward.--

Behcet

--------------1B402B30749FA5735C752FA2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Rajeev,
<br>&nbsp; In your text, would it be OK to replace
<br>piggybacking
<br>with
<br>piggybacking BU/Back?
<p>Regards,
<p>"Koodli Rajeev (NRC/MtView)" wrote:
<blockquote TYPE=CITE>&nbsp;&nbsp;<span class=750194216-24102001><font face="Arial"><font color="#0000FF"><font size=-1>Hello
Hesham,</font></font></font></span><span 
class=750194216-24102001></span><span class=750194216-24102001><font face="Arial"><font color="#0000FF"><font size=-1>this
is continuing to be a long discussion. Anyway, I think we are probably
converging on some issues. Let me make a (bold) try in summarizing the
discussion.</font></font></font></span><span 
class=750194216-24102001></span><span class=750194216-24102001><font face="Arial"><font color="#0000FF"><font size=-1>-
"tight channel" is the main focus.&nbsp;</font></font></font></span><span class=750194216-24102001><font face="Arial"><font color="#0000FF"><font size=-1>-
I say on such a channel, HC is likely used. You have concurred. My claim
is HC will work with piggybacking. You seem to agree. However, there is
something below to iron out.</font></font></font></span><span class=750194216-24102001><font face="Arial"><font color="#0000FF"><font size=-1>-
My position is that if a link supports IPv6, destination option is a given.
You seem to agree. I say this means it is supporting piggybacking. You
say if it does, it has performance issues. I say we don't design based
on a link's performance..</font></font></font></span><span class=750194216-24102001><font face="Arial"><font color="#0000FF"><font size=-1>-
Service disruption is moot to me. See comments below.</font></font></font></span><span 
class=750194216-24102001></span><span 
class=750194216-24102001><font face="Arial"><font color="#0000FF"><font size=-1>Finally,
my position is that removing piggybacking is not an option. However, including
some text in the draft stating that some links MAY have performance issues
to consider when piggybacking is fine with me. I think this may be the
way forward.</font></font></font></span><span 
class=750194216-24102001></span>--</blockquote>
Behcet</html>

--------------1B402B30749FA5735C752FA2--



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 15:41:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12712
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 15:41:42 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01650;
	Wed, 24 Oct 2001 13:41:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28279;
	Wed, 24 Oct 2001 12:40:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJbo6C017331
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:37:50 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OJbndY017330
	for mobile-ip-dist; Wed, 24 Oct 2001 12:37:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJbk6C017323
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:37:46 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27691
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:37:48 -0700 (PDT)
Received: from smtp6.andrew.cmu.edu (SMTP6.ANDREW.CMU.EDU [128.2.10.86])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17898
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:37:48 -0700 (PDT)
Received: from UNIX1.ANDREW.CMU.EDU (UNIX1.ANDREW.CMU.EDU [128.2.11.201])
	(user=asamar mech=KERBEROS_V4 (0 bits))
	by smtp6.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f9OJbi6E023876;
	Wed, 24 Oct 2001 15:37:44 -0400
Date: Wed, 24 Oct 2001 15:37:44 -0400 (EDT)
From: Asad Samar <asamar@andrew.cmu.edu>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Brenda Liu <bhliu@andrew.cmu.edu>, Humayun Latif <hlatif@andrew.cmu.edu>
Subject: [mobile-ip] HA compromises
Message-ID: <Pine.GSO.4.33L-022.0110241535181.6379-100000@unix1.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi People

I have a small question about the security in MIPv4

What happens if the home agent is compromised? Say I am running a
webserver on my laptop (hard to believe but possible) and my home agent is
over taken by some malicious user which denies stops forwarding all
packets destined to me from the web clients.

Seems like some sort of mechanism for detecting a bad HA and dynamically
deploying a new home agent in the home network would be useful. Has anyone
worked on something like this? I couldnt find any hint of such a mechanism
in the MIPv4 rfc...am I missing something big?

A quick reply will really help.
Thanks
Asad

On Sun, 21 Oct 2001, Henrik Petander wrote:

> Hi Asad,
>
> On Sat, 20 Oct 2001, Asad Samar wrote:
>
> > Hi Henrik
> >
> > We got your reference from the email below.
> > Are there still some issues with MIPv6 which can result in a DDOS attack?
>
> Yes, but probably most will be fixed before MIPv6 becomes an RFC.
>
>
> >
> > We read the threat model document being discussed these days on the MIP
> > email list and seems like the answer to all of their questions is
> > authentication. Are you dealing with issues which cannot be solved even by
> > authentication in MIPv6? We will be grateful if you can give us some
> > hints.
>
> I am personally focusing on the authorization of Binding Updates which,
> especially when used for route optimization, is IMO the most important
> security issue with Mobile IPv6. If this issue is solved properly
> (authorization of keys used for BUs/BAs, authentication, integrity and
> replay protection for BUs/BAs, then also the vulnerabilities related to
> DOS attacks will be mostly limited to the general wireless / IPv6 ones.
> Some exceptions: (there may also be other ones that I can't remember right
> now)
>
> Home Address option opens vulnerabilities in CNs to reflection attacks.
> Pekka Savola has analyzed the vulnerabilities Home Address option creates
> in CNs in a draft. He also speaks about routing header, which is not
> exactly a MIPv6 mechanism.
>
> MN will probably use some wireless technology with limited bandwdth, which
> makes it vulnerable to clogging attacks. This is not actually a MIPv6
> specific problem, but a more general problem related to wireless
> networking. However, the tunneling of packets from HA to MN could
> allow an attacker to bypass packet filtering rules in the foreign network.
>
> If there is no firewall in the home network, then these two factors could
> make MN vulnerable to DoS attacks. The reverse situation of a FW in home
> network and no FW in foreign network also creates vulnerabilities in
> MN, since it can be attacked through its care-of address, which the
> attacker can learn through triangle routing. I think the latter is the
> more important vulnerability, i.e, a laptop normally behind a strict
> firewall goes mobile and is suddenly reachable by anyone who can learn
> its CoA.
>
> Regards,
> Henrik
>
> >
> > Thanks
> > Asad
> >
> >
> > ---------- Forwarded message ----------
> > Date: Tue, 16 Oct 2001 16:06:05 -0700
> > From: Jari T. Malinen <jmalinen@IPRG.nokia.com>
> > To: Charlie Perkins <charliep@iprg.nokia.com>
> > Cc: Asad Samar <asamar@andrew.cmu.edu>, Humayun Latif <hlatif@andrew.cmu.edu>,
> >      Brenda Liu <bhliu@andrew.cmu.edu>
> > Subject: Re: Mobile IP
> >
> > Hello,
> >
> > Back when at Helsinki U of Technology, Jouni K. Malinen wrote
> > a set of exploits for MIPv4, but it was not turned into a study
> > nor were these exploits made available to the public.
> >
> > One of these considered the case when there is a cooperating
> > attacking MN and HA, one sending a registration request on behalf
> > of the snooped MN on its link and a cooperating HA responding with
> > a valid reply, say, from the victim's home link, or from elsewhere.
> > A visitor list (binding cache) entry can be thus modified
> > in the FA on behalf of the victim MN to point to a wrong HA thus
> > disrupting communication. This is a DDOS if, say, the FA does not
> > accept reg.replies from the same port where the attacking MN is,
> > otherwise the MN can also play the cooperating HA and send itself
> > the registration reply with a success status.
> >
> > You can ask more from the Dynamics mailing list, info how to join
> > you can find via http://www.cs.hut.fi/Research/Dynamics/
> >
> > Another HUT person doing security work is Henrik Petander,
> > lpetande@tml.hut.fi, he is writing his M.Sc. on MIPv6 security,
> > you might ask from him, too.
> >
> > BR,
> >
> > -Jari
> >
> > Charlie Perkins wrote:
> > >
> > > Hello folks,
> > >
> > > I am myself not aware of such a testbed as you have described,
> > > but I would recommend that you join the mobile-ip mailing list
> > > (from the IETF working group) and ask the question there.
> > > If someone has a testbed, you'll most likely get an answer.
> > > I am also not aware of any related attempt to simulate such
> > > a DDOS attack in a simulated mobile environment.
> > >
> > > Regarding the usefulness for DDoS attacks, though, I am not
> > > so sure!  It's a matter of creativity to mount such attacks, not
> > > necessarily randomness, so I don't know what you might try
> > > to measure.
> > >
> > > I've CC:'d Jari Malinen on this note, in hopes that he might
> > > have a lead for any related work from his cohorts at HUT
> > > (Technical Univervsity of Helsinki).
> > >
> > > Regards,
> > > Charlie P.
> > >
> > > Asad Samar wrote:
> > >
> > > > Hi Charles
> > > >
> > > > We are a group taking the Advanced OS and Distributed Systems course at
> > > > CMU. We are thinking about modeling DDOS (distributed denial of service)
> > > > attacks in the mobile environment, specifically in the context of mobile
> > > > IP for our semster project.
> > > >
> > > > >From what we know so far, there doesnt seem to be too much information
> > > > available in this domain. Since you have been involved in Mobile-IP from
> > > > the beginning we just wanted to get your input and any experience or
> > > > pointers you have that might be helpful.
> > > >
> > > > Something really useful would be a way to setup some sort of a testbed
> > > > where we can possibly emulate such an attack. If you have any
> > > > code/development-kits/pointers in this respect that will be very useful.
> > > >
> > > > Are you aware of anyone who has worked in this area at all? We know people
> > > > have tried to solve some of the problems in the protocol but was there an
> > > > extensive study of modeling these concerns (launching a DDOS attack in a
> > > > mobile environment) in the first place? We will greatly appreciate any
> > > > hints on that.
> > > >
> > > > Thanks
> > > > Asad~Brenda~Humayun
> >
>
> 		----------------------------------
> 		Henrik Petander
> 		Helsinki University of Technology,
> 		GO/Core Project
> 		Henrik.Petander@hut.fi
> 		Office: +358 (0)9 451 5846
> 		GSM: +358 (0)40 741 5248
> 		----------------------------------
>
>
>




From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 15:49:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12807
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 15:49:48 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08183;
	Wed, 24 Oct 2001 13:49:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00143;
	Wed, 24 Oct 2001 12:49:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJmD6C017449
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:48:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OJmDhu017448
	for mobile-ip-dist; Wed, 24 Oct 2001 12:48:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJmA6C017441
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:48:10 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29960
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:48:12 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07390
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 13:48:12 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9OJmHY08643;
	Wed, 24 Oct 2001 12:48:17 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE12526;
	Wed, 24 Oct 2001 12:47:34 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10836; Wed, 24 Oct 2001 12:48:10 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15319.6906.236506.466029@thomasm-u1.cisco.com>
Date: Wed, 24 Oct 2001 12:48:10 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: Brenda Liu <bhliu@andrew.cmu.edu>, Humayun Latif <hlatif@andrew.cmu.edu>
Subject: [mobile-ip] HA compromises
In-Reply-To: <Pine.GSO.4.33L-022.0110241535181.6379-100000@unix1.andrew.cmu.edu>
References: <Pine.GSO.4.33L-022.0110241535181.6379-100000@unix1.andrew.cmu.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Asad Samar writes:
 > What happens if the home agent is compromised? Say I am running a
 > webserver on my laptop (hard to believe but possible) and my home agent is
 > over taken by some malicious user which denies stops forwarding all
 > packets destined to me from the web clients.

I'd say that it's pretty much the same as if your
first hop router was compromised. In other words,
bad.

 > Seems like some sort of mechanism for detecting a bad HA and dynamically
 > deploying a new home agent in the home network would be useful. Has anyone
 > worked on something like this? I couldnt find any hint of such a mechanism
 > in the MIPv4 rfc...am I missing something big?

This depends on the compromise. If somebody breaks
into the HA, then it will still most likely have
all of the keying material and trust relationships
as before and would be undetectable by the MN. For
other attacks, strong authentication should be
used to defeat MITM and rogue HA attacks, but this
isn't any different than initial mutual
authentication.

	  Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 15:54:47 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12952
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 15:54:46 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17199;
	Wed, 24 Oct 2001 12:53:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01263;
	Wed, 24 Oct 2001 12:53:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJq56C017560
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:52:05 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OJq5DQ017559
	for mobile-ip-dist; Wed, 24 Oct 2001 12:52:05 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJq16C017549
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:52:01 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16371
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:51:53 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10861
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 13:52:02 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9OJq7Y11393;
	Wed, 24 Oct 2001 12:52:07 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE12655;
	Wed, 24 Oct 2001 12:51:25 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10839; Wed, 24 Oct 2001 12:52:00 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15319.7136.734934.516029@thomasm-u1.cisco.com>
Date: Wed, 24 Oct 2001 12:52:00 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

What has not been established is whether the
particular form of header compression you are
singling out -- ROHC -- will be of much practical
use over the kind of L2 Hesham is talking about.
That is, ROHC+RTP over a fixed slot scheduler.  As
far as I can tell, it would require the roof of
allocation (that is, full header) for the slots
which sounds like a not very good fit.

	     Mike

Koodli Rajeev (NRC/MtView) writes:
 >  
 > Hello Hesham,
 >  
 > this is continuing to be a long discussion. Anyway, I think we are
 > probably converging on some issues. Let me make a (bold) try in
 > summarizing the discussion.
 >  
 > - "tight channel" is the main focus. 
 > - I say on such a channel, HC is likely used. You have concurred. My
 > claim is HC will work with piggybacking. You seem to agree. However,
 > there is something below to iron out.
 > - My position is that if a link supports IPv6, destination option is a
 > given. You seem to agree. I say this means it is supporting
 > piggybacking. You say if it does, it has performance issues. I say we
 > don't design based on a link's performance..
 > - Service disruption is moot to me. See comments below.
 >  
 > Finally, my position is that removing piggybacking is not an option.
 > However, including some text in the draft stating that some links MAY
 > have performance issues to consider when piggybacking is fine with me. I
 > think this may be the way forward.
 >  
 > Please see additional comments below.
 >  
 > Regards,
 >  
 > -Rajeev
 >  
 >  
 > 
 > 
 >  
 > 
 > 	Rajeev, 
 > 
 > I don't know where I poorly explained my point, but 
 > let me see if this works. 
 > Let's assume we have a tight channel with a large 
 > RTT delay and was designed with the assumption that HC 
 > is used. Hence, there is no 40 byte slack in the channel 
 > because the assumption was always that HC exists 
 > and the IP header was not accounted for. This is 
 > obviously for the case where this channel is "tight" 
 > due the low BW requirement of the service running on it. 
 > 
 > 
 > [Rajeev] Since HC is used, how was the context initialized in the first
 > place ? You have to send IR packets first. So, the tight channel must
 > have means for initializing the context. Furthermore, it must have means
 > to re-establish it when necessary. 
 > 
 > When a device starts sending an occasional (additional) ext header 
 > that causes the payload to be split across more than 
 > one radio frame, then significant delays will be encountered 
 > for that payload. If this is a real time payload (like voice) 
 > then the delays makes this datagram useless when it 
 > arrives at the other end. Hence service disruption has 
 > already taken place. 
 > 
 > 
 > [Rajeev]  When HC is used, the payload should not be split. When it is
 > not used, what is the magnitude of this service disruption ? One
 > packetization interval ? Real-time applications work with play-back
 > adjustments schemes that account for the inherent jitter (i.e.,
 > variation in delay for back to back packets) in packet-switched
 > networks. So, your "performance" argument is moot.
 > 
 >  
 > 
 > 	Note that I didn't say anything about the packet being 
 > dropped above. I will assume that the implementation 
 > of this channel will not drop the packet. So the packet 
 > will still (eventually) be delivered to the other end where 
 > the BU is processed. 
 > 
 > Now In the above (_realistic_) scenario, 
 > was the service disrupted due to the piggybacking ? Yes 
 > Will the BU be delivered to the other end ? Based on the 
 > assumption above: Yes 
 > Is this radio link breaking RFC2460 ? No because the 
 > packet was not dropped. 
 > Did the user gain anything from piggybacking ? No. 
 > 
 > 
 > [Rajeev]  This is not a good enough reason to _remove_ piggybacking. I
 > see no quantifiably significant service disruption. By piggybacking, we
 > are only making use of base IPv6 which the link claims to support.
 > 
 >  
 > 
 > 	So I don't understand why you're in favour of mandating 
 > piggybacking. 
 > 
 > 	This covers some of your answers, more comments below: 
 > 
 > 
 > 	        I am in favor of option 1 you mention below. This is in
 > line with
 > general IP protocol design. Any performance considerations could be
 > stated in the draft in some form.
 > For instance, we could state that "..if the BAck does not return after
 > transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
 > a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
 > configurable parameter. 
 > 
 > 	=> I don't think that's a good idea. It shouldn't take a few BUs
 > and dropped packets for us to "guess" whether piggybacking
 > is needed or not. 
 > 
 > 	[Rajeev:]There was an e-mail earlier from Greg Daley on how to
 > do this better. 
 > 
 > => No that doesn't solve the problem. Michael already 
 > responded to that. 
 > 
 > 
 > [Rajeev]  I will have to look into it for more details. If channel
 > asymmetry is the issue, that channel should still consider if it is
 > supporting IPv6.
 > 
 >  
 > 
 > 
 > 	In fact I don't know why you say it's in line with general IP
 > protocol
 > design ?? Could you explain what that is ?
 > In the Fast Handoffs work for v4 and v6, the design teams have
 > been modifying parts of MIP to -for example- get the AR to
 > start forwarding before receiving a BU, why was this acceptable ?
 > Why didin't we just say link layers should be desinged to allow
 > for MIP signalling ?
 > 
 > 
 > 	[Rajeev]  Well, do they eliminate piggybacking ? How do they
 > violate base IPv6 specification ?  
 > 
 > => I didn't refer to piggybacking ! They violate MIPv6 which clearly 
 > states that forwarding to a new CoA must be done based on 
 > the reception of an authenticated BU. They don't violate 
 > the base IPv6, but MIPv6. Is that allowed ? If so then I 
 > don't understand the "violation" argument. 
 > 
 > 
 > [Rajeev]  This is a good argument to discuss. In FMIPv6 at least, if you
 > keep the old CoA, there is no requirement for BU. If the network does
 > host routing, it is not violating anything either. So, I am not sure
 > what they are violating.. On the other hand, if we remove piggybacking
 > on a link that claims to support IPv6, that is a violation. We are
 > designing protocols based _solely_ on _a_ link's idiosyncrasies. That
 > seems like violation to me..
 > 
 >  
 > 
 > 	 
 > Well some of us did, but the WG decided that both philosophies
 > are needed to support existing link layers. BETH is one example.
 > So I don't think your logic is in line with the previous WG decisions
 > on similar topics.
 > 
 > 
 > 	[Rajeev] Performance optimizations are fine as long as the base
 > protocol is not violated. Here, by saying that we will disallow
 > piggybacking, you are saying that we don't support IPv6 destination
 > options in arbitrary packets.  
 > 
 > => The example I showed above does NOT disallow 
 > piggybacking, but it shows that it can be disruptive to 
 > the services. Anyway, I don't think your charaterisation 
 > is accurate. Destination options are certainly supported 
 > (the Home address option is for one). The point is that, 
 > the behaviour by which a node signals to the other end 
 > needs to be optimised to minimise service disruption. 
 > In this case the optimisation is to send the MIPv6 signalling 
 > message on a separate channel, hence eliminate piggybacking. 
 > 
 > 
 > [Rajeev]  If you are, by saying we do not disallow piggybacking,
 > referring to having piggybacking but make a recommendation that some
 > links MAY have performance issues, I can live with that. Regarding your
 > statement above concerning Destination Option: I specifically mentioned
 > that a link has to be able to support destination option in _arbitrary_
 > packets. I know I have a lot to learn, but please don't disrespect
 > whatever I already happen to know!
 > 
 > There is nothing wrong with sending DST options in separate 
 > IP packets. RFC 2460 did not say that all the information 
 > MUST be piggybacked. 
 > 
 > 
 > [Rajeev]  Right. I am not saying DON'T send BU in separate packets. I
 > _am_ saying that that's not the only way to send a BU. Piggybacking is
 > use of destination option, and if a link supports IPv6, I see no reason
 > why I must not use it!
 > 
 >  
 > 
 > 	        Hesham 
 > 
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 > <HTML><HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
 > 
 > <META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
 > <BODY>
 > <DIV>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>Hello 
 > Hesham,</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>this 
 > is continuing to be a long discussion. Anyway, I think we are probably 
 > converging on some issues. Let me make a (bold) try in summarizing the 
 > discussion.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- 
 > "tight channel" is the main focus. </SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- I 
 > say on such a channel, HC is likely used. You have concurred. My claim is HC 
 > will work with piggybacking. You seem to agree. However, there is something 
 > below to iron out.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- My 
 > position is that if a link supports IPv6, destination option is a given. You 
 > seem to agree. I say this means it is supporting piggybacking. You say if it 
 > does, it has performance issues. I say we don't design based on a link's 
 > performance..</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- 
 > Service disruption is moot to me. See&nbsp;comments below.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>Finally, my position is that removing piggybacking is 
 > not an option. However,&nbsp;including some text in the draft stating that some 
 > links MAY have performance issues to consider when piggybacking is fine with me. 
 > I think this may be the way forward.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>Please 
 > see additional comments below.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>Regards,</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>-Rajeev</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>&nbsp;</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <BLOCKQUOTE 
 > style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
 >   <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
 >   size=2><BR>&nbsp;</DIV></FONT>
 >   <UL>
 >     <UL>
 >       <P><FONT color=#0000ff face=Arial size=2>Rajeev, </FONT></P></UL></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>I don't know where I poorly explained 
 >   my point, but </FONT><BR><FONT color=#0000ff face=Arial size=2>let me see if 
 >   this works. </FONT><BR><FONT color=#0000ff face=Arial size=2>Let's assume we 
 >   have a tight channel with a large </FONT><BR><FONT color=#0000ff face=Arial 
 >   size=2>RTT delay and was designed with the assumption that HC </FONT><BR><FONT 
 >   color=#0000ff face=Arial size=2>is used. Hence, there is no 40 byte slack in 
 >   the channel</FONT> <BR><FONT color=#0000ff face=Arial size=2>because the 
 >   assumption was always that HC exists</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>and the IP header was not accounted for. This is </FONT><BR><FONT 
 >   color=#0000ff face=Arial size=2>obviously for the case where this channel is 
 >   "tight"</FONT> <BR><FONT color=#0000ff face=Arial size=2>due the low BW 
 >   requirement of the service running on it.</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;Since HC is used, how was the context 
 >   initialized in the first place ? You have to send IR packets first. So, the 
 >   tight channel must have means for initializing the context. Furthermore, it 
 >   must have means to re-establish it 
 > when&nbsp;necessary.&nbsp;</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2>When a device starts sending an 
 >   occasional (additional) ext header</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>that causes the payload to be split across more than</FONT> <BR><FONT 
 >   color=#0000ff face=Arial size=2>one radio frame, then significant delays will 
 >   be encountered</FONT> <BR><FONT color=#0000ff face=Arial size=2>for that 
 >   payload. If this is a real time payload (like voice)</FONT> <BR><FONT 
 >   face=Arial><FONT color=#0000ff size=2>then the delays makes this datagram 
 >   useless when it <BR>arrives at the other end. Hence service disruption has 
 >   <BR></FONT></FONT><FONT size=2><FONT color=#0000ff><FONT face=Arial>already 
 >   taken place. <BR><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;When HC is used, the payload 
 >   should not be split. When it is not used, what is the magnitude of this 
 >   service disruption ? One packetization interval ? Real-time applications work 
 >   with play-back adjustments schemes that account for the inherent jitter (i.e., 
 >   variation in delay for back to back packets) in packet-switched networks. So, 
 >   your "performance" argument is moot.</SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
 >   <UL>
 >     <UL>
 >       <P><FONT color=#0000ff face=Arial size=2>Note that I didn't say anything 
 >       about the packet being </FONT><BR><FONT color=#0000ff face=Arial 
 >       size=2>dropped above. I will assume that the implementation 
 >       </FONT><BR><FONT color=#0000ff face=Arial size=2>of this channel will not 
 >       drop the packet. So the packet</FONT> <BR><FONT color=#0000ff face=Arial 
 >       size=2>will still (eventually) be delivered to the other end where 
 >       </FONT><BR><FONT color=#0000ff face=Arial size=2>the BU is 
 >       processed.</FONT> </P></UL></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>Now In the above (_realistic_) 
 >   scenario, </FONT><BR><FONT color=#0000ff face=Arial size=2>was the service 
 >   disrupted due to the piggybacking ? Yes</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2>Will the BU be delivered to the other end ? Based on 
 >   the</FONT> <BR><FONT color=#0000ff face=Arial size=2>assumption above: 
 >   Yes</FONT> <BR><FONT face=Arial><FONT color=#0000ff size=2>Is this radio link 
 >   breaking RFC2460 ? No because the <BR>packet was not dropped. 
 >   <BR></FONT></FONT><FONT size=2><FONT color=#0000ff><FONT face=Arial>Did the 
 >   user gain anything from piggybacking ? No. <BR><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;This is not a good enough reason 
 >   to _remove_ piggybacking. I see no quantifiably significant service 
 >   disruption. By piggybacking, we are only making use of base IPv6 which the 
 >   link claims to support.</SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
 >   <UL>
 >     <UL>
 >       <P><FONT color=#0000ff face=Arial size=2>So I don't understand why you're 
 >       in favour of mandating </FONT><BR><FONT color=#0000ff face=Arial 
 >       size=2>piggybacking. </FONT></P>
 >       <P><FONT color=#0000ff face=Arial size=2>This covers some of your answers, 
 >       more comments below:</FONT> </P><BR>
 >       <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>I am 
 >       in favor of option 1 you mention below. This is in line with</FONT><FONT 
 >       face=Arial><BR></FONT><FONT face=Arial size=2>general IP protocol design. 
 >       Any performance considerations could be</FONT><FONT 
 >       face=Arial><BR></FONT><FONT face=Arial size=2>stated in the draft in some 
 >       form.</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>For 
 >       instance, we could state that "..if the BAck does not return 
 >       after</FONT><FONT face=Arial><BR></FONT><FONT face=Arial 
 >       size=2>transmitting a Binding Update BU_PIGGY_TIMES, the sending node must 
 >       send</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>a BU 
 >       without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is 
 >       a</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>configurable 
 >       parameter.</FONT><FONT face=Arial> </FONT></P></UL>
 >     <P><FONT color=#0000ff face=Arial size=2>=&gt; I don't think that's a good 
 >     idea. It shouldn't take a few BUs</FONT><FONT face=Arial><BR></FONT><FONT 
 >     color=#0000ff face=Arial size=2>and dropped packets for us to "guess" 
 >     whether piggybacking</FONT><BR><FONT color=#0000ff face=Arial size=2>is 
 >     needed or not.</FONT><FONT face=Arial> </FONT></P>
 >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev:]There was an 
 >     e-mail&nbsp;earlier from Greg Daley on how to do this better.</FONT> </P></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>=&gt; No that doesn't solve the 
 >   problem. Michael already </FONT><BR><FONT color=#0000ff face=Arial 
 >   size=2>responded to that.</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;I will have to look into it for 
 >   more details. If channel asymmetry is the issue, that channel should still 
 >   consider if it is supporting IPv6.</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
 >   <UL><BR>
 >     <P><FONT color=#0000ff face=Arial size=2>In fact I don't know why you say 
 >     it's in line with general IP protocol</FONT><FONT 
 >     face=Arial><BR></FONT><FONT color=#0000ff face=Arial size=2>design ?? Could 
 >     you explain what that is ?</FONT><BR><FONT color=#0000ff face=Arial 
 >     size=2>In the Fast Handoffs work for v4 and v6, the design teams 
 >     have</FONT><BR><FONT color=#0000ff face=Arial size=2>been modifying parts of 
 >     MIP to -for example- get the AR to</FONT><BR><FONT color=#0000ff face=Arial 
 >     size=2>start forwarding before receiving a BU, why was this acceptable 
 >     ?</FONT><FONT face=Arial><BR></FONT><FONT color=#0000ff face=Arial 
 >     size=2>Why didin't we just say link layers should be desinged to 
 >     allow</FONT><BR><FONT color=#0000ff face=Arial size=2>for MIP signalling 
 >     ?</FONT><FONT face=Arial><BR></FONT></P>
 >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev]&nbsp;&nbsp;Well, do they 
 >     eliminate piggybacking ? How do they violate base IPv6 specification ?&nbsp; 
 >     </FONT></P></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>=&gt; I didn't refer to piggybacking 
 >   ! They violate MIPv6 which clearly </FONT><BR><FONT color=#0000ff face=Arial 
 >   size=2>states that forwarding to a new CoA must be done based on 
 >   </FONT><BR><FONT color=#0000ff face=Arial size=2>the reception of an 
 >   authenticated BU. They don't violate</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>the base IPv6, but MIPv6. Is that allowed ? If so then I 
 >   </FONT><BR><FONT color=#0000ff face=Arial size=2>don't understand the 
 >   "violation" argument.</FONT> <BR><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;This is a good argument to 
 >   discuss. In FMIPv6 at least, if you keep the old CoA, there is no requirement 
 >   for BU. If the network does host routing, it is not violating anything either. 
 >   So, I am not sure what they are violating.. On the other hand, if we remove 
 >   piggybacking on a link that claims to support IPv6, that is a violation. We 
 >   are designing protocols based _solely_ on _a_ link's idiosyncrasies. That 
 >   seems like violation to me..</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
 >   <UL>
 >     <P><FONT color=#0000ff face=Arial size=2>&nbsp;<BR>Well some of us did, but 
 >     the WG decided that both philosophies<BR>are needed to support existing link 
 >     layers. BETH is one example.<BR>So I don't think your logic is in line with 
 >     the previous WG decisions</FONT><FONT face=Arial><BR></FONT><FONT 
 >     color=#0000ff face=Arial size=2>on similar topics.</FONT><FONT 
 >     face=Arial><BR></FONT></P>
 >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev] Performance optimizations 
 >     are&nbsp;fine as long as the base protocol is not violated.&nbsp;Here, by 
 >     saying that we will disallow piggybacking, you are saying that we don't 
 >     support IPv6 destination options in arbitrary packets. &nbsp;</FONT></P></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>=&gt; The example I showed above does 
 >   NOT disallow </FONT><BR><FONT color=#0000ff face=Arial size=2>piggybacking, 
 >   but it shows that it can be disruptive to</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2>the services. Anyway, I don't think your 
 >   charaterisation</FONT> <BR><FONT color=#0000ff face=Arial size=2>is accurate. 
 >   Destination options are certainly supported</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2>(the Home address option is for one). The point is that, 
 >   </FONT><BR><FONT color=#0000ff face=Arial size=2>the behaviour by which a node 
 >   signals to the other end</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>needs to be optimised to minimise service disruption. </FONT><BR><FONT 
 >   color=#0000ff face=Arial size=2>In this case the optimisation is to send the 
 >   MIPv6 signalling</FONT> <BR><FONT color=#0000ff face=Arial size=2>message on a 
 >   separate channel, hence eliminate piggybacking.</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;If you are, by saying we do not 
 >   disallow piggybacking, referring to having piggybacking but make a 
 >   recommendation that some links MAY have performance issues, I can live with 
 >   that. </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>Regarding your statement above concerning Destination 
 >   Option: I specifically mentioned that a link has to be able to support 
 >   destination option in _arbitrary_ packets. I know I have a lot to learn, but 
 >   please don't disrespect whatever I already happen to know!</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2>There is nothing wrong with sending 
 >   DST options in separate</FONT> <BR><FONT color=#0000ff face=Arial size=2>IP 
 >   packets. RFC 2460 did not say that all the information</FONT> <BR><FONT 
 >   color=#0000ff face=Arial size=2>MUST be piggybacked.</FONT> <BR><FONT 
 >   color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;Right. I am not saying DON'T send 
 >   BU in separate packets. I _am_ saying that that's not the only way to send a 
 >   BU. Piggybacking is use of destination option, and if a link supports IPv6, I 
 >   see no reason why I must not use it!</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
 >   <UL>
 >     <P><FONT color=#0000ff face=Arial 
 >     size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hesham</FONT><FONT 
 >     face=Arial> </FONT></P></UL></BLOCKQUOTE></BODY></HTML>


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 15:58:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13035
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 15:58:03 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15300;
	Wed, 24 Oct 2001 13:57:20 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02239;
	Wed, 24 Oct 2001 12:57:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJuM6C017665
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:56:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OJuMQX017664
	for mobile-ip-dist; Wed, 24 Oct 2001 12:56:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OJuI6C017657
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:56:18 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17036
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:56:11 -0700 (PDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27053
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 12:56:20 -0700 (PDT)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <4KA6RMA2>; Wed, 24 Oct 2001 15:56:18 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048616605@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Cc: Brenda Liu <bhliu@andrew.cmu.edu>, Humayun Latif
	 <hlatif@andrew.cmu.edu>
Subject: Portable Firewall?  was RE: [mobile-ip] HA compromises
Date: Wed, 24 Oct 2001 15:56:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This seems to indicate to me that Norton's (Symantec) personal firewall 
software or other such products are going to sell really well in the near
term wireless future!!!  The typical Window's PC or CE device (and Linux)
have tons of gaping holes that can be exploited if not fire-walled.  The
logical place to put the firewall is on the MN I believe.  Hopefully the
firewall will support MIP ICMP advertisements etc..

--
Mesh Networks, Inc. (www.meshnetworks.com)
Phillip D. Neumiller, Staff Scientist
pneumiller@meshnetworks.com PH: 1-407-659-5387
> 
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 17:30:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14784
	for <mobileip-archive@lists.ietf.org>; Wed, 24 Oct 2001 17:30:57 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05313;
	Wed, 24 Oct 2001 15:30:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28851;
	Wed, 24 Oct 2001 14:29:40 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OLSn6C018134
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 14:28:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OLSnmU018133
	for mobile-ip-dist; Wed, 24 Oct 2001 14:28:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OLSk6C018126
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 14:28:46 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28751
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 14:28:49 -0700 (PDT)
Received: from smtp7.andrew.cmu.edu (SMTP7.ANDREW.CMU.EDU [128.2.10.87])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17438
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 14:28:49 -0700 (PDT)
Received: from UNIX1.ANDREW.CMU.EDU (UNIX1.ANDREW.CMU.EDU [128.2.11.201])
	(user=asamar mech=KERBEROS_V4 (0 bits))
	by smtp7.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f9OLSkUi010565;
	Wed, 24 Oct 2001 17:28:46 -0400
Date: Wed, 24 Oct 2001 17:28:47 -0400 (EDT)
From: Asad Samar <asamar@andrew.cmu.edu>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Brenda Liu <bhliu@andrew.cmu.edu>, Humayun Latif <hlatif@andrew.cmu.edu>
Subject: Re: [mobile-ip] HA compromises
In-Reply-To: <15319.6906.236506.466029@thomasm-u1.cisco.com>
Message-ID: <Pine.GSO.4.33L-022.0110241721030.20669-100000@unix1.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

>
> Asad Samar writes:
>  > What happens if the home agent is compromised? Say I am running a
>  > webserver on my laptop (hard to believe but possible) and my home agent is
>  > over taken by some malicious user which denies stops forwarding all
>  > packets destined to me from the web clients.
>
> I'd say that it's pretty much the same as if your
> first hop router was compromised. In other words,
> bad.

True...but the question is if we can do something to help the "compromised
HA" situation which we can (possibly) not do in the router case.

For instance, maybe a MN sends periodic control packets to its home
address to see if they are tunnelled back to it by the HA or not. A
compromised HA can atmost block the packets and not alter them because I
was assuming some integrity checks (digital signatures etc). So if we can
sense (using whatever means) some packets being lost/stopped by the HA
because of a technical fault or malicious intent; will it be useful to
dynamically deploy another HA in the home network and have that tunnel the
packets?

Asad

>
>  > Seems like some sort of mechanism for detecting a bad HA and dynamically
>  > deploying a new home agent in the home network would be useful. Has anyone
>  > worked on something like this? I couldnt find any hint of such a mechanism
>  > in the MIPv4 rfc...am I missing something big?
>
> This depends on the compromise. If somebody breaks
> into the HA, then it will still most likely have
> all of the keying material and trust relationships
> as before and would be undetectable by the MN. For
> other attacks, strong authentication should be
> used to defeat MITM and rogue HA attacks, but this
> isn't any different than initial mutual
> authentication.
>
> 	  Mike
>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 18:38:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15832
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 18:38:29 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00443;
	Wed, 24 Oct 2001 16:37:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22476;
	Wed, 24 Oct 2001 15:37:10 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OMaG6C018363
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 15:36:16 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OMaGOW018362
	for mobile-ip-dist; Wed, 24 Oct 2001 15:36:16 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OMaD6C018355
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 15:36:13 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22084
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 15:36:05 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26093
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:42:13 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA26902;
	Wed, 24 Oct 2001 15:36:00 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9OMZxw32605;
	Wed, 24 Oct 2001 15:35:59 -0700
X-mProtect:  Wed, 24 Oct 2001 15:35:59 -0700 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141130.americas.nokia.com (172.18.141.130, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdyzbEJI; Wed, 24 Oct 2001 15:35:57 PDT
Message-ID: <3BD74225.1A17E604@iprg.nokia.com>
Date: Wed, 24 Oct 2001 15:35:19 -0700
From: Cedric Westphal <cedric@iprg.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of 
 the security discussion
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com> <15319.7136.734934.516029@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael Thomas wrote:

> What has not been established is whether the
> particular form of header compression you are
> singling out -- ROHC -- will be of much practical
> use over the kind of L2 Hesham is talking about.
> That is, ROHC+RTP over a fixed slot scheduler.  As
> far as I can tell, it would require the roof of
> allocation (that is, full header) for the slots
> which sounds like a not very good fit.
>
>              Mike

You hit the point, Mike: Hesham's L2 link would require a roof
allocation for the slots, and ROHC would give the slack for
piggybacking.

C.

>
>
> Koodli Rajeev (NRC/MtView) writes:
>  >
>  > Hello Hesham,
>  >
>  > this is continuing to be a long discussion. Anyway, I think we are
>  > probably converging on some issues. Let me make a (bold) try in
>  > summarizing the discussion.
>  >
>  > - "tight channel" is the main focus.
>  > - I say on such a channel, HC is likely used. You have concurred. My
>  > claim is HC will work with piggybacking. You seem to agree. However,
>  > there is something below to iron out.
>  > - My position is that if a link supports IPv6, destination option is a
>  > given. You seem to agree. I say this means it is supporting
>  > piggybacking. You say if it does, it has performance issues. I say we
>  > don't design based on a link's performance..
>  > - Service disruption is moot to me. See comments below.
>  >
>  > Finally, my position is that removing piggybacking is not an option.
>  > However, including some text in the draft stating that some links MAY
>  > have performance issues to consider when piggybacking is fine with me. I
>  > think this may be the way forward.
>  >
>  > Please see additional comments below.
>  >
>  > Regards,
>  >
>  > -Rajeev
>  >
>  >
>  >
>  >
>  >
>  >
>  >      Rajeev,
>  >
>  > I don't know where I poorly explained my point, but
>  > let me see if this works.
>  > Let's assume we have a tight channel with a large
>  > RTT delay and was designed with the assumption that HC
>  > is used. Hence, there is no 40 byte slack in the channel
>  > because the assumption was always that HC exists
>  > and the IP header was not accounted for. This is
>  > obviously for the case where this channel is "tight"
>  > due the low BW requirement of the service running on it.
>  >
>  >
>  > [Rajeev] Since HC is used, how was the context initialized in the first
>  > place ? You have to send IR packets first. So, the tight channel must
>  > have means for initializing the context. Furthermore, it must have means
>  > to re-establish it when necessary.
>  >
>  > When a device starts sending an occasional (additional) ext header
>  > that causes the payload to be split across more than
>  > one radio frame, then significant delays will be encountered
>  > for that payload. If this is a real time payload (like voice)
>  > then the delays makes this datagram useless when it
>  > arrives at the other end. Hence service disruption has
>  > already taken place.
>  >
>  >
>  > [Rajeev]  When HC is used, the payload should not be split. When it is
>  > not used, what is the magnitude of this service disruption ? One
>  > packetization interval ? Real-time applications work with play-back
>  > adjustments schemes that account for the inherent jitter (i.e.,
>  > variation in delay for back to back packets) in packet-switched
>  > networks. So, your "performance" argument is moot.
>  >
>  >
>  >
>  >      Note that I didn't say anything about the packet being
>  > dropped above. I will assume that the implementation
>  > of this channel will not drop the packet. So the packet
>  > will still (eventually) be delivered to the other end where
>  > the BU is processed.
>  >
>  > Now In the above (_realistic_) scenario,
>  > was the service disrupted due to the piggybacking ? Yes
>  > Will the BU be delivered to the other end ? Based on the
>  > assumption above: Yes
>  > Is this radio link breaking RFC2460 ? No because the
>  > packet was not dropped.
>  > Did the user gain anything from piggybacking ? No.
>  >
>  >
>  > [Rajeev]  This is not a good enough reason to _remove_ piggybacking. I
>  > see no quantifiably significant service disruption. By piggybacking, we
>  > are only making use of base IPv6 which the link claims to support.
>  >
>  >
>  >
>  >      So I don't understand why you're in favour of mandating
>  > piggybacking.
>  >
>  >      This covers some of your answers, more comments below:
>  >
>  >
>  >              I am in favor of option 1 you mention below. This is in
>  > line with
>  > general IP protocol design. Any performance considerations could be
>  > stated in the draft in some form.
>  > For instance, we could state that "..if the BAck does not return after
>  > transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
>  > a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
>  > configurable parameter.
>  >
>  >      => I don't think that's a good idea. It shouldn't take a few BUs
>  > and dropped packets for us to "guess" whether piggybacking
>  > is needed or not.
>  >
>  >      [Rajeev:]There was an e-mail earlier from Greg Daley on how to
>  > do this better.
>  >
>  > => No that doesn't solve the problem. Michael already
>  > responded to that.
>  >
>  >
>  > [Rajeev]  I will have to look into it for more details. If channel
>  > asymmetry is the issue, that channel should still consider if it is
>  > supporting IPv6.
>  >
>  >
>  >
>  >
>  >      In fact I don't know why you say it's in line with general IP
>  > protocol
>  > design ?? Could you explain what that is ?
>  > In the Fast Handoffs work for v4 and v6, the design teams have
>  > been modifying parts of MIP to -for example- get the AR to
>  > start forwarding before receiving a BU, why was this acceptable ?
>  > Why didin't we just say link layers should be desinged to allow
>  > for MIP signalling ?
>  >
>  >
>  >      [Rajeev]  Well, do they eliminate piggybacking ? How do they
>  > violate base IPv6 specification ?
>  >
>  > => I didn't refer to piggybacking ! They violate MIPv6 which clearly
>  > states that forwarding to a new CoA must be done based on
>  > the reception of an authenticated BU. They don't violate
>  > the base IPv6, but MIPv6. Is that allowed ? If so then I
>  > don't understand the "violation" argument.
>  >
>  >
>  > [Rajeev]  This is a good argument to discuss. In FMIPv6 at least, if you
>  > keep the old CoA, there is no requirement for BU. If the network does
>  > host routing, it is not violating anything either. So, I am not sure
>  > what they are violating.. On the other hand, if we remove piggybacking
>  > on a link that claims to support IPv6, that is a violation. We are
>  > designing protocols based _solely_ on _a_ link's idiosyncrasies. That
>  > seems like violation to me..
>  >
>  >
>  >
>  >
>  > Well some of us did, but the WG decided that both philosophies
>  > are needed to support existing link layers. BETH is one example.
>  > So I don't think your logic is in line with the previous WG decisions
>  > on similar topics.
>  >
>  >
>  >      [Rajeev] Performance optimizations are fine as long as the base
>  > protocol is not violated. Here, by saying that we will disallow
>  > piggybacking, you are saying that we don't support IPv6 destination
>  > options in arbitrary packets.
>  >
>  > => The example I showed above does NOT disallow
>  > piggybacking, but it shows that it can be disruptive to
>  > the services. Anyway, I don't think your charaterisation
>  > is accurate. Destination options are certainly supported
>  > (the Home address option is for one). The point is that,
>  > the behaviour by which a node signals to the other end
>  > needs to be optimised to minimise service disruption.
>  > In this case the optimisation is to send the MIPv6 signalling
>  > message on a separate channel, hence eliminate piggybacking.
>  >
>  >
>  > [Rajeev]  If you are, by saying we do not disallow piggybacking,
>  > referring to having piggybacking but make a recommendation that some
>  > links MAY have performance issues, I can live with that. Regarding your
>  > statement above concerning Destination Option: I specifically mentioned
>  > that a link has to be able to support destination option in _arbitrary_
>  > packets. I know I have a lot to learn, but please don't disrespect
>  > whatever I already happen to know!
>  >
>  > There is nothing wrong with sending DST options in separate
>  > IP packets. RFC 2460 did not say that all the information
>  > MUST be piggybacked.
>  >
>  >
>  > [Rajeev]  Right. I am not saying DON'T send BU in separate packets. I
>  > _am_ saying that that's not the only way to send a BU. Piggybacking is
>  > use of destination option, and if a link supports IPv6, I see no reason
>  > why I must not use it!
>  >
>  >
>  >
>  >              Hesham
>  >
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
>  > <HTML><HEAD>
>  > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
>  > <TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
>  >
>  > <META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
>  > <BODY>
>  > <DIV>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>Hello
>  > Hesham,</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>this
>  > is continuing to be a long discussion. Anyway, I think we are probably
>  > converging on some issues. Let me make a (bold) try in summarizing the
>  > discussion.</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>-
>  > "tight channel" is the main focus. </SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- I
>  > say on such a channel, HC is likely used. You have concurred. My claim is HC
>  > will work with piggybacking. You seem to agree. However, there is something
>  > below to iron out.</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- My
>  > position is that if a link supports IPv6, destination option is a given. You
>  > seem to agree. I say this means it is supporting piggybacking. You say if it
>  > does, it has performance issues. I say we don't design based on a link's
>  > performance..</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>-
>  > Service disruption is moot to me. See&nbsp;comments below.</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001>Finally, my position is that removing piggybacking is
>  > not an option. However,&nbsp;including some text in the draft stating that some
>  > links MAY have performance issues to consider when piggybacking is fine with me.
>  > I think this may be the way forward.</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>Please
>  > see additional comments below.</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001>Regards,</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001>-Rajeev</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001>&nbsp;</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
>  > <BLOCKQUOTE
>  > style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
>  >   <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
>  >   size=2><BR>&nbsp;</DIV></FONT>
>  >   <UL>
>  >     <UL>
>  >       <P><FONT color=#0000ff face=Arial size=2>Rajeev, </FONT></P></UL></UL>
>  >   <P><FONT color=#0000ff face=Arial size=2>I don't know where I poorly explained
>  >   my point, but </FONT><BR><FONT color=#0000ff face=Arial size=2>let me see if
>  >   this works. </FONT><BR><FONT color=#0000ff face=Arial size=2>Let's assume we
>  >   have a tight channel with a large </FONT><BR><FONT color=#0000ff face=Arial
>  >   size=2>RTT delay and was designed with the assumption that HC </FONT><BR><FONT
>  >   color=#0000ff face=Arial size=2>is used. Hence, there is no 40 byte slack in
>  >   the channel</FONT> <BR><FONT color=#0000ff face=Arial size=2>because the
>  >   assumption was always that HC exists</FONT> <BR><FONT color=#0000ff face=Arial
>  >   size=2>and the IP header was not accounted for. This is </FONT><BR><FONT
>  >   color=#0000ff face=Arial size=2>obviously for the case where this channel is
>  >   "tight"</FONT> <BR><FONT color=#0000ff face=Arial size=2>due the low BW
>  >   requirement of the service running on it.</FONT> <BR><FONT color=#0000ff
>  >   face=Arial size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001>[Rajeev]&nbsp;Since HC is used, how was the context
>  >   initialized in the first place ? You have to send IR packets first. So, the
>  >   tight channel must have means for initializing the context. Furthermore, it
>  >   must have means to re-establish it
>  > when&nbsp;necessary.&nbsp;</SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2>When a device starts sending an
>  >   occasional (additional) ext header</FONT> <BR><FONT color=#0000ff face=Arial
>  >   size=2>that causes the payload to be split across more than</FONT> <BR><FONT
>  >   color=#0000ff face=Arial size=2>one radio frame, then significant delays will
>  >   be encountered</FONT> <BR><FONT color=#0000ff face=Arial size=2>for that
>  >   payload. If this is a real time payload (like voice)</FONT> <BR><FONT
>  >   face=Arial><FONT color=#0000ff size=2>then the delays makes this datagram
>  >   useless when it <BR>arrives at the other end. Hence service disruption has
>  >   <BR></FONT></FONT><FONT size=2><FONT color=#0000ff><FONT face=Arial>already
>  >   taken place. <BR><SPAN
>  >   class=750194216-24102001></SPAN></FONT></FONT></FONT></P>
>  >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN
>  >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;When HC is used, the payload
>  >   should not be split. When it is not used, what is the magnitude of this
>  >   service disruption ? One packetization interval ? Real-time applications work
>  >   with play-back adjustments schemes that account for the inherent jitter (i.e.,
>  >   variation in delay for back to back packets) in packet-switched networks. So,
>  >   your "performance" argument is moot.</SPAN></FONT></FONT></FONT></P>
>  >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN
>  >   class=750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
>  >   <UL>
>  >     <UL>
>  >       <P><FONT color=#0000ff face=Arial size=2>Note that I didn't say anything
>  >       about the packet being </FONT><BR><FONT color=#0000ff face=Arial
>  >       size=2>dropped above. I will assume that the implementation
>  >       </FONT><BR><FONT color=#0000ff face=Arial size=2>of this channel will not
>  >       drop the packet. So the packet</FONT> <BR><FONT color=#0000ff face=Arial
>  >       size=2>will still (eventually) be delivered to the other end where
>  >       </FONT><BR><FONT color=#0000ff face=Arial size=2>the BU is
>  >       processed.</FONT> </P></UL></UL>
>  >   <P><FONT color=#0000ff face=Arial size=2>Now In the above (_realistic_)
>  >   scenario, </FONT><BR><FONT color=#0000ff face=Arial size=2>was the service
>  >   disrupted due to the piggybacking ? Yes</FONT> <BR><FONT color=#0000ff
>  >   face=Arial size=2>Will the BU be delivered to the other end ? Based on
>  >   the</FONT> <BR><FONT color=#0000ff face=Arial size=2>assumption above:
>  >   Yes</FONT> <BR><FONT face=Arial><FONT color=#0000ff size=2>Is this radio link
>  >   breaking RFC2460 ? No because the <BR>packet was not dropped.
>  >   <BR></FONT></FONT><FONT size=2><FONT color=#0000ff><FONT face=Arial>Did the
>  >   user gain anything from piggybacking ? No. <BR><SPAN
>  >   class=750194216-24102001></SPAN></FONT></FONT></FONT></P>
>  >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN
>  >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;This is not a good enough reason
>  >   to _remove_ piggybacking. I see no quantifiably significant service
>  >   disruption. By piggybacking, we are only making use of base IPv6 which the
>  >   link claims to support.</SPAN></FONT></FONT></FONT></P>
>  >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN
>  >   class=750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
>  >   <UL>
>  >     <UL>
>  >       <P><FONT color=#0000ff face=Arial size=2>So I don't understand why you're
>  >       in favour of mandating </FONT><BR><FONT color=#0000ff face=Arial
>  >       size=2>piggybacking. </FONT></P>
>  >       <P><FONT color=#0000ff face=Arial size=2>This covers some of your answers,
>  >       more comments below:</FONT> </P><BR>
>  >       <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>I am
>  >       in favor of option 1 you mention below. This is in line with</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>general IP protocol design.
>  >       Any performance considerations could be</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>stated in the draft in some
>  >       form.</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>For
>  >       instance, we could state that "..if the BAck does not return
>  >       after</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
>  >       size=2>transmitting a Binding Update BU_PIGGY_TIMES, the sending node must
>  >       send</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>a BU
>  >       without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is
>  >       a</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>configurable
>  >       parameter.</FONT><FONT face=Arial> </FONT></P></UL>
>  >     <P><FONT color=#0000ff face=Arial size=2>=&gt; I don't think that's a good
>  >     idea. It shouldn't take a few BUs</FONT><FONT face=Arial><BR></FONT><FONT
>  >     color=#0000ff face=Arial size=2>and dropped packets for us to "guess"
>  >     whether piggybacking</FONT><BR><FONT color=#0000ff face=Arial size=2>is
>  >     needed or not.</FONT><FONT face=Arial> </FONT></P>
>  >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev:]There was an
>  >     e-mail&nbsp;earlier from Greg Daley on how to do this better.</FONT> </P></UL>
>  >   <P><FONT color=#0000ff face=Arial size=2>=&gt; No that doesn't solve the
>  >   problem. Michael already </FONT><BR><FONT color=#0000ff face=Arial
>  >   size=2>responded to that.</FONT> <BR><FONT color=#0000ff face=Arial
>  >   size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;I will have to look into it for
>  >   more details. If channel asymmetry is the issue, that channel should still
>  >   consider if it is supporting IPv6.</SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
>  >   <UL><BR>
>  >     <P><FONT color=#0000ff face=Arial size=2>In fact I don't know why you say
>  >     it's in line with general IP protocol</FONT><FONT
>  >     face=Arial><BR></FONT><FONT color=#0000ff face=Arial size=2>design ?? Could
>  >     you explain what that is ?</FONT><BR><FONT color=#0000ff face=Arial
>  >     size=2>In the Fast Handoffs work for v4 and v6, the design teams
>  >     have</FONT><BR><FONT color=#0000ff face=Arial size=2>been modifying parts of
>  >     MIP to -for example- get the AR to</FONT><BR><FONT color=#0000ff face=Arial
>  >     size=2>start forwarding before receiving a BU, why was this acceptable
>  >     ?</FONT><FONT face=Arial><BR></FONT><FONT color=#0000ff face=Arial
>  >     size=2>Why didin't we just say link layers should be desinged to
>  >     allow</FONT><BR><FONT color=#0000ff face=Arial size=2>for MIP signalling
>  >     ?</FONT><FONT face=Arial><BR></FONT></P>
>  >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev]&nbsp;&nbsp;Well, do they
>  >     eliminate piggybacking ? How do they violate base IPv6 specification ?&nbsp;
>  >     </FONT></P></UL>
>  >   <P><FONT color=#0000ff face=Arial size=2>=&gt; I didn't refer to piggybacking
>  >   ! They violate MIPv6 which clearly </FONT><BR><FONT color=#0000ff face=Arial
>  >   size=2>states that forwarding to a new CoA must be done based on
>  >   </FONT><BR><FONT color=#0000ff face=Arial size=2>the reception of an
>  >   authenticated BU. They don't violate</FONT> <BR><FONT color=#0000ff face=Arial
>  >   size=2>the base IPv6, but MIPv6. Is that allowed ? If so then I
>  >   </FONT><BR><FONT color=#0000ff face=Arial size=2>don't understand the
>  >   "violation" argument.</FONT> <BR><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001></SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;This is a good argument to
>  >   discuss. In FMIPv6 at least, if you keep the old CoA, there is no requirement
>  >   for BU. If the network does host routing, it is not violating anything either.
>  >   So, I am not sure what they are violating.. On the other hand, if we remove
>  >   piggybacking on a link that claims to support IPv6, that is a violation. We
>  >   are designing protocols based _solely_ on _a_ link's idiosyncrasies. That
>  >   seems like violation to me..</SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
>  >   <UL>
>  >     <P><FONT color=#0000ff face=Arial size=2>&nbsp;<BR>Well some of us did, but
>  >     the WG decided that both philosophies<BR>are needed to support existing link
>  >     layers. BETH is one example.<BR>So I don't think your logic is in line with
>  >     the previous WG decisions</FONT><FONT face=Arial><BR></FONT><FONT
>  >     color=#0000ff face=Arial size=2>on similar topics.</FONT><FONT
>  >     face=Arial><BR></FONT></P>
>  >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev] Performance optimizations
>  >     are&nbsp;fine as long as the base protocol is not violated.&nbsp;Here, by
>  >     saying that we will disallow piggybacking, you are saying that we don't
>  >     support IPv6 destination options in arbitrary packets. &nbsp;</FONT></P></UL>
>  >   <P><FONT color=#0000ff face=Arial size=2>=&gt; The example I showed above does
>  >   NOT disallow </FONT><BR><FONT color=#0000ff face=Arial size=2>piggybacking,
>  >   but it shows that it can be disruptive to</FONT> <BR><FONT color=#0000ff
>  >   face=Arial size=2>the services. Anyway, I don't think your
>  >   charaterisation</FONT> <BR><FONT color=#0000ff face=Arial size=2>is accurate.
>  >   Destination options are certainly supported</FONT> <BR><FONT color=#0000ff
>  >   face=Arial size=2>(the Home address option is for one). The point is that,
>  >   </FONT><BR><FONT color=#0000ff face=Arial size=2>the behaviour by which a node
>  >   signals to the other end</FONT> <BR><FONT color=#0000ff face=Arial
>  >   size=2>needs to be optimised to minimise service disruption. </FONT><BR><FONT
>  >   color=#0000ff face=Arial size=2>In this case the optimisation is to send the
>  >   MIPv6 signalling</FONT> <BR><FONT color=#0000ff face=Arial size=2>message on a
>  >   separate channel, hence eliminate piggybacking.</FONT> <BR><FONT color=#0000ff
>  >   face=Arial size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;If you are, by saying we do not
>  >   disallow piggybacking, referring to having piggybacking but make a
>  >   recommendation that some links MAY have performance issues, I can live with
>  >   that. </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001>Regarding your statement above concerning Destination
>  >   Option: I specifically mentioned that a link has to be able to support
>  >   destination option in _arbitrary_ packets. I know I have a lot to learn, but
>  >   please don't disrespect whatever I already happen to know!</SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2>There is nothing wrong with sending
>  >   DST options in separate</FONT> <BR><FONT color=#0000ff face=Arial size=2>IP
>  >   packets. RFC 2460 did not say that all the information</FONT> <BR><FONT
>  >   color=#0000ff face=Arial size=2>MUST be piggybacked.</FONT> <BR><FONT
>  >   color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001></SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;Right. I am not saying DON'T send
>  >   BU in separate packets. I _am_ saying that that's not the only way to send a
>  >   BU. Piggybacking is use of destination option, and if a link supports IPv6, I
>  >   see no reason why I must not use it!</SPAN></FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2><SPAN
>  >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
>  >   <UL>
>  >     <P><FONT color=#0000ff face=Arial
>  >     size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hesham</FONT><FONT
>  >     face=Arial> </FONT></P></UL></BLOCKQUOTE></BODY></HTML>



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 19:07:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16512
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 19:07:29 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA19353;
	Wed, 24 Oct 2001 16:06:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22870;
	Wed, 24 Oct 2001 16:06:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ON546C018535
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:05:04 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9ON54Vg018534
	for mobile-ip-dist; Wed, 24 Oct 2001 16:05:04 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ON516C018527
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:05:01 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12930
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:05:03 -0700 (PDT)
Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10888
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:11:00 -0600 (MDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id SAA20192
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 18:04:59 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9ON4wC21134
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 18:04:59 -0500 (CDT)
Message-ID: <3BD739A9.C00F8EB8@alcatel.com>
Date: Wed, 24 Oct 2001 17:59:05 -0400
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: Law of objectivity? Was RE: [mobile-ip] MIPv6 - Focus of the 
 security discussion
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com> <15319.7136.734934.516029@thomasm-u1.cisco.com> <3BD74225.1A17E604@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Law of objectivity:
If an I-D is from others then you are very objective about it
otherwise if the I-D is from your colleague/company then objectivity disappears.

(the above is a very generic law and applies in other domains such as professors and
students; parents and children, and so on)

Cedric Westphal wrote:

> Michael Thomas wrote:
>
>
>
> > Koodli Rajeev (NRC/MtView) writes:
> >  >
>
> >  >
> >  >              Hesham Soliman wrote:
> >  >
> >

> --

Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 19:37:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17092
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 19:37:09 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00952;
	Wed, 24 Oct 2001 16:36:25 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17059;
	Wed, 24 Oct 2001 16:36:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ONZ96C018706
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:35:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9ONZ9nj018705
	for mobile-ip-dist; Wed, 24 Oct 2001 16:35:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ONZ56C018698
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:35:05 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06494
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 16:34:58 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25812
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:41:07 -0600 (MDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9ONZ8Y13854;
	Wed, 24 Oct 2001 16:35:08 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE19015;
	Wed, 24 Oct 2001 16:34:25 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA10862; Wed, 24 Oct 2001 16:35:01 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15319.20517.681504.273238@thomasm-u1.cisco.com>
Date: Wed, 24 Oct 2001 16:35:01 -0700 (PDT)
To: Cedric Westphal <cedric@iprg.nokia.com>
Cc: mobile-ip@sunroof.eng.sun.com,
        "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of 
 the security discussion
In-Reply-To: <3BD74225.1A17E604@iprg.nokia.com>
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
	<15319.7136.734934.516029@thomasm-u1.cisco.com>
	<3BD74225.1A17E604@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Cedric Westphal writes:
 > Michael Thomas wrote:
 > 
 > > What has not been established is whether the
 > > particular form of header compression you are
 > > singling out -- ROHC -- will be of much practical
 > > use over the kind of L2 Hesham is talking about.
 > > That is, ROHC+RTP over a fixed slot scheduler.  As
 > > far as I can tell, it would require the roof of
 > > allocation (that is, full header) for the slots
 > > which sounds like a not very good fit.
 > >
 > >              Mike
 > 
 > You hit the point, Mike: Hesham's L2 link would require a roof
 > allocation for the slots, and ROHC would give the slack for
 > piggybacking.

   I guess I'd have to question the sanity of
   somebody running a complex state machine like
   ROHC or CRTP if the only realized bandwidth
   savings were for the occasional binding update
   you could sneak in. If I were a cellular
   operator, I think I'd rather have a header
   compression scheme which worked well on the
   vast majority of packets and paid the price
   for exception packets (= BU) on an as needed
   basis.

   As I keep pointing out, this is why the cable
   MAC uses Payload Header Suppression for
   DOCSIS because it gives them that ability.
   I sure hope this is no surprise to the
   ROHC WG. You guys are making me nervous that
   it is.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 20:17:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17754
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 20:17:19 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08589;
	Wed, 24 Oct 2001 18:16:45 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25074;
	Wed, 24 Oct 2001 17:16:33 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P0FC6C018876
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:15:13 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9P0FCua018875
	for mobile-ip-dist; Wed, 24 Oct 2001 17:15:12 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P0F96C018868
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:15:09 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27948
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:15:12 -0700 (PDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09127
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:15:12 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9P0FBe02008;
	Wed, 24 Oct 2001 17:15:11 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE20110;
	Wed, 24 Oct 2001 17:14:34 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA10865; Wed, 24 Oct 2001 17:15:10 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15319.22926.148456.166125@thomasm-u1.cisco.com>
Date: Wed, 24 Oct 2001 17:15:10 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Koodli Rajeev (NRC/MtView) writes:
  >You say if it does, it has performance issues. I say we
 > don't design based on a link's performance..

_Oh_??? There's a difference between being a slave
to link layers and not considering them at all. If
I believed that this was a narrow situation that
is only related to a single link layer which needs
to be redesigned for IP anyway, you would not be
getting any arguments from me. However, I believe
that this slotting problem that we've been
describing is a fundamental engineering tradeoff
when you have a shared media, such as radio.

I have repeatedly asked for a concrete example of
a shared media which provides QoS guarantees which
would substantially benefit from piggybacking. You
still have not done that. 

 > Finally, my position is that removing piggybacking is not an option.

Everything is an option. The draft is not done.

	      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 20:34:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17986
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 20:34:06 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18703;
	Wed, 24 Oct 2001 18:33:27 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01803;
	Wed, 24 Oct 2001 17:33:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P0Vu6C019003
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:31:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9P0VtZg019002
	for mobile-ip-dist; Wed, 24 Oct 2001 17:31:55 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P0Vq6C018995
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:31:52 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09390
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:31:55 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17735
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 18:31:54 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA05417;
	Wed, 24 Oct 2001 17:31:45 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9P0Vhb13419;
	Wed, 24 Oct 2001 17:31:43 -0700
X-mProtect:  Wed, 24 Oct 2001 17:31:43 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdjJlT09; Wed, 24 Oct 2001 17:30:22 PDT
Message-ID: <3BD75D1F.7954FAE1@iprg.nokia.com>
Date: Wed, 24 Oct 2001 17:30:23 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of 
 the security discussion
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com> <15319.22926.148456.166125@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

You cannot stop an IPv6 host from including destination option in
_arbitrary_ packets. In that sense, removing piggybacking is not an
option. Any link that claims to carry IPv6 must know how to handle
destination option in any arbitrary packet. As I indicated, IF performance
is the issue, appropriate text can be added in the draft.

Regards,

-Rajeev


Michael Thomas wrote:

> Koodli Rajeev (NRC/MtView) writes:
>   >You say if it does, it has performance issues. I say we
>  > don't design based on a link's performance..
>
> _Oh_??? There's a difference between being a slave
> to link layers and not considering them at all. If
> I believed that this was a narrow situation that
> is only related to a single link layer which needs
> to be redesigned for IP anyway, you would not be
> getting any arguments from me. However, I believe
> that this slotting problem that we've been
> describing is a fundamental engineering tradeoff
> when you have a shared media, such as radio.
>
> I have repeatedly asked for a concrete example of
> a shared media which provides QoS guarantees which
> would substantially benefit from piggybacking. You
> still have not done that.
>
>  > Finally, my position is that removing piggybacking is not an option.
>
> Everything is an option. The draft is not done.
>
>               Mike



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 24 20:45:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18102
	for <mobileip-archive@odin.ietf.org>; Wed, 24 Oct 2001 20:45:49 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23215;
	Wed, 24 Oct 2001 17:45:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04124;
	Wed, 24 Oct 2001 17:45:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P0i86C019159
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:44:08 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9P0i8Oj019158
	for mobile-ip-dist; Wed, 24 Oct 2001 17:44:08 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P0i46C019151
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:44:04 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03870
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:44:08 -0700 (PDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18810
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 17:44:07 -0700 (PDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9P0fx912732;
	Wed, 24 Oct 2001 17:41:59 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE20849;
	Wed, 24 Oct 2001 17:43:30 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA10878; Wed, 24 Oct 2001 17:44:05 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15319.24661.737460.932886@thomasm-u1.cisco.com>
Date: Wed, 24 Oct 2001 17:44:05 -0700 (PDT)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'ext Hesham Soliman (EPA)'" <Hesham.Soliman@ericsson.com.au>,
        "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho" <mramalho@cisco.com>
Subject: Re: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of 
 the security discussion
In-Reply-To: <3BD75D1F.7954FAE1@iprg.nokia.com>
References: <A6D9D7495456414BA08DB655C2AC6712078143@bsebe001.NOE.Nokia.com>
	<15319.22926.148456.166125@thomasm-u1.cisco.com>
	<3BD75D1F.7954FAE1@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I don't know how this can be made to be any
clearer than has been tried by the endless
attempts by many different people. Since you won't
answer the one pertinent question, there is no
point to this discussion.

	 Mike

Rajeev Koodli writes:
 > You cannot stop an IPv6 host from including destination option in
 > _arbitrary_ packets. In that sense, removing piggybacking is not an
 > option. Any link that claims to carry IPv6 must know how to handle
 > destination option in any arbitrary packet. As I indicated, IF performance
 > is the issue, appropriate text can be added in the draft.
 > 
 > Regards,
 > 
 > -Rajeev
 > 
 > 
 > Michael Thomas wrote:
 > 
 > > Koodli Rajeev (NRC/MtView) writes:
 > >   >You say if it does, it has performance issues. I say we
 > >  > don't design based on a link's performance..
 > >
 > > _Oh_??? There's a difference between being a slave
 > > to link layers and not considering them at all. If
 > > I believed that this was a narrow situation that
 > > is only related to a single link layer which needs
 > > to be redesigned for IP anyway, you would not be
 > > getting any arguments from me. However, I believe
 > > that this slotting problem that we've been
 > > describing is a fundamental engineering tradeoff
 > > when you have a shared media, such as radio.
 > >
 > > I have repeatedly asked for a concrete example of
 > > a shared media which provides QoS guarantees which
 > > would substantially benefit from piggybacking. You
 > > still have not done that.
 > >
 > >  > Finally, my position is that removing piggybacking is not an option.
 > >
 > > Everything is an option. The draft is not done.
 > >
 > >               Mike
 > 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 00:00:42 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23685
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 00:00:42 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21902;
	Wed, 24 Oct 2001 21:59:54 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15128;
	Wed, 24 Oct 2001 20:59:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P3wj6C019450
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 20:58:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9P3wiMG019449
	for mobile-ip-dist; Wed, 24 Oct 2001 20:58:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P3wf6C019442
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 20:58:41 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09966
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 20:58:44 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22378
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 20:58:43 -0700 (PDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA13001
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 13:57:33 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA05734
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 13:58:40 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VGPNK52V>; Thu, 25 Oct 2001 13:58:39 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDE0@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Koodli Rajeev (NRC/MtView)'" <rajeev.koodli@nokia.com>,
        "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>,
        mobile-ip@sunroof.eng.sun.com
Cc: "'ext Michael Thomas'" <mat@cisco.com>,
        "Michael A. Ramalho"
	 <mramalho@cisco.com>
Subject: RE: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Fo
	cus of the security discussion
Date: Thu, 25 Oct 2001 13:58:38 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
	Rajeev, 

>  
> this is continuing to be a long discussion. Anyway, I think we are
> probably converging on some issues. Let me make a (bold) try in
> summarizing the discussion.
>  
> - "tight channel" is the main focus. 
> - I say on such a channel, HC is likely used. You have concurred. My claim
> is HC will work with piggybacking. You seem to agree. However, there is
> something below to iron out.
> - My position is that if a link supports IPv6, destination option is a
> given. You seem to agree. I say this means it is supporting piggybacking.
> You say if it does, it has performance issues. I say we don't design based
> on a link's performance..
> - Service disruption is moot to me. See comments below.
> 
	=> OK great, I'm glad you went to the bottom of it. Minimising
service
	disruption is definitely not moot to some of us. I have customers
	that are interested in minimising service disruption, but 
	that's out of the list's scope. 
>  
> Finally, my position is that removing piggybacking is not an option. 
> 
	=> That's fine, but it was good to know
	the motives. Anyway, I attempted to provide alternatives
	so let's see what others tink.

> However, including some text in the draft stating that some links MAY have
> performance issues to consider when piggybacking is fine with me. I think
> this may be the way forward.
> 
	=> I don't think this is enough. We have seen that it is 
	an e2e problem. Without providing a concrete fix I think
	the problem still stands. I think we've discussed this 
	just about enough and I'll get out before the circle 
	starts again, but I have one comment below.
>   
> 
> 
> => I didn't refer to piggybacking ! They violate MIPv6 which clearly 
> states that forwarding to a new CoA must be done based on 
> the reception of an authenticated BU. They don't violate 
> the base IPv6, but MIPv6. Is that allowed ? If so then I 
> don't understand the "violation" argument. 
> 
> 
> [Rajeev]  This is a good argument to discuss. In FMIPv6 at least, if you
> keep the old CoA, there is no requirement for BU. If the network does host
> routing, it is not violating anything either. So, I am not sure what they
> are violating..
> 
	=> We're talking about MIPv6, right ? As I'm sure you're aware, 
	the decision of the oAR (acting like a HA) to forward packets
	to another address is only allowed when an authenticated BU is 
	received. Now if you're saying host routes are used in the 
	domain, what is propagating these host routes ?
	As far as I can see, in FMIPv6 the oAR either tunnels
	to the new CoA, or to the nAR (BETH). There was no 
	protocol designed to propagate host routes, unless
	you're assuming the MN is running a routing protocol, 
	which is certainly not the case in FMIPv6. 

	Regards,
	Hesham


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 00:02:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23735
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 00:02:15 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22637;
	Wed, 24 Oct 2001 22:01:28 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15567;
	Wed, 24 Oct 2001 21:01:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P40S6C019486
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 21:00:28 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9P40Smv019485
	for mobile-ip-dist; Wed, 24 Oct 2001 21:00:28 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P40O6C019475
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 21:00:24 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10162
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 21:00:27 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA03921
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 22:07:35 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA13153
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 13:59:16 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA06222
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 14:00:24 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VGPNK5JZ>; Thu, 25 Oct 2001 14:00:23 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDE1@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition
Date: Thu, 25 Oct 2001 14:00:22 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15D09.9194EE30"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15D09.9194EE30
Content-Type: text/plain

> I also believe that this is an important work item to persue, in view of
> the
> fact that 3GPP has mandated using IPv6 as transport over the UTRAN. IPv6
> is
> also considered by other SDO's in other cellular networks as well. Thus,
> in
> order to interconnect these systems, to the IP backbone, which currently
> runs IPv4, solutions like the "dual stack model" will be very important.
> 
	=> Transport level issues are not related to MIP. A dual stack
	model with 6-to-4 support or configured tunnels will do the job. 

	Hesham

> -----Original Message-----
> From: Eng Soo Guan [mailto:engsg@cwc.nus.edu.sg]
> Sent: Tuesday, October 23, 2001 10:04 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] IPv4 and MIPv6 Transition
> 
> 
> Dear All,
> 
> I would like to know if any work has being done with regard to
> 'transiting'
> to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a
> NAT.
> 
> The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
> Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks
> based on Dual-Stack Model".
> 
> I read found the NGTRANS Shipworm draft attractive to be modified for
> MIPv6
> in a IPv4 only network behind a NAT.
> 
> Warmest regards.
> 
> SG
> Soo Guan, Eng
> Centre for Wireless Communications, NUS
> http://www.cwc.nus.edu.sg
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

------_=_NextPart_001_01C15D09.9194EE30
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] IPv4 and MIPv6 Transition</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I also believe that this is an =
important work item to persue, in view of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">fact that 3GPP has mandated using =
IPv6 as transport over the UTRAN. IPv6 is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">also considered by other SDO's in =
other cellular networks as well. Thus, in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">order to interconnect these systems, =
to the IP backbone, which currently</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">runs IPv4, solutions like the =
&quot;dual stack model&quot; will be very important.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Transport =
level issues are not related to MIP. A dual stack</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">model with 6-to-4 =
support or configured tunnels will do the job. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Eng Soo Guan [</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:engsg@cwc.nus.edu.sg">mailto:engsg@cwc.nus.edu.sg</A></FO=
NT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Tuesday, October 23, 2001 10:04 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
mobile-ip@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: [mobile-ip] IPv4 and MIPv6 =
Transition</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dear All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to know if any work has =
being done with regard to 'transiting'</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to Mobile IPv6 with IPv4 Internet, =
especially with Mobile Node behing a NAT.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The closet drafts I find are =
&quot;Mobile IPv4 Traversal Across NAT and VPN</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Gateways&quot; and &quot;Mobility =
Support for IPv4 and IPv6 Interconnected Networks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">based on Dual-Stack =
Model&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I read found the NGTRANS Shipworm =
draft attractive to be modified for MIPv6</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in a IPv4 only network behind a =
NAT.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Warmest regards.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SG</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Soo Guan, Eng</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Centre for Wireless Communications, =
NUS</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.cwc.nus.edu.sg" =
TARGET=3D"_blank">http://www.cwc.nus.edu.sg</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15D09.9194EE30--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 01:55:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28131
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 01:55:26 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA29573;
	Wed, 24 Oct 2001 22:54:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27598;
	Wed, 24 Oct 2001 22:54:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P5rm6C019797
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 24 Oct 2001 22:53:48 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9P5rm8h019796
	for mobile-ip-dist; Wed, 24 Oct 2001 22:53:48 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P5ri6C019789
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 22:53:44 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07279
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 22:53:46 -0700 (PDT)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06478
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 24 Oct 2001 23:53:45 -0600 (MDT)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA22903
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:52:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA04281
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:53:39 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <VGPNK81G>; Thu, 25 Oct 2001 15:53:38 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308EDE6@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition
Date: Thu, 25 Oct 2001 15:53:37 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15D19.63D91060"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15D19.63D91060
Content-Type: text/plain


	Pekka, 

> Perhaps I shouldn't comment on this, but anyway...
> 
	=> Why not !

> > There is another draft you can find at:
> > http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt
> > 
> > It's a WG draft in NGTRANS but it expired and I'll
> > resubmit it after adding some of the comments received. 
> 
> SIIT is regarded by many to be an abomination (redefining internal 
> structure like mapped-addresses) from security point-of-view among others.
> 
> It can probably solve some problems efficiently though, or else it 
> wouldn't have been introduced. :-)
> 
	=> Well SIIT is a translation algorithm, used by NAT-PT and
	this draft. It certainly does solve problems, like translating
	packets.

> But it should be kept in mind that it, alone, cannot be relied on to be
> sufficient for (M)IPv4 -> (M)IPv6 transition.
> 
	=> Can you elaborate a bit ? This draft is done for allowing
	IPv4-only nodes to communicate with IPv6-only nodes. 
	MIP is one aspect of this communication. 
	The draft doesn't say that this is the only way to do it, 
	although in fact, for this scenario, it is the only way I know
	of that allows for mobility support. 

	Hesham


------_=_NextPart_001_01C15D19.63D91060
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: [mobile-ip] IPv4 and MIPv6 Transition</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Pekka, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Perhaps I shouldn't comment on this, =
but anyway...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Why not =
!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; There is another draft you can =
find at:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dst=
m-00.txt" =
TARGET=3D"_blank">http://standards.ericsson.net/hesham/draft-ietf-ngtran=
s-siit-dstm-00.txt</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; It's a WG draft in NGTRANS but =
it expired and I'll</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; resubmit it after adding some of =
the comments received. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SIIT is regarded by many to be an =
abomination (redefining internal </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">structure like mapped-addresses) from =
security point-of-view among others.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It can probably solve some problems =
efficiently though, or else it </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">wouldn't have been introduced. =
:-)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Well SIIT is =
a translation algorithm, used by NAT-PT and</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">this draft. It =
certainly does solve problems, like translating</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">packets.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But it should be kept in mind that it, =
alone, cannot be relied on to be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sufficient for (M)IPv4 -&gt; (M)IPv6 =
transition.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">=3D&gt; Can you =
elaborate a bit ? This draft is done for allowing</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">IPv4-only nodes to =
communicate with IPv6-only nodes. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">MIP is one aspect =
of this communication. </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The draft doesn't =
say that this is the only way to do it, </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">although in fact, =
for this scenario, it is the only way I know</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">of that allows for =
mobility support. </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hesham</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C15D19.63D91060--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 05:26:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12272
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 05:26:32 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03024;
	Thu, 25 Oct 2001 03:25:51 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19039;
	Thu, 25 Oct 2001 02:25:20 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P9OW6C020076
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 02:24:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9P9OWsG020075
	for mobile-ip-dist; Thu, 25 Oct 2001 02:24:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9P9OS6C020068
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 02:24:28 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26886
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 02:24:31 -0700 (PDT)
From: Yanqun.Le@nokia.com
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22382
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 02:24:29 -0700 (PDT)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9P9P5A11374
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 12:25:06 +0300 (EET DST)
Received: from esebh11nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d03a451fac158f231f3@esvir03nok.nokia.com>;
 Thu, 25 Oct 2001 12:24:27 +0300
Received: by esebh11nok with Internet Mail Service (5.5.2652.78)
	id <VLFJDJCF>; Thu, 25 Oct 2001 12:24:28 +0300
Message-ID: <4AE1AC3D692F55488F2D03518907B8AD063D01@beebe001.NOE.Nokia.com>
To: pcalhoun@diameter.org, charliep@iprg.nokia.com
Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] about the password in Bake off test cases
Date: Thu, 25 Oct 2001 12:21:53 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi,

Looking through RFC2002, I can't find any text about password. And I
wonder how can mobile node send password to Foreign Agent. Is password
sent by Registration Request?

Even if Foreign Agent received password, by which AVP does it deliver
the password to AAA server?

Thank you in advance.

Le Yanqun

  


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 06:06:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12665
	for <mobileip-archive@lists.ietf.org>; Thu, 25 Oct 2001 06:06:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA14087;
	Thu, 25 Oct 2001 03:05:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22894;
	Thu, 25 Oct 2001 03:05:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PA4X6C020234
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 03:04:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PA4WFr020233
	for mobile-ip-dist; Thu, 25 Oct 2001 03:04:32 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PA4T6C020226
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 03:04:29 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18102
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 03:04:30 -0700 (PDT)
From: Yanqun.Le@nokia.com
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24049
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 04:04:25 -0600 (MDT)
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PA51A18491
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 13:05:01 +0300 (EET DST)
Received: from esebh11nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d05ed7a6ac158f24077@esvir04nok.ntc.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Thu, 25 Oct 2001 13:04:23 +0300
Received: by esebh11nok with Internet Mail Service (5.5.2652.78)
	id <VLFJDTKK>; Thu, 25 Oct 2001 13:04:19 +0300
Message-ID: <4AE1AC3D692F55488F2D03518907B8AD063D1B@beebe001.NOE.Nokia.com>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] problem about deregistration of MIP
Date: Thu, 25 Oct 2001 13:03:53 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="gb2312"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

hi,

When a mobile node send Registration Request to a Mobile IP Agent, how
can the Agent decide whether the mobile node doing deregistration? By
which criterion below?
1) care-of-address equal to its home address, 
2) registration lifetime equal to 0;
3) if NAI exists in Registration Request ,the realm part of NAI is the
same to the realm the Agent belongs to.

Can every one be used to decide deregistration or the combination of
those?

Thanks 
Le Yanqun
 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 06:37:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12888
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 06:37:11 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22443;
	Thu, 25 Oct 2001 03:36:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21170;
	Thu, 25 Oct 2001 03:36:15 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PAZL6C020424
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 03:35:21 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PAZL1o020423
	for mobile-ip-dist; Thu, 25 Oct 2001 03:35:21 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PAZH6C020416
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 03:35:17 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10516
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 03:35:18 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA02361
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 03:35:18 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com
          via smtpd (for saturn.Sun.COM [192.9.25.2]) with SMTP; 25 Oct 2001 10:31:48 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4])
	by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id GAA01640
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 06:35:17 -0400 (EDT)
Received: from exno02.dynas.se (localhost [127.0.0.1])
	by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id GAA23071
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 06:35:15 -0400 (EDT)
Received: from sjosefsson-pc.d.dynas.se ([172.16.13.115]) by exno02.dynas.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 4WCBZ9YW; Thu, 25 Oct 2001 12:35:00 +0200
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] RFC2002bis and MD5 vs SHA1
From: Simon Josefsson <sjosefsson@dynas.se>
Date: Thu, 25 Oct 2001 12:37:32 +0200
Message-ID: <m3adyg80pf.fsf@sjosefsson-pc.d.dynas.se>
Lines: 14
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Since the Son-Of-RFC2002 draft changes the mandatory authentication
from keyed-MD5 in prefix+suffix mode to HMAC-MD5, is it too late to
instead change it into HMAC-SHA1?  See for instance
ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf for a
discussion on MD5 security, I assume it hasn't gotten stronger since
then.

Several protocols have been moving from MD5 to SHA1 as the default
hash function for some time now, and I think it would be unfortunate
to change protocols so that they use MD5 today.

If there is a possibility of changing it without affecting
implementations (you don't implement IETF drafts, do you? <g>) I think
it would be good to do this.



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 07:44:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14361
	for <mobileip-archive@lists.ietf.org>; Thu, 25 Oct 2001 07:44:37 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13900;
	Thu, 25 Oct 2001 05:43:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02026;
	Thu, 25 Oct 2001 04:43:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PBge6C020646
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 04:42:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PBgeC1020645
	for mobile-ip-dist; Thu, 25 Oct 2001 04:42:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PBgb6C020638
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 04:42:37 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01923
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 04:42:28 -0700 (PDT)
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.com [193.49.124.32])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA13035
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 05:42:36 -0600 (MDT)
Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id <4JT8CSW8>; Thu, 25 Oct 2001 13:42:27 +0200
Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr>
From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE
	 <mohamed.kassilahlou@rd.francetelecom.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition
Date: Thu, 25 Oct 2001 13:41:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9PBgb6C020639
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello,

If the MN and the HA are dual-stack, the solution could be the following:
On the home network, the MN receives an Ipv6 RA with the H bit set and an
Ipv4 RA with the H bit set.
When the MN arrives on the visited Ipv4 network, it acquires an Ipv4 CoA
(co-located CoA) and tunnels Ipv6 BU in Ipv4 packets to its HA.
The HA intercepts Ipv6 packets intended for the MN and tunnels them to the
MN in Ipv4 packets.
The MN tunnels Ipv6 packets intended for the CN in Ipv4 packets to the HA.
The HA decapsulates the packets and sends them directly to the CN.

The same solution can be used when the CN is Ipv4 and the visited network is
Ipv6.

I do not know any developments about this but it could be a new work item.

Kassi

-----Message d'origine-----
De : Eng Soo Guan [mailto:engsg@cwc.nus.edu.sg]
Envoyé : mercredi 24 octobre 2001 11:07
À : mobile-ip@sunroof.eng.sun.com
Objet : Re: [mobile-ip] IPv4 and MIPv6 Transition


Thanx for your reply.

I read the SITT and DSTM draft. My question is that MN is using DSTM. But
there are possible cases where MN cannot obtain a "IPv4 Global Addresses".
As such, the SITT and DSTM solution is not what I am looking for.

If a MN visits a foreign IPv4 network running NAT and DHCP (and no 6to4,
Tunnel Broker or 6over4 stuff), how can the MN sends a Binding Update to its
Home Agent in IPv6? Can the MN uses some configuration information it has
when it was previously at home to access the 6Bone?

The best candidate I see it Shipworm. I'm wondering if anyone has come
across other proposals.

SG
Soo Guan, Eng
R&D Engineer (Software Lab)
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
Tel (65) 8709330
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- Original Message -----
From: Hesham Soliman (EPA)
To: 'mobile-ip@sunroof.eng.sun.com'
Sent: Wednesday, October 24, 2001 3:12 PM
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition


Hello Eng,
There is another draft you can find at:
http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt
It's a WG draft in NGTRANS but it expired and I'll
resubmit it after adding some of the comments received.
Cheers,
Hesham


-----Original Message-----
From:   Eng Soo Guan [SMTP:engsg@cwc.nus.edu.sg]
Sent:   Wednesday, 24 October 2001 12:04
To:     mobile-ip@sunroof.eng.sun.com
Subject:        [mobile-ip] IPv4 and MIPv6 Transition
Dear All,
I would like to know if any work has being done with regard to 'transiting'
to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a NAT.
The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks
based on Dual-Stack Model".
I read found the NGTRANS Shipworm draft attractive to be modified for MIPv6
in a IPv4 only network behind a NAT.
Warmest regards.
SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 08:54:53 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17126
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 08:54:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29413;
	Thu, 25 Oct 2001 06:54:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08631;
	Thu, 25 Oct 2001 05:53:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PCqr6C020848
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 05:52:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PCqrRY020847
	for mobile-ip-dist; Thu, 25 Oct 2001 05:52:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PCqk6C020832;
	Thu, 25 Oct 2001 05:52:46 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18019;
	Thu, 25 Oct 2001 05:52:49 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28343;
	Thu, 25 Oct 2001 06:52:47 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9PCqkK19944;
	Thu, 25 Oct 2001 15:52:46 +0300
Date: Thu, 25 Oct 2001 15:52:46 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <ngtrans@sunroof.eng.sun.com>
cc: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Security and use of SIIT and NAT-PT [IPv4 and MIPv6 Transition]
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308EDE6@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110251528520.19785-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I'll post this primary on ngtrans.  If there are further comments I think 
mobile-ip can be safely removed.

On Thu, 25 Oct 2001, Hesham Soliman (EPA) wrote:
> > Perhaps I shouldn't comment on this, but anyway...
> > 
> 	=> Why not !

Partly ideological debate, better held in ngtrans anyway :-)
 
> > > There is another draft you can find at:
> > > http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt
> > > 
> > > It's a WG draft in NGTRANS but it expired and I'll
> > > resubmit it after adding some of the comments received. 
> > 
> > SIIT is regarded by many to be an abomination (redefining internal 
> > structure like mapped-addresses) from security point-of-view among others.
> > 
> > It can probably solve some problems efficiently though, or else it 
> > wouldn't have been introduced. :-)
> > 
> 	=> Well SIIT is a translation algorithm, used by NAT-PT and
> 	this draft. It certainly does solve problems, like translating
> 	packets.

There is a significant difference with SIIT and NAT-PT algorithm.  NAT-PT
does not use mapped addresses when signifying an IPv4 node.

Putting mapped addresses as source/destination addresses is evil; think of
(ab)using these against dual-stacked nodes. 

E.g.: IPv4 firewall would block packets from source 1.2.3.4, but the
packet gets through via IPv6 transport with src address ::ffff:1.2.3.4,
and the destination will falsely believe that it originated from IPv4
source 1.2.3.4.

This would open some new IPv6 <-> IPv4 reflector attacks, too, I believe.
 
> > But it should be kept in mind that it, alone, cannot be relied on to be
> > sufficient for (M)IPv4 -> (M)IPv6 transition.
> > 
> 	=> Can you elaborate a bit ? This draft is done for allowing
> 	IPv4-only nodes to communicate with IPv6-only nodes. 
> 	MIP is one aspect of this communication. 
> 	The draft doesn't say that this is the only way to do it, 
> 	although in fact, for this scenario, it is the only way I know
> 	of that allows for mobility support. 

Perhaps I didn't say it clearly; _IMO_, SIIT is not fit to be a
wide-spread translation mechanism for IPv6-only nodes.  NAT-PT seems much
better.  I tried to avoid getting MIP mixed into this.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 10:06:57 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19765
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 10:06:57 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03629;
	Thu, 25 Oct 2001 07:05:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02605;
	Thu, 25 Oct 2001 07:04:16 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PE2x6C021116
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:02:59 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PE2wAm021115
	for mobile-ip-dist; Thu, 25 Oct 2001 07:02:58 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PE2t6C021108
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:02:55 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29911
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:02:46 -0700 (PDT)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01156
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 08:11:41 -0600 (MDT)
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="GB2312"
Subject: RE: [mobile-ip] problem about deregistration of MIP
Date: Thu, 25 Oct 2001 10:02:44 -0400
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB2109CEAD@EXCHANGE01.domain.ecutel.com>
Thread-Topic: [mobile-ip] problem about deregistration of MIP
Thread-Index: AcFdPOdRDXY1duYwTPWALuPSp1rY7QAKc8CA
From: "Qiang Zhang" <qzhang@ecutel.com>
To: <mobile-ip@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9PE2t6C021109
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Yanqun,

The requested reg life time =0 should be used to determine the
deregistration. 

Qiang

-----Original Message-----
From: Yanqun.Le@nokia.com [mailto:Yanqun.Le@nokia.com]
Sent: Thursday, October 25, 2001 5:04 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] problem about deregistration of MIP


hi,

When a mobile node send Registration Request to a Mobile IP Agent, how
can the Agent decide whether the mobile node doing deregistration? By
which criterion below?
1) care-of-address equal to its home address, 
2) registration lifetime equal to 0;
3) if NAI exists in Registration Request ,the realm part of NAI is the
same to the realm the Agent belongs to.

Can every one be used to decide deregistration or the combination of
those?

Thanks 
Le Yanqun
 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 10:25:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20177
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 10:25:40 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12786;
	Thu, 25 Oct 2001 07:25:03 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05087;
	Thu, 25 Oct 2001 07:24:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PENv6C021259
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:23:57 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PENv3f021258
	for mobile-ip-dist; Thu, 25 Oct 2001 07:23:57 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PENr6C021251
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:23:53 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04992
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:23:55 -0700 (PDT)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06344
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 08:23:54 -0600 (MDT)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09YZQM>; Thu, 25 Oct 2001 10:22:56 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA96@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition
Date: Thu, 25 Oct 2001 10:22:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15D60.89F14AA0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15D60.89F14AA0
Content-Type: text/plain;
	charset="iso-8859-1"

            Yes, that is correct. I was actually referring to tunneling IPv6
packets coming from the UTRAN, over an IPv4 backbone.
 
            Sharif.

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Thursday, October 25, 2001 12:00 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition



	I also believe that this is an important work item to persue, in
view of the 
fact that 3GPP has mandated using IPv6 as transport over the UTRAN. IPv6 is 
also considered by other SDO's in other cellular networks as well. Thus, in 
order to interconnect these systems, to the IP backbone, which currently 
runs IPv4, solutions like the "dual stack model" will be very important. 

	=> Transport level issues are not related to MIP. A dual stack 
model with 6-to-4 support or configured tunnels will do the job. 

	Hesham 

	-----Original Message----- 
From: Eng Soo Guan [ mailto:engsg@cwc.nus.edu.sg
<mailto:engsg@cwc.nus.edu.sg> ] 
Sent: Tuesday, October 23, 2001 10:04 PM 
To: mobile-ip@sunroof.eng.sun.com 
Subject: [mobile-ip] IPv4 and MIPv6 Transition 


	Dear All, 

	I would like to know if any work has being done with regard to
'transiting' 
to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a NAT.


	The closet drafts I find are "Mobile IPv4 Traversal Across NAT and
VPN 
Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks 
based on Dual-Stack Model". 

	I read found the NGTRANS Shipworm draft attractive to be modified
for MIPv6 
in a IPv4 only network behind a NAT. 

	Warmest regards. 

	SG 
Soo Guan, Eng 
Centre for Wireless Communications, NUS 
http://www.cwc.nus.edu.sg <http://www.cwc.nus.edu.sg>  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 


------_=_NextPart_001_01C15D60.89F14AA0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [mobile-ip] IPv4 and MIPv6 Transition</TITLE>

<META content="MSHTML 5.00.3211.1700" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=889092614-25102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Yes, that is correct. I was actually referring to tunneling IPv6 packets coming 
from the UTRAN, over an IPv4 backbone.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=889092614-25102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=889092614-25102001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Sharif.</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hesham Soliman (EPA) 
  [mailto:Hesham.Soliman@ericsson.com.au]<BR><B>Sent:</B> Thursday, October 25, 
  2001 12:00 AM<BR><B>To:</B> 'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> 
  RE: [mobile-ip] IPv4 and MIPv6 Transition<BR><BR></DIV></FONT>
  <UL>
    <P><FONT face=Arial size=2>I also believe that this is an important work 
    item to persue, in view of the</FONT> <BR><FONT face=Arial size=2>fact that 
    3GPP has mandated using IPv6 as transport over the UTRAN. IPv6 is</FONT> 
    <BR><FONT face=Arial size=2>also considered by other SDO's in other cellular 
    networks as well. Thus, in</FONT> <BR><FONT face=Arial size=2>order to 
    interconnect these systems, to the IP backbone, which currently</FONT> 
    <BR><FONT face=Arial size=2>runs IPv4, solutions like the "dual stack model" 
    will be very important.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>=&gt; Transport level issues are 
    not related to MIP. A dual stack</FONT> <BR><FONT color=#0000ff face=Arial 
    size=2>model with 6-to-4 support or configured tunnels will do the job. 
    </FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>Hesham</FONT> </P>
    <P><FONT face=Arial size=2>-----Original Message-----</FONT> <BR><FONT 
    face=Arial size=2>From: Eng Soo Guan [</FONT><U><FONT color=#0000ff 
    face=Arial size=2><A 
    href="mailto:engsg@cwc.nus.edu.sg">mailto:engsg@cwc.nus.edu.sg</A></FONT></U><FONT 
    face=Arial size=2>]</FONT> <BR><FONT face=Arial size=2>Sent: Tuesday, 
    October 23, 2001 10:04 PM</FONT> <BR><FONT face=Arial size=2>To: 
    mobile-ip@sunroof.eng.sun.com</FONT> <BR><FONT face=Arial size=2>Subject: 
    [mobile-ip] IPv4 and MIPv6 Transition</FONT> </P><BR>
    <P><FONT face=Arial size=2>Dear All,</FONT> </P>
    <P><FONT face=Arial size=2>I would like to know if any work has being done 
    with regard to 'transiting'</FONT> <BR><FONT face=Arial size=2>to Mobile 
    IPv6 with IPv4 Internet, especially with Mobile Node behing a NAT.</FONT> 
    </P>
    <P><FONT face=Arial size=2>The closet drafts I find are "Mobile IPv4 
    Traversal Across NAT and VPN</FONT> <BR><FONT face=Arial size=2>Gateways" 
    and "Mobility Support for IPv4 and IPv6 Interconnected Networks</FONT> 
    <BR><FONT face=Arial size=2>based on Dual-Stack Model".</FONT> </P>
    <P><FONT face=Arial size=2>I read found the NGTRANS Shipworm draft 
    attractive to be modified for MIPv6</FONT> <BR><FONT face=Arial size=2>in a 
    IPv4 only network behind a NAT.</FONT> </P>
    <P><FONT face=Arial size=2>Warmest regards.</FONT> </P>
    <P><FONT face=Arial size=2>SG</FONT> <BR><FONT face=Arial size=2>Soo Guan, 
    Eng</FONT> <BR><FONT face=Arial size=2>Centre for Wireless Communications, 
    NUS</FONT> <BR><U><FONT color=#0000ff face=Arial size=2><A 
    href="http://www.cwc.nus.edu.sg" 
    target=_blank>http://www.cwc.nus.edu.sg</A></FONT></U> <BR><FONT face=Arial 
    size=2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT> </P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15D60.89F14AA0--


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 10:42:45 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20689
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 10:42:44 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21645;
	Thu, 25 Oct 2001 08:42:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08456;
	Thu, 25 Oct 2001 07:41:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PEf36C021428
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:41:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PEf3id021427
	for mobile-ip-dist; Thu, 25 Oct 2001 07:41:03 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PEex6C021420
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:40:59 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09287
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:41:01 -0700 (PDT)
Received: from smail2.dmz1.icn.siemens.it ([213.156.59.6])
	by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA11721
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:40:59 -0700 (PDT)
Received: FROM imail.icn.siemens.it BY smail2.dmz1.icn.siemens.it ; Thu Oct 25 16:41:40 2001 +0200
Received: from ii1su001.settimo.italtel.it (ii1hu001.settimo.italtel.it [141.29.204.93])
	by imail.icn.siemens.it (8.9.3/8.9.3) with ESMTP id QAA16714
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 16:35:47 +0200 (MET DST)
Received: from iltcw051 (iltcw051.icn.siemens.it [141.29.194.190])
 by ii1su001.settimo.italtel.it
 (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8)
 with SMTP id <0GLR00BDLNMI9L@ii1su001.settimo.italtel.it> for
 mobile-ip@sunroof.eng.sun.com; Thu, 25 Oct 2001 16:44:42 +0200 (MET DST)
Date: Thu, 25 Oct 2001 16:40:17 +0200
From: emanuel monticelli <emanuel.monticelli@icn.siemens.it>
Subject: [mobile-ip] Any news about Fast Handovers for MIPv6 ?
To: mobile-ip@sunroof.eng.sun.com
Message-id: <013501c15d62$f6fdf060$bec21d8d@icn.siemens.it>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: multipart/alternative;
	boundary="----=_NextPart_000_0132_01C15D73.BA699B70"
X-Priority: 3
X-MSMail-priority: Normal
References: 
 <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0132_01C15D73.BA699B70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Any news about Fast Handovers for MIPv6 other than the 02 draft ?
Do you know anyone that is trying to implement something in this area ?

Thanks

Emanuel Monticelli

------=_NextPart_000_0132_01C15D73.BA699B70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4522.1801" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial>Any news about Fast Handovers for =
MIPv6 other=20
than the 02 draft ?</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Do you know anyone that is trying to =
implement=20
something in this area ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Emanuel =
Monticelli</FONT></DIV></BODY></HTML>

------=_NextPart_000_0132_01C15D73.BA699B70--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 10:55:01 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20853
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 10:55:00 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26594;
	Thu, 25 Oct 2001 07:54:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09369;
	Thu, 25 Oct 2001 07:47:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PEkV6C021539
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:46:32 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PEkVqB021538
	for mobile-ip-dist; Thu, 25 Oct 2001 07:46:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PEkS6C021531
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:46:28 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25963
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 07:46:19 -0700 (PDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA25938
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 08:46:29 -0600 (MDT)
Received: (qmail 4954 invoked by uid 500); 25 Oct 2001 14:30:55 -0000
Date: Thu, 25 Oct 2001 07:30:55 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Yanqun.Le@nokia.com
Cc: pcalhoun@diameter.org, charliep@iprg.nokia.com, aaa-wg@merit.edu,
        mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Re: about the password in Bake off test cases
Message-ID: <20011025073055.C4902@charizard.diameter.org>
Mail-Followup-To: Yanqun.Le@nokia.com, pcalhoun@diameter.org,
	charliep@iprg.nokia.com, aaa-wg@merit.edu,
	mobile-ip@sunroof.eng.sun.com
References: <4AE1AC3D692F55488F2D03518907B8AD063D01@beebe001.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4AE1AC3D692F55488F2D03518907B8AD063D01@beebe001.NOE.Nokia.com>; from Yanqun.Le@nokia.com on Thu, Oct 25, 2001 at 12:21:53PM +0300
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Thu, Oct 25, 2001 at 12:21:53PM +0300, Yanqun.Le@nokia.com wrote:
> Hi,
> 
> Looking through RFC2002, I can't find any text about password. And I
> wonder how can mobile node send password to Foreign Agent. Is password
> sent by Registration Request?
> 
> Even if Foreign Agent received password, by which AVP does it deliver
> the password to AAA server?

sorry, what is a password?

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 15:25:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28064
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 15:25:32 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21245;
	Thu, 25 Oct 2001 13:25:00 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18882;
	Thu, 25 Oct 2001 12:24:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PJNf6C022348
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 12:23:41 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PJNf8Q022347
	for mobile-ip-dist; Thu, 25 Oct 2001 12:23:41 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PJNb6C022340
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 12:23:37 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22439
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 12:23:39 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20020
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 13:23:39 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA05111
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 12:23:38 -0700 (PDT)
X-Delivered-For: <mobile-ip@sunroof.eng.sun.com>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9PJNcR00733
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 12:23:38 -0700
X-mProtect:  Thu, 25 Oct 2001 12:23:38 -0700 Nokia Silicon Valley Messaging Protection
Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd5wysb0; Thu, 25 Oct 2001 12:23:36 PDT
Message-ID: <3BD866B9.3DA53695@iprg.nokia.com>
Date: Thu, 25 Oct 2001 12:23:37 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Any news about Fast Handovers for MIPv6 ?
References: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr> <013501c15d62$f6fdf060$bec21d8d@icn.siemens.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

We have an implementation of the 02 draft. Rajeev Koodli did a 
presentation at the London IETF on a few issues that we encountered
while implementing it.

and take a look at the following journal paper. "Fast Handovers and
Context Transfer in Mobile Networks" to appear in  ACM Computer 
Communication Review (october 2001 issue). It has some performance
results from the Fast Handoff tests we did on our testbed.

and the results look very promising. Fast Handoffs (02 draft) does
not need any additional improvements/enhancements (IMHO). 

Vijay

> emanuel monticelli wrote:
> 
> Hi,
> 
> Any news about Fast Handovers for MIPv6 other than the 02 draft ?
> Do you know anyone that is trying to implement something in this area
> ?
> 
> Thanks
> 
> Emanuel Monticelli


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 18:31:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01419
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 18:31:57 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22293;
	Thu, 25 Oct 2001 16:31:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00569;
	Thu, 25 Oct 2001 15:31:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PMU26C022652
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:30:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PMU1Jl022651
	for mobile-ip-dist; Thu, 25 Oct 2001 15:30:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PMTw6C022644
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:29:58 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11105
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:29:45 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228] (may be forged))
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00935
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 16:40:37 -0600 (MDT)
Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9PMTrj07174
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:29:53 -0700 (PDT)
Message-ID: <01fb01c15da4$d3952070$2b6015ac@DOCOMOKEMPF>
From: "James kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Assumptions about L2 Address Use in Low Latency Draft
Date: Thu, 25 Oct 2001 15:31:44 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01F8_01C15D6A.270E9C30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_01F8_01C15D6A.270E9C30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi folks,

In the process of implementing the low latency draft, a bunch of issues =
around assumptions about how L2 addresses are used came up. The draft =
assumes that the L2 triggers are delivering up "IP Address Identifiers", =
which are either IP addresses or L2 addresss that can be mapped to IP =
addresses  (I actually suggested this wording myself). The question is =
how likely will it be that a given L2 will be able to deliver up IP =
addresses? It seems to me that an L2 is more likely to confine itself to =
delivering up L2 information and let L3 take care of performing the =
mapping. As a consequence, I think it is probably valid to assume that =
most L2s will deliver up L2 addresses if they provide L2 triggers at =
all.

Given that, there are three ways that the low latency draft uses L2 =
addresses:

1) On link. This is used:
  a) in postreg, when the MN shows up at the new FA, the new FA uses the =
L2 address in the L2-LU trigger to determine where to send any incoming =
traffic for the MN.=20
    It matches the L2 address in the HRqst or HRply to the home IP =
address to determine whether it has the MN on the link. The MN uses the =
L2 address of the new FA in a
    similar fashion, namely to send its traffic to the new FA as the =
default router, for forwarding down the tunnel back to the old FA.
  b) in postreg, when the old FA maps the L2 address delivered through =
the L2-ST or in the HRqst(t) to the home address of the MN, so it can =
send an HRqst or HRply to
     the new FA with the MN's home address.
  c) in source triggered prereg, when the old FA maps the MN's L2 =
address delivered through the L2 trigger to the MN's CoA for sending the =

      ProxyRouterAdvert.

2) Resolve cross-link to an IP address for an entity in the wired =
network. This is used:
  a) in target triggered postreg, the new FA must resolve the address in =
the L2-TT trigger to the old FA's IP address in order to send the HRqst. =
Similarly in source triggered postreg.
  b) in source triggered prereg, map the new FA L2 address to IP address =
so it can find the RouterAdvert to send to the MN.
  c) in mobile triggered prereg at the old  FA, map the L2 address of =
the new FA from the ProxyRouterAdvSol to the IP address of the new FA =
for sending the=20
     ProxyRouterAdv back to the MN.

3) Resolve cross-link to an IP address for the MN or on the MN for an =
entity in the wired network. This is used:
  a) target-triggered prereg, the new FA uses the MN's L2 address from =
the target trigger to determine the MN's IP address (I assume the Care =
Of Address)=20
     so it can send the FA Advert directly to the MN.
  b) mobile-triggered prereg, the MN resolves the new FA L2 address to =
the IP address of the new FA to determine where to send the FA Advert =
solicitation.

Of these, only 1) has currently well understood mechanisms for =
performing it. 2) and 3) essentially require cross-link Reverse Address =
Resolution (RARP). There is no general mechanism currently available for =
this function.

For 2), it is possible that static configuration or dynamic =
configuration via a CAR discovery protocol (see =
draft-ietf-seamoby-cardiscovery-issues-01.txt in the Seamoby  working =
group for a discussion of the issues) could  provide the needed address =
mapping. For 3), no such possibility exists because the MN's CoA is =
constantly changing.

The 802.11 InterAccess Point Protocol (IAPP) defines a way to do =
cross-link RARP using SLP. Each access point acts as an SLP SA and UA. =
When a MN reassociates with a new access point, the new access point =
acts as an SLP UA to request resolution of the old access point's =
Ethernet MAC address to an IP address. The old access point acts as an =
SLP SA to reply with the resolution. Since SLP uses multicast, the =
resolution works across subnets (disclaimer: though I am an enthusiastic =
supporter of SLP, I am not sure I agree with this mechanism =
architecturally. However, it does seem to have a fair amount of traction =
in the IEEE IAPP working group).

I think the draft needs to mention these points, at a minimum. I'm also =
wondering how practical the techniques which depend on 3) will be =
without the necessary mechanism, and whether a recommendation is =
required to an IETF working group should be made to start investigating =
mechanism to support 3), perhaps the IAPP mechanism, or maybe look at an =
RARP profile that uses multicast?

Comments?

                    jak



------=_NextPart_000_01F8_01C15D6A.270E9C30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In the process&nbsp;of implementing the =
low latency=20
draft, a bunch of issues around assumptions about </FONT><FONT =
face=3DArial=20
size=3D2>how L2 addresses are used came up. The draft assumes that the =
L2 triggers=20
are delivering up </FONT><FONT face=3DArial size=3D2>"IP Address =
Identifiers", which=20
are either IP addresses or L2 addresss that can be mapped to IP =
addresses=20
&nbsp;(I actually suggested this wording myself). The question&nbsp;is =
how=20
likely will it be that a given L2 will be able to deliver up IP =
addresses? It=20
seems to me that an L2 is more likely to confine itself to delivering up =
L2=20
information and let L3 take care of performing the mapping. As a =
consequence, I=20
think it is probably valid to assume that most L2s will deliver up L2 =
addresses=20
if they provide L2 triggers at all.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Given that, there are three ways that =
the low=20
latency draft uses L2 addresses:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) On link. This is used:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; a)&nbsp;in postreg, when the MN =
shows up at=20
the new FA, the new FA uses the L2 address in the L2-LU trigger to =
determine=20
where to send any incoming traffic for the MN. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; It matches the L2 =
address in the=20
HRqst or HRply to the home IP address to determine whether it has the MN =
on the=20
link. The MN uses the L2 address of the new FA in a</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; similar fashion, =
namely to send=20
its traffic to the new FA as the default router, for forwarding down the =
tunnel=20
back to the old FA.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; b) in postreg, when the old FA =
maps the L2=20
address delivered through the L2-ST or in the HRqst(t) to the home =
address of=20
the MN, so it can send an HRqst or HRply to</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; the new FA =
with the MN's=20
home address.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; c) in source triggered prereg, =
when the old=20
FA maps the MN's L2 address delivered through the L2 trigger to the MN's =
CoA for=20
sending the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ProxyRouterAdvert.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2) Resolve cross-link to an IP address =
for an=20
entity in the wired network. This is used:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; a)&nbsp;in&nbsp;target triggered =

postreg,&nbsp;the new FA must resolve the address in the L2-TT trigger =
to the=20
old FA's IP address in order to send the HRqst. Similarly in source =
triggered=20
postreg.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; b) in source triggered prereg, =
map the new=20
FA L2 address to IP address so it can find the RouterAdvert to send to =
the=20
MN.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; c) in mobile triggered prereg at =
the=20
old&nbsp; FA, </FONT><FONT face=3DArial size=3D2>map the L2 address of =
the new FA=20
from the ProxyRouterAdvSol to the IP address of the new FA for sending =
the=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; ProxyRouterAdv =
back to the=20
MN.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3) Resolve cross-link to an IP address =
for=20
the&nbsp;MN or on the&nbsp;MN for an entity in the wired network. This =
is=20
used:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; a) target-triggered prereg, the =
new FA uses=20
the MN's L2 address from the target trigger to determine the MN's IP =
address (I=20
assume the Care Of Address) </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; so it can send =
the FA=20
Advert directly to the MN.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; b) mobile-triggered prereg, the =
MN resolves=20
the new FA L2 address to&nbsp;the&nbsp;IP address of the new FA to =
determine=20
where to send the FA Advert solicitation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Of these, only 1) has currently well =
understood=20
mechanisms for performing it. 2) and 3) essentially require cross-link =
Reverse=20
Address Resolution (RARP). There is no general mechanism currently =
available for=20
this function.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>For 2), it is possible that static =
configuration or=20
dynamic configuration via a CAR discovery protocol (see=20
draft-ietf-seamoby-cardiscovery-issues-01.txt in the Seamoby&nbsp; =
working group=20
for a discussion of the issues) could&nbsp; provide the needed address =
mapping.=20
For 3), no such possibility exists because the MN's CoA is constantly=20
changing.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The 802.11 InterAccess Point Protocol =
(IAPP)=20
defines a way to do cross-link RARP using SLP. Each access point acts as =
an SLP=20
SA and UA. When a MN reassociates with a new access point, the new =
access point=20
acts as an SLP UA to request resolution of the old access point's =
Ethernet MAC=20
address to an IP address. The old access point acts as an SLP SA to =
reply with=20
the resolution. Since SLP uses multicast, the resolution works across =
subnets=20
(disclaimer: though I am an enthusiastic supporter of SLP, I am not sure =
I agree=20
with this mechanism architecturally. However, it does seem to have a =
fair amount=20
of traction in the IEEE IAPP working group).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I think the draft needs to mention =
these points, at=20
a minimum. I'm also wondering how practical the techniques which depend =
on 3)=20
will be without the necessary mechanism, and whether a recommendation is =

required to an IETF working group should be made to start investigating=20
mechanism to support 3), perhaps the IAPP mechanism, or maybe look at an =
RARP=20
profile that uses multicast?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Comments?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
jak</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_01F8_01C15D6A.270E9C30--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 18:45:56 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01552
	for <mobileip-archive@lists.ietf.org>; Thu, 25 Oct 2001 18:45:56 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13556;
	Thu, 25 Oct 2001 15:45:14 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04040;
	Thu, 25 Oct 2001 15:44:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PMhl6C022785
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:43:47 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PMhlFU022784
	for mobile-ip-dist; Thu, 25 Oct 2001 15:43:47 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PMhh6C022777
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:43:43 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29128
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:43:45 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01060
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 16:43:44 -0600 (MDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PMiHQ05532
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 17:44:17 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d15e9538ac12f255079@davir02nok.americas.nokia.com>;
 Thu, 25 Oct 2001 17:43:44 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 25 Oct 2001 17:43:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: Law of objectivity? Was RE: [mobile-ip] MIPv6 - Focus of the  security discussion
Date: Thu, 25 Oct 2001 17:43:45 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCF4E@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Law of objectivity? Was RE: [mobile-ip] MIPv6 - Focus of the  security discussion
Thread-Index: AcFc4HX1dhmCCMjTEdWryAAIx6S5QwAxcCwg
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "'ext Behcet Sarikaya'" <behcet.sarikaya@alcatel.com>
X-OriginalArrivalTime: 25 Oct 2001 22:43:45.0571 (UTC) FILETIME=[8124C730:01C15DA6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9PMhi6C022778
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Behcet,

Your comments are adding no value to the discussions on this mailing
list.
Please refrain from making comments that appear to be inflamatory. 

-Basavaraj

> From: ext Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> Sent: Wednesday, October 24, 2001 4:59 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: Law of objectivity? Was RE: [mobile-ip] MIPv6 - Focus of
> the security discussion
> 
> 
> Law of objectivity:
> If an I-D is from others then you are very objective about it
> otherwise if the I-D is from your colleague/company then 
> objectivity disappears.
> 
> (the above is a very generic law and applies in other domains 
> such as professors and
> students; parents and children, and so on)
> 
> Cedric Westphal wrote:
> 
> > Michael Thomas wrote:
> >
> >
> >
> > > Koodli Rajeev (NRC/MtView) writes:
> > >  >
> >
> > >  >
> > >  >              Hesham Soliman wrote:
> > >  >
> > >
> 
> > --
> 
> Behcet
> 


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 18:54:35 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01655
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 18:54:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08163;
	Thu, 25 Oct 2001 16:54:03 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06242;
	Thu, 25 Oct 2001 15:53:53 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PMrA6C022922
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:53:10 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9PMr97p022921
	for mobile-ip-dist; Thu, 25 Oct 2001 15:53:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9PMr66C022914
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:53:06 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10217
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 15:53:08 -0700 (PDT)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07486
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 16:53:07 -0600 (MDT)
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA06428;
	Thu, 25 Oct 2001 17:53:07 -0500 (CDT)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9PMr7O15870;
	Thu, 25 Oct 2001 17:53:07 -0500 (CDT)
Message-ID: <3BD89966.90E171D2@alcatel.com>
Date: Thu, 25 Oct 2001 17:59:50 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: Law of objectivity? Was RE: [mobile-ip] MIPv6 - Focus of the  
 security discussion
References: <697DAA22C5004B4596E033803A7CEF444CCF4E@daebe007.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Oops,
apologies.
  I don't know what I did wrong but it is good to apologize.

"Patil Basavaraj (NET/Dallas)" wrote:

> Behcet,
>
> Your comments are adding no value to the discussions on this mailing
> list.
> Please refrain from making comments that appear to be inflamatory.
>
> -Basavaraj
>
> > From: ext Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
> > Sent: Wednesday, October 24, 2001 4:59 PM
> > To: mobile-ip@sunroof.eng.sun.com
> > Subject: Re: Law of objectivity? Was RE: [mobile-ip] MIPv6 - Focus of
> > the security discussion
> >
> >
> > Law of objectivity:
> > If an I-D is from others then you are very objective about it
> > otherwise if the I-D is from your colleague/company then
> > objectivity disappears.
> >
> > (the above is a very generic law and applies in other domains
> > such as professors and
> > students; parents and children, and so on)
> >
> > Cedric Westphal wrote:
> >
> > > Michael Thomas wrote:
> > >
> > >
> > >
> > > > Koodli Rajeev (NRC/MtView) writes:
> > > >  >
> > >
> > > >  >
> > > >  >              Hesham Soliman wrote:
> > > >  >
> > > >
> >
> > > --

>

>

> Behcet



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 20:30:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03199
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 20:30:38 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09562;
	Thu, 25 Oct 2001 18:29:59 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25345;
	Thu, 25 Oct 2001 17:29:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q0SX6C023349
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 17:28:33 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9Q0SXSj023348
	for mobile-ip-dist; Thu, 25 Oct 2001 17:28:33 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q0SQ6C023333;
	Thu, 25 Oct 2001 17:28:26 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29860;
	Thu, 25 Oct 2001 17:28:30 -0700 (PDT)
Received: from mail.itri.org.tw (nti.itri.org.tw [140.96.157.2])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08103;
	Thu, 25 Oct 2001 17:28:26 -0700 (PDT)
Received: from utopia (localhost [127.0.0.1])
	by mail.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id IAA22715;
	Fri, 26 Oct 2001 08:27:07 +0800 (CST)
Message-ID: <008101c15db5$69a688f0$3168608c@utopia>
From: "Shiao-Li Charles Tsao" <sltsao@itri.org.tw>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <ngtrans@sunroof.eng.sun.com>
References: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr>
Subject: Re: [mobile-ip] IPv4 and MIPv6 Transition
Date: Fri, 26 Oct 2001 08:30:24 +0800
Organization: CCL/ITRI
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007E_01C15DF8.7521DA70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_007E_01C15DF8.7521DA70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,=20

This approach was also addressed in "Moving in a Dual Stack Internet" =
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-moving-00.txt>.=20
It is a WG draft in NGTRANS. However, this approach can be only applied =
to a MN with a co-located IPv4 address in the visited IPv4 network. To =
work with NAT and DHCP in the visited IPv4 network, it seems a pratical =
scenario and should be further investigated.=20

Charles Tsao


----- Original Message -----=20
From: "KASSI-LAHLOU Mohammed FTRD/DMI/CAE" =
<mohamed.kassilahlou@rd.francetelecom.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Thursday, October 25, 2001 7:41 PM
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition


Hello,

If the MN and the HA are dual-stack, the solution could be the =
following:
On the home network, the MN receives an Ipv6 RA with the H bit set and =
an
Ipv4 RA with the H bit set.
When the MN arrives on the visited Ipv4 network, it acquires an Ipv4 CoA
(co-located CoA) and tunnels Ipv6 BU in Ipv4 packets to its HA.
The HA intercepts Ipv6 packets intended for the MN and tunnels them to =
the
MN in Ipv4 packets.
The MN tunnels Ipv6 packets intended for the CN in Ipv4 packets to the =
HA.
The HA decapsulates the packets and sends them directly to the CN.

The same solution can be used when the CN is Ipv4 and the visited =
network is
Ipv6.

I do not know any developments about this but it could be a new work =
item.

Kassi

-----Message d'origine-----
De : Eng Soo Guan [mailto:engsg@cwc.nus.edu.sg]
Envoy=E9 : mercredi 24 octobre 2001 11:07
=C0 : mobile-ip@sunroof.eng.sun.com
Objet : Re: [mobile-ip] IPv4 and MIPv6 Transition


Thanx for your reply.

I read the SITT and DSTM draft. My question is that MN is using DSTM. =
But
there are possible cases where MN cannot obtain a "IPv4 Global =
Addresses".
As such, the SITT and DSTM solution is not what I am looking for.

If a MN visits a foreign IPv4 network running NAT and DHCP (and no 6to4,
Tunnel Broker or 6over4 stuff), how can the MN sends a Binding Update to =
its
Home Agent in IPv6? Can the MN uses some configuration information it =
has
when it was previously at home to access the 6Bone?

The best candidate I see it Shipworm. I'm wondering if anyone has come
across other proposals.

SG
Soo Guan, Eng
R&D Engineer (Software Lab)
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
Tel (65) 8709330
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- Original Message -----
From: Hesham Soliman (EPA)
To: 'mobile-ip@sunroof.eng.sun.com'
Sent: Wednesday, October 24, 2001 3:12 PM
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition


Hello Eng,
There is another draft you can find at:
http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00.txt
It's a WG draft in NGTRANS but it expired and I'll
resubmit it after adding some of the comments received.
Cheers,
Hesham


-----Original Message-----
From:   Eng Soo Guan [SMTP:engsg@cwc.nus.edu.sg]
Sent:   Wednesday, 24 October 2001 12:04
To:     mobile-ip@sunroof.eng.sun.com
Subject:        [mobile-ip] IPv4 and MIPv6 Transition
Dear All,
I would like to know if any work has being done with regard to =
'transiting'
to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a =
NAT.
The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected =
Networks
based on Dual-Stack Model".
I read found the NGTRANS Shipworm draft attractive to be modified for =
MIPv6
in a IPv4 only network behind a NAT.
Warmest regards.
SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

------=_NextPart_000_007E_01C15DF8.7521DA70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Courier New">Hello, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New">This approach was also addressed in =
<FONT=20
face=3D"Courier New" size=3D2><STRONG><A name=3DMOVING></A>"Moving in a =
Dual Stack=20
Internet" &lt;<A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-moving-00.=
txt">http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-moving-00.txt=
</A>&gt;.=20
</STRONG></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New">It is a WG draft in NGTRANS. However, =
this=20
approach can be only applied to a MN with a co-located IPv4 address in =
the=20
visited IPv4 network. To work with NAT and DHCP in the visited IPv4 =
network, it=20
seems a pratical scenario and should be further investigated. =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New">Charles Tsao</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New">----- Original Message ----- </FONT>
<DIV><FONT face=3D"Courier New">From: "KASSI-LAHLOU Mohammed =
FTRD/DMI/CAE"=20
&lt;</FONT><A =
href=3D"mailto:mohamed.kassilahlou@rd.francetelecom.com"><FONT=20
face=3D"Courier =
New">mohamed.kassilahlou@rd.francetelecom.com</FONT></A><FONT=20
face=3D"Courier New">&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New">To: &lt;</FONT><A=20
href=3D"mailto:mobile-ip@sunroof.eng.sun.com"><FONT=20
face=3D"Courier New">mobile-ip@sunroof.eng.sun.com</FONT></A><FONT=20
face=3D"Courier New">&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New">Sent: Thursday, October 25, 2001 7:41=20
PM</FONT></DIV>
<DIV><FONT face=3D"Courier New">Subject: RE: [mobile-ip] IPv4 and MIPv6=20
Transition</FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=3D"Courier New">Hello,<BR><BR>If the MN and =
the HA are=20
dual-stack, the solution could be the following:<BR>On the home network, =
the MN=20
receives an Ipv6 RA with the H bit set and an<BR>Ipv4 RA with the H bit=20
set.<BR>When the MN arrives on the visited Ipv4 network, it acquires an =
Ipv4=20
CoA<BR>(co-located CoA) and tunnels Ipv6 BU in Ipv4 packets to its =
HA.<BR>The HA=20
intercepts Ipv6 packets intended for the MN and tunnels them to =
the<BR>MN in=20
Ipv4 packets.<BR>The MN tunnels Ipv6 packets intended for the CN in Ipv4 =
packets=20
to the HA.<BR>The HA decapsulates the packets and sends them directly to =
the=20
CN.<BR><BR>The same solution can be used when the CN is Ipv4 and the =
visited=20
network is<BR>Ipv6.<BR><BR>I do not know any developments about this but =
it=20
could be a new work item.<BR><BR>Kassi<BR><BR>-----Message =
d'origine-----<BR>De=20
: Eng Soo Guan [</FONT><A href=3D"mailto:engsg@cwc.nus.edu.sg"><FONT=20
face=3D"Courier New">mailto:engsg@cwc.nus.edu.sg</FONT></A><FONT=20
face=3D"Courier New">]<BR>Envoy=E9 : mercredi 24 octobre 2001 =
11:07<BR>=C0 : </FONT><A=20
href=3D"mailto:mobile-ip@sunroof.eng.sun.com"><FONT=20
face=3D"Courier New">mobile-ip@sunroof.eng.sun.com</FONT></A><BR><FONT=20
face=3D"Courier New">Objet : Re: [mobile-ip] IPv4 and MIPv6=20
Transition<BR><BR><BR>Thanx for your reply.<BR><BR>I read the SITT and =
DSTM=20
draft. My question is that MN is using DSTM. But<BR>there are possible =
cases=20
where MN cannot obtain a "IPv4 Global Addresses".<BR>As such, the SITT =
and DSTM=20
solution is not what I am looking for.<BR><BR>If a MN visits a foreign =
IPv4=20
network running NAT and DHCP (and no 6to4,<BR>Tunnel Broker or 6over4 =
stuff),=20
how can the MN sends a Binding Update to its<BR>Home Agent in IPv6? Can =
the MN=20
uses some configuration information it has<BR>when it was previously at =
home to=20
access the 6Bone?<BR><BR>The best candidate I see it Shipworm. I'm =
wondering if=20
anyone has come<BR>across other proposals.<BR><BR>SG<BR>Soo Guan, =
Eng<BR>R&amp;D=20
Engineer (Software Lab)<BR>Centre for Wireless Communications, =
NUS<BR></FONT><A=20
href=3D"http://www.cwc.nus.edu.sg"><FONT=20
face=3D"Courier New">http://www.cwc.nus.edu.sg</FONT></A><BR><FONT=20
face=3D"Courier New">Tel (65) =
8709330<BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>-----=20
Original Message -----<BR>From: Hesham Soliman (EPA)<BR>To: </FONT><A=20
href=3D"mailto:'mobile-ip@sunroof.eng.sun.com'"><FONT=20
face=3D"Courier New">'mobile-ip@sunroof.eng.sun.com'</FONT></A><BR><FONT =

face=3D"Courier New">Sent: Wednesday, October 24, 2001 3:12 =
PM<BR>Subject: RE:=20
[mobile-ip] IPv4 and MIPv6 Transition<BR><BR><BR>Hello Eng,<BR>There is =
another=20
draft you can find at:<BR></FONT><A=20
href=3D"http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm=
-00.txt"><FONT=20
face=3D"Courier =
New">http://standards.ericsson.net/hesham/draft-ietf-ngtrans-siit-dstm-00=
.txt</FONT></A><BR><FONT=20
face=3D"Courier New">It's a WG draft in NGTRANS but it expired and=20
I'll<BR>resubmit it after adding some of the comments=20
received.<BR>Cheers,<BR>Hesham<BR><BR><BR>-----Original=20
Message-----<BR>From:&nbsp;&nbsp; Eng Soo Guan [</FONT><A=20
href=3D"mailto:SMTP:engsg@cwc.nus.edu.sg"><FONT=20
face=3D"Courier New">SMTP:engsg@cwc.nus.edu.sg</FONT></A><FONT=20
face=3D"Courier New">]<BR>Sent:&nbsp;&nbsp; Wednesday, 24 October 2001=20
12:04<BR>To:&nbsp;&nbsp;&nbsp;&nbsp; </FONT><A=20
href=3D"mailto:mobile-ip@sunroof.eng.sun.com"><FONT=20
face=3D"Courier New">mobile-ip@sunroof.eng.sun.com</FONT></A><BR><FONT=20
face=3D"Courier New">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[mobile-ip] IPv4 and MIPv6 Transition<BR>Dear All,<BR>I would like to =
know if=20
any work has being done with regard to 'transiting'<BR>to Mobile IPv6 =
with IPv4=20
Internet, especially with Mobile Node behing a NAT.<BR>The closet drafts =
I find=20
are "Mobile IPv4 Traversal Across NAT and VPN<BR>Gateways" and "Mobility =
Support=20
for IPv4 and IPv6 Interconnected Networks<BR>based on Dual-Stack =
Model".<BR>I=20
read found the NGTRANS Shipworm draft attractive to be modified for =
MIPv6<BR>in=20
a IPv4 only network behind a NAT.<BR>Warmest regards.<BR>SG<BR>Soo Guan, =

Eng<BR>Centre for Wireless Communications, NUS<BR></FONT><A=20
href=3D"http://www.cwc.nus.edu.sg"><FONT=20
face=3D"Courier New">http://www.cwc.nus.edu.sg</FONT></A><BR><FONT=20
face=3D"Courier New">~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT></BODY></HTML>

------=_NextPart_000_007E_01C15DF8.7521DA70--



From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 22:26:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05748
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 22:26:28 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA16444;
	Thu, 25 Oct 2001 19:25:41 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20649;
	Thu, 25 Oct 2001 19:25:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q2OZ6C023700
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 19:24:35 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9Q2OYKa023699
	for mobile-ip-dist; Thu, 25 Oct 2001 19:24:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q2OV6C023692
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 19:24:31 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20577
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 19:24:33 -0700 (PDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20291
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 19:24:33 -0700 (PDT)
Received: from blrc.china.bell-labs.com (h135-252-17-219.lucent.com [135.252.17.219])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9Q2OUY16982
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 22:24:30 -0400 (EDT)
Received: from marshall ([135.252.6.53])
	by blrc.china.bell-labs.com (8.9.3+Sun/8.9.1) with SMTP id KAA07756
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 10:19:04 +0800 (CST)
Message-ID: <001f01c15dc5$69d08be0$3506fc87@marshall>
From: "Weishuai Yang" <wsyang@eyou.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr> <013501c15d62$f6fdf060$bec21d8d@icn.siemens.it> <3BD866B9.3DA53695@iprg.nokia.com>
Subject: Re: [mobile-ip] Any news about Fast Handovers for MIPv6 ?
Date: Fri, 26 Oct 2001 10:25:00 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9Q2OV6C023693
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

hi, folks,

I think adding Buffer Management for Fast Handovers is necessery, and I'm 
doing it right now. How do you think about it?

Weishuai Yang



----- Original Message ----- 
From: "Vijay Devarapalli" <vijayd@iprg.nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Friday, October 26, 2001 3:23 AM
Subject: Re: [mobile-ip] Any news about Fast Handovers for MIPv6 ?


> We have an implementation of the 02 draft. Rajeev Koodli did a 
> presentation at the London IETF on a few issues that we encountered
> while implementing it.
> 
> and take a look at the following journal paper. "Fast Handovers and
> Context Transfer in Mobile Networks" to appear in  ACM Computer 
> Communication Review (october 2001 issue). It has some performance
> results from the Fast Handoff tests we did on our testbed.
> 
> and the results look very promising. Fast Handoffs (02 draft) does
> not need any additional improvements/enhancements (IMHO). 
> 
> Vijay
> 
> > emanuel monticelli wrote:
> > 
> > Hi,
> > 
> > Any news about Fast Handovers for MIPv6 other than the 02 draft ?
> > Do you know anyone that is trying to implement something in this area
> > ?
> > 
> > Thanks
> > 
> > Emanuel Monticelli


From owner-mobile-ip@sunroof.eng.sun.com  Thu Oct 25 23:26:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07282
	for <mobileip-archive@odin.ietf.org>; Thu, 25 Oct 2001 23:26:37 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA04470;
	Thu, 25 Oct 2001 20:26:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28214;
	Thu, 25 Oct 2001 20:26:17 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q3PM6C023915
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 20:25:22 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9Q3PMno023914
	for mobile-ip-dist; Thu, 25 Oct 2001 20:25:22 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q3PI6C023907
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 20:25:18 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28065
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 20:25:21 -0700 (PDT)
From: Yanqun.Le@nokia.com
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00613
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 20:25:20 -0700 (PDT)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9Q3PuA17861
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 06:25:56 +0300 (EET DST)
Received: from esebh11nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d417cf44ac158f231f3@esvir03nok.nokia.com>;
 Fri, 26 Oct 2001 06:25:17 +0300
Received: by esebh11nok with Internet Mail Service (5.5.2652.78)
	id <VLFJJSRJ>; Fri, 26 Oct 2001 06:25:19 +0300
Message-ID: <4AE1AC3D692F55488F2D03518907B8AD08533A@beebe001.NOE.Nokia.com>
To: MAkram@megisto.com
Cc: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] problem about deregistration of MIP
Date: Fri, 26 Oct 2001 06:25:04 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="gb2312"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Thank you very much.

I have another question:
If the home address is allocated dynamilcally, that is to say, in
Registration Request, the home address is zero, and the allocated home
address is returned by Registration Reply.
Then if the MN deregistrater, must it fill the home address with
allocated home address?

Best regards
Le Yanqun


-----Original Message-----
From: ext Mohammad Akram [mailto:MAkram@MEGISTO.com]
Sent: Thursday, October 25, 2001 9:47 PM
To: Le Yanqun (Nokia-RD/Beijing)
Subject: RE: [mobile-ip] problem about deregistration of MIP


Hi Le,

Comments inline.

-----Original Message-----
From: Yanqun.Le@nokia.com [mailto:Yanqun.Le@nokia.com]
Sent: Thursday, October 25, 2001 6:04 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] problem about deregistration of MIP


hi,

When a mobile node send Registration Request to a Mobile IP Agent, how
can the Agent decide whether the mobile node doing deregistration? By
which criterion below?

There are two cases to consider here:
Case 1: HA supports Simultaneous Bindings.
Case 2: HA DOES NOT supports Simultaneous Bindings.

Condition 1) care-of-address equal to its home address, 
Condition 2) registration lifetime equal to 0;

If both Condition1 & 2 are true then for both Case1 & 2 this means 
MN is at the Home network and wants to de-register.
HA removes ALL the mobility binding(s) associated to this MN.

If only condition 2 is true then -
In Case 1: HA removes ONLY the mobility binding associated to the CoA
address
		specified in the Registration Request. HA could have
other
active 
		mobility bindings for the MN ,with other CoA.
In Case 2: HA removes the single mobility binding permited. 
           But MN is not on the Home network.

Note: Condition 1 is true only when condition 2 is also true but not
vice
versa.



3) if NAI exists in Registration Request ,the realm part of NAI is the
same to the realm the Agent belongs to.

I am sorry, I don't know about the NAI.

Can every one be used to decide deregistration or the combination of
those?

Thanks 
Le Yanqun
 

Hope this helps.

Mohammad.


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 01:21:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09589
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 01:21:32 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19626;
	Thu, 25 Oct 2001 23:21:18 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17517;
	Thu, 25 Oct 2001 22:20:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q5K26C024138
	for <mobile-ip-dist@sunroof.eng.sun.com>; Thu, 25 Oct 2001 22:20:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9Q5K2bf024137
	for mobile-ip-dist; Thu, 25 Oct 2001 22:20:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q5Jx6C024130
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 22:19:59 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10259
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 22:20:01 -0700 (PDT)
Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19074
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 23:20:00 -0600 (MDT)
Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34])
	by ws130.nomadiclab.com (Postfix) with ESMTP
	id D29B674403; Fri, 26 Oct 2001 08:21:10 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by ws34.nomadiclab.com (Postfix) with ESMTP
	id CAF59BA21; Fri, 26 Oct 2001 08:19:56 +0300 (EEST)
Message-ID: <3BD8F16B.5040500@nomadiclab.com>
Date: Fri, 26 Oct 2001 08:15:23 +0300
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011
X-Accept-Language: en-us
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
Cc: James Kempf <kempf42@yahoo.com>, Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: [mobile-ip] DoS against DAD (was Re: Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-...)
References: <Roam.SIMC.2.0.6.1003779107.21247.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Erik Nordmark wrote:

> If a device uses RFC 2461 Duplicate Address Detection there is nothing
> to prevent another device on the same multi-access link from responding
> to each DAD probe. Hence the first device would not be able to allocate
> any IPv6 link-local address. Without this it can't do anything. For instance,
> it can't even talk to a DHCP server.


FYI:  Last spring when I considered the address ownership problem,
I also had some ideas how one maybe could fix this with a relatively
cheap S/Key like reveal-hashes-in-reverse order kind of construct.

See Sections 3.1.2 and 3.1.3 of
http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt

--Pekka Nikander



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 11:37:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07417
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 11:37:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12001;
	Fri, 26 Oct 2001 08:35:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15093;
	Fri, 26 Oct 2001 08:34:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QFXc6C024974
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 08:33:38 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QFXbFo024973
	for mobile-ip-dist; Fri, 26 Oct 2001 08:33:37 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QFXZ6C024966
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 08:33:36 -0700 (PDT)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03175
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 11:33:37 -0400 (EDT)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA16170
	for mobile-ip@sunroof.eng.sun.com; Fri, 26 Oct 2001 11:34:07 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q3FH6C023850
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 20:15:17 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23827
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 20:15:20 -0700 (PDT)
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02620
	for <mobile-ip@sunroof.eng.sun.com>; Thu, 25 Oct 2001 21:15:17 -0600 (MDT)
Received: from sooguan ([172.16.3.160])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id LAA16206
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 11:14:10 +0800 (SGT)
Message-ID: <00aa01c15dcd$290421a0$a00310ac@cwc.nus.edu.sg>
From: "Eng Soo Guan" <engsg@cwc.nus.edu.sg>
To: <mobile-ip@sunroof.eng.sun.com>
References: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr> <008101c15db5$69a688f0$3168608c@utopia>
Subject: Re: [mobile-ip] IPv4 and MIPv6 Transition
Date: Fri, 26 Oct 2001 11:20:27 +0800
Organization: CWC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Dear All,

When I used GPRS, I discovered that the network assigns a private IP, and
uses NAT to route the packet to my Home Network. I have not tested with IPv6
yet, and am looking around for a possible solution. As Charles pointed out,
the draft "Moving in a Dual Stack Internet" is unsuitable for NAT & DHCP.

Warmest regards.

SG
Eng Soo Guan
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
----- Original Message -----
From: Shiao-Li Charles Tsao
To: mobile-ip@sunroof.eng.sun.com
Cc: ngtrans@sunroof.eng.sun.com
Sent: Friday, October 26, 2001 8:30 AM
Subject: Re: [mobile-ip] IPv4 and MIPv6 Transition


Hello,

This approach was also addressed in "Moving in a Dual Stack Internet"
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-moving-00.txt>.
It is a WG draft in NGTRANS. However, this approach can be only applied to a
MN with a co-located IPv4 address in the visited IPv4 network. To work with
NAT and DHCP in the visited IPv4 network, it seems a pratical scenario and
should be further investigated.

Charles Tsao


----- Original Message -----
From: "KASSI-LAHLOU Mohammed FTRD/DMI/CAE"
<mohamed.kassilahlou@rd.francetelecom.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Thursday, October 25, 2001 7:41 PM
Subject: RE: [mobile-ip] IPv4 and MIPv6 Transition


Hello,

If the MN and the HA are dual-stack, the solution could be the following:
On the home network, the MN receives an Ipv6 RA with the H bit set and an
Ipv4 RA with the H bit set.
When the MN arrives on the visited Ipv4 network, it acquires an Ipv4 CoA
(co-located CoA) and tunnels Ipv6 BU in Ipv4 packets to its HA.
The HA intercepts Ipv6 packets intended for the MN and tunnels them to the
MN in Ipv4 packets.
The MN tunnels Ipv6 packets intended for the CN in Ipv4 packets to the HA.
The HA decapsulates the packets and sends them directly to the CN.

The same solution can be used when the CN is Ipv4 and the visited network is
Ipv6.

I do not know any developments about this but it could be a new work item.

Kassi



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 11:48:15 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07851
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 11:48:15 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20289;
	Fri, 26 Oct 2001 08:48:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17189;
	Fri, 26 Oct 2001 08:41:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QFf26C025094
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 08:41:02 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QFf1Vf025093
	for mobile-ip-dist; Fri, 26 Oct 2001 08:41:01 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QFew6C025083
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 08:40:58 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10347
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 08:41:00 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228] (may be forged))
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19451
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:54:25 -0600 (MDT)
Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9QFesj10802
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 08:40:54 -0700 (PDT)
Message-ID: <002e01c15e34$dcf94ac0$2b6015ac@DOCOMOKEMPF>
From: "James kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr> <013501c15d62$f6fdf060$bec21d8d@icn.siemens.it> <3BD866B9.3DA53695@iprg.nokia.com> <001f01c15dc5$69d08be0$3506fc87@marshall>
Subject: Re: [mobile-ip] Any news about Fast Handovers for MIPv6 ?
Date: Fri, 26 Oct 2001 08:42:48 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

>
> I think adding Buffer Management for Fast Handovers is necessery, and I'm
> doing it right now. How do you think about it?
>

It depends on what algorithm you are using. You could also use bicasting for
smoothing. For FMIPv6, smoothing is probably needed in any case. For BETH,
it may or may not be needed,  depending on how much handover sequencing
information you have and how high the L2 latency is. If the L2 latency is
less than the packet interarrival time, there should be no need for
smoothing with BETH if you can time tunnel establishment to start
as soon as the L2 handover occurs.

        jak



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 12:06:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08585
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 12:06:04 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01844;
	Fri, 26 Oct 2001 10:06:02 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23993;
	Fri, 26 Oct 2001 09:05:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QG4r6C025238
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:04:53 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QG4rLS025237
	for mobile-ip-dist; Fri, 26 Oct 2001 09:04:53 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QG4n6C025230
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:04:49 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26663
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:04:41 -0700 (PDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00770
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 10:04:50 -0600 (MDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA25467 for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 08:55:55 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA12941 for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:04:45 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52)
	id <VRW8A5FG>; Fri, 26 Oct 2001 11:04:45 -0500
Message-ID: <A5B4C9A2AD89D411AB3E009027B0DA1E0396C1B0@IL27EXM09.cig.mot.com>
From: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Assumptions about L2 Address Use in Low Latency D
	raft
Date: Fri, 26 Oct 2001 11:04:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15E37.EDCCAAB0"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15E37.EDCCAAB0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello James:
 
I have some minor comment regarding the use of L2 identifier in link layer 
trigger:
 
a.MN identifier: I agree MN identifier must be the L2 identifier of mobile node. 
b.FA identifier : IMHO, we should not limit this identifier to the L2 address of the foreign agent.
Sometime it is much easier to provide IP address of the peer foreign agent. 
 
regards,
ajoy 
 

-----Original Message-----
From: James kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, October 25, 2001 5:32 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Assumptions about L2 Address Use in Low Latency Draft


Hi folks,
 
In the process of implementing the low latency draft, a bunch of issues around assumptions about how L2 addresses are used came up. The draft assumes that the L2 triggers are delivering up "IP Address Identifiers", which are either IP addresses or L2 addresss that can be mapped to IP addresses  (I actually suggested this wording myself). The question is how likely will it be that a given L2 will be able to deliver up IP addresses? It seems to me that an L2 is more likely to confine itself to delivering up L2 information and let L3 take care of performing the mapping. As a consequence, I think it is probably valid to assume that most L2s will deliver up L2 addresses if they provide L2 triggers at all.
 
Given that, there are three ways that the low latency draft uses L2 addresses:
 
1) On link. This is used:
  a) in postreg, when the MN shows up at the new FA, the new FA uses the L2 address in the L2-LU trigger to determine where to send any incoming traffic for the MN. 
    It matches the L2 address in the HRqst or HRply to the home IP address to determine whether it has the MN on the link. The MN uses the L2 address of the new FA in a
    similar fashion, namely to send its traffic to the new FA as the default router, for forwarding down the tunnel back to the old FA.
  b) in postreg, when the old FA maps the L2 address delivered through the L2-ST or in the HRqst(t) to the home address of the MN, so it can send an HRqst or HRply to
     the new FA with the MN's home address.
  c) in source triggered prereg, when the old FA maps the MN's L2 address delivered through the L2 trigger to the MN's CoA for sending the 
      ProxyRouterAdvert.
 
2) Resolve cross-link to an IP address for an entity in the wired network. This is used:
  a) in target triggered postreg, the new FA must resolve the address in the L2-TT trigger to the old FA's IP address in order to send the HRqst. Similarly in source triggered postreg.
  b) in source triggered prereg, map the new FA L2 address to IP address so it can find the RouterAdvert to send to the MN.
  c) in mobile triggered prereg at the old  FA, map the L2 address of the new FA from the ProxyRouterAdvSol to the IP address of the new FA for sending the 
     ProxyRouterAdv back to the MN.
 
3) Resolve cross-link to an IP address for the MN or on the MN for an entity in the wired network. This is used:
  a) target-triggered prereg, the new FA uses the MN's L2 address from the target trigger to determine the MN's IP address (I assume the Care Of Address) 
     so it can send the FA Advert directly to the MN.
  b) mobile-triggered prereg, the MN resolves the new FA L2 address to the IP address of the new FA to determine where to send the FA Advert solicitation.
 
Of these, only 1) has currently well understood mechanisms for performing it. 2) and 3) essentially require cross-link Reverse Address Resolution (RARP). There is no general mechanism currently available for this function.
 
For 2), it is possible that static configuration or dynamic configuration via a CAR discovery protocol (see draft-ietf-seamoby-cardiscovery-issues-01.txt in the Seamoby  working group for a discussion of the issues) could  provide the needed address mapping. For 3), no such possibility exists because the MN's CoA is constantly changing.
 
The 802.11 InterAccess Point Protocol (IAPP) defines a way to do cross-link RARP using SLP. Each access point acts as an SLP SA and UA. When a MN reassociates with a new access point, the new access point acts as an SLP UA to request resolution of the old access point's Ethernet MAC address to an IP address. The old access point acts as an SLP SA to reply with the resolution. Since SLP uses multicast, the resolution works across subnets (disclaimer: though I am an enthusiastic supporter of SLP, I am not sure I agree with this mechanism architecturally. However, it does seem to have a fair amount of traction in the IEEE IAPP working group).
 
I think the draft needs to mention these points, at a minimum. I'm also wondering how practical the techniques which depend on 3) will be without the necessary mechanism, and whether a recommendation is required to an IETF working group should be made to start investigating mechanism to support 3), perhaps the IAPP mechanism, or maybe look at an RARP profile that uses multicast?
 
Comments?
 
                    jak
 
 


------_=_NextPart_001_01C15E37.EDCCAAB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4613.1700" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=446274215-26102001><FONT face=Arial color=#0000ff size=2>Hello 
James:</FONT></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2>I have some minor comment&nbsp;regarding the use 
of L2 identifier in link layer </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2>trigger:</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2>a.MN identifier: I agree MN identifier must be 
the L2 identifier of mobile node.&nbsp;</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2>b.FA identifier :&nbsp;IMHO, we should 
not&nbsp;limit this identifier to the L2 address of the foreign 
agent.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2>Sometime it is much easier to provide IP address 
of the&nbsp;peer foreign agent. </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2>regards,</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2>ajoy </FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=446274215-26102001><SPAN class=381533215-26102001><FONT 
face=Arial color=#0000ff size=2></FONT></SPAN></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> James kempf 
  [mailto:kempf@docomolabs-usa.com]<BR><B>Sent:</B> Thursday, October 25, 2001 
  5:32 PM<BR><B>To:</B> mobile-ip@sunroof.eng.sun.com<BR><B>Subject:</B> 
  [mobile-ip] Assumptions about L2 Address Use in Low Latency 
  Draft<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2>Hi folks,</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>In the process&nbsp;of implementing the low 
  latency draft, a bunch of issues around assumptions about </FONT><FONT 
  face=Arial size=2>how L2 addresses are used came up. The draft assumes that 
  the L2 triggers are delivering up </FONT><FONT face=Arial size=2>"IP Address 
  Identifiers", which are either IP addresses or L2 addresss that can be mapped 
  to IP addresses &nbsp;(I actually suggested this wording myself). The 
  question&nbsp;is how likely will it be that a given L2 will be able to deliver 
  up IP addresses? It seems to me that an L2 is more likely to confine itself to 
  delivering up L2 information and let L3 take care of performing the mapping. 
  As a consequence, I think it is probably valid to assume that most L2s will 
  deliver up L2 addresses if they provide L2 triggers at all.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Given that, there are three ways that the low 
  latency draft uses L2 addresses:</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>1) On link. This is used:</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; a)&nbsp;in postreg, when the MN shows up 
  at the new FA, the new FA uses the L2 address in the L2-LU trigger to 
  determine where to send any incoming traffic for the MN. </FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; It matches the L2 address in 
  the HRqst or HRply to the home IP address to determine whether it has the MN 
  on the link. The MN uses the L2 address of the new FA in a</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; similar fashion, namely to 
  send its traffic to the new FA as the default router, for forwarding down the 
  tunnel back to the old FA.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; b) in postreg, when the old FA maps the L2 
  address delivered through the L2-ST or in the HRqst(t) to the home address of 
  the MN, so it can send an HRqst or HRply to</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; the new FA with the MN's 
  home address.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; c) in source triggered prereg, when the 
  old FA maps the MN's L2 address delivered through the L2 trigger to the MN's 
  CoA for sending the </FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  ProxyRouterAdvert.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>2) Resolve cross-link to an IP address for an 
  entity in the wired network. This is used:</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; a)&nbsp;in&nbsp;target triggered 
  postreg,&nbsp;the new FA must resolve the address in the L2-TT trigger to the 
  old FA's IP address in order to send the HRqst. Similarly in source triggered 
  postreg.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; b) in source triggered prereg, map the new 
  FA L2 address to IP address so it can find the RouterAdvert to send to the 
  MN.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; c) in mobile triggered prereg at the 
  old&nbsp; FA, </FONT><FONT face=Arial size=2>map the L2 address of the new FA 
  from the ProxyRouterAdvSol to the IP address of the new FA for sending the 
  </FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; ProxyRouterAdv back to 
  the MN.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>3) Resolve cross-link to an IP address for 
  the&nbsp;MN or on the&nbsp;MN for an entity in the wired network. This is 
  used:</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; a) target-triggered prereg, the new FA 
  uses the MN's L2 address from the target trigger to determine the MN's IP 
  address (I assume the Care Of Address) </FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp;&nbsp; so it can send the FA 
  Advert directly to the MN.</FONT></DIV>
  <DIV><FONT face=Arial size=2>&nbsp; b) mobile-triggered prereg, the MN 
  resolves the new FA L2 address to&nbsp;the&nbsp;IP address of the new FA to 
  determine where to send the FA Advert solicitation.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Of these, only 1) has currently well understood 
  mechanisms for performing it. 2) and 3) essentially require cross-link Reverse 
  Address Resolution (RARP). There is no general mechanism currently available 
  for this function.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>For 2), it is possible that static configuration 
  or dynamic configuration via a CAR discovery protocol (see 
  draft-ietf-seamoby-cardiscovery-issues-01.txt in the Seamoby&nbsp; working 
  group for a discussion of the issues) could&nbsp; provide the needed address 
  mapping. For 3), no such possibility exists because the MN's CoA is constantly 
  changing.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>The 802.11 InterAccess Point Protocol (IAPP) 
  defines a way to do cross-link RARP using SLP. Each access point acts as an 
  SLP SA and UA. When a MN reassociates with a new access point, the new access 
  point acts as an SLP UA to request resolution of the old access point's 
  Ethernet MAC address to an IP address. The old access point acts as an SLP SA 
  to reply with the resolution. Since SLP uses multicast, the resolution works 
  across subnets (disclaimer: though I am an enthusiastic supporter of SLP, I am 
  not sure I agree with this mechanism architecturally. However, it does seem to 
  have a fair amount of traction in the IEEE IAPP working group).</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I think the draft needs to mention these points, 
  at a minimum. I'm also wondering how practical the techniques which depend on 
  3) will be without the necessary mechanism, and whether a recommendation is 
  required to an IETF working group should be made to start investigating 
  mechanism to support 3), perhaps the IAPP mechanism, or maybe look at an RARP 
  profile that uses multicast?</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Comments?</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; jak</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15E37.EDCCAAB0--


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 12:20:41 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09146
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 12:20:41 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10222;
	Fri, 26 Oct 2001 09:19:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27204;
	Fri, 26 Oct 2001 09:19:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGIa6C025357
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:18:36 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QGIaH0025356
	for mobile-ip-dist; Fri, 26 Oct 2001 09:18:36 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGIX6C025349
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:18:33 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29357
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:18:25 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228] (may be forged))
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10823
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:18:35 -0700 (PDT)
Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9QGIZj12538
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:18:35 -0700 (PDT)
Message-ID: <00a001c15e3a$208ed430$2b6015ac@DOCOMOKEMPF>
From: "James kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <A5B4C9A2AD89D411AB3E009027B0DA1E0396C1B0@IL27EXM09.cig.mot.com>
Subject: Re: [mobile-ip] Assumptions about L2 Address Use in Low Latency Draft
Date: Fri, 26 Oct 2001 09:20:29 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009D_01C15DFF.742B6850"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_009D_01C15DFF.742B6850
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ajoy,

  a.MN identifier: I agree MN identifier must be the L2 identifier of =
mobile node.=20
  b.FA identifier : IMHO, we should not limit this identifier to the L2 =
address of the foreign agent.
  Sometime it is much easier to provide IP address of the peer foreign =
agent.=20

Sure, I wasn't trying to imply that it was not possible. Its just in =
most cases, I think L2 will
be more likely to return L2 information. I think we need to understand =
how to handle
those cases, even if they turn out not to be common.

In addition, the FA address isn't the critical one anyway. It should be =
fairly straightforward
to supply by static configuration or a dynamic configuration with a =
protocol like CAR discovery
even if it is not available from the L2 trigger.. The critical case is =
where cross link RARP is needed for=20
resolving the MN's L2 address to an L3 address. This was case 3) in the =
original note. There are two specific instances
where the draft depends on this functionality, and the only solution =
currently that I'm
aware of is using SLP like IAPP does.

            jak

------=_NextPart_000_009D_01C15DFF.742B6850
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Ajoy,</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
  face=3DArial color=3D#0000ff size=3D2>a.MN identifier: I agree MN =
identifier must be=20
  the L2 identifier of mobile node.&nbsp;</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
  face=3DArial color=3D#0000ff size=3D2>b.FA identifier :&nbsp;IMHO, we =
should=20
  not&nbsp;limit this identifier to the L2 address of the foreign=20
  agent.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
  face=3DArial color=3D#0000ff size=3D2>Sometime it is much easier to =
provide IP=20
  address of the&nbsp;peer foreign agent. </FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>Sure, I wasn't trying to imply =
that it was not=20
possible. Its just in most cases, I think L2 =
will</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>be more likely to return L2 =
information. I think=20
we need to understand how to handle</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>those cases, even if they turn out =
not to be=20
common.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>In addition, the FA address isn't =
the critical=20
one anyway. It should be fairly =
straightforward</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>to supply by static configuration =
or a dynamic=20
configuration with a protocol like CAR =
discovery</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>even if it is not available from =
the L2=20
trigger.. </FONT></SPAN></SPAN><SPAN class=3D446274215-26102001><SPAN=20
class=3D381533215-26102001><FONT face=3DArial color=3D#0000ff =
size=3D2>The critical case=20
is where cross link RARP is needed for </FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>resolving the MN's L2 address=20
</FONT></SPAN></SPAN><SPAN class=3D446274215-26102001><SPAN=20
class=3D381533215-26102001><FONT face=3DArial color=3D#0000ff =
size=3D2>to an L3 address.=20
This was case 3) in the original note. There are two specific=20
instances</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>where the draft depends on this =
functionality,=20
and the only solution currently that I'm</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2>aware of is using SLP like IAPP=20
does.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D446274215-26102001><SPAN =
class=3D381533215-26102001><FONT=20
face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
jak</FONT></SPAN></SPAN></DIV></BODY></HTML>

------=_NextPart_000_009D_01C15DFF.742B6850--



From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 12:45:32 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10246
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 12:45:31 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12349;
	Fri, 26 Oct 2001 10:45:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03656;
	Fri, 26 Oct 2001 09:45:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGiQ6C025500
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:44:26 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QGiQdD025499
	for mobile-ip-dist; Fri, 26 Oct 2001 09:44:26 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGiM6C025492
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:44:22 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03453
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:44:25 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25872
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:44:20 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA09203;
	Fri, 26 Oct 2001 09:44:19 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9QGiIw19721;
	Fri, 26 Oct 2001 09:44:18 -0700
X-mProtect:  Fri, 26 Oct 2001 09:44:18 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd9iXMh6; Fri, 26 Oct 2001 09:43:35 PDT
Message-ID: <3BD992B8.FDAEB04C@iprg.nokia.com>
Date: Fri, 26 Oct 2001 09:43:36 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: wsyang@eyou.com
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Any news about Fast Handovers for MIPv6 ?
References: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr> <013501c15d62$f6fdf060$bec21d8d@icn.siemens.it> <3BD866B9.3DA53695@iprg.nokia.com> <001f01c15dc5$69d08be0$3506fc87@marshall>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello,

We have implemented buffer management for fast handovers, and it
does work very well.

For some background, take a look at:

@INPROCEEDINGS{caceres-padman, 
        author = "Ramon Caceres and Venkata Padmanabhan",
        title = "{Fast and {S}calable {H}andoffs for {W}ireless
                 {I}nternetworks}",
        booktitle = "ACM Mobicom 96",
        month = nov,
        pages = {56-66},
        year = 1996,
}

and

@INPROCEEDINGS{perkins-wang,  
        author = "Charles E. Perkins and Kuang-Yeh Wang",
        title = {Optimized {S}mooth {H}andoffs in {M}obile {IP}},
        booktitle = "Proceedings of the Fourth IEEE Symposium on
                Computers & Communications (ISCC'99)",
        month = jul,
        pages = {340-346},
        year = 1999,
}

A version of the latter is available at:
	http://people.nokia.net/~charliep/iscc99/iscc99.ps

I hope you find these useful.

Regards,
Charlie P.





Weishuai Yang wrote:
> 
> hi, folks,
> 
> I think adding Buffer Management for Fast Handovers is necessery, and I'm
> doing it right now. How do you think about it?
> 
> Weishuai Yang


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 12:58:01 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10931
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 12:58:00 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03850;
	Fri, 26 Oct 2001 09:57:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05791;
	Fri, 26 Oct 2001 09:54:05 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGrH6C025636
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:53:17 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QGrHTZ025635
	for mobile-ip-dist; Fri, 26 Oct 2001 09:53:17 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGrD6C025628
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:53:13 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05583
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:53:16 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01200
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 09:53:16 -0700 (PDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9QGrJQ24206
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 11:53:19 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d5441101ac12f256126@davir03nok.americas.nokia.com>;
 Fri, 26 Oct 2001 11:53:15 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 26 Oct 2001 11:53:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: [mobile-ip] RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Date: Fri, 26 Oct 2001 11:53:16 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCF62@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Thread-Index: AcFdt/eZh7w07smoEdWBTgBQi2X+DwAhjuDQ
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'ext Pat Calhoun'" <pcalhoun@diameter.org>, <aaa-wg@merit.edu>
Cc: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 26 Oct 2001 16:53:15.0461 (UTC) FILETIME=[B4A26750:01C15E3E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9QGrD6C025629
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Pat,

The GNAIE I-D is in the process of being deprecated as a WG document.
So refering to the GNAIE as a way to fix it may not be the solution. As
I
have pointed out to you and the other authors of the GNAIE I-D, the I-D
that needs a specific NAI extension ought to define it rather than
having a
placeholder for extensions I-D which is reference by others.
The FA-NAI specified in GNAIE should (or can) be specified in the
reg-tun
I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
I-D. So far the HA-NAI has not been really shown as a requirement by any
other I-Ds in the Mobile IP WG.

-Basavaraj

> 
> 
> Submitter name: Pat Calhoun
> Submitter email address: pcalhoun@diameter.org 
> Date first submitted: 25-Oct-01 
> Reference:  
> Document: MIP
> Comment type: Technical 
> Priority: 1
> Section: 
> Rationale/Explanation of issue: 
> 
> Once a mobile has been assigned a home agent, if a subsequent 
> HAR is to
> be sent, a new AAAH has no way to map the IP address in the 
> registration
> request to a Destination-Host AVP of the Home Agent.
> 
> Fix
> 
> The GNAIE ID is being updated to reflect comments of the IESG. In this
> document we will specify that the HA may include its NAI in the 
> Registration Reply, and if so, the mobile node must include 
> the same extension
> in subsequent registration requests. This will require some 
> Mobile IP WG
> involvement.
> 


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 17:19:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19280
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 17:19:46 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02674;
	Fri, 26 Oct 2001 15:19:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28529;
	Fri, 26 Oct 2001 14:19:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QLIY6C026152
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 14:18:34 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QLIYmW026151
	for mobile-ip-dist; Fri, 26 Oct 2001 14:18:34 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QLIV6C026144
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 14:18:31 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03674
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 14:18:34 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01868
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 15:18:33 -0600 (MDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9QLIbQ25925
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:18:37 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56d636f55eac12f256126@davir03nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Fri, 26 Oct 2001 16:18:33 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 26 Oct 2001 16:18:33 -0500
content-class: urn:content-classes:message
Subject: RE: [mobile-ip] Improving BETH: chain tunneling
Date: Fri, 26 Oct 2001 16:18:25 -0500
Message-ID: <748E8123D183394982E32A511DB3E73610B07D@daebe005.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: [mobile-ip] Improving BETH: chain tunneling
Thread-Index: AcFTcGiKscviYb9hEdWxLwAIx6TWeAK6O3Qw
From: "Purnadi Rene (NRC/Dallas)" <rene.purnadi@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 26 Oct 2001 21:18:33.0221 (UTC) FILETIME=[C45BD350:01C15E63]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9QLIV6C026145
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hi James,

Thanks for your comment on our proposal. My comments are embedded. Sorry
for the late reply since I was travelling and then I was swamped with
other things


Rene Purnadi
Phone: +1 972.894.4897
e-mail: rene.purnadi@nokia.com


-----Original Message-----
From: ext James Kempf [mailto:James.Kempf@sun.com]
Sent: Friday, October 12, 2001 5:49 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: kempf42@yahoo.com
Subject: Re: [mobile-ip] Improving BETH: chain tunneling


Purnadi,

Comments embedded.

>Current BETH:
> 
>According to draft-kempf-beth-ipv6-02.txt, in the model for the
"handoff
>to third" a new BET tunnel is established from the anchor AR (aAR) to
>the new AR (nAR). Since the MN may maintain the BET tunnels for a
while,
>there may be some issues related to QoS. In fact, in order to guarantee
>that the BET tunnel supports the QoS needed by the MN, we need to
either
>assume that an SLA is in place between the oAR and nAR or that
>"pre-defined" QoS is allocated between the oAR and the nAR. However,
>since it is not possible to foresee a-priori where the MN is going to
>handoff to and since the BET tunnels will be established not only
>between "adjacent" routers but also between non-adjacent routers (HTT
>case), the adoption of SLAs or pre-defined QoS in order to guarantee
the
>QoS for the MN over the tunnel does not scale well. 

Can you explain why this is any different than standard MIPv6?

Rene>> The MIPv6 does not have the QoS establishment procedure, and the
QoS negotiation happens separately. For a new route or tunnel
establishment, you need to ensure the QoS consistency. This means
additional QoS signaling and the delay associated with signaling and
establishment. This may not be suitable for time critical handoff
procedure. I hope I have answered based upon the correct understanding
of your question.

>As an alternative,
>at the BET establishment a QoS negotiation can take place to ensure the
>QoS for the tunnel will be supported. However, such QoS negotiation may
>in some situations introduce some latency.
>
>		       new tunnel
>       || ==============================================||
>       ||                                               ||
>  +-------+                  +-------+               +-------+
>  |       |    old tunnel    |       |               |       |
>  |  aAR  | ================ | oAR   |               |  nAR  |
>  |       |                  |       |               |       |
>  +-------+                  +-------+               +-------+
>
>            Original BETH procedure
>
>  +-------+                  +-------+                +-------+
>  |       |    old tunnel    |       |  new tunnel    |       |
>  | aAR   | ================ | oAR   | ===============|  nAR  |
>  |       |                  |       |                |       |
>  +-------+                  +-------+                +-------+
>
>            Proposed Beth enhancement
>
>Proposed enhancement:
> 
>We propose that the BETH model should accommodate the option of "chain
>tunneling" where, in case of handoff to third, the oAR creates a new
>tunnel to the nAR. The procedure to establish the new BET tunnel from
>oAR to the nAR is  the same as the procedure to establish the initial
>tunnel from the aAR to the oAR. 
>

The difficulty with this proposal is that it introduces the possibility
of routing loops if the MN moves back to aAR. Can you explain how you
would 
avoid that, short of forcing the MN to always establish
a nCoA on nAR?

Rene>> There will not be any routing loops.  One way to do this is, the
aAR can determine that the MN has still CoA from aAR (IP Address Option
containing MN's old Care of Address) and it has established a tunnel to
oAR. It either responds normally to the HRqst with HRply to nAR, but
soon after L2-UP happens at the aAR, it tears down both tunnels to oAR
and nAR/aAR, or it won't create the second tunnel to the oAR and soon
after L2-UP happens at the aAR, it tears down the tunnel to oAR.  There
is no need for tunnel and for nCoA. However, if the MN is in the process
of getting a nCoA then the either the oAR or the nAR (depending on who
sent PrRtAdv) shall keep the tunnel up and change the anchor point.

>Reason:
>
>Different domains will manage traffic and QoS according to specific
>mechanisms and policies. Some networks may prefer to support QoS for
BET
>tunnels by pre-allocating QoS between physically adjacent routers, i.e.
>router to which the MN can move in "one step" due to handoff. Given a
>router, the number of physically adjacent routers is limited, and the
>amount of QoS "pre-allocated" can be determined, e.g. for cellular
>links, based on the amount of radio links that can be accepted in a
cell
>as handoff links (this is already being done in cellular networks, thus
>there is no impact on L2). The use of chain tunnels and pre-allocated
>QoS is a scalable solution that allows for fast handoffs and guaranteed
>QoS with minimal network configuration.
>
>Result:
>
>Creating long tunnel chains may have issues, e.g. many routers in the
>chain need to maintain the state. The chaining issues, however, can be
>reduced by forcing the MN to obtain a new COA every time it does a BETH
>Handoff. 

This issue comes up all the time, and I am curious why. People
seem to have difficulty with the concept of removing all
IP signalling so that you just have the bare minimum latency. Basically,
any introducion of MIP signalling on handover is going to result
in a disruption of the real time traffic on handover on low
speed links, period. The whole point of BETH is to let the MN decide
when to 
perform handover, or have the network force handover if its required.

Rene>>  the idea is that we force the MN to get a nCoA only after the
BET is established and the MN has moved at L2 so that the time critical
L2 handoff can be conducted without interruption. This may happen
immediately or later according to the policies of the AR. In fact, in
case of low speed channels you need already to optimize the way you send
signaling over traffic channels for several reasons. Here, you can
safely assume that the MIP signaling is distributed in such a way that
it has the minimal impact on the quality of the real time service. In
addition, the signaling may be transmitted over the dedicated signaling
channel in cdma2000/UMTS. 

In any case, it is desirable from the network point of view that the
traffic path is optimized by removing the tunnel as and when determined
by the network.  Hence the network must be able to force the MN to do
new CoA formation.

>The proposed chain tunneling plus the network ability to force
>the MN to obtain nCoA and to move to the nAR, solve the issue related
to
>chain tunneling. For fast moving MN, a new BETH handoff may take place
>before the MN has created nCoA and moved to the nAR,thus multiple
>tunnels may exist at the same time. However, multiple tunnels are only
>temporary.
>
>

The network is *always* in a position to force handover. If an AR 
requires that the MN establish a nCoA to force QoS negotiation
or for any other reason, it can send an unsolicited Router Advert
and the MN must perform the handover.

Rene>> But our understanding is that if MN has L3 connectivity with oCoA
, it does not need to compute a new CoA with just an unsolicited RtAdv.
Hence, we support an explicit command like PrRtAdv or other.   We both
agree that the network is in control of "forcing" the MN when it wants
as per the local policy of the AR .  But it was not clear from the list
of events provided in the section 2.5 of BETH draft.  It would clarify
to add this event to avoid the confusion.

		jak


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 19:53:45 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20677
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 19:53:44 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18402;
	Fri, 26 Oct 2001 16:52:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02416;
	Fri, 26 Oct 2001 16:51:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QNoT6C026401
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:50:29 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QNoTZO026400
	for mobile-ip-dist; Fri, 26 Oct 2001 16:50:29 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QNoP6C026393
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:50:26 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05420
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:50:28 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228] (may be forged))
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20665
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 18:05:37 -0600 (MDT)
Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9QNoQj01302
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:50:26 -0700 (PDT)
Message-ID: <024b01c15e79$3fd54600$2b6015ac@DOCOMOKEMPF>
From: "James kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <748E8123D183394982E32A511DB3E73610B07D@daebe005.NOE.Nokia.com>
Subject: Re: [mobile-ip] Improving BETH: chain tunneling
Date: Fri, 26 Oct 2001 16:52:19 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Purnadi,

> Can you explain why this is any different than standard MIPv6?
>
> Rene>> The MIPv6 does not have the QoS establishment procedure, and the
> QoS negotiation happens separately. For a new route or tunnel
> establishment, you need to ensure the QoS consistency. This means
> additional QoS signaling and the delay associated with signaling and
> establishment. This may not be suitable for time critical handoff
> procedure. I hope I have answered based upon the correct understanding
> of your question.
>

I guess I still don't understand the problem, sorry. If the network is
doing QoS, then I assume a new QoS treatment for the mobile's
packets will need to be set up at the new AR regardless of
whether FMIPv6, SMIPv6 (standard MIPv6), or BETH is used.
Why is tunnel establishment any different? In Solaris (with
which I am a little familar), there is no need for special
QoS when establishing a tunnel.

> The difficulty with this proposal is that it introduces the possibility
> of routing loops if the MN moves back to aAR. Can you explain how you
> would
> avoid that, short of forcing the MN to always establish
> a nCoA on nAR?
>
> Rene>> There will not be any routing loops.  One way to do this is, the
> aAR can determine that the MN has still CoA from aAR (IP Address Option
> containing MN's old Care of Address) and it has established a tunnel to
> oAR. It either responds normally to the HRqst with HRply to nAR, but
> soon after L2-UP happens at the aAR, it tears down both tunnels to oAR
> and nAR/aAR, or it won't create the second tunnel to the oAR and soon
> after L2-UP happens at the aAR, it tears down the tunnel to oAR.  There
> is no need for tunnel and for nCoA. However, if the MN is in the process
> of getting a nCoA then the either the oAR or the nAR (depending on who
> sent PrRtAdv) shall keep the tunnel up and change the anchor point.
>

Actually, after I wrote this, I realized that you could prevent routing
loops by having nAR check whether it already has an outstanding
tunnel for that Care of Address or L2 address.

If the handover is target triggered, then the L2 address in the trigger to
the aAR will
be the same as an L2 address for which the aAR currently has an
open tunnel. If the handover is source triggered, then the oAR will
send the old CoA, which the aAR will recognize as being on its subnet.
In either case, aAR (==nAR) would send a lifetime of zero for the tunnel
back to oAR, indicating that
no tunnel was necessary, tear down the tunnel going out, and take
the MN directly without setting up a new tunnel to oAR. .

So I guess this problem could be handled. But I'm not so sure about
how to terminate the tunnel in the general case. It seems to me that
this would result in a cascade of tunnel termination signaling. It might get
tricky, I think it needs more study.

> >Reason:
> >
> >Different domains will manage traffic and QoS according to specific
> >mechanisms and policies. Some networks may prefer to support QoS for
> BET
> >tunnels by pre-allocating QoS between physically adjacent routers, i.e.
> >router to which the MN can move in "one step" due to handoff. Given a
> >router, the number of physically adjacent routers is limited, and the
> >amount of QoS "pre-allocated" can be determined, e.g. for cellular
> >links, based on the amount of radio links that can be accepted in a
> cell
> >as handoff links (this is already being done in cellular networks, thus
> >there is no impact on L2). The use of chain tunnels and pre-allocated
> >QoS is a scalable solution that allows for fast handoffs and guaranteed
> >QoS with minimal network configuration.
> >
> >Result:
> >
> >Creating long tunnel chains may have issues, e.g. many routers in the
> >chain need to maintain the state. The chaining issues, however, can be
> >reduced by forcing the MN to obtain a new COA every time it does a BETH
> >Handoff.
>
> This issue comes up all the time, and I am curious why. People
> seem to have difficulty with the concept of removing all
> IP signalling so that you just have the bare minimum latency. Basically,
> any introducion of MIP signalling on handover is going to result
> in a disruption of the real time traffic on handover on low
> speed links, period. The whole point of BETH is to let the MN decide
> when to
> perform handover, or have the network force handover if its required.
>
> Rene>>  the idea is that we force the MN to get a nCoA only after the
> BET is established and the MN has moved at L2 so that the time critical
> L2 handoff can be conducted without interruption. This may happen
> immediately or later according to the policies of the AR. In fact, in
> case of low speed channels you need already to optimize the way you send
> signaling over traffic channels for several reasons. Here, you can
> safely assume that the MIP signaling is distributed in such a way that
> it has the minimal impact on the quality of the real time service. In
> addition, the signaling may be transmitted over the dedicated signaling
> channel in cdma2000/UMTS.
>
> In any case, it is desirable from the network point of view that the
> traffic path is optimized by removing the tunnel as and when determined
> by the network.  Hence the network must be able to force the MN to do
> new CoA formation.
>

Sure, I've got no problem with letting the network remove the tunnel when
it needs to.

I think I understand your point now.
It seems like you are proposing using traffic engineering between ARs in
order
to get better performance on the wired edge, correct? I could even see this
extending to using MPLS LSPs instead of IP in IP tunnels. If it is not
possible to do tunnel chaining, then the network operator is forced to
mesh connect the ARs. This may not be physically possible, or it may not be
optimal.
If tunnel chaining is possible, the network operator has the option of doing
a mesh
or a chain, depending on how the physical and logical parameters of the
particular
deployment dictate.

> The network is *always* in a position to force handover. If an AR
> requires that the MN establish a nCoA to force QoS negotiation
> or for any other reason, it can send an unsolicited Router Advert
> and the MN must perform the handover.
>
> Rene>> But our understanding is that if MN has L3 connectivity with oCoA
> , it does not need to compute a new CoA with just an unsolicited RtAdv.

No, this is not so. If the MN receives an unsolicted RtAdv, it is a signal
that
the network wants it to apply for a nCoA. See Section 2.6.1

> Hence, we support an explicit command like PrRtAdv or other.   We both
> agree that the network is in control of "forcing" the MN when it wants
> as per the local policy of the AR .  But it was not clear from the list
> of events provided in the section 2.5 of BETH draft.  It would clarify
> to add this event to avoid the confusion.
>

I've got no objection to using PrRtAdv, but someone else pointed up that
since handover is not occuring, this is not the right message to use.

It sounds to me like you've got some particular cdma2000 applications in
mind. I wonder if any of the other cdma2000-knowledgable folks on the
list care to comment?

I think I'd like to think about how tunnel termination would work with
chained tunnels, and perhaps you could too (and maybe others have
some ideas) before I agree to this. Tunnel termination is one of the
trickiest parts of BETH, and I think I understand how it works with
tunnel handover, I'm not sure I do (yet) with tunnel chaining. If you come
up with something on how tunnel chains would be terminated, please
post it, as will I.

            jak





From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 19:58:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20712
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 19:58:01 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17710;
	Fri, 26 Oct 2001 17:56:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03427;
	Fri, 26 Oct 2001 16:55:28 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QNsj6C026479
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:54:45 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QNsiDY026478
	for mobile-ip-dist; Fri, 26 Oct 2001 16:54:44 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QNsf6C026471
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:54:41 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03306
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:54:44 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228] (may be forged))
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29494
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:54:43 -0700 (PDT)
Received: from DOCOMOALPER (dhcp98.docomo-usa.com [172.21.96.98])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9QNshj01482
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 16:54:43 -0700 (PDT)
Message-ID: <0bcf01c15e79$78a04e30$626015ac@DOCOMOALPER>
From: "Alper Yegin" <alper@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <Roam.SIMC.2.0.6.1003740874.29682.nordmark@bebop.france>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
Date: Fri, 26 Oct 2001 16:53:55 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello,

I know I'm late for the last call. But nevertheless I'd like to identify a
new security issue
with Mobile IPv6. Please take a look at this and comment....

Home address option of Mobile IPv6 gives the flexibility to use any IP
address as the source
address of a packet and send it to a receipent (a correspondent node). And
the correspondent
node should be able to process home address option to figure out the true
end point of this
communication. By using this option, a node can use any arbitrary IP address
as the source
address of outgoing packets, and be able to maintain end2end connection with
a peer.

This can be exploited by malicious nodes to impersonate other nodes, as far
as the routers
along the path are concerned.

Any mechanism that relies on the source IP address of a packet can be fooled
by using an
acceptable source IP address (like one borrowed from a legitimate node) and
carrying the
real source address in the home address option.

For example, a flow is (or proposed to be?) identified by the source address
and the flow
info of an IPv6 packet. If the malicious node can learn these two fields of
a legitimate packet, it can
start using them in its own packets. Therefore stealing QoS established for
another device (along
the common path).

So, why do we think there's something new here. Afterall, even with IPv4, a
device can steal
some other device's IP address and use it. But.... if it does so, the
correspondent node would
think that this packet is coming from the legitimate device, therefore any
correspondence will
be directed at the legitimate device. And hence, malicious node cannot enjoy
a end2end
communication.

With IPv6 and home address option, the packets from the malicious node look
like they are from
a legitimate node to all the routers along the path (same as in IPv4)  and
when arrived at the
correspondent node they reveal their true sender (this is new!).

A correspondent node receiving such packets won't know what's going on. And
nothing special
on correspondent node is expected for this to work (except a correct
implementation of home
address option processing :)

First solution that comes to mind would be to expect protocols to check for
home address
option in addition to source address, but that is not desirable as it is
costly.

What do people think about this issue?

(I might not be able to follow rest of the discussion for a week. I'll be
out of town. But I'm sending
this now, so that the discussion is not delayed).

alper
NTT DoCoMo USA Labs




From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 21:34:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21524
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 21:34:26 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10135;
	Fri, 26 Oct 2001 18:33:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10695;
	Fri, 26 Oct 2001 18:31:54 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R1TV6C027017
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 18:29:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9R1TVsR027016
	for mobile-ip-dist; Fri, 26 Oct 2001 18:29:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R1TS6C027009
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 18:29:28 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17651
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 18:29:30 -0700 (PDT)
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25569
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 19:29:28 -0600 (MDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA23956
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 21:26:57 -0400
Received: from d03nm036.boulder.ibm.com (d03nm036.boulder.ibm.com [9.99.140.36])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9R1TSN220440
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 19:29:28 -0600
From: "Venkata Jagana" <jagana@us.ibm.com>
Importance: Normal
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: mobile-ip@sunroof.eng.sun.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFEF63CB64.BF48BF5C-ON88256AF2.00049538@boulder.ibm.com>
Date: Fri, 26 Oct 2001 18:29:22 -0700
X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 10/26/2001 07:29:28 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>



Hello Alper,

What a coincidence! I am little bit late in sending out the exactly
similar thought that I have on this security hole and the corresponding
enhancement.

In fact, I believe, the malicious node don't even need to know the CoA
of MN and the home address is more than sufficient for it to send a
packet with arbitrary src address in the packet to CN. As per
the current MIpv6 draft, CN  would have to simply replace the 'src'
address of IPv6 packet by the home address in the home address option
in the incoming packet without any further validations and this is a
problem.

The solution, that I have in my mind, can be simply to look at the
CN's binding cache upon receipt of incoming packet and validate that
'src and home address' of the packet matches with CN's CoA <-> Home
Address binding before accepting it for further processing. In fact, this
binding cache is already consulted for outgoing packets and it needs
to be done for incoming packets as well in order to address this
security concern and so, this may not be a real overhead since it is
a simple lookup. However, this solution may not really work well in
case where the malicious node somehow steals both CoA and Home address
of MN and I guess that's always an issue anyway.


Thanks,
Venkat

----------------------------------------------------------------
Venkata R Jagana
IBM Linux Technology Centre, Beaverton
jagana@us.ibm.com
Tel: (503) 578 3430 T/L 775-3430


"Alper Yegin" <alper@docomolabs-usa.com>@sunroof.eng.sun.com on 10/26/2001
04:53:55 PM

Please respond to mobile-ip@sunroof.eng.sun.com

Sent by:  owner-mobile-ip@sunroof.eng.sun.com


To:   <mobile-ip@sunroof.eng.sun.com>
cc:
Subject:  Re: [mobile-ip] Last Call Comments on
      http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt


Hello,

I know I'm late for the last call. But nevertheless I'd like to identify a
new security issue
with Mobile IPv6. Please take a look at this and comment....

Home address option of Mobile IPv6 gives the flexibility to use any IP
address as the source
address of a packet and send it to a receipent (a correspondent node). And
the correspondent
node should be able to process home address option to figure out the true
end point of this
communication. By using this option, a node can use any arbitrary IP
address
as the source
address of outgoing packets, and be able to maintain end2end connection
with
a peer.

This can be exploited by malicious nodes to impersonate other nodes, as far
as the routers
along the path are concerned.

Any mechanism that relies on the source IP address of a packet can be
fooled
by using an
acceptable source IP address (like one borrowed from a legitimate node) and
carrying the
real source address in the home address option.

For example, a flow is (or proposed to be?) identified by the source
address
and the flow
info of an IPv6 packet. If the malicious node can learn these two fields of
a legitimate packet, it can
start using them in its own packets. Therefore stealing QoS established for
another device (along
the common path).

So, why do we think there's something new here. Afterall, even with IPv4, a
device can steal
some other device's IP address and use it. But.... if it does so, the
correspondent node would
think that this packet is coming from the legitimate device, therefore any
correspondence will
be directed at the legitimate device. And hence, malicious node cannot
enjoy
a end2end
communication.

With IPv6 and home address option, the packets from the malicious node look
like they are from
a legitimate node to all the routers along the path (same as in IPv4)  and
when arrived at the
correspondent node they reveal their true sender (this is new!).

A correspondent node receiving such packets won't know what's going on. And
nothing special
on correspondent node is expected for this to work (except a correct
implementation of home
address option processing :)

First solution that comes to mind would be to expect protocols to check for
home address
option in addition to source address, but that is not desirable as it is
costly.

What do people think about this issue?

(I might not be able to follow rest of the discussion for a week. I'll be
out of town. But I'm sending
this now, so that the discussion is not delayed).

alper
NTT DoCoMo USA Labs








From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 22:19:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22562
	for <mobileip-archive@odin.ietf.org>; Fri, 26 Oct 2001 22:19:02 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08828;
	Fri, 26 Oct 2001 20:17:57 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14622;
	Fri, 26 Oct 2001 19:16:47 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R2FV6C027157
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 19:15:31 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9R2FVKJ027156
	for mobile-ip-dist; Fri, 26 Oct 2001 19:15:31 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R2FR6C027149
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 19:15:27 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14387
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 19:15:30 -0700 (PDT)
Received: from pub.shantou.gd.cn (pub.shantou.gd.cn [202.96.144.46])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28934
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 19:15:29 -0700 (PDT)
Received: from marshall ([202.108.10.6])
	by pub.shantou.gd.cn (8.9.3/8.9.3) with SMTP id KAA28002
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 10:14:54 +0800 (CST)
Message-ID: <005301c15e8d$543391b0$060a6cca@marshall>
From: "Weishuai Yang" <wsyang@eyou.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <91A311FF6A85D3118DDF0060080C3D82010DCE85@lat3721.rd.francetelecom.fr> <013501c15d62$f6fdf060$bec21d8d@icn.siemens.it> <3BD866B9.3DA53695@iprg.nokia.com> <001f01c15dc5$69d08be0$3506fc87@marshall> <3BD992B8.FDAEB04C@iprg.nokia.com>
Subject: Re: [mobile-ip] Any news about Fast Handovers for MIPv6 ?
Date: Sat, 27 Oct 2001 10:11:26 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9R2FS6C027150
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hi Charles,

That file can't be found on your server.
Not Found
The requested URL /~charliep/iscc99/iscc99.ps was not found on this server.

and do you mean buffer management for FMIPv6 is implemented?

I can't find that draft on ietf.


Thank.

Weishuai Yang

----- Original Message ----- 
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
To: <wsyang@eyou.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
Sent: Saturday, October 27, 2001 12:43 AM
Subject: Re: [mobile-ip] Any news about Fast Handovers for MIPv6 ?


> Hello,
> 
> We have implemented buffer management for fast handovers, and it
> does work very well.
> 
> For some background, take a look at:
> 
> @INPROCEEDINGS{caceres-padman, 
>         author = "Ramon Caceres and Venkata Padmanabhan",
>         title = "{Fast and {S}calable {H}andoffs for {W}ireless
>                  {I}nternetworks}",
>         booktitle = "ACM Mobicom 96",
>         month = nov,
>         pages = {56-66},
>         year = 1996,
> }
> 
> and
> 
> @INPROCEEDINGS{perkins-wang,  
>         author = "Charles E. Perkins and Kuang-Yeh Wang",
>         title = {Optimized {S}mooth {H}andoffs in {M}obile {IP}},
>         booktitle = "Proceedings of the Fourth IEEE Symposium on
>                 Computers & Communications (ISCC'99)",
>         month = jul,
>         pages = {340-346},
>         year = 1999,
> }
> 
> A version of the latter is available at:
> http://people.nokia.net/~charliep/iscc99/iscc99.ps
> 
> I hope you find these useful.
> 
> Regards,
> Charlie P.
> 
> 
> 
> 
> 
> Weishuai Yang wrote:
> > 
> > hi, folks,
> > 
> > I think adding Buffer Management for Fast Handovers is necessery, and I'm
> > doing it right now. How do you think about it?
> > 
> > Weishuai Yang


From owner-mobile-ip@sunroof.eng.sun.com  Fri Oct 26 23:49:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24633
	for <mobileip-archive@lists.ietf.org>; Fri, 26 Oct 2001 23:49:16 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25290;
	Fri, 26 Oct 2001 20:48:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03683;
	Fri, 26 Oct 2001 20:46:37 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R3jn6C027362
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 20:45:49 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9R3jnN0027361
	for mobile-ip-dist; Fri, 26 Oct 2001 20:45:49 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R3jj6C027354
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 20:45:45 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28003
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 20:45:49 -0700 (PDT)
Received: from telecom.samsung.co.kr (metro.telecom.samsung.co.kr [165.213.221.4])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16292
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 20:45:48 -0700 (PDT)
Received: from cychong (a22421 [165.213.224.21])
	by telecom.samsung.co.kr (8.11.6/8.11.6) with SMTP id f9R3fZ515424
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 12:41:35 +0900 (KST)
Message-ID: <000a01c15e9a$858b2db0$15e0d5a5@cychong>
From: "Chae-yong Chong" <cychong@metro.telecom.samsung.co.kr>
To: <mobile-ip@sunroof.eng.sun.com>
References: <4AE1AC3D692F55488F2D03518907B8AD08533A@beebe001.NOE.Nokia.com>
Subject: Re: [mobile-ip] problem about deregistration of MIP
Date: Sat, 27 Oct 2001 12:50:29 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9R3jk6C027355
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

why not do that?

Chae-yong

----- Original Message ----- 
From: <Yanqun.Le@nokia.com>
To: <MAkram@MEGISTO.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
Sent: Friday, October 26, 2001 12:25 PM
Subject: RE: [mobile-ip] problem about deregistration of MIP


> Thank you very much.
> 
> I have another question:
> If the home address is allocated dynamilcally, that is to say, in
> Registration Request, the home address is zero, and the allocated home
> address is returned by Registration Reply.
> Then if the MN deregistrater, must it fill the home address with
> allocated home address?
> 
> Best regards
> Le Yanqun
> 
> 
> -----Original Message-----
> From: ext Mohammad Akram [mailto:MAkram@MEGISTO.com]
> Sent: Thursday, October 25, 2001 9:47 PM
> To: Le Yanqun (Nokia-RD/Beijing)
> Subject: RE: [mobile-ip] problem about deregistration of MIP
> 
> 
> Hi Le,
> 
> Comments inline.
> 
> -----Original Message-----
> From: Yanqun.Le@nokia.com [mailto:Yanqun.Le@nokia.com]
> Sent: Thursday, October 25, 2001 6:04 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] problem about deregistration of MIP
> 
> 
> hi,
> 
> When a mobile node send Registration Request to a Mobile IP Agent, how
> can the Agent decide whether the mobile node doing deregistration? By
> which criterion below?
> 
> There are two cases to consider here:
> Case 1: HA supports Simultaneous Bindings.
> Case 2: HA DOES NOT supports Simultaneous Bindings.
> 
> Condition 1) care-of-address equal to its home address, 
> Condition 2) registration lifetime equal to 0;
> 
> If both Condition1 & 2 are true then for both Case1 & 2 this means 
> MN is at the Home network and wants to de-register.
> HA removes ALL the mobility binding(s) associated to this MN.
> 
> If only condition 2 is true then -
> In Case 1: HA removes ONLY the mobility binding associated to the CoA
> address
> specified in the Registration Request. HA could have
> other
> active 
> mobility bindings for the MN ,with other CoA.
> In Case 2: HA removes the single mobility binding permited. 
>            But MN is not on the Home network.
> 
> Note: Condition 1 is true only when condition 2 is also true but not
> vice
> versa.
> 
> 
> 
> 3) if NAI exists in Registration Request ,the realm part of NAI is the
> same to the realm the Agent belongs to.
> 
> I am sorry, I don't know about the NAI.
> 
> Can every one be used to decide deregistration or the combination of
> those?
> 
> Thanks 
> Le Yanqun
>  
> 
> Hope this helps.
> 
> Mohammad.
> 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct 27 00:29:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24877
	for <mobileip-archive@odin.ietf.org>; Sat, 27 Oct 2001 00:29:24 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29424;
	Fri, 26 Oct 2001 21:28:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01850;
	Fri, 26 Oct 2001 21:26:56 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R4Ps6C027521
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 21:25:54 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9R4PsQ0027520
	for mobile-ip-dist; Fri, 26 Oct 2001 21:25:54 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R4Pn6C027513
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 21:25:49 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07261
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 21:25:42 -0700 (PDT)
Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11447
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 22:25:51 -0600 (MDT)
Received: from jariws1 ([62.248.155.34]) by fep07-app.kolumbus.fi
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP
          id <20011027042551.CQHH5453.fep07-app.kolumbus.fi@jariws1>
          for <mobile-ip@sunroof.eng.sun.com>;
          Sat, 27 Oct 2001 07:25:51 +0300
Message-ID: <008001c15e9f$7b2c5b00$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: <mobile-ip@sunroof.eng.sun.com>
References: <OFEF63CB64.BF48BF5C-ON88256AF2.00049538@boulder.ibm.com>
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
Date: Sat, 27 Oct 2001 07:26:00 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

> The solution, that I have in my mind, can be simply to look at the
> CN's binding cache upon receipt of incoming packet and validate that
> 'src and home address' of the packet matches with CN's CoA <-> Home
> Address binding before accepting it for further processing. In fact, this

If you did this, wouldn't it mean that Route Optimization is mandatory to use
in all Mobile IPv6 communications? This would be a big change. Also,
how would the first BU packet get validated by this rule?!

Jari





From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct 27 00:58:49 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25008
	for <mobileip-archive@odin.ietf.org>; Sat, 27 Oct 2001 00:58:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA02438;
	Fri, 26 Oct 2001 21:57:42 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04372;
	Fri, 26 Oct 2001 21:56:32 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R4te6C027667
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 21:55:40 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9R4teXO027666
	for mobile-ip-dist; Fri, 26 Oct 2001 21:55:40 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R4tb6C027659
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 21:55:37 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04299
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 21:55:40 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA05106
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 23:12:32 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA22535;
	Fri, 26 Oct 2001 21:55:39 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9R4tcP17249;
	Fri, 26 Oct 2001 21:55:38 -0700
X-mProtect:  Fri, 26 Oct 2001 21:55:38 -0700 Nokia Silicon Valley Messaging Protection
Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdZJETad; Fri, 26 Oct 2001 21:55:35 PDT
Message-ID: <3BDA3D5D.BB88AD6A@iprg.nokia.com>
Date: Fri, 26 Oct 2001 21:51:41 -0700
From: Charlie Perkins <charliep@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alper Yegin <alper@docomolabs-usa.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Last Call Comments on 
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
References: <Roam.SIMC.2.0.6.1003740874.29682.nordmark@bebop.france> <0bcf01c15e79$78a04e30$626015ac@DOCOMOALPER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Alper,


Alper Yegin wrote:

> This can be exploited by malicious nodes to impersonate other nodes, as far
> as the routers along the path are concerned.

The point of the option is to apply a topologically correct source
address.  Routers aren't checking to see _who_ is sending the
packet.  They're checking to see if the address matches a reasonable
prefix.  I don't think it makes sense to worry about a malicious node
impersonating a node, when the entity it is fooling doesn't care anyway.

>
>
>
> Aaddress in the home address option.
>
> For example, a flow is (or proposed to be?) identified by the source address
> and the flow
> info of an IPv6 packet. If the malicious node can learn these two fields of
> a legitimate packet, it can
> start using them in its own packets. Therefore stealing QoS established for
> another device (along
> the common path).

It is an interesting problem about whether a flow label needs to be
interpreted according to the destination IP address or the home
address.  It seems wrong to try to make the intermediate
routers parse the home address option.  I reckon that there
should be a QoS feature transfer, which includes something
about new and old flow labels, to handle the flow over a tunnel
between access routers while the new care-of address gets to
be associated with the flow.  We've been puzzling over this a
little bit already in our group, but it depends on a lot of things that
are currently unknown.

It's not a security problem, though...

>

> With IPv6 and home address option, the packets from the malicious node look
> like they are from
> a legitimate node to all the routers along the path (same as in IPv4)  and
> when arrived at the
> correspondent node they reveal their true sender (this is new!).

It would be exactly like the packets came from the home network.... right?
And so that's exactly what we are trying to accomplish!

> First solution that comes to mind would be to expect protocols to check for
> home address
> option in addition to source address, but that is not desirable as it is
> costly.

Why do you want to do this?  Which protocols should check?  Surely not
the protocols running on the routers...?

Regards,
Charlie P.




From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct 27 01:18:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25938
	for <mobileip-archive@odin.ietf.org>; Sat, 27 Oct 2001 01:18:51 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA04734;
	Fri, 26 Oct 2001 22:17:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA06151;
	Fri, 26 Oct 2001 22:16:34 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R5Fh6C027798
	for <mobile-ip-dist@sunroof.eng.sun.com>; Fri, 26 Oct 2001 22:15:43 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9R5FhEq027797
	for mobile-ip-dist; Fri, 26 Oct 2001 22:15:43 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R5Fd6C027790
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 22:15:40 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11559
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 22:15:25 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA10560
	for <mobile-ip@sunroof.eng.sun.com>; Fri, 26 Oct 2001 23:32:28 -0600 (MDT)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9R5FYD06139;
	Sat, 27 Oct 2001 08:15:34 +0300
Date: Sat, 27 Oct 2001 08:15:33 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Alper Yegin <alper@docomolabs-usa.com>, Venkata Jagana <jagana@us.ibm.com>
Subject: Re: [mobile-ip] Last Call Comments on
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
In-Reply-To: <OFEF63CB64.BF48BF5C-ON88256AF2.00049538@boulder.ibm.com>
Message-ID: <Pine.LNX.4.33.0110270811340.5991-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Fri, 26 Oct 2001, Venkata Jagana wrote:
> What a coincidence! I am little bit late in sending out the exactly
> similar thought that I have on this security hole and the corresponding
> enhancement.
> 
> In fact, I believe, the malicious node don't even need to know the CoA
> of MN and the home address is more than sufficient for it to send a
> packet with arbitrary src address in the packet to CN. As per
> the current MIpv6 draft, CN  would have to simply replace the 'src'
> address of IPv6 packet by the home address in the home address option
> in the incoming packet without any further validations and this is a
> problem.
> 
> The solution, that I have in my mind, can be simply to look at the
> CN's binding cache upon receipt of incoming packet and validate that
> 'src and home address' of the packet matches with CN's CoA <-> Home
> Address binding before accepting it for further processing. In fact, this
> binding cache is already consulted for outgoing packets and it needs
> to be done for incoming packets as well in order to address this
> security concern and so, this may not be a real overhead since it is
> a simple lookup. However, this solution may not really work well in
> case where the malicious node somehow steals both CoA and Home address
> of MN and I guess that's always an issue anyway.

AFAICS, most of theses issues were brought up and discussed somewhat
during the last two weeks.  Some description of the problem is at:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords







From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct 27 11:53:21 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14462
	for <mobileip-archive@lists.ietf.org>; Sat, 27 Oct 2001 11:53:21 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08453;
	Sat, 27 Oct 2001 08:52:12 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14147;
	Sat, 27 Oct 2001 08:50:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9RFo96C028575
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sat, 27 Oct 2001 08:50:09 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9RFo9v9028574
	for mobile-ip-dist; Sat, 27 Oct 2001 08:50:09 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9RFo56C028567
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 08:50:05 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12655
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 08:50:07 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14034
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 10:08:39 -0600 (MDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9RFo4k18193;
	Sat, 27 Oct 2001 08:50:04 -0700 (PDT)
Received: from oranlt ([161.44.238.48])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABF96326;
	Sat, 27 Oct 2001 08:50:04 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: "'ext Hesham Soliman \(EPA\)'" <Hesham.Soliman@ericsson.com.au>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>
Subject: RE: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of the security discussion
Date: Sat, 27 Oct 2001 11:50:14 -0400
Organization: Cisco Systems
Message-ID: <009b01c15eff$11fcdbe0$30ee2ca1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3311
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000
In-Reply-To: <15319.22926.148456.166125@thomasm-u1.cisco.com>
Importance: Normal
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Small refinement to what Mike Thomas was saying:

> -----Original Message-----
> From: owner-mobile-ip@sunroof.eng.sun.com 
> [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of 
> Michael Thomas
> Sent: Wednesday, October 24, 2001 8:15 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: 'ext Hesham Soliman (EPA)'; 'ext Michael Thomas'; Michael 
> A. Ramalho
> Subject: Piggybacking: final thoughts ? Was RE: [mobile-ip] 
> MIPv6 - Focus of the security discussion
> 
> 
> Koodli Rajeev (NRC/MtView) writes:
>   >You say if it does, it has performance issues. I say we
>  > don't design based on a link's performance..
> 
> _Oh_??? There's a difference between being a slave
> to link layers and not considering them at all. If
> I believed that this was a narrow situation that
> is only related to a single link layer which needs
> to be redesigned for IP anyway, you would not be
> getting any arguments from me. However, I believe
> that this slotting problem that we've been
> describing is a fundamental engineering tradeoff
> when you have a shared media, such as radio.
> 
I believe Mike's right for links which are shared point-to-multipoint
AND have a long channel arbitration time for the centralized scheduler
to grant access. The channel slotting amortizes the access time and
minimizes the lost bandwidth due to control overhead. The efficiency
improvement on both scores is actually quite dramatic.

If these were in fact really oddball links, then it would in fact be
appropriate to just dump L3 packets in any old way and tell the link
designers to cope. The reality is that these links are pretty common
(DOCSIS, cellular radio, 802.11, etc.) and the designers didn't just
throw in slotting because they were stupid. They wanted to provide a L2
with decent jitter bounds for traffic that cares about delay dispersion
without paying an exhorbitant bandwidth cost in control overhead.

So, my 2 cents is that it does make sense to tune MIP to run well over
slotted, centrally arbitrated channels.

What seems to be of issue is whether the cases of other bandwidth
constrained non-slotted channels (e.g. low speed pt-pt links) gain
enough from things like piggybacking to make a tradeoff which will
likely hurt performance on slotted channels. My personal view is that
even over non-slotted channels header compression makes the additional
gain of piggybacking quite small, and layer 2 blocking (multiple IP
packets in one layer 2 frame) eliminates nearly all of the rest of the
potential gain.

> I have repeatedly asked for a concrete example of
> a shared media which provides QoS guarantees which
> would substantially benefit from piggybacking. You
> still have not done that. 
> 
>  > Finally, my position is that removing piggybacking is not 
> an option.
> 
> Everything is an option. The draft is not done.
>
Unfortunately, I fear that we have argued this back and forth so much
without progress, that consensus seems unlikely. I don't know frankly
where we go from here...

Dave Oran
 
> 	      Mike
> 



From owner-mobile-ip@sunroof.eng.sun.com  Sat Oct 27 20:34:20 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17540
	for <mobileip-archive@odin.ietf.org>; Sat, 27 Oct 2001 20:34:20 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA09138;
	Sat, 27 Oct 2001 17:33:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27933;
	Sat, 27 Oct 2001 17:31:46 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9S0V26C029088
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sat, 27 Oct 2001 17:31:03 -0700 (PDT)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9S0V2ip029087
	for mobile-ip-dist; Sat, 27 Oct 2001 17:31:02 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9S0Ux6C029080
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 17:30:59 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27872
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 17:30:50 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13656
	for <mobile-ip@sunroof.eng.sun.com>; Sat, 27 Oct 2001 18:30:56 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA23736;
	Sat, 27 Oct 2001 17:31:00 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9S0V0230841;
	Sat, 27 Oct 2001 17:31:00 -0700
X-mProtect:  Sat, 27 Oct 2001 17:31:00 -0700 Nokia Silicon Valley Messaging Protection
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdnf4e57; Sat, 27 Oct 2001 17:30:57 PDT
Message-ID: <3BDB51C1.C5C9B7CD@iprg.nokia.com>
Date: Sat, 27 Oct 2001 17:30:57 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: David Oran <oran@cisco.com>
CC: mobile-ip@sunroof.eng.sun.com
Subject: Re: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of 
 the security discussion
References: <009b01c15eff$11fcdbe0$30ee2ca1@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello Dave,

"David R. Oran" wrote:

>> _Oh_??? There's a difference between being a slave
>> to link layers and not considering them at all. If
>> I believed that this was a narrow situation that
>> is only related to a single link layer which needs
>> to be redesigned for IP anyway, you would not be
>> getting any arguments from me. However, I believe
>> that this slotting problem that we've been
>> describing is a fundamental engineering tradeoff
>> when you have a shared media, such as radio.

> I believe Mike's right for links which are shared point-to-multipoint
> AND have a long channel arbitration time for the centralized scheduler
> to grant access. The channel slotting amortizes the access time and
> minimizes the lost bandwidth due to control overhead. The efficiency
> improvement on both scores is actually quite dramatic.

There isn't any essential conflict between channel slotting
vs. IP,, or vs. IPv6, or vs. Mobile IPv6, or vs. sending Binding
Updates in a destination option with payload.  In order to handle
IP over a rigorously slotted link, one _could_ reasonable expect to
have some slicing and dicing going on, which is already _mandated_
for those links if they run IPv6 (section 5,RFC 2460).  If you want
to run IPv6 over a link that cannot support 1280 byte MTU, then
I reckon you're going to have all sorts of problems.

What if we assume the link CAN run IPv6 (or even just IPv4, for
that matter!)?  With that assumption, then I claim that we will
always see a performance improvement if one can include destination
options with payload, vs. sending destination options in a separate
packet.  You may then ask what the numbers are.  I'm not quite
ready to cite them, but I'm still taking bets that it will be
a positive number (increased performance) vs. a negative number
(a performance loss).

What do you think?

> So, my 2 cents is that it does make sense to tune MIP to run well over
> slotted, centrally arbitrated channels.

Agreed!

>                                             My personal view is that
> even over non-slotted channels header compression makes the additional
> gain of piggybacking quite small, and layer 2 blocking (multiple IP
> packets in one layer 2 frame) eliminates nearly all of the rest of the
> potential gain.

I am sure that we will see a variation of the performance gains over
various links.  I am also sure the variation will range over positive
numbers only, for links that are engineered to fulfill the mandates of
IPv6.  Since a receiver does not need extra complexity to handle such
packets, then the performance gains will go to those systems where the
implementers carry out the necessary extra work so that mobile nodes
sending packets can see the improvement.  For some links, it may not
make sense to invest the time for implementation.  For other links it
will.  But to change the rules so that no one can ever benefit from the
performance enhancement, on any possible link, seems quite ill advised
to me.

I am sure that _nobody_ is making suggestions that will cause cellular
links that perform _worse_, given reasonable assumptions.  Furthermore,
I am also sure that future cellular links will be engineered to handle
IP{,v6} data _better_ than current links do.  Then, it would be a shame
to look back and observe how short-sighted it was to deploy a mobility
protocol that _could not_ fulfill the performance gain in the same easy
ways.  We may even discover that the performance gain is not killer,
but only an incremental improvement.  But the whole history of cellular
has been putting together more and more incremental improvements.
No one technique solves all the problems, and performance leaks do have
a way of accumulating.

> Unfortunately, I fear that we have argued this back and forth so much
> without progress, that consensus seems unlikely. I don't know frankly
> where we go from here...

I don't have that fear.  I think that with enough reasonable conversation
between reasonable engineers we will get to the point of agreement.
I'll try to do my part.

Regards,
Charlie P.


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 28 11:28:39 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14438
	for <mobileip-archive@lists.ietf.org>; Sun, 28 Oct 2001 11:28:39 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15280;
	Sun, 28 Oct 2001 09:28:21 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02155;
	Sun, 28 Oct 2001 08:28:04 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SGQaQO000233
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 08:26:36 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9SGQaLM000232
	for mobile-ip-dist; Sun, 28 Oct 2001 08:26:36 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SGQWQO000224
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 08:26:32 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22338
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 08:26:34 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02334
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 08:26:33 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9SGQXe18719;
	Sun, 28 Oct 2001 08:26:33 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE72275;
	Sun, 28 Oct 2001 08:25:56 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12084; Sun, 28 Oct 2001 08:26:32 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15324.12728.299221.747763@thomasm-u1.cisco.com>
Date: Sun, 28 Oct 2001 08:26:32 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: "'ext Hesham Soliman \(EPA\)'" <Hesham.Soliman@ericsson.com.au>,
        "'Michael A. Ramalho'" <mramalho@cisco.com>
Subject: RE: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of the security discussion
In-Reply-To: <009b01c15eff$11fcdbe0$30ee2ca1@cisco.com>
References: <15319.22926.148456.166125@thomasm-u1.cisco.com>
	<009b01c15eff$11fcdbe0$30ee2ca1@cisco.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

David R. Oran writes:
 > Unfortunately, I fear that we have argued this back and forth so much
 > without progress, that consensus seems unlikely. I don't know frankly
 > where we go from here...

   This can all be boiled down to this tradeoff:

   Piggybacking: an optimization which cannot be used to
     any appreciable gain for the flows on shared bandwidth 
     constrained links; specifically makes using 2401
     compliant IPsec impossible, and provides no means
     for automated key distribution for strong authentication

   Non-piggybacking: loses bandwidth/latency gains on other
     L2's, but primarily where the optimization is either
     unnecessary or can be accommodated by equivalent L2 
     mechanisms. Allows use of RFC 2401 standard IPsec, and 
     retains  the ability to use standard IPsec key distribution
     mechanisms (IKE, KINK).

		      Mike


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 28 11:35:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14489
	for <mobileip-archive@lists.ietf.org>; Sun, 28 Oct 2001 11:35:19 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16839;
	Sun, 28 Oct 2001 09:35:11 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02725;
	Sun, 28 Oct 2001 08:35:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SGYXQO000394
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 08:34:33 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9SGYX4V000393
	for mobile-ip-dist; Sun, 28 Oct 2001 08:34:33 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SGYTQO000386
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 08:34:29 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22821
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 08:34:31 -0800 (PST)
Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16608
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 09:34:25 -0700 (MST)
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: RE: [mobile-ip] problem about deregistration of MIP
Date: Sun, 28 Oct 2001 11:34:30 -0500
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB21068B94@EXCHANGE01.domain.ecutel.com>
Thread-Topic: [mobile-ip] problem about deregistration of MIP
Thread-Index: AcFdzj4oD+gtAFdXQSmqCiDwqEdM8AB+U7l+
From: "Qiang Zhang" <qzhang@ecutel.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <mobile-ip@sunroof.eng.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9SGYUQO000387
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
	I have another question:
	If the home address is allocated dynamilcally, that is to say,
Content-Transfer-Encoding: 8bit

in
	Registration Request, the home address is zero, and the
allocated home
	address is returned by Registration Reply.
	Then if the MN deregistrater, must it fill the home address with
	allocated home address?

	=> That should be required, for example, it is not restricted
that MN can have obtained multiple home addresses either from one HA or
different HAs so that the MN actually tended to maintain multiple
bindings.  Unless otherwise the Home address is being conveyed, there
will be confusion for the HA and AAA server which try to maintain the
multiple bindings and accounting sessions. NAI is not unique in this
scenario, which only enables user level mobility.

	 Also just to tackle on the earlier discussion,  the
care-of-address sent by the Mobile node while-deregistration is not
trustable if put the MN in a context of private network or regional
registration network, care-of-addr for known to the MN may be different
from the COA known to the HA. 

	In short, combined credentials need to be used to locate the
uniqueness if you have a complicated environment. 

	 

	There are two cases to consider here:
	Case 1: HA supports Simultaneous Bindings.
	Case 2: HA DOES NOT supports Simultaneous Bindings.
	
	Condition 1) care-of-address equal to its home address,
	Condition 2) registration lifetime equal to 0;
	
	If both Condition1 & 2 are true then for both Case1 & 2 this
means
	MN is at the Home network and wants to de-register.
	HA removes ALL the mobility binding(s) associated to this MN.
	
	If only condition 2 is true then -
	In Case 1: HA removes ONLY the mobility binding associated to
the CoA
	address
	                specified in the Registration Request. HA could
have
	other
	active
	                mobility bindings for the MN ,with other CoA.
	In Case 2: HA removes the single mobility binding permited.
	           But MN is not on the Home network.
	
	Note: Condition 1 is true only when condition 2 is also true but
not
	vice
	versa.
	
	
	
	3) if NAI exists in Registration Request ,the realm part of NAI
is the
	same to the realm the Agent belongs to.
	

	 

	
	 



From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 28 16:37:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16198
	for <mobileip-archive@lists.ietf.org>; Sun, 28 Oct 2001 16:37:04 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03284;
	Sun, 28 Oct 2001 14:36:56 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20385;
	Sun, 28 Oct 2001 13:36:54 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SLZSQO000696
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 13:35:28 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9SLZSLm000695
	for mobile-ip-dist; Sun, 28 Oct 2001 13:35:28 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SLZOQO000688
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 13:35:24 -0800 (PST)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24067
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 13:35:15 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03532
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 13:35:26 -0800 (PST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9SLXG900355;
	Sun, 28 Oct 2001 13:33:16 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE73087;
	Sun, 28 Oct 2001 13:34:49 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12096; Sun, 28 Oct 2001 13:35:25 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15324.31261.259540.451514@thomasm-u1.cisco.com>
Date: Sun, 28 Oct 2001 13:35:25 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Alper Yegin <alper@docomolabs-usa.com>
Subject: Re: [mobile-ip] Last Call Comments on 
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
In-Reply-To: <3BDA3D5D.BB88AD6A@iprg.nokia.com>
References: <Roam.SIMC.2.0.6.1003740874.29682.nordmark@bebop.france>
	<0bcf01c15e79$78a04e30$626015ac@DOCOMOALPER>
	<3BDA3D5D.BB88AD6A@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Charlie Perkins writes:
 > Hello Alper,
 > 
 > 
 > Alper Yegin wrote:
 > 
 > > This can be exploited by malicious nodes to impersonate other nodes, as far
 > > as the routers along the path are concerned.
 > 
 > The point of the option is to apply a topologically correct source
 > address.  Routers aren't checking to see _who_ is sending the
 > packet.  They're checking to see if the address matches a reasonable
 > prefix.  I don't think it makes sense to worry about a malicious node
 > impersonating a node, when the entity it is fooling doesn't care anyway.

   Would this were true. There is one pretty
   intersting question about the RSVP/MIPv6
   interaction, and that is whether the RSVP
   router should filter off of the CoA, or off
   of the home address. As far as I can tell,
   there isn't an answer for this. There's 
   some amount of win were it to filter off
   of the home address because of session 
   persistence (changing CoA's pretty much
   means that you have to start a new reservation
   otherwise). Here, the attack Alper points out
   could in fact lead to hijacking of QoS
   resources, I'd think were it to filter off
   of home address. That would certainly be
   notable since it would move the attack from
   a DoS attack to a hijacking attack.

   Of course, the reality is that routers do
   make decisions off of L3/L4 headers all the
   time. It's not clear that they wouldn't want
   to filter off of home address option as well
   since that denotes "home". Since the home 
   address option was motivated primarily by the
   fact that routers do ingress filtering, I don't
   think this is quite as clear as you make it out to be.

	    Mike


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 28 16:43:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16240
	for <mobileip-archive@lists.ietf.org>; Sun, 28 Oct 2001 16:43:41 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05147;
	Sun, 28 Oct 2001 14:43:33 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08746;
	Sun, 28 Oct 2001 13:43:32 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SLgYQO000815
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 13:42:34 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9SLgYGN000814
	for mobile-ip-dist; Sun, 28 Oct 2001 13:42:34 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SLgVQO000807
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 13:42:31 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24303
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 13:42:21 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00923
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 15:03:27 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9SLgbU03630;
	Sun, 28 Oct 2001 13:42:37 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE73116;
	Sun, 28 Oct 2001 13:41:56 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12099; Sun, 28 Oct 2001 13:42:32 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15324.31687.893562.211060@thomasm-u1.cisco.com>
Date: Sun, 28 Oct 2001 13:42:31 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Cc: Alper Yegin <alper@docomolabs-usa.com>
Subject: Re: [mobile-ip] Last Call Comments on 
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
In-Reply-To: <3BDA3D5D.BB88AD6A@iprg.nokia.com>
References: <Roam.SIMC.2.0.6.1003740874.29682.nordmark@bebop.france>
	<0bcf01c15e79$78a04e30$626015ac@DOCOMOALPER>
	<3BDA3D5D.BB88AD6A@iprg.nokia.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Charlie Perkins writes:
 > > With IPv6 and home address option, the packets from the malicious node look
 > > like they are from
 > > a legitimate node to all the routers along the path (same as in IPv4)  and
 > > when arrived at the
 > > correspondent node they reveal their true sender (this is new!).
 > 
 > It would be exactly like the packets came from the home network.... right?
 > And so that's exactly what we are trying to accomplish!

   There's nothing that currently prevents me from
   having a legitimate CoA and putting any home address
   I feel like in the home address option. Routers
   currently can prevent source spoofing by doing
   reverse path forwarding checks (RPF), but a RPF
   check on a spoofed HA option would be useless 
   since the access router does not have any clue
   about mobility with MIPv6, and thus cannot verify
   the legitimacy of the source spoofed HA option.

   Thus you get a new source spoofing attack which
   isn't easily defeated at the edges. Not Good.

		Mike


From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 28 17:08:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16326
	for <mobileip-archive@lists.ietf.org>; Sun, 28 Oct 2001 17:08:20 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13332;
	Sun, 28 Oct 2001 15:08:12 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10403;
	Sun, 28 Oct 2001 14:08:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SM6gQO000952
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 14:06:42 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9SM6gFc000951
	for mobile-ip-dist; Sun, 28 Oct 2001 14:06:42 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9SM6cQO000944
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 14:06:38 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21909
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 14:06:42 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03007
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 14:06:40 -0800 (PST)
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id f9SM6d524775;
	Mon, 29 Oct 2001 00:06:39 +0200
Date: Mon, 29 Oct 2001 00:06:38 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: <mobile-ip@sunroof.eng.sun.com>
cc: Alper Yegin <alper@docomolabs-usa.com>
Subject: Re: [mobile-ip] Last Call Comments on 
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
In-Reply-To: <15324.31687.893562.211060@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.33.0110290001270.24744-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Sun, 28 Oct 2001, Michael Thomas wrote:
> Charlie Perkins writes:
>  > > With IPv6 and home address option, the packets from the malicious node look
>  > > like they are from
>  > > a legitimate node to all the routers along the path (same as in IPv4)  and
>  > > when arrived at the
>  > > correspondent node they reveal their true sender (this is new!).
>  > 
>  > It would be exactly like the packets came from the home network.... right?
>  > And so that's exactly what we are trying to accomplish!
> 
>    There's nothing that currently prevents me from
>    having a legitimate CoA and putting any home address
>    I feel like in the home address option. Routers
>    currently can prevent source spoofing by doing
>    reverse path forwarding checks (RPF), but a RPF
>    check on a spoofed HA option would be useless 
>    since the access router does not have any clue
>    about mobility with MIPv6, and thus cannot verify
>    the legitimacy of the source spoofed HA option.
> 
>    Thus you get a new source spoofing attack which
>    isn't easily defeated at the edges. Not Good.

One common counter-argument here is that the real source address will be 
stored in the header anyway, so it wouldn't be a real, "complete" spoof.

As my rh-ha-security draft points out, this causes problems with at least 
following scenarios:

 1) the spoofer does not actually care all that much whether the real 
address is detected or not (example: sending udp exploits off a stolen 
brazilian dial-up account), but spoofing could still yield better results.

 2) there is no ingress filtering at all (all too common); this can be 
used to get around _destination site's_ ingress filtering checks!

 3) ingress filtering is not done at the first hop router, but e.g.  
site/ISP border, and then spoofing for the src address could be done so
that the real destination/source differ enough so that the real sender is
not traceable.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 28 21:33:28 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18080
	for <mobileip-archive@lists.ietf.org>; Sun, 28 Oct 2001 21:33:28 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03198;
	Sun, 28 Oct 2001 18:33:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01693;
	Sun, 28 Oct 2001 18:32:55 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T2VOQO001366
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 18:31:24 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9T2VO3j001365
	for mobile-ip-dist; Sun, 28 Oct 2001 18:31:24 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T2VKQO001358
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 18:31:20 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09013
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 18:31:22 -0800 (PST)
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25331
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 18:31:21 -0800 (PST)
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id LAA25145;
	Mon, 29 Oct 2001 11:31:05 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from nttmail3.ecl.ntt.co.jp
	by vcs3.rdh.ecl.ntt.co.jp (8.9.3/3.7W/20010920) with ESMTP id LAA05296;
	Mon, 29 Oct 2001 11:31:05 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from eclscan3.m.ecl.ntt.co.jp
	by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id LAA14979;
	Mon, 29 Oct 2001 11:30:59 +0900 (JST)
	(envelope-from ohnishi.hiroyuki@lab.ntt.co.jp)
Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id LAA17677;
	Mon, 29 Oct 2001 11:30:59 +0900 (JST)
Received: from ohnishi-gw.lab.ntt.co.jp
	by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id LAA21239;
	Mon, 29 Oct 2001 11:30:58 +0900 (JST)
Message-Id: <4.3.2-J.20011024122852.00bc2570@imd.m.ecl.ntt.co.jp>
X-Sender: ho005@imd.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J
Date: Mon, 29 Oct 2001 11:33:08 +0900
To: Michael Thomas <mat@cisco.com>
From: Hiroyuki OHNISHI <ohnishi.hiroyuki@lab.ntt.co.jp>
Subject: Re: [mobile-ip] Route optimization method in Mobile IP
Cc: mobile-ip@sunroof.eng.sun.com
In-Reply-To: <15316.16095.940510.716248@thomasm-u1.cisco.com>
References: <20011003210342.2A14.OHNISHI.HIROYUKI@lab.ntt.co.jp>
 <20011003210342.2A14.OHNISHI.HIROYUKI@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hello Mike,

Thank you for your reply.

At 08:44 01/10/22 -0700, Michael Thomas wrote:
>I have some questions about this draft:
>
>1) How is it appreciatively different than HMIP?
>    It sure seems to do similar things.

In HMIP, a hierarchical information is sent to MNs by agent advertisements.
This method is not good for the carrier because the network structure can be
known by users (I am not sure why WG's HMIP approach is not one like "Dynamics
HUT MIP".)
MBG method does not show such kind of informations to users.
Only MBG and HA knows each other and achieve route optimization.
And the MBG which is used to optimize routes depends on the route packets 
for MNs pass
through,


>2) How does the MN discover the MBG? This is one
>    of the things that last I checked wasn't one of
>    HMIP's strong points.

MN do not need to discover the MBG.

MBG have the information about MNs and HAs that the MNs belongs.
So if MBG detects the packets destined to a MN, MBG will send the binding request
to the HA that the MN belongs to.
Then HA send the binding update to MBG.

>3) The optimal placement of a MGB is at the join point
>    of a particular flow. If, for administrative reason say,
>    you can't put the MBG there, it's still better to put
>    the MGB as far along the path as possible. For all
>    but the simplest topologies, there may be many such
>    (close to) optimal points possible, and is clearly
>    dependent on the CN you are talking to at any time.
>    Have you considered this, or is this strictly static
>    the way that HMIP works?

I know there are better joint points to optimize the route.
As you mentioned, we can not put the MBG there.
But this method can optimize the route inside the network
surrounded by MBGs at least.
MBG works as same as flow driven shortcut. So we can use
the optimal one among them.

>4) Given the previous, MGB's at a peering point, say,
>    would end up proxying lots of MN's BU's. Can this
>    scale? This is similar to the soft state that RSVP
>    creates, and there's been a fair amount of concern
>    about the scaling which has lead to the RSVP aggregation
>    work. I expect that those same kinds of scaling
>    concerns would be relevant here too.

As you mentioned MBGs have to deal many MN' BUs.
But I think the MBG's processing is not so heavy as that of HAs located
at gateway point (such as 3GPP2 model).


>
>5) Related to 3 again, another of HMIP's
>    weaknesses is redundancy. It seems to me that
>    any scheme like this needs to be able to
>    provide failover which is lockstep with the
>    routing subsystem. That is, if the route
>    changes, the MN ought to be able to
>    transparently discover the new MBR in the
>    path and reestablish the binding.


If the route changes, another MBG will send the binding request
to the HA.  Then HA send the binding update to the MBG.
MN does not need to know the MBG.


Hiroyuki

>           Mike
>
>Hiroyuki OHNISHI writes:
>  > Hi all,
>  >
>  > We wrote a draft about a route optimization method in Mobile IP.
>  >
>  > http://search.ietf.org/internet-drafts/draft-ohnishi-mobileip-mbg-00.txt
>  >
>  > This method is proposed from the viewpoint of a career that will provide
>  > mobile ip services.
>  > To provide mobile ip services, we think route optimization is needed 
> to use network efficiently and reduce data transmission delay.
>  >
>  > But existing "Route optimization in Mobile IP" needs all the CNs 
> have to have Mobile IP functions and we have no control over all of the 
> CNs in the Internet. I know this problem can be solved if all CNs become 
> IPv6 nodes
>  > (if current problem will be solved).
>  > But we think it takes long time before all the CNs become the IPv6 nodes.
>  > So we need the some solution to achieve route optimization before 
> all the CNs have not been IPv6 nodes yet.
>  > And we also need route optimization method that does not tell CoA to 
> CNs directly for maintaining the location privacy.
>  >
>  > In our proposal, we introduce the new Mobile IP agents that are 
> located between a mobile ISP and other networks. This agent is called as 
> MBG (Mobile IP Border Gateway).
>  > MBG sends the Binding Requests to HA when it received the packets 
> for MNs. After receiving the Binding Updates from HA, it maintains a 
> binding cache and forwarded following packets directly to CoA of MNs by 
> using the binding caches.
>  > These MBGs are fully under the control of mobile ISPs and have 
> security asociations with HAs.
>  > So this solution does not suffer from SA issues. We have already had 
> a prototype and had tests.
>  > Our hope is to have some solution for route optimization that can be 
> deployed at early time and co-exist with the end-to-end route 
> optimization method for the future Mobile IPv6 deployment time.
>  >
>  > I am looking forward to having many comments about this approach for
>  > route optimization.
>  >
>  > Sincerely,
>  > Hiroyuki
>  >
>  >



From owner-mobile-ip@sunroof.eng.sun.com  Sun Oct 28 22:54:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20291
	for <mobileip-archive@odin.ietf.org>; Sun, 28 Oct 2001 22:54:18 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02445;
	Sun, 28 Oct 2001 20:53:55 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19666;
	Sun, 28 Oct 2001 19:53:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T3p4QO001574
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 19:51:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9T3p4OR001573
	for mobile-ip-dist; Sun, 28 Oct 2001 19:51:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T3p1QO001566
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 19:51:01 -0800 (PST)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06961
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 19:51:03 -0800 (PST)
Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00877
	for <mobile-ip@sunroof.eng.sun.com>; Sun, 28 Oct 2001 19:50:57 -0800 (PST)
Received: from thwack.its.monash.edu.au ([130.194.1.72])
 by vaxh.cc.monash.edu.au (PMDF V5.2-31 #29714)
 with ESMTP id <01KA2SCNS2OE8YH815@vaxh.cc.monash.edu.au> for
 mobile-ip@sunroof.eng.sun.com; Mon, 29 Oct 2001 14:49:50 +1100
Received: from localhost (localhost [127.0.0.1])	by thwack.its.monash.edu.au
 (Postfix) with ESMTP id B037C12C008	for <mobile-ip@sunroof.eng.sun.com>; Mon,
 29 Oct 2001 14:49:50 +1100 (EST)
Received: from eng.monash.edu.au
 (PC00004790.eng.monash.edu.au [130.194.137.189])	by thwack.its.monash.edu.au
 (Postfix) with ESMTP id 0812412C006	for <mobile-ip@sunroof.eng.sun.com>; Mon,
 29 Oct 2001 14:49:50 +1100 (EST)
Date: Mon, 29 Oct 2001 14:55:45 +1100
From: Greg Daley <greg.daley@eng.monash.edu.au>
Subject: Re: [mobile-ip] Route optimization method in Mobile IP
To: mobile-ip@sunroof.eng.sun.com
Message-id: <3BDCD341.714EEE19@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
X-Virus-Scanned: by AMaViS perl-11
References: <20011003210342.2A14.OHNISHI.HIROYUKI@lab.ntt.co.jp>
 <20011003210342.2A14.OHNISHI.HIROYUKI@lab.ntt.co.jp>
 <4.3.2-J.20011024122852.00bc2570@imd.m.ecl.ntt.co.jp>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7BIT

Response to Q1 below:


Hiroyuki OHNISHI wrote:
> 
> Hello Mike,
> 
> Thank you for your reply.
> 
> At 08:44 01/10/22 -0700, Michael Thomas wrote:
> >I have some questions about this draft:
> >
> >1) How is it appreciatively different than HMIP?
> >    It sure seems to do similar things.
> 
> In HMIP, a hierarchical information is sent to MNs by agent advertisements.
> This method is not good for the carrier because the network structure can be
> known by users (I am not sure why WG's HMIP approach is not one like "Dynamics
> HUT MIP".)
> MBG method does not show such kind of informations to users.
> Only MBG and HA knows each other and achieve route optimization.
> And the MBG which is used to optimize routes depends on the route packets
> for MNs pass
> through,

	In HMIPv6, propagation of network structure information is only
	through the distance metric of map options  "dynamically learned"
	through Router Advertisements.

	In the case where static MAP options are defined this is overridden,
	so no topological information needs be disclosed, and in the case
	where Router Renumbering is used the metrics advertised by the 
	Access routers are exactly as sent in the Original Router Renumbering
	message (regardless of the number of hops traversed).

	Therefore topology need not be disclosed.
	This is all part of HMIPv6.
	

		Greg Daley


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 02:33:20 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06747
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 02:33:19 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29822;
	Mon, 29 Oct 2001 00:32:04 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18878;
	Sun, 28 Oct 2001 23:32:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T7UwQO001885
	for <mobile-ip-dist@sunroof.eng.sun.com>; Sun, 28 Oct 2001 23:30:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9T7UvNS001884
	for mobile-ip-dist; Sun, 28 Oct 2001 23:30:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T7UpQO001869;
	Sun, 28 Oct 2001 23:30:51 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06986;
	Sun, 28 Oct 2001 23:30:41 -0800 (PST)
Received: from tiger.korea.ac.kr (tiger.korea.ac.kr [163.152.209.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12133;
	Sun, 28 Oct 2001 23:30:51 -0800 (PST)
Received: from LocalHost (ccl.korea.ac.kr [163.152.217.76])
	by tiger.korea.ac.kr (8.11.0/8.11.0) with SMTP id f9T7Rjs28412;
	Mon, 29 Oct 2001 16:27:45 +0900
From: "???" <kahng@tiger.korea.ac.kr>
To: "Shiao-Li Charles Tsao" <sltsao@itri.org.tw>,
        <mobile-ip@sunroof.eng.sun.com>
Cc: <ngtrans@sunroof.eng.sun.com>
Subject: RE: (ngtrans) Re: [mobile-ip] IPv4 and MIPv6 Transition
Date: Mon, 29 Oct 2001 16:26:32 +0900
Message-ID: <KPEGJCHEODAGGLGIDBIEGEIFCFAA.kahng@tiger.korea.ac.kr>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0093_01C16096.78B281D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <008101c15db5$69a688f0$3168608c@utopia>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0093_01C16096.78B281D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

QWxzbywgd2UgYXJlIHdvcmtpbmcgb24gdGhpcyBub3cuIA0KWW91IGNhbiBmaW5kIG91ciBwYXBl
ciwgd2hpY2ggd2lsbCBiZSBzZW50IHRvIElFVEYgYXMgYSBkYXJmdCBzb29uLg0KVGhlIHRpbGUg
aXMgInJlcXVpcmVtZW50cyBmb3IgNHRvNiBtb2JpbGl0eSB0cmFuc2l0aW9uIHVzaW5nIGhpZXJh
cmNoaWNhbCBtb2JpbGl0eS4iDQoNClVwIHRvIGRhdGUsIHNpbmNlIHRoZSBlZmZlY3RzIG9mIGNv
bnNpZGVyaW5nIG1vYmlsZSBub2RlIHJvYW1pbmcgaW4gSVB2NC9JUHY2IHRyYW5zaXRpb24gbmV0
d29ya3MgaGF2ZSBub3QgYmVlbiBpbnZlc3RpZ2F0ZWQgZnVsbHksIHdlIHByb3Bvc2UgdGhlIHJl
cXVpcmVtZW50cyBhbmQgYW5hbHlzaXMgb2YgZGlmZXJlbnQgcm91dGluZyBhcmNoaXRlY3R1cmUg
b2YgPElQdjQvTUlQdjYgdHJhbnNpdGlvbiBuZXR3b3JrLg0KDQpXZSBhcmUgd29ya2luZyBvbiB0
aGUgcHJvYmxlbSBzb2x2aW5nIG1lY2hhbmlzbSBhY2NvcmRpbmcgdG8gdGhlIHJlcXVpcmVtZW50
cy4NCg0KUGxlYXNlIHJlZmVyIHRvOg0KaHR0cDovL2hhcmQua29yZWEuYWMua3IvfmNjbC9yZXNl
YXJjaC9kcmFmdF9rYWhuZ19uZ3RyYW5zX2hkc21hLTAwLnR4dA0KDQoNCiAgLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCiAgRnJvbTogb3duZXItbmd0cmFuc0BzdW5yb29mLmVuZy5zdW4uY29t
IFttYWlsdG86b3duZXItbmd0cmFuc0BzdW5yb29mLmVuZy5zdW4uY29tXU9uIEJlaGFsZiBPZiBT
aGlhby1MaSBDaGFybGVzIFRzYW8NCiAgU2VudDogRnJpZGF5LCBPY3RvYmVyIDI2LCAyMDAxIDk6
MzAgQU0NCiAgVG86IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tDQogIENjOiBuZ3RyYW5z
QHN1bnJvb2YuZW5nLnN1bi5jb20NCiAgU3ViamVjdDogKG5ndHJhbnMpIFJlOiBbbW9iaWxlLWlw
XSBJUHY0IGFuZCBNSVB2NiBUcmFuc2l0aW9uDQoNCg0KICBIZWxsbywgDQoNCiAgVGhpcyBhcHBy
b2FjaCB3YXMgYWxzbyBhZGRyZXNzZWQgaW4gIk1vdmluZyBpbiBhIER1YWwgU3RhY2sgSW50ZXJu
ZXQiIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ndHJh
bnMtbW92aW5nLTAwLnR4dD4uIA0KICBJdCBpcyBhIFdHIGRyYWZ0IGluIE5HVFJBTlMuIEhvd2V2
ZXIsIHRoaXMgYXBwcm9hY2ggY2FuIGJlIG9ubHkgYXBwbGllZCB0byBhIE1OIHdpdGggYSBjby1s
b2NhdGVkIElQdjQgYWRkcmVzcyBpbiB0aGUgdmlzaXRlZCBJUHY0IG5ldHdvcmsuIFRvIHdvcmsg
d2l0aCBOQVQgYW5kIERIQ1AgaW4gdGhlIHZpc2l0ZWQgSVB2NCBuZXR3b3JrLCBpdCBzZWVtcyBh
IHByYXRpY2FsIHNjZW5hcmlvIGFuZCBzaG91bGQgYmUgZnVydGhlciBpbnZlc3RpZ2F0ZWQuIA0K
DQogIENoYXJsZXMgVHNhbw0KDQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAg
RnJvbTogIktBU1NJLUxBSExPVSBNb2hhbW1lZCBGVFJEL0RNSS9DQUUiIDxtb2hhbWVkLmthc3Np
bGFobG91QHJkLmZyYW5jZXRlbGVjb20uY29tPg0KICBUbzogPG1vYmlsZS1pcEBzdW5yb29mLmVu
Zy5zdW4uY29tPg0KICBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNSwgMjAwMSA3OjQxIFBNDQog
IFN1YmplY3Q6IFJFOiBbbW9iaWxlLWlwXSBJUHY0IGFuZCBNSVB2NiBUcmFuc2l0aW9uDQoNCg0K
ICBIZWxsbywNCg0KICBJZiB0aGUgTU4gYW5kIHRoZSBIQSBhcmUgZHVhbC1zdGFjaywgdGhlIHNv
bHV0aW9uIGNvdWxkIGJlIHRoZSBmb2xsb3dpbmc6DQogIE9uIHRoZSBob21lIG5ldHdvcmssIHRo
ZSBNTiByZWNlaXZlcyBhbiBJcHY2IFJBIHdpdGggdGhlIEggYml0IHNldCBhbmQgYW4NCiAgSXB2
NCBSQSB3aXRoIHRoZSBIIGJpdCBzZXQuDQogIFdoZW4gdGhlIE1OIGFycml2ZXMgb24gdGhlIHZp
c2l0ZWQgSXB2NCBuZXR3b3JrLCBpdCBhY3F1aXJlcyBhbiBJcHY0IENvQQ0KICAoY28tbG9jYXRl
ZCBDb0EpIGFuZCB0dW5uZWxzIElwdjYgQlUgaW4gSXB2NCBwYWNrZXRzIHRvIGl0cyBIQS4NCiAg
VGhlIEhBIGludGVyY2VwdHMgSXB2NiBwYWNrZXRzIGludGVuZGVkIGZvciB0aGUgTU4gYW5kIHR1
bm5lbHMgdGhlbSB0byB0aGUNCiAgTU4gaW4gSXB2NCBwYWNrZXRzLg0KICBUaGUgTU4gdHVubmVs
cyBJcHY2IHBhY2tldHMgaW50ZW5kZWQgZm9yIHRoZSBDTiBpbiBJcHY0IHBhY2tldHMgdG8gdGhl
IEhBLg0KICBUaGUgSEEgZGVjYXBzdWxhdGVzIHRoZSBwYWNrZXRzIGFuZCBzZW5kcyB0aGVtIGRp
cmVjdGx5IHRvIHRoZSBDTi4NCg0KICBUaGUgc2FtZSBzb2x1dGlvbiBjYW4gYmUgdXNlZCB3aGVu
IHRoZSBDTiBpcyBJcHY0IGFuZCB0aGUgdmlzaXRlZCBuZXR3b3JrIGlzDQogIElwdjYuDQoNCiAg
SSBkbyBub3Qga25vdyBhbnkgZGV2ZWxvcG1lbnRzIGFib3V0IHRoaXMgYnV0IGl0IGNvdWxkIGJl
IGEgbmV3IHdvcmsgaXRlbS4NCg0KICBLYXNzaQ0KDQogIC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt
LS0tLQ0KICBEZSA6IEVuZyBTb28gR3VhbiBbbWFpbHRvOmVuZ3NnQGN3Yy5udXMuZWR1LnNnXQ0K
ICBFbnZveekgOiBtZXJjcmVkaSAyNCBvY3RvYnJlIDIwMDEgMTE6MDcNCiAgwCA6IG1vYmlsZS1p
cEBzdW5yb29mLmVuZy5zdW4uY29tDQogIE9iamV0IDogUmU6IFttb2JpbGUtaXBdIElQdjQgYW5k
IE1JUHY2IFRyYW5zaXRpb24NCg0KDQogIFRoYW54IGZvciB5b3VyIHJlcGx5Lg0KDQogIEkgcmVh
ZCB0aGUgU0lUVCBhbmQgRFNUTSBkcmFmdC4gTXkgcXVlc3Rpb24gaXMgdGhhdCBNTiBpcyB1c2lu
ZyBEU1RNLiBCdXQNCiAgdGhlcmUgYXJlIHBvc3NpYmxlIGNhc2VzIHdoZXJlIE1OIGNhbm5vdCBv
YnRhaW4gYSAiSVB2NCBHbG9iYWwgQWRkcmVzc2VzIi4NCiAgQXMgc3VjaCwgdGhlIFNJVFQgYW5k
IERTVE0gc29sdXRpb24gaXMgbm90IHdoYXQgSSBhbSBsb29raW5nIGZvci4NCg0KICBJZiBhIE1O
IHZpc2l0cyBhIGZvcmVpZ24gSVB2NCBuZXR3b3JrIHJ1bm5pbmcgTkFUIGFuZCBESENQIChhbmQg
bm8gNnRvNCwNCiAgVHVubmVsIEJyb2tlciBvciA2b3ZlcjQgc3R1ZmYpLCBob3cgY2FuIHRoZSBN
TiBzZW5kcyBhIEJpbmRpbmcgVXBkYXRlIHRvIGl0cw0KICBIb21lIEFnZW50IGluIElQdjY/IENh
biB0aGUgTU4gdXNlcyBzb21lIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaXQgaGFzDQogIHdo
ZW4gaXQgd2FzIHByZXZpb3VzbHkgYXQgaG9tZSB0byBhY2Nlc3MgdGhlIDZCb25lPw0KDQogIFRo
ZSBiZXN0IGNhbmRpZGF0ZSBJIHNlZSBpdCBTaGlwd29ybS4gSSdtIHdvbmRlcmluZyBpZiBhbnlv
bmUgaGFzIGNvbWUNCiAgYWNyb3NzIG90aGVyIHByb3Bvc2Fscy4NCg0KICBTRw0KICBTb28gR3Vh
biwgRW5nDQogIFImRCBFbmdpbmVlciAoU29mdHdhcmUgTGFiKQ0KICBDZW50cmUgZm9yIFdpcmVs
ZXNzIENvbW11bmljYXRpb25zLCBOVVMNCiAgaHR0cDovL3d3dy5jd2MubnVzLmVkdS5zZw0KICBU
ZWwgKDY1KSA4NzA5MzMwDQogIH5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCiAgLS0tLS0g
T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICBGcm9tOiBIZXNoYW0gU29saW1hbiAoRVBBKQ0KICBU
bzogJ21vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tJw0KICBTZW50OiBXZWRuZXNkYXksIE9j
dG9iZXIgMjQsIDIwMDEgMzoxMiBQTQ0KICBTdWJqZWN0OiBSRTogW21vYmlsZS1pcF0gSVB2NCBh
bmQgTUlQdjYgVHJhbnNpdGlvbg0KDQoNCiAgSGVsbG8gRW5nLA0KICBUaGVyZSBpcyBhbm90aGVy
IGRyYWZ0IHlvdSBjYW4gZmluZCBhdDoNCiAgaHR0cDovL3N0YW5kYXJkcy5lcmljc3Nvbi5uZXQv
aGVzaGFtL2RyYWZ0LWlldGYtbmd0cmFucy1zaWl0LWRzdG0tMDAudHh0DQogIEl0J3MgYSBXRyBk
cmFmdCBpbiBOR1RSQU5TIGJ1dCBpdCBleHBpcmVkIGFuZCBJJ2xsDQogIHJlc3VibWl0IGl0IGFm
dGVyIGFkZGluZyBzb21lIG9mIHRoZSBjb21tZW50cyByZWNlaXZlZC4NCiAgQ2hlZXJzLA0KICBI
ZXNoYW0NCg0KDQogIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogIEZyb206ICAgRW5nIFNv
byBHdWFuIFtTTVRQOmVuZ3NnQGN3Yy5udXMuZWR1LnNnXQ0KICBTZW50OiAgIFdlZG5lc2RheSwg
MjQgT2N0b2JlciAyMDAxIDEyOjA0DQogIFRvOiAgICAgbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1
bi5jb20NCiAgU3ViamVjdDogICAgICAgIFttb2JpbGUtaXBdIElQdjQgYW5kIE1JUHY2IFRyYW5z
aXRpb24NCiAgRGVhciBBbGwsDQogIEkgd291bGQgbGlrZSB0byBrbm93IGlmIGFueSB3b3JrIGhh
cyBiZWluZyBkb25lIHdpdGggcmVnYXJkIHRvICd0cmFuc2l0aW5nJw0KICB0byBNb2JpbGUgSVB2
NiB3aXRoIElQdjQgSW50ZXJuZXQsIGVzcGVjaWFsbHkgd2l0aCBNb2JpbGUgTm9kZSBiZWhpbmcg
YSBOQVQuDQogIFRoZSBjbG9zZXQgZHJhZnRzIEkgZmluZCBhcmUgIk1vYmlsZSBJUHY0IFRyYXZl
cnNhbCBBY3Jvc3MgTkFUIGFuZCBWUE4NCiAgR2F0ZXdheXMiIGFuZCAiTW9iaWxpdHkgU3VwcG9y
dCBmb3IgSVB2NCBhbmQgSVB2NiBJbnRlcmNvbm5lY3RlZCBOZXR3b3Jrcw0KICBiYXNlZCBvbiBE
dWFsLVN0YWNrIE1vZGVsIi4NCiAgSSByZWFkIGZvdW5kIHRoZSBOR1RSQU5TIFNoaXB3b3JtIGRy
YWZ0IGF0dHJhY3RpdmUgdG8gYmUgbW9kaWZpZWQgZm9yIE1JUHY2DQogIGluIGEgSVB2NCBvbmx5
IG5ldHdvcmsgYmVoaW5kIGEgTkFULg0KICBXYXJtZXN0IHJlZ2FyZHMuDQogIFNHDQogIFNvbyBH
dWFuLCBFbmcNCiAgQ2VudHJlIGZvciBXaXJlbGVzcyBDb21tdW5pY2F0aW9ucywgTlVTDQogIGh0
dHA6Ly93d3cuY3djLm51cy5lZHUuc2cNCiAgfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fiAN
Cg==

------=_NextPart_000_0093_01C16096.78B281D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz
by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDUuMDAuMzMxNS4yODcwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE
Pg0KPEJPRFk+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7
IHNpemU9Mj48U1BBTiBjbGFzcz0wMTk0NzE2MDctMjkxMDIwMDE+QWxzbywgd2UgDQphcmUgd29y
a2luZyBvbiB0aGlzIG5vdy4gPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9
IzAwMDBmZiBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjxTUEFOIGNsYXNzPTAxOTQ3MTYw
Ny0yOTEwMjAwMT5Zb3UgY2FuIA0KZmluZCBvdXIgcGFwZXIsIHdoaWNoIHdpbGwgYmUgc2VudCB0
byBJRVRGIGFzIGEgZGFyZnQgc29vbi48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBj
b2xvcj0jMDAwMGZmIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PFNQQU4gY2xhc3M9MDE5
NDcxNjA3LTI5MTAyMDAxPlRoZSB0aWxlIA0KaXMgInJlcXVpcmVtZW50cyBmb3IgNHRvNiBtb2Jp
bGl0eSB0cmFuc2l0aW9uIHVzaW5nIGhpZXJhcmNoaWNhbCANCm1vYmlsaXR5LiI8L1NQQU4+PC9G
T05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIGNv
bG9yPSMwMDAwZmY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7PlVwJm5ic3A7PFNQQU4gDQpj
bGFzcz0wMTk0NzE2MDctMjkxMDIwMDE+dG88L1NQQU4+IGRhdGU8U1BBTiBjbGFzcz0wMTk0NzE2
MDctMjkxMDIwMDE+LCBzaW5jZSANCnRoZSZuYnNwOzwvU1BBTj48U1BBTiBjbGFzcz0wMTk0NzE2
MDctMjkxMDIwMDE+ZWZmZWN0cyBvZiBjb25zaWRlcmluZyBtb2JpbGUgDQpub2RlIHJvYW1pbmc8
L1NQQU4+Jm5ic3A7PFNQQU4gY2xhc3M9MDE5NDcxNjA3LTI5MTAyMDAxPmluIElQdjQvSVB2NiB0
cmFuc2l0aW9uIA0KbmV0d29ya3MgaGF2ZSBub3QgYmVlbiBpbnZlc3RpZ2F0ZWQgZnVsbHksIHdl
IHByb3Bvc2UgdGhlIHJlcXVpcmVtZW50cyBhbmQgDQphbmFseXNpcyBvZiBkaWZlcmVudCByb3V0
aW5nIGFyY2hpdGVjdHVyZSBvZiAmbHQ7SVB2NC9NSVB2NiB0cmFuc2l0aW9uIA0KbmV0d29yay48
L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAw
ZmYgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48U1BBTiANCmNsYXNzPTAxOTQ3MTYwNy0y
OTEwMjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw
MGZmIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PFNQQU4gY2xhc3M9MDE5NDcxNjA3LTI5
MTAyMDAxPldlIGFyZSANCndvcmtpbmcgb24gdGhlIHByb2JsZW0gc29sdmluZyBtZWNoYW5pc20g
YWNjb3JkaW5nIHRvIHRoZSANCnJlcXVpcmVtZW50cy48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PFNQQU4g
DQpjbGFzcz0wMTk0NzE2MDctMjkxMDIwMDE+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE
SVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjxTUEFO
IGNsYXNzPTAxOTQ3MTYwNy0yOTEwMjAwMT5QbGVhc2UgDQpyZWZlciB0bzo8QlI+PEEgDQpocmVm
PSJodHRwOi8vaGFyZC5rb3JlYS5hYy5rci9+Y2NsL3Jlc2VhcmNoL2RyYWZ0X2thaG5nX25ndHJh
bnNfaGRzbWEtMDAudHh0Ij5odHRwOi8vaGFyZC5rb3JlYS5hYy5rci9+Y2NsL3Jlc2VhcmNoL2Ry
YWZ0X2thaG5nX25ndHJhbnNfaGRzbWEtMDAudHh0PC9BPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8
RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9JiM0NDQwNDsm
IzQ3NTQ4OyBzaXplPTI+PFNQQU4gDQpjbGFzcz0wMTk0NzE2MDctMjkxMDIwMDE+PC9TUEFOPjwv
Rk9OVD4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFPg0KICA8RElWIGFsaWduPWxlZnQgY2xhc3M9
T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0cj48Rk9OVCBmYWNlPVRhaG9tYSANCiAgc2l6ZT0y
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiANCiAgb3duZXItbmd0
cmFuc0BzdW5yb29mLmVuZy5zdW4uY29tIA0KICBbbWFpbHRvOm93bmVyLW5ndHJhbnNAc3Vucm9v
Zi5lbmcuc3VuLmNvbV08Qj5PbiBCZWhhbGYgT2YgPC9CPlNoaWFvLUxpIENoYXJsZXMgDQogIFRz
YW88QlI+PEI+U2VudDo8L0I+IEZyaWRheSwgT2N0b2JlciAyNiwgMjAwMSA5OjMwIEFNPEJSPjxC
PlRvOjwvQj4gDQogIG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPEJSPjxCPkNjOjwvQj4g
DQogIG5ndHJhbnNAc3Vucm9vZi5lbmcuc3VuLmNvbTxCUj48Qj5TdWJqZWN0OjwvQj4gKG5ndHJh
bnMpIFJlOiBbbW9iaWxlLWlwXSBJUHY0IA0KICBhbmQgTUlQdjYgVHJhbnNpdGlvbjxCUj48QlI+
PC9ESVY+PC9GT05UPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5IZWxsbywgPC9G
T05UPjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJp
ZXIgTmV3Ij5UaGlzIGFwcHJvYWNoIHdhcyBhbHNvIGFkZHJlc3NlZCBpbiA8Rk9OVCANCiAgZmFj
ZT0iQ291cmllciBOZXciIHNpemU9Mj48U1RST05HPjxBIG5hbWU9TU9WSU5HPjwvQT4iTW92aW5n
IGluIGEgRHVhbCBTdGFjayANCiAgSW50ZXJuZXQiICZsdDs8QSANCiAgaHJlZj0iaHR0cDovL3d3
dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uZ3RyYW5zLW1vdmluZy0wMC50
eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmd0cmFu
cy1tb3ZpbmctMDAudHh0PC9BPiZndDsuIA0KICA8L1NUUk9ORz48L0ZPTlQ+PC9GT05UPjwvRElW
Pg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5JdCBpcyBhIFdHIGRyYWZ0IGluIE5H
VFJBTlMuIEhvd2V2ZXIsIHRoaXMgDQogIGFwcHJvYWNoIGNhbiBiZSBvbmx5IGFwcGxpZWQgdG8g
YSBNTiB3aXRoIGEgY28tbG9jYXRlZCBJUHY0IGFkZHJlc3MgaW4gdGhlIA0KICB2aXNpdGVkIElQ
djQgbmV0d29yay4gVG8gd29yayB3aXRoIE5BVCBhbmQgREhDUCBpbiB0aGUgdmlzaXRlZCBJUHY0
IG5ldHdvcmssIA0KICBpdCBzZWVtcyBhIHByYXRpY2FsIHNjZW5hcmlvIGFuZCBzaG91bGQgYmUg
ZnVydGhlciBpbnZlc3RpZ2F0ZWQuIDwvRk9OVD48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4N
CiAgPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Q2hhcmxlcyBUc2FvPC9GT05UPjwvRElW
Pg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05U
IGZhY2U9IkNvdXJpZXIgTmV3Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRk9OVD4N
CiAgPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+RnJvbTogIktBU1NJLUxBSExPVSBNb2hh
bW1lZCBGVFJEL0RNSS9DQUUiIA0KICAmbHQ7PC9GT05UPjxBIGhyZWY9Im1haWx0bzptb2hhbWVk
Lmthc3NpbGFobG91QHJkLmZyYW5jZXRlbGVjb20uY29tIj48Rk9OVCANCiAgZmFjZT0iQ291cmll
ciBOZXciPm1vaGFtZWQua2Fzc2lsYWhsb3VAcmQuZnJhbmNldGVsZWNvbS5jb208L0ZPTlQ+PC9B
PjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OzwvRk9OVD48L0RJVj4NCiAgPERJVj48
Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+VG86ICZsdDs8L0ZPTlQ+PEEgDQogIGhyZWY9Im1haWx0
bzptb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIg
TmV3Ij5tb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvRk9OVD48L0E+PEZPTlQgDQogIGZh
Y2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNv
dXJpZXIgTmV3Ij5TZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNSwgMjAwMSA3OjQxIA0KICBQTTwv
Rk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+U3ViamVjdDogUkU6
IFttb2JpbGUtaXBdIElQdjQgYW5kIE1JUHY2IA0KICBUcmFuc2l0aW9uPC9GT05UPjwvRElWPjwv
RElWPg0KICA8RElWPjxCUj48L0RJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+SGVsbG8sPEJS
PjxCUj5JZiB0aGUgTU4gYW5kIHRoZSBIQSBhcmUgDQogIGR1YWwtc3RhY2ssIHRoZSBzb2x1dGlv
biBjb3VsZCBiZSB0aGUgZm9sbG93aW5nOjxCUj5PbiB0aGUgaG9tZSBuZXR3b3JrLCB0aGUgDQog
IE1OIHJlY2VpdmVzIGFuIElwdjYgUkEgd2l0aCB0aGUgSCBiaXQgc2V0IGFuZCBhbjxCUj5JcHY0
IFJBIHdpdGggdGhlIEggYml0IA0KICBzZXQuPEJSPldoZW4gdGhlIE1OIGFycml2ZXMgb24gdGhl
IHZpc2l0ZWQgSXB2NCBuZXR3b3JrLCBpdCBhY3F1aXJlcyBhbiBJcHY0IA0KICBDb0E8QlI+KGNv
LWxvY2F0ZWQgQ29BKSBhbmQgdHVubmVscyBJcHY2IEJVIGluIElwdjQgcGFja2V0cyB0byBpdHMg
SEEuPEJSPlRoZSANCiAgSEEgaW50ZXJjZXB0cyBJcHY2IHBhY2tldHMgaW50ZW5kZWQgZm9yIHRo
ZSBNTiBhbmQgdHVubmVscyB0aGVtIHRvIHRoZTxCUj5NTiANCiAgaW4gSXB2NCBwYWNrZXRzLjxC
Uj5UaGUgTU4gdHVubmVscyBJcHY2IHBhY2tldHMgaW50ZW5kZWQgZm9yIHRoZSBDTiBpbiBJcHY0
IA0KICBwYWNrZXRzIHRvIHRoZSBIQS48QlI+VGhlIEhBIGRlY2Fwc3VsYXRlcyB0aGUgcGFja2V0
cyBhbmQgc2VuZHMgdGhlbSBkaXJlY3RseSANCiAgdG8gdGhlIENOLjxCUj48QlI+VGhlIHNhbWUg
c29sdXRpb24gY2FuIGJlIHVzZWQgd2hlbiB0aGUgQ04gaXMgSXB2NCBhbmQgdGhlIA0KICB2aXNp
dGVkIG5ldHdvcmsgaXM8QlI+SXB2Ni48QlI+PEJSPkkgZG8gbm90IGtub3cgYW55IGRldmVsb3Bt
ZW50cyBhYm91dCB0aGlzIA0KICBidXQgaXQgY291bGQgYmUgYSBuZXcgd29yayBpdGVtLjxCUj48
QlI+S2Fzc2k8QlI+PEJSPi0tLS0tTWVzc2FnZSANCiAgZCdvcmlnaW5lLS0tLS08QlI+RGUgOiBF
bmcgU29vIEd1YW4gWzwvRk9OVD48QSANCiAgaHJlZj0ibWFpbHRvOmVuZ3NnQGN3Yy5udXMuZWR1
LnNnIj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciPm1haWx0bzplbmdzZ0Bjd2MubnVzLmVk
dS5zZzwvRk9OVD48L0E+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij5dPEJSPkVudm956SA6
IG1lcmNyZWRpIDI0IG9jdG9icmUgMjAwMSAxMTowNzxCUj7AIDogDQogIDwvRk9OVD48QSBocmVm
PSJtYWlsdG86bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20iPjxGT05UIA0KICBmYWNlPSJD
b3VyaWVyIE5ldyI+bW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb208L0ZPTlQ+PC9BPjxCUj48
Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciPk9iamV0IDogUmU6IFttb2JpbGUtaXBdIElQdjQg
YW5kIE1JUHY2IA0KICBUcmFuc2l0aW9uPEJSPjxCUj48QlI+VGhhbnggZm9yIHlvdXIgcmVwbHku
PEJSPjxCUj5JIHJlYWQgdGhlIFNJVFQgYW5kIERTVE0gDQogIGRyYWZ0LiBNeSBxdWVzdGlvbiBp
cyB0aGF0IE1OIGlzIHVzaW5nIERTVE0uIEJ1dDxCUj50aGVyZSBhcmUgcG9zc2libGUgY2FzZXMg
DQogIHdoZXJlIE1OIGNhbm5vdCBvYnRhaW4gYSAiSVB2NCBHbG9iYWwgQWRkcmVzc2VzIi48QlI+
QXMgc3VjaCwgdGhlIFNJVFQgYW5kIA0KICBEU1RNIHNvbHV0aW9uIGlzIG5vdCB3aGF0IEkgYW0g
bG9va2luZyBmb3IuPEJSPjxCUj5JZiBhIE1OIHZpc2l0cyBhIGZvcmVpZ24gDQogIElQdjQgbmV0
d29yayBydW5uaW5nIE5BVCBhbmQgREhDUCAoYW5kIG5vIDZ0bzQsPEJSPlR1bm5lbCBCcm9rZXIg
b3IgNm92ZXI0IA0KICBzdHVmZiksIGhvdyBjYW4gdGhlIE1OIHNlbmRzIGEgQmluZGluZyBVcGRh
dGUgdG8gaXRzPEJSPkhvbWUgQWdlbnQgaW4gSVB2Nj8gDQogIENhbiB0aGUgTU4gdXNlcyBzb21l
IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaXQgaGFzPEJSPndoZW4gaXQgd2FzIA0KICBwcmV2
aW91c2x5IGF0IGhvbWUgdG8gYWNjZXNzIHRoZSA2Qm9uZT88QlI+PEJSPlRoZSBiZXN0IGNhbmRp
ZGF0ZSBJIHNlZSBpdCANCiAgU2hpcHdvcm0uIEknbSB3b25kZXJpbmcgaWYgYW55b25lIGhhcyBj
b21lPEJSPmFjcm9zcyBvdGhlciANCiAgcHJvcG9zYWxzLjxCUj48QlI+U0c8QlI+U29vIEd1YW4s
IEVuZzxCUj5SJmFtcDtEIEVuZ2luZWVyIChTb2Z0d2FyZSANCiAgTGFiKTxCUj5DZW50cmUgZm9y
IFdpcmVsZXNzIENvbW11bmljYXRpb25zLCBOVVM8QlI+PC9GT05UPjxBIA0KICBocmVmPSJodHRw
Oi8vd3d3LmN3Yy5udXMuZWR1LnNnIj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciPmh0dHA6
Ly93d3cuY3djLm51cy5lZHUuc2c8L0ZPTlQ+PC9BPjxCUj48Rk9OVCANCiAgZmFjZT0iQ291cmll
ciBOZXciPlRlbCAoNjUpIDg3MDkzMzA8QlI+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fjxC
Uj4tLS0tLSANCiAgT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxCUj5Gcm9tOiBIZXNoYW0gU29saW1h
biAoRVBBKTxCUj5UbzogPC9GT05UPjxBIA0KICBocmVmPSJtYWlsdG86J21vYmlsZS1pcEBzdW5y
b29mLmVuZy5zdW4uY29tJyI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij4nbW9iaWxlLWlw
QHN1bnJvb2YuZW5nLnN1bi5jb20nPC9GT05UPjwvQT48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJp
ZXIgTmV3Ij5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjQsIDIwMDEgMzoxMiBQTTxCUj5TdWJq
ZWN0OiBSRTogDQogIFttb2JpbGUtaXBdIElQdjQgYW5kIE1JUHY2IFRyYW5zaXRpb248QlI+PEJS
PjxCUj5IZWxsbyBFbmcsPEJSPlRoZXJlIGlzIA0KICBhbm90aGVyIGRyYWZ0IHlvdSBjYW4gZmlu
ZCBhdDo8QlI+PC9GT05UPjxBIA0KICBocmVmPSJodHRwOi8vc3RhbmRhcmRzLmVyaWNzc29uLm5l
dC9oZXNoYW0vZHJhZnQtaWV0Zi1uZ3RyYW5zLXNpaXQtZHN0bS0wMC50eHQiPjxGT05UIA0KICBm
YWNlPSJDb3VyaWVyIE5ldyI+aHR0cDovL3N0YW5kYXJkcy5lcmljc3Nvbi5uZXQvaGVzaGFtL2Ry
YWZ0LWlldGYtbmd0cmFucy1zaWl0LWRzdG0tMDAudHh0PC9GT05UPjwvQT48QlI+PEZPTlQgDQog
IGZhY2U9IkNvdXJpZXIgTmV3Ij5JdCdzIGEgV0cgZHJhZnQgaW4gTkdUUkFOUyBidXQgaXQgZXhw
aXJlZCBhbmQgDQogIEknbGw8QlI+cmVzdWJtaXQgaXQgYWZ0ZXIgYWRkaW5nIHNvbWUgb2YgdGhl
IGNvbW1lbnRzIA0KICByZWNlaXZlZC48QlI+Q2hlZXJzLDxCUj5IZXNoYW08QlI+PEJSPjxCUj4t
LS0tLU9yaWdpbmFsIA0KICBNZXNzYWdlLS0tLS08QlI+RnJvbTombmJzcDsmbmJzcDsgRW5nIFNv
byBHdWFuIFs8L0ZPTlQ+PEEgDQogIGhyZWY9Im1haWx0bzpTTVRQOmVuZ3NnQGN3Yy5udXMuZWR1
LnNnIj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciPlNNVFA6ZW5nc2dAY3djLm51cy5lZHUu
c2c8L0ZPTlQ+PC9BPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldyI+XTxCUj5TZW50OiZuYnNw
OyZuYnNwOyBXZWRuZXNkYXksIDI0IE9jdG9iZXIgMjAwMSANCiAgMTI6MDQ8QlI+VG86Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD48QSANCiAgaHJlZj0ibWFpbHRvOm1vYmlsZS1pcEBz
dW5yb29mLmVuZy5zdW4uY29tIj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciPm1vYmlsZS1p
cEBzdW5yb29mLmVuZy5zdW4uY29tPC9GT05UPjwvQT48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJp
ZXIgTmV3Ij5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyANCiAgW21vYmlsZS1pcF0gSVB2NCBhbmQgTUlQdjYgVHJhbnNpdGlvbjxCUj5EZWFyIEFsbCw8
QlI+SSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgDQogIGFueSB3b3JrIGhhcyBiZWluZyBkb25lIHdp
dGggcmVnYXJkIHRvICd0cmFuc2l0aW5nJzxCUj50byBNb2JpbGUgSVB2NiB3aXRoIA0KICBJUHY0
IEludGVybmV0LCBlc3BlY2lhbGx5IHdpdGggTW9iaWxlIE5vZGUgYmVoaW5nIGEgTkFULjxCUj5U
aGUgY2xvc2V0IGRyYWZ0cyANCiAgSSBmaW5kIGFyZSAiTW9iaWxlIElQdjQgVHJhdmVyc2FsIEFj
cm9zcyBOQVQgYW5kIFZQTjxCUj5HYXRld2F5cyIgYW5kIA0KICAiTW9iaWxpdHkgU3VwcG9ydCBm
b3IgSVB2NCBhbmQgSVB2NiBJbnRlcmNvbm5lY3RlZCBOZXR3b3JrczxCUj5iYXNlZCBvbiANCiAg
RHVhbC1TdGFjayBNb2RlbCIuPEJSPkkgcmVhZCBmb3VuZCB0aGUgTkdUUkFOUyBTaGlwd29ybSBk
cmFmdCBhdHRyYWN0aXZlIHRvIGJlIA0KICBtb2RpZmllZCBmb3IgTUlQdjY8QlI+aW4gYSBJUHY0
IG9ubHkgbmV0d29yayBiZWhpbmQgYSBOQVQuPEJSPldhcm1lc3QgDQogIHJlZ2FyZHMuPEJSPlNH
PEJSPlNvbyBHdWFuLCBFbmc8QlI+Q2VudHJlIGZvciBXaXJlbGVzcyBDb21tdW5pY2F0aW9ucywg
DQogIE5VUzxCUj48L0ZPTlQ+PEEgaHJlZj0iaHR0cDovL3d3dy5jd2MubnVzLmVkdS5zZyI+PEZP
TlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij5odHRwOi8vd3d3LmN3Yy5udXMuZWR1LnNnPC9GT05U
PjwvQT48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij5+fn5+fn5+fn5+fn5+fn5+fn5+
fn5+fn5+fn5+PC9GT05UPiANCjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0093_01C16096.78B281D0--



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 08:37:37 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11249
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 08:37:37 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10831;
	Mon, 29 Oct 2001 05:36:25 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24243;
	Mon, 29 Oct 2001 05:35:42 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TDYqQO002322
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 05:34:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TDYpUi002321
	for mobile-ip-dist; Mon, 29 Oct 2001 05:34:51 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TDYmQO002314
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 05:34:48 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07979
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 05:34:37 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09486
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 06:34:37 -0700 (MST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA16438 for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 06:34:48 -0700 (MST)]
Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA14919 for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 06:25:28 -0700 (MST)]
Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Mon, 29 Oct 2001 07:34:45 -0600
Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239])
	by thorgal.crm.mot.com (Postfix) with ESMTP
	id 0F5322ED48; Mon, 29 Oct 2001 14:29:26 +0100 (CET)
To: mobile-ip@sunroof.eng.sun.com
Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>, <Jari.Arkko@ericsson.com>
Subject: Re: [mobile-ip] Question on draft-arkko-mipv6-bu-security-00.txt
References: <Roam.SIMC.2.0.6.1003855373.12071.nordmark@bebop.france>
	<008101c15bfe$f4abb8c0$8a1b6e0a@arenanet.fi>
From: Alexandru Petrescu <petrescu@crm.mot.com>
Date: 29 Oct 2001 14:34:16 +0100
In-Reply-To: <008101c15bfe$f4abb8c0$8a1b6e0a@arenanet.fi>
Message-Id: <m3wv1eh8o7.fsf@test9.crm.mot.com>
Lines: 17
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

"Jari Arkko" <jari.arkko@kolumbus.fi> writes:
> As a side note, we'd also benefit from some terminology to replace 'weak
> authentication' with something that doesn't sound so negative...

Yes, the term "weak authentication" is at least misleading to me.  One
can have strong/weak algorithms, terms that traditionnally refer to
resisting brute-force, but not to routability or infrastructure.

I suppose that, at some of its origins, "weak authentication" was used
to refer to Unix login authentication, passwords being stored locally
and subject to traffic analysis.  Contrasted to "strong auth" that
would imply third-party hosts to authenticate.

Thus I would propose "weak auth"   - "infrastructure-free authentication"
                     "strong auth" - "infrastructure-based authentication".

Alex



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 09:29:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14785
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 09:29:39 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00279;
	Mon, 29 Oct 2001 06:28:23 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13646;
	Mon, 29 Oct 2001 06:27:57 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TEREQO002511
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 06:27:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TEREKi002510
	for mobile-ip-dist; Mon, 29 Oct 2001 06:27:14 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TERAQO002503
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 06:27:10 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13527
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 06:27:00 -0800 (PST)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25313
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 07:50:12 -0700 (MST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09Y00H>; Mon, 29 Oct 2001 09:26:12 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA9C@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject:  [mobile-ip] RFC2002:CORRECTION
Date: Mon, 29 Oct 2001 09:26:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hi,

	I wonder if there is a contradiction in RFC2002 in section 3.7.3.2. 

	In the first paragraph, it states: ".....If Code indicates the
registraton was denied by the home agent, the foreign agent MUST delete its
pending registration list entry, but not its visitor list entry ....."

However, in the last paragraph, it states: ".....if registration was
rejected by the home agent, the foreign agent deletes its visitor list
entry....."

It appears that these are conflicting statements, thus should be corrected.

I take it that the second statement is not correct, but the first one is
correct?

-Sharif.


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 11:33:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18864
	for <mobileip-archive@lists.ietf.org>; Mon, 29 Oct 2001 11:33:14 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09138;
	Mon, 29 Oct 2001 09:32:16 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00394;
	Mon, 29 Oct 2001 08:32:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGVHQO002723
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:31:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TGVGo6002722
	for mobile-ip-dist; Mon, 29 Oct 2001 08:31:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGVDQO002715
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:31:13 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17241
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:31:14 -0800 (PST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228] (may be forged))
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08210
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:55:07 -0700 (MST)
Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9TGVCj20937
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:31:12 -0800 (PST)
Message-ID: <002301c16097$63e8e4a0$2b6015ac@DOCOMOKEMPF>
From: "James kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <OFEF63CB64.BF48BF5C-ON88256AF2.00049538@boulder.ibm.com>
Subject: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt)
Date: Mon, 29 Oct 2001 08:33:07 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Alper and Venkata,

I think there may be an easy response to this. It requires 1) a secure L2 so
that a malicious MN can't set it's L2 address arbitrarially, and 2) that an
AR not route any packets from a MN that has not successfully done Neighbor
Discovery and for which the AR has a valid IP adress to L2 address binding
in its neighbor cache. If the link shares these two characteristics, then it
should not be possible for a malicious  MN to steal the address of a benign
MN because the AR won't route any packets from the malicious MN. The AR just
needs to check whether the source address corresponds to a legitimate
binding in the neighbor cache.

            jak

----- Original Message -----
From: "Venkata Jagana" <jagana@us.ibm.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Friday, October 26, 2001 5:29 PM
Subject: Re: [mobile-ip] Last Call Comments on
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
.txt


>
>
> Hello Alper,
>
> What a coincidence! I am little bit late in sending out the exactly
> similar thought that I have on this security hole and the corresponding
> enhancement.
>
> In fact, I believe, the malicious node don't even need to know the CoA
> of MN and the home address is more than sufficient for it to send a
> packet with arbitrary src address in the packet to CN. As per
> the current MIpv6 draft, CN  would have to simply replace the 'src'
> address of IPv6 packet by the home address in the home address option
> in the incoming packet without any further validations and this is a
> problem.
>
> The solution, that I have in my mind, can be simply to look at the
> CN's binding cache upon receipt of incoming packet and validate that
> 'src and home address' of the packet matches with CN's CoA <-> Home
> Address binding before accepting it for further processing. In fact, this
> binding cache is already consulted for outgoing packets and it needs
> to be done for incoming packets as well in order to address this
> security concern and so, this may not be a real overhead since it is
> a simple lookup. However, this solution may not really work well in
> case where the malicious node somehow steals both CoA and Home address
> of MN and I guess that's always an issue anyway.
>
>
> Thanks,
> Venkat
>
> ----------------------------------------------------------------
> Venkata R Jagana
> IBM Linux Technology Centre, Beaverton
> jagana@us.ibm.com
> Tel: (503) 578 3430 T/L 775-3430
>
>
> "Alper Yegin" <alper@docomolabs-usa.com>@sunroof.eng.sun.com on 10/26/2001
> 04:53:55 PM
>
> Please respond to mobile-ip@sunroof.eng.sun.com
>
> Sent by:  owner-mobile-ip@sunroof.eng.sun.com
>
>
> To:   <mobile-ip@sunroof.eng.sun.com>
> cc:
> Subject:  Re: [mobile-ip] Last Call Comments on
>
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
.txt
>
>
> Hello,
>
> I know I'm late for the last call. But nevertheless I'd like to identify a
> new security issue
> with Mobile IPv6. Please take a look at this and comment....
>
> Home address option of Mobile IPv6 gives the flexibility to use any IP
> address as the source
> address of a packet and send it to a receipent (a correspondent node). And
> the correspondent
> node should be able to process home address option to figure out the true
> end point of this
> communication. By using this option, a node can use any arbitrary IP
> address
> as the source
> address of outgoing packets, and be able to maintain end2end connection
> with
> a peer.
>
> This can be exploited by malicious nodes to impersonate other nodes, as
far
> as the routers
> along the path are concerned.
>
> Any mechanism that relies on the source IP address of a packet can be
> fooled
> by using an
> acceptable source IP address (like one borrowed from a legitimate node)
and
> carrying the
> real source address in the home address option.
>
> For example, a flow is (or proposed to be?) identified by the source
> address
> and the flow
> info of an IPv6 packet. If the malicious node can learn these two fields
of
> a legitimate packet, it can
> start using them in its own packets. Therefore stealing QoS established
for
> another device (along
> the common path).
>
> So, why do we think there's something new here. Afterall, even with IPv4,
a
> device can steal
> some other device's IP address and use it. But.... if it does so, the
> correspondent node would
> think that this packet is coming from the legitimate device, therefore any
> correspondence will
> be directed at the legitimate device. And hence, malicious node cannot
> enjoy
> a end2end
> communication.
>
> With IPv6 and home address option, the packets from the malicious node
look
> like they are from
> a legitimate node to all the routers along the path (same as in IPv4)  and
> when arrived at the
> correspondent node they reveal their true sender (this is new!).
>
> A correspondent node receiving such packets won't know what's going on.
And
> nothing special
> on correspondent node is expected for this to work (except a correct
> implementation of home
> address option processing :)
>
> First solution that comes to mind would be to expect protocols to check
for
> home address
> option in addition to source address, but that is not desirable as it is
> costly.
>
> What do people think about this issue?
>
> (I might not be able to follow rest of the discussion for a week. I'll be
> out of town. But I'm sending
> this now, so that the discussion is not delayed).
>
> alper
> NTT DoCoMo USA Labs
>
>
>
>
>
>
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 11:45:02 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19232
	for <mobileip-archive@lists.ietf.org>; Mon, 29 Oct 2001 11:45:02 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23487;
	Mon, 29 Oct 2001 09:44:17 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02719;
	Mon, 29 Oct 2001 08:44:12 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGhHQO002800
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:43:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TGhHa4002799
	for mobile-ip-dist; Mon, 29 Oct 2001 08:43:17 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGhDQO002792
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:43:13 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02539
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:43:15 -0800 (PST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16210
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:07:07 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9TGf2913846
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:41:04 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE78891;
	Mon, 29 Oct 2001 08:42:35 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12337; Mon, 29 Oct 2001 08:43:11 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15325.34591.223887.492446@thomasm-u1.cisco.com>
Date: Mon, 29 Oct 2001 08:43:11 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt)
In-Reply-To: <002301c16097$63e8e4a0$2b6015ac@DOCOMOKEMPF>
References: <OFEF63CB64.BF48BF5C-ON88256AF2.00049538@boulder.ibm.com>
	<002301c16097$63e8e4a0$2b6015ac@DOCOMOKEMPF>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

James kempf writes:
 > Alper and Venkata,
 > 
 > I think there may be an easy response to this. It requires 1) a secure L2 so
 > that a malicious MN can't set it's L2 address arbitrarially, and 2) that an
 > AR not route any packets from a MN that has not successfully done Neighbor
 > Discovery and for which the AR has a valid IP adress to L2 address binding
 > in its neighbor cache. If the link shares these two characteristics, then it
 > should not be possible for a malicious  MN to steal the address of a benign
 > MN because the AR won't route any packets from the malicious MN. The AR just
 > needs to check whether the source address corresponds to a legitimate
 > binding in the neighbor cache.

   The AR only knows about its own prefixes, not
   the HA's prefixes. Unless there is some way for
   the HA to populate the AR with legitimate MN
   bindings of its home address, the AR will be
   clueless about this. In MIPv6, there is, in
   fact, no AR->HA communication so this is even
   more problematic.

	Mike


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 11:52:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19503
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 11:52:14 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02665;
	Mon, 29 Oct 2001 09:51:25 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04414;
	Mon, 29 Oct 2001 08:51:27 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGohQO002901
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:50:43 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TGohSC002900
	for mobile-ip-dist; Mon, 29 Oct 2001 08:50:43 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TGodQO002893
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:50:40 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06935
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:50:24 -0800 (PST)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18123
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 08:50:36 -0800 (PST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA26488 for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:41:38 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA08708 for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:41:12 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52)
	id <4K0BWKRK>; Mon, 29 Oct 2001 10:50:30 -0600
Message-ID: <A5B4C9A2AD89D411AB3E009027B0DA1E0396C1B6@IL27EXM09.cig.mot.com>
From: Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] Improving BETH: chain tunneling
Date: Mon, 29 Oct 2001 10:50:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

Hello Purandi:
Please find my inline comments/question.
I may provide more comments after 
thoroughly studying your proposal. 
regards,
ajoy 


-----Original Message-----
From: Purnadi Rene (NRC/Dallas) [mailto:rene.purnadi@nokia.com]
Sent: Friday, October 26, 2001 4:18 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Improving BETH: chain tunneling


Hi James,

Thanks for your comment on our proposal. My comments are embedded. Sorry
for the late reply since I was travelling and then I was swamped with
other things


Rene Purnadi
Phone: +1 972.894.4897
e-mail: rene.purnadi@nokia.com


-----Original Message-----
From: ext James Kempf [mailto:James.Kempf@sun.com]
Sent: Friday, October 12, 2001 5:49 PM
To: mobile-ip@sunroof.eng.sun.com
Cc: kempf42@yahoo.com
Subject: Re: [mobile-ip] Improving BETH: chain tunneling


Purnadi,

Comments embedded.

>Current BETH:
> 
>According to draft-kempf-beth-ipv6-02.txt, in the model for the
"handoff
>to third" a new BET tunnel is established from the anchor AR (aAR) to
>the new AR (nAR). Since the MN may maintain the BET tunnels for a
while,
>there may be some issues related to QoS. In fact, in order to guarantee
>that the BET tunnel supports the QoS needed by the MN, we need to
either
>assume that an SLA is in place between the oAR and nAR or that
>"pre-defined" QoS is allocated between the oAR and the nAR. However,
>since it is not possible to foresee a-priori where the MN is going to
>handoff to and since the BET tunnels will be established not only
>between "adjacent" routers but also between non-adjacent routers (HTT
>case), the adoption of SLAs or pre-defined QoS in order to guarantee
the
>QoS for the MN over the tunnel does not scale well. 

Can you explain why this is any different than standard MIPv6?

Rene>> The MIPv6 does not have the QoS establishment procedure, and the
QoS negotiation happens separately. For a new route or tunnel
establishment, you need to ensure the QoS consistency. This means
additional QoS signaling and the delay associated with signaling and
establishment. This may not be suitable for time critical handoff
procedure. I hope I have answered based upon the correct understanding
of your question.


>As an alternative,
>at the BET establishment a QoS negotiation can take place to ensure the
>QoS for the tunnel will be supported. However, such QoS negotiation may
>in some situations introduce some latency.
>
>		       new tunnel
>       || ==============================================||
>       ||                                               ||
>  +-------+                  +-------+               +-------+
>  |       |    old tunnel    |       |               |       |
>  |  aAR  | ================ | oAR   |               |  nAR  |
>  |       |                  |       |               |       |
>  +-------+                  +-------+               +-------+
>
>            Original BETH procedure
>
>  +-------+                  +-------+                +-------+
>  |       |    old tunnel    |       |  new tunnel    |       |
>  | aAR   | ================ | oAR   | ===============|  nAR  |
>  |       |                  |       |                |       |
>  +-------+                  +-------+                +-------+
>
>            Proposed Beth enhancement
>
>Proposed enhancement:
> 
>We propose that the BETH model should accommodate the option of "chain
>tunneling" where, in case of handoff to third, the oAR creates a new
>tunnel to the nAR. The procedure to establish the new BET tunnel from
>oAR to the nAR is  the same as the procedure to establish the initial
>tunnel from the aAR to the oAR. 
>

The difficulty with this proposal is that it introduces the possibility
of routing loops if the MN moves back to aAR. Can you explain how you
would 
avoid that, short of forcing the MN to always establish
a nCoA on nAR?

Rene>> There will not be any routing loops.  One way to do this is, the
aAR can determine that the MN has still CoA from aAR (IP Address Option
containing MN's old Care of Address) and it has established a tunnel to
oAR. It either responds normally to the HRqst with HRply to nAR, but
soon after L2-UP happens at the aAR, it tears down both tunnels to oAR
and nAR/aAR, or it won't create the second tunnel to the oAR and soon
after L2-UP happens at the aAR, it tears down the tunnel to oAR.  There
is no need for tunnel and for nCoA. However, if the MN is in the process
of getting a nCoA then the either the oAR or the nAR (depending on who
sent PrRtAdv) shall keep the tunnel up and change the anchor point.

ajoy-> I think chained approach introduces additional single point 
of failure in the system which may not be a good idea. The chaining 
will also add extra end-to-end delay due to queuing and processing
delay at the chained nodes. 

>Reason:
>
>Different domains will manage traffic and QoS according to specific
>mechanisms and policies. Some networks may prefer to support QoS for
BET
>tunnels by pre-allocating QoS between physically adjacent routers, i.e.
>router to which the MN can move in "one step" due to handoff. Given a
>router, the number of physically adjacent routers is limited, and the
>amount of QoS "pre-allocated" can be determined, e.g. for cellular
>links, based on the amount of radio links that can be accepted in a
cell
>as handoff links (this is already being done in cellular networks, thus
>there is no impact on L2). The use of chain tunnels and pre-allocated
>QoS is a scalable solution that allows for fast handoffs and guaranteed
>QoS with minimal network configuration.
>
>Result:
>
>Creating long tunnel chains may have issues, e.g. many routers in the
>chain need to maintain the state. The chaining issues, however, can be
>reduced by forcing the MN to obtain a new COA every time it does a BETH
>Handoff. 

This issue comes up all the time, and I am curious why. People
seem to have difficulty with the concept of removing all
IP signalling so that you just have the bare minimum latency. Basically,
any introducion of MIP signalling on handover is going to result
in a disruption of the real time traffic on handover on low
speed links, period. The whole point of BETH is to let the MN decide
when to 
perform handover, or have the network force handover if its required.

Rene>>  the idea is that we force the MN to get a nCoA only after the
BET is established and the MN has moved at L2 so that the time critical
L2 handoff can be conducted without interruption. This may happen
immediately or later according to the policies of the AR. In fact, in
case of low speed channels you need already to optimize the way you send
signaling over traffic channels for several reasons. Here, you can
safely assume that the MIP signaling is distributed in such a way that
it has the minimal impact on the quality of the real time service. In
addition, the signaling may be transmitted over the dedicated signaling
channel in cdma2000/UMTS. 

ajoy->Could you please provide me additional information about how Mobile/IP

message can be mapped over cdma2000 dedicated channels? I am not aware of
any
such standard, but I would like to know. My understanding is that cdma2000 
RLP does not support any quality of service and RLP treats all the traffic
received for a Mobile Node as octet stream. 

In any case, it is desirable from the network point of view that the
traffic path is optimized by removing the tunnel as and when determined
by the network.  Hence the network must be able to force the MN to do
new CoA formation.

ajoy-> How much optimization we are talking about ? I guess in typical 
well engineered network, you may not really get substantial 
benefit by optimizing this route. Anyway in case of BETH, network 
can force the Mobile Node to acquire new care of address, hence
this optimization can be obtained.  

>The proposed chain tunneling plus the network ability to force
>the MN to obtain nCoA and to move to the nAR, solve the issue related
to
>chain tunneling. For fast moving MN, a new BETH handoff may take place
>before the MN has created nCoA and moved to the nAR,thus multiple
>tunnels may exist at the same time. However, multiple tunnels are only
>temporary.
>
>

The network is *always* in a position to force handover. If an AR 
requires that the MN establish a nCoA to force QoS negotiation
or for any other reason, it can send an unsolicited Router Advert
and the MN must perform the handover.

Rene>> But our understanding is that if MN has L3 connectivity with oCoA
, it does not need to compute a new CoA with just an unsolicited RtAdv.
Hence, we support an explicit command like PrRtAdv or other.   We both
agree that the network is in control of "forcing" the MN when it wants
as per the local policy of the AR .  But it was not clear from the list
of events provided in the section 2.5 of BETH draft.  It would clarify
to add this event to avoid the confusion.


		jak


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 12:16:59 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20443
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 12:16:59 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01642;
	Mon, 29 Oct 2001 10:16:07 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10883;
	Mon, 29 Oct 2001 09:16:09 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9THEqQO003067
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:14:52 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9THEqfg003066
	for mobile-ip-dist; Mon, 29 Oct 2001 09:14:52 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9THEmQO003059
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:14:48 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10564
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:14:50 -0800 (PST)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228] (may be forged))
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03527
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:14:50 -0800 (PST)
Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9THEoj22466
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:14:50 -0800 (PST)
Message-ID: <009f01c1609d$7bd7b270$2b6015ac@DOCOMOKEMPF>
From: "James kempf" <kempf@docomolabs-usa.com>
To: <mobile-ip@sunroof.eng.sun.com>
References: <OFEF63CB64.BF48BF5C-ON88256AF2.00049538@boulder.ibm.com><002301c16097$63e8e4a0$2b6015ac@DOCOMOKEMPF> <15325.34591.223887.492446@thomasm-u1.cisco.com>
Subject: Re: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt)
Date: Mon, 29 Oct 2001 09:16:44 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Mike,

By "done Neighbor Discovery" I was meaning Neighbor Discovery
for the CoA, which should be controlled by the access router.
Would that be sufficient?

            jak

----- Original Message -----
From: "Michael Thomas" <mat@cisco.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Monday, October 29, 2001 8:43 AM
Subject: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments
on
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
.txt)


> James kempf writes:
>  > Alper and Venkata,
>  >
>  > I think there may be an easy response to this. It requires 1) a secure
L2 so
>  > that a malicious MN can't set it's L2 address arbitrarially, and 2)
that an
>  > AR not route any packets from a MN that has not successfully done
Neighbor
>  > Discovery and for which the AR has a valid IP adress to L2 address
binding
>  > in its neighbor cache. If the link shares these two characteristics,
then it
>  > should not be possible for a malicious  MN to steal the address of a
benign
>  > MN because the AR won't route any packets from the malicious MN. The AR
just
>  > needs to check whether the source address corresponds to a legitimate
>  > binding in the neighbor cache.
>
>    The AR only knows about its own prefixes, not
>    the HA's prefixes. Unless there is some way for
>    the HA to populate the AR with legitimate MN
>    bindings of its home address, the AR will be
>    clueless about this. In MIPv6, there is, in
>    fact, no AR->HA communication so this is even
>    more problematic.
>
> Mike
>



From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 12:26:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20811
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 12:26:29 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22099;
	Mon, 29 Oct 2001 09:25:40 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13383;
	Mon, 29 Oct 2001 09:23:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9THN5QO003142
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:23:05 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9THN55F003141
	for mobile-ip-dist; Mon, 29 Oct 2001 09:23:05 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9THN1QO003134
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:23:01 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15126
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:22:51 -0800 (PST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08824
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:22:50 -0700 (MST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9THN2e12294
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 09:23:02 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAE79739;
	Mon, 29 Oct 2001 09:22:25 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12345; Mon, 29 Oct 2001 09:23:01 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15325.36981.7458.474458@thomasm-u1.cisco.com>
Date: Mon, 29 Oct 2001 09:23:01 -0800 (PST)
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt)
In-Reply-To: <009f01c1609d$7bd7b270$2b6015ac@DOCOMOKEMPF>
References: <OFEF63CB64.BF48BF5C-ON88256AF2.00049538@boulder.ibm.com>
	<002301c16097$63e8e4a0$2b6015ac@DOCOMOKEMPF>
	<15325.34591.223887.492446@thomasm-u1.cisco.com>
	<009f01c1609d$7bd7b270$2b6015ac@DOCOMOKEMPF>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

James kempf writes:
 > Mike,
 > 
 > By "done Neighbor Discovery" I was meaning Neighbor Discovery
 > for the CoA, which should be controlled by the access router.
 > Would that be sufficient?

   It would be sufficient to do ingress filtering on the
   CoA, which is not the same thing as doing ingress filtering
   on the home address option. The latter was the subject
   of this thread, right? The home address option was
   specifically created so that the source address would
   look topologically correct so that it would pass
   ingress filtering. It appears that it just moves the
   problem around though, which shouldn't be too surprising.

		  Mike

 > 
 >             jak
 > 
 > ----- Original Message -----
 > From: "Michael Thomas" <mat@cisco.com>
 > To: <mobile-ip@sunroof.eng.sun.com>
 > Sent: Monday, October 29, 2001 8:43 AM
 > Subject: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments
 > on
 > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
 > .txt)
 > 
 > 
 > > James kempf writes:
 > >  > Alper and Venkata,
 > >  >
 > >  > I think there may be an easy response to this. It requires 1) a secure
 > L2 so
 > >  > that a malicious MN can't set it's L2 address arbitrarially, and 2)
 > that an
 > >  > AR not route any packets from a MN that has not successfully done
 > Neighbor
 > >  > Discovery and for which the AR has a valid IP adress to L2 address
 > binding
 > >  > in its neighbor cache. If the link shares these two characteristics,
 > then it
 > >  > should not be possible for a malicious  MN to steal the address of a
 > benign
 > >  > MN because the AR won't route any packets from the malicious MN. The AR
 > just
 > >  > needs to check whether the source address corresponds to a legitimate
 > >  > binding in the neighbor cache.
 > >
 > >    The AR only knows about its own prefixes, not
 > >    the HA's prefixes. Unless there is some way for
 > >    the HA to populate the AR with legitimate MN
 > >    bindings of its home address, the AR will be
 > >    clueless about this. In MIPv6, there is, in
 > >    fact, no AR->HA communication so this is even
 > >    more problematic.
 > >
 > > Mike
 > >
 > 


From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 13:16:27 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22481
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 13:16:26 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06798;
	Mon, 29 Oct 2001 11:15:17 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29531;
	Mon, 29 Oct 2001 10:14:47 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TIDwQO003496
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:13:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TIDwAD003495
	for mobile-ip-dist; Mon, 29 Oct 2001 10:13:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TIDtQO003488
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:13:55 -0800 (PST)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13370
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:13:57 -0800 (PST)
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23956
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:13:56 -0800 (PST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA44854
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 13:11:21 -0500
Received: from d03nm036.boulder.ibm.com (d03nm036.boulder.ibm.com [9.99.140.36])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9TICbN47870
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 11:12:37 -0700
From: "Venkata Jagana" <jagana@us.ibm.com>
Importance: Normal
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: mobile-ip@sunroof.eng.sun.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF3E1D74A4.FF4B1ECB-ON88256AF4.00624287@boulder.ibm.com>
Date: Mon, 29 Oct 2001 10:12:20 -0800
X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 10/29/2001 11:12:36 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>



Hello Jari,

>> The solution, that I have in my mind, can be simply to look at the
>> CN's binding cache upon receipt of incoming packet and validate that
>> 'src and home address' of the packet matches with CN's CoA <-> Home
>> Address binding before accepting it for further processing. In fact,
this

>If you did this, wouldn't it mean that Route Optimization is mandatory to
use
>in all Mobile IPv6 communications? This would be a big change.

When home address option is used, does't it mean that it is already using
route optimization. Not sure though, whether home address option is used
in cases other than route optimization.

>Also,how would the first BU packet get validated by this rule?!

Either stand-alone first (or subsequent) BU's or BU's included in the
data packets are authenticated and so, I guess this rule is not an
issue at all. The problem comes for the unathenticated data packets
containing the home address option and this solution should solve
this problem.

Thanks,
Venkat

----------------------------------------------------------------
Venkata R Jagana
IBM Linux Technology Centre, Beaverton
jagana@us.ibm.com
Tel: (503) 578 3430 T/L 775-3430




From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 13:23:16 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22691
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 13:23:16 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15466;
	Mon, 29 Oct 2001 11:22:16 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15508;
	Mon, 29 Oct 2001 10:21:56 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TIKwQO003583
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:20:58 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TIKvFS003582
	for mobile-ip-dist; Mon, 29 Oct 2001 10:20:57 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TIKrQO003572
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:20:53 -0800 (PST)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01715
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:20:43 -0800 (PST)
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28602
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 10:20:54 -0800 (PST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA85932;
	Mon, 29 Oct 2001 13:18:04 -0500
Received: from d03nm036.boulder.ibm.com (d03nm036.boulder.ibm.com [9.99.140.36])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9TIJJN66154;
	Mon, 29 Oct 2001 11:19:19 -0700
From: "Venkata Jagana" <jagana@us.ibm.com>
Importance: Normal
Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt
To: Pekka Savola <pekkas@netcore.fi>
Cc: <mobile-ip@sunroof.eng.sun.com>, Alper Yegin <alper@docomolabs-usa.com>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF404F6C5E.6C44B720-ON88256AF4.00645F7B@boulder.ibm.com>
Date: Mon, 29 Oct 2001 10:19:04 -0800
X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 10/29/2001 11:19:19 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>


Hello Pekka,

> AFAICS, most of theses issues were brought up and discussed somewhat
> during the last two weeks.  Some description of the problem is at:

>
http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

Thanks. I would look into this draft and let you know if I have
any comments.

Thanks,
Venkat

----------------------------------------------------------------
Venkata R Jagana
IBM Linux Technology Centre, Beaverton
jagana@us.ibm.com
Tel: (503) 578 3430 T/L 775-3430


Pekka Savola <pekkas@netcore.fi> on 10/26/2001 10:15:33 PM

To:   <mobile-ip@sunroof.eng.sun.com>
cc:   Alper Yegin <alper@docomolabs-usa.com>, Venkata
      Jagana/Beaverton/IBM@IBMUS
Subject:  Re: [mobile-ip] Last Call Comments on
      http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt


On Fri, 26 Oct 2001, Venkata Jagana wrote:
> What a coincidence! I am little bit late in sending out the exactly
> similar thought that I have on this security hole and the corresponding
> enhancement.
>
> In fact, I believe, the malicious node don't even need to know the CoA
> of MN and the home address is more than sufficient for it to send a
> packet with arbitrary src address in the packet to CN. As per
> the current MIpv6 draft, CN  would have to simply replace the 'src'
> address of IPv6 packet by the home address in the home address option
> in the incoming packet without any further validations and this is a
> problem.
>
> The solution, that I have in my mind, can be simply to look at the
> CN's binding cache upon receipt of incoming packet and validate that
> 'src and home address' of the packet matches with CN's CoA <-> Home
> Address binding before accepting it for further processing. In fact, this
> binding cache is already consulted for outgoing packets and it needs
> to be done for incoming packets as well in order to address this
> security concern and so, this may not be a real overhead since it is
> a simple lookup. However, this solution may not really work well in
> case where the malicious node somehow steals both CoA and Home address
> of MN and I guess that's always an issue anyway.

AFAICS, most of theses issues were brought up and discussed somewhat
during the last two weeks.  Some description of the problem is at:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

--
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords











From owner-mobile-ip@sunroof.eng.sun.com  Mon Oct 29 15:04:15 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25602
	for <mobileip-archive@odin.ietf.org>; Mon, 29 Oct 2001 15:04:15 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23296;
	Mon, 29 Oct 2001 13:03:29 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15458;
	Mon, 29 Oct 2001 12:03:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TK2SQO003819
	for <mobile-ip-dist@sunroof.eng.sun.com>; Mon, 29 Oct 2001 12:02:29 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TK2SmF003818
	for mobile-ip-dist; Mon, 29 Oct 2001 12:02:28 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TK2PQO003811
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 12:02:25 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26762
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 12:02:26 -0800 (PST)
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22254
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 13:02:13 -0700 (MST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA59876
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 14:59:51 -0500
Received: from d03nm036.boulder.ibm.com (d03nm036.boulder.ibm.com [9.99.140.36])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9TK16p238280
	for <mobile-ip@sunroof.eng.sun.com>; Mon, 29 Oct 2001 13:01:06 -0700
From: "Venkata Jagana" <jagana@us.ibm.com>
Importance: Normal
Subject: Re: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments on
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt)
To: mobile-ip@sunroof.eng.sun.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF177D9E75.85FAAEAC-ON88256AF4.006B48FA@boulder.ibm.com>
Date: Mon, 29 Oct 2001 12:00:49 -0800
X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 10/29/2001 01:01:06 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>


Hello James,

> I think there may be an easy response to this. It requires 1) a secure L2
so
> that a malicious MN can't set it's L2 address arbitrarially, and > 2)
that an
> AR not route any packets from a MN that has not successfully done
Neighbor
> Discovery and for which the AR has a valid IP adress to L2 address
binding
> in its neighbor cache.

The issue is not the 'src' CoA address but it is the home address set
by a malicious node in an outgoing IPv6 packet. Who can prevent any node
from setting any valid home address in a packet as long as the src COA is
address is valid under ingress-filtering enabled network and the
problem mounts even further with packets originating from the malicious
nodes where no ingress filtering is enabled at all. In fact, the validation
at CN though should be done based on the home addres in the packet but
not on the CoA address which is arbitrary for the MNs visiting foreign
nodes.

I would consider this problem related to the receiving side rather than to
the sending side. It is hard to control on the sending side because
there are always unprotected networks from where these malicious nodes
can send packets that can disturb the normal flow.

Thanks,
Venkat

----- Original Message -----
From: "Venkata Jagana" <jagana@us.ibm.com>
To: <mobile-ip@sunroof.eng.sun.com>
Sent: Friday, October 26, 2001 5:29 PM
Subject: Re: [mobile-ip] Last Call Comments on
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01

.txt


>
>
> Hello Alper,
>
> What a coincidence! I am little bit late in sending out the exactly
> similar thought that I have on this security hole and the corresponding
> enhancement.
>
> In fact, I believe, the malicious node don't even need to know the CoA
> of MN and the home address is more than sufficient for it to send a
> packet with arbitrary src address in the packet to CN. As per
> the current MIpv6 draft, CN  would have to simply replace the 'src'
> address of IPv6 packet by the home address in the home address option
> in the incoming packet without any further validations and this is a
> problem.
>
> The solution, that I have in my mind, can be simply to look at the
> CN's binding cache upon receipt of incoming packet and validate that
> 'src and home address' of the packet matches with CN's CoA <-> Home
> Address binding before accepting it for further processing. In fact, this
> binding cache is already consulted for outgoing packets and it needs
> to be done for incoming packets as well in order to address this
> security concern and so, this may not be a real overhead since it is
> a simple lookup. However, this solution may not really work well in
> case where the malicious node somehow steals both CoA and Home address
> of MN and I guess that's always an issue anyway.
>
>
> Thanks,
> Venkat
>
> ----------------------------------------------------------------
> Venkata R Jagana
> IBM Linux Technology Centre, Beaverton
> jagana@us.ibm.com
> Tel: (503) 578 3430 T/L 775-3430
>
>
> "Alper Yegin" <alper@docomolabs-usa.com>@sunroof.eng.sun.com on
10/26/2001
> 04:53:55 PM
>
> Please respond to mobile-ip@sunroof.eng.sun.com
>
> Sent by:  owner-mobile-ip@sunroof.eng.sun.com
>
>
> To:   <mobile-ip@sunroof.eng.sun.com>
> cc:
> Subject:  Re: [mobile-ip] Last Call Comments on
>
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01

.txt
>
>
> Hello,
>
> I know I'm late for the last call. But nevertheless I'd like to identify
a
> new security issue
> with Mobile IPv6. Please take a look at this and comment....
>
> Home address option of Mobile IPv6 gives the flexibility to use any IP
> address as the source
> address of a packet and send it to a receipent (a correspondent node).
And
> the correspondent
> node should be able to process home address option to figure out the true
> end point of this
> communication. By using this option, a node can use any arbitrary IP
> address
> as the source
> address of outgoing packets, and be able to maintain end2end connection
> with
> a peer.
>
> This can be exploited by malicious nodes to impersonate other nodes, as
far
> as the routers
> along the path are concerned.
>
> Any mechanism that relies on the source IP address of a packet can be
> fooled
> by using an
> acceptable source IP address (like one borrowed from a legitimate node)
and
> carrying the
> real source address in the home address option.
>
> For example, a flow is (or proposed to be?) identified by the source
> address
> and the flow
> info of an IPv6 packet. If the malicious node can learn these two fields
of
> a legitimate packet, it can
> start using them in its own packets. Therefore stealing QoS established
for
> another device (along
> the common path).
>
> So, why do we think there's something new here. Afterall, even with IPv4,
a
> device can steal
> some other device's IP address and use it. But.... if it does so, the
> correspondent node would
> think that this packet is coming from the legitimate device, therefore
any
> correspondence will
> be directed at the legitimate device. And hence, malicious node cannot
> enjoy
> a end2end
> communication.
>
> With IPv6 and home address option, the packets from the malicious node
look
> like they are from
> a legitimate node to all the routers along the path (same as in IPv4)
and
> when arrived at the
> correspondent node they reveal their true sender (this is new!).
>
> A correspondent node receiving such packets won't know what's going on.
And
> nothing special
> on correspondent node is expected for this to work (except a correct
> implementation of home
> address option processing :)
>
> First solution that comes to mind would be to expect protocols to check
for
> home address
> option in addition to source address, but that is not desirable as it is
> costly.
>
> What do people think about this issue?
>
> (I might not be able to follow rest of the discussion for a week. I'll be
> out of town. But I'm sending
> this now, so that the discussion is not delayed).
>
> alper
> NTT DoCoMo USA Labs
>
>
>
>
>
>
>







From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 30 07:39:28 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26009
	for <mobileip-archive@odin.ietf.org>; Tue, 30 Oct 2001 07:39:24 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08692;
	Tue, 30 Oct 2001 05:38:16 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21402;
	Tue, 30 Oct 2001 04:38:19 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UCbVQO005286
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 30 Oct 2001 04:37:31 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9UCbV77005285
	for mobile-ip-dist; Tue, 30 Oct 2001 04:37:31 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UCbRQO005278
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 04:37:27 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08598
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 04:37:29 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA25526
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 04:37:29 -0800 (PST)
Received: (qmail 25360 invoked by uid 500); 30 Oct 2001 12:21:37 -0000
Date: Tue, 30 Oct 2001 04:21:37 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: "Patil Basavaraj \(NET/Dallas\)" <Basavaraj.Patil@nokia.com>
Cc: "'ext Pat Calhoun'" <pcalhoun@diameter.org>, aaa-wg@merit.edu,
        "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Re: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Message-ID: <20011030042137.H24979@charizard.diameter.org>
Mail-Followup-To: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>,
	'ext Pat Calhoun' <pcalhoun@diameter.org>, aaa-wg@merit.edu,
	'Mobile IP' <mobile-ip@sunroof.eng.sun.com>
References: <697DAA22C5004B4596E033803A7CEF444CCF62@daebe007.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CCF62@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Fri, Oct 26, 2001 at 11:53:16AM -0500
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

I guess I missed the conclusion ofthe GNAIE spec. The extension mentioned
below has many benefits, and it would be even better if it was in an FQDN
format than an NAI. This extension really will be required to the proper
operation of MobileIP+AAA. Are you stating that the AAA WG should include
the definition of the extension in one of it's documents?

PatC
On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj (NET/Dallas) wrote:
> 
> Pat,
> 
> The GNAIE I-D is in the process of being deprecated as a WG document.
> So refering to the GNAIE as a way to fix it may not be the solution. As
> I
> have pointed out to you and the other authors of the GNAIE I-D, the I-D
> that needs a specific NAI extension ought to define it rather than
> having a
> placeholder for extensions I-D which is reference by others.
> The FA-NAI specified in GNAIE should (or can) be specified in the
> reg-tun
> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
> I-D. So far the HA-NAI has not been really shown as a requirement by any
> other I-Ds in the Mobile IP WG.
> 
> -Basavaraj
> 
> > 
> > 
> > Submitter name: Pat Calhoun
> > Submitter email address: pcalhoun@diameter.org 
> > Date first submitted: 25-Oct-01 
> > Reference:  
> > Document: MIP
> > Comment type: Technical 
> > Priority: 1
> > Section: 
> > Rationale/Explanation of issue: 
> > 
> > Once a mobile has been assigned a home agent, if a subsequent 
> > HAR is to
> > be sent, a new AAAH has no way to map the IP address in the 
> > registration
> > request to a Destination-Host AVP of the Home Agent.
> > 
> > Fix
> > 
> > The GNAIE ID is being updated to reflect comments of the IESG. In this
> > document we will specify that the HA may include its NAI in the 
> > Registration Reply, and if so, the mobile node must include 
> > the same extension
> > in subsequent registration requests. This will require some 
> > Mobile IP WG
> > involvement.
> > 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 30 16:51:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15579
	for <mobileip-archive@lists.ietf.org>; Tue, 30 Oct 2001 16:51:26 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03874;
	Tue, 30 Oct 2001 13:50:41 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11820;
	Tue, 30 Oct 2001 13:49:58 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ULn4QO005823
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 30 Oct 2001 13:49:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9ULn4wE005822
	for mobile-ip-dist; Tue, 30 Oct 2001 13:49:04 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9ULn1QO005815
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 13:49:01 -0800 (PST)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06269
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 13:49:03 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16518
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 13:49:02 -0800 (PST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9ULn5Q15594
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 15:49:05 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56eab559d9ac12f2540ff@davir01nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Tue, 30 Oct 2001 15:49:01 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 30 Oct 2001 15:49:00 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: [mobile-ip] Feeback from WG on draft-ietf-mobileip-gnaie-05.txt
Date: Tue, 30 Oct 2001 15:49:02 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCFA8@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Feeback from WG on draft-ietf-mobileip-gnaie-05.txt
Thread-Index: AcFhjK4SbbGlJs1GEdWxIQAAhj/HZA==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 30 Oct 2001 21:49:00.0750 (UTC) FILETIME=[AF4D9EE0:01C1618C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9ULn1QO005816
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Hello,

The Generalized NAI (GNAI) Extension for Mobile IPv4 I-D
(draft-ietf-mobileip-gnaie-05.txt) defines two new extensions:
1. The FA-NAI Extension 
2. The HA-NAI extension

The I-D does not state any real applicability of these extensions and
hence is merely a placeholder for these two new NAI types in addition
to proposing the use of the MIER format for these MIP NAIs. 

I believe it is appropriate that an extension be specified in an I-D
that actually has a use for it. Currently the I-D
draft-ietf-mobileip-reg-tunnel-05.txt utilizes the FA-NAI extension,
but this is carried in agent advts. Hence it would be appropriate for
the reg-tunnel I-D to also specify the FA-NAI extension. And if there
is a need for the HA-NAI extension elsewhere, that I-D should specify
it. 

I would like to solicit feedback from the WG about dropping the GNAIE
I-D as a WG doc. If you believe there are good reasons for keeping
this I-D, please let us know.

-Basavaraj 




From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 30 17:20:07 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16045
	for <mobileip-archive@lists.ietf.org>; Tue, 30 Oct 2001 17:20:07 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17490;
	Tue, 30 Oct 2001 14:19:40 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14947;
	Tue, 30 Oct 2001 14:19:29 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UMIBQO005949
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 30 Oct 2001 14:18:11 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9UMIAqj005948
	for mobile-ip-dist; Tue, 30 Oct 2001 14:18:10 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UMI7QO005941
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 14:18:07 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24810
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 14:18:10 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07013
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 15:48:13 -0700 (MST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9UMIkQ08935
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 16:18:46 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56ead002c2ac12f255079@davir02nok.americas.nokia.com>;
 Tue, 30 Oct 2001 16:18:08 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 30 Oct 2001 16:18:11 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: [mobile-ip] RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Date: Tue, 30 Oct 2001 16:18:10 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCFA9@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Thread-Index: AcFhP6V62MF9g80xEdWryQAIx6S5QwAUQ7kw
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'ext Pat Calhoun'" <pcalhoun@diameter.org>
Cc: <aaa-wg@merit.edu>, "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 30 Oct 2001 22:18:11.0314 (UTC) FILETIME=[C2B87D20:01C16190]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9UMI7QO005942
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Comments below:

>I guess I missed the conclusion ofthe GNAIE spec. The extension
mentioned
>below has many benefits, and it would be even better if it was in an
FQDN
>format than an NAI. This extension really will be required to the
proper
>operation of MobileIP+AAA. Are you stating that the AAA WG should
include
>the definition of the extension in one of it's documents?
>
>PatC

Pat,

I was alluding to having the HA-NAI being specified in the AAA WG, but
it does not look like that makes much sense. So lets ignore that.

Why is the HA-NAI absolutely required for proper operation of MIP+AAA?
I do realize the HA can be assigned in a foreign domain (as mentioned
in the MIP-Diameter I-D), but fail to see how you really use the
HA-NAI . Maybe I am misunderstanding the problem here.

Once a MN has been assigned an HA (Home or Foreign), would'nt the MN
send subsequent registrations to the HA via its IP address? A new HAR
at a new AAAH is a result of a reg-req from the MN. Why would this new
reg-req not include the address of the HA if it had been previously
assigned unless it wants a new HA (in which case it is equivalent to
initial registration).

-Basavaraj

>On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj (NET/Dallas)
wrote:
>> 
>> Pat,
>> 
>> The GNAIE I-D is in the process of being deprecated as a WG document.
>> So refering to the GNAIE as a way to fix it may not be the solution.
As
>> I
>> have pointed out to you and the other authors of the GNAIE I-D, the
I-D
>> that needs a specific NAI extension ought to define it rather than
>> having a
>> placeholder for extensions I-D which is reference by others.
>> The FA-NAI specified in GNAIE should (or can) be specified in the
>> reg-tun
>> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
>> I-D. So far the HA-NAI has not been really shown as a requirement by
any
>> other I-Ds in the Mobile IP WG.
>> 
>> -Basavaraj
>> 
>> > 
>> > 
>> > Submitter name: Pat Calhoun
>> > Submitter email address: pcalhoun@diameter.org 
>> > Date first submitted: 25-Oct-01 
>> > Reference:  
>> > Document: MIP
>> > Comment type: Technical 
>> > Priority: 1
>> > Section: 
>> > Rationale/Explanation of issue: 
>> > 
>> > Once a mobile has been assigned a home agent, if a subsequent 
>> > HAR is to
>> > be sent, a new AAAH has no way to map the IP address in the 
>> > registration
>> > request to a Destination-Host AVP of the Home Agent.
>> > 
>> > Fix
>> > 
>> > The GNAIE ID is being updated to reflect comments of the IESG. In
this
>> > document we will specify that the HA may include its NAI in the 
>> > Registration Reply, and if so, the mobile node must include 
>> > the same extension
>> > in subsequent registration requests. This will require some 
>> > Mobile IP WG
>> > involvement.
>> > 


> -----Original Message-----
> From: ext Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, October 30, 2001 6:22 AM
> To: Patil Basavaraj (NET/Dallas)
> Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP'
> Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the
> Destination-Host of a previously assigned foreign HA?
> 
> 
> I guess I missed the conclusion ofthe GNAIE spec. The 
> extension mentioned
> below has many benefits, and it would be even better if it 
> was in an FQDN
> format than an NAI. This extension really will be required to 
> the proper
> operation of MobileIP+AAA. Are you stating that the AAA WG 
> should include
> the definition of the extension in one of it's documents?
> 
> PatC
> On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj 
> (NET/Dallas) wrote:
> > 
> > Pat,
> > 
> > The GNAIE I-D is in the process of being deprecated as a WG 
> document.
> > So refering to the GNAIE as a way to fix it may not be the 
> solution. As
> > I
> > have pointed out to you and the other authors of the GNAIE 
> I-D, the I-D
> > that needs a specific NAI extension ought to define it rather than
> > having a
> > placeholder for extensions I-D which is reference by others.
> > The FA-NAI specified in GNAIE should (or can) be specified in the
> > reg-tun
> > I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
> > I-D. So far the HA-NAI has not been really shown as a 
> requirement by any
> > other I-Ds in the Mobile IP WG.
> > 
> > -Basavaraj
> > 
> > > 
> > > 
> > > Submitter name: Pat Calhoun
> > > Submitter email address: pcalhoun@diameter.org 
> > > Date first submitted: 25-Oct-01 
> > > Reference:  
> > > Document: MIP
> > > Comment type: Technical 
> > > Priority: 1
> > > Section: 
> > > Rationale/Explanation of issue: 
> > > 
> > > Once a mobile has been assigned a home agent, if a subsequent 
> > > HAR is to
> > > be sent, a new AAAH has no way to map the IP address in the 
> > > registration
> > > request to a Destination-Host AVP of the Home Agent.
> > > 
> > > Fix
> > > 
> > > The GNAIE ID is being updated to reflect comments of the 
> IESG. In this
> > > document we will specify that the HA may include its NAI in the 
> > > Registration Reply, and if so, the mobile node must include 
> > > the same extension
> > > in subsequent registration requests. This will require some 
> > > Mobile IP WG
> > > involvement.
> > > 
> 


From owner-mobile-ip@sunroof.eng.sun.com  Tue Oct 30 22:48:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21430
	for <mobileip-archive@lists.ietf.org>; Tue, 30 Oct 2001 22:48:22 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA26665;
	Tue, 30 Oct 2001 19:46:18 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16423;
	Tue, 30 Oct 2001 19:45:49 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V3irQO006524
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 30 Oct 2001 19:44:53 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9V3ir56006523
	for mobile-ip-dist; Tue, 30 Oct 2001 19:44:53 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V3ioQO006516
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 19:44:50 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19961
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 19:44:52 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA03493
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 19:44:52 -0800 (PST)
Received: (qmail 32045 invoked by uid 500); 31 Oct 2001 03:29:01 -0000
Date: Tue, 30 Oct 2001 19:29:01 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: "Patil Basavaraj \(NET/Dallas\)" <Basavaraj.Patil@nokia.com>
Cc: "'ext Pat Calhoun'" <pcalhoun@diameter.org>, aaa-wg@merit.edu,
        "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Re: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Message-ID: <20011030192900.A32037@charizard.diameter.org>
Mail-Followup-To: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>,
	'ext Pat Calhoun' <pcalhoun@diameter.org>, aaa-wg@merit.edu,
	'Mobile IP' <mobile-ip@sunroof.eng.sun.com>
References: <697DAA22C5004B4596E033803A7CEF444CCFA9@daebe007.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CCFA9@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Tue, Oct 30, 2001 at 04:18:10PM -0600
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

The problem has to do with re-registrations. Since the AAAH is stateless,
it may not know the FQDN of the Home Agent assigned. All it has is the IP
address, and folks felt that IP->FQDN translation may not be reliable in
certain environments. So if the mobile could state the HA's FQDN, that would
solve all of the problems.

PatC
On Tue, Oct 30, 2001 at 04:18:10PM -0600, Patil Basavaraj (NET/Dallas) wrote:
> 
> Comments below:
> 
> >I guess I missed the conclusion ofthe GNAIE spec. The extension
> mentioned
> >below has many benefits, and it would be even better if it was in an
> FQDN
> >format than an NAI. This extension really will be required to the
> proper
> >operation of MobileIP+AAA. Are you stating that the AAA WG should
> include
> >the definition of the extension in one of it's documents?
> >
> >PatC
> 
> Pat,
> 
> I was alluding to having the HA-NAI being specified in the AAA WG, but
> it does not look like that makes much sense. So lets ignore that.
> 
> Why is the HA-NAI absolutely required for proper operation of MIP+AAA?
> I do realize the HA can be assigned in a foreign domain (as mentioned
> in the MIP-Diameter I-D), but fail to see how you really use the
> HA-NAI . Maybe I am misunderstanding the problem here.
> 
> Once a MN has been assigned an HA (Home or Foreign), would'nt the MN
> send subsequent registrations to the HA via its IP address? A new HAR
> at a new AAAH is a result of a reg-req from the MN. Why would this new
> reg-req not include the address of the HA if it had been previously
> assigned unless it wants a new HA (in which case it is equivalent to
> initial registration).
> 
> -Basavaraj
> 
> >On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj (NET/Dallas)
> wrote:
> >> 
> >> Pat,
> >> 
> >> The GNAIE I-D is in the process of being deprecated as a WG document.
> >> So refering to the GNAIE as a way to fix it may not be the solution.
> As
> >> I
> >> have pointed out to you and the other authors of the GNAIE I-D, the
> I-D
> >> that needs a specific NAI extension ought to define it rather than
> >> having a
> >> placeholder for extensions I-D which is reference by others.
> >> The FA-NAI specified in GNAIE should (or can) be specified in the
> >> reg-tun
> >> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
> >> I-D. So far the HA-NAI has not been really shown as a requirement by
> any
> >> other I-Ds in the Mobile IP WG.
> >> 
> >> -Basavaraj
> >> 
> >> > 
> >> > 
> >> > Submitter name: Pat Calhoun
> >> > Submitter email address: pcalhoun@diameter.org 
> >> > Date first submitted: 25-Oct-01 
> >> > Reference:  
> >> > Document: MIP
> >> > Comment type: Technical 
> >> > Priority: 1
> >> > Section: 
> >> > Rationale/Explanation of issue: 
> >> > 
> >> > Once a mobile has been assigned a home agent, if a subsequent 
> >> > HAR is to
> >> > be sent, a new AAAH has no way to map the IP address in the 
> >> > registration
> >> > request to a Destination-Host AVP of the Home Agent.
> >> > 
> >> > Fix
> >> > 
> >> > The GNAIE ID is being updated to reflect comments of the IESG. In
> this
> >> > document we will specify that the HA may include its NAI in the 
> >> > Registration Reply, and if so, the mobile node must include 
> >> > the same extension
> >> > in subsequent registration requests. This will require some 
> >> > Mobile IP WG
> >> > involvement.
> >> > 
> 
> 
> > -----Original Message-----
> > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org]
> > Sent: Tuesday, October 30, 2001 6:22 AM
> > To: Patil Basavaraj (NET/Dallas)
> > Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP'
> > Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the
> > Destination-Host of a previously assigned foreign HA?
> > 
> > 
> > I guess I missed the conclusion ofthe GNAIE spec. The 
> > extension mentioned
> > below has many benefits, and it would be even better if it 
> > was in an FQDN
> > format than an NAI. This extension really will be required to 
> > the proper
> > operation of MobileIP+AAA. Are you stating that the AAA WG 
> > should include
> > the definition of the extension in one of it's documents?
> > 
> > PatC
> > On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj 
> > (NET/Dallas) wrote:
> > > 
> > > Pat,
> > > 
> > > The GNAIE I-D is in the process of being deprecated as a WG 
> > document.
> > > So refering to the GNAIE as a way to fix it may not be the 
> > solution. As
> > > I
> > > have pointed out to you and the other authors of the GNAIE 
> > I-D, the I-D
> > > that needs a specific NAI extension ought to define it rather than
> > > having a
> > > placeholder for extensions I-D which is reference by others.
> > > The FA-NAI specified in GNAIE should (or can) be specified in the
> > > reg-tun
> > > I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
> > > I-D. So far the HA-NAI has not been really shown as a 
> > requirement by any
> > > other I-Ds in the Mobile IP WG.
> > > 
> > > -Basavaraj
> > > 
> > > > 
> > > > 
> > > > Submitter name: Pat Calhoun
> > > > Submitter email address: pcalhoun@diameter.org 
> > > > Date first submitted: 25-Oct-01 
> > > > Reference:  
> > > > Document: MIP
> > > > Comment type: Technical 
> > > > Priority: 1
> > > > Section: 
> > > > Rationale/Explanation of issue: 
> > > > 
> > > > Once a mobile has been assigned a home agent, if a subsequent 
> > > > HAR is to
> > > > be sent, a new AAAH has no way to map the IP address in the 
> > > > registration
> > > > request to a Destination-Host AVP of the Home Agent.
> > > > 
> > > > Fix
> > > > 
> > > > The GNAIE ID is being updated to reflect comments of the 
> > IESG. In this
> > > > document we will specify that the HA may include its NAI in the 
> > > > Registration Reply, and if so, the mobile node must include 
> > > > the same extension
> > > > in subsequent registration requests. This will require some 
> > > > Mobile IP WG
> > > > involvement.
> > > > 
> > 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 31 00:33:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22704
	for <mobileip-archive@lists.ietf.org>; Wed, 31 Oct 2001 00:33:09 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA14470;
	Tue, 30 Oct 2001 21:32:16 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21277;
	Tue, 30 Oct 2001 21:32:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V5UGQO006670
	for <mobile-ip-dist@sunroof.eng.sun.com>; Tue, 30 Oct 2001 21:30:17 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9V5UGsn006669
	for mobile-ip-dist; Tue, 30 Oct 2001 21:30:16 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V5UCQO006662
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 21:30:12 -0800 (PST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA00674
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 21:30:16 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20255
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 22:30:02 -0700 (MST)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9V5UIQ02817
	for <mobile-ip@sunroof.eng.sun.com>; Tue, 30 Oct 2001 23:30:19 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56ec5b9bbbac12f256126@davir03nok.americas.nokia.com>;
 Tue, 30 Oct 2001 23:30:14 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 30 Oct 2001 23:30:13 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: [mobile-ip] RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Date: Tue, 30 Oct 2001 23:30:13 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCFB0@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Thread-Index: AcFhvmnpN/5rD82xEdWpXgBQi2kYTQADp9Qg
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'ext Pat Calhoun'" <pcalhoun@diameter.org>
Cc: <aaa-wg@merit.edu>, "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 31 Oct 2001 05:30:13.0768 (UTC) FILETIME=[1DB51080:01C161CD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9V5UDQO006663
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

>(The problem has to do with re-registrations. Since the AAAH is
stateless,
>it may not know the FQDN of the Home Agent assigned. All it has is the
IP
>address, and folks felt that IP->FQDN translation may not be reliable
in
>certain environments. 

Possibly. But are there are any real requirements or example scenarios
where the FQDN of the HA is required and how the AAAH utilises this
info? 
Also why would re-registrations utilize the AAA network elements? The
MN can directly send subsequent registrations to the HA that has been
previously assigned to it via AAAH (maybe in a foreign domain). 

>So if the mobile could state the HA's FQDN, that would
>solve all of the problems.

Not sure if we really have a strong argument for having the MN send
the FQDN of the HA to the AAAH here yet. 

>
>PatC

-Basavaraj



On Tue, Oct 30, 2001 at 04:18:10PM -0600, Patil Basavaraj (NET/Dallas)
wrote:
> 
> Comments below:
> 
> >I guess I missed the conclusion ofthe GNAIE spec. The extension
> mentioned
> >below has many benefits, and it would be even better if it was in an
> FQDN
> >format than an NAI. This extension really will be required to the
> proper
> >operation of MobileIP+AAA. Are you stating that the AAA WG should
> include
> >the definition of the extension in one of it's documents?
> >
> >PatC
> 
> Pat,
> 
> I was alluding to having the HA-NAI being specified in the AAA WG, but
> it does not look like that makes much sense. So lets ignore that.
> 
> Why is the HA-NAI absolutely required for proper operation of MIP+AAA?
> I do realize the HA can be assigned in a foreign domain (as mentioned
> in the MIP-Diameter I-D), but fail to see how you really use the
> HA-NAI . Maybe I am misunderstanding the problem here.
> 
> Once a MN has been assigned an HA (Home or Foreign), would'nt the MN
> send subsequent registrations to the HA via its IP address? A new HAR
> at a new AAAH is a result of a reg-req from the MN. Why would this new
> reg-req not include the address of the HA if it had been previously
> assigned unless it wants a new HA (in which case it is equivalent to
> initial registration).
> 
> -Basavaraj
> 
> >On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj
(NET/Dallas)
> wrote:
> >> 
> >> Pat,
> >> 
> >> The GNAIE I-D is in the process of being deprecated as a WG
document.
> >> So refering to the GNAIE as a way to fix it may not be the
solution.
> As
> >> I
> >> have pointed out to you and the other authors of the GNAIE I-D, the
> I-D
> >> that needs a specific NAI extension ought to define it rather than
> >> having a
> >> placeholder for extensions I-D which is reference by others.
> >> The FA-NAI specified in GNAIE should (or can) be specified in the
> >> reg-tun
> >> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
> >> I-D. So far the HA-NAI has not been really shown as a requirement
by
> any
> >> other I-Ds in the Mobile IP WG.
> >> 
> >> -Basavaraj
> >> 
> >> > 
> >> > 
> >> > Submitter name: Pat Calhoun
> >> > Submitter email address: pcalhoun@diameter.org 
> >> > Date first submitted: 25-Oct-01 
> >> > Reference:  
> >> > Document: MIP
> >> > Comment type: Technical 
> >> > Priority: 1
> >> > Section: 
> >> > Rationale/Explanation of issue: 
> >> > 
> >> > Once a mobile has been assigned a home agent, if a subsequent 
> >> > HAR is to
> >> > be sent, a new AAAH has no way to map the IP address in the 
> >> > registration
> >> > request to a Destination-Host AVP of the Home Agent.
> >> > 
> >> > Fix
> >> > 
> >> > The GNAIE ID is being updated to reflect comments of the IESG. In
> this
> >> > document we will specify that the HA may include its NAI in the 
> >> > Registration Reply, and if so, the mobile node must include 
> >> > the same extension
> >> > in subsequent registration requests. This will require some 
> >> > Mobile IP WG
> >> > involvement.
> >> > 
> 
> 
> > -----Original Message-----
> > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org]
> > Sent: Tuesday, October 30, 2001 6:22 AM
> > To: Patil Basavaraj (NET/Dallas)
> > Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP'
> > Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the
> > Destination-Host of a previously assigned foreign HA?
> > 
> > 
> > I guess I missed the conclusion ofthe GNAIE spec. The 
> > extension mentioned
> > below has many benefits, and it would be even better if it 
> > was in an FQDN
> > format than an NAI. This extension really will be required to 
> > the proper
> > operation of MobileIP+AAA. Are you stating that the AAA WG 
> > should include
> > the definition of the extension in one of it's documents?
> > 
> > PatC
> > On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj 
> > (NET/Dallas) wrote:
> > > 
> > > Pat,
> > > 
> > > The GNAIE I-D is in the process of being deprecated as a WG 
> > document.
> > > So refering to the GNAIE as a way to fix it may not be the 
> > solution. As
> > > I
> > > have pointed out to you and the other authors of the GNAIE 
> > I-D, the I-D
> > > that needs a specific NAI extension ought to define it rather than
> > > having a
> > > placeholder for extensions I-D which is reference by others.
> > > The FA-NAI specified in GNAIE should (or can) be specified in the
> > > reg-tun
> > > I-D i MIP WG and the HA-NAI can be specified in this
Diameter-MIPv4
> > > I-D. So far the HA-NAI has not been really shown as a 
> > requirement by any
> > > other I-Ds in the Mobile IP WG.
> > > 
> > > -Basavaraj
> > > 
> > > > 
> > > > 
> > > > Submitter name: Pat Calhoun
> > > > Submitter email address: pcalhoun@diameter.org 
> > > > Date first submitted: 25-Oct-01 
> > > > Reference:  
> > > > Document: MIP
> > > > Comment type: Technical 
> > > > Priority: 1
> > > > Section: 
> > > > Rationale/Explanation of issue: 
> > > > 
> > > > Once a mobile has been assigned a home agent, if a subsequent 
> > > > HAR is to
> > > > be sent, a new AAAH has no way to map the IP address in the 
> > > > registration
> > > > request to a Destination-Host AVP of the Home Agent.
> > > > 
> > > > Fix
> > > > 
> > > > The GNAIE ID is being updated to reflect comments of the 
> > IESG. In this
> > > > document we will specify that the HA may include its NAI in the 
> > > > Registration Reply, and if so, the mobile node must include 
> > > > the same extension
> > > > in subsequent registration requests. This will require some 
> > > > Mobile IP WG
> > > > involvement.
> > > > 
> > 


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 31 08:56:27 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18513
	for <mobileip-archive@odin.ietf.org>; Wed, 31 Oct 2001 08:56:26 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09198;
	Wed, 31 Oct 2001 05:55:39 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24817;
	Wed, 31 Oct 2001 05:54:10 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VDrEQO007101
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 31 Oct 2001 05:53:14 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VDrDCp007100
	for mobile-ip-dist; Wed, 31 Oct 2001 05:53:13 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VDrAQO007093
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 05:53:10 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24577
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 05:53:12 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23799
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:26:36 -0700 (MST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9VDrnQ04692
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:53:49 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T56ee2811f1ac12f257079@davir04nok.americas.nokia.com> for <mobile-ip@sunroof.eng.sun.com>;
 Wed, 31 Oct 2001 07:53:10 -0600
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 31 Oct 2001 07:53:10 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: [mobile-ip] Test
Date: Wed, 31 Oct 2001 07:53:10 -0600
Message-ID: <697DAA22C5004B4596E033803A7CEF444CCFB6@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Test
Thread-Index: AcFiE2AmcqcVsc4GEdWxI0RFU1R3dw==
From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>
To: "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
X-OriginalArrivalTime: 31 Oct 2001 13:53:10.0570 (UTC) FILETIME=[607BA0A0:01C16213]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9VDrAQO007094
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 8bit

Testing


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 31 10:12:52 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21251
	for <mobileip-archive@odin.ietf.org>; Wed, 31 Oct 2001 10:12:52 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10542;
	Wed, 31 Oct 2001 07:12:06 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09473;
	Wed, 31 Oct 2001 07:10:20 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VF97QO007249
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:09:07 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VF97Ge007248
	for mobile-ip-dist; Wed, 31 Oct 2001 07:09:07 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VF93QO007241
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:09:03 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21892
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:09:04 -0800 (PST)
Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12799
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:09:03 -0800 (PST)
Received: from fredrikj (sparcis.ipunplugged.com [10.0.1.163])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA16451;
	Wed, 31 Oct 2001 16:08:36 +0100
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Pat Calhoun" <pcalhoun@diameter.org>,
        "Patil Basavaraj \(NET/Dallas\)" <Basavaraj.Patil@nokia.com>
Cc: <aaa-wg@merit.edu>, "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Date: Wed, 31 Oct 2001 16:09:26 +0100
Message-ID: <MJEMJBGGCLLDLFFAHLJKMEDMDJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20011030042137.H24979@charizard.diameter.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>
Content-Transfer-Encoding: 7bit

if we are specifying the new extension in the MIPv4 Application for
diameter, can we then make it a URI instead, that way we will have all
information we'll ever need, such as port and transport.

/Fredrik

>-----Original Message-----
>From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of
>Pat Calhoun
>Sent: den 30 oktober 2001 13:22
>To: Patil Basavaraj (NET/Dallas)
>Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP'
>Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the
>Destination-Host of a previously assigned foreign HA?
>
>
>I guess I missed the conclusion ofthe GNAIE spec. The extension mentioned
>below has many benefits, and it would be even better if it was in an FQDN
>format than an NAI. This extension really will be required to the proper
>operation of MobileIP+AAA. Are you stating that the AAA WG should include
>the definition of the extension in one of it's documents?
>
>PatC
>On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj
>(NET/Dallas) wrote:
>>
>> Pat,
>>
>> The GNAIE I-D is in the process of being deprecated as a WG document.
>> So refering to the GNAIE as a way to fix it may not be the solution. As
>> I
>> have pointed out to you and the other authors of the GNAIE I-D, the I-D
>> that needs a specific NAI extension ought to define it rather than
>> having a
>> placeholder for extensions I-D which is reference by others.
>> The FA-NAI specified in GNAIE should (or can) be specified in the
>> reg-tun
>> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4
>> I-D. So far the HA-NAI has not been really shown as a requirement by any
>> other I-Ds in the Mobile IP WG.
>>
>> -Basavaraj
>>
>> >
>> >
>> > Submitter name: Pat Calhoun
>> > Submitter email address: pcalhoun@diameter.org
>> > Date first submitted: 25-Oct-01
>> > Reference:
>> > Document: MIP
>> > Comment type: Technical
>> > Priority: 1
>> > Section:
>> > Rationale/Explanation of issue:
>> >
>> > Once a mobile has been assigned a home agent, if a subsequent
>> > HAR is to
>> > be sent, a new AAAH has no way to map the IP address in the
>> > registration
>> > request to a Destination-Host AVP of the Home Agent.
>> >
>> > Fix
>> >
>> > The GNAIE ID is being updated to reflect comments of the IESG. In this
>> > document we will specify that the HA may include its NAI in the
>> > Registration Reply, and if so, the mobile node must include
>> > the same extension
>> > in subsequent registration requests. This will require some
>> > Mobile IP WG
>> > involvement.
>> >



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 31 10:44:26 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22156
	for <mobileip-archive@odin.ietf.org>; Wed, 31 Oct 2001 10:44:25 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21729;
	Wed, 31 Oct 2001 08:43:24 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07639;
	Wed, 31 Oct 2001 07:43:15 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VFgJQO007382
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:42:19 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VFgJkL007381
	for mobile-ip-dist; Wed, 31 Oct 2001 07:42:19 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VFgGQO007374
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:42:16 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27090
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 07:42:16 -0800 (PST)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA23540
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 09:16:18 -0700 (MST)
Received: (qmail 1704 invoked by uid 500); 31 Oct 2001 15:26:19 -0000
Date: Wed, 31 Oct 2001 07:26:19 -0800
From: Pat Calhoun <pcalhoun@diameter.org>
To: "Patil Basavaraj \(NET/Dallas\)" <Basavaraj.Patil@nokia.com>
Cc: "'ext Pat Calhoun'" <pcalhoun@diameter.org>, aaa-wg@merit.edu,
        "'Mobile IP'" <mobile-ip@sunroof.eng.sun.com>
Subject: [mobile-ip] Re: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Message-ID: <20011031072618.A1694@charizard.diameter.org>
Mail-Followup-To: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>,
	'ext Pat Calhoun' <pcalhoun@diameter.org>, aaa-wg@merit.edu,
	'Mobile IP' <mobile-ip@sunroof.eng.sun.com>
References: <697DAA22C5004B4596E033803A7CEF444CCFB0@daebe007.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CCFB0@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Tue, Oct 30, 2001 at 11:30:13PM -0600
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

On Tue, Oct 30, 2001 at 11:30:13PM -0600, Patil Basavaraj (NET/Dallas) wrote:
> 
> >(The problem has to do with re-registrations. Since the AAAH is
> stateless,
> >it may not know the FQDN of the Home Agent assigned. All it has is the
> IP
> >address, and folks felt that IP->FQDN translation may not be reliable
> in
> >certain environments. 
> 
> Possibly. But are there are any real requirements or example scenarios
> where the FQDN of the HA is required and how the AAAH utilises this
> info? 

yes, without it the protocol doesn't work (hope that's a good enough requirement :)

> Also why would re-registrations utilize the AAA network elements? The
> MN can directly send subsequent registrations to the HA that has been
> previously assigned to it via AAAH (maybe in a foreign domain). 

this can occur in two circumstances:

1. Mobile moves to a new foreign agent (once the fast handoff/CT work is complete
   perhaps the FAs in a domain will be able to share keys, but for now this isn't
   possible)
2. Once #1 is resolved, when the mobile uses a foreign agent in a new domain

> 
> >So if the mobile could state the HA's FQDN, that would
> >solve all of the problems.
> 
> Not sure if we really have a strong argument for having the MN send
> the FQDN of the HA to the AAAH here yet. 

Well, as I mentioned, without this info, MIP+AAA doesn't work. When an AAAH receives
a registration request, it doesn't know the identity of the Home Agent. It does have
an IP address, but it needs to know how to route the message via Diameter, and 
this is based on FQDN (to provide inter domain message routing). So if the AAAH
only gets an IP address, it would have to map it to FQDN via DNS, and some folks
are arguing that this is the wrong approach.

If others feel that this is sufficient, please speak up. All I have is data from
the parties implying this is not a workable solution.

PatC


From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 31 14:14:28 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28405
	for <mobileip-archive@odin.ietf.org>; Wed, 31 Oct 2001 14:14:28 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04530;
	Wed, 31 Oct 2001 11:13:17 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04929;
	Wed, 31 Oct 2001 11:11:00 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VJA4QO007745
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 31 Oct 2001 11:10:04 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VJA3CJ007744
	for mobile-ip-dist; Wed, 31 Oct 2001 11:10:03 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VJA0QO007737
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 11:10:00 -0800 (PST)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04591
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 11:10:01 -0800 (PST)
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04919
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 12:44:15 -0700 (MST)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA15689
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 13:09:57 -0600 (CST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 31 Oct 2001 13:02:56 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <VPB2MM5S>; Wed, 31 Oct 2001 13:09:00 -0600
Message-ID: <6B49EDFE974BD51197D70002A56079D82AF518@zrc2c013.us.nortel.com>
From: "Ahmad Muhanna" <amuhanna@nortelnetworks.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question
Date: Wed, 31 Oct 2001 13:09:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1623F.7FC8C3D0"
X-Orig: <amuhanna@americasm01.nt.com>
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1623F.7FC8C3D0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All;
 
I thought that I have posted this but apparently not.
Concerning the STALE_CHALLENGE issue, the following is what I think is the
issue and a suggested fix.
I believe after reading section 3.2., RFC3012, anyone can come up with the
following concepts which has been highlighted and addressed directly or
indirectly:

1.	The term of unused challenge. Paragraph 1 section 3.2.

          "Foreign Agent MUST check that the MN-FA Challenge extension
exists, and that it contains a challenge value previously unused by the
Mobile Node. "

2.	The term of previously used challenge. Paragraph 3, section 3.2

          "If a mobile node retransmits a Registration Request with the same
Identification field and the same Challenge extension, and the Foreign Agent
still has 
            a pending Registration Request record in effect for the mobile
node, then the Foreign Agent forwards the Registration Request to the Home
Agent again.  
            In all other circumstances, if the Foreign Agent receives a
Registration Request with a Challenge extension containing a Challenge value
previously 
           used by that mobile node, the Foreign Agent SHOULD send a
Registration Reply to the mobile node containing the Code value
STALE_CHALLENGE."

3.	The term of UNKNOWN_CHALLENGE, Paragraph 4, section 3.2.

          "The Foreign Agent MUST NOT accept any Challenge in the
Registration Request unless it was offered in last successful Registration
Reply issued to the 
            Mobile Node, or else advertised as one of the last
CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
immediately preceding 
            Agent advertisements.  If the Challenge is not one of the
recently advertised values, the foreign Agent SHOULD send a Registration
Reply with Code 
            UNKNOWN_CHALLENGE (see section 10)."
As per paragraph 4, section 3.2, it is clear that any CHALLENGE value which
is not one of the last advertised in the Agent Advertisement message
"CHALLENGE_WINDOW" nor the one received in the last Registration Reply
Message is considered UNKNOWN_CHALLENGE. 
This contradicts with paragraph 1 and 3 which suggest that there are USED
CHALLENGES.
I believe the RFC needs to identify the following:<?xml:namespace prefix = o
ns = "urn:schemas-microsoft-com:office:office" />
1.      USED_CHALLENGE_WINDOW with a default value of 2 just like the
CHALLENGE_WINDOW.
2.      The meaning of the USED Challenge is any challenge that has been
used in a RRQ message and accepted by the PDSN as a valid CHALLENGE and PDSN

       relayed/generated a RRP in response to that RRQ message.
3.      "In all other circumstances" in paragraph 3 is very vague. We may
need to elaborate a little bit to explicitly say that STALE_CHALLENGE will
be generated 
      whenever a USED CHALLENGE is sent in a RRQ message. 
 
NOW the UNKNOWN CHALLENGE becomes any Challenge value other than the one
which was offered in last (NO Successful is mentioned) Registration Reply
issued to the Mobile Node, or else advertised as one of the last
CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
immediately preceding Agent advertisements, or else has previously been used
as one of the last USED_CHALLENGE_WINDOW (to be added to section 9).
 
I hope this would help in clarifying this issue.
 

Regards; 

Ahmad Muhanna 



 -----Original Message-----
From: Muhanna, Ahmad [RICH1:2Q23:EXCH] 
Sent: Monday, October 22, 2001 9:02 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question



I agree. 
I believe there is a couple of issues need to be clarified. 
One regarding Stale Challenge. 
The other regarding MN using the CHALLENGE received in the RRP with error
code and the meaning of successful Registration Request.

I will provide details at later time. 

Regards; 

Ahmad Muhanna 


-----Original Message----- 
From: Erik Nordmark [ mailto:Erik.Nordmark@eng.sun.com
<mailto:Erik.Nordmark@eng.sun.com> ] 
Sent: Monday, October 22, 2001 4:18 AM 
To: mobile-ip@sunroof.eng.sun.com 
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question 


Whatever the best interpretation will be, the fact that this is subject 
to interpretation tells me that RFC 3012 needs to be revised ASAP 
with a description which is clear on this point. 

Are there other issues that aren't (or weren't) clear to implementors 
of RFC 3012? Any issues that required sending a question on a mailing 
list or to the authors would seem like a good reason to get the 
spec clarified. 

  Erik 


>----- Begin Included Message -----< 

Date: Fri, 19 Oct 2001 15:47:24 -0500 
From: Mike_Borella@3com.com 
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question 
To: mobile-ip@sunroof.eng.sun.com 



I don't think that one can conclude that there is a security problem unless 
it is documented.  A quick search of the web finds plenty of general
concerns 
with 
MD5 but nothing about this particular issue.  Does copying a byte in an n
byte 
hash make it any less secure than the other interpretation which is an n-1 
byte hash? 

It is very clear that a literal reading of RFC3012 indicates that the byte 
should 
be copied.  There are commercial deployments that already do it this way. 

-Mike 





"Robert J Marks" <rjmarks@cambianetworks.com> on 10/18/2001 04:27:49 PM 

Please respond to mobile-ip@sunroof.eng.sun.com 

Sent by:  "Robert J Marks" <rjmarks@cambianetworks.com> 


To:   mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com, 
      pcalhoun@diameter.org 
cc:    (Mike Borella/MW/US/3Com) 
Subject:  RE: [mobile-ip] URGENT - rfc3012 interpretation question 



Although I am not sure of the intention in the RFC, I agree that the 
byte should not be duplicated in 2 places. I also seem to remember that 
known duplication tends to weaken the security. 

Bob 

-----Original Message----- 
From: owner-mobile-ip@sunroof.eng.sun.com 
[ mailto:owner-mobile-ip@sunroof.eng.sun.com
<mailto:owner-mobile-ip@sunroof.eng.sun.com> ] On Behalf Of Nish Abrol 
Sent: Thursday, October 18, 2001 12:14 AM 
To: charliep@iprg.nokia.com; pcalhoun@diameter.org; 
mobile-ip@sunroof.eng.sun.com 
Subject: [mobile-ip] URGENT - rfc3012 interpretation question 


Pat/Charlie, 

Really appreciate any insights into this really important interop issue 
for cdma2000: 

A question regarding the  interpretation of section 8 of rfc3012. This 
section specifies how to calculate the MN-AAA authenticator. It says: 

" To compute the authenticator, apply MD5 [11] 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 " 

The question is - if the challenge has less than 237 bytes - should the 
high order byte which was already used in the MD5 calculation  be 
included again as part of the  "least-order 237 bytes from Challenge"? 

e.g. if the challenge is 50 bytes in length - should the authenticator 
be calculated  as: 
    (a)  authenicator = md5(byte0 || key.......|| byte1 through byte49) 

or (b) authenticator = md5(byte0 || key ......|| byte0 through byte49). 

      where byte0 is the most significant byte of the challenge. 

A strict reading of the RFC seems to suggest (b). However, it seems 
that calculating the MD5 authenticator with the same information(high 
order byte) at different locations of the payload weakens the 
authenticator. 

So, what was the intention of the RFC and how should it be implemented? 
Also, do you know if RFC3012 implementations have participated in any 
bakeoffs/interops. If so, how have they interpreted this section? 

Your help will be really appreciated. 

Thanks 
Nish Abrol 
Qualcomm, Inc. 








>----- End Included Message -----< 


------_=_NextPart_001_01C1623F.7FC8C3D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [mobile-ip] URGENT - rfc3012 interpretation question</TITLE>

<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D115540519-31102001>Hi=20
All;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D115540519-31102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D115540519-31102001>I=20
thought that I have posted this but apparently not.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D115540519-31102001>Concerning the STALE_CHALLENGE issue, the =
following is=20
what I think is the issue and a suggested fix.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D115540519-31102001>
<P class=3DMsoNormal><FONT color=3D#0000ff>I believe after reading =
section 3.2.,=20
RFC3012, anyone can come up with the following concepts which has been=20
highlighted and addressed directly or indirectly:</FONT></P>
<OL style=3D"MARGIN-TOP: 0in" type=3D1>
  <LI class=3DMsoNormal=20
  style=3D"mso-list: l2 level1 lfo1; tab-stops: list .5in"><FONT =
color=3D#0000ff>The=20
  term of <STRONG>unused challenge</STRONG>. Paragraph 1 section=20
3.2.</FONT></LI></OL><PRE><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;</SPAN>&#8220;Foreign Agent MUST check that the MN-FA =
Challenge extension exists, and that it contains a challenge value <B =
style=3D"mso-bidi-font-weight: normal">previously unused</B> by the =
</SPAN><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt">Mobile Node. &#8221;</SPAN></FONT></PRE>
<OL start=3D2 style=3D"MARGIN-TOP: 0in" type=3D1>
  <LI class=3DMsoNormal=20
  style=3D"mso-list: l2 level1 lfo1; tab-stops: list .5in"><FONT =
color=3D#0000ff>The=20
  term of <STRONG>previously used challenge</STRONG>. Paragraph 3, =
section=20
  3.2</FONT></LI></OL><PRE><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;   =
</SPAN>&#8220;If a mobile node retransmits a Registration Request with =
the same Identification field and the same Challenge extension, and the =
Foreign Agent still has </SPAN></FONT></PRE><PRE><FONT =
color=3D#0000ff><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; =
FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; </SPAN>a pending Registration Request record in =
effect for the mobile node, then the Foreign Agent forwards the =
Registration Request to the Home Agent again.<SPAN =
style=3D"mso-spacerun: yes">&nbsp; =
</SPAN></SPAN></FONT></PRE><PRE><SPAN style=3D"FONT-FAMILY: 'Times New =
Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt"><SPAN =
style=3D"mso-spacerun: yes"></SPAN><SPAN =
class=3D384561003-31102001></SPAN><FONT color=3D#0000ff> <SPAN =
class=3D384561003-31102001>           </SPAN>In all other =
circumstances, if the Foreign Agent receives a Registration Request =
with a <B>Challenge extension containing a Challenge value previously =
</B></FONT></SPAN></PRE><PRE><SPAN style=3D"FONT-FAMILY: 'Times New =
Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt"><B><SPAN =
class=3D384561003-31102001></SPAN><FONT color=3D#0000ff> <SPAN =
class=3D384561003-31102001>          </SPAN>used by that mobile =
node</FONT></B><FONT color=3D#0000ff>, the Foreign Agent SHOULD send a =
Registration Reply to the mobile node containing the Code value =
STALE_CHALLENGE.&#8221;</FONT></SPAN></PRE>
<OL start=3D3 style=3D"MARGIN-TOP: 0in" type=3D1>
  <LI class=3DMsoNormal=20
  style=3D"mso-list: l2 level1 lfo1; tab-stops: list .5in"><FONT =
color=3D#0000ff>The=20
  term of <STRONG>UNKNOWN<SPAN=20
  class=3D828181603-31102001>_</SPAN>CHALLENGE</STRONG>, Paragraph 4, =
section=20
  3.2.</FONT></LI></OL><PRE><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;   =
</SPAN>&#8220;The Foreign Agent MUST NOT accept any Challenge in the =
Registration Request unless it was offered in last successful =
Registration Reply issued to the </SPAN></FONT></PRE><PRE><FONT =
color=3D#0000ff><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; =
FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; </SPAN>Mobile Node, or else advertised as one of the =
last CHALLENGE_WINDOW (see section 9) Challenge values inserted into =
the immediately preceding </SPAN></FONT></PRE><PRE><FONT =
color=3D#0000ff><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; =
FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; </SPAN>Agent advertisements.<SPAN =
style=3D"mso-spacerun: yes">&nbsp; </SPAN>If the Challenge is not one =
of the recently advertised values, the foreign Agent SHOULD send a =
Registration Reply with Code </SPAN></FONT></PRE><PRE><FONT =
color=3D#0000ff><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; =
FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; </SPAN>UNKNOWN_CHALLENGE (see section =
10).&#8221;</SPAN></FONT></PRE><PRE><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt">As per paragraph 4, section 3.2, it is =
clear that any CHALLENGE value which is not one of the last advertised =
in the Agent Advertisement message</SPAN></FONT></PRE><PRE><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"></SPAN><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt">"CHALLENGE_WINDOW&#8221; nor the one =
received in the last Registration Reply Message is considered =
UNKNOWN_CHALLENGE. </SPAN><SPAN style=3D"FONT-FAMILY: 'Times New =
Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: =
10.0pt"></SPAN></FONT></PRE><PRE><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt">This contradicts with paragraph 1 and 3 =
which suggest that there are USED =
CHALLENGES.</SPAN></FONT></PRE><PRE><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"><STRONG>I believe the RFC needs to identify =
the following:</STRONG><?xml:namespace prefix =3D o ns =3D =
"urn:schemas-microsoft-com:office:office" =
/><o:p></o:p></SPAN></FONT></PRE><PRE style=3D"MARGIN-LEFT: 0.5in; =
TEXT-INDENT: -0.25in; mso-list: l1 level1 lfo4; tab-stops: list .5in =
left 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt =
412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><FONT =
color=3D#0000ff><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; =
FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt">1.<SPAN style=3D"FONT: 7pt =
'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"><STRONG>USED_CHALLENGE_WINDOW </STRONG>with =
a default value of 2<SPAN class=3D828181603-31102001> just like the =
CHALLENGE_WINDOW</SPAN>.<o:p></o:p></SPAN></FONT></PRE><PRE =
style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l1 level1 =
lfo4; tab-stops: list .5in left 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt =
274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt =
687.0pt 732.8pt"><FONT color=3D#0000ff><SPAN style=3D"FONT-FAMILY: =
'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt">2.<SPAN =
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></SPAN><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: =
12pt; mso-bidi-font-size: 10.0pt">The meaning of the USED Challenge is =
any challenge that has been used in a RRQ message and accepted by the =
PDSN as a valid CHALLENGE and PDSN </SPAN></FONT></PRE><PRE =
style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l1 level1 =
lfo4; tab-stops: list .5in left 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt =
274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt =
687.0pt 732.8pt"><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; =
FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001></SPAN><FONT color=3D#0000ff> <SPAN =
class=3D384561003-31102001>      </SPAN>relayed/generated a RRP in =
response to that RRQ message</FONT></SPAN><FONT color=3D#0000ff><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt">.<o:p></o:p></SPAN></FONT></PRE><PRE =
style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l1 level1 =
lfo4; tab-stops: list .5in left 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt =
274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt =
687.0pt 732.8pt"><FONT color=3D#0000ff><SPAN style=3D"FONT-FAMILY: =
'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt">3.<SPAN =
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></SPAN><SPAN style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: =
12pt; mso-bidi-font-size: 10.0pt">&#8220;In all other =
circumstances&#8221; in paragraph 3 is very vague. We may need to =
elaborate a little bit to explicitly say that STALE_CHALLENGE will be =
generated </SPAN></FONT></PRE><PRE style=3D"MARGIN-LEFT: 0.5in; =
TEXT-INDENT: -0.25in; mso-list: l1 level1 lfo4; tab-stops: list .5in =
left 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt =
412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><SPAN =
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt"><SPAN =
class=3D384561003-31102001></SPAN><FONT color=3D#0000ff> <SPAN =
class=3D384561003-31102001>     </SPAN>whenever a USED CHALLENGE is =
sent in a RRQ message.</FONT></SPAN><FONT =
color=3D#0000ff>&nbsp;</FONT></PRE>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff><SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: =
'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D828181603-31102001>NOW the UNKNOWN CHALLENGE becomes any =
Challenge value=20
other than the one which was offered in last (<STRONG>NO Successful is=20
mentioned</STRONG>) Registration Reply issued to the <SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt">Mobile=20
Node, or else advertised as one of the last CHALLENGE_WINDOW (see =
section 9)=20
Challenge values inserted into the immediately preceding </SPAN><SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-bidi-font-size: 10.0pt">Agent=20
advertisements, or else</SPAN></SPAN></SPAN><SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: =
'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D828181603-31102001> has previously been used as one of the last =

USED_CHALLENGE_WINDOW (<SPAN class=3D115540519-31102001>to be added to =
section=20
9</SPAN>).</SPAN></SPAN></FONT></DIV>
<DIV><SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: =
'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D828181603-31102001></SPAN></SPAN><FONT =
color=3D#0000ff>&nbsp;</FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: =
'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D828181603-31102001>I hope this would help in clarifying this=20
issue.</SPAN></SPAN></FONT></DIV>
<DIV></SPAN></FONT>&nbsp;</DIV></DIV>
<P><B><I><FONT color=3D#0000ff face=3D"Times New =
Roman">Regards;</FONT></I></B> </P>
<P><B><I><FONT color=3D#0000ff face=3D"Times New Roman">Ahmad=20
Muhanna</FONT></I></B>&nbsp;</P>
<P><BR><FONT face=3DTahoma><BR><FONT size=3D2><SPAN =
class=3D115540519-31102001><FONT=20
color=3D#0000ff face=3DArial>&nbsp;</FONT></SPAN>-----Original=20
Message-----<BR><B>From:</B> Muhanna, Ahmad [RICH1:2Q23:EXCH] =
<BR><B>Sent:</B>=20
Monday, October 22, 2001 9:02 AM<BR><B>To:</B>=20
'mobile-ip@sunroof.eng.sun.com'<BR><B>Subject:</B> RE: [mobile-ip] =
URGENT -=20
rfc3012 interpretation question<BR><BR></P></FONT>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"></FONT>
  <P><FONT size=3D2>I agree. </FONT><BR><FONT size=3D2>I believe there =
is a couple=20
  of issues need to be clarified.</FONT> <BR><FONT size=3D2>One =
regarding Stale=20
  Challenge.</FONT> <BR><FONT size=3D2>The other regarding MN using the =
CHALLENGE=20
  received in the RRP with error code and the meaning of successful =
Registration=20
  Request.</FONT></P>
  <P><FONT size=3D2>I will provide details at later time. </FONT></P>
  <P><FONT size=3D2>Regards;</FONT> </P>
  <P><FONT size=3D2>Ahmad Muhanna</FONT> </P><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Erik=20
  Nordmark [<A=20
  =
href=3D"mailto:Erik.Nordmark@eng.sun.com">mailto:Erik.Nordmark@eng.sun.c=
om</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Monday, October 22, 2001 4:18 AM</FONT> =
<BR><FONT=20
  size=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT> <BR><FONT =
size=3D2>Subject: RE:=20
  [mobile-ip] URGENT - rfc3012 interpretation question</FONT> </P><BR>
  <P><FONT size=3D2>Whatever the best interpretation will be, the fact =
that this=20
  is subject</FONT> <BR><FONT size=3D2>to interpretation tells me that =
RFC 3012=20
  needs to be revised ASAP</FONT> <BR><FONT size=3D2>with a description =
which is=20
  clear on this point.</FONT> </P>
  <P><FONT size=3D2>Are there other issues that aren't (or weren't) =
clear to=20
  implementors</FONT> <BR><FONT size=3D2>of RFC 3012? Any issues that =
required=20
  sending a question on a mailing</FONT> <BR><FONT size=3D2>list or to =
the authors=20
  would seem like a good reason to get the</FONT> <BR><FONT =
size=3D2>spec=20
  clarified.</FONT> </P>
  <P><FONT size=3D2>&nbsp; Erik</FONT> </P><BR>
  <P><FONT size=3D2>&gt;----- Begin Included Message -----&lt;</FONT> =
</P>
  <P><FONT size=3D2>Date: Fri, 19 Oct 2001 15:47:24 -0500</FONT> =
<BR><FONT=20
  size=3D2>From: Mike_Borella@3com.com</FONT> <BR><FONT =
size=3D2>Subject: RE:=20
  [mobile-ip] URGENT - rfc3012 interpretation question</FONT> <BR><FONT =

  size=3D2>To: mobile-ip@sunroof.eng.sun.com</FONT> </P><BR><BR>
  <P><FONT size=3D2>I don't think that one can conclude that there is a =
security=20
  problem unless</FONT> <BR><FONT size=3D2>it is documented.&nbsp; A =
quick search=20
  of the web finds plenty of general concerns</FONT> <BR><FONT=20
  size=3D2>with</FONT> <BR><FONT size=3D2>MD5 but nothing about this =
particular=20
  issue.&nbsp; Does copying a byte in an n byte</FONT> <BR><FONT =
size=3D2>hash=20
  make it any less secure than the other interpretation which is an =
n-1</FONT>=20
  <BR><FONT size=3D2>byte hash?</FONT> </P>
  <P><FONT size=3D2>It is very clear that a literal reading of RFC3012 =
indicates=20
  that the byte</FONT> <BR><FONT size=3D2>should</FONT> <BR><FONT =
size=3D2>be=20
  copied.&nbsp; There are commercial deployments that already do it =
this=20
  way.</FONT> </P>
  <P><FONT size=3D2>-Mike</FONT> </P><BR><BR><BR><BR>
  <P><FONT size=3D2>"Robert J Marks" &lt;rjmarks@cambianetworks.com&gt; =
on=20
  10/18/2001 04:27:49 PM</FONT> </P>
  <P><FONT size=3D2>Please respond to =
mobile-ip@sunroof.eng.sun.com</FONT> </P>
  <P><FONT size=3D2>Sent by:&nbsp; "Robert J Marks"=20
  &lt;rjmarks@cambianetworks.com&gt;</FONT> </P><BR>
  <P><FONT size=3D2>To:&nbsp;&nbsp; mobile-ip@sunroof.eng.sun.com,=20
  charliep@iprg.nokia.com,</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pcalhoun@diameter.org</FONT> =
<BR><FONT=20
  size=3D2>cc:&nbsp;&nbsp;&nbsp; (Mike Borella/MW/US/3Com)</FONT> =
<BR><FONT=20
  size=3D2>Subject:&nbsp; RE: [mobile-ip] URGENT - rfc3012 =
interpretation=20
  question</FONT> </P><BR><BR>
  <P><FONT size=3D2>Although I am not sure of the intention in the RFC, =
I agree=20
  that the</FONT> <BR><FONT size=3D2>byte should not be duplicated in 2 =
places. I=20
  also seem to remember that</FONT> <BR><FONT size=3D2>known =
duplication tends to=20
  weaken the security.</FONT> </P>
  <P><FONT size=3D2>Bob</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  owner-mobile-ip@sunroof.eng.sun.com</FONT> <BR><FONT size=3D2>[<A=20
  =
href=3D"mailto:owner-mobile-ip@sunroof.eng.sun.com">mailto:owner-mobile-=
ip@sunroof.eng.sun.com</A>]=20
  On Behalf Of Nish Abrol</FONT> <BR><FONT size=3D2>Sent: Thursday, =
October 18,=20
  2001 12:14 AM</FONT> <BR><FONT size=3D2>To: charliep@iprg.nokia.com;=20
  pcalhoun@diameter.org;</FONT> <BR><FONT=20
  size=3D2>mobile-ip@sunroof.eng.sun.com</FONT> <BR><FONT =
size=3D2>Subject:=20
  [mobile-ip] URGENT - rfc3012 interpretation question</FONT> </P><BR>
  <P><FONT size=3D2>Pat/Charlie,</FONT> </P>
  <P><FONT size=3D2>Really appreciate any insights into this really =
important=20
  interop issue</FONT> <BR><FONT size=3D2>for cdma2000:</FONT> </P>
  <P><FONT size=3D2>A question regarding the&nbsp; interpretation of =
section 8 of=20
  rfc3012. This</FONT> <BR><FONT size=3D2>section specifies how to =
calculate the=20
  MN-AAA authenticator. It says:</FONT> </P>
  <P><FONT size=3D2>" To compute the authenticator, apply MD5 [11] =
computed on=20
  the</FONT> <BR><FONT size=3D2>following data, in the order =
shown:</FONT> </P>
  <P><FONT size=3D2>High-order byte from Challenge || Key ||</FONT> =
<BR><FONT=20
  size=3D2>MD5(Preceding Mobile IP data ||</FONT> <BR><FONT =
size=3D2>Type, Subtype=20
  (if present), Length, SPI) ||</FONT> <BR><FONT size=3D2>Least-order =
237 bytes=20
  from Challenge "</FONT> </P>
  <P><FONT size=3D2>The question is - if the challenge has less than =
237 bytes -=20
  should the</FONT> <BR><FONT size=3D2>high order byte which was =
already used in=20
  the MD5 calculation&nbsp; be</FONT> <BR><FONT size=3D2>included again =
as part of=20
  the&nbsp; "least-order 237 bytes from Challenge"?</FONT> </P>
  <P><FONT size=3D2>e.g. if the challenge is 50 bytes in length - =
should the=20
  authenticator</FONT> <BR><FONT size=3D2>be calculated&nbsp; =
as:</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; (a)&nbsp; authenicator =3D md5(byte0 || =
key.......||=20
  byte1 through byte49)</FONT> </P>
  <P><FONT size=3D2>or (b) authenticator =3D md5(byte0 || key ......|| =
byte0 through=20
  byte49).</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where byte0 is the =
most=20
  significant byte of the challenge.</FONT> </P>
  <P><FONT size=3D2>A strict reading of the RFC seems to suggest (b). =
However, it=20
  seems</FONT> <BR><FONT size=3D2>that calculating the MD5 =
authenticator with the=20
  same information(high</FONT> <BR><FONT size=3D2>order byte) at =
different=20
  locations of the payload weakens the</FONT> <BR><FONT=20
  size=3D2>authenticator.</FONT> </P>
  <P><FONT size=3D2>So, what was the intention of the RFC and how =
should it be=20
  implemented?</FONT> <BR><FONT size=3D2>Also, do you know if RFC3012=20
  implementations have participated in any</FONT> <BR><FONT=20
  size=3D2>bakeoffs/interops. If so, how have they interpreted this=20
  section?</FONT> </P>
  <P><FONT size=3D2>Your help will be really appreciated.</FONT> </P>
  <P><FONT size=3D2>Thanks</FONT> <BR><FONT size=3D2>Nish Abrol</FONT> =
<BR><FONT=20
  size=3D2>Qualcomm, Inc.</FONT> </P><BR><BR><BR><BR><BR><BR><BR>
  <P><FONT size=3D2>&gt;----- End Included Message -----&lt;</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1623F.7FC8C3D0--


From glass@onion.east.sun.com  Wed Oct 31 15:20:29 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29764
	for <mobileip-archive@odin.ietf.org>; Wed, 31 Oct 2001 15:20:28 -0500 (EST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01568
	for <mobileip-archive@lists.ietf.org>; Wed, 31 Oct 2001 12:19:51 -0800 (PST)
Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110])
	by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14329
	for <mobileip-archive@lists.ietf.org>; Wed, 31 Oct 2001 15:12:59 -0500 (EST)
Received: (from glass@localhost)
	by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA22176
	for mobileip-archive@lists.ietf.org; Wed, 31 Oct 2001 15:13:30 -0500 (EST)
Date: Wed, 31 Oct 2001 15:13:30 -0500 (EST)
Message-Id: <200110312013.PAA22176@onion.east.sun.com>
From: glass@east.sun.com
To: mobileip-archive@ietf.org
Subject: Test 1049 - regrettably necessary, please ignore!
reply-to: owner-mobile-ip@sunroof.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain


    Sorry for the wide distribution.  I'm tracking down something
that's being very elusive...

                              Cheers,
                                  Steve
                                  your email-alias sleuth



From owner-mobile-ip@sunroof.eng.sun.com  Wed Oct 31 15:36:09 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00452
	for <mobileip-archive@odin.ietf.org>; Wed, 31 Oct 2001 15:36:09 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11576;
	Wed, 31 Oct 2001 12:35:04 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15402;
	Wed, 31 Oct 2001 11:55:26 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VJsRQO007893
	for <mobile-ip-dist@sunroof.eng.sun.com>; Wed, 31 Oct 2001 11:54:27 -0800 (PST)
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VJsRKH007892
	for mobile-ip-dist; Wed, 31 Oct 2001 11:54:27 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VJsOQO007885
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 11:54:24 -0800 (PST)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08015
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 11:54:12 -0800 (PST)
Received: from idcpa4.pa.interdigital.com ([12.32.197.142])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29967
	for <mobile-ip@sunroof.eng.sun.com>; Wed, 31 Oct 2001 11:54:25 -0800 (PST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <RN09ZHAQ>; Wed, 31 Oct 2001 14:53:26 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1FA9F@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>
Subject:  [mobile-ip] Question of FA obtaining MAC addresses
Date: Wed, 31 Oct 2001 14:53:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mobile-ip@sunroof.eng.sun.com
Precedence: bulk
Reply-To: mobile-ip@sunroof.eng.sun.com
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:owner-mobile-ip@sunroof.eng.sun.com>
List-Subscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=subscribe>
List-Unsubscribe: <mailto:mobile-ip-request@sunroof.eng.sun.com?body=unsubscribe>

One of the "major changes" listed in rfc2002-bis is that the foreign agent
is not permitted to broadcast an ARP Request on all its local links, in
order to retreive the MAC address of a mobile node.

However, in RFC2002, I did not see any text that prohibits this action.
Could someone please confirm this, i.e. the FA is allowed to send Gratuitous
ARP's on its local links to determine MAC addresses, as per RFC2002?

Is the latter is acceptable, there there may be a backward compatibility
problem with existing deployments of foreign agents that do implement
Gratuitous ARP?

-Sharif.