Subject: [Mip4] Issue #45; Deregistration vs. Foreign-Home authentication failure

From: "Charles E.Perkins" <[email-masked]>
Date: Fri, 10 Dec 2004 15:49:30 -0800

Hello folks,

The question revolves around proper specification in the
case that a mobile node receives a Registration Reply to
its deregistration request message, and:
- The Foreign-Home Authentication extension does not check
- The Mobile-Home Authentication extension checks O.K.

My eventual proposal was to prohibit the foreign agent
and home agent from attaching the Foreign-Home Authentication
extension to a deregistration request or reply message.
I think this works well enough, and does not seem to
violate any published specification.

If this is O.K., then I would like to close the issue
and submit the document for Working Group Last Call.
I have the document ready for submission now, but I would
like to wait until this issue is closed.

If, on the other hand, the issue isn't ready to be closed,
then, I think we need a new issue number.

Regards,
Charlie P.

PS. I noticed that rev ...-01.txt of rfc3344bis claimed to
    have been submitted during October, 2005.  Oops!

-- 
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 <[email-masked]>
Date: Fri, 10 Dec 2004 19:55:58 -0800

Hi Charlie.  Is this the text we agreed on for closure?

If the Care-of Address in the Registration Request is not in the
Agent Advertisement, then the foreign agent MUST NOT append the
Foreign-Home Authentication Extension when relaying the message to
the home agent.  In this case, the foreign agent's security association
with the home agent is ignored. This ensures that the home agent will
be able to authenticate the Registration Request using the security
association with the foreign agent when Foreign-Home Agent Extension
is appended. The lookup of the foreign agent is based on either the
Care-of Address or the source IP address of the Registration Request.

Kent

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 IOS Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]

---

From: Pete McCann <[email-masked]>
Date: Tue, 14 Dec 2004 11:18:01 -0600

I think we have to make clear that this is an exception in both the FA
and the HA's security association database.

Myabe:

  If the Care-of Address in a deregistration request (A Registration
  Request with Lifetime set to 0) is not one that was previously
  advertised by the FA, then the FA MUST NOT append the Foreign-Home
  Authentication Extension.

  When the HA receives a deregistration request that does not contain
  a Foreign-Home Authentication Extension it MUST NOT discard the
  request as part of security association processing, unless the
  Mobile-Home Authentication Extension is missing or invalid.

Note that it is not possible for the HA to reliably determine whether
the CoA does or does not belong to the FA in question, so that part of
the exception does not apply (the HA accepts a strictly greater set of
deregistration messages than those that would be sent by conforming
FAs).

-Pete

---

From: Kent Leung <[email-masked]>
Date: Tue, 14 Dec 2004 16:31:16 -0800

Hi Pete.

>   Authentication Extension.

Why confine statement to deregistration only?  Seems the common logic
is dealing with the case when FA cannot be identified by the HA
using CoA.  So let's not add the FHAE in this case.  This would
avoid the problem of FA adding the FHAE to RRQ in CCOA mode
(R bit advertised), which would cause HA to look up the non-existent
FA's SA.

My previous comments:

>These are the cases that I can think of when the CoA field
>in the RRQ is not what FA advertised. Although not what FA advertised,
>the CoA is legitimate. First case is when MN is deregistering a previous
>CoA on a previous FA using the current FA. This can happen when
>simultaneous bindings are supported and MN wants to deregister one
>of the bindings which it no longer is attached. The other case is when
>FA is advertising the R bit and MN is in collocated CoA mode. The CoA
>in the RRQ will not be what FA advertised in the CoA fields.
>
>So this is about the current FA that is relaying the RRQ from the MN.
>Just happens that the CoA in the RRQ is not the FA's. Trying to point
>out the cases when this can legitimately happen.

>   Mobile-Home Authentication Extension is missing or invalid.

Agree.  Is the "unless ..." statement explicitly defined somewhere already
and not needed here?

Kent

---

From: Pete McCann <[email-masked]>
Date: Wed, 15 Dec 2004 09:39:11 -0600

Hi, Kent,

 > (R bit advertised), which would cause HA to look up the non-existent

