Subject: [MEXT] On CE NEMO RO Requirements

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 13 Mar 2008 01:41:02 +0800

Hello all, 

As Marcelo has pointed out in the meeting today, some form of feedback
is needed for this draft to moved on.  Lack of feedback can means that
the WG is not interested in this work (didn't seem so in Vancouver where
I managed to attract quite a line at the mic ;)), or arguably I can
choose to interpret it as the WG does not object to this work.

I think some response is better, so I urge people to comment on it, even
if you only say that you think this draft should become a WG document is
better than no comments.

Thanks,

/rgds
/cwng

On Mon, 2008-02-18 at 23:04 +0800, Chan-Wah Ng wrote:
> Hello all,
> 
> we have published a new version of the CE requirements for NEMO RO --
> see forwarded mail below.
> 
> The changes include:
> *  Added "Protocol Harmony" as requirement
> *  Added "Separability" and "Multihoming" as desired feature
> *  Elaborated more on some of the explanations of requirements
> 
> The draft is also currently more in-line with the aeronautics's draft
> in terms of format.
> 
> /rgds
> /cwng
> 
> 
> -------- Forwarded Message --------
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
> Subject: I-D Action:draft-ng-nemo-ce-req-02.txt
> Date: Mon, 18 Feb 2008 06:15:01 -0800 (PST)
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Consumer Electronics Requirements for Network Mobility Route Optimization
> 	Author(s)       : C. Ng, et al.
> 	Filename        : draft-ng-nemo-ce-req-02.txt
> 	Pages           : 16
> 	Date            : 2008-02-16
> 
> This document illustrates different deployments of Network Mobility
> (NEMO) from the consumer electronics perspective.  From these
> deployments, a set of requirements is deduced for Route Optimization
> (RO) with NEMO.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ng-nemo-ce-req-02.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-ng-nemo-ce-req-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:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ng-nemo-ce-req-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.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/i-d-announce
> _______________________________________________
> MEXT mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 18 Mar 2008 10:29:06 -0500

The draft is clear enough, in my opinion.  The questions I have
about the content are mostly due to my not being an expert in
the particular subject area of CE, and may not be specific to
RO for CE devices.  Here are some comments:

(1) Is it typical for a handset or other device in a PAN to have
enough router functionality for other devices to connect to it?
I suppose it would have to send RAs or act as a DHCP server on
the PAN.  How would devices know to prefer connection to this
router rather than using their own WLAN or GPRS links?  The
draft describes local mobile nodes like laptops and PDAs which
probably have such links of their own and might also be trying
to act as mobile routers in the PAN, and I don't see how leader
election or something similar is done.  This seems more fundamental
to the personal mobile router concept and not really a concern
with RO itself.

(2) The pictures in the draft are very nice.

(3) Req3: Security - Should this specify that the additional risk
to be avoided beyond the risk of running MIPv6/NEMO?  I think you
could more specifically scope it so that the acceptable level of
risk would be that of the nodes within the MNP running MIPv6 RO
themselves, so that the same security concerns for 3775 RO apply.

The requirements for the mobile router's security could then be
separated from the requirements for the nodes within the MNP.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2008 19:03:06 +0100

Hi Wesley and thanks for comments,

Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> The draft is clear enough, in my opinion.  The questions I have about
>  the content are mostly due to my not being an expert in the 
> particular subject area of CE, and may not be specific to RO for CE 
> devices.  Here are some comments:
> 

WEll depends who one is asking.  For example, a Windows Mobile PDA of
these days does run a DHCP Server and has several wireless interfaces,
and runs NAT and static routing, and IPv4 link-local addresses.  For
other prototyping projects there are many other devices running linux
doing same.

> I suppose it would have to send RAs or act as a DHCP server on the 
> PAN.

For linux PDA prototypes well yes, there are RAs sent by the PDA or even
by the mobile phone.

> How would devices know to prefer connection to this router rather 
> than using their own WLAN or GPRS links?

That's a good question and often comes down to manually pre-configuring
the devices with a certain behaviour they should do.  But it's true that
by default it may very well be that a certain device prefers connecting
straight to GPRS or the WLAN link, instead of going to the Personal
Mobile Router.  In order to prefer the PMR the device should have
incentive to do so, and in some prototyping demo the incentive is to be
offered continuous session by the PMR (because typical device's stack
doesn't do MIP whereas PMR does).

> The draft describes local mobile nodes like laptops and PDAs which 
> probably have such links of their own and might also be trying to act
>  as mobile routers in the PAN, and I don't see how leader election or
>  something similar is done.  This seems more fundamental to the 
> personal mobile router concept and not really a concern with RO 
> itself.

To me that seems reasonable to say.  It may very well be that RO as many
know and try to deal with does not cover the dynamic configuration of a
PAN, whose tool may be electing a leader out of many.  In this sense,
these PAN scenarios are very different than what the aero industry
describes, maybe the aero method of achieving optimal paths is not same
as methods in a PAN.

I think it's good to say which is which and delineate the scope.

> (3) Req3: Security - Should this specify that the additional risk to
>  be avoided beyond the risk of running MIPv6/NEMO?  I think you could
>  more specifically scope it so that the acceptable level of risk
> would be that of the nodes within the MNP running MIPv6 RO

Ok, this goes already assuming PMR runs MIP6/NEMOv6.

I think we can say that, when PMR runs MIP6/NEMOv6, the acceptable level
of risk of any new protocol is the same risk as when MHs attaching to MR
were running RO.

I think it's difficult to grasp that technically but at the same time I
think it's good indeed to scope the security landscape of any new tool
we're about to define, relying on previous threat analysis.

In a security section one would also like to identify who are the
attacker devices and their motivation.  For example a PMR pretending to
offer continuous sessions to visiting MNs but otherwise stealing their
legitimate traffic, or similar.  There may be others.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 19 Mar 2008 13:22:04 +0800

Hello,

Thanks you for your comments, response in line.

On Tue, 2008-03-18 at 10:29 -0500, Eddy, Wesley M. (GRC-RCN0)[VZ]
wrote: 
> the PAN.  

Yes, the typical processor found in mobile phones has already surpass
the basic capability to function as a router.  In fact, current high end
models already have processing power beyond that of a cheaper home
router that one can find in the market.  Power consumption is the
primary design consideration nowadays, not the processing power.

> How would devices know to prefer connection to this

In the absence of a leader election mechanism (such as those found in
bluetooth), one can fallback to user configuration.  This is similar to
your pairing bluetooth devices. I envision that the user would be
presented with a GUI for selecting the paired device and also the paired
mode, whether it should act as an MNN or an MR.

And anyway, as you have mentioned, this has nothing to do with RO ;)
The consumer electronics industry is very good at adapting, and I am
sure other vendors would come up with more creative ways to realize the
PMR and a PAN than what I have described above.

> (2) The pictures in the draft are very nice.

Thanks, compliments to Alex.

> themselves, so that the same security concerns for 3775 RO apply.
Phrasing it that way does seems reasonable from one point of view,
however, one may object to the hint of a MIPv6-RO-like solution.   My
initial intention was to restrict the threats to the same level as NEMO
Basic Support (but perhaps that seems too stringent?).

> separated from the requirements for the nodes within the MNP.

I don't see why there would be requirements for the MNNs ... by all
scenarios listed in the draft, the MNNs would be pure IPv6 nodes.

/rgds
/cwng