Subject: [Mip4] [Fwd: Re: consensus on FHAE/CoA issue]

From: "Charles E.Perkins" <[email-masked]>
Date: Tue, 16 Nov 2004 09:11:25 -0800

Hello folks,

The following transcript represents some discussion
between Kent Leung and myself.  We were trying to resolve
our differences on the issue of whether to prohibit the
inclusion of the Foreign-Home Authentication Extension
on what could be called "remote deregistration" messages.
We were asked to take the discussion to the mailing list,
and so here I forward Kent's last note to me (I hope Kent
does not mind!).  It's a bit too terse to get the points
without having participated in at least the recent WG
meeting, but I hope it's clear enough at least for those
who are most interested.

>  == me (or rfc3344, towards the end)
>> == Kent,

Regards,
Charlie P.

-------- Original Message --------
From: Kent Leung <[email-masked]>
Subject: Re: consensus on FHAE/CoA issue
To: "Charles E.Perkins" <[email-masked]>
CC: Pete McCann <[email-masked]>, Henrik Levkowetz <[email-masked]>

At 03:21 PM 11/15/2004 -0800, Charles E.Perkins wrote:

>Hello Kent,
>
>Kent Leung wrote:
> >
> > Hi folks.  Let me confirm if there's agreement now or not. :)
> >
> > Note I don't have the presented text to massage..
> >
> > 1) The Foreign Agent SHOULD/MUST? not append the FHAE to the RRQ when the
>
>I would say MUST NOT.
>
> > Care-of Address field
> >      does not contain a value in Agent Advertisements from the FA,
> > regardless if an SA with the HA exists.
>
>Check.
>
> > The CoA may not match the advertised value for deregistration
> > request of a previous
> >      binding on a different FA or collocated CoA registration when R-bit
> > set in advertisements.
>
>I don't understand this part.  Is it descriptive or
>proscriptive?  If it's about something on a different FA,
>how would it be enforced?

Descriptive. 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.

> > 2) The Home Agent and Foreign Agent MUST drop registration messages which
> > do not contain the
> >      FHAE when the SA with the peer FA/HA exist.
>
>How about inserting "Otherwise," as the first word of this sentence?

Looking at RFC 3344, looks like this check is already covered?

>3.8.2.1. Validity Checks
>       c) If the home agent shares a mobility security association with
>          the foreign agent, the home agent MUST check for the presence
>          of a valid Foreign-Home Authentication Extension.  Exactly one
>          Foreign-Home Authentication Extension MUST be present in the
>          Registration Request in this case, and the home agent MUST
>          check the Authenticator value in the Extension.  If no
>          Foreign-Home Authentication Extension is found, or if more than
>          one Foreign-Home Authentication Extension is found, or if the
>          Authenticator is invalid, the home agent MUST reject the mobile
>          node's registration and SHOULD send a Registration Reply to the
>          mobile node with Code 132.  The home agent MUST then discard
>          the Request and SHOULD log the error as a security exception.

>3.7.3.1. Validity Checks
>    If the foreign agent and the home agent share a mobility security
>    association, exactly one Foreign-Home Authentication Extension MUST
>    be present in the Registration Reply, and the foreign agent MUST
>    check the Authenticator value in the Extension.  If no Foreign-Home
>    Authentication Extension is found, or if more than one Foreign-Home
>    Authentication Extension is found, or if the Authenticator is
>    invalid, the foreign agent MUST silently discard the Reply and SHOULD
>    log the event as a security exception.  The foreign agent also MUST
>    reject the mobile node's registration and SHOULD send a Registration
>    Reply to the mobile node with Code 68.

Kent

>Regards,
>Charlie P.

--
      |           |                   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]

-- 
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: Tue, 16 Nov 2004 10:20:09 -0800

Hi Charlie. Don't mind.

The issue is a bit more generic than just remote deregistration IMHO.
I think if we use the logic that if the CoA in the RRQ is the
agent advertisements, then the FA MUST NOT append the FHAE when
relaying the RRQ to the HA, even if security association exists.
This ensures that the HA will be able to authenticate the RRQ using
the security association with the FA when FHAE is appended. The lookup
of the FA is based on either the CoA or the source IP address of the RRQ.
Note that the source IP address may be NAT'ed.

Comments?

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Nov 2004 12:01:26 -0800

> I think if we use the logic that if the CoA in the RRQ is the

Here I think you meant, "in the RRQ is _NOT_ in the ..."

> Note that the source IP address may be NAT'ed.

Can you supply some text that works for this, while still not mentioning
NAT?  It seems to me that we can make the right text, but that the
NAT problems should be reserved for discussion elsewhere.  Otherwise,
we might be opening a too-big can of worms for the specification under
consideration.

>> Looking at RFC 3344, looks like this check is already covered?

O.K.  Should  I insert wording to the effect:
    "Otherwise, the Home Agent and Foreign Agent follow the specification
      in sections 3.8.2.1 and 3.7.3.1."   ...?

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Tue, 16 Nov 2004 13:45:54 -0800

>Here I think you meant, "in the RRQ is _NOT_ in the ..."

Right.

>we might be opening a too-big can of worms for the specification under

OK.  Will do.

Something like this OK?

"Note that the source IP address of the received RRQ may not be the
original sender's IP address."

>      in sections 3.8.2.1 and 3.7.3.1."   ...?

Not sure if this is redundant. There's no new operation on the receiver of the
registrations. So do we even need the references? I think if we just
say what's different on the FA and explain why, the rest of processing is
assumed. Having this text or not is fine with me.

Kent