The exception at the FA and the exception at the HA must be symmetric;
if you agree with the language for the HA exception (which mentions
de-registrations explicitly) then I think we need similar language
here.  Otherwise, the HA would be rejecting some messages (that are
not deregistrations) for lack of an FA-HA Authentication Extension.

 > >out the cases when this can legitimately happen.

But the FA can be identified from its source IP address in the RRQ
(absent NAT considerations).  So in general we should allow an FA to
append FA-HA Authentication Extension when passing through an RRQ for
co-located CoA, even though it didn't advertise the address.

 > Agree.  Is the "unless ..." statement explicitly defined somewhere already

A blanket "MUST NOT discard" is clearly wrong because there are other
processing steps that might trigger discard.  This is idea is hard to
capture with text and the above is just one attempt.  There's probably
a better way to say it...

-Pete

---

From: "Charles E.Perkins" <[email-masked]>
Date: Fri, 17 Dec 2004 13:21:15 -0800

Hello Kent,
    
I took your paragraph and put it into the specification
as part of Section 3.5.4.  but then I had some reservations  
about parts of it.
    
>   the home agent.
    
Check.  However, I added the following sentence to account for
the other cases of deregistration:

                    Moreover, for a deregistration message (i.e.,
    lifetime = 0), the foreign agent MUST NOT append the Foreign-Home
    Authentication Extension when relaying the message to the home agent.

Furthermore, in order to satisfy Pete's observation, I included
the following sentence:

    When the HA receives a deregistration request that does not contain
    a Foreign-Home Authentication Extension it MUST NOT for this reason
    discard the request as part of security association processing.

I think it would be a bad idea to try to expand the previously
suggested "... unless" clause.  Instead, I believe that the
phrase "for this reason" pretty much covers the intention.

>                  In this case, the foreign agent's security association
>   with the home agent is ignored.

This sentence does not belong, because it pertains to a
particular model of internal processing for the mobility
security association.  The specification only needs to
describe the externally visible behavior.  This external
behavior can be produced by valid implementations that
do NOT ignore the security association during the processing
that produces conformant operation.

>                                    This ensures that the home agent will
>   is appended.

I don't know why this text was there.

>                The lookup of the foreign agent is based on either the

Up until now, I have thought that the mobility security association
was selected based on the source IP address of the IP packet,
since it was a security association for a network-layer protocol.
If you would like to see this changed (presumably to handle NAT
boxes), I could suggest the following reformulation:

    When this extension is applied to a Registration Request
    message, the mobility security association for verifying the
    correctness of the authentication data is selected by the
    Home Agent based on the value of the Care-of Address field
    of the Registration Request.

    When this extension is applied to a Registration Reply
    message, the mobility security association for verifying the
    correctness of the authentication data is selected by the
    foreign agent based on the value of the Home Agent Address
    field of the Registration Reply.

For now, I inserted these directives before the restriction on
applicability of the extension, since presumably the
selection of the mobility security association is not
going to depend on whether or not the message is about
deregistration.  That determines the ability to use the
extension, not the selection of some not-to-be-employed
security association.  I can remove the text very easily
since it is localized to the one section.

The new revision is available at the following URL:
	http://people.nokia.net/~charliep/txt/mobileip/rfc3344bis.txt

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Fri, 17 Dec 2004 20:56:17 -0800

>not deregistrations) for lack of an FA-HA Authentication Extension.

For registration case, the only scenario that the CoA in RRQ is not what FA
advertised happens in CCoA mode.  This means HA will unlikely have
an SA indexed by the CoA.  The source IP address is unreliable from the
NAT perspective.  So if FA adds the FHAE in the RRQ to HA, then HA
would drop the message.

In the non-NAT'ed mode, I see the issue with missing FHAE in HA
processing.  Seems something will break if FA adds or not the
FHAE when it has SA with the HA in the RRQ. :)

A fundamental question to clear up may be what identifies
the FA for SA lookup: CoA, source IP address or combination of both?

