Subject: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 5 Apr 2006 16:29:21 -0700

Hello all,

I want to add some more text to 
draft-ietf-mip6-ikev2-ipsec to clarify the use
of "tunnel all" mode. a pre-06 version of the
draft is at
http://www.dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt
a diff from version 05 to 06 is at
http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html

the current status for this draft is "AD 
Evaluation". it was felt that the changes are 
significant enough to refer the changes to the
working group before making the changes. there
will be a short working group call later on
on these changes.

the tunnel mode was already introduced with 
the addition of the section on IPsec granularity 
considerations in version 04. the new text is
only for better clarity.

comments are welcome.

Vijay

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Shinta Sugimoto <[email-masked]>
Date: Sun, 09 Apr 2006 21:01:34 +0300

Hello Vijay,

I've parsed the diff from 05 to 06 and had some comments/questions.
In the "tunnel all" mode, do you assume that the IKEv2 takes the
role of updating the outer endpoint address of the IPsec tunnel
established between the MN and HA ?  I mean, in my view, BU message
meant to be the trigger for updating the endpoint address.  In this
sense, it is actually convinient for the MN and HA to have transport
mode SA pair which is agnostic on MN's CoA.  If we assume that all
mobility signals (including BU) are sent over the IPsec tunnel,
I believe MN and HA are required to run MOBIKE (or re-establish the
IPsec SA) prior to the home registration.  So, I think the draft
should mention implications/side-effect that "tunnel all" mode have.

Regards,
Shinta

On Wed, 5 Apr 2006 16:29:21 -0700

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Apr 2006 17:40:21 +0200

I have three comments (in next messages) about:
 - whether the "tunnel all" mode needs a requirement keyword and which one
 - compatibility issue with existing (not really new nor fully bound
   to the "tunnel all" mode)
 - consequences for IPsec/IKE.

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 17 Apr 2006 22:43:22 +0200

The "tunnel all" mode was "MUST NOT", now we can make it optional
("MAY"), recommended ("SHOULD") or mandatory ("MUST"):
 - the reason of the "MUST NOT" was compatibility with the standard mode
   (but look at the next message).
 - "MAY" is the simplest, it only adds a new option
 - "SHOULD" can be argued because it is more in the line of the "all"
   idea and avoids to give a choice (i.e., to become incompatible)
 - "MUST" IMHO is too early because it makes some current implementations
   both incompatible and not compliant.
Note that the current wording could be interpreted as an implicit MAY?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 17 Apr 2006 22:52:57 +0200

The second point is compatibility with current implementations: the
"tunnel all" mode is clearly not compatible as it introduces a new
choice.
But in fact the current (previous soon :-) specs don't enforce full
compatibility because the SA pairs for BU/BA and for MPS/MPA protections
can be shared or not. So if we consider the "tunnel all" mode as a
super sharing option, it is just a third case...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 17 Apr 2006 23:06:37 +0200

The "tunnel all" mode has some impacts on IPsec:
 - there is no more transport mode SAs: the IPsec config is far simpler.
 - all packets between the MN and the HA are through the tunnel: there are
   no difference (at the exception of the MIPv6 signaling for mobility
   control) with a mobile IPsec VPN with the MN in the client role and
   the HA in the Security Gateway role.
 - the K flag (again) is very useful: the MIPv6 signaling updates the SPD
   and the SAD but can't directly update the IKE internal state (this is
   the role of the K flag stuff).
 - actions at home are not very clearly defined: one can delete the tunnel
   as usual or keep it in order to make the home position not so special
   (cf monami6 stuff for development of this kind of ideas),

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Apr 2006 15:19:50 -0700

> Note that the current wording could be interpreted as an implicit MAY?

MAY sound good to me.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Apr 2006 15:27:43 -0700

> super sharing option, it is just a third case...

I am not sure I understand the concern.

there is still a "MUST" for the packet
formats specified in RFC 3775. the tunnel
all mode is optional. so there shouldnt
be an interop issue.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Apr 2006 15:30:51 -0700

>    the role of the K flag stuff).

agree with the above.

>    (cf monami6 stuff for development of this kind of ideas),

both are possible. the mobile node can explicitly
tear down the tunnels, keep the tunnels or just let
the IPsec SAs expire.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Apr 2006 19:13:23 +0200

In your previous mail you wrote:

   
   
=> the MN and the HA must either both be configured to use the tunnel
all mode or the old RFC 3775 style. But this is not a new constraint
as they already had to be configured to share or not the transport mode
SAs for BU/BA and MPS/MPA, i.e., we add only a new option to an already
existing issue (so this is not a concern).

Regards