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

From: Pete McCann <[email-masked]>
Date: Wed, 5 Jan 2005 16:55:43 -0600

Bringing some off-list discussion back into the fold...

<please note chair hat off for the below>

Charlie P writes:
 > Pete McCann wrote:
 > 
 > >After mulling over this issue some more, I am tending to agree with
 > >Kent's reasoning below.  We had talked about allowing some exceptions
 > >to the SA processing, but the exact conditions under which the
 > >exceptions apply seem fuzzy to me (remember, they have to be identical
 > >and computable at both the FA and HA).
 > >  
 > >
 > I don't see anything wrong with the idea of prohibiting FHAE
 > on deregistrations for external care-of addresses.  The home
 > agent will have no difficulty with this.  At the last IETF, and
 > during the discussion in the room, this seemed like a workable
 > solution without any technical diffculties raised.

I am still having trouble with the definition of "external care-of
addresses".  (see my previous e-mail to the list).  Is it possible to
define this set such that both the FA and HA are in agreement on which
de-registrations are excluded from security processing?  How does the
HA know which care-of addresses are "external" to a given FA?

Even if we could define this properly, I am having more and more
doubts that this sort of processing belongs at the Mobile IP security
layer.  Imagine if we were using IPSec for security (which,
thankfully, we are not right now) and trying to convince an IPSec
implementor to put exceptions into the SAD based on the contents of
the message... it would be absolutely, totally, and in all other ways
inconceivable.

I understand the motivation here; we don't want the FA to be able to
disrupt a de-registration that doesn't concern it.  However, modifying
the security processing in the FA and HA doesn't really achieve that
goal; the FA could still, for example, drop the packet without
forwarding it to the HA, as could any router along the e2e path.

Maybe the real problem here is the 'R' bit.  I proposed once before
that we allow de-registrations to go directly to the HA, even if the
'R' bit is set, but there was at least one objection.  Can someone
remind me what was the basis for it?

 > Regards,
 > Charlie P.

-Pete

Kent Leung writes:
 > Hi Charlie.
 > 
 > I was addressing the issue from the context of a NAT environment
 > by using the CoA field for indexing the security association.  But
 > realize that I should not be bundling the NAT issue with the
 > deregistration and CCoA mode.  The NAT problem should be
 > dealt with in 3519bis (likely adding a new source IP address field in the
 > extension for detection).
 > 
 > Leaving the NAT issue aside, I agree with both you and Pete that the
 > the security association should be indexed by the source IP address
 > and SPI.  This means that the FA can be identified by the source
 > IP address of the RRQ. Both registrations and deregistration are
 > protected by the SA. If there is any problem in the SA between HA and
 > FA, then both registration and deregistration will be problematic.  This
 > problem needs to be fixed by the administrator.  I think
 > if the SA exists, then FA and HA must append the FHAE when sending
 > message, as well as check for FHAE upon reception.  Can't think of
 > good reasons why there should be exceptions.
 > 
 > Kent
 > 

-- 
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, 06 Jan 2005 00:46:23 +0100

Hi Pete,

  inline...

> HA know which care-of addresses are "external" to a given FA?

Well, we could easily say that any care-of address which doesn't match
the source address of the packet is an external address.  This is a
bit simplistic, but actually can be made to work also for FAs which
have multiple care-of addresses (which is not a common thing in my
experience) buy having the FA take care to always match source IP
with care-of address when the care-of address is it's own.

> the message... it would be absolutely, totally, and in all other ways

Yes, but the analogy is flawed.

With IPsec, you would not have the case that all traffic went through
the tunnel, except for some particular messages which were dropped
due to their content -- which would be closer to the case we are
experiencing here.  Anything like that should indeed be regarded as
a flaw in IPsec.

> forwarding it to the HA, as could any router along the e2e path.

Yes, but the big, huge difference is that consistently dropping
certain packages would either be hostile or a bug in implementation,
set-up, or administrator attitude ;-)

To not only condone but actively choose to codify a practice which
denies service to a MN in certain cases is improper, I believe.

> remind me what was the basis for it?

