Re: [Mipshop] Adoption of draft-liebsch-netlmm-transient-bce-pmipv6 as a WG document

["Ahmad Muhanna" <[e-mail]>]

Dear Ryuji,

Just like you, I do not have unlimited time to dedicate to this issue:)
but since there is still some claims that this tBCE, specifically what
is referenced as usecase 1, can be addressed by implementation tweak,
tricks, or kluge at the LMA, I would like to explain a little more.

As I said earlier, there are two different cases here. 

Case 1:
=======
This one you apparently referenced in your original email where the LMA
may keep the BCE which points to the pMAG for a little longer to capture
in-flight uplink packets. In this case, the LMA has already received a
PBU and sent a PBA to the nMAG and the tunnel has been switched to pint
to the nMAG, taking in consideration the above trick.

In this case, apparently the MN (previous) Proxy BCE had a pCoA which
points to the pMAG and this was established via a secure PMIPv6
signaling. Additionally the LMA has received another secure PBU from the
nMAG to indicate the mobile node movement and HO process and to update
the MN proxy point of attachment by updating the MN proxy BCE with the
new pCoA. 

>From a security prospective, someone may argue that a preconfigured
timer may solve this issue and there is NOT much great security risk
involved in here, for the fact that the MN PMA (MAG) has signaled via
secure PBU that the MN is in the process of handoff in order for the LMA
to update the MN proxy BCE.

>From security prospective, the problem rises when some people think of
the usecase 1 as defined in tBCE draft as the same as this one!:)


Case 2:
=======
The case which we refer to as usecase 1 in the tBCE draft is as follows:

The LMA has a proxy BCE for the MN which has a pCoA that points to the
pMAG. 
The LMA has a routing entry for the MN HNP which points to the pMAG-LMA
tunnel.

ALL of a sudden, the LMA receives an IP-in-IP uplink data packet from a
MAG, it happens to be the nMAG with a payload carrying a data packet
with a source IP address which belongs to a MN HNP that is supposed to
be hosted at the pMAG.

NOW: 
====
What is the implementation trick that those who claim that this tBCE
usecase can be addressed ONLY by defining that implementation trick at
the LMA side and NO Need for a protocol?

A claim like this can for sure be categorized as one of the followings:

1. A Claim that does NOT understand the security implications of such a
claim and this case. BTW: UNTIL now, the details of such implementation
CLAIM is still UNCLEAR.

2. A Claim that probably has some understanding of the security
implication and its impact on PMIPv6 BUT at the same time has certain
undisclosed security assumptions THAT IS NOT in line to those of the
Proxy MIPv6 Domain as defined in RFC5213.

Finally, IMO, any action that the LMA MAY take based ONLY on receiving
an uplink data packet that is coming from a nMAG is similar to the "path
management" issue that we have discussed on netlmm mailing list in which
some people argued that the LMA can take an action based ONLY on
receiving an uplink data packet from a MAG while the LMA does not have a
BCE for the MN, I mean for the HNP. At least that was set to rest on
netlmm mailing list and I am sure this one will do too.

Cheers and sorry for the long email!

