Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4

From: Phil Roberts <[email-masked]>
Date: Wed, 22 May 2002 19:56:39 -0400

> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:[email-masked]] 
> 
> Since I disagree with the 'architecture' argument, I have
> to comment on this.

Did you comment on what part of the argument you disagree with?  The IAB
recommendations themselves?  Or that they apply here?  I'm sorry if you
said that and I missed it.

> 
> Also, regardless of why it's needed, it's already
> there. We already have a precedence.

Yuk.

> BTW, this raises
> the issue of HA redundancy. We need to address that 
> at some stage.

Agreed.

> 
> I would also like to add a note, for the WG in general, 
> not only to James. Can we _pleeeease_ have some consistency
> in the way we assess proposals. Let's consider the RFC being 
> referenced here (1958). Doesn't the quote used by Phil state 
> that the intelligence should be in the end hosts? So why are 
> we accepting proposals that do not follow these principals? 
> Yes I'm referring to both FMIPv4 and FMIPv6, and I have 
> contributed heavily to both drafts, so no bias here ;)

Good questions.  There are some interesting questions about to 
what extent these sorts of things can be done without help at the
edge, and how that effects the way we think about architecture.
Definitely needs some thought.

> 
> I don't understand why certain actions are taken towards
> some proposals and not others. Why was their a big LMM 
> requirements doc done for one WG document and not 
> for reg reg in MIPv4? 
> All these things need to be considered. Using a separate 
> process to handle each proposal is not only confusing, but 
> will likely lead to no direction for this WG's output.
> 
> Please follow one process!

Responded in a separate thread, so folks can track it.

> Hesham

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 22 May 2002 19:26:52 -0700

Hello,

We have a question on the security of BUs...

The current draft identifies a need to verify the
return routability of CoA when the BU is sent to
a CN. 

But it suggests that one can use IPsec between
the MN and the HA when MN is sending a BU,
and this should be sufficient.... Shouldn't we be
doing a RR on the CoA even if we are using IPsec?

alper

---

From: Francis Dupont <[email-masked]>
Date: Thu, 23 May 2002 11:55:38 +0200

=> this is an open point. Some believe RR check is simply
mandatory, some believe RR check is only one possible way
to fulfill security requirements and a suitable IPsec protection
should not need an extra RR check (the argument is the RR check
is not possible for the HA so "suitable IPsec" includes the trust
in the MN to not provide a fake CoA).

=> I believe the answer is no and I'd like to see how to perform a RR
check between the MN and the HA...

Thanks

[email-masked]

PS: note the MN may (so it MUST) protect the CoA as soon as
nobody adds a "NAT traversal" capability to the signaling protocol
(I've written an I-D about this kind of problems, it should be
published soon).

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 May 2002 07:08:47 -0700 (PDT)

> doing a RR on the CoA even if we are using IPsec?

Alper,

I don't think it's necessary. A normal security
association decides, for example, whether to pass
data through the stack/forwarding-path given the
credentials. Since the home agent "owns" the
source subnet, I don't think it's much of a
stretch to say that it can decide based upon
presented credential whether a MN can move
bindings around as well. That is, the credential
itself could imply "allow pass/forward/rebind".

This is distinctly different than the
correspondent node case which has absolutely no
relationship with the subnet in question (in
general). In that case the credential would need
to be more specific; where you could imply it
above, it would need to be specific if you want to
guard against inside attacks (eg, attacks
authenticated but malicious MN's). On the CN
insufficient authz could lead to a hijacking
attack since it doesn't "own" the subnet and has
no way to know who that address/prefix was
delegated to. This isn't the case on the HA since
where the worst that could happen is a depletion
of IP addresses attack on that subnet, and even
that would be pretty easy to defend against.

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 May 2002 08:33:05 -0700 (PDT)

> in the MN to not provide a fake CoA).

Francis,

I thought of another way of thinking why it's not
necessary. IPsec as an access control mechanism,
protects a host (transport) or router (tunnel)
from unauthorized traversal past the access
control point, either up the stack or through the
forwarding plane. Thus, unauthorized packets are
not allowed, say, to do HTTP GET's on web servers
which are behind that access control point. If you
have credentials to burrow through (ie, make an
SA), you're at liberty to send whatever packets
you care to, subject to the hole's restrictions.

We can view (re)binding the same way as HTTP. That
is, if you have sufficient authz to create a hole
in the IPsec firewall -- on the HA presumably --
you are at liberty to send binding packets through
the hole, just like you might be able to send
packets to any other server through the hole. In
this case, the home agent is quite similar to any
other server; indeed, it is providing a service:
mobility tunneling.

		Mike

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 23 May 2002 16:03:59 -0700

