Subject: multi6-threats-00.txt vs. MIPv6 - different strength verifications?

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Nov 2003 17:44:19 +0100 (CET)

Comparing the threats in draft-nordmark-multi6-threats-00.txt and
the residual threats in mobile IPv6 there are some interesting differences.
These differences are natural in that Tony and I try to based the
multi6-threats on the existing IPv4 Internet.

One case where MIPv6 is weaker than today's Internet is that an attacker
which is on the path for a few seconds can redirect packets for a few minutes.
In today's Internet an attacker needs to be on the path all the time in order
to be able to redirect packets to some other destination (for instance
by spoofing ARP on an Ethernet between two routers).
MIPv6 explicitly allows this but does limits the exposure to a few minutes.

Trying to compare different multi6 schemes and MIPv6 from a security
perspective there seems to be different types of verification going on.
In MIPv6 the strongest (which isn't very strong in this case) verification of 
the identity is that it is reachable at the home address i.e. there isn't
a MiTM between the correspondent and the home agent.
Once a node has be so verified the resulting redirection to a Care-of-address
remain valid for a few minutes and then needs to be renewed.

One can envision similar things for multihoming solutions.

We can have weak initial verification, for instance the first packet
arrived from some identifier/locator pair, and return traffic goes back
to the same node.

Then we can have strong verification, for instance using the DNS or the CBID
property with public key crypto, to verify that the peer indeed "owns" the
claimed identifier hence is authorized to specify the locators to use with it.

But, based on the MIPv6 model, one could also envision a weak but time limited
verification that builds on some earlier verification (whether the earlier
verification was weak or strong).
For instance, if the peer shows that it knows a clear-text random number
which was exchanged during the earlier verification, then it
might be reasonable to allow redirection to a new locator *for a limited time*.
 An on-path attacker could use this, but would have to repeat the attack every
few minutes i.e. it is not sufficient for the attacker to "drive by" some
link and launch an attack that lasts forever.
If the attacker needs to be on the path all the time the residual threat 
wouldn't be much different than what an on-path attacker could do today.

Comments?
   Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 3 Nov 2003 20:15:59 +0100

> might be reasonable to allow redirection to a new locator *for a

The problem here is how to extend the lifetime of the binding after an
outage. (using mip terminology)
The clear text random number has to be exchanged form both locators the
initial one (HoA) and the new one (CoA)
Once the outage has occurred, you cannot longer verify the HoA, since it has
become unreachable.
So the resulting solution only preserved established communications for the
*limited time* that the redirection last for.
this IMHO is an inherent problem of using IP addresses as identifiers and it
due to the fact that the way to prove the ownership is only provided by the
routing system( a possible workaround is to use an external authority to
secure the binding, such as the DNS), but in the nature of the IP address,
the only verifiable characteristic is the routability
The other possible workaround would be not to limit in time the binding but
limit it by connection, so that checks are performed when a connection is
set up, In this case, an attacker can hijack a connection but not a complete
IP address (in its identifier role).
This would change the scope of permitted attacks from some minutes in the
case of MIP to a single connection.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Nov 2003 12:39:22 +0100 (CET)

> *limited time* that the redirection last for.

Yes, but this gives you additional time to do a more heavy-weight verification
(whether using the DNS or PK for verification).
Before a failure is likely to occur it is desirable to have a strong 
verification for at least one alternate locator for the peer.
But if you don't, this weak verification could be used for some time
(a few minutes was the number that was picked for MIPv6). 

> the only verifiable characteristic is the routability

That is true for MIPv6.
But in multi6 there are approaches like using the DNS or public key CBIDs
for a strong verification.

> case of MIP to a single connection.

I don't know how that interacts with application assumptions.
The fact that some applications, in order to perform some work,
creates multiple parallel or sequential transport connections,
means that an application might implicitly assume that such connections to
the same IP address actually reach the same peer.
Then there is the issue when the ULPs notion of "connection" isn't known to
the multi6 layer; for example applications layered over UDP.

My gut feel is that the time limited weak verification has more predictable
behavior than basing things on some notion of ULP "connection".

But the point of my note was really that MIPv6 provides an example of
another building block that can be considered when looking
at performance/security tradeoffs for multi6.

  Erik

---

From: masataka ohta <[email-masked]>
Date: Tue, 04 Nov 2003 21:04:02 +0900

Erik;

> which is on the path for a few seconds can redirect packets for a few minutes.

One case where MIPv6 is no weaker than today's Internet is that
an attacker which is on the path for a few seconds can, by modifying
DNS answer, redirect packets for weeks.

In addition, an elementary fact on serious security is that once an
attack to a system is successful, the system is kept to be contaminated
unless the system is fully initialized.

That is,

> MIPv6 explicitly allows this but does limits the exposure to a few minutes.

is not a serious argument on security, at all.

However, the argument is even more pointless from the beginning.

MIPv6 and M6 share a property that they handle multiple addresses
but nothing beyond that.

That is, comparison of security of MIPv6 and M6 is nothing more
than an abstract nonsense.

							Masataka Ohta

PS

Can you discontinue the thread on false threats?

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Nov 2003 13:26:19 +0100 (CET)

> DNS answer, redirect packets for weeks.

Correct if the attacker is on the path between the host and the DNS 
infrastructure.

But part of the point is that there is a solution to make DNS more secure.
Once that is starting to get deployed it would be nice if we haven't
designed a multihoming solution which makes the network less secure again.

   Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Nov 2003 14:17:47 +0100

> verification was weak or strong).

No, this is no good at all. In multihoming, when a line goes down it 
may not come back up again. Ever.

> might be reasonable to allow redirection to a new locator *for a 

This is susceptible to a "man listening at the sidelines" attack. 
That's a relatively common capability. However, we can do better than 
this with by adding some hashing and gradual release of previously 
secret information. This is only susceptible to actual man in the 
middle attacks, but then so is everything else, as a MITM can always 
blackhole traffic if nothing else.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Nov 2003 14:28:42 +0100 (CET)

> may not come back up again. Ever.

Yes, but a weak verification can be converted to a strong verification
at any time by invoking the strong verification mechanism (be it DNS
or CBID-based).

> This is susceptible to a "man listening at the sidelines" attack. 

You mean somebody which is on the path and can see the content of packets, but
is unable to prevent packets from being deliverd on the correct path?

> That's a relatively common capability.

Do you have examples where seeing the content of packets is possible or 
significanty easier than also being able to supressing the delivery of
packets or modifying the packets?

> However, we can do better than 

Good point.
One can do a limited length hash chain and reveal it in reverse
reverse order as an improvement. If the chains are short enough (length 10?)
the cost of creating them might not be that significant; just run MD5 (or SHA1)
10 times. Should the chain run out, then one can fallback to the stronger 
verification.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Nov 2003 14:42:44 +0100

> at any time by invoking the strong verification mechanism (be it DNS

Why not go for the strong stuff immediately?

> is unable to prevent packets from being deliverd on the correct path?

Yes.

> packets or modifying the packets?

Wireless networks are a good example. Many switches provide monitoring 
capabilities and fibers are not that hard to sniff. So someone with 
physical access can look at the traffic with relative ease. However, in 
order to block selected packets the attacker needs to redirect traffic 
or install equipment in the middle. I suppose that's doable on wireless 
lans but not so much when tapping into existing monitoring 
capabilities.

> 10 times. Should the chain run out, then one can fallback to the 

Or use the last step to authenticate a new one.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 4 Nov 2003 14:37:31 +0100

> designed a multihoming solution which makes the network less secure again.

Fully agree
besides not all of the communications actually use the DNS, you can
establish a communication direclty using IP addresses.
Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 4 Nov 2003 14:57:37 +0100

> (whether using the DNS or PK for verification).

Ok, agree that this is an option, but it is an expensive option, i guess.
You will have to echange packets periodically (HoTI/HoT CoTI/CoT like
exchange) to always have valid authorization information available
(if authorization information lifetime is long you expose the host to more
dangerous attacks)
So, i guess that we would better off if we don't use such a mechanism (if we
can) and we just use the strong one.
But i agree that we should keep it in mind as a last resourse

[....]

> the multi6 layer; for example applications layered over UDP.

Well we could generate an ephemeral AID so that the every app has a
different AID. So we can distinguish every communication using its AID.
The other option is not to do it at the M6 layer, but do it at the TCP layer

> behavior than basing things on some notion of ULP "connection".

Yes, i may agree with that.
But the time limited option has a very important drawback: it is time
limited :-)
So it can be used as a bridge solution while you verify the binding with
stronger methods, as you mention, but not for much more than that.
The connection oriented solution can be used without any additional strong
mechanism

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 4 Nov 2003 15:07:41 +0100

> Or use the last step to authenticate a new one.
I don't see how could you do this, since the path to the initial address is
down, so you cannot exchange information using this address. Am i missing
something?
Regards, marcelo

---

From: masataka ohta <[email-masked]>
Date: Wed, 05 Nov 2003 01:10:01 +0900

Erik;

> But part of the point is that

Your point is that you said "today's Internet".

> there is a solution to make DNS more secure.

