Subject: Re: The state of IPv6 multihoming development

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Oct 2002 18:28:56 +0100 (CET)

>> The basic idea is simple: the IP addresses the transport layer uses
>> become the identifiers of a session. In transit, these identifiers
>> may/must be replaced by locators, but they identifiers are restored
>> before the packet reaches the transport layer at the other end.

>Why does this so much sound like Mobile IPv6 to me?

There are many similarities. That's why it would be good to talk with the mobility people.

>I am probably biased here, but IMHO once you start to really
>ponder the security consequences, you pretty much come to the
>idea that maybe, after all, it might be better to introduce
>a new cryptographic name space instead of once more overloading
>the IP name space with some IP addresses that are end-point
>identifiers (and locators) and some that are (just) locators.
>The resulting aliasing problems are nasty, security wise.

What would this cryptographic name space look like? Remember that we have to maintain backward compatibility with a lot of stuff.

>The NSRG report still makes a good reading.

Do you have a pointer?

>If you are going to require changes to the end-host and the
>introduction of a mudem box anyway, the HIP design might
>be a good place to start with.  The more recent variants of
>HIP already support end-host multi-homing, and they contain
>a "mudem" which is able to perform prefix translation, function
>as a mobility home agent, and as a mobility anchor point.

That sounds good. Another pointer, please?

However, mobility as I understand it assumes things, especially the home agent, are reachable. In multihoming, this definately isn't an assumption we can make.

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 27 Oct 2002 20:39:39 +0200

> What would this cryptographic name space look like?

The basic idea is simple:  Introduce a new name space for
end-points.  Architecturally, the name space would be located
between the IP addresses and the TCP/UDP/SCTP ports.  The
scope of the transport layer ports would be changed from
IP addresses to end-point names.

The end-points names would then be bound to IP addresses.
For mobility, this binding would be dynamic.  For end-host
multi-homing, this binding would be one-to-many.  For
virtual hosts, the binding would be many-to-one.

If the new name space was cryptographic, the primary end-point
identifiers would be public keys (or equivalents).  However,
since public keys are so large, it would be more convenient to
use digests of the keys in most data structures.

Thus, instead of trying to make a TCP connection to e.g.
your-ip:25 I would create a TCP connection to hash(your-key):25.

Security would be trivial, since you would know the public
key of your peer.  The details are in the HIP drafts.

> Remember that we have to maintain backward compatibility
> with a lot of stuff.

There are lots of details to be worked out, but the basic
idea in HIP is to represent the end-point ID as a 127 bit
hash of the public key.  This hash would then be encoded
so that it looks like an IPv6 address with the first two
bits being either 01 or 10.  Both of these code points
are currently unassigned.

The host stack would then, underneath TCP or UDP, look
at these two bits.  If the bits indicate a normal IPv6
address, nothing would happen and the host would work
just like today.  On the other hand, if the bits indicate
HIP, the host would select an IP address from the addresses
currently available for the given host, and replace the
key hash with the address.  The recipient would then make
the reverse, thereby preserving transport layer checksums.

This is somewhat hackish, I agree, but it would preserve
backward compatibility.  A new API would be a better
alternative, but would break backward compatibility.

In the wire, IP addresses are always used as today.
Thus, no changes are required to routing.

>> The NSRG report still makes a good reading.

http://www.ietf.org/internet-drafts/draft-irtf-nsrg-report-06.txt

> That sounds good. Another pointer, please?

The basic design is perhaps best explained in our forthcoming
NDSS paper.  I'm happy to send preprints upon request; I'm afraid
I can't put it on my web site yet.  (NDSS will be held in
February in San Diego, see http://www.isoc.org)

Other sources of information are the following:

http://homebase.htt-consult.com/HIP.html
http://hip4inter.net

> However, mobility as I understand it assumes things,
> especially the home agent, are reachable. In multihoming,
>  this definately isn't an assumption we can make.

According to my understanding, mobility requires reachability
for the following two reasons:
  a) Initial reachability.  You need some initial IP address
     to reach the host in the first place.  If multi-homing
     is supported in addition to mobility, the set of initial
     addresses can contain more than one address.
  b) Resolving simultaneous movements (double jump).  If both
     ends of a connection are mobile and move at the same time,
     they must somehow be able to reach each other after the
     movements.
Both of these, in fact, are easier to solve with end-host
multi-homing.

(It is a completely different thing that Mobile IPv6 is
designed as it is designed, with home agents and lots of
complexity.  It carries much history from Mobile IPv4 design...)

--Pekka Nikander

---

From: Peter Tattam <[email-masked]>
Date: Mon, 28 Oct 2002 07:50:57 +1100 (EST)

> What would this cryptographic name space look like? Remember that we have to maintain backward compatibility with a lot of stuff.

I strongly believe that any solution which depends on crypto won't fly, mainly
on the grounds that it is my understanding that good crypto relies on PKI and
also requires significant cpu resources that may not be applicable to monster
servers or miniscule devices. Generally the nature of mobility is that crypto
is mandatory because of the dangerous environment that it operates within.  The
only security requirement that a MH solution needs to conform to would be
equivalent to what we have in IPv4.  I believe this requirement is fully met by
a syn/ack exchange of addresses on the primary addresses between the hosts.
While this does not preclude a man in the middle attack steal the connection,
neither does the BGP model preclude a man in the middle attack also in such a
scenario.  I believe it could withstand a man on the side attack though.

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Oct 2002 23:53:28 +0100 (CET)

> key of your peer.  The details are in the HIP drafts.

Hm, what problem exactly does this solve that isn't solved by (for
instance) SSL?

Also, how does the hash to IP address mapping work in the absence of a
hierarchy?

> are currently unassigned.

I'm not sure if I've said so clearly on this list, but over the last
month or so I've come to realize that it's probably too soon to create a
definitive multihoming solution. So it would be good to come up with
meta-solutions that enable different solutions to work together, or
provide a growth path from one solution to the other. I share Peter's
scepticism towards crypto-based solutions, so I don't think we should
crate a solution that only works with crypto. But a first step solution
could very well have the right hooks to enable the use of cryptography
where desired. More specifically: if we can make some sort of
identifier/locator seperation solution where the identifiers are simply
routable addresses, most of the ground work to move to crypto hash
identifiers is in place, and the only thing necessary is a good locator
discovery mechanism.

> NDSS paper.  I'm happy to send preprints upon request;

Condiser it requested.

>      addresses can contain more than one address.

I'm afraid we have to push this into the application (trying multiple
addresses) as long as we don't have a good locator discovery service.

>      they must somehow be able to reach each other after the

But what if the home agent becomes unreachable?

Requiring the home agent to be reachable just moves the problem to the
place where the home agent is located. This may have some benefits as
the number of home agent locations can be smaller than the number of
multihomed hosts, but it still requires some other means of multihoming
to protect the home agent.

I read about a homeless mobility proposal somewhere a while ago, but I
haven't been able to find it again afterwards...

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Oct 2002 23:55:36 +0100 (CET)

On Mon, 28 Oct 2002, Peter Tattam wrote:

> The

This is a good point.

Sometimes the security people get carried away...

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Oct 2002 07:25:57 +0200

[I changed the subject line to reflect the contents of discussion.]

> scenario.  I believe it could withstand a man on the side attack though.

Well, I fully agree that there are problems with crypto.  However,
part of your worry is ungrounded, IMHO.  The kind of crypto we are
now taking about does *not* depend on PKI.  It may even be possible
to base it on symmetric crypto instead of public key crypto, thus
alleviating some of the performance worries.  OTOH, using public
key crypto is so much easier that AFAIK nobody has yet seriously
considered the symmetric alternatives.

Why do I believe that crypto is probably needed?  Well, *if* the
goal of end-host multi-homing is to keep transport sessions
flowing, it becomes equivalent with mobility, at least from
security point of view.