Francis,

> In your previous mail you wrote:
> 

Yes, this is the question: does a "suitable IPsec" include the trust
in the MN to not provide a fake CoA?

But, if such a trust between MN and HA was sufficient, a "home
test" that goes through HA should have been sufficient for
sending BU  to CN. Home agent could verify that the MN is
authenticated and authorized before passing the test packet on.
Am I missing something??

> check between the MN and the HA...

After HA receives the IPsec'ed BU, we can add one more round-trip between 
the HA and the CoA. This can verify that the MN is really reachable at
the CoA before binding cache entry is modified.

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 23 May 2002 16:12:11 -0700

Mike,

> itself could imply "allow pass/forward/rebind".

Yes, this means that MN is authorized to change
the binding cache, but it doesn't say if the MN is
authorized to change the care-of address to a
given IP address... Because we don't know if the MN
is the host using this CoA or not. We seem to care about
this for when BU is sent to the CN, but ignore it with HA.

alper

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 May 2002 17:12:23 -0700 (PDT)

> this for when BU is sent to the CN, but ignore it with HA.

   Let's see: the home agent knows which identity
   is bound to a particular *home* address, and it
   expects that anybody who is trying to change the
   binding for that home address to a new CoA must
   prove that it has keying material from the identity
   bound to that home address. Ie, it must ship
   an IPsec integrity protected BU meesage over an SA
   that was created using that identity.

   What's the problem here?

	      Mike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 May 2002 14:12:58 +0200

=> I believe it does.

   sending BU  to CN.

=> no because this "home test" assumes the CN trusts the HA
and it has no more reasons to trust it than the MN.

   
=> yes, we can do something similar to the case where the sequence number
is wrong using the sequence number as a value the MN must repeat.
Exceptions to this extra check (which is not the 5.5.5 RR) should be
the return to home (H@ = Co@) and renew (old Co@ = new Co@).
Is this check worth an extra round-trip?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 May 2002 14:21:03 +0200

What's the problem here?
   
=> the issue is with the COA. I believe the check proposed by Alper
is a good idea and as it is initiated or not by the HA, it is managed
by the HA: it is a good option for IPsec protection.

Regards

PS: 11.6.1 has a "The mobile node MUST store this information and use
the next Sequence Number value for the next Binding Update it sends"
at the reception of BA with status 141 "Sequence number out of
window" so the bad sequence when the COA changes for something else
than the home address is a suitable procedure (and with ESP this
sequence number is not visible to eavesdroppers).

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 May 2002 16:54:02 +0200 (CEST)

> doing a RR on the CoA even if we are using IPsec?

[I'm assuming that IPsec authentication ensures that the MN is not being 
spoofed.]

A possible way to look at this is to compare the relationship
between the nodes.

The HA and MN have some form of trust relationship and some form
of business relationship (whether or not money changes hands).
The CN and MN are not assumed to have any such relationship.

Thus if a MN misbehaves by sending BUs to its HA that have a bogus CoA
(for the purposes of launching a DoS attack against that CoA) the victim
can contact the HA's adminstration/ISP to alert them of this attack
and they can take appropriate action against the MN usingv the above
relationship.
Contrast this with the CN case where the MN, using a bogus CoA, can cause
a CN with high bandwidth to flood the victim. If the victim contacts
the CN they are not likely to be able to do anything about the misbehaving
MN due to the lack of a relationship.

Also, if the HA was indeed required to to a CoA RR check, it doesn't
prevent misbehavior. The HA and MN might be run by the same administation
(i.e. my HA at home and my MN on the road), in which case the HA might 
just ignore the requirement to do the CoA RR check, or the HA might 
pretend that the HA exists when in fact there is no HA.

So requiring the HA doing a CoA RR check doesn't seem to remove the
need for adminstrative measures that treat the HA+MN as one unit
when it comes to misbehavior.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Fri, 24 May 2002 18:59:21 +0300

> authenticated and authorized before passing the test packet on.

One difference that was mentioned was the trust, or at least
relationship, between the MN-HA which doesn't exist between
the CN and either of the two other nodes.

Another difference is that the MN-HA security is end-to-end
and directly observable by the end-points. In the case above,
the CN would have to not just trust the HA, but also the
_path_ towards the HA.

For these reasons the care-of tests are necessary in the CN
case. It isn't clear that the same reasons apply in the HA
case.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 24 May 2002 19:14:28 +0300

> when it comes to misbehavior.

This is true, and I agree.

