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

[Hesham Soliman <[e-mail]>]

>>> 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.

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

> 
>> 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.

=> 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 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.

=> 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

> 
> 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
> You got attachement! (https://www.codealias.info/~zrelli/attachements/)


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