Let's consider the following scenario:

   1. Alice contacts Bob from 10.0.0.1
   2. Alice tells Bob that she is also reachable at 10.1.1.2
   3. Alice stops answering to 10.0.0.1
   4. Bob assumes that the path to 10.0.0.1 has failed and
      starts using 10.1.1.2 instead

This is equivalent, from the security point of view, to

   1. Alice contacts Bob from 10.0.0.1
   2. Alice tells Bob that she has moved to 10.1.1.2
   3. Bob starts using 10.1.1.2 instead of 10.0.0.1

Ergo, if someone can launch an attack against a mobility
mechanism, she is also able to launch a similar attack against
an equivalent end-host multi-homing mechanism.  The level of
protection needed is basically similar, and the same basic
security solutions are applicable.

Well, the multi-homing case (as well as the so called smooth
handover case) is slightly easier to solve, since we can assume
that the multi-homed host is (at least briefly) reachable
through both addresses.  However, the difference is quite small
in practise.  The resulting security protocols are fairly similar
in both end-host mobility and end-host multihoming.  The details
differ more based on the exact nature of the mobility resp.
multi-homing solution, not whether it is a question of end-host
mobility or end-host multi-homing.

If we forget about keeping the transport sessions flowing, or
rely completely on mechanisms on the routing infrastructure,
the story is different, of course.  I am only referring to the
case where multi-homing is visible to the end-hosts.

Anyway, that's my current humble understanding, after having
played with the ideas for some 2-3 years now.  Maybe I am
completely flawed in my analysis, and most probably I haven't
layed out the underlying assumptions well enough in this message.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Oct 2002 08:00:25 +0200

[CC:in to hipsec from multi6]

> Hm, what problem exactly does this solve that isn't solved by (for

That is a subtle question, thanks for asking that.  That is also
exactly the question which has prevented HIP from becoming a WG
a long time ago.  I think that the multi6 list is perhaps not the
right place to discuss that question, the answer is too long.
If you are interested, let's move this point off-line, to
the HIP mailing list, or some other better suited mailing list.
And please read the NSRG report before we start to dive into this.

> Also, how does the hash to IP address mapping work in the absence of a

How does a name to IP address mapping work today?  Using DNS,
for example.  Or some other name resolution service.

There are pure hash based name resolution services, dubbed
"distributed hash tables" (DHT).  I'm not an expert there,
but I can dig up a couple of references if you are interested.

> provide a growth path from one solution to the other.

I agree.  Basically I wanted to point of the following:

  1. Once we start to discuss solutions that require changes to the
     end host (and perhaps these "mudem"s), there is also the option
     of introducing a new name space, cryptographic or not.

  2. End-host based multi-homing solutions *seem* to have the
     same security problems as (some) end-host mobility solutions.

> ...  More specifically: if we can make some sort of

If you create a solution where identifiers are simply
routable addresses, you are, from my point of view, basically
re-inventing Mobile IPv6.  And since there are so many
problems with Mobile IPv6, I am quite sceptical about such
a design.  Well, Mobile IPv6 works (probably) and the security
problems have been solved, but the result is, well, large
and complex.  But perhaps I'm short sighted here, and you
have something else in your mind.

> But what if the home agent becomes unreachable?

If the end-host is multi-homed, either in reality or conceptually,
there is no problem.  You can consider the home agent as one
multi-homed interface.  You can have multiple home agents if you
need to.  Or none, temporarily.  See the paper.

> haven't been able to find it again afterwards...

That was our draft.  Since then we moved our work to HIP,
mainly due to security constraints.  Maybe it would be the
time to have a look at cheaper-than-PK crypto solutions for
HIP.

--Pekka Nikander

---

From: Peter Tattam <[email-masked]>
Date: Mon, 28 Oct 2002 17:51:58 +1100 (EST)

>       starts using 10.1.1.2 instead

This should be...

1. Alice at primary address 10.0.0.1 contacts Bob at primary
address 10.10.0.1 and at the same time says
that she is reachable also at 10.1.1.2