I have no objection - but I don't think it solves the problem in all
cases.  Some nets may very well permit egress only through the FA,
so there may not be any route past the FA.

	Henrik

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Jan 2005 16:13:09 -0800 (PST)

Hi Pete,

On Wed, 5 Jan 2005, Pete McCann wrote:

...

> remind me what was the basis for it?

Some one could potentially enforce fire policies filtering
all MIP control traffic originating from non FA-COA addresses
and by enabling "R" bit for administrative control. So,
allowing De-reg traffic directly ignoring the "R" bit may
introduce problems.

Sri.

---

From: Pete McCann <[email-masked]>
Date: Thu, 6 Jan 2005 09:46:03 -0600

Hi, Henrik,

<chair hat continues to be off, in case that isn't obvious to everyone>

 > with care-of address when the care-of address is it's own.

Ok, your assumptions about the security policy are slightly different
from mine.  I thought we were allowing an exemption for the case where
the MN is de-registering an address that it obtained while connected
to a different network (this is how I interpreted "external").
Addresses on the current subnet (even co-located CoAs) would NOT be
exempted from security processing because they are "owned" in some
sense by that FA, even though they are not the address of any
interface of the FA.  Clearly, this policy would be difficult or
impossible to process at the HA because it can't know what addresses
are on the same subnet as the FA.

I agree your policy is easier to implement, but it effectively
prohibits FHAE on any de-registration of a co-located COA.  Is that
what we want?  If so, it could certainly be stated more clearly in the
text than it is right now.

 > experiencing here.  Anything like that should indeed be regarded as

I don't understand how my proposal leads to dropped messages, as long
as the SAs are properly configured between the FAs and HAs.

 > denies service to a MN in certain cases is improper, I believe.

That's not at all what I am suggesting.  If the SA between the FA and
HA is good then the packet won't be dropped.  If the SA isn't working
then the administrator needs to fix something.

 > so there may not be any route past the FA.

Sure, the packets go through the FA, but I would argue that a policy
(even with the 'R' bit set) that drops de-registration requests
directed to the home agent is hostile or a bug in implementation,
set-up, or administrator attitude.  Maybe it would be easier to change
those policies (with a recommendation/clarification about the meaning
of the 'R' bit in 3344bis) than to make deep changes in the security
association processing code.

-Pete

---

From: Pete McCann <[email-masked]>
Date: Thu, 6 Jan 2005 09:47:44 -0600

Hi, Sri,

 > allowing De-reg traffic directly ignoring the "R" bit may

Wouldn't it be easier to change those policies than to change the
security association processing code?  See my response to Henrik.

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 06 Jan 2005 18:02:49 +0100

> are on the same subnet as the FA.

True; so this sounds as if we have a potential solution for the regular
case (CoA belongs to the FA) but not for the R-bit case.

> text than it is right now.

Yes.  For not the first time I'm so tempted to advocate ripping out the
R-bit...  It causes such a lot of grief.  Anyway, for Co-located CoA
with registration through FA, we can then proceed by

  a. Disallowing FHAE on these de-registrations
  b. Defining a new extension to handle this case
  c. Restricting the use of the R-bit together with FHAE
  d. Grip the nettle and remove the R-bit from 3344bis
  e. Come up with another solution

> as the SAs are properly configured between the FAs and HAs.

Mmm? With FHAE always used, the de-registrations of external CoAs get
dropped, no?  (Are we talking past each other here?)

> then the administrator needs to fix something.

Hmm, then I don't think I know exactly what you're suggesting (but see
below)

> association processing code.

Ok, I see.  Hmm, this sounds like a slightly new variation on the theme,
and one which I've unfortunately not seen before.  Do we have proposed
text for this?  From this first impression, it sounds to me as if it
could be workable.

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Thu, 06 Jan 2005 10:50:50 -0800

Let's confirm what's agreed and what's not.

Is there agreement that FHAE is used to protect message exchange between
the FA and HA?

Now seems there could possibly be an exception based on the following.

>disrupt a de-registration that doesn't concern it.

