Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd)

From: Henrik Petander <[email-masked]>
Date: Tue, 16 Oct 2001 10:39:18 +0300 (EEST)

Hi,

Here are some comments on the draft:

1) Replay protection : MN and HA are assumed to have an existing security
association. If it is a manually configured shared secret, i.e., not
created dynamically, replay protection becomes an issue in the subnets of
MN and HA. Still replay protection is not mentioned in the requirements
and neither is replay attacks in the threats section. 

Replay attacks can be generally divided into a) DoS attacks where an
attacker in same subnet as MN, HA (or CN) replays BU of MN to HA (or CN)  
to a random address and b) redirect attacks where the attacker located in
old foreign subnet of MN replays the BU from MN and configures itself with
old CoA to get packets to home address of MN.

2) Different requirements for HAs. The draft handles HAs differently
depending on whether they are "foreign" HAs or "normal" HAs. Still both
kinds of HAs provide exactly the same HA services to MN. MIPv6 protocol
does not define any differences. The difference between how MN and its
"normal" HA and how MN and its foreign "HA" interact is only a matter of
policy. Thus also the security assumptions and requirements for the
protocol should probably be the same.

3) The requirement of authenticating ICMP DHAAD requests should be made
less strict or removed altogether. If IPSec is used for authenticating it,
MN needs to have a SA for an anycast address. AFAIK, this is not possible.
If MN wants to do DHAAD with its old foreign network HAs, how could it
dynamically create a SA with the home agents anycast address?

4) The requirement H.3 of not allowing the processing of the home address
option, if it is not authorized, in practice prevents triangle routing. We
agree with the analysis of the threat H.3 caused by home address option,
though. This should be specified more excatly if authorization for home
address option is required.

5) The draft seems to accept or implicitly propose an authorization
mechanism, which is vulnerable to attackers located in the subnets of MN,
CN or HA. From a security point of view these vulnerabilities should be
avoided if possible in the first place. Later adding an option to use more
secure alternatives such as SUCV, CAM, etc. does not really add to the
security, if a less secure mechanism based on return routability is still
mandatory. Also first creating a less secure mechanism and later adding
more security as an "optimization" does not work, since vendors will from
interoperability reasons support the old mechanisms and most
administrators probably do not really understand their difference.

It should be noted that any authorization mechanism for BUs based on
return routability is not applicable to CNs on insecure links (for example
MN in its home WLAN acting as a CN) and its use MUST be configurable.

6) The requirement D.2 of authenticating BRs is useful only if MN uses
reverse tunneling via HA or mechanisms decribed in 7.2.3. If MN uses
triangle routing, CN gets to know both the home address and the care-of
addresses of MN by pinging the home address. The effect is the same. If
BRs should be accepted only from CNs MN is already communicating with, the
same requirement should apply to triangle routing.
  
Editorial comments:

1) 7.3 Requirement B.4 is ambiguous. It should be ...mobile node SHOULD
ensure the sender of the BA was authorized to send it.  Now the text gives
the impression that MN should generally trust the sender, whereas MN
should actually trust that the sender of the BA was the node to which MN
sent the BU and which is authorized to send the BA.

Regards,

Henrik Petander,
Catharina Candolin

		----------------------------------
		Henrik Petander 		
		Helsinki University of Technology,	
		GO/Core Project 
		[email-masked]
		Office: +358 (0)9 451 5846 
		GSM: +358 (0)40 741 5248	
		----------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 12:52:28 +0300 (EEST)

> dynamically create a SA with the home agents anycast address?

I don't follow this line of though.  If ICMP DHAAD cannot be done
securely, why should the requirements be made less strict to allow it to
be done insecurely?  What point would there be in security if the
requirements could be waived when they may be inconvenient?

If this cannot be worked around, perhaps best course would be to remove
ICMP DHAAD altogether for now like mobile routers, and specify it better
later, when it can be done properly.

> 4) The requirement H.3 of not allowing the processing of the home
> address option, if it is not authorized, in practice prevents triangle
> routing. We agree with the analysis of the threat H.3 caused by home
> address option, though. This should be specified more excatly if
> authorization for home address option is required.

Let me phrase it this way:

If a CN does not have a binding for the MN, would there be any need for CN
to process HA option?

I don't think so, but I may be wrong.

A probable corner-case is establishing the binding, which has even more
reason to be done securely.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Henrik Petander <[email-masked]>
Date: Tue, 16 Oct 2001 14:15:02 +0300 (EEST)

On Tue, 16 Oct 2001, Pekka Savola wrote:

> be done insecurely?  

Bad choice of words from me. The comment on the requirement of
authenticating DHAAD being difficult to do was not meant as a reason not
to authenticate DHAAD, but as a comment on the feasibility of doing it.