2. Bob responds by saying, ok you tell me that you are at 10.0.0.1 and
10.1.1.2, and I'm at 10.10.0.1 and also at 10.12.0.1

3. Alice says ok, that agrees with what I sent you and I'm responding back
to you to say you're telling me you're at 10.10.0.1 and at 10.12.0.1.  I'm
still awaiting final confirmation.

4. Bob sends his final response saying yes, your response agrees with what
I sent you.  We both trust each other to send data on these addresses, but we
agree now that no other addresses can be used from this point on.

    time passes...

5. Alice stops answering to 10.0.0.1
6. Bob knows already that alice might be listening at 10.1.1.2 and tries
that address also.

(Steps 1 to 4 *MUST* be done on the primary addresses.  If that fails a new
primary address should be chosen and the whole process starts again.)

Been through this issue many times before.  Both sides exchange the set of
reachable addresses with a three way syn/ack handshake before any addresses are
allowed to be switched. The strength of this is governed by the size of the
ISS/IRS in TCP, which in recent times has been encouraged to have much more
cryptographically strong properties. It is plausible to have a much larger
nonce for this purpose included in the IPv6 option that is cryptographically
strong enough to prevent any kind of guessing that is common in syn/ack
hijacking.  If the session doesn't reach an established state, nothing goes
ahead.  For the really paranoid, the only solution is signing the packets, but
that implies there are either shared secrets or some kind of public key crypto. 

The difference between a MH solution and a mobility solution is that in the MH
solution, both ends negotiate in advance all possible addresses because each
end knows in advance all the possible addresses which can be used, and only the
primary address pair is used for negotation. In mobility, the alternative
addresses are generally not known in advance and hence crypto is required to
establish trust that the change of address is authorized.

Don't also forget that DNS provides MH information which can also be used
to add some extra checking at least for destination addresses.  It is
unrealistic for the listening host to consult DNS for every incoming
connection, although many sites do this as a matter of good practice anyway.

> security solutions are applicable.

They are not the same for reasons mentioned above. The attack can be launched
only during the exchange, but no other time.  With mobility, the attack could
be launched any time.

I challenge the security people to work out an attack strategy which is not a
man in the middle one, and then I will be perfectly happy to concede defeat.

> layed out the underlying assumptions well enough in this message.

No problem.  I would really like a definitive answer from the security
heavyweights to finally put the matter to rest if possible.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Oct 2002 09:26:00 +0300

> 6. Bob knows already that alice might be listening at 10.1.1.2 and tries

I'm quite happy with your extended description instead of my
more compact one, no problem with that.

However, there is a potential flooding DoS problem with the scenario:

   1. Alice the attacker contacts 20000 hosts, tells them that her
      primary address is 10.0.0.1 and she is also reachable at 10.1.1.2
      She may make the contacts one at time if she has herself only
      limited network capability, leaving the connections dormant.
      She also performs the three way handshake as outlined above.

   2. Alice orders a large data stream from each of the 20000 hosts,
      perhaps once at a time, and *immediately* stops answering
      at 10.0.0.1 for that particular host.  Preferably she uses
      a service where the data stream will start with a delay, e.g.
      streaming video which will start only somewhat later.

   3. The 20000 hosts notice, one by one, that Alice is not answering
      any more at 10.0.0.1, and divert the large data stream to 10.1.1.2.
      To make the situation worse, Alice may try to send faked canned
      acknowledgements that look like they were coming from 10.1.1.2.
      Notice that there does not have to be any hosts at 10.1.1.2, and
      therefore the 20000 hosts are not receiving ICMP replies or
      TCP RSTs.   The real target might be the network 10.1.1.0/24.

   4. As a result, the 10.1.1.0/24 network is flooded with unwanted traffic.