This problem would not exist if the SA between FA and HA is legitimate,
which is the common case.  If there is a bad SA, then even registrations
would fail.  This would be completely noticeable, and the situation should
be fixed by administrator.  Deregistration is a corner case as described
below.

List of all deregistration cases:

1) MN returned home

MN deregisters when back at home network. This is not applicable.

2) Single binding support

a) MN deregisters from foreign network. Since MN is on newFA, there is no
reason to deregister from oldFA because the only binding is for newFA.
The deregistration may have CoA set to HoA or newFA. This is not
applicable.

b) MN moves to newFA and only deregister without registering on this FA.  I 
think
this is very uncommon case (pls correct me if wrong).  Only in this corner case
*and* the existence of a bad SA between newFA and HA (which must be fixed for
mobility service to be available), will the problem statement apply. The 
harm is
the HA would age out the binding entry later.  Much as if MN had lost all 
network
access, which this would be equivalent to since MN could not register to the
newFA.  IMHO, this should be just handled by having operational SA and not
over-specification.

3) Simultaneous binding support

Pretty sure that there's no deployment of simultaneous binding (S bit)
between HA and FA/MN currently. MN deregisters another binding from
current foreign network. But for MN to be registered on current foreign
network, the SA between newFA and HA must be valid.  Let's say that
SA is good, then there is no problem with deregistering the oldFA.
Let's say that SA is bad, then MN would not be able to register to
newFA either.  It would make sense for MN to find a FA that can be
registered before deregistering an old binding. If this is the case, then
there is no problem.

I just can't think of good reason to have any exception to the simple rule
of FHAE protecting message exchange between FA and HA, given my
opinion on case #2b.

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: Kent Leung <[email-masked]>
Date: Thu, 06 Jan 2005 10:59:17 -0800

Hi Henrik.

I'm in total agreement on getting rid of the R bit.  Is anyone deploying this
scheme?  I doubt it.  This bit makes specifications and coding much
more complicated.  There is little return on investment here.  Removing
the R bit in 3344bis would make our lives healthier, richer, safer, 
happier, etc.
OK, maybe just drafts and code simpler. ;)

It's such an annoying bit..... I think it's a case of over-specification. :)

Kent

---

From: Pete McCann <[email-masked]>
Date: Thu, 6 Jan 2005 16:34:43 -0600

Hi, Henrik,

Some comments below...

 > case (CoA belongs to the FA) but not for the R-bit case.

It seems like the only policy that can be checked by both the FA and
HA is to check the CoA against the source IP address of the
Registration Request between the FA and HA.  If they differ, and if it
is a de-registration, then omit the FHAE.

Of course, any NAT along the path will change the source IP address...
this really throws a monkey wrench into my understanding and I'm not
sure of all the security implications.

 >   e. Come up with another solution

I think (a) is the result of the policy I outlined above.

 > dropped, no?  (Are we talking past each other here?)

Why would they?  The HA looks up the SA based on the source IP address
of the packet (the FA) and if it checks out, then the message is
processed like any other.  What is the problem?

You may be bringing in a NAT-related issue here...

 > text for this?  From this first impression, it sounds to me as if it

The text would be to clarify the meaning of the 'R' bit: it would
really be "Registration Required" but not "Deregistration Required".

-Pete

---

From: Kent Leung <[email-masked]>
Date: Thu, 06 Jan 2005 16:04:14 -0800

A few issues with this FHAE policy solution:

- All deregistrations are unnecessarily constraint to use the CoA
as the source IP address of RRQ.  Typically, the egress interface's
IP address is used.  See Alan Oneill's thread on this topic of
allowing CoA and source address to be different.  Same argument
should apply for registration and deregistration.

- If deregistrations are confined to CoA as source IP address of RRQ,
deregistrations of binding on current FA using HoA in CoA field would
not be protected by FHAE.  Shouldn't deregistration of binding for
current FA be protected when SA exists between FA and HA?

- If deregistrations are sent with source IP address that is not the CoA
(assuming this is still allowed), then deregistration with CoA of current
FA would not be protected by FHAE.  It would make sense to protect
this type of message exchange.

