Proposal for revised charter
Pekka Nikander <[email protected]> Wed, 22 Mar 2006 16:20:37 -0600
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
As discussed in yesterday's meeting, below is a proposal for a
charter delta, to address transport mode. In practical terms, the
work could consist of the following:
1) Complete BEET in terms of fragmentation etc. support (as noted by
Michael Richardson)
2) Perform security analysis on how BEET could be used in security
gateways
3) Add necessary IKE extensions (probably minimal) so that non-
transport gets supported.
I can see that the WG may not have the interest and energy for this,
as tunnel mode already works. Hence, from my point of view, quite a
lot depends on whether there would be volunteers to do the work. I
am volunteering to read the resulting specs, but I can't promise to
do much else.
--Pekka
--- mobike-charter.orig 2006-03-22 16:08:56.000000000 -0600
+++ mobike-charter.proposed 2006-03-22 16:14:54.000000000 -0600
@@ -18,19 +18,10 @@
protocol. In particular, the WG shall NOT develop mechanisms for the
following functions:
-o Hiding of mobility from transport layer protocols or applications
- (beyond what already exists through the use of the tunnel mode). In
+o Hiding of mobility from transport layer protocols or applications. In
this respect MOBIKE is different from Mobile IP, HIP, and other
mobility protocols.
-o IP address changes done by third parties (NATs, firewalls etc). In
- particular, MOBIKE shall not replace or modify IKEv2 NAT traversal
- function. MOBIKE handles IP address changes initiated by one of the
- endpoints of the security associations. NAT traversal handles other
- address changes. MOBIKE should not be tightly coupled with the NAT
- traversal function, but it is necessary to specify in which cases
- (if any) they can be used together, and how they interact.
-
o Opportunistic authentication or other tools for the reduction of
configuration effort. The mechanisms specified in this WG are to be
designed for the traditional VPN use case only.
@@ -43,9 +34,9 @@
o Use of IKEv1.
-Work Items
+Past Work Items
-The goals of the MOBIKE working group are to address the
+In the past, the MOBIKE working group has succesfully addressed the
following issues:
(1) IKEv2 mobile IP support for IKE SAs. Support for changing and
@@ -68,17 +59,21 @@
from certificates, or through the use of a return routability
mechanism.
+Current Work Items
+
(5) Reduction of header overhead involved with mobility-related
tunnels. This is a performance requirement in wireless
environments.
(6) Specification of PFKEY extensions to support the IPsec SA
movements and tunnel overhead reduction.
+
+(7) Non-tunnel-mode use. This may involve addressing IP address
+ changes performed by third parties, such as NATs and firewalls.
+ However, MOBIKE shall not replace IKEv2 NAT traversal function but
+ it may extend it to support non-tunneled use cases. While NAT
+ traversal handles address changes performed by NATs, the current
+ solution works only with tunnel mode. To address non-tunnel mode
+ SAs, MOBIKE may be coupled with the NAT traversal function, if
+ necessary.
+