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

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 18 Sep 2005 20:55:11 +0300

Hello folks,

Trying to get this out the door this week...

Henrik Levkowetz wrote:

>>>
>>> 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.
>>
>>
>> KL>
>> Not sure if this text is any clearer or not?  I'm OK either way.
>>
>>    In order to perform the authentication, the Home Agent and the
>>    Foreign Agent are configured with a mobility security association 
>> that
>>    is indexed by the SPI (in the appended Foreign-Home Authentication 
>>    Extension) and the IP Source Address of the Registration Request.
>
>
> Looks good to me

Done!  I took Ketn's text.

>
>>> 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.
>>
>>
>> KL> If HA skips checking the presence of FHAE, then validity check is
>> already bypassed.
>>
>> Change:
>>
>>    When processing a Registration Request with Lifetime=0, the HA MAY
>>    skip checking for the presence and validity of a Foreign-Home
>>    Authentication Extension.
>>
>> To:
>>
>>    When processing a Registration Request with Lifetime=0, the Home 
>> Agent MAY
>>    skip the Foreign-Home Authentication Extension.
>
>
> I prefer the original version - what you argue is correct, but I find the
> original text is more explicit, and matching how I'd think when 
> implementing
> this...

O.K.  I made the change without incorporating Kent's modification.
I am happy either way, though.

>
>> KL>
>>
>> What happens to extensions between MHAE and MFAE when MFAE is skipped?
>> Are they also skipped since these extensions are no longer protected?
>> Or they are processed normally, which is implicitly implied in current
>> text.
>>
>
> The latter, I think.  Do you have a position on this, Kent?

I think so too, and I don't see where any additional text needs to
be added but if you have any suggestion please let me know.

>
>>
>> Do we also need to change "MUST" to "MAY" for checking the FHAE in the
>> RRP with Lifetime=0 in the section below?  Else FA will send RRP with
>> error code 68 to MN.  I can't find what was agreed upon for FA
>> processing of the RRP w/o FHAE from HA.
>>
>> 3.7.1:
>>
>>    As with any node on the Internet, a foreign agent MAY also share
>>    mobility security associations with any other nodes.  When relaying a
>>    Registration Request from a mobile node to its home agent, if the
>>    foreign agent shares a mobility security association with the home
>>    agent, it MUST add a Foreign-Home Authentication Extension to the
>>    Request and MUST check the required Foreign-Home Authentication
>>    Extension in the Registration Reply from the home agent (Sections 3.3
>>    and 3.4). 
>
>
> Yes, this change should be done to match the other one above.

How about,
   "In this case, when the Registration Reply has nonzero lifetime,
    the foreign agent MUST check the required Foreign-Home
    Authentication Extension ..."?

>
>> KL>
>>
>> Inconsistency encountered:
>>
>> http://people.nokia.net/~charliep/txt/mobileip/rfc3344bis.txt
>>
>> Error code 68 is missing in section 3.4, but referenced in 3.7.3.1.
>
>
> Oops!  Gremlins at work.  Charlie, you need to speak sternly to your
> pets ;-)  It's there in RFC 3344 but has been inexplicably lost here...

My notes show that error 68 had been deprecated and moved
into the "faerr" document.  I guess to avoid a normative dependency
on the latter document, I will "un-deprecate" it.  Then I can make
sure that the "faerr" document does the right thing in this matter.

Or, I can make the normative dependency if you'd like.

Regards,
Charlie P.

-- 
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: Sun, 18 Sep 2005 20:11:12 +0200

> Trying to get this out the door this week...

[...]

> be added but if you have any suggestion please let me know.

Kent?

>     Authentication Extension ..."?

Sounds good.

> Or, I can make the normative dependency if you'd like.

Ok, I understand.  Better to keep it in 3344bis, I think.

Regards,

	Henrik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 19 Sep 2005 15:35:02 +0300

Hello folks,

I have prepared the revised Internet Draft for submission.
You can find it at the following URL:
    http://people.nokia.net/charliep/txt/mobileip/rfc3344bis.txt

Please let me know if there is anything else I need to do
before submitting this text for distribution.

Regards,
Charlie P.