IMHO the authenticating of DHAAD requests should be optional or a SHOULD,
since the threats DHAAD creates are not relevant in many cases. The home
agents can still be found locally from router advertisments sent to the
home subnet or remotely possibly with traceroute or pinging the all home
agents anycast address, etc. Actually a more relevant threat is a faked
reply to MN, which would result in MN sending BUs to nonexistant
addresses.

On closer reading I noticed also a sentence about using HA as a packet
reflector in 6.8., Result H.1. This should probably be in some other
section (header for H.2?) since DHAAD does create any new opportunities
for DoS using HA as a packety reflector when compared to other ICMP types.

> later, when it can be done properly.

The authentication requirements for anycast DHAAD requests probably make
it more convenient to use some workaround, e.g, configure MN with the DNS
name or the IP address of its home agent and then possibly send DHAAD
requests to the unicast address.

> If a CN does not have a binding for the MN, would there be any need for CN

Yes, if the CN does not support route optimization and the MN sends
packets directly to it. CNs with minimal protocol stacks probably will not
support route optimization, whereas processing the home address option
requires only very little effort and no state from a CN. Even if a CN
supports route optimization, a MN can send a BU to the CN only after
receiving the first tunneled packet from the CN.

Henrik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 16:15:19 +0300 (EEST)

> receiving the first tunneled packet from the CN.

Am I right by saying:

 - with Home Address, without BU: the route will be suboptimal, but 
mobility (connections break if MN changes IP address) will still work.
 - with Home Address, with BU: route will be optimal and mobility works.
 - without Home Address, without BU: the route will be optimal and 
mobility will not work
 - without Home Address, with BU: route will be optimal but mobility will 
not work.

That is, 

if HA
  mobility
  if BU
    route optimization
  fi
else
  route optimization
fi

From above, the only reason why HA should be useful for a dummy node not
implementing BU is mobility (non-breaking connections).  Is that scenario
relevant enough to justify non-authorized HA usage?

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 17:01:04 +0200 (CEST)

> If a CN does not have a binding for the MN, would there be any need for CN

Yes.
As MIPv6 is currently defined the MN will always (except when reverse tunneling
through the HA) include a HA option. The home address will be the address used
in higher level protocols. For instance, the TCP connection identification and
TCP pseudo-header checksum use the address in the HA option.

Thus all IPv6 implementations MUST process the HA option as MIPv6 is currently
defined.

If it turns out that this is an unacceptable source of reflectors (that can be
used for DoS attacks etc) then I suspect that the protocol needs to change
so that the HA option is only used once it is known that the CN has
accepted a BU from the MN.

Thus MIPv6 would operate in two different modes: 
before a BU is accepted doing rectangular routing i.e. reverse tunnel.
after the BU is accepted send packets directly to CN using HA option.

Changing the protocol to work this way seems to require that the MN always
ask for an ACK to BUs sent to CN so that it knows for sure when a BU
was accepted and some mechanism to recover from a CN that as accidentally
or intentionally (garbage collected) the binding cache entry.

But first let's make sure we agree on the requirement wrt the HA option.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 16:54:04 +0200 (CEST)

> and neither is replay attacks in the threats section. 

Agreed that the document should talk about replay threats.

> protocol should probably be the same.

The difference between the HA and the "previous default router action as
a HA for a previous CoA" (I sure wish there was a concise term for
the latter) is that requirement D.1 (which is really an assumption)
applies in the former case but not in the latter.

Only if you believe there will be pre-existing security associations between
the MN and all possible default routers it uses while moving around ,
does it make sense to treat them the same.

> dynamically create a SA with the home agents anycast address?

Are you saying that the reason to make the requirements weaker is because
we don't know how to implement it securely? How does this create secure 
protocols?

In reality I think it can be implemented. If the MN has some abstract SA with
its collection of home agents (the boxes that provide it with the
home agent service on its home subnet) it can clearly use that to
communicate with any HA, including the anycast address.
You do have a point if this abstract SA is implemented e.g. as an AH or ESP
SA. It would be good to understand the options in this case.
Can't the pre-establishment of such an AH or ESP SA be made with a collection
of machines i.e. some machinery to associate e.g. the same IKE pre-shared
keys with both the HA anycast address and the HA addresses that are
discovered?

So I think the requirement is a reasonable one.

> address option is required.

Agreed.

> administrators probably do not really understand their difference.

Mandatory to implement doesn't imply that all CNs are required to accept
BUs with the weaker forms of security forever.
Some CNs might reject BUs for such simple reasons as not wanting
to create a huge binding cache, so rejecting them for security reasons should
be fine as well.

> same requirement should apply to triangle routing.

By "communicating with" do you mean "to which the MN has sent a BU" i.e.
"the CN is in the binding update list"?

   Erik

