Subject: [MEXT] De-resgistering bindings in MCoA draft

From: Hesham Soliman <[email-masked]>
Date: Wed, 17 Dec 2008 00:43:33 +1100

Hi, 

I have a comment on this aspect of the spec. The removal of BIDs based on
zero lifetime is completely inconsistent with the processing of the BU in
MIPv6. The lifetime should be for the entire binding cache for the home
address. BIDs should be removed by explicitly by requesting a removal
operation in the BID fields (or by simply excluding them from the new BU),
not by giving them separate lifetimes. I don't see any reason for
complicating things this way. This is not how a binding update is supposed
to work. The way it works is that one BU replaces the previous one.

Hesham

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 16 Dec 2008 09:27:49 -0800

Hi Hesham,

I agree we need to clarify better how lifetime and multiple bindings are handled, considering also the interactions with flow bindings.

It's right that based on RFC 3775 one BU replaces the previous one, but we need to understand how this applies to multiple bindings. Saying that every BU replaces the previous one in this context implies that the MN needs to include at any BU all the BIDs (and if flow bindings are supported all the FIDs). This is not acceptable as it makes bulk registration mandatory and increases the signaling overhead to an unacceptable value.

The current solution in the draft works but there may be cleaner solutions. 

One cleaner solution would be to treat every BID as logically separate with its own lifetime. In this case if the BID is present in the BU the lifetime of the BU itself is ignored. This approach would keep the principle "one BID replaces the previous one" alive. It is still true that if a BU does not include any BID, then it replaces the entire HoA BCE (i.e. removing or updating all the BIDs). 

Another possibility is that we assume all BIDs have the same lifetime, which is the lifetime in the BU. However to remove a BID the MN explicitly indicates that with a flag in the BID option. This changes a bit the nature of the MIPv6 signaling.

I think the first approach seems the cleanest one. What do you think?

Cheers
Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hesham
> Soliman
> Sent: Tuesday, December 16, 2008 5:44 AM
> To: [email-masked]
> Subject: [MEXT] De-resgistering bindings in MCoA draft
> 
> Hi,
>

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 17 Dec 2008 09:42:10 +1100

Hi Gerardo,

> Hi Hesham,
> 
> I agree we need to clarify better how lifetime and multiple bindings are
> handled, considering also the interactions with flow bindings.
> 
> It's right that based on RFC 3775 one BU replaces the previous one, but we
> need to understand how this applies to multiple bindings. Saying that every BU
> replaces the previous one in this context implies that the MN needs to include
> at any BU all the BIDs (and if flow bindings are supported all the FIDs). This
> is not acceptable as it makes bulk registration mandatory and increases the
> signaling overhead to an unacceptable value.

=> That's why the FIDs are not included in full for refreshes or deletes. We
only send the index. I understand your reasoning, but I think in practice
there will rarely be a case where you have more than 2, or max 3 BIDs. So,
it's hardly going to be overloading the LTE links. Anyway, assuming that
this is an issue, please see my suggestion below.

> One cleaner solution would be to treat every BID as logically separate with
> its own lifetime. In this case if the BID is present in the BU the lifetime of
> the BU itself is ignored. This approach would keep the principle "one BID
> replaces the previous one" alive. It is still true that if a BU does not
> include any BID, then it replaces the entire HoA BCE (i.e. removing or
> updating all the BIDs).
> 
> Another possibility is that we assume all BIDs have the same lifetime, which
> is the lifetime in the BU. However to remove a BID the MN explicitly indicates
> that with a flag in the BID option. This changes a bit the nature of the MIPv6
> signaling.

=> Not sure how the second approach works to avoid sending all BIDs.
There is a simple way to address this I think. All BIDs have the BU's
lifetime (which is how it should work).
You send a list of BIDs that need to be refreshed in each BU. Just the
numbers for the BIDs themselves. If a number is not in the list then it is
effectively removed.
The list is essentially a compression mechanism for the BID option. You only
need to send the full option if you're changing some of the option's
attributes. 

> I think the first approach seems the cleanest one. What do you think?

=> I don't like having different lifetimes for the same HoA bindings. It
makes life unnecessarily complex. I can't find any scenario where the MN
will want to explicitly have different lifetimes for different flow bindings
or CoA bindings. 

Hesham

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 16 Dec 2008 15:03:35 -0800

Hi Hesham,

