Subject: [Mip4] draft-mccann-mip4-mbb-00.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 4 Apr 2008 13:31:41 -0400

<<Chair hat off>>

I've just uploaded a short draft that contains some suggestions
on HA implementation details to assist in make-before-break 
handoffs.  I hope people can read and comment:

   A make-before-break handoff is one where resources on a target system
   are allocated prior to releasing the resources on a source system.
   Make-before-break can be an effective means to provide a more
   seamless handoff with fewer dropped packets.  The existing Mobile
   IPv4 specification supports simultaneous bindings, which can
   facilitate a make-before-break handoff.  However, the binding state
   at the home agent is only one example of a resource that can be
   allocated; others include the link connection to the Foreign Agent
   (or access router) and the provision of security associations between
   the mobile node and the mobility agents.  It may be desirable to set
   up these resources on the target system without necessarily creating
   a binding entry on the Home Agent.  This document provides some
   additional conventions on the use of simultaneous bindings in a make-
   before-break handoff that can be used to optimize the allocation of
   resources in these scenarios.

These suggestions might be appropriate for inclusion in rfc3344bis,
if there is still time to make them, or it could be published as a 
separate document.

Please, let me know what you think!

-Pete
-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.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: Tue, 8 Apr 2008 11:57:55 -0700

Hi Pete.  The draft seems to only point out that the security
association can be fetched during the pre-registration exchange using
RFC 3957.  But this RFC is not in use, AFAIK.  It's not clear to me if
that the draft clearly identify other benefits besides the early SA
establishment.  In the PMIP case, it's unlikely that the PMIP client/PMA
would have the MN-AAA key which is needed to derive the other keys in
RFC 3957.

The use of the 'S' bit (and zero lifetime and new CoA) for this purpose
seems kludgy in the protocol.  It may be better to have explicit
Pre-registration Extension to indicate that the message is intended to
perform operations on the entities before actual handoff signaled by
registration request/reply exchange.

So maybe the draft has some promise.  But it would be much better if the
applicability is better articulated.  I'm willing to help out if that is
desired.

Kent 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
McCann Peter-A001034
Sent: Friday, April 04, 2008 10:32 AM
To: [email-masked]
Subject: [Mip4] draft-mccann-mip4-mbb-00.txt

<<Chair hat off>>

I've just uploaded a short draft that contains some suggestions on HA
implementation details to assist in make-before-break handoffs.  I hope
people can read and comment:

These suggestions might be appropriate for inclusion in rfc3344bis, if
there is still time to make them, or it could be published as a separate
document.

-Pete

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 9 Apr 2008 11:06:42 -0400

Hi, Kent,

Thanks for reading the document.  See below...

Kent Leung (kleung) wrote:
> RFC 3957.  But this RFC is not in use, AFAIK.  It's not clear to me
> if that the draft clearly identify other benefits besides the early
> SA establishment.  In the PMIP case, it's unlikely that the PMIP
> client/PMA would have the MN-AAA key which is needed to derive the
> other keys in RFC 3957.      

We originally started the draft to solve a problem when handing off
from PMIPv4 to CMIPv4; the idea is to complete authentication on
the CMIPv4 side without actually setting up the tunnel for the bearer
traffic, but to do that at a later time.  There are deployments 
that use MN-AAA, and personally, I think these deployments should
also be using RFC 3957 because it solves the problem of distributing
complete security associations, whereas other solutions just distribute
keys.  In any case, it doesn't really matter whether or not the
deployment uses 3957 as long as it has authentication (MN-AAA and
FA Challenge/Response) which most CMIP deployments do.

> The use of the 'S' bit (and zero lifetime and new CoA) for this
> purpose seems kludgy in the protocol.  It may be better to have
> explicit Pre-registration Extension to indicate that the message is
> intended to perform operations on the entities before actual handoff
> signaled by registration request/reply exchange.    

We decided to use the 'S' bit because it seems logical that the
node is trying to create another registration without tearing down
the old one, albeit one which doesn't tunnel traffic hence the zero
lifetime.  However, I'm open to other ways of solving the problem 
and perhaps a new extension would work; however, we really wanted to
introduce just the minimum amount of new specification and the current
approach could even be considered an implementation option in an
existing
HA.