The fix is simple, but needed:  Either

   a) during the initial negotiation the hosts check the reachability
      of the secondary addresses, and make sure, through some simple
      and cheap crypto, that it is the same host answering at all of
      the given addresses, or

   b) once the primary address becomes unreachable, the hosts check,
      using some simple and cheap crypto, that it is the same host
      answering at the secondary address, *before* sending any larger
      amounts of data to that secondary address.

If you look at the current MIPv6 security solution, it is essentially
a variation combined a) and b); a) since a MIPv6 host is multihomed
at its home address and care-of-address and b) since the care-of-address
changes in an unpredictable way during a handoff.

The essense: You *have* to check that it is the *same* host that
is answering in the secondary address *before* you send any larger
amounts of data to that address.

For what I've been following SCTP etc, it looks like the possibility
of such a flooding attack has been neglected.

Using that "simple and cheap" crypto is not very secure, of course.
PK makes it more secure.  But people seemed to agree that it is
good enough for MIPv6; maybe it would be good enough for end-host
multi-homing as well.  Hence also my call for non-PK crypto for HIP,
since HIP is more than just security.

[In principle I agree with your "strengthening TCP ISS/IRS" view.]

> establish trust that the change of address is authorized.

IMHO, that is quite a black&white view.  I think that the majority
of end-host multihoming cases will be shades of gray there in between,
e.g. mobile devices with multiple alternative network interfaces.

> only during the exchange, but no other time.  With mobility, the attack could

I slightly disagree for two reasons:  Firstly, I don't believe
in the black&white multi-homing vs. mobility distinction, but I
see the shades of gray.  Secondly, IMHO the flooding attacks
look very much the same, even though the details differ.

The expired draft-aura-mipv6-bu-attacks-01.txt had pretty good
text about the flooding attacks.  It is still available at
Google cache.

> man in the middle one, and then I will be perfectly happy to concede defeat.

Maybe the flooding above qualifies as one? :-)

> heavyweights to finally put the matter to rest if possible.

Well, the security people think that I'm a mobility person, knowing
nuthin about security, and the mobility people think that I'm a
security Steve, knowing nuthing about mobility.  So take your
grain of salt.

--Pekka Nikander

---

From: Peter Tattam <[email-masked]>
Date: Mon, 28 Oct 2002 19:03:09 +1100 (EST)

>       amounts of data to that secondary address.

How about a variation on both of these...

c) only the primary address remains in an established state.  Secondary
addresses remain in a syn-received state until required to be used in which
case the syn-ack and ack packets have to also be sent on the secondary
addresses using the same nonce.  If it doesn't arrive on the same host, the
flood storm will be immediately quenched.  (the decision to send a RST might be
a policy decision on the host).

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Oct 2002 10:23:37 +0300

> a policy decision on the host).

I think that approach could be developed as well.  However,
maybe you should pay attention to the possibility of faked
acks.  That is, if Alice is the attacker, she knows the
nonce.  Thus, she might be able to anticipate the forthcoming
syn-ack containing the nonce, and be able to ack that even
if she doesn't see the syn-ack.  Thus, we must combine
   a) the nonce used on the primary connection, and
   b) a fresh nonce generated for the syn-ack on the secondary
      address.

If you hash these together, you, again, have a solution very
similar to that of Mobile IPv6.

--Pekka

---

From: Peter Tattam <[email-masked]>
Date: Mon, 28 Oct 2002 20:01:22 +1100 (EST)

>    b) a fresh nonce generated for the syn-ack on the secondary

Hmm..  good point.

What about if we turn the process around backward.  The site which decides the
other end is unreachable starts a fresh exchange on the new address pair
(although it is still a secondary address and no new addresses may be
introduced) with a separate nonce for each unused destination address (as seen
by the host originating packets).  The new nonce has to be cryptographically
strong enough to be unguessable.

i.e.

5. Bob sees Alice is not responding to the primary address and sends a new MH
SYN-Secondary to the secondary address, but with new originating nonce.

6. Alice responds with a MH SYN-Secondary ACK-Secondary (with same addresses
as before). (original nonce or new nonce???)

