Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE

From: Pete McCann <[email-masked]>
Date: Wed, 8 Jun 2005 14:57:06 -0500

Sorry for my long absence from the list.

I am disappointed to find no further movement on this issue; I thought
the writeup I did below summarized some of the issues nicely.

First, can we agree that there should be an unambiguous specification
of the "selectors" for Mobility Security Associations?  And second,
can we agree that for the FA-HA MSA the selectors for the Registration
Request should be (a) the source address of the RRQ and (d) the Home
Agent address.  It seems like the most important issue is to clarify
this in 3344bis.

Now, what we are debating here is whether to include the boolean (e)
(Lifetime=0) as an additional selector.  In other words, the FA-HA
authentication extension may be left out by the FA and need not be 
checked by the HA if the message is a de-registration.

We need to converge.  If this is not resolved soon I am inclined to
flip a coin at IETF63.

-Pete

Henrik Levkowetz writes:
 > Hi Kent and Charlie,
 > 
 >     Below I attach Pete's writeup of the different combinations of
 > SA selectors we could use to express your respective 2 approaches.
 > Could you please check through the writeup, and indicate your
 > preferred selectors in terms of the a) to f) selectors in
 > Pete's note, (or add other's, if there are more than a) to
 > f) to consider), so we are clear here on exactly what is being
 > proposed.  
 > 
 > With that in hand I'll ask the people on the list to please weigh
 > in with considered opinions, so we can (hopefully) find a consensus
 > position regarding this, and close it.
 > 
 > 
 > 	Henrik
 > 
 > 
 > On 2005-03-14 10:05 pm Kent Leung said the following:
 > > Hi Charlie.  Thanks.  We have now articulated the 2 different
 > > approaches.  I believe we both agree on one thing - closure on
 > > this issue.  :)
 > > 
 > > Kent
 > > 
 > > At 12:53 PM 3/14/2005 -0800, Charles E. Perkins wrote:
 > [...]
 > 
 > >>>   And if real deployment
 > >>>problem is encountered by operators/customers, _then_ we can
 > >>>add more logic to support specific scenario.
 > >>
 > >>O.K.  Let's interpret this sentence to mean the following:
 > >>
 > >>Allow the deregistration, and if real deployment shows any
 > >>problem with the FA when the mobile node wants to deregister,
 > >>then we will add more logic.
 > >>
 > >>>For now, please just keep it straightforward.  Thanks.
 > >>
 > >>Check.
 > >>
 > >>Let's keep it straightforward.
 > >>
 > >>Mobile node authenticates   ==>  home agent acts on its
 > >>verifiable request.
 > >>
 > 
 > 
 > On 2005-02-25 10:47 pm Pete McCann said the following:
 > > Hi, Henrik,
 > > 
 > > I went back and reviewed the archives.  There are a lot of complex and
 > > thorny issues here.
 > 
 > [...]
 > 
 > > Whatever selectors we choose, it is important to understand that they
 > > serve two purposes:
 > > 
 > > 1. The sender of a message must find the right SA with which to
 > >    compute the authentication extension, or determine that an
 > >    authentication extension is not necessary.
 > > 
 > > 2. The receiver of a message must find the right SA with which to
 > >    check the authentication extension, or to determine that a message
 > >    without an authentication extension should be dropped.
 > > 
 > > Both ends of the selector computation must be done in exactly the same
 > > way to guarantee interoperability.
 > > 
 > > I would say that we need to choose some subset of the following fields
 > > as the selector set:
 > > 
 > > Possible Registration Request Selector Fields
 > >   a) The Source IP address
 > >   b) The Destination IP address
 > >   c) The Care-of Address
 > >   d) The Home Agent Address
 > >   e) The Lifetime field (or a bit which says whether or not it is zero)
 > >   f) The D bit (set to 1 if co-located CoA is being used)
 > > 
 > > Current status quo in the 3344bis text is, I believe, (c,d) with a
 > > proposal from Charlie to add (e).
 > > 
 > > Now, before we consider adding (e) I think we need to get our story
 > > straight on why (c,d) is such a good choice.  I have already pointed
 > > out the difficulty with (c,d) when using co-located CoA registering
 > > via the FA (which may or may not be using the 'R' bit).  A possible
 > > solution to this difficulty is to configure duplicate SAs at every
 > > possible legal value of (c,d) (i.e., all CoAs 'c' that could be used
 > > from a given FA) but this seems like way too much state and doesn't
 > > handle the case where more than one FA are deployed on a given link.
 > > 
 > > Another possible approach is to go back to using (a,d) instead of
 > > (c,d).  Of course, NATs can change the value of (a) and so this is why
 > > 3519 mandated (c,d) and a=c.  However, my understanding is that most
 > > current implementations (those that don't do 3519) actually use (a,d)
 > > even though this has been ambiguous ever since RFC 2002.  (a,d) seems
 > > to be the most straightforward approach and matches e.g., IPSec style
 > > processing.
 > > 
 > > I have proposed on the list a possible fix to the NAT issue where
 > > duplicate SAs are deployed at every possible legal value of (a,d)
 > > (i.e., all NATs that could be on the path between a given FA and HA)
 > > but this is a bit of an administrative overhead and doesn't handle the
 > > case where more than one FA is deployed behind the NAT.  Another
 > > possible approach is to bury our heads in the sand while uttering some
 > > wistful complaint about the never-ending stupidity of NATs.  I make it
 > > sound silly but it is actually my personally favored approach.
 > > 
 > > Now, as I understand it, part of the motivation for adding (e) was to
 > > handle the case when the selector was (c,d) and the CoA 'c' in
 > > question nevertheless did not belong to the current FA.  We really
 > > should nail down the question of whether we are going to revert back
 > > to (a,d) before debating whether to transition to (c,d,e).  Agreed?
 > > Furthermore, if we do transition to (c,d,e) wouldn't we sometimes want
 > > an FA-HA authentication extension for (c,d,0)?
 > > 
 > > In summary, I do not see a clear winner here.
 > > 
 > > 
 > > 
 > > Note that for Registration Replies our choices are a bit different as
 > > the CoA is not represented in the message:
 > > 
 > > Possible Registration Reply Selector Fields
 > >   w) The Source IP address
 > >   x) The Destination IP address
 > >   y) The Home Agent Address
 > >   z) The Lifetime field (or a bit which says whether or not it is zero)
 > > 
 > > I assume that most implementations today use (x,y).  Note that in this
 > > case the NAT issue boils down to modifying 'x' not 'w' because this is
 > > a response that trickles back through the NAT state set up by the
 > > request.  How does 3519 handle this case?  It seems like the HA has to
 > > find the SA based not on the contents of the outgoing message but
 > > based on the fact that it is a reply to a request and there is a
 > > corresponding SA pair in place that are bound together with
 > > administrative provisioning.  Processing on the FA seems similarly
 > > bound up in the outstanding Request state, at least in the case of
 > > multi-interfaced FAs with different security policies for each
 > > interface.
 > > 
 > [...]
 > 
 > > -Pete
 > > 
 > > 
 > 
 > 
 > 
 > -- 
 > 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/

-- 
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: Charlie P <[email-masked]>
Date: Wed, 08 Jun 2005 16:07:35 -0700

Hello Pete,

You must have been reading my mind.  I was preparing to send out
some e-mail on the issue to try to resolve it.  I think your solution is
very workable, and fairly represents the situation.

I am myself in favor of enlarging the set of selectors -- and not
just in this situation.  We had major damage to Mobile IPv6
because of carping about the available selectors.  At least in
this case, the situation is entirely under our control.

Regards,
Charlie P.