Subject: [Mobike] MOBIKE work

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jun 2004 18:04:52 +0300

This list has been quiet for too long, given the level of
interest people have expressed off-line. We would love to
get the WG moving again so that we can move towards getting
the protocol written. To that end, we have asked Tero to
update the problem statement document. In order to do that,
he needs more input on what the WG thinks about some of the
open issues.

Once we have more stability in the problem statement document,
the editors of the three proposed protocol drafts can respond
more intelligently in updated versions. That is, if we give a
better set of parameters to the design space, the protocols
will move towards those parameters. At that point, it will be
easier to pick which protocol proposal(s) to move forwards with.
In any case, the three editors have promised to update their
documents for San Diego.

The next few e-mails are about the open issues in the MOBIKE design.

Please respond to the e-mails and let us know what you think should
be done to the issues. There are probably some more issues as well --
if you think you have an issue that has not been discussed, please
post that to the list as well, with a new Subject: line.

At this time we would like to focus the discussion on the
first group of issues, the user visible "requirements". This is
because it seems that those issues have a big impact on the
protocol design, and getting an answer to them will help us
move forward.

We have grouped the issues as follows:

User-level visible "requirement" issues:
========================================

- Level of support for NAT-T - MOBIKE interaction?
- Should MOBIKE react to problems that are not
   known locally: your interface went down vs. some router
   on the path died?
- How much protection against 3rd party bombing should
   MOBIKE offer?
- Should MOBIKE support movement from IPv4 to IPv6 and
   vice versa?
- Are simultaneous movements of two mobile nodes
   supported by MOBIKE?

Other issues which clearly need a lot of work:
==============================================

- Explicit vs. implicit address changes.
- Whether MOBIKE handles changes to individual addresses
   or paths (= address pairs).
- How to do path testing & congestion control?

Smaller issues that might be easy to decide:
============================================

- Signaling support for MOBIKE.
- What the role of MOBIKE return routability tests
   is versus other similar tests in other protocols,
   such as Mobile IPv6?
- Are empty informational exchanges sufficient for
   return routability test, or is a cookie needed?
- Is a set of zero addresses allowed?
- Move all SAs at once, or allow individual movements?
- Window size issues.

Paul & Jari

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 17:49:54 +0200

In your previous mail you wrote:

=> I like the requirement/mechanism/policy grouping but...

=> this is a policy issue with another suit, or do you refer
to what I call the "transient pseudo-NAT attack"?

=> in fact this is more a charter issue (:-)!

=> are signaling and mechanism the same thing. I don't understand
the question for sure.

=> this question has no meaning (i.e., the answer is trivial)
in the IKEv2 context.

=> interesting question but not a "small issue" at all!

=> not small too, IMHO this is the main difference between my and
Tero's proposal.

   - Window size issues.
   
=> can you explain? IKEv2 is a sequenced protected exchange protocol.

Thanks

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike