Subject: Re: Transport multihoming

From: Manuel Urueña Pascual <[email-masked]>
Date: 04 Nov 2002 13:51:57 +0100

Hi,

I've been working in a protocol that seems very close to your reasoning.
Not really a new approach but catching some good ideas from SCTP and
Mobile-IP to exchange dynamic/multiple addresses between end-hosts with
legacy transport protocols.

http://www.it.uc3m.es/muruenya/draft-muruenya-epcp-00.txt

I think it may be applicable to the multihoming problem, but I'm seeking
some feedback from the MH people.

Thanks,
--Manuel

PD: I'm still trying to catch the mailing-list so maybe I've missed
something.

Peter Tattam wrote:
> As discussed at the Tokyo meeting, there are limitations in the TCP header size
> which may preclude this being done there.  Having it at the IP layer kind of
> makes sense, and having the gleaned information cached beyond the life of
> connections not only benefits multiple connections to the same host but should
> also aid connectionless protocols as well.
> 
> At Tokyo, I think Steve Deering made a suggestion that we make this an IP layer
> feature available to all protocols but it was so fresh in my mind that I had
> not thought through all the possibilities.
> 
> So my latest thought would be that we could do it at the IP layer in a similar
> way to that described in my preliminary draft.  
> 
> For TCP connections, the prefix/address set negotiation be done at syn/ack
> time, and for any other protocols that have the same syn/ack semantics. 
> 
> For connectionless protocols, the IP layer would need to rely on cached state
> to do its thing.  In such a scenario, it may be important to set an upper time
> limit on the cached information being valid, the information being updated by
> incoming traffic.  A nonce for the negotiation would have to be supplied by
> both ends in this case.
> 
> If a nonce were to be added to the IP MH options, this could be made larger
> than the TCP sequence number thereby increasing the security from seq number
> attacks.
> 
> Another possibility is that we define a MH connection protocol which
> establishes the MH characteristics of the connection between the two hosts. It
> would be analogous to a TCP session and would have the same degree of security
> as a TCP session.  It could be done directly at the IP layer or be an
> ancilliary protocol on top of IP.  It would imply that there would be host-host
> state information kept somewhere in the IP stack, but it is possible that this
> could distributed amongst the control blocks associated with each connection.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 04 Nov 2002 15:58:53 +0200

> some feedback from the MH people.

Very interesting, IMHO.  Architecturally it looks fairly similar to HIP.
What would you consider to be the main differences?

--Pekka Nikander

---

From: Manuel Urueña Pascual <[email-masked]>
Date: 04 Nov 2002 16:51:21 +0100

> What would you consider to be the main differences?

I agree with you, they are very similar, and IMHO any end-to-end MH
solution will look the same.

I've only read a paper by Francis Dupont so my knowledge about HIP is
far from deep, but I'll try:

EPCP does not require any kind of crypto capabilities or infrastructure
for basic association init, maybe for cookie generation, as it relies on
the Return Routability check. However, it allows any other mechanism to
authenticate an end-point address. In fact, CGAs are suggested as an
alternative mechanism in the Fast Add section.

I'm not really sure about this (please correct me), but HIP seems to
support just one address, that may be changed for another one with the
Readdress packet. Maybe that's a hard constrain, EPCP supports several
simultaneous addresses, even IPv4 and IPv6 altogether.

Maybe the main difference is my perception about the Identifier -
Locator problem. I think IP addresses are great identifiers: global
unique, fixed length... (see more properties in "Endpoints and Endpoint
Names", J. Noel Chiappa), and much more important, today's applications
employ them. That's why Primary Address is employed as an identifier
mapped to several locators (even to itself).

--Manuel

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 05 Nov 2002 09:59:11 +0200

> Pekka Nikander wrote:

> far from deep, but I'll try:

Thanks!

...

> simultaneous addresses, even IPv4 and IPv6 altogether.

In draft-jokela-*-01.txt the HIP REA packet has been fixed to
support multi-homing, and per-interface mobility.  However, the
RR check is still missing.  We know that.

> mapped to several locators (even to itself).

OK.  I have then the same basic problem with this as with LIN6.
Both your proposal and LIN6 conceptually *overload* the same ID space.
That causes alias problems, and potentially "stealing" problems.

When the name spaces are completely different, the alias and "stealing"
problems do not exist.  Thus, the security requirements are slightly
less strict.  For example, CGA is not needed even in a "quick" mode,
since address "ownership" is not an issue, its who is using an address
right now, not who used it before or whose primary identifier it is.

--Pekka Nikander

---

From: Manuel Urueña Pascual <[email-masked]>
Date: 05 Nov 2002 12:09:23 +0100

> RR check is still missing.  We know that.

Time to go to the library :)
 
> That causes alias problems, and potentially "stealing" problems.

I don't understand why have a separate space for ID alone solves the
stealing problem. Anyone can steal your ID unless cryto is used, of
course. Do I miss something?

Anyway I didn't explain it well, Primary Address is employed by legacy
transport protocols to identify the peer. For the network layer it's
wiser to employ the Endpoint Identifier, which is set locally and it's a
separate ID space.

> right now, not who used it before or whose primary identifier it is.
 
That is exactly what EPCP checks with RR+Endpoint Identifier, that an
address is used by the peer that tries to add it.

--Manuel

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 08:32:11 -0500

On Tuesday, Nov 5, 2002, at 06:09 America/Montreal, Manuel Urueña 
> course. Do I miss something?

You are not missing anything.  Anytime any identity is being used
*without* cryptographic authentication, that identity might be forged.
Most identities used today (e.g. IPv6 address) are used without 
cryptography
in deployed practice.

This important detail is eluding some other people here seemingly.

Ran

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 05 Nov 2002 18:37:33 +0200

RJ Atkinson wrote:
> Most identities used today (e.g. IPv6 address) are used without cryptography
> in deployed practice.

I guess I was careless in my language, (and perhaps even muddy in
my thinking).   With separate spaces, *address* "ownership" is not
much a problem in the sense it is in MIPv6, but *ID* "ownership"
certainly is.   While RR (Return Routability) works, to a degree,
with *address* ownership, it certainly doesn't work with *ID*
ownership (that is, if IDs are separated from locators).

Sorry for the confusion, and thanks for the clarification, Ran.

--Pekka Nikander

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 12:13:14 -0500

On Tuesday, Nov 5, 2002, at 11:37 America/Montreal, Pekka Nikander 
wrote:
> With separate spaces, *address* "ownership" is not
> certainly is.

When the "address" is overloaded to have both identity and location
semantics, it inherits all the issues of both.  If there is separation,
then the issues are similarly separated -- the identity only has to
deal with identity issues and the location only has to deal with
location ("routing") issues.

> While RR (Return Routability) works, to a degree,

Given the known common presence of man-in-the-middle attacks,
I don't see that RR actually buys anything in the way
of trust or assurance that one is talking with the party
one thinks one is talking with.

Ran

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 05 Nov 2002 19:19:10 +0200

> On Tuesday, Nov 5, 2002, at 11:37 America/Montreal, Pekka Nikander wrote:

> one thinks one is talking with.

Right.  It just prevents someone from "stealing" addresses with
MIPv6 BUs from an arbitrary location in the Internet, and limits
the viable attack locations to those on the path.  I *think*
(but haven't analyzed in detail) that it would work in the same
way with end-host multi-homing based on secondary addresses.
And we must not forget the danger of and the prevention of flooding,
either.  Thus, for example, SCTP should use some sort of RR when
falling to secondary addresses.  I don't know if it currently does.

--Pekka

---

From: Manuel Urueña Pascual <[email-masked]>
Date: 05 Nov 2002 18:34:15 +0100

> ownership (that is, if IDs are separated from locators).

Why not? I mean, the RR check can test both *ownerships*:
Send a cookie to the new locator, it should reply with the cookie plus
the ID, as long as IDs are related to single a connection thus unknown
for anyone other than connection peers. 

This is more a shared secret than a ID but, are IDs needed for something
else outside the connection context?

Of course I do refer neither DNS nor crypto certificates but a
multihomed-host ID.

--Manuel

---

From: Manuel Urueña Pascual <[email-masked]>
Date: 05 Nov 2002 18:42:53 +0100

> the viable attack locations to those on the path.  

IMHO nothing can be do against man-in-the-middle attack but a PKI to
authenticate the other peer. I agree with Pekka that RR is just a
mechanism to limit attacks without the need of crypto.
 
> I *think* (but haven't analyzed in detail) that it would work in the same

I fully agree.

> falling to secondary addresses.  I don't know if it currently does.

I think SCTP sends probes periodically to inactive addresses in order to
measure RTT to choose the best alternative path if primary one fails. It
can be seen as a continuous RR check.

--Manuel

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Nov 2002 08:19:39 +0859 ()

Pekka;

> That causes alias problems, and potentially "stealing" problems.

In-addr.arpa. domain is a protection against stealing ID of
IPv4 addresses.

Similar protection is possible and implemented with LIN6.

							Masataka Ohta