If you are talking about secure DNS, it was proposed even before
IPv6 and still is not deployed at all. And, there are reasons why
it is not deployed. In short, it is useless.

But, your argument is broken in other ways, too.

So, let's assume that we were talking about an imaginary IP network
where secure DNS were deployed and a pair of hosts were actually
using it for their forward and reverse domains.

> designed a multihoming solution which makes the network less secure again.

Then,  there is no reason to make some part of address of a host
a hash of host's public key, as the host can simply put its full
public key in DNS.

Then, the pair of hosts can and will exchange a session key with
which the communication, including parts for multihoming control,
is secured.

Still, you may argue that DoS of telling wrong locators should be
possible. But, you are wrong because MITM can issue as much DoS
as he wants regardless of security mechanism used. DoS by MITM,
agaist which cookies does not work, is fatally efficient, if
public key (that is, *EXPENSIVE*) cryptography is used.

Finally, as a set of locators of a host can be securely obtained
from secure DNS that there is no need to dynamically authenticate
the set, which is the fundamental difference between MIPv6 and M6.

That is, comparison to MIPv6 has been pointless, from the beginning
both on the today's Internet and the imaginary IP network.

						Masataka Ohta

---

From: masataka ohta <[email-masked]>
Date: Wed, 05 Nov 2003 01:20:28 +0900

Iljitsch;
 
> lans but not so much when tapping into existing monitoring capabilities.

An elementary fact on security is that DoS is so easy.

In this case, attackers block all the packets and relay almost all
the packets (except for a few selected packets) by themselves
copying everything include MAC addresses, which hides the attack
from monitoring, which is easy both on wireless and wired lans.

						Masataka Ohta

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Nov 2003 11:18:50 +0100 (CET)

> Why not go for the strong stuff immediately?

Because it is likely to be more expensive; for CBID schemes you'd need
a public key challenge response (signing by the peer, verification at your end)
and for DNS schemes like NOID you'd need at least a reverse lookup of the new
locator. If the new locator is from a revious unused ISP DNS cachaes might 
not help and if DNSsec is used this implies verifying at least 3 (or it is 6
with delegation signer?) since there are likely to be 3 new delegations to
find the previously unused ip6.arpa entry.

Hence I think it is useful to explore different weak schemes that
defers stronger verification until it is actually needed (for instance,
until the peer rehomes to different locators).

> lans but not so much when tapping into existing monitoring 

ARP/ND spoofing works well for any LAN I suspect.
Hadn't thought about using monitoring capabailities.
Do these require physical access, or can they be exploited remotely
due to poor access control in the switches?
If the attacker has physical access I don't know if there
is that much different between installing some inductive coupling on
a wire and installing a box on that wire.
Remember that we assume that security sensitive traffic secure its payload
(IPsec, TLS, etc) thus for that traffic the worst attack is a DoS. And an
attacker with physical access can accomplish a DoS by just cutting the wire.

Granted that there is a slight difference between cutting a wire
and selectively redirecting a single connection/host-pair communication
to a black hole; the former is much more likely to be detected and promptly
repaired.

    Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Nov 2003 12:44:19 +0100

> a public key challenge response (signing by the peer, verification at 
> your end) and for DNS schemes like NOID you'd need at least a reverse 
> lookup of the new locator.

Good point. Still, I don't think a clear text cookie isn't the best 
tradeoff here. Doing one or two MD5 hashes over a few dozen bytes is 
enough to get rid of attackers who can sniff, but not block traffic.

> If the new locator is from a revious unused ISP DNS cachaes might

I think we have to assume that DNSSEC won't be used.

> ARP/ND spoofing works well for any LAN I suspect.

But that's something that operators can fix if they care enough.

> due to poor access control in the switches?

Hard to say. But remember that ISPs and service providers higher up the 
stack in very many cases house their equipment in colo facilities where 
it's often not too hard for someone with legitimate access (ie, who 
rents some rack space there too) to mess around with someone else's 
equipment.

> a wire and installing a box on that wire.

I suppose not, but often the monitoring facilities are already in 
place. It's just a question of connecting a notebook to a monitoring 
port on a switch

> attacker with physical access can accomplish a DoS by just cutting the 

True, but that will be detected very quickly. Monitoring may remain 
undetected for a long time. Maybe in quantum physics looking at 
something is on the same scale as manipulating it, but in networks this 
isn't exactly the case.  :-)

My point is that trying to prevent man in the middle attacks doesn't 
make any sense for what we're trying to do here, but making our stuff 
such that someone with just sniffing and packet injection capability 
but who can't block the real traffic, is helpful.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Nov 2003 12:45:31 +0100 (CET)