> So maybe the draft has some promise.  But it would be much better if
> the applicability is better articulated.  I'm willing to help out if
> that is desired.  

Thanks for that - maybe this note can clear up some of the intentions
of the draft.

-Pete

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of McCann Peter-A001034 
> implementation details to assist in make-before-break handoffs.  I
> hope people can read and comment:  
> 
>    A make-before-break handoff is one where resources on a target
>    system are allocated prior to releasing the resources on a source
>    system. Make-before-break can be an effective means to provide a
>    more seamless handoff with fewer dropped packets.  The existing
>    Mobile IPv4 specification supports simultaneous bindings, which can
>    (or access router) and the provision of security associations
>    between the mobile node and the mobility agents.  It may be
>    desirable to set up these resources on the target system without
>    necessarily creating a binding entry on the Home Agent.  This
>    document provides some additional conventions on the use of
>    simultaneous bindings in a make- before-break handoff that can be
>    used to optimize the allocation of resources in these scenarios.
>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 10 Apr 2008 15:40:40 -0700

Comments below.

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]] 
Sent: Wednesday, April 09, 2008 8:07 AM
To: Kent Leung (kleung); [email-masked]
Subject: RE: [Mip4] draft-mccann-mip4-mbb-00.txt

Hi, Kent,

> establishment.  In the PMIP case, it's unlikely that the PMIP 

We originally started the draft to solve a problem when handing off from
PMIPv4 to CMIPv4; the idea is to complete authentication on the CMIPv4
side without actually setting up the tunnel for the bearer traffic, but
to do that at a later time.  There are deployments that use MN-AAA, and
personally, I think these deployments should also be using RFC 3957
because it solves the problem of distributing complete security
associations, whereas other solutions just distribute keys.  In any
case, it doesn't really matter whether or not the deployment uses 3957
as long as it has authentication (MN-AAA and FA Challenge/Response)
which most CMIP deployments do.

KL> So the context is handover from PMIPv4 to CMIPv4.  CMIPv4 to PMIPv4
is not covered?  

If RFC 3957 is not used, then what method will set up the security
associations?  I'm not sure how the MN-AAA and FA challenge/response can
be avoided when switching over to CMIPv4, assuming no SA fetched ahead
of time?

> signaled by registration request/reply exchange.    

We decided to use the 'S' bit because it seems logical that the node is
trying to create another registration without tearing down the old one,
albeit one which doesn't tunnel traffic hence the zero lifetime.
However, I'm open to other ways of solving the problem and perhaps a new
extension would work; however, we really wanted to introduce just the
minimum amount of new specification and the current approach could even
be considered an implementation option in an existing HA.

KL> Either way, it's a change to existing HA implementation. :)

Kent

> the applicability is better articulated.  I'm willing to help out if 

Thanks for that - maybe this note can clear up some of the intentions of
the draft.

-Pete

> there is still time to make them, or it could be published as a 
> separate document.
>

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 11 Apr 2008 11:05:53 -0400

Hi, Kent,

Kent Leung (kleung) wrote:
>> if 
> from 
> PMIPv4 to CMIPv4; the idea is to complete authentication on the
> CMIPv4 side without actually setting up the tunnel for the bearer
> traffic, but to do that at a later time.  There are deployments that
> use MN-AAA, and personally, I think these deployments should also be
> using RFC 3957 because it solves the problem of distributing complete
> security associations, whereas other solutions just distribute keys. 
> In any case, it doesn't really matter whether or not the deployment
> uses 3957 as long as it has authentication (MN-AAA and FA
> Challenge/Response) which most CMIP deployments do.        
> 
>> So the context is handover from PMIPv4 to CMIPv4.  CMIPv4 to PMIPv4
>> is not covered? 

I would imagine that a PMIP network already has security associations
in place to protect the proxy registrations.

> associations?  I'm not sure how the MN-AAA and FA challenge/response
> can be avoided when switching over to CMIPv4, assuming no SA fetched
> ahead of time?   

No, they wouldn't be avoided; in fact the draft anticipates their use.
If 3957 isn't being used, the HA can do whatever it needs to set up
the security association such as fetching it from AAA or whatever.
 
