Subject: security requirement for multi6

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Nov 2003 13:37:20 +0900

Here is the security requirement for multihoming with or without
DNS.

A point is that a set of locators of a host is stable, which
makes the requirement different from that for mobility.

That is, if a set of all the locators of a host is obtained
with certain security, it's OK. Peer of the host should accept
any locator in the set.

With DNS, a set of all the locators of a host can be simply
obtained as a RR set with reasonable security. Those insisting
on more complex security may use secure DNS (though secure DNS
is impractical to deploy).

Without DNS, a cookie and a set of all the locators of a
host should be exchanged with the peer as 3 way handshake
at the beginning of a communication. The cookie is to prevent
DoS with source address spoofing. The handshaking may be
performed as a special protocol or piggybacked on an existing
protocol. Especially, the handshaking may be piggybacked on
initial 3 way handshaking of TCP with sequence numbers as cookies.

Even with DNS, the set of locators may still be exchanged, in
which case, DNS reverse-forward lookup should be used
to verify the set.

As the entire process is light weighted (unless secure DNS is
used, which is one of a reason why secure DNS is impractical),
further attempt of DoS prevention is unreasonable only
to increases the chance of DoS.

						Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 11 Nov 2003 11:30:16 -0600

Hi Masataka,

> makes the requirement different from that for mobility.

This assumption does not take into account a renumbering event, but i agree
that this is common scenario.

> with certain security, it's OK. Peer of the host should accept

Agree

> is impractical to deploy).

agree

> initial 3 way handshaking of TCP with sequence numbers as cookies.

Could you expand a little bit how the mechanism would be? I mean how do you
deal with threats detailed in section 4.3.  Third Party Denial-of-Service
Attacks of draft-nordmark-multi6-threats-00.txt.
I think that you meant using a cookie, but i think that you will need to
exchange the cookie using all of the locators of the set, right?
I mean it is not enough to exchange cookie through a single locator, you
need to do it through all locators.

> which case, DNS reverse-forward lookup should be used

Yes, that is noid, i think

> to increases the chance of DoS.

The remaining attack AFAICS, is how do you prevent connection hijack from an
attacker that intercept the initial three way handshake and then moves away.
Note that currenlty an attacker can only hijack a connection as long as he
stays in the path intercepting packets, so if you allow this type of attacks
you are introducing a new vulnerability.

BTW: Erik, in a quick scan i haven't seen this attack in the threats draft,
but i guess it should be there, right?

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Nov 2003 05:50:01 +0900

Hi, marcelo;

> exchange the cookie using all of the locators of the set, right?

No.

> need to do it through all locators.

Only thing we can do without DNS is to assure that the identity stays
same. In addition, it is silently assumed that a host initiating a
connection knows a locator of its peer but not all the set of locators
(otherwise, just use the set). It is also assumed that peer initially
knows nothing about the initiating host.

So, a cookie is used by the initiating host to securely get a set
of locators of its peer using the initial locator of the peer.

Another cookie is used by the peer to securely get a set of
locators of the initiating host using the locator initially
used by the initiating host. 

> stays in the path intercepting packets,

Such a attack will be meaningful as a faked peer (server) of a
host (client) initiating a connection.

However, prevention of connection hijack against a temporary MITM
is not a requirement, at all.

> so if you allow this type of attacks

No, it is not new.

As I wrote to Erik, with DNS, if MITM intercepts initial DNS exchange
to redirect a connection to his host elsewhere, the connection is
hijacked by a host not currently on the path.

That is, prevention of connection hijack against a temporary MITM
is impossible without expensive security mechanism and is not a
requirement here.

						Masataka Ohta

PS

Considering that it is not realistic to type raw IPv6 addresses,
it may be reasonable to assume that addresses are obtained from
DNS or some electric media, in either of which case, the entire
set of locators can be stored that there is nothing to worry
about.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 11 Nov 2003 17:44:57 -0600

> used by the initiating host.

So if you don't use RR to verify address owbership for each of the locators,
could you explain me how do you deal with threats detailed in section 4.3.
Third Party Denial-of-Service Attacks of
draft-nordmark-multi6-threats-00.txt?

> is not a requirement, at all.

I think it is.
If it weren't we could just use MIPv6 and end of the story

[...]

> set of locators can be stored that there is nothing to worry

Let me see if i understand what you are saying: (please correct me if i am
wrong, (i know you will ;-)
- you assume that all communications will use DNS to obtain addresses
- DNS is susceptible to temporary MITM attacks
- so, the proposed solution should not protect against temporary MITM
attacks since they are already there.

is this right?

Well i don't know if the first one is a reasonable assumption.
This would imply that we would be actually make the internet weaker, since
you won't be protected from temporary MITM attack eevn if you don't use DNS.

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Nov 2003 09:26:10 +0900

marcelo;

> you won't be protected from temporary MITM attack eevn if you don't use DNS.

My point is that temporary MITM attacks are no new and common.

If you don't like DNS, consider temporary MITM in FTP control
channel to redirect data connection.

Or, consider temporary MITM compromise a host in the middle, which
works as a MITM to do anything.

Prevention of connection hijack against a temporary MITM
is not a requirement, at all.

> If it weren't we could just use MIPv6 and end of the story

At Vienna, I gave three reasons on why MIPv6 is hopeless
and can not be used for M6.

> that this is common scenario.

Difference of security model requirement makes security mechanism
different.

The only interaction I can see so far between mobility and
multihoming is that they should use same packet format, which
should address the MTU problem of mobility forwarding.

						Masataka Ohta

PS

Renumbering can be addressed by making DNS query again after
TTL expiration or by sending set of locators in TCP option again,
though I'm not sure it worthes the effort.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Nov 2003 16:58:07 +0900

marcelo;

> Yes, that is noid, i think

Wrong.

DNS reverse-foward lookup of IPv4 is PTR and A lookup.

DNS revers-forward lookup of IPv6 is PTR and A* lookup.

No cryptographic technology should be involved only to
extend valunerability by DoS.

						Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 12 Nov 2003 08:48:25 -0600

> is not a requirement, at all.

I would like other opinions about this particular issue... does anyone care
to comment?

> and can not be used for M6.

Sorry i remeber the following ones:
1) timing in mip is not compatible with multi-homing
My answer to this is that the idea is not to use mip as is, but use the
packet format and the CN route optimization capabilities. So mip timing is
not really being used, so i think this should not be an issue.

the next one would be security as you mention, right?

> Difference of security model requirement makes security mechanism

Well if you don't care about tmeporary MITM attacks, mip provides all the
security that you need, so i don't see a problem here

> should address the MTU problem of mobility forwarding.

Well as i mention above, not only packet format but CN route optimization
capabilities, which IMHO is the main benefit of using mip, (i.e. you don't
need to deploy new mechanisms in external hosts)
I agree that PMTU is an issue, but i would say that we could do some
optimizations to improve that, and that capability of re-using CN RO
capabilities outweights this particular drawback IMHO

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 05:54:54 +0900

marcelo;

> 1) timing in mip is not compatible with multi-homing

No, it is not. It, instead, is a reason on why MIPv6 mechanism can
not be used for M6. But, let's continue.

> not really being used, so i think this should not be an issue.

With MIPv6, CN is expected to use a new locator. With M6, a host is free
to choose any locator, which, in most cases, the host has from the
beginning.

> the next one would be security as you mention, right?

Yup.

> security that you need, so i don't see a problem here

I don't care about MITM between CN and HA. MITM between CN and MN,
local environment of which is foreign, is a different matter.
 
> need to deploy new mechanisms in external hosts)

No new mechanism even if timing and security are completely different?

> I agree that PMTU is an issue

That is a reason on why MIPv6 is hopeless, though it has less
relevence to this WG. Other reasons are DAD and unnecessary
complexities.

					Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Nov 2003 16:09:00 -0600

> is not a requirement, at all.

The attack vector here would that an attacker opens a TCP session to a 
third party relay host and requests a large amount of data. When the 
data starts flowing, the attacker sends a false rehoming message that 
makes the relay host redirect the flow to the target. Then the attacker 
sends spoofed TCP ACKs that make the relay host keep sending data at 
high speed.

The victim will start sending back TCP RSTs to get the relay host to 
stop sending data, but even if the relay host immediately stops 
sending, the attacker was able to generate abusive traffic for a round 
trip time. We're probably not talking megabits worth of data, but it 
would be enough to choke a limited bandwidth host.

Also, the fake ACKs will probably make the RSTs fall outside the 
allowed window so they're ignored, so the attack doesn't stop 
regardless of RSTs.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 08:25:53 +0900

Iljitsch;

I should state an elementary fact again.

DoS is so easy.

That is, that you happen to find a way of DoS does not mean other
forms of DoS is not possible.

> sends spoofed TCP ACKs that make the relay host keep sending data at 

The attacker as a temporary MITM opens a TCP session to a third party
relay host with a spoofed source address of a target and requests a
large amount of data. When the data starts flowing, the attacker
moves away that makes the relay host direct the flow to the target.
Then the attacker, now at a distance, sends spoofed TCP ACKs that
make the relay host keep sending data at high speed.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Nov 2003 17:33:15 -0600

> DoS is so easy.

Unfortunately that is true.

> forms of DoS is not possible.

Still, I think this new kind of denial of service is bad enough that we 
shouldn't allow this to happen, even though other denial of service 
attacks are also possible today. Hopefully we'll be able to do 
something about that in the future.

Iljitsch

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 08:45:41 +0900

Iljitsch;

> attacks are also possible today.

Read my previous mail, again.

The damages on the target by two attack forms are identical.

> Hopefully we'll be able to do something 
> about that in the future.

DoS is so easy.

						Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 05:07:05 +0100

On torsdag, nov 13, 2003, at 00:33 Europe/Stockholm, Iljitsch van 
Beijnum wrote:

> Still, I think this new kind of denial of service is bad enough that 
> we shouldn't allow this to happen, even though other denial of service 

Just because there are DoS possibilities that we do not yet know about, 
does not mean that we should not fix the ones that we do know about, 
and also know how to fix.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 13:27:41 +0900

Kurt Erik Lindqvist wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
Kurt;

> and also know how to fix.

What is your point?

The current situation is that there are DoS possibilities that we
(I, at least) already know about.

						Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 15:20:48 +0100

On torsdag, nov 13, 2003, at 05:27 Europe/Stockholm, Masataka Ohta 
wrote:

>>> we shouldn't allow this to happen, even though other denial of 
>>> service attacks are also possible today. Hopefully we'll be able to 
>>> do something about that in the future.
>> Just because there are DoS possibilities that we do not yet know 
>> about, does not mean that we should not fix the ones that we do know 
>> about, and also know how to fix.
>
> What is your point?
>

In the id/loc separation case? That are not in Eriks draft? Then this 
is the time to list them. If you know how to work around them, even 
better.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 00:20:06 +0900

Kurt;

> In the id/loc separation case?

No.

> That are not in Eriks draft?

No.

> Then

Then?

						Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 16:27:41 +0100

>>>>> Still, I think this new kind of denial of service is bad enough 
>>>>> that we shouldn't allow this to happen, even though other denial 
>>>>> of service attacks are also possible today. Hopefully we'll be 
>>>>> able to do something about that in the future.
>>>>
>>>> about, does not mean that we should not fix the ones that we do 
>>>> know about, and also know how to fix.
>>>
>>> What is your point?
>>>

Then please post to the list.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 01:33:48 +0900

Kurt;

> Then please post to the list.

It was posted to the list on this thread on the same day you post
your opinion, which quoted part of my post.

						Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 21:43:33 +0100

This is not really leading us anywhere...

> your opinion, which quoted part of my post.

Uhm, I replied to a mail from Iljitsch, that had replied to your 

 >forms of DoS is not possible.

I then went on to say that although DOS attacks are a fact of life, 
that does not mean that when designing future solutions, and we 
discover new possible DOS attacks, and we at the same time knows how to 
fix them - that we should ignore that.

You then said in a reply to my message that

 >(I, at least) already know about.

And my question was :

If you know of DOS possibilities against id/loc split models such as 
NOID or SIM or others, that are not described in 
draft-nordmark-multi6-threats-00.txt, then please mail a description of 
those to the multi6 list. If you also have suggestions or know how to 
prevent against those attacks, include that.

If you can't describe any new threats I think we can kill this thread.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 06:07:25 +0900

Kurt;

> If you can't describe any new threats I think we can kill this thread.

No, we can't.

This thread is whether threats claimed to be new are really new
or not.

You miss the point.

I showed that some are not new.

Iljitsch showed a new case, which was expected to be a new
threat.

I modified the case using current TCP to show that the threat
is not new.

Note that our security requirement is not more security but
not-less security.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Nov 2003 23:21:24 +0100

Masataka,

Whether a threat is new or old really doesn't matter.

Our objective is to have a complete threat analysis that we can use
to evaluate the security of proposed solutions.

As Kurt says, if you have additional threats that should be added
to Erik's threat analysis draft, please send text.

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 07:45:19 +0900

Brian;

> to evaluate the security of proposed solutions.

If you use "complete" that way, the threat list MUST be proposal
specific.

For example, if I propose a protocol which clones TCP and name it
MOCP, there will be a new threat of MOCP SYN attack, in addition
to TCP SYN attack.

This is not a productive way to do things, though.

Erik is trying to be more productive stating in the abstract that:

   The intent is to look at how IPv6 multihoming solutions might make
   the Internet less secure than the current Internet, without studying
   any proposed solution but instead looking at threats that are
   inherent in the problem itself.

Just as SYN attack is inherent to not TCP but having state on the
initial paket of a 3-way handshake, redirection by MITM is inherent
to not M6 problem but MITM.

							Masataka Ohta