> From: Hesham Soliman [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2008 2:42 PM
> To: Giaretta, Gerardo; [email-masked]
> Subject: Re: De-resgistering bindings in MCoA draft
> 
> 
> Hi Gerardo,
> 
> > Hi Hesham,
> >

Yes, let's assume that as it is an issue if we want to apply this to 3GPP.

> => Not sure how the second approach works to avoid sending all BIDs.

A Refresh BU will always include all BIDs. But adding a BID and removing a BID would not require all BIDs.

> numbers for the BIDs themselves. If a number is not in the list then it is

The issue I have in general with bulk registration (and your proposal is extending the lifetime of all BIDs with one BU so it is basically a compressed bulk registration) is that it may be considered not optimal from a security point of view. Basically the usage of bulk registration has the same issues we have identified for the Alternate CoA option and it allows the MN to start redirecting attacks. This is why I am also concerned about including all the BIDs.

The MN could be required to always send the BU for one BID from the CoA that needs to be registered for that BID. 

> will want to explicitly have different lifetimes for different flow bindings

I don't care much if the lifetime is the same or not. I agree with you there is not a clear scenario where different lifetimes are needed. However I think we should find a clean solution which does not imply always the usage of bulk registration. To me the cleanest way is to associated a specific lifetime to each BID, but I am open to suggestions.

Gerardo

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 17 Dec 2008 10:11:37 +1100

> would not require all BIDs.

=> But I thought you were trying to avoid including all BIDs in every
refresh.

> The issue I have in general with bulk registration (and your proposal is
> extending the lifetime of all BIDs with one BU so it is basically a compressed
> bulk registration) is that it may be considered not optimal from a security
> point of view. Basically the usage of bulk registration has the same issues we
> have identified for the Alternate CoA option and it allows the MN to start
> redirecting attacks. This is why I am also concerned about including all the
> BIDs.

=> But that's an issue against bulk registrations in general. If we have
bulk registrations in the draft then this proposal is fine. If we remove
bulk registrations from the draft then there is no point in this discussion
because we have to send one BU for each BID anyway. If we allow each BID to
have the lifetime of the BU then problem solved.
But I thought you'd be concerned about removing bulk registrations because
if you think that:
A. There will be a lot of BIDs (which is what you mentioned earlier for the
bandwidth argument)
B. Bandwidth is an issue.

Then sending one BU per BID would be an issue.

> I don't care much if the lifetime is the same or not. I agree with you there
> is not a clear scenario where different lifetimes are needed. However I think
> we should find a clean solution which does not imply always the usage of bulk
> registration. To me the cleanest way is to associated a specific lifetime to
> each BID, but I am open to suggestions.

=> Well, if we have bulk registrations, then I think the cleanest way is to
send a few bytes to refresh them. If we don't have bulk registrations then
there is no problem to discuss I think.

Hesham

> You got attachement! (https://www.codealias.info/~zrelli/attachements/)

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 16 Dec 2008 21:51:35 -0800

Hi Hesham,

I think the point is that we should enable also a solution which does not rely on bulk registration. This is because bulk registration may not be allowed in some systems as I mentioned below and also as mentioned in the draft.

In case bulk registration is not used, each BU will contain only one BID. The lifetime of this BID is indicated in the main BU message. This implies that logically at the HA's BC and at the MN's BUL there are different lifetimes for each BID. If this is the case then the current solution of the draft to put lifetime=0 in the BU to deregister one BID makes sense.

What do you think?

Gerardo

________________________________________
From: Hesham Soliman [[email-masked]]
Sent: Tuesday, December 16, 2008 3:11 PM
To: Giaretta, Gerardo; [email-masked]
Subject: Re: [MEXT] De-resgistering bindings in MCoA draft

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 13:58:30 +0900

Hesham,

When you use the bulk registration, all bindings share the same lifetime
specified in BU message.  This is what you proposed here.  We also
have specified Overwrite flag to explicitly replace all the bindings
corresponding to the home address.

When MN does not use the bulk registration, each binding registering
with BID is treated as a regular binding. Each binding will have
individual lifetime. It is not the operation of BID removal, but of a binding removal.
Removing a binding with zero lifetime is consisitent with MIP6.

ryuji

At Wed, 17 Dec 2008 00:43:33 +1100,

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 14:13:42 +0900

Hi

At Wed, 17 Dec 2008 09:42:10 +1100,
> will want to explicitly have different lifetimes for different flow bindings

If you use the bulk registration, you only have one lifetime for every bindings.
in section 5.3
   "To use bulk registration, the mobile node includes a Binding
   Identifier Mobility option for each BID and Care-of address pair it
   wants to register in the same Binding Update message.  This is shown
   in Figure 7.  The rest of the fields and options in the Binding
   Update such as Lifetime, Sequence Number, and the flags in the
   Binding Update are common across all care-of addresses."

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 14:13:55 +0900

Gerardo,

At Tue, 16 Dec 2008 15:03:35 -0800,
Giaretta, Gerardo wrote:
> I don't care much if the lifetime is the same or not. I agree with
> you there is not a clear scenario where different lifetimes are
> needed. However I think we should find a clean solution which does
> not imply always the usage of bulk registration. To me the cleanest
> way is to associated a specific lifetime to each BID, but I am open
> to suggestions.

In MCoA, we have two modes to register multiple bindings

- Bulk
  the use single lifetime for all bindings

- No Bulk
  spseparate lifetime per binding.

I think this solves both Hesham and your issues.

The confusion here is that we only mention the case of the non-bulk
mode in Section 5.4 "Binding deregistration". I can add some texts how
the binding removal can be done for the bulk mode.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 14:14:05 +0900

Hi Hesham,

For lacking the CoA verification in the bulk-registration, we have
some texts in Security Consideration. HA can reject the bulk
registration if it wants strict CoA verification.

We support the bulk registration, but operators can always disable
this feature.

ryuji

At Wed, 17 Dec 2008 10:11:37 +1100,

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 17 Dec 2008 18:12:32 +1100

> individual lifetime. It is not the operation of BID removal, but of a binding

=> It's the same thing, you won't remove a BID and keep the binding.

> Removing a binding with zero lifetime is consisitent with MIP6.

=> Yes but that's not the issue, the issue here is having multiple bindings
for the same home address that have different lifetimes.

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 16:21:45 +0900

Hi Hesham

We slightly changed the semantics of MIP6, because both HoA and BID is
now used as a key to search/manage binding cache/binding update list.

I don't see any issues assigning individual lifetime to BID bindings  
for the same HoA,
if there is reason (i.e. no bulk registration).

regards,
ryuji

On 2008/12/17, at 16:12, Hesham Soliman wrote:

>> individual lifetime. It is not the operation of BID removal, but of  
>> a binding
>> removal.
>