Regards,
Ahmad
 

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:[e-mail]] 
> Sent: Tuesday, October 21, 2008 12:34 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; [e-mail]
> Subject: Re: [Mipshop] Adoption of 
> draft-liebsch-netlmm-transient-bce-pmipv6 as a WG document
> 
> Hello Ahmad,
> 
> see my comments inline.
> 
> On 2008/10/21, at 4:40, Ahmad Muhanna wrote:
> 
> > Hi Ryuji,
> > Please see inline.
> >
> > Regards,
> > Ahmad
> >
> >
> >> discussed in this document can be solved by  > > implementations.
> >>>
> >>> [Ahmad]
> >>> As probably has been pointed out by Oliver and Marco, the
> >> answer here is  > sure, you can design some implementation to 
> >> hopefully capture a solution  > for this issue; however, 
> it will be 
> >> beneficial for us on this mailing  > list to examine such 
> >> implementation in order to evaluate if it really  > works or NOT. 
> >> Please explain what you have in mind.
> >>
> >> Do you want me to implement it and evaluate it?
> >> I no longer work for University and don't have any 
> students to ask;-<
> >>
> >> The idea is very simple, before removing a (proxy) 
> binding, LMA just 
> >> hold it with certain pre-configured time.
> >
> > [Ahmad]
> > I guess what you are suggesting here is an attempt to 
> handle the case 
> > of switching the IP tunnel from the pMAG to the nMAG while 
> trying to 
> > capture in-flight uplink traffic from the pMAG. Right?
> >
> > Although this mechanism is NOT the best approach in my opinion, 
> > because the statically pre-configured timer could sometime work and 
> > sometime miss because of different delay in the network. 
> However, do 
> > you think that statically configured timer is very rigid or 
> a little 
> > more flexible. In other words, what happens if the timer 
> expires and 
> > there is still uplink traffic coming for the same session?
> 
> But the exactly same thing can be happened to tBCE...
> MAG may send a missed tuned value....
> 
> > Is what you have in mind to remove the routing entry and start 
> > discarding packets or dynamically extending the timer?
> >
> > On the other hand, the case we are trying to address here 
> is a little 
> > different.
> > The LMA will receive uplink traffic from the nMAG before the LMA 
> > receive any PMIPv6 signaling to switch the tunnel to the 
> nMAG. Do you 
> > see the difference?
> 
> Ah, I was referring to the tunnel between pMAG and LMA.
> 
> 
> 
> > In other words, we need to allow traffic from a MAG that 
> have not sent 
> > secure PMIPv6 signaling to start with while in your case, you would 
> > like to prolong the BCE to continue to point to the pMAG 
> for a little 
> > longer.
> >
> 
> You need PBU and PBA before receiving uplink traffic, right?
> I see PBU/PBA(transient) before the uplink setup in Figure 4.
> 
> If you have PBU-transient  before accepting the uplink 
> traffic, we don't need much modification.
> 
> Modifications to the LMA internal processing are enough in 
> the document.
> 
> >>
> >>> In the meantime, I fundamentally disagree with handling
> >> such issue using  > some arbitrary mechanism or solution 
> other than 
> >> SECURE control  > signaling. This is clearly a change that impacts 
> >> the mobile node BCE at  > the LMA which was NOT created in 
> random BUT 
> >> via a secure PMIPv6  > signaling and MUST continue to be 
> maintained 
> >> via PMIPv6 protocol  > specification as captured in 
> RFC5213 or a new 
> >> enhancement to such  > signaling.
> >>
> >> Well, I agree the SECURE part.
> >> I believe static configuration is most secured way in most of
> >> scenarios;-)
> >
> > [Ahmad]
> > Please see comments above. In summary two points:
> > 1. Statically configured timer does not guarantee always 
> that it works 
> > with all types of delay and possibly needs to be 
> dynamically adjusted 
> > based on traffic arrival.
> 
> OK. The difference is dynamic or constant value.
> Dynamic value is useful in some case, but there is no grantee 
> that dynamic value covers all the case successfully.
> 
> Again, I don't see much need to have dynamic value for HO stuff.
> 
> > 2. The case we are talking about is a little different than the one 
> > you referenced.
> 
> see above comments.
> 
> >
> >>
> >>> Having said all of the above, please remember to make sure
> >> that your  > implementation "tweak" or "kluge" :) is 
> inline with the 
> >> above assumption  > which is applicable to any protocol.
> >>>
> >>>
> >>>> For instance, the uplink issue (section 3.2.2) and
> >> others are  > > also happened to Mobile IPv6 operation.
> >>> [Ahmad]
> >>> TRUE.
> >>>
> >>> Also, similar issue has been identified in the case of
> >> MIPv4 too and  > there is a work in progress to address 
> that at MIP4. 
> >> But what is the  > point you are trying to make here?
> >>
> >> OK. I wonder why nobody raise this issue at MIP6.
> >> Maybe no operators yet? :-)
> >
> > [Ahmad]
> > No comments!
> >
> >>
> >>
> >>>> We had same problem, but we can use implementation trick
> >> to  > > solve the issue (delaying the BC removal, etc).
> >>>
> >>> [Ahmad]
> >>> Hmmmmm... Interesting approach.
> >>> I may rephrase this as follows "yes we have a problem but
> >> what about  > adopting a kluge to solve it"!
> >>> Also, delaying the removal of which BC? Could you please
> >> explain a  > little more.
> >>>
> >>> Thanks as always!
> >>
> >> - receiving deregistration BU
> >> - the target BCE marked as old/dead/whatever-BCE
> >> - receiving registration BU
> >> - creating a new BCE
> >> - removing old-BCE after certain time
> >>
> >> We can implement this in similar way of tBCE with no signaling.
> >> tBCE only carries the lifetime, it's to be expected.
> >
> > [Ahmad]
> > BTW: why you refer to the BCE update as delete then create. 
> It could 
> > be but in my mind for simplification it is just update:) Please see 
> > comments above. But still I do not follow the steps you listed.
> > Probably
> > using that in the context of nMAG and pMAG would be 
> helpful. Because I 
> > am not sure what the target BCE in the above means. Is it the BCE 
> > based on a PMIPv6 signaling received from nMAG?
> >
> > Also, tBCE define the allowed direction of traffic 
> associated with the 
> > transient state of the tBCE.
> 
> I don't have any intention and time to write an ID for this 
> even on ML...
> I am not fully convinced the necessity of this document, but 
> consensus call was ended.
> I will stop noising here ;-) Thanks for discussion.
> 
> I would rather wait for MIPSHOP Chair's clarification about 
> the scope of this document. (supporting MBB or not).
> 
> regards,
> ryuji
> 
> 
> 
> >
> >
> > Best Regards,
> > Ahmad
> >
> >>
> >>
> >>>> It looks too complicated to solve such transient issue.
> >>>>
> >>> [Ahmad]
> >>> Why?
> >>> Is there any defect in the proposed solution? If there is
> >> one, please  > help us identify it to fix it.
> >>> Thanks again.
> >>
> >> Maybe my question is do you really need dynamic lifetime 
> assignment 
> >> (from MAG?) on this? How much different lifetime (10msec, 1sec,
> >> 10sec?) do you expect to configure at MAG depending on 
> access media 
> >> or what metrics?!
> >>
> >>
> >>>> In addition, this document deals with one part of
> >> multihoming  > > support for PMIP (i.e. The use of multihoming to 
> >> improve the  > > inter-tech HO.) If we will extend PMIP to 
> support  > 
> >> > multihoming, I would like to discuss this document at 
> the  > > same 
> >> time of multihoming discussion.
> >>>
> >>> [Ahmad]
> >>> Sure, it may be perceived as having a flavor of
> >> multihoming, but it  > seems that you agree that 
> multihoming needs to 
> >> be addressed via a  > protocol signaling mechanism while 
> at the same 
> >> time for this "special  > case of multihoming" you suggest 
> using some 
> >> implementation tricks!:)
> >>
> >> If this is "special case" of multihoming, why do we need 
> to have this 
> >> item now?
> >>
> >> Multihoming related part in tBCE is the case of inter-tech HO 
> >> scenario (MBB). Other parts are just how to treat data 
> from oMAG in 
> >> such short minutes...
> >>
> >> Is MBB the scope of this work -> chairs?
> >>
> >> regards,
> >> ryuji
> >>
> >>
> >>
> >>
> >>>>
> >>>> regards,
> >>>> ryuji
> >>>>
> >>>> On 2008/09/25, at 3:55, Vijay Devarapalli wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> At the MIPSHOP WG meeting at the last IETF, there was
> >> sufficient  > > > support to adopt  > > 
> >> draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as a  > > > WG 
> >> document. We would like to confirm that consensus on the 
> mailing  > > 
> >> > list. You can find the latest document at  > >
> >>>>>
> >> http://www.ietf.org/internet-drafts/draft-liebsch-netlmm-transient-
> >> bce
> >>>>> -p
> >>>>> mipv6-01.txt
> >>>>>
> >>>>> Please respond by October 10, if you support or do not
> >> support  > > > adopting the document as a WG document. If you have 
> >> already  > > expressed  > > > your opinion in the WG 
> meeting, there 
> >> is no need to send an  > > email on  > > > this.
> >>>>>
> >>>>> The intended status for this document is Experimental.
> >>>>>
> >>>>> Vijay
> >>>>> _______________________________________________
> >>>>> Mipshop mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>
> >>>> _______________________________________________
> >>>> Mipshop mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>
> >>
> >>
> 
> 
_______________________________________________
Mipshop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop