Subject: [Mip4] new I-D on network based MIPv4

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 1 Mar 2006 10:44:03 -0500

Hi all,

I submitted the following I-D to define a network based connectivity and
L3 mobility management scheme using Mobile IPv4 client function in the
Access Router:

http://www.ietf.org/internet-drafts/draft-chowdhury-netmip4-00.txt

Here is the abstract:

   The layer 3 mobility management in a mobile wireless network can be
   performed with Mobile IPv4.  The solution however requires the mobile
   nodes to have Mobile IPv4 clients.  There may be scenarios where the
   mobile devices do not have Mobile IPv4 clients.  The layer 3 mobility
   for these devices (often called simple IPv4 mobiles) can be done if
   the network has a Mobile IPv4 client function that can perform Mobile
   IPv4 procedures on behalf of the mobile nodes.  This document defines
   such a mechanism.

I appreciate your review and comment.

Regards,
Kuntal

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 1 Mar 2006 09:28:32 -0800

Hi folks.  We have submitted a new Internet Draft on Proxy Mobile IPv4
at:

http://www.ietf.org/internet-drafts/draft-leung-mip4-proxy-mode-00.txt

Abstract

   Mobile IPv4 is a standard mobility protocol that enables IPv4 device
   to roam between networks.  The mobile device has the Mobile IP
   function to signal its location to the routing anchor, known as the
   Home Agent.  However, there are many IPv4 devices without such
   capability due to various reasons.  This document describes a
   solution based on Proxy Mobile IPv4, which enables some other entity
   to provide mobility support on behalf of an unaltered and mobility-
   unaware IPv4 device.

Comments and feedback appreciated.  Thanks.

Kent

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 2 Mar 2006 15:23:15 -0800

Hi Kent,
I took a look at this draft and I have a few questions/comments. 

1. It would be good to have a list of changes done to the HA from
RFC3344. I guess support for the sequencing extension would be one, but
is there anything else? Also, even though your IANA section says that
the document defines a new sequencing extension, the extension itself
seems to be missing from the document. 

2. Is it fair to say that nothing changes with the FA from RFC3344? 

3. This is probably my biggest question of all - while doing
network-based mobility management, what is the need for MN-specific
security associations? The fact that any MPA the MN moves to, needs to
know the MN-HA key used to secure the RRQ/RRP, MN-specific keys don't
really make sense to me. It would be one thing if we are trying to
maintain interoperability with an RFC3344 HA - but, given that this is
not the case, what are we gaining from keeping this inline with RFC3344?
In my mind, it would make sense for this document to define an MPA-HA
authentication extension - that would be a lot more scalable and does
not seem to make a difference from a security perspective. I don't
particularly like the thought of having to go to the AAA and obtaining
an MS-specific key at every handoff before a registration request can be
sent. If we continue down this path of using the MN-HA authentication
extension, ultimately, we will see a lot of context transfer mechanisms
in practical deployments where the key simply gets passed around from
one MPA to the next, simply to avoid going to the AAA every time. Here
are some negatives of the MPA retrieving keys from AAA: 

a. Potentially undesirable latency added to handoffs
b. The assumption is that the MPA has the NAI of the MN to fetch the
key. Depending on the type of access authentication, this may not be
true. 
c. If the system uses an MN-AAA key to bootstrap the MN-HA key, the very
first MPA performing the RRQ/RRP exchange on behalf of the MS will need
access to the MN-AAA key. I don't believe handing this out is a good
thing in general. 
d. Now you need changes to AAA that don't seem to really be needed here.
Of course, pre-provisioning and subsequent context transfer will also
solve this - but, why? 

It seems to me that it would be cleaner to allow an MPA-HA SA (IPsec
would be good; if not, to be inline with MIPv4, an MPA-HA authentication
extension would be good to allow PSKs). I don't think that is
unreasonable to require that trust between MPA and HA in a network-based
mobility management protocol. 

Your third instance of the wireless terminal performing MIP for the host
doesn't fit this model - but then, that is also significantly different
from a network entity doing proxy MIP - in that case, the WT is acting
as an MPA only for one host; whereas, in the case where the MPA is in an
AR or AP, it is acting as an MPA for multiple MSs. 

I saw that your introduction alluded to the use of a common mobility SA
between the proxy node and HA when the two are in the same domain. I can
see the argument that when the MPA and HA are in different domains,
there may not be an SA between them. However, I would imagine this model
to be most used in cases where the MPAs belong to the same domain as the
HAs. I think that it would be important to standardize an MPA-HA SA
model at least for that. Also, lets say that you do want to use this
protocol when the MPA and HA are in different domains. As you say in the
document, the MS would now have to do MIP4 when it moves out of one
domain. It would be bad to use the same MN-HA key used for proxy-MIP
within one domain to secure RRQ/RRP from/to the MN when it roamed out of
that domain. So, I would really view that as a layered mobility approach
- where the MN doing MIP4 is a mobile-based inter-domain mobility
layered on top of network-based intra-domain mobility. 