7. Bob sends MH ACK-Secondary as with MH ACK-primary.

We add some extra signals...

for Primary MH address establishment we use as before..

SYN-primary and ACK-primary control signals (like SYN and ACK bits in TCP).

for each Secondary MH address establishment we use two new signals..

SYN-secondary and ACK-secondary control signals

A SYN secondary must be ignored if there is no MH state with the primary
address in the ESTABLISHED state.  Also, I think the address list should match
exactly the same as the primary address.

Would that solve the problems?

> similar to that of Mobile IPv6.

I am not sure if that is totally necessary if we exchange the same addresses as
before along with a new originating nonce (so the packet looks almost identical
to a primary MH SYN address packet except for nonce and control bits)

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Oct 2002 15:30:31 +0300

> Would that solve the problems?

Maybe.  I'd have to see a much more specific description before
I could analyze it for possible holes.  But as a quick evaluation,
maybe the address list + the existense of a higher layer context
would work well enough.

But, IMHO, we are now going too far into a transport specific
solution space.  There are other problems with transport-only
solutions, like consistency between different parallal transport
connections, the amount of signalling when changing from primary
to secondary etc.

I fully support Iljitsch in the call for an architectural discussion.
That was the reason why I chimed in:  instead of trying to hack
end-host multi-homing support into TCP or IP, maybe it would be
the right time to consider a new name space.  And if not, taking
a good look at SCTP, as Brian suggested, might be the right road.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Oct 2002 19:44:25 +0100 (CET)

> right place to discuss that question, the answer is too long.

If the answer is so long, how do you expect to convince people they need
it...?

> And please read the NSRG report before we start to dive into this.

Ok.

> for example.  Or some other name resolution service.

The DNS is strictly hierarchical. If address/number/hash 1234::5678
belongs to organization A, 1234::5679 to B, 1234::567A to C and so on,
it is impossible to delegate authority so the whole thing must be
administered at some central place. This is bad. This problem is one of
the reasons why GSE didn't make it.

>      of introducing a new name space, cryptographic or not.

I don't completely agree (or disagree). Yes, the best time to do this
would be when making changes anyway, but since this means changing more
than what's needed to get multi-address multihoming going, doing it at
the same time isn't "free".

>      same security problems as (some) end-host mobility solutions.

That's what everyone has been saying the last few days. However, I see
some fundamental differences. First of all, in multihoming all the
addresses are known beforehand. This gives us more options to implement
security mechanisms. Second, mobile hosts are likely to travel to a
place where the network is less secure than at their home location. For
multihomed hosts, the security of their network connections doesn't
really change.

> have something else in your mind.

As you say, MIPv6 is complex. I haven't fully digested how this works,
so it's hard for me to say much about it. I realize that there is a lot
of overlap in what needs to happen, but the functionality is
fundamentally different so I don't think we are reinventing the same
thing.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Oct 2002 20:12:17 +0100 (CET)

[...]

>       and cheap crypto, that it is the same host answering at all of

This isn't the preferred option as the secondary address may be down at
the time of connection/association establishment. If there is no way
around it, we can adopt a solution where you can only use the addresses
that were up at the start of the negotiation, but that isn't the best
way to handle it.

>       amounts of data to that secondary address.

Why do all this checking? Just assume the host is interested in the
traffic until it tells you otherwise. For TCP apps, you're pretty much
guaranteed to be in slow start anyway, so there wouldn't be much
flooding. However, some way to throttle back streaming applications
until we know the other end is happy would be good. It would be
appropriate to redo the path characteristics discovery at this point in
time for any streaming media applications as it is likely these
characteristics are different now. (Note that using current multihoming
a minute or more of unreachability when rehoming isn't out of the
ordinary.)

If the host at the new address doesn't want the traffic, there should be
a way for it to make the sender stop without relying on transport
mechanisms such as TCP RSTs. It would be good if the host at the new
address receives the IP address from which all of this was initiated so
an attacker can be traced easily.

> amounts of data to that address.