- When administrator creates an SA between HA and FA, isn't there
a security agreement that should be maintained for communications
between them?  Is it up to us to decide that deregistrations don't need
to be secured?  Note FHAE omission happens also for MN deregistering
the current FA (when CoA is HoA or CoA is not same as src address).

The reason we are introducing this new FHAE policy is because the
fear that FA has a bad SA?  Any other circumstances that mandate
disabling of the security enforcement?

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 10 Jan 2005 23:10:47 +0100

Getting back to this issue after a long weekend...

...
> sure of all the security implications.

Yes.  I think we need to back up and look at what we want to accomplish,
and where we want to accomplish it.

> I think (a) is the result of the policy I outlined above.

Yes, that is the way I saw it and what I was thinking of for A.

> You may be bringing in a NAT-related issue here...

Yes, I'm afraid I was thinking of that.

...
> really be "Registration Required" but not "Deregistration Required".

Yes, that could be one way to go.

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 10 Jan 2005 23:35:01 +0100

Pete, Charlie, Kent, Sri,

Let me see if I have understood the issues here, and where we stand,
by trying to sum everything up the way I see things.  If I've missed
something, please correct me.

1.  The issues involved here occurs when there is a SA between HA and
    FA.  Currently the FA adds a FA-HA Auth. Ext to messages to the HA,
    and the HA expects to be able to verify the Auth. Ext appended to
    any message from this FA.

2.  We have two cases where this breaks down:

    a.  The FA is behind a NAT, and the MN is de-registering a CoA
	which is different from the CoA used by the current FA.  In
	this case neither source address nor CoA will be usable for
	finding the correct SA in order to verify the FA-HA Auth. Ext.

    b.  The FA has the R-bit set, and the MN is registered with a Co-
	located CoA.  It then tries to de-register a CoA which does
	not match any CoA used by the current FA.  Again the result
	is that neither source address nor CoA matches any address
	belonging to the FA, and it is not possible to match an SA
	with the FA-HA Auth. Ext.

3.  For the NAT case, 2.a., it is proposed that it should be handled
    by a 3519bis, not by the 3344bis.

4.  For the R-bit case, we currently have 2 proposals which seems to
    both permit de-registration in case 2.b. and not require a
    more complicated security policy.

    i.  Change the meaning of the R-bit to be "Registration through
	the FA required, but de-registrations MAY be sent directly."

    ii. Remove the R-bit completely from 3344bis.

Have I captured this correctly?

	Henrik

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 10 Jan 2005 14:58:59 -0800 (PST)

Hi Henrik,
          Please see inline ... I think you summarized it quite
right.

Sri

>     any message from this FA.

There needs to be a way for locating the SA's for the peer.

> 	finding the correct SA in order to verify the FA-HA Auth. Ext.

Yes !

> 	with the FA-HA Auth. Ext.

Assuming NAT here ?

>     by a 3519bis, not by the 3344bis.

If we incorporate the Source Address/Port of the tunnel peer in
the UDP Tunnel Request extension, we can solve this in 3519bis.
Probably, the source address is always the right way to locate
Security Associations. 3519 introduced this issue and probably
we can solve it by fixing the issue there.

>     ii. Remove the R-bit completely from 3344bis.

Removing it completely is not a bad idea, unless there are tons
of implementations supporting this monster bit.

---

From: Kent Leung <[email-masked]>
Date: Mon, 10 Jan 2005 17:56:28 -0800

>         with the FA-HA Auth. Ext.

Actually, the deregistration will work fine when the SA between FA
and HA is valid.  The SA is indexed by the source IP address of the
RRQ on the HA.  This IP address is the FA.

The NAT issue will be dealt with in 3519bis as you said.

>     ii. Remove the R-bit completely from 3344bis.

I agree with removing R-bit.

Just to be clear, one other optino is to leave RFC 3344 as is.  This means
the FHAE is always added by FA when relaying to an HA which it has an
SA.  And that the HA will authenticate the FHAE since it has an SA with
the FA.  This is what is already defined.

