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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 8 Jun 2005 17:47:30 -0700

Welcome back Pete.

#1) Agree with unambiguous selector of SA.

#2) Currently RFC 3344 specifies selector of SA "by their SPI and IP
address".

> 3.2. Authentication

>    Each mobile node, foreign agent, and home agent MUST be able to
>    support a mobility security association for mobile entities,
indexed
>    by their SPI and IP address.

    This is the same language since RFC 2002.  I don't think we need to
change this.  For example, RRQ to FA/HA can be indexed by the source IP
address/SPI.  RRP to FA/MN can be indexed by the source IP address/SPI.

#3) I favor a mobility security association selector that doesn't need
the additional registration lifetime field.  There's a backward
compatibility issue if we add lifetime field to the selector parameters.
For example, an FA (new change) will not append the FHAE when lifetime
is zero.  But an existing HA (with SA for FA) will drop the RRQ in
compliance to RFC 3344.  For registrations the SA and FHAE are in affect
and will still work fine.

Doesn't the IP addresses of the peers exchanging messages already
"unambiguously" (#1 pt) satisfy the condition of securing communications
between them?  Is that what SA was designed for?   

I'll bring the coin to Paris. ;)

Kent

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Wednesday, June 08, 2005 12:57 PM
> To: Henrik Levkowetz
> Cc: Kent Leung (kleung); [email-masked]; Charles E. Perkins
> Subject: Re: [Mip4] Issue #45; Seeking closure for on 
> deregistration with FHAE
> 
> 
> 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: Henrik Levkowetz <[email-masked]>
Date: Thu, 09 Jun 2005 07:19:47 +0200

Hi Kent,

> address/SPI.  RRP to FA/MN can be indexed by the source IP address/SPI.

Since we need to firm up what the selector actually is, and any choice
we make should be more explicit than this, we are in effect making a
change if we define an unambiguous selector of SA (which I think we should
do.  For some implementers, our definitive choice may coincide with what
they have implemented, but in general we can't expect this.

Or in other words - I think we need to change the wording above to make
it explicit exactly what the SA selector shall be.

> and will still work fine.

No, I don't see that this argument holds.  If there is a FA-HA SA, I think
we can assume that both boxes are under the same administrative control.

Now, it would be a simple thing for any vendor who implements a new
SA selector scheme to keep a backward compatibility option, and when
deploying new FAs to work with old HAs, an administrator setting up the
FA-HA SA could indicate that it should run in compatibility mode, rather
than in 3344bis mode.

We can't use this as a blocker for moving forward to something better than
we have today.

> between them?  Is that what SA was designed for?   

Obviously we have had shifting interpretations both over time and between
vendors, so the answer seems to be "No".

> I'll bring the coin to Paris. ;)

Let's all bring coins and spend'em on some nice food and drink ;-)

	Henrik

[...]

>>  > > I would say that we need to choose some subset of the following fields
>>  > > as the selector set:
>>  > >
>>  > >   e) The Lifetime field (or a bit which says whether or not it is zero)
>>  > > 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)?
>>  > >
>>  > > Note that for Registration Replies our choices are a bit different as
>>  > > the CoA is not represented in the message:
>>  > >
>>  > > 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

---

From: Pete McCann <[email-masked]>
Date: Thu, 9 Jun 2005 09:42:04 -0500

Strictly speaking, I don't think we would include the SPI as a
"selector."  Remember, the selector set has two functions:

>    that a message without an authentication extension should be dropped.

It is true that, given multiple MSAs between two peers, the SPI field
determines which MSA is in use.  However, the SPI field does not
"select" the outgoing traffic in (1) above, and is not present in
messages that are missing authentication extensions as in (2).  So,
strictly speaking, I would say that the SPI field is part of the MSA
but is not itself a selector.

In the multiple MSA case, we should also have text which states that
the sender can use any of the applicable MSAs, and the receiver should
be prepared to validate the message based on any of the MSAs.

Also note that, given (1) and (2) above, if we add the lifetime field,
it simply means that an authentication extension is not necessary to
either add at the sender or check at the receiver.  One possible
approach to backwards compatibility is to mandate that the FA adds it
anyway but just allow the HA to skip it when the lifetime=0.

Unlike Henrik, I do think it is important to address the backwards
compatibility issue because we have mechanisms for dynamically
distributing MSAs among FAs and HAs from different administrative
domains (i.e., using AAA).

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 10 Jun 2005 12:40:22 +0200

On 06/09/2005 04:42 PM Pete McCann said the following:
[...]

> anyway but just allow the HA to skip it when the lifetime=0.

This seems like a good proposal to me.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 21 Jun 2005 23:02:27 +0200

Kent, Charlie,

It seems to me that we have a definitive proposal from Pete (see below)
which would resolve the issue, without violating the position of either
of you.

Could you please indicate if this solution is acceptable to you, in which
case we could move forward and forge some text and finish the 3344bis; or
alternatively, explain clearly why this solution is unworkable, so we can
search some other resolution.

	Henrik

---

From: "Charles E.Perkins" <[email-masked]>
Date: Tue, 21 Jun 2005 14:30:46 -0700

Hello Henrik,

This is fine with me.

Regards,
Charlie P.

Henrik Levkowetz wrote:
>   --------------------------------------------------------------------------------
>                        Name: signature.asc
>    signature.asc       Type: application/pgp-signature
>                 Description: OpenPGP digital signature

---

From: Pete McCann <[email-masked]>
Date: Wed, 29 Jun 2005 13:21:40 -0500

Proposed resolution of Issue #45:

Section 3.5.4:

Remove the sentence:
   The Foreign-Home Authentication extension MUST NOT be applied to
   deregistration messages.

Replace the following:
   In order to perform the authentication, the Home Agent and the
   Foreign Agent have to have configured a security association that
   is able to be indexed by use of the SPI and the care-of address
   assocated with the Foreign Agent.  This care-of address MUST be used
   as the Source IP address of the Registration Request containing the
   Foreign-Home Authentication Extension.  
with:
   In order to perform the authentication, the Home Agent and the
   Foreign Agent have to have configured a security association that
   is able to be indexed by use of the SPI and the Source IP of the
   Registration Request containing the Foreign-Home Authentication
   Extension.

Section 3.8.1:
Replace the following:
   When receiving a Registration Request
   from a foreign agent, if the home agent shares a mobility security
   association with the foreign agent, the home agent MUST check the
   Authenticator in the required Foreign-Home Authentication Extension
   in the message, based on this mobility security association.
with:
   When receiving a Registration Request from a foreign agent, if the
   home agent shares a mobility security association with the foreign
   agent, the home agent MUST check the Authenticator in the required
   Foreign-Home Authentication Extension in the message, based on this
   mobility security association, unless the Lifetime field equals 0.
   When processing a Registration Request with Lifetime=0, the HA MAY
   skip checking for the presence and validity of a Foreign-Home
   Authentication Extension.

---

From: "Charles E.Perkins" <[email-masked]>
Date: Wed, 29 Jun 2005 13:14:14 -0700

Hello Pete,

This is fine with me.  Just let me know, and
I will prepare the next (and perhaps last!)
revision of rfc3344bis.

Regards,
Charlie P.