CoA identifies FA and its tunnel endpoint but not when in CCoA mode
or deregistration of previous CoA or HoA.  Source IP address identifies
FA but not when NAT'ed, and multiple interfaces (requiring more SAs)
may be used by same FA to relay the RRQ.  FA NAI may solve this
problem by being protected in  the RRQ and identifies the FA
regardless of interfaces used or reconfigurations on interfaces.

>co-located CoA, even though it didn't advertise the address.

I thought NAT was part of the consideration since the source IP address
may be translated and not reliable for identification.  Though I believe
that CoA is generally unreliable as well in NAT case.

Here's one possible solution.

Typically, if FA is behind NAT, it's known and UDP tunnel is required.
FA MUST NOT append the FHAE to RRQ with UDP Tunnel Request Ext.
By default, FA will append FHAE to RRQ when the HA's SA exist.

Since we are avoiding NAT issues and deferring them to 3519bis,
I'm OK with the deregistration statements now.  I was focused on
addressing the registration problem with NAT too.  But now I believe
it should be in the context of 3519bis and not here.

>a better way to say it...

That was not my intention.  Just wondering if checks for missing or invalid
MHAE is already expected.  Charlie's wording sounds good to me.  So I'm in
agreement with the suggested text along with Charlie's text below. :)

Kent

---

From: Kent Leung <[email-masked]>
Date: Fri, 17 Dec 2004 21:01:08 -0800

Hi Charlie.

I was trying to deal with the NAT issues.  I believe that they should be
handle in 3519bis and not here.  So I'm in agreement with Pete's
suggested text with your "for this reason" revision.  I won't explain
my text as it's irrelevant now.  Leave that for 3519bis discussions
later. :)

Thanks.

Kent

---

From: Pete McCann <[email-masked]>
Date: Mon, 20 Dec 2004 14:35:12 -0600

Some comments on the text that I see in Section 3.5.4 at
http://people.nokia.net/~charliep/txt/mobileip/rfc3344bis.txt:

>   This Extension MAY be included in Registration Requests and Replies
>   in cases in which a mobility security association exists between
>   the foreign agent and the home agent, except in certain restriced
                                                            ^ "restricted"?
>   cases (see below).  as long as the Registration Request is not a
>   deregistration (i.e., it is requesting a positive lifetime and
>   the home address is different than the care-of address).  
                        ^ Sentence fragment - remove?
>   The
>   Foreign-Home Authentication extension MUST NOT be applied to
>   deregistration messages.
    ^ Kent, is this ok with you?
>   See Section 5.1 for information about
>   support requirements for message authentication codes.
>
>...
>
>   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.

The SA should be indexed by the FA's IP address, which is sometimes
(but not always) the CoA in the message.  Right?  When using
co-located CoA (but registering via an FA), we should be allowed to
use FHAE.

>   When the extension is used
>   with a Registration Reply message, the foreign agent address MUST be
>   used as the Destination IP address in the IP header.
>
>   When this extension is applied to a Registration Request message, the
>   mobility security association for verifying the correctness of the
>   authentication data is selected by the Home Agent based on the value
>   of the Care-of Address field of the Registration Request.

This only works for FA-located CoA.  For co-located CoA we have to use
the FA's IP address, which is the source IP address of the RRQ.  Do we
want to split this into cases here?  I think not.

>   When this extension is applied to a Registration Reply message, the
>   mobility security association for verifying the correctness of the
>   authentication data is selected by the foreign agent based on the
>   value of the Home Agent Address field of the Registration Reply.

I'm more comfortable with this, because there is only one Home Agent
address...

>   Agent Advertisement, then the foreign agent MUST NOT append the
    ^ Which advertisement?  Any previous advertisement?  The most
      recent one?
>   Foreign-Home Authentication Extension when relaying the message
>   to the home agent.  Moreover, for a deregistration message (i.e.,
    ^ Kent, is this ok with you?
>   Consequently, when the HA receives a deregistration request that
>   does not contain a Foreign-Home Authentication Extension it MUST NOT
>   for this reason discard the request as part of security association
>   processing.
What about the other requests (first sentence of this paragraph) that
won't contain FHAE but which aren't de-registrations?

-Pete