> We decided to use the 'S' bit because it seems logical that the node
> is trying to create another registration without tearing down the old
> one, albeit one which doesn't tunnel traffic hence the zero lifetime.
> However, I'm open to other ways of solving the problem and perhaps a
> new extension would work; however, we really wanted to introduce just
> the minimum amount of new specification and the current approach
> could even be considered an implementation option in an existing HA. 
> 
>> Either way, it's a change to existing HA implementation. :)

True, but no new PDUs need to be decoded.

-Pete

>> Of McCann Peter-A001034 Sent: Friday, April 04, 2008 10:32 AM
>> To: [email-masked]
>>    Mobile IPv4 specification supports simultaneous bindings, which
>>    can facilitate a make-before-break handoff.  However, the binding
>>    state at the home agent is only one example of a resource that
>>    can be allocated; others include the link connection to the
>>    Foreign Agent (or access router) and the provision of security
>>    associations between the mobile node and the mobility agents.  It
>>    may be desirable to set up these resources on the target system
>>    without necessarily creating a binding entry on the Home Agent. 
>>    This document provides some additional conventions on the use of
>> if

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sun, 13 Apr 2008 23:27:55 -0700

No, they wouldn't be avoided; in fact the draft anticipates their use.
If 3957 isn't being used, the HA can do whatever it needs to set up the
security association such as fetching it from AAA or whatever.
 
KL> OK.  That is reasonable.  The preregistation message can fetch
subscriber attributes from AAA server in advance.

> the minimum amount of new specification and the current approach could

> even be considered an implementation option in an existing HA.
> 

KL> My initial reaction to re-using/overloading the S-bit (which was
defined for simultaneous bindings) was that it was confusing to be using
for a different function, namely pre-registration operation.  Now, your
explanation helps with why that approach was selected.  Though I'm not
sure if I would quite agree with that because both the message initiator
and the HA have to have the new logic for dealing with the new
signaling, regardless if it's a bit or extension. 

Kent

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 14 Apr 2008 08:04:37 -0500

> defined for simultaneous bindings) was that it was confusing 
> to be using for a different function, namely pre-registration 
> operation.  Now, your explanation helps with why that 
> approach was selected.  Though I'm not sure if I would quite 
> agree with that because both the message initiator and the HA 
> have to have the new logic for dealing with the new 

[Ahmad]
I tend to agree. 
I actually communicated my views earlier to Pete offline and mentioned
that since the proposal include changes at the MN and the HA anyway,
then why not we do a clean solution for this pr-registration by using a
new extension rather than over load the status bit logic.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 14 Apr 2008 08:09:29 -0500

> > defined for simultaneous bindings) was that it was confusing to be 
> > using for a different function, namely pre-registration operation.  
> > Now, your explanation helps with why that approach was selected.  
> > Though I'm not sure if I would quite agree with that 
> because both the 
> > message initiator and the HA have to have the new logic for dealing 
> > with the new signaling, regardless if it's a bit or extension.
> 
> [Ahmad]
> I tend to agree. 
> I actually communicated my views earlier to Pete offline and 
> mentioned that since the proposal include changes at the MN 
> and the HA anyway, then why not we do a clean solution for 
> this pr-registration by using a new extension rather than 
> over load the status bit logic.

[Ahmad]
Hmmm.. meant to say the Simultaneous binding bit:-)
> >      Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 14 Apr 2008 10:49:55 -0400

Hi, Ahmad, Kent,

In principle I am open to solving the problem in a different
way if we can.  Let's work offline and try to come back with
a draft that we are all happy with.  I think we at least have
a common agreement on the problem to be solved.

Thanks,

-Pete

Ahmad Muhanna wrote:
>>> Though I'm not sure if I would quite agree with that because both
>>> the message initiator and the HA have to have the new logic for
>>> dealing with the new signaling, regardless if it's a bit or
>>> extension. 
>> 
>> [Ahmad]
>> I tend to agree.
>> mentioned that since the proposal include changes at the MN and the
>> HA anyway, then why not we do a clean solution for this
>> pr-registration by using a new extension rather than over load the
>> status bit logic. 
> 
> [Ahmad]