Subject: [Mobike] Proposal for revised charter

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Mar 2006 16:20:37 -0600

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.
+

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 23 Mar 2006 00:09:40 +0100

In your previous mail you wrote:

   As discussed in yesterday's meeting, below is a proposal for a  
   charter delta, to address transport mode.

=> please remember there were 12 vs 10 against an extension to transport
mode, so obviously there is no rough consensus to revise the charter
this way.

Regards   

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