---

From: Kishore Asarpota <[email-masked]>
Date: Tue, 16 Oct 2001 11:05:16 -0400

Hi,

Is there a Mobile Node product out there that I can use for
testing my HA and FA routers. I am just curious to find out
what is everyone using as their MN for testing. I have the Linux
version running, is there anything else.

thx, kishore

---

From: Henrik Petander <[email-masked]>
Date: Tue, 16 Oct 2001 20:04:41 +0300 (EEST)

> does it make sense to treat them the same.
 
The main point was that if MN and its regular HA need a "strong" SA, so do
MN and its "foreign" HA. I agree that the assumption that MN and its HA
have a preconfigured security association might not easily apply to the
"foreign" HAs. Probably they and MN will still have an existing trust
relationship, so that they can create a "strong" SA.
 
> we don't know how to implement it securely? How does this create secure
 
See my response to Pekka's mail. The reason for not requiring it was not
the difficulty of making it work, but more related to the benefits of
authenticating the requests.
 
> communicate with any HA, including the anycast address.
 
I agree that it should work on a theoretical level, but I am just afraid
that specifying it to work using existing mechanisms such as IPSec may be
difficult.
 
> SA. It would be good to understand the options in this case.
 
Probably ESP or AH would be the easiest way to secure the ICMP messages in
MIPv6. Speaking of ICMP messages, I did not see any mention of the mobile
prefix solicitation and advertisement, of which at least the latter should
be authenticated, since it creates state in MN. This is already mentioned
in the draft of draft 15.
 
The authentication of DHAAD request would require that the SA between MN
and the anycast address would apply to all the HAs and that they would
share and synchronize all state for the SA. I don't know if this is
actually doable, at least replay protection would break this or make
synchonization expensive. Maybe it could work without replay protection,
though.
 
> keys with both the HA anycast address and the HA addresses that are
 
If you establish a SA with one of the HAs, the HA receiving the DHAAD
request could be a different one. There would need to be a system to
distribute the created SA from the HA, which took part in IKE with MN, to
also the other HAs.
 
> > triangle routing, CN gets to know both the home address and the 
> > care-of addresses of MN by pinging the home address. The effect is the
> > same. If BRs should be accepted only from CNs MN is already
> > communicating with,the same requirement should apply to triangle
> >routing.

> "the CN is in the binding update list"
 
More generally, the decision to reveal both the home address and care-of
address should be handled similarly by the privacy policy of MN,
regardless of the method the location and identity are revealed. (If MN
has a privacy policy not to send BUs to certain nodes, it should not use
triangle routing with those nodes.)

Henrik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 21:52:04 +0200 (CEST)

> relationship, so that they can create a "strong" SA.

Could you explain the source of your belief expressed in the last sentence?

If you are correct and a MN can have a trust relationship with an
arbitrary previous default router, then why is that limited to just routers?
If it isn't then I think you've just shown that an MN can have a trust 
relationship with an arbitrary CN.
Thus we wouldn't need any new method for securiting BUs following this
logic.

Where did I go wrong?

  Erik

---

From: Henrik Petander <[email-masked]>
Date: Wed, 17 Oct 2001 11:42:13 +0300 (EEST)

> Could you explain the source of your belief expressed in the last sentence?

MN and the ISP providing the access via the router are likely to have a
trust relationship, since MN is allowed to use the resources of the ISP.
This trust relationship could be used also between the (acccess) routers
acting as HAs and MN to authorize the use of the HA service.

I think that the problem of authorizing the home registration is twofold,
on one hand MN needs to prove that it is allowed to use the service of HA,
and on the other it needs to prove that it "owns" the possibly temporary
address it is trying to register with the HA. The trust relationship
between MN and the default router could easily be used for the first
purpose, but for the second purpose something else is needed. 

One possible solution is that MN creates the SA with the "foreign" HA when
it is in the same network as the HA and, if the HA does not have an
existing registration / SA for that address it accepts the SA, provided
that MN is authorized to use the HA service. If the registration fails MN
creates a new CoA with a random host identifier and tries to establish a
SA for it. DAD would guarantee that there would not be two nodes with the
same address.

MN presents its credentials to the HA to gain access to the HA service, so
only nodes authorized to use the service of the HA could establish SAs and
do home registrations for the addresses. This should protect the system
against DoS attacks effectively. The same system could perhaps be used
also for "normal" home registration with dynamic DNS. 

What do you think?

Henrik

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Oct 2001 11:27:13 -0700 (PDT)

> I don't think so, but I may be wrong.

   I believe it does. Even if the CN ignores the
   BU, it needs to process the HA option so that
   it can properly receive datagrams from a topologically
   incorrect address (ie, at the new CoA). Otherwise
   TCP, etc, would fail since it looks up the src/port
   normally, which wouldn't find a TCB for the CoA.

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Oct 2001 11:44:29 -0700 (PDT)

