Subject: [nemo] NEMO Solution Requirements Process

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 24 Oct 2002 11:50:09 -0700

This week, we have been discussing the issue of how to begin work on 
producing the documents which the NEMO wg has promised to deliver. This 
involved process begins with defining the requirements of Phase I of our 
work: the non-optimized reachability support using reverse tunneling. 
Our ADs have been helpful in suggesting how to make good forward 
progress on this, and we would like to share the process that was 
proposed, and what we feel is necessary to build momentum at this point.

Firstly, one of our goals is to start discussing the various facets of 
the requirements as they have been proposed right away. This way, we can 
identify the areas of agreement straight off, and discuss the 
controversial topics one by one.

In order to take all viewpoints into consideration, we would like to 
have as a starting point all requirements documents that were previously 
discussed in the BOF sessions. Since these are individual drafts which 
have expired, we ask those authors to resubmit them before the draft 
cutoff. If others have already written text on ideas for requirements that
are ready for discussion, they can be put into draft form as well,
minding the fast approaching cut-off for new drafts.

Once we have these drafts, it will be helpful if a reviewer can go through
them to see the common points of agreement, the deltas between the 
documents; i.e. points of difference, and unique ideas which may only be 
found in one or two drafts. After having this information, we can 
discuss these points on the list and reach a consensus in an organized
way.

For the IETF, we have requested a 2 hour slot, when we can have some 
further analysis of open issues in the Requirements, and other topics as 
will be outlined in the agenda.

And finally, we were wondering whether anyone has begun to think about 
the threats analysis document and has come up with any material on that 
topic.

Thanks,

TJ & Thierry

---

From: Alexandru Petrescu<[email-masked]>
Date: 25 Oct 2002 14:13:19 +0200

> work: the non-optimized reachability support using reverse

Yes, we should concentrate more on requirements that are related to
the MRHA tunnel kind of solution.  For example, requirements that are
related to RO, or requirements that are related to it being
transparent to TCP are no longer relevant now.  We now know that this
is transparent to TCP and that RO is for later.

IMHO, what we need to require is things like how is the link-local
address supported in Mobile IPv6, because MR is a router and normally
uses its ll address for exchanging routing info.  Requirements like
that.

> the threats analysis document and has come up with any material on that 

Yes, we begun thinking about security threat analysis, but not about
the document :-)

Threat analysis is much simplified when the MRHA-like Mobile IPv6
solution is clearer.  There are still many open questions about that
solution.

As with the MRHA requirements, the security threat analysis should
address only the MRHA-like solution, not the RO.  It should find out
whether using MR instead of MH in Mobile IPv6 introduces new threats
and what kinds of threats.  For example, in the MH case, a possible
threat is that MH1 impersonates MH2, where MH1 and MH2 have the same
HA.  This is countered by securing the MHHA tunnel.

In the MR case, when MR acts as an MH too, and if that MH develops an
SA with a CN (via return routability tests), then it must not be
possible for the LFN's to take advantage of that SA in order to
communicate with the CN.

When the MR is at home, and MR maintains secure classical secure
routing (like authenticated RIP or authenticated OSPF) with its
routers at home, then that classical secure routing should be
maintained when the MR is not at home.

Things like that.  But I bet there are many more.

Alex