It considers HA+MN from an outside viewpoint. There
may be another aspect if you look at things from the
inside, e.g. from the point of view of e.g. an ISP operating
a HA. While they have a contractual relationship with the MN's
owner, they might still wish to _prevent_ forged CoAs rather
just to send a bill/police to the MN's owner afterwards, if
someone complains. Still, the ISP could cut the MN's access
off immediately when a complaint is received. So I'm not sure
a test is worth the trouble. Certainly not as a mandatory thing
for everyone.

I think Francis was saying that we already do something similar
in the sequence number resync case. Actually, it seems that the
HA could implement a CoA test using existing protocol mechanisms,
if they wanted. Just complain about a wrong sequence number,
and require the MN to resync. The right sequence number will not
be received if the CoA was wrong. (Of course, with some effort
you could guess the sequence number with repeated trials, but
at this point the HA would probably notice that something funny
is going on anyway.)

In conclusion, we have the following options:

(1) Declare that we never need such tests. End of story.
(2) Declare that we always need such tests, and add this
     to the protocol.
(3) Declare that you are allowed to run such tests, if your
     policy requires it. You could alternatively implement this
     with (a) existing mechanisms or (b) design new mechanisms.

My personal preference is either (1) or (3a). I don't think
we should spend too many cycles on specifying this or roundtrips
on doing it.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Fri, 24 May 2002 09:21:58 -0700 (PDT)

>      with (a) existing mechanisms or (b) design new mechanisms.

Jari --

I vote for (1). Nothing would prevent us from
implementing (3) at a later date if it were
perceived to be necessary. Indeed, keeping our
options open here may actually be a benefit for
mobility since being able to project a new binding
where you aren't currently reachable -- but
assumely will be soon -- could be advantageous for
MN's trying to keep connectivity.

	     Mike

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Fri, 24 May 2002 09:27:46 -0700

If the CoA is not being used, then the HA does not have a BCE for it, which
implies that the MN can use the CoA if it wants without bothering any other
MN. The question would be does the HA allow a CoA to be shared between
multiple MN's ?

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jari Arkko
Sent: Friday, May 24, 2002 9:14 AM
To: Erik Nordmark
Cc: Alper E. YEGIN; [email-masked]
Subject: Re: [mobile-ip] RR and BU to HA

Jari

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Fri, 24 May 2002 09:47:05 -0700

Is there a possibility of similar spoofing in the Home Address (HoA) field
in RR/BU ? How should the CN/HA treat a BU/RR  with a "spoofed" HoA  ?

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dr. Subrata
Goswami
Sent: Friday, May 24, 2002 9:28 AM
To: [email-masked]
Subject: RE: [mobile-ip] RR and BU to HA

Subrata

-----Original Message-----

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 24 May 2002 20:30:40 +0300

> in RR/BU ? How should the CN/HA treat a BU/RR  with a "spoofed" HoA  ?

I'm not sure I understand the question, but if you are asking
for the basic spoofing attack of claiming a wrong home address,
then in the CN case we make a home address test. In the HA case
we must make sure that the right SA is used together with the
right home address, to prevent another mobile for the same HA
taking over your address.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 24 May 2002 20:35:06 +0300

> MN. The question would be does the HA allow a CoA to be shared between

I don't see a reason to prohibit the same CoA for several MNs. Anyway,

as long as the MN doesn't register its current address in the home
agent, it looks exacly like any IPv6 address and the same rules apply
on duplicate address detection etc.

Jari

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 28 May 2002 11:52:46 -0700

>      with (a) existing mechanisms or (b) design new mechanisms.

Earlier, it wasn't clear whether this policy difference between processing
BUs at the CN vs at the HA was a design choice with an explanation.
It seems like there are explanations on this. Therefore I don't mind
going with (1), as long as we put one or two sentences in the draft
reasoning this design. And if people think that this might be an issue
for an highly-secure deployment, they can write a separate draft to
fix it (like 3a).

alper

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 May 2002 23:20:21 +0300

> for an highly-secure deployment, they can write a separate draft to

Ok, looks like most people agree on this. I'm writing a new
version of the security considerations sections. It contains
the following text:

   ...
   The above mechanisms do not show that the care-of address
   given in the Binding Update is correct. This opens the
   possibility for Denial-of-Service attacks against third
   parties. However, since the mobile node and home agent
   have a security association, the home agent can always
   identify an ill-behaving mobile node. This allows the home
   agent operator to discontinue the mobile node's service, and
   possibly take further actions based on the business relationship
   with the mobile node's owner.

Does this work for everyone?

Jari