Charlie is requesting to loosen up the security checks between the
FA and HA (even if SA exists) for the case of deregistering an CoA that's
no the FA.

This problem doesn't happen if the SA between FA and HA is valid, which
would be expected for mobility service between them.

Kent

---

From: Pete McCann <[email-masked]>
Date: Tue, 11 Jan 2005 09:56:49 -0600

Hi,

 > >         finding the correct SA in order to verify the FA-HA Auth. Ext.

If this point is used as justification for disabling the FA-HA Auth
extension, then to me this seems like saying "security is too hard,
therefore we should turn it off."

There are other fixes here; one that comes to mind is to require the
administrator to configure a duplicate SA where the IP address matches
that of the NAT but the keys/algorithms/SPIs are the same.  This would
have zero impact on the Mobile IP spec but would increase the burden
on administrators to know about the NATs.

Another solution would be to make the SPIs globally unique (not
indexed per-FA) and use that as the uniform mechanism to find an SA.
However, this would be more of an impact to the base spec and existing
implementations.

Using the CoA to index the FA-HA SAD doesn't work for the case of
co-located CoA, whether we are talking about Registrations or
Deregistrations.  Don't we need to solve this problem for
*Registrations* before we consider kludges to handle the failed
Deregistrations?

 > The NAT issue will be dealt with in 3519bis as you said.

I agree with these two points.

 > >     by a 3519bis, not by the 3344bis.

And this one.

 > I agree with removing R-bit.

We might want to be careful here; I know that 3GPP2 currently
specifies the use of the R-bit for PDSNs and there may be other
deployments that use it as well.  Personally I would rather relax the
semantics in the minimal way needed to fix this problem than to get
rid of it entirely.

-Pete

---

From: "Charles E.Perkins" <[email-masked]>
Date: Tue, 11 Jan 2005 12:53:35 -0800

Hello Kent,

One more thought on this...

> FA and HA (even if SA exists) for the case of deregistering an CoA that's

It's also good to keep in mind what FHAE does.
It allows the home agent to verify the identity of the
foreign agent that claims to relay the deregistration.

But, in the case under discussion the home agent doesn't
care which foreign agent sent the deregistration.
I believe it's always better to eliminate wasteful
work when it doesn't have any beneficial effect.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Tue, 11 Jan 2005 17:31:20 -0800

Thanks Charlie.  I contend if there's a security relationship
set up between HA and FA, then message exchanges
should always abide by this policy.  And that operationally, the
SA is valid and deregistrations of old CoA, HoA, CCoA
will all work.

One more thought is for such corner case (my humble opinion)
where nothing is broken (unless administrator makes mistake
which prevents general mobility service), it's best to leave
specification as-is.  If there is overwhelming evidence or deployment
feedback that this is operational issue, then we can address this.

Last 2 cents on this topic ... :)

Kent

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 11 Jan 2005 20:18:35 -0800

Hello Kent,

What you say is certainly correct, depending on _what kind_
of messages.  For instance, you probably meant only
messages that are sent to a particular port.  But I would
be equally well justified to say that the messages to be
validated are those which are specified in the Mobile IP
document.  To go farther than this, I would most likely
get into a discussion about what's wrong with IPsec, and
I reckon neither one of us wants to swim around there.

As a thought experiment, suppose that the Mobile IP
specification had defined _two_ port numbers for
operations between the mobile node and the home agent.
In fact, this was discussed a long time ago.  What would
the force of your argument be in that case?

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Wed, 12 Jan 2005 10:17:01 -0800

Hi Charlie.

Since the source port of the Mobile IP registration message
is at times set to a variable number, the security association
is not binded to a particular port but based on the protocol
type.  For example, an MN may use different UDP port
number for each registration request and authenticate the
registration reply destined to that port using the same SA
for the HA.  The same case exists between FA and HA.
The index of the SA is based on the IP address and SPI,
so the port number is not directly linked to the security
relationship.  I see the port number mainly as a transport
for messages between mobility entities.  I think we're
in agreement here?

Kent