Subject: [Mip6] [issue68] The use of K bit

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 05 Mar 2006 22:06:50 +0000

New submission from Vijay Devarapalli <[email-masked]>:

Jari Arkko wrote:

  o  If the mobile node has used IKEv2 to establish security
     associations with its home agent, it should follow the procedures
     discussed in Section 11.7.1 and 11.7.3 of the base specification
     [2] to determine whether the IKE endpoints can be moved or if the
     IKE SA has to be re-established.

    o If the home agent has used IKEv2 to establish security
    associations with the mobile node, it should follow the procedures
    discussed in Section 10.3.1 and 10.3.2 of the base specification
    [2] to determine whether the IKE endpoints can be moved or if the
    IKE SA has to be re-established.

Hmm... I wonder if we really want to carry the K bit scheme
forward. I saw that as an intermediate solution. There's
no requirement for you to handle everything in this spec,
you can also streamline & simplify. Also, I would prefer the
above text to allow IKEv2-specific address changes. In
particular, there seems to be no reason to disallow
automatic NAT-T address changes or even MOBIKE. None
of that has any effect on Mobile IPv6, as long as the
client still sends a correct Mobile IPv6 Binding Update
inside. And MOBIKE is already referenced from elsewhere
of the spec, so this is also a consistency issue.

Same issue in Section 7.3.

----------
category: Technical
draft: draft-ietf-mip6-ikev2-ipsec
messages: 208
nosy: vijay
priority: Must fix
status: Pending
title: The use of K bit

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue68>
_________________________________________________

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Mar 2006 00:05:38 +0100

In your previous mail you wrote:

   category: Technical
   
=> I am strongly in favor of the K bit in the IKEv2 case because we
don't want at all have to close/reopen IKE SAs (IKEv2 "session" for
not-IPsec folk) at each handoff, which by side-effect in IKEv2 includes
close/reopen all IPsec SAs between the MN and the HA, i.e., even the
transport mode SA pair for BU/BA protection.
So clearly a smooth handling of handoff is needed for IKE SAs, and this
is exactly what the K bit stuff does. BTW the K bit stuff is easier to
implement in IKEv2 than in IKEv1 IMHO, there is no orphan IPsec SA pair
for instance (orphan = with no link or a weak link to an IKE SA).

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Mar 2006 00:23:12 +0100

=> nearly the same answer with an extra proposal.

   category: Technical
   
=> I am strongly in favor of the K bit in the IKEv2 case because we
don't want at all to have to re-establish IKE SAs (IKEv2 "session" for
not-IPsec folk) at each handoff, which by side-effect in IKEv2 includes
to re-establish all IPsec SAs between the MN and the HA, i.e., even the
transport mode SA pair for BU/BA protection...
So clearly a smooth handling of handoffs is needed for IKE SAs, and this
is exactly what the K bit stuff does. BTW the K bit stuff is easier to
implement in IKEv2 than in IKEv1 IMHO, there is no orphan IPsec SA pair
for instance (orphan = with no link or a weak link to an IKE SA).
As the K bit is not a negociation, i.e., it can be used only to detect
misconfiguration (one side doesn't support IKE endpoint address update
when it is expected to support it), I propose to reverse Jari's proposal
and to recommend (i.e., put a SHOULD) the support of the K bit stuff.
Any comment/concern/support?

Thanks

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Sun, 5 Mar 2006 15:37:00 -0800

> for instance (orphan = with no link or a weak link to an IKE SA).

I agree. perhaps someone from the last TAHI interop
can do a presentation at the IETF meeting. there were
interoperable implementations of the 'K' bit.

Vijay

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 07 Mar 2006 11:19:16 +0900

Hello,

Let me comment on the treatment of K-bit.  First, I need to clarify
what we are discussing.  I assume that we almost agree on a point that
updating IKE internal state (namely the IP address on which IKE runs)
in accordance with MN's movement is a good thing because it simply helps
to reduce IKE signaling messages exchange between MN and HA.  I assume
that the issue is whether if K-bit is necessary in BU/BA message in
order to make it work, in particular, we should avoid any
problem which may be caused by inconsistency of IKE internal states
maintained by the HA and MN.  I see there is a problematic situation
where (assuming that MN is Initiator and HA is Responder in respect of
IKE) MN is capable of dynamically updating IKE internal state but the HA
is not.  In such case, the Responder (HA) will be confused when it
receives subsequent IKE messages from its peer with different IP address.
So, I think we should keep K-bit.  Regarding the wording, I don't have
strong opinion on whether we should make it "SHOULD" or keep it as is
(should).

BTW, updating IKE internal state can be done by MOBIKE or possibly
other mechanisms and such options should be allowed.  And I don't see
any problem with keeping K-bit in this respect.  FWIW, I personally
think that running MOBIKE in conjunction with MIPv6 is kind of a
duplication (redundant operation) in a sense that the same problem
is handled by two entities.  Semantically MIPv6 binding registration
and SA address update in MOBIKE are more or less the same.

Regards,
Shinta

On Mon, 06 Mar 2006 00:23:12 +0100