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

[Ryuji Wakikawa <[e-mail]>]

Gerardo,

At Tue, 16 Dec 2008 15:03:35 -0800,
Giaretta, Gerardo wrote:
> 
> Hi Hesham,
> 
> > -----Original Message-----
> > From: Hesham Soliman [mailto:[e-mail]]
> > Sent: Tuesday, December 16, 2008 2:42 PM
> > To: Giaretta, Gerardo; [e-mail]
> > Subject: Re: De-resgistering bindings in MCoA draft
> > 
> > 
> > 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.
> > 
> 
> Yes, let's assume that as it is an issue if we want to apply this to 3GPP.
> 
> > >
> > > 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.
> > 
> > => 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.
> 
> > 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 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. 
> 
> > 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.
> >
> 
> 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

> Gerardo
> 
>  
> > Hesham
> > 
> > 
> > >
> > > Cheers
> > > Gerardo
> > >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > >> Hesham
> > >> Soliman
> > >> Sent: Tuesday, December 16, 2008 5:44 AM
> > >> To: [e-mail]
> > >> Subject: [MEXT] De-resgistering bindings in MCoA draft
> > >>
> > >> 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/mext
> > 
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext