Subject: Re: evaluation of draft-van-beijnum-multi6-odt-00.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 Jan 2004 20:45:41 +0100

On 9-jan-04, at 15:40, marcelo bagnulo wrote:

> This with the address verification that you also use,  would be 
> similar to
> the return routability procedure of MIPv6, right?

I'm not sure.

>> If there is no encryption of the actual data over an insecure link,
>> then I don't see how the data is sufficiently sensitive that the
>> redirection attack that is possible with clear-text keys is a show
>> stopper.

> Well, if you consider mipv6 route optimization security design, 
> current IP
> provides an intermediate level of security, where traffic is not 
> encrypted
> but communications cannot be so easily redirected. I think this is the 
> goal
> for multihoming security: not to do worse than current ip security. I 
> am
> afraid that the security of this draft is worse than current ip 
> security.

In theory, you're right. But in practice, things are different. I see 
three classes of traffic over insecure links:

1. Sensitive data that is encrypted using IPsec/SSL/SSH or what have you
2. Sensitive data that isn't encrypted
3. Non-sensitive data

1. already solves the PKI problem in some way or another. If we can 
find a way to tap in to that solution and use it to create session keys 
we have bullet proof redirection protection. So I think this situation 
is addressed.

2. is insane; trying to salvage anything here is useless.

So that leaves 3. An attacker can redirect traffic to another address 
for which he can see the traffic (so not to arbitrary addresses) which 
is a bad thing, but for the "real" client the effect is pretty much the 
same as when the attacker had sent a TCP RST: the real client doesn't 
see any data anymore. The fact that the dat is now delivered to the 
attacker isn't of great importance due to the non-sensitive nature of 
the data.

> Put it in another way: the security of this solution would be similar 
> than
> using MIPv6 with inifinity BCE lifetime. MIP has an additional benefit 
> that
> it is already standarized and code is available, so why deploy a 
> solution
> tha has similar limitations?

But MIPv6 also has some huge disadvantages, for instance the 24 byte 
per packet overhead. We've already concluded that using MIPv6 for 
multihoming without any changes won't fly. If your point is that using 
MIP interactions is easier and no less effective and efficient than 
designing something new then that's certainly something we can explore, 
as long as we have a very clear picture of where we want to go. Just 
diving into MIPv6 with the idea that it can solve multihoming with some 
tweaks would be a very bad idea. The two facts that MIPv6 still isn't 
an RFC and that the draft is 172 pages speak for themselves.

Anyone any idea whether MIPv6 (with route optimization) can be 
implemented in a middlebox?

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 12 Jan 2004 17:13:32 +0100

> attacker isn't of great importance due to the non-sensitive nature of

Well, actually the attacker could do the oposite.
The attacker could generate some malicious state in the victims machine so
that when the victim wants to initiate a communication will send the traffic
to the attacker. So now the attacker can impersonate the server and send
back modified answers for instance.

For example, you have a host A that is running ODP. The host is not
communicationg with anyone.

Supose now that there is a very well known server, that A usually connects
to, for instance a newspaper web page, that have address B.

Supose that there is an attacker that has an address C

During an inactivity period, the Attacker initates the communication with A
and pretends to have address B (receiving packets  containing keys sent from
A to B, the attacker can achieve that if he is in the same lan than A). Now
it generates some ODT state in A mapping the address B (of the server) to
its own address C.

Now the attacker leaves the place and goes to its usual address C, where he
waits

Considering that the state mapping B to C is indefinite, later on when the
user of arrives and tries to contact B it will be actually  sending packets
to C.

Would this attack be possible with ODP?
If so, don't you think this is security risk?

> an RFC and that the draft is 172 pages speak for themselves.

My personal opinion about MIPv6 is that it is unsuitable for multihoming
support becuase the required modifications would introduce inacceptable
security risks as the one described above.
However, i folks think that those security risks are acceptable, i think it
would be interesting to consider it, because the available code and
implementations. But for now, i would focus the discussion on which is the
desired level of security. IMHO a multihoming solution shouldn't introduce
new security issues to the internet that is it should be as secure as fixed
single homed ip

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 Jan 2004 18:57:21 +0100

> back modified answers for instance.

Ok. It took me a while to realize we're not talking about attacks that 
are possible because of insecure links anymore.

> Supose that there is an attacker that has an address C

Ok.

> and pretends to have address B

Hm, but in this case A must accept an incoming connection of some type. 
Also, the attacker must know A's address in the first place. This isn't 
as trivial in IPv6 as it is in IPv4.