> which the communication, including parts for multihoming control,

Yes, but this implies doing a full key exchange to form the session keys
for every pair of hosts that communicate.
That might be acceptable if those hosts want cryptographical strength
integrity and/or confidentiality, but feels like a lot of resources to
spend for the off-chance that during their communication one or both
of them will need to use different locators.

Your argument also assumes that all hosts will be in the DNS so that they
have a FQDN under which they can store their public key.
That isn't the case in IPv4 today and I haven't seen a strong driver for
this changing with IPv6. Thus I think it is important to enable multihoming
support when only one end of the communication has information in the DNS.
I haven't seen a proposal for how to do this using public keys stored
in the DNS. If you have one please explain it.

> public key (that is, *EXPENSIVE*) cryptography is used.

DoS from MiTM isn't the main DoS concern in the threats draft.
In fact it points out that such DoS attacks are possible in today's Internet.
One concern added by multihoming are around 3rd party DoS attacks,
where the redirection capability inherent in multihoming could potentially
be used to redirect large, sustained packet flows to a 3rd party.
See the draft for details.

The other DoS concern is about opportunities potentially created by
the multihoming mechanisms themselves; creating state or doing large amounts
of processing on an initial packet for instance.

> the set, which is the fundamental difference between MIPv6 and M6.

As the NOID draft discusses, if you want to use the DNS for verification,
one actually has to verify not only that the node/fdqn claims to use a locator,
but also that the locator points back at the fqdn. Otherwise, such a mechanism
could be used for 3rd party DoS.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Nov 2003 12:54:55 +0100 (CET)

> I think we have to assume that DNSSEC won't be used.

We (unfortunately) can't rely on it being deployed, but I think we need
to understand how both performance and security of a multihoming solution
changes when/where DNSsec gets deployed.

> enough to get rid of attackers who can sniff, but not block traffic.

Agreed.

> but who can't block the real traffic, is helpful.

I agree. We should put some discussion about this in the threats draft.

  Erik

---

From: masataka ohta <[email-masked]>
Date: Wed, 05 Nov 2003 21:59:15 +0900

Erik;

> integrity and/or confidentiality,

Urrr, what, are you saying, "acceptable"?

Apparently, you don't know that secure DNS is *EXPENSIVE*.

It take more computation to retrieve information from secure DNS, or
anything with hierarchical CAs, than to exchange a session
key for cryptographical strength integrity and/or confidentiality.

> but feels like a lot of resources to

Huh?

"exchange a session key" for cryptographical strength integrity
and/or confidentiality at the beginning of communication means
that a shared secret session key is exchanged helped by public
key cryptography.

After that, cryptographical computaions are secrete key ones and
are inexpensive.
 
> have a FQDN under which they can store their public key.

It is *YOUR* assumption.

> this changing with IPv6. Thus

Thus, even though you use public key cryptography with keys
authenticated by plain DNS, it is as secure as just believe
plain DNS.

> I think it is important to enable multihoming

See above.

It is easy to have a proposal using public keys.

However, that your proposal use public keys wrongly does not mean
your proposal has reasonable security.

> DoS from MiTM isn't the main DoS concern in the threats draft.

That is a problem of your draft.

> where the redirection capability inherent in multihoming

Wrong.

> could potentially

See previous mails on how it can be done with DNS without M6.

> of processing on an initial packet for instance.

An elementary fact on security is that DoS is so eacy.

That you happen to find a way of DoS attack for M6 does not mean
that similar attack is not possible for other protocols.

For example, secure DNS is subject to similar DoS attacks.

> but also that the locator points back at the fqdn.

And it is identical to reverse-then-forward look up of DNS for
verification widely used today with no M6 specific issues.

Unlike secure DNS, it is easy, useful, inexpensive, reliable
and proven to work.

							Masataka Ohta

PS

Learn elementary security.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Nov 2003 14:14:15 +0100 (CET)

masataka,

> It is *YOUR* assumption.

Nope - it was *YOU* who suggested to use DNSsec to store public keys.
An outline of a suggestion of mine is in draft-nordmark-multi6-sim-01.txt
and it doesn't add any use of DNS, secure or not.

   Erik

---

From: masataka ohta <[email-masked]>
Date: Wed, 05 Nov 2003 22:28:45 +0900

Erik;
 
> Nope - it was *YOU* who suggested to use DNSsec to store public keys.

It has nothing to do with *YOUR* assumption.

Read your mail on what was *YOUR* assumption, if you still insist
on your broken analysis and proposals.

							Masataka Ohta