Thoughts? 

Thanks,
Vidya

> -----Original Message-----
> From: Kent Leung (kleung) [mailto:[email-masked]] 
> Sent: Wednesday, March 01, 2006 9:29 AM
> To: [email-masked]
> Subject: RE: [Mip4] new I-D on network based MIPv4 
>

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Thu, 2 Mar 2006 23:33:20 -0800

Hi Vidya.  Thanks for the quick feedback.  My comments below.

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Thursday, March 02, 2006 3:23 PM
> To: Kent Leung (kleung); [email-masked]
> 1. It would be good to have a list of changes done to the HA 
> from RFC3344. I guess support for the sequencing extension 
> would be one, but is there anything else? Also, even though 
> your IANA section says that the document defines a new 
> sequencing extension, the extension itself seems to be 
> missing from the document. 
> 

Yes, I agree.  Depending on the scheme of PMIP, the sequencing extension
may not always be needed.  We need to clarify this more in later
revisions.  That extension format will be added later too.

> 2. Is it fair to say that nothing changes with the FA from RFC3344? 

Yes, PMIP can be supported w/o any changes to FA.

> network-based mobility management, what is the need for 
> MN-specific security associations? The fact that any MPA the 
> MN moves to, needs to know the MN-HA key used to secure the 
> RRQ/RRP, MN-specific keys don't really make sense to me. It 
> would be one thing if we are trying to maintain 
> interoperability with an RFC3344 HA - but, given that this is 

Good question.  One that has come up many times regarding PMIP.  We will
need to explain a bit more in later revision.

> In my mind, it would make sense for this document to define 
> an MPA-HA authentication extension - that would be a lot more 
> scalable and does not seem to make a difference from a 
> security perspective. I don't particularly like the thought 
> of having to go to the AAA and obtaining an MS-specific key 
> at every handoff before a registration request can be sent. 
> If we continue down this path of using the MN-HA 
> authentication extension, ultimately, we will see a lot of 
> context transfer mechanisms in practical deployments where 
> the key simply gets passed around from one MPA to the next, 
> simply to avoid going to the AAA every time. Here are some 
> negatives of the MPA retrieving keys from AAA: 
> 
> a. Potentially undesirable latency added to handoffs b. The 
> assumption is that the MPA has the NAI of the MN to fetch the 
> key. Depending on the type of access authentication, this may 
> not be true. 
> c. If the system uses an MN-AAA key to bootstrap the MN-HA 
> key, the very first MPA performing the RRQ/RRP exchange on 
> behalf of the MS will need access to the MN-AAA key. I don't 
> believe handing this out is a good thing in general. 
> Of course, pre-provisioning and subsequent context transfer 
> will also solve this - but, why? 
> 
> It seems to me that it would be cleaner to allow an MPA-HA SA 
> (IPsec would be good; if not, to be inline with MIPv4, an 
> MPA-HA authentication extension would be good to allow PSKs). 
> I don't think that is unreasonable to require that trust 
> between MPA and HA in a network-based mobility management protocol. 
> 

I think the question is how strict should the authentication criteria be
(i.e. per MN or per MPA basis).  The answer depends heavily on the
infrastructure.  I agree that MPA-HA SA could be an option (especially
for intra-domain case).  We had this in mind but the writeup is based on
PMIP deployment which is constrainted to RFC 3344.  Also, it's mixed in
with some upcoming work on PMIP.  We'll need to clean this up a bit.

> Your third instance of the wireless terminal performing MIP 
> for the host doesn't fit this model - but then, that is also 
> significantly different from a network entity doing proxy MIP 
> - in that case, the WT is acting as an MPA only for one host; 
> whereas, in the case where the MPA is in an AR or AP, it is 
> acting as an MPA for multiple MSs. 
> 

The point we're making is that the host itself does not have MIP client.

> I saw that your introduction alluded to the use of a common 
> mobility SA between the proxy node and HA when the two are in 
> the same domain. I can see the argument that when the MPA and 
> HA are in different domains, there may not be an SA between 
> them. However, I would imagine this model to be most used in 
> cases where the MPAs belong to the same domain as the HAs. I 
> think that it would be important to standardize an MPA-HA SA 
> model at least for that. Also, lets say that you do want to 
> use this protocol when the MPA and HA are in different 
> domains. As you say in the document, the MS would now have to 
> do MIP4 when it moves out of one domain. It would be bad to 
> use the same MN-HA key used for proxy-MIP within one domain 
> to secure RRQ/RRP from/to the MN when it roamed out of that 
> domain. So, I would really view that as a layered mobility approach
> - where the MN doing MIP4 is a mobile-based inter-domain 
> mobility layered on top of network-based intra-domain mobility. 
> 

The PMIP key and client-based MIP key will be different.

Kent