> (receiving packets  containing keys sent from

Note that the mapping state is passive in ODT: the attacker also has to 
get the victim to failover from the regular address to the fake one.

> Considering that the state mapping B to C is indefinite,

By "indefinite" I don't mean "lasts forever", but rather that there 
isn't a fixed timeout. Obviously implementations will want to remove 
this state at some point, with a logical moment being shortly after the 
last session that matched the mapping entry has stopped. (I should 
probably explain this in the draft.)

However, this doesn't effect the possibility of an attack much as an 
attacker can simply keep the state fresh by sending packets from time 
to time.

[Aside: a similar attack is possible if the atacker is present on the 
victim's subnet: the attacker can advertise the address block of the 
server it wants to impersonate as on-link and then simply answer 
neighbor solicitations. Not even any sniffing capability necessary in 
this case.]

> later on when the user of arrives and tries to contact B it will be 
> actually  sending packets to C.

> Would this attack be possible with ODP?

It depends on whether the attacker can make the victim failover to the 
negotiated backup addresses. This could be remedied by sending a probe 
to the "real" address after a while and/or when a new session is 
initiated. The real host will then send back an error since the state 
referenced in the probe doesn't match its own state.

If the real address isn't reachable, then the attacking host still gets 
to play dice, but that's possible today too (in many cases): it can 
fake replies from the real host without having to worry about the real 
host getting in the way.

Or we could separate the state for outgoing sessions from the state for 
incoming sessions. But this leads to interesting conundrums when host X 
contacts Y and then Y sets up a new session back to X.

> If so, don't you think this is security risk?

Sure.

> implementations.

It's unfortunate that we haven't been able to get a dialog going with 
any mobility people because there is substantial overlap here, which 
can be very good (reuse of (semi-)existing stuff) or very bad 
(multihoming and mobility solutions getting in each other's way).

> But for now, i would focus the discussion on which is the

While it would be insane to defend the opposite, I think this is a trap 
we should avoid falling into. The safety features that are appropriate 
for an airplane aren't automatically justified in a car, or the other 
way around. Let's focus on the level of protection that is appropriate 
for what we're trying to build here, now and in the forseeable future, 
regardless of whether a certain class of attack is possible with single 
homed IP.

Iljitsch

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 12 Jan 2004 19:24:15 +0100

> Hm, but in this case A must accept an incoming connection of some type.

How does the ODT mechanism knows about existent connections? I mean, ODT is
a IP layer mechanism right, so it is not aware if there is a communication
or if packets are just echo requests. To be more precise, wouldn't a ping do
the trick?

> as trivial in IPv6 as it is in IPv4.

ok.

> get the victim to failover from the regular address to the fake one.

Perhaps i am not understanding this correctly. what happens if the attacker
continues to send pings, from time to time with the source address set to C?

The general question is how does the ODT end knows which is the actual
address that it has to use?

> attacker can simply keep the state fresh by sending packets from time

Yes.

> neighbor solicitations. Not even any sniffing capability necessary in

yes (but this is a problem for the send guys)
BEsides, the problem here is that the attacker may leave the subnet and
continue with the attack. This is aproblem because it is probably easier to
access to a physical media for a short time of period than staying there for
a while.

> referenced in the probe doesn't match its own state.

Yes, i porposed the same solution for mip :-)

But Pekka N. didn't like it (as far as i remember), becuase the security of
the host is based on the fact that the error message is not filtered.
Considering the wide adoption of ICMP filtering this may be a a problem.
Then i proposed that the state is renewed if when the client send a state
refresh request, the client obtains an ICMP unreachable message as reply ,
meaning that the path is down (so there is no attack going on). The problem
here is that the fault tolerance of your solution depends on ICMP messages,
which i didn't really liked. But if you accept that the security or the
fault tolerance of the solution depends on periodic exchange of signaling
messages, this could work.

Also keep in mind that there are other attacks that may also be interesting
to consider like stealing an unused IP address from a certain subnet. (i
don't know if this is important)

> regardless of whether a certain class of attack is possible with single

Just to clarify this, I am not claiming that we shouldn't provide additional
security if we can, but that we shouldn't provide less.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Jan 2004 13:48:30 +0100

> or if packets are just echo requests. To be more precise, wouldn't a 

Depends on the implementation, I guess. I think in a host 
implementation, the ODT state would be coupled with the transport state 
because there is overlap here (when to failover and so on). It would be 
possible to implement ODT without looking below IP at all, but that 
could have negative side effects. For instance, I believe it makes 
sense to leave ICMP alone and not tunnel it.

> continues to send pings, from time to time with the source address set 

In other proposals the idea was to use the source address in incoming 
packets as a strong hint for the destination address in outgoing 
packets. Since ODT requires that all addresses be verified before use, 
such a hint isn't required so the attacker must come out as the best 
choice in the verification procedure. But during this verification 
procedure, the fact that the host sitting at the original address sends 
back errors should make this attack non-trivial.

> address that it has to use?

Send packets to all destination addresses (possibly from all source 
addresses, creating a "ping bomb" of significant size) and see what 
comes back and how soon.

> Considering the wide adoption of ICMP filtering this may be a a 

Ok. I had a very nice rebuttal here, namely that all ODT interactions 
(including errors) use the ODT extension header so this shouldn't be an 
issue. (Problems are of course possible when either all packets 
containing the ODT header or packets containing the ODT header but not 
any ULP are filtered.)

Unfortunately, this doesn't solve the problem, since the host that is 
impersonated may not implement ODT so error messsages aren't 
forthcoming.

I think this means that the only way to be secure is for all new 
sessions to use the "real" address for at least a few packets. This of 
course makes initiating new sessions after a failure problematic, 
especially in cases where the full set of remote addresses is no longer 
available, such as after a referral.

> security if we can, but that we shouldn't provide less.

Redirection attacks at the IP level aren't possible in current IP. Any 
kind of rehoming allows for the possibility of redirection attacks. If 
we mandate that mobility/multihoming must not allow any new attacks, 
this means the countermeasures against these attacks must be bullet 
proof. I think this is raising the bar too high: if people are stupid 
enough to use insecure links without crypto AND enable protocols that 
break current expectations, they shouldn't be surprised if they see new 
attacks. Obviously such attacks shouldn't be possible when using 
reasonably secure links or IPsec.

In other words: we accept that we have to use plastic knives when 
eating our in-flight meals, but just because metal knives are 
unacceptable in airplanes, doesn't mean they shouldn't be available 
elsewhere.