> does it make sense to treat them the same.

Erik, 

I brought this point up in my comments as well
Currently, the draft is silent about any
differences between "home" HA's and other kinds of
HA's (basically tunnel drop off points). My
general inclination is that given the permanent
DoS, MITM, etc, kinds of attacks that can be
mounted by an illegitimate HA of any kind, it
would be prudent to require strong authentication
all the time.

Also: I'm not sure I buy your induction of
non-Home-HA's (<-- ick!) to CN's at large.  While
it's not always the case, it's fairly clear that
you could create cross realm relationships to deal
with MN/HA(FA) keying. Since there is likely to be
admission control on the foreign network in many
cases, it's not really the any-to-any keying
problem that MN/CN presents. Since these localized
HA's are just an optimization for fast/smooth
handoffs, I don't really see them as being in the
same class: there's probably a lot of implicit
assumptions about QoS, security, context transfer,
etc to affect that, and the probably means a
fair amount of linkage to AAA-like subsystems,
unlike the MN/CN communication.

	    Mike

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Oct 2001 21:59:57 +0300 (EEST)

>    normally, which wouldn't find a TCB for the CoA.

True.

But this should also be true:  if neither HA nor BU are processed, mobile
node can still communicate with everyone.

Only, the connections will break if MN moves so that IP address changes.

So the worst case appears to be like with normal IPv6.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 Oct 2001 09:10:25 +0200 (CEST)

> also for "normal" home registration with dynamic DNS. 

I think you've, perhaps non-intentionally, just shown that you agree with
my original point which was that the security and trust issues with
a previous default router accepting BUs from an MN for the MNs previous CoA
(in the "previous-default-router-HA-for-CoA" case)
requires quite different security mechanisms than what is needed
between the MN and its "normal" HA.

Hence it makes sense to discuss them separately in the security-reqs document.

   Erik

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 18 Oct 2001 12:09:17 +0200

>  - without Home Address, with BU: route will be optimal but mobility will
As a note: this is how Homeless MIPv6 (and SCTP) works. First, you
register valid addresses to use, next you can use any of them as source
address.

> relevant enough to justify non-authorized HA usage?

Finally, I'd like to point out the issue of location privacy again.
Maybe have a second thought about this when we find ourselves having a
lot of problems with practically everything that has something to do
with route optimization.

Using bi-directional tunnels between MN and HA basically
+ provides location privacy
+ will work today
+ will be secure
- longer RTT
- slightly lower PMTU

What if we spend another five versions on this I-D trying to fix RO and
the luxury and then people come asking for solutions for location
hiding? Will that not kill RO anyway?

I'm sorry for sounding so negative but I see my list of advantages of
MIPv6 getting shorter for each day we learn something about security. I
don't want to underrate the work you people are doing but I think at
times one should look at things in a different light.

Why not take the tricky parts to IRTF as someone said?

/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: 18 Oct 2001 14:07:24 +0200

Henrik Petander <[email-masked]> writes:
> 1) 7.3 Requirement B.4 is ambiguous. It should be ...mobile node
> SHOULD ensure the sender of the BA was authorized to send it.  Now
> the text gives the impression that MN should generally trust the
> sender, whereas MN should actually trust that the sender of the BA
> was the node to which MN sent the BU and which is authorized to send
> the BA.

Ok, I would better like to see "mobile node SHOULD ensure the Binding
Acknowledgment it receives comes from the legitimate node to which the
corresponding Binding Update has been sent".

Also, Charles proposed to use "MN should authenticated the sender of
the Binding Acknowledgment", but I feel this implies too much the use
of crypto exchanges, while other mechanisms could be used instead.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: 18 Oct 2001 14:31:54 +0200

> Agreed that the document should talk about replay threats.

Replay threats have been mentioned several times in the discussions.
I feel they are too generic to be treated separately in a Mobile IPv6
- specific document.

I can list 21 generic threats in computer communications (from a book)
and then find embodiments for each of them in Mobile IPv6.  Is this
what is wanted?

Take replay.  Replay of BU's only?  Why not replay of ack's?

Take repudiation.  An MN could decline to respond to Binding Requests
coming from a CN (those binding requests are sent to MN _after_ MN has
sent an initial BU, so now MN denies it has sent that initial BU:
repudiation).  What's the likely effect of this?  Probably not big
deal.  This is why it's good to quantify the realization of each
threat and then decide which of them is worth defending against and
which is not.  But it looks nobody is sensitive to this.

All we have to this point is only _rough_ evaluations to what it's
worth protecting: do no harm, no worse than current Internet, etc.

Alex