Why? If this address was presented as a valid secondary address
(assuming this is done in a way that is reasonably secure) AND the host
at the new address accepts the traffic, what's the problem?

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Oct 2002 21:47:41 +0200

[I changed the subject to match content.  Besides,
  this starts to go off-topic.  But a part of this
  discussion is already moving elsewhere.]

> If the answer is so long, how do you expect to convince people they need

Well, to give a short answer, HIP doesn't fit in to the way
people are used to work at the IETF:  take one problem, and
solve it.  And that's the reason why there is no HIP WG,
at least as far as I understand the situation.  I didn't
have the discussions with the IESG, so I don't know.

Anyway, I'll write a longer one to the hipsec list, explaining
the details, but here is the condensed answer:

   HIP does not solve any new problems (except perhaps
   IPv6 end-host multi-homing).  Instead, it solves a number
   of problems that have already been solved individually,
   but in an integrated and architecturally "better" way.

(If you don't want to subscribe to the hipsec list, the
archive is at http://lists.freeswan.org/pipermail/hipsec/)

> multihomed hosts, the security of their network connections doesn't

I agree and disagree.  As I already wrote in my answer to Peter,
if you take the view that end-host multi-homing is only for large
servers, I can't but agree with you.

However, I'm personally more interested in multi-homed end-user
devices, i.e. the future mobile devices and home appliances
with multiple simultaneous network connections.  There are
already now PCMCIA NICs available that are able to switch
from WLAN to GPRS to something else, and the next generation
NICs will be able to maintain a WLAN and a GPRS/EDGE connection
at the same time.  I have both an old ISDN line and an ADSL
line to my home server, and if I had a good end-host
multi-homing solution I could use the ISDN line as a good backup.
My current practise of manually changing the routing tables and
re-establishing TCP connections is not very transparent.
With a better multi-homing solution, maybe I could replace the
ISDN with a second ADSL or Cable.  Under the current arrangment
that doesn't make much sense.

Now, if we speak about this kind of end-host multi-homing,
then I don't think that the difference is so great.
Either you have multiple IP addresses at the same time,
or you have multiple IP addresses one after another,
or some combination of both.

So what?  Maybe we need not just different multi-homing
solutions for large sites and small sites, but also for
large stationary servers, home servers, and mobile multi-access
end-hosts.  I just don't know.  But so many solutions sure
sounds quite complex.

I'm just making an observation that to *me* the *security*
problems look pretty similar.  Maybe I'm wrong, I'm still
learning about multi-homing.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Oct 2002 20:49:44 +0100 (CET)

> I fully support Iljitsch in the call for an architectural discussion.

Actually it was Tony.

> the right time to consider a new name space.

Then the first order of business would be to solve the discovery
problem. Is someone brave (or foolish?) enough to stand up to the DNS
people and suggest using the domain name system for this? Or have a look
at the MHAP draft for an example of one that doesn't use the DNS:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt

I think something completely new, designed specially for this purpose,
would be best, but that will take a good deal of time.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Oct 2002 22:23:16 +0200

> traffic until it tells you otherwise. 

Remember that maybe there is no host there.  Maybe the target is
to flood a network.  In IPv6 it is fairly easy to select an empty
address, in fact probably easier than to pick an existing host.

 > For TCP apps, you're pretty much
> flooding. 

In TCP the attacker can anticipate what you send and send
you faked acks, probably even trick you to send data on
much faster rate than what you otherwise would do.

The checking just takes on round trip, and you can even
piggypack your regular data.

> an attacker can be traced easily.

I agree with the value of sending the initial address.  However,
we must remember that maybe there is no host in the first place,
and at the time when the local router knows this for sure, it
may be already too late: the router may be completely flooded
with all those extra streams, maybe even targetted to different
address each.

> at the new address accepts the traffic, what's the problem?

Once more:  The attacker selects an address that has no host on
it, with the goal of flooding the network.  It will take some
time for the end-router to notice (through ND) that there is no
host in that address.  The attacker can send acks to the TCP
segments, since it knows the sequence numbers and most probably
can anticipate the traffic pattern.  When the end-router is
ready to send ICMP host unreachable, it is already too late since
it will be flooded.

Paying the price of delaying some packets and calculating
one hash (or something equivalent) isn't that high.

--Pekka Nikander

---

From: Peter Tattam <[email-masked]>
Date: Tue, 29 Oct 2002 08:01:57 +1100 (EST)

> maybe the address list + the existense of a higher layer context

Doesn't bother me - I'm just thinking on my feet.

> connections, the amount of signalling when changing from primary

I don't want to rule out crypto altogether (e.g. I would insist on crypto
for the nonce selection.  My latest TCP stack [Trumpet Winsock and PetrOS
TCP] uses crypto [MD5 hashed sequence] to select ISS for all tcp sessions now.
It seems to be fast enough for the purpose of building lots of TCP connection.)
You must however be very carefully aware of the types of crypto being selected
from a CPU time perspective.  PK encryption is very CPU intensive and could
easily result in DoS attacks at the kernel layer.

> a good look at SCTP, as Brian suggested, might be the right road.

I looked at SCTP a while back.  While it has some similarities, I agree with
others that it will not solve the legacy problem of apps that are built for
TCP.

> --Pekka Nikander

I have gotten to the point where I am agnostic about whether this particular
solution should be deployed or not.  It would be nice if it solved a large part
of the MH problem, but if it never gets accepted, I'm not going to lose any
sleep over it.  I don't have a great deal of time at my disposal, and IETF
meetings are out of the question because of my limited financial resources.

Maybe mobility is the way to go.  Why not apply it to realistic scenarios and
see how well it fits.

Peter

---

From: [email-masked]
Date: Tue, 29 Oct 2002 08:25:49 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

 > end-hosts.  I just don't know.  But so many solutions sure

we should have only one multihoming solution and that should definitely
also cover the mobile hosts that are simultaneously attached to several
mobile network (wlan, gprs, umts) and whose attachments can come and go
dynamically.  ietf should not approve any limited solution that would
only apply to stationary multihomed sites.

-- juha

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Oct 2002 09:39:40 +0859 ()

Juha;

> only apply to stationary multihomed sites.

Unfortunately, your requirement for mobility is limited.

Morevoer, it is partially satisfied already as mobile host implementation
matter. A mobile host with multiple attachments is free to try all
the attachment, if, through some attachment, communication with a home
agent fails.

We already have running IPv4 mobile host implementation with PHS and
WLAN attachment.

Note that it is a variant of end to end multihoming, though a property
of moblity that care of addresses are variable and variable and that
WLAN is always better than PHS makes the implementation easier.

The basic reuirement for robust mobility, equivalent to the robustness
of multihoming, is to have multiple mobility agents (such as home agents).

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Oct 2002 11:59:23 +0100 (CET)

> address, in fact probably easier than to pick an existing host.

But unlike with v4, there is a good chance you'll get a host unreachable
back.

> much faster rate than what you otherwise would do.

Good point. We need something to protect against that.

> piggypack your regular data.

Yes, that would be a good way to handle it. Do you agree that doing this
at the time the first choice address becomes unavailable makes more
sense than doing it at the time of initialization?

> with all those extra streams, maybe even targetted to different

I didn't think this was a very likely attack scenario because it is so
expensive for the attacker, but now that I think about it: it would be a
viable attack because the attacker gets to bypass any filters the
attacked network may have in place. I don't really see any way around
this, though, except make this attack as expensive as possible for the
attacker.

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 30 Oct 2002 21:45:14 +0200

> sense than doing it at the time of initialization?

 From the security point of view it doesn't make much difference
whether you make the check in the beginning or when the first
choice address becomes unavailable.  What is important is that
you can strongly bind the existing connection between the first
address pair to the secodary addresses, and that you check the
validity of the secondary address before sending any larger amounts
of data.

--Pekka