Re: [netlmm] MIP6 HoA and PMIPv6 pHoA

[Basavaraj Patil <[e-mail]>]

Vidya,

I tend to agree with Sri's comments as well about the usage of the MIP6 HoA
as the PMIP address. Is the " prefix-per-MN global addressing model" a
baseline assumption?

-Raj


On 2/1/07 6:51 PM, "ext Sri Gundavelli" <[e-mail]> wrote:

> 
> Hi Vidya,
> 
> Lets hear from others in the WG on this. I'll defer my
> comments for now.
> 
> Regards !
> Sri
> 
> 
> 
> On Thu, 1 Feb 2007, Narayanan, Vidya wrote:
> 
>> Hi Sri,
>> Given the prefix-per-MN global addressing model, this discussion is
>> probably moot - in that model, the MIP6 HoA cannot be the PMIP address
>> anyway. So, I won't spend a lot of time on this discussion, but there
>> are still some points worth noting. Please see inline.
>> 
>>> -----Original Message-----
>>> From: Sri Gundavelli [mailto:[e-mail]]
>>> Sent: Thursday, February 01, 2007 11:04 AM
>>> To: Narayanan, Vidya
>>> Cc: [e-mail]
>>> Subject: Re: [netlmm] MIP6 HoA and PMIPv6 pHoA
>>> 
>>> 
>>> Vidya,
>>> 
>>> I do not agree with this restriction.
>>> 
>>> 1. There are clear sementics for the home agent to differentiate
>>>     a BU from a PBU and apply the corresponding security model.
>>> 
>>> 2. There is one race condition as we mentioned before in the ML,
>>>     when the CMIP enabled mobile rapidly moves from PMIP link to
>>>     a normal link and the home agent receives BU's and PBU's in
>>>     out of order, there is an issue with the ordering. We have
>>>     suggested the use of time stamp, optionally, even for BU's
>>>     from a CMIP client to resolve this issue.
>> 
>> Updating RFC3775 MN behavior is not within the scope of this WG.
>> However, we do need to ensure that PMIPv6 does not affect the operation
>> of MIP6 when used in the same network.
>> 
>>> If that is not
>>>     acceptible, this can be properly documented. Also, note that
>>>     this is a rare corner case, BU's have to be out of ordered,
>>>     the PMIP/CMIP links have to be located right next, MN needs
>>>     to be configured for this ...etc. When all this fall in place,
>>>     this issue occurs.
>>> 
>> 
>> Not sure what you mean by MN needs to be configured, but, when the MN is
>> at the border of two PMIP domains, for instance, this behavior can
>> happen. It depends on how often a given MN geographically visits that
>> point - and the protocol cannot dismiss it as a rare event in my view.
>> Here is where PMIP gets into stepping on the correct operation of MIP6
>> and that's the real issue here.
>> 
>>> 3. Typically, all operators configure mobile's to be a virtual link.
>>>     Now, if we go for Per-MN-Prefix model, I cannot imagine any
>>>     operator configuring a million home prefixes on a phsyical
>>>     interfaces. The going home issue and the NA is not relevant for
>>>     PMIP.
>>> 
>>> 4. I think this restriction is very expensive and architecturally
>>>     limits the PMIP scope. I suggest, we document issues around
>>>     CMIP-PMIP coexistence and leave the operator a deployment choice.
>>> 
>>> Other comments ..see inline ..
>>> 
>>> Sri
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, 1 Feb 2007, Narayanan, Vidya wrote:
>>> 
>>>> 
>>>> One of the possible ways of allowing PMIPv6 and MIP6 to
>>> co-exist is by
>>>> allowing a MIP6 HoA of an MN to be a PMIP6 pHoA within a
>>> PMIP domain.
>>>> This potentially causes a given binding to be updated by the MN and
>>>> the PMAs. This presents several problems as summarized below.
>>>> 
>>>> 1. The PMA is the default router and the entity generating
>>> the RAs to
>>>> the MN. In order for the MN to detect that it is on the
>>> home link, a
>>>> couple of different things may happen. The RA from the HA must be
>>>> available to the MN with the H bit set and the source link-layer
>>>> address. In accordance with RFC3775, the MN must multicast an RS -
>>>> such a multicast RS in the PMIP domain will (and should)
>>> not be sent
>>>> beyond the PMA, as the PMIP domain is not treated as a
>>> broadcast domain.
>>>> 
>>> 
>>> The point is that, the mobile should be able to detect its home link.
>>> The RA's must contain the home prefix. If the RA is unicasted
>>> or multicasted is a different issue. If there is a MUST
>>> requirement, we should relax that for this scenario.
>>> 
>> 
>> Relaxing anything in RFC3775 for sake of PMIP is not an option - please
>> do keep that in mind.
>> 
>>> 
>>>> 2. As I noted in another email, the consensus on the unique
>>> prefix per
>>>> MN model for global IP addressing still holds. In this case, the RA
>>>> sent to the MN has its own prefix - hence, there is really
>>> no scope to
>>>> have that be the home link prefix as well - there can be no
>>> H bit set
>>>> on that, for one.
>>> 
>>> 
>>> If the home link is virtual, there is no issue on this either.
>>> 
>>>> 
>>>> 3. A MIP6 HA, upon receiving a de-registration, will stop defending
>>>> the HoA of the MN. In this case, the HA must continue to defend the
>>>> address and intercept packets belonging to the MN. I
>>> realize that the
>>>> pBU will kick that process off again, but, the changes to the HA
>>>> behavior would still need to be described. This is especially
>>>> problematic if the PMIP and MIP BCEs are the same - for
>>> e.g., what if
>>>> the de-registration reaches after the pBU? It is not within the
>>>> charter to modify any MIP6 behaviors to define PMIP - so,
>>> we have to
>>>> be careful about where this leads us.
>>>> 
>>> 
>>> 
>>> As discussed in the ML, the home link for PMIP in general
>>> will be on a virtual link. Typically, the home agent will
>>> have a route for the mobile's prefix and will not involve in
>>> any ND related operations.
>>> 
>> 
>> Again, in view of the prefix-per-MN model, this discussion is not
>> needed.
>> 
>>> 
>>>> 4. A similar impact will be on the MIP6 behavior of the MN - the MN
>>>> must send an unsolicited NA upon returning home, in accordance with
>>>> RFC3775; but, the MN will not do this after a link change
>>> within the PMIP domain.
>>>> 
>>> 
>>> Home is typically configured on a virtual link.
>>> Besides, In the per-MN-prefix model, why is this relevant ?
>>> 
>>> 
>>>> 
>>>> 5. If the MN moves back and forth between two PMAs associated with
>>>> different LMAs, the pBU and the BU at the LMA/HA may create race
>>>> conditions. The sequence numbers are obviously not synchronized and
>>>> hence, there is really no way to tell which is the latest one.
>>>> 
>>> 
>>> We have suggested the use of time stamp for resolving the
>>> uniqueness in such situations. Optionally, BU's from the
>>> client MAY have the time stamp option and the home agent can
>>> predictably identify the latest time stamped BU. Also, this
>>> reflects a specific network topology and is a corner case.
>>> 
>> 
>> Same point as what I've clarified above.
>> 
>>> 
>>>> 6. The security model of PMIP and MIP are vastly different. PMIP
>>>> operates with a notable risk that in the event of a PMA
>>> compromise, it
>>>> is feasible to redirect traffic belonging to any address within the
>>>> PMIP domain. If the PMA is authorized to send BUs for the MN's MIP
>>>> HoA, a compromised PMA can redirect traffic belonging to an MN even
>>>> when the MN is no longer in that domain. In this case, PMIP is
>>>> extending the threat to the scope of MIP6 and this is not
>>> acceptable.
>>>> 
>>> 
>>> 
>>> Compromised home agent can do the same thing as well. The
>>> same threat applies to NEMO MNP prefixes. Home agent can
>>> certainly apply proper authorization checks on who can send a
>>> PBU's. I do not think this introduces any new threat.
>>> 
>>> 
>> 
>> You are missing the point here. When a given entity is compromised, any
>> service provided by that entity is obviously affected and that is a
>> given. In the case of network-based mobility, the compromise of an AR
>> already has the potential to affect the PMIP service in the entire
>> domain and this has already been noted. When the compromised of an AR
>> leads to affecting the MIP6 service to an MN beyond the PMIP domain that
>> the AR is serving in, it extends the threat to the scope of MIP6 and
>> that is not acceptable.
>> 
>>> 
>>>> 7. The different security models also lead to IPsec processing
>>>> differences. For MIP6, the SPD must be checked against the
>>> HoA of the
>>>> MN. For PMIP6, the SPD must be checked against the PMA's IP address
>>>> (which is often the pCoA or simply, the source address of the pBU).
>>>> When a given IP address is both the MIP6 HoA and the PMIP6
>>> pHoA, there
>>>> is an issue with IPsec processing due to the differences in
>>> the two models.
>>>> This would result in improper (or even lack of) authorization of the
>>>> MIP6 BUs, resulting in an undesirable and unacceptable
>>> impact to MIP6
>>>> security.
>>>> 
>>> 
>>> There are clear sementics on how the home agent can
>>> distinguish between a BU and PBU. The home agent will always
>>> be able to identify the type of registration and the
>>> corresponding security method that it needs to apply. If we
>>> fail to achive that, I will agree with this comment.
>>> 
>> 
>> In both cases, the HA is using IPsec for security. On this point,
>> however, thinking about it further, it seems like it can be made to
>> work.
>> 
>> All other problems noted above are still true.
>> 
>>> 
>>>> For all the above reasons, I suggest explicitly disallowing
>>> the case
>>>> of
>>>> MIP6 HoA and PMIP6 pHoA being the same.
>>>> 
>>> 
>>> I think this restriction is very expensive and
>>> architecturally limits the PMIP scope. I do not agree this
>>> restriction.
>> 
>> Not true. This restriction puts the PMIP scope where it belongs - within
>> the PMIP domain. Once again, hopefully, we don't need much discussion on
>> this point with the prefix-per-MN global addressing model anyway.
>> 
>> Regards,
>> Vidya
>> 
> 
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm


_______________________________________________
netlmm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/netlmm