Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 20 May 2009 13:19:47 +0200

Hi Ryuji,

>From the 4 main points I raised in my review, 3 have been clarified. 1
is IMHO still open. It is discussed after a summary of closed items (for
the records): 

 - Section 5.6, i.e. complex Home Link scenario w/o *explicit*
   rationale : 3GPP use case, described by Christian and Julien.

 - No ability to have traffic routed to the HoA : will be handled in
   flow-binding document.

 - Reuse of a single IPsec tunnel mode SA for traffic for all CoA:
   the hack is certainly difficult to implement but easier on RFC 4301
   compliant implementations. Thanks to Vijay for having coped w/ me on
   that one.

The last point regarding the reuse of K bit was still open so I took a
new look at what is in the draft. I'd like to clarify the expected
behavior for the common case.

The idea developed in section 9.1 of the draft is that the MN sends a
BU with K bit set *and* a single BID mobility option to update the CoA
which must be used by IKE. The HA receiving that BU will inform the IKE
daemon on its side with the CoA with the BID. 

The thing is that if the IKE module on the MN supports movement, K bit
will be set in all BU. It would not make sense ("MCoA keeps backward
compatible with 3775") but it is probably worth asking the question
before going further: does MCoA draft change that behavior?

Now, let's consider a MN whose IKE module supports movement (its HA
too). It will have K-bit set in all its BU. Let's say the MN currently 
has two CoA on different interfaces: CoA1 and CoA2 registered with its
HA. Each one is associated with a given BID. Let's consider CoA1 is
currently used for IKE traffic to the HA. Now, due to a handover, the MN
configures a new address instead of CoA2. CoA1 had not been modified so
the MN does not have to request an update of IKE address to the HA. But
the MN needs to warn its HA about the address change. It cannot send a
BU with K bit set and only the BID mobility option with the updated CoA2
value. How is this handled?

Cheers,

a+

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 20 May 2009 15:01:52 -0700

Hi Arnaud,

> before going further: does MCoA draft change that behavior?

With MCoA draft, the 'K' bit is set in a BU only if there is a change in 
the "primary CoA", i.e., the CoA with which the IKEv2 SA was created. 
All other BUs sent by the mobile node can have the 'K' bit unset.

Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for a 
binding refresh when there is no change in CoA. When the CoA changes, 
the MN can set the 'K' bit in the BU sent to update the CoA.

> value. How is this handled?

It would send a BU with the 'K' bit unset, CoA2 information and the BID 
associated with CoA2. It can also include CoA1 information and the BID 
associated with CoA1 in the BU.

 From the beginning our goal was to avoid creating a new mechanism to 
update the care-of address information in the IKEv2 and IPsec SAs. We 
are trying to re-use what is there in RFC 3775.

Vijay

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 21 May 2009 11:32:15 +0200

Hi Vijay,

Vijay Devarapalli <[email-masked]> writes:

> With MCoA draft, the 'K' bit is set in a BU only if there is a change
> in the "primary CoA", i.e., the CoA with which the IKEv2 SA was
> created. All other BUs sent by the mobile node can have the 'K' bit
> unset.

At least, this clarifies the expectations of MCoA draft on the
topic. IMHO, this would have been better to state that explicitly but
considering previous discussions, I guess it is too late now :-b

> Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for
> a binding refresh when there is no change in CoA. When the CoA
> changes, the MN can set the 'K' bit in the BU sent to update the CoA.

Rereading Section 10.3.1 of RFC 3775, the binding refresh case when
there is no change of CoA does not exist. As usual, the content of a new
BU basically replace the content of the previous one in the BCE. In
section 10.3.1, the processing performed by the HA is done *only* based
on the value of the K bit it sets *in its BA* (section 10.3.1). When the
K bit is 0, the action is to "discard the key management connections, if
any, to the old care-of address" (the one in the BCE).

What I say is that an implementation which *strictly* follows what is in
section 10.3.1 will just discard the key management connections to the
old CoA.

Nonetheless, I think what you describe is valid and it makes sense to
consider that *in all cases* implementations specifically handle the
binding refresh with no change of CoA (and not even look at K bit value
in that specific case).

Thanks for your thoughts,

Cheers,

a+

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 May 2009 13:48:31 -0700

Hi Arnaud,

Arnaud Ebalard wrote:

> there is no change of CoA does not exist. 

No. The mobile node would send a BU to refresh an existing binding if 
the lifetime is about to expire, even if there is no change in CoA. 
Maybe this is not explicitly pointed out in section 10.3.1. Section 
11.7.1 says

    Also, if the mobile node wants the services of the home agent beyond
    the current registration period, the mobile node should send a new
    Binding Update to it well before the expiration of this period, even
    if it is not changing its primary care-of address.

> As usual, the content of a new

So I am going to conclude that there is no need for any change in the 
MCoA document on this issue.

> Thanks for your thoughts,

No problem. Your detailed reviews are always welcome.

Vijay

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 22 May 2009 00:02:32 +0200

Hi,

Vijay Devarapalli <[email-masked]> writes:

> the lifetime is about to expire, even if there is no change in
> CoA. Maybe this is not explicitly pointed out in section
> 10.3.1. Section 11.7.1 says
>

Sorry, I meant "the specific 'K' bit processing you describe for a
refresh w/o CoA change" does not exist. The processing (including K bit
one) is described for all kinds of BU, no matter if they create or
refresh a binding.

I obviously did not mean binding refresh is not defined. 

> MCoA document on this issue.

Right.

Cheers,

a+