Subject: Multihoming by IP Layer Address Rewriting (MILAR)

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Sep 2001 20:36:38 +0200 (CEST)

Before I write up a draft, let me run it by the list.

Considering that:

- using multiple address ranges is the only way disconnect the growth in
  multihoming from the growth of the global routing table

- the transport layer is not the best place to implement multihoming:
  the natural place is layer 3 and implementing it there also avoids large
  amounts of API problems and higher layer changes

- multihoming should work in all stages of a connection, including setup

- tunnels are a Bad Thing: they waste bandwidth, hide the network topology
  and current PMTU discovery standards and implementations easily break in
  the presence of careless tunnel deployment

- a host implementation is a good: no need to change routers and
  multihoming benefits trickle down all the way to the host, unlike
  current IPv4 multihoming

- a router implementation is good: no need to change large numbers of
  hosts

a multi-address multihoming system could work as follows:

Transport layer entities connect to a remote host in exactly the same way
as they do now. However, in the mean time the network layer takes steps to
discover alternative addresses for the destination address.

This can be done using the DNS ip6.int zone, a special ICMP message or
some other means.

When the IP layer decides that the destination address is unreachable or
performance is not what it should be (because it receives an ICMP
unreachable, an ICMP TTL exceeded or a hint from the transport layer), it
chooses one of the alternative addresses, and starts to rewrite the
destination address for packets to the destination host.

Note that this happens for ALL packets to that host, the only exception
being layer 4 sessions that have the new "I know about MILAR and I'll pick
the destination address myself, thankyouverymuch" option in the layer 4 ->
layer 3 interface enabled.

When the destination host receives a packet that is addressed to one of
its alternative addresses, it restores the original destination address
and delivers the packet to the transport layer. (So the TCP pseudo-header
will again produce a valid TCP checksum, among other things.)

The rewriting and/or restoring of the destination address can also be
performed by a router on behalf of a group of hosts.

There is a security problem: a host may think it's communicating with host
with a certain IP address, while it is in fact communicating with a very
different host, which is not the owner of the IP address in question nor
reachable over it using regular routing. This breaks "security by looking
at the IP address", but this was never very secure to begin with anyway.

Iljitsch van Beijnum

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 3 Sep 2001 22:49:34 +0200

I think LIN6 is an implementation of the host translation case that you are
proposing.
Regards, marcelo

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]]En
nombre de Iljitsch van Beijnum
Enviado el: lunes, 03 de septiembre de 2001 20:37
Para: [email-masked]
Asunto: Multihoming by IP Layer Address Rewriting (MILAR)

Considering that:

Iljitsch van Beijnum

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Sep 2001 23:09:50 +0200 (CEST)

> I think LIN6 is an implementation of the host translation case that you are

I have perused the LIN6 draft, but as far as I can tell without a much
closer read, it requires IPsec (which makes it too heavy-weight for most
current applications) and it also uses a special value in the rewritten
address.

What I want to do (but, granted, do not explain in much detail) is rewrite
a prefix. That could be a /128 or a /64 or a /48 or anything else.
Obviously, when a host is doing this itself, it will usually replace one
/128 with another. On the other hand, if a proxy rewriting agent performs
the operation, it might substitute one /64 prefix for another. The host
bits remain the same. That way, the entire process is just about
completely stateless.

I am of course in now way claiming to be the inventor of address rewriting
or even a particular way of address rewriting, all I did was to remove
most of the complexity of earlier proposals and integrate everything.

Iljitsch van Beijnum

PS. Is it just me or are there severe bootstrapping problems when trying
to understand drafts? I've read about 8 of them today, and in most cases
you have to read the whole thing before understanding much... Please
please please use a good abstract and/or introduction in longer drafts.

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Mon, 3 Sep 2001 15:33:06 -0700 (PDT)

> - tunnels are a Bad Thing: they waste bandwidth,

Don't host solutions waste b/w discovering alternate addresses? I
think they waste even more than tunnels which are only used when routing
reliably knows there are failures.

> hide the network topology

Tunnels, at least as I used them in my draft
(draft-ramki-multi6-nlmp-00.txt)  don't have to hide topology
in any way. They only mask failures.
Perhaps tunnels is a bad name; may be encapsulation is more appropriate.

>   and current PMTU discovery standards

Current PMTU standard *requires* the host to cope with changes in MTU when
routing changes MTU even with no tunnels. If one is so insistent on not
adding encapsulated header, a router can rewrite the destination routing
goop instead of adding an encapsulation header.

> and implementations easily break in

My draft shows how you can automate them as attributes to routing; no
manual configuration is necessary.

>
> When the IP layer decides that the destination address is unreachable

how can this be done without wasting b/w?

> unreachable,

How do you deal with fake ICMP messages?

> at the IP address", but this was never very secure to begin with anyway.

Arbitrary change of addresses opens up lots of *new* "interesting"
hijacking and DoS issues without a proper security architecture in place.
Something along the lines of hip (host-identity payload) must be used.

One other complexity in doing host-level multihoming is supporting
multicast.

regards,
-ramki

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 03 Sep 2001 20:13:23 -0400

>Something along the lines of hip (host-identity payload) must be used.

        RFC-1825/2401 defines a Security Architecture that covers this case
quite well (was designed to do so, oddly enough) and ESP/AH are 
mechanisms that work.  AH was designed to handle things like ICMP 
authentication and works quite well for that.  I demo'd AH authentication 
of ICMP in running code for ARPA back in late August 1995.  Small 
vendors like Microsoft and Sun have shipping ESP/AH today 
(e.g. in Win2K, Solaris8).  Free software vendors (Linux, *BSD) 
also have shipping ESP/AH today.

        So we don't have a security architecture or a security technology
problem [1] today in this regard.

Ran
[email-masked]

[1] Caveat:  IKE is arguably broken, but there is running IKE code 
        these days and it will get the job above done at least until 
        a replacement for IKE happens...

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Mon, 3 Sep 2001 17:57:33 -0700 (PDT)

> problem [1] today in this regard.

But my concern is that without a scalable key distribution and revocation
mechanism, wouldn't we be converting the problem of scalable routing into
scalable security?

thanks,
ramki

---

From: Peter Tattam <[email-masked]>
Date: Tue, 4 Sep 2001 11:10:48 +1000 (EST)

The discovery of the alternative destination address is the crux of the problem
and needs to be handled in such a manner as to prevent spoofing attacks.  IPsec
is too heavy to deal with the issue - my lightwieght proposal of a SYN/ACK
exchange like TCP works but is subject to address list explosion issues which I
hope to resolve through sending compressed address trees instead of lists or
sets. Much of what you have suggested about processing incoming packets is
also dealt with in my proposal.

The most difficult task is knowing which addresses to choose first based on DNS
queries, choosing alternative addresses when a failure occurs and knowing when
to start choosing an alternative address.  We don't have much empirical
experience with this and we are only guessing at the right way to do this.

I'm not sure that you have addressed these issues - I look forward to any new
ideas on this front.

Peter

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

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 03 Sep 2001 21:25:57 -0400

>mechanism, wouldn't we be converting the problem of scalable routing into

        IKE works fine for now and can provide scalable key distribution.
Key revocation is a concept that applies to certificates, not really 
to session keys used with ESP/AH.  In short, we have technology today 
that suffices.  IKE could be better, but what we have is sufficient 
for now (until replaced with something else).

        Again, we do NOT have a security architecture or
a security technology problem today that prevents address
re-writing from being considered here.

Ran
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Sep 2001 09:06:05 +0200 (CEST)

On Tue, 4 Sep 2001, Peter Tattam wrote:

> sets.

Doing this in the SYN/ACK handshake has the disadvantage that you have to
do it over and over again for each TCP session. One popular application
comes to mind that uses many short lived TCP sessions...

I think we should definately not rule out the DNS for this, unless we're
absolutely sure this will not work. Yes, the domain name system has many
problem areas, but since it is already used for normal session setup,
(A/AAAA record), the exposure to these problems is already there and using
the DNS again will not do much, if any, additional harm.

And even if the DNS can't be trusted, it could still be a valuable source
of "hints" that can be validated through some more secure means later.

Another way that could work reasonably well is to use ICMP messages.
Incoming ICMP messages that claim to carry alternative addresses for some
host are highly suspect, but we can work around this by having the source
host first send an ICMP "what are your addresses" message, along with a
certain amount of reasonably random data. (A challenge, if you will.) The
destination host would then respond by echoing back the random data and
supplying the alternative addresses. This is safe if the data is
sufficiently random and the traffic is not intercepted, and there could be
options for "real" security.

The major drawback of ICMP or TCP solutions is that they can only work
when the first address is reachable at the beginning of the session.

> queries,

You could check the addresses that come back from the DNS against the
routing table, but I suspect that won't help much to find the best route,
but would only help in avoiding a small set of failure modes.

> choosing alternative addresses when a failure occurs and knowing when

One system could be to periodically cycle through all available addresses
and gather statistics for each. After a while, the system would know which
addresses are best. We could even come up with a scheme to share this
information with other hosts. Thinking about an implementation for my
proposal, I came to the conclusion that there would need to be some kind
of "address discovery daemon" because waiting for DNS replies in the
kernel wouldn't be a very good idea. Such a daemon could of course
communicate to other instances of itself on other hosts. This opens many
cans of worms for sure, and massive amounts of work need to be done to get
it right, but there are many interesting possibilities.

Simple failover schemes are in use today and/or are available as
experimental implementations and nothing suggests that "if A doesn't work,
we'll use B" isn't at least a huge improvement over "if A doesn't work,
we do nothing".

Iljitsch

---

From: Peter Tattam <[email-masked]>
Date: Tue, 4 Sep 2001 17:28:42 +1000 (EST)

> comes to mind that uses many short lived TCP sessions...

There is the chance that it can be made independent of the TCP session but
still tied to the sessions so that it may only need to be done once, and could
also work for other connection protocols. BTW, my current tcp proposal does
piggy back on the syn/ack so it's only just a little extra baggage.  It's more
expensive to send extra packets than to piggy back on an existing packet IMHO.

> the DNS again will not do much, if any, additional harm.

In my experience, it's much easier to misconfigure DNS.  There are a lot of
clueless admins out there who would not understand the implications of getting
it wrong.  Even I'm guilty of stuffing up DNS delegations and SOA's in recent
times :)

> of "hints" that can be validated through some more secure means later.

I start to get nervous whenever I hear about needing a secure channel to
exchange information.  If the system can operate without requiring rigorous
security, then it is one step more able to withstand a security attack than a
system that requires it.

> when the first address is reachable at the beginning of the session.

The DNS should have the initial set for connecting end for starters anyway.  It
was my assumption that this was a prerequisite to all the current discussion.

It doesn't tell the other end what addresses you might be coming from though. 
That would require reverse DNS at the server end (assuming client/server type
connections) and can be a matter of policy for heavily loaded sites.  We do
reverse dns on all our web servers because they are not loaded heavily, but I
bet there are some heavily used sites which might not.  In my experience having
run web servers and also having written some too is that reverse DNS can
significantly reduce the performance of the server.

> but would only help in avoiding a small set of failure modes.

DNS will give roughly the same info, but may acquire it in a less efficient
manner.  Also current DNS has no mechanism for assigning address priorities.
not unless we invent a new RR to do it.

> it right, but there are many interesting possibilities.

Depends if it's a passive or active approach to gather stats.  If it involves
extra traffic just for the sake of gathering statistics I don't think it will
be popular.  The passive approach would rely on traffic already taking place
which I had already hinted at requiring doing in my proposal.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Sep 2001 11:52:46 +0200 (CEST)

> expensive to send extra packets than to piggy back on an existing packet IMHO.

I'm not worried about something you might have to do once every hour or
so: that may take a few packets. But these days many Web pages have more
than 20 pictures. That could mean 20 TCP sessions, each negotiating all
addresses all over again. That's not the best way to do it. But you could
cache this information, of course.

> > absolutely sure this will not work.

> it wrong.  Even I'm guilty of stuffing up DNS delegations and SOA's in recent

Sure it's easy to misconfigure the DNS. But it's easy to do a lot of
things wrong. We're not trying to build a Word clone, where pressing
random keys on the keybord has to result in the creation of a perfect
business letter.

> security, then it is one step more able to withstand a security attack than a

Security is a hot topic, with just about every IP weakness known and
unknown to man being exploited today. We have to be sure the protocols we
come up with aren't easily fooled by someone falsifying header
information. But I agree with you: we shouldn't require all kinds of
strong crypto in simple protocols.

> The DNS should have the initial set for connecting end for starters anyway.

In my proposal: not really. The alternative addresses can't be listed as
valid A or AAAA records, since if these addresses can also receive regular
traffic, the destination host can't easily determine if the destination
address must be rewritten or not. On the other hand, if this is deemed
very desirable, it could be done at the cost of keeping extra state and/or
checking the TCP checksum with and without rewriting the destination
address.

The IP layer could discover the extra IP addresses through cooperation
with the resolver library, bypassing the regular DNS -> application -> TCP
-> IP path the destination address follows when creating application layer
sessions so the socket API doesn't have to change.

> It doesn't tell the other end what addresses you might be coming from though.

Good point. But this information could easily be carried in an IP option.

> > addresses are best.

> which I had already hinted at requiring doing in my proposal.

On hosts the passive approach would be appropriate. Changing to the next
address periodically and keeping a copy of the RTT values for each address
would probably do it. Maybe for routers that rewrite many sessions, the
overhead of sending some extra packets is worth it.

If we want to be really ambitious, we could come up with a TCP
implementation that could actively take advantage of having multiple
destination addresses. This TCP would load balance the traffic over the
different destination addresses, exploiting different bandwidth and delay
properties of the different paths.

Iljitsch

---

From: Peter Tattam <[email-masked]>
Date: Tue, 4 Sep 2001 20:48:14 +1000 (EST)

> cache this information, of course.

As the address exchange is controlled by the sender, I see no reason why a TCP
stack should not use a cached value while any sessions exist in the established
state.  Any other states would need careful thought about whether the cached
information s reliable enough.  Of course the API should be able to control the
desired behaviour if necessary.  

e.g. 

1) normal behaviour (exchange addresses using cache if available)
2) IPv4 behaviour (single address) 
3) normal behviour with no caching.

BTW, web browsers these days are getting a little smarter by using keep alive
HTTP connections - typically no more than 5-10 smultaneous connections.  I
recently added support for them into my web server.

> sessions so the socket API doesn't have to change.

so what are you suggesting? new RR's to list alternative addresses?  Would this
not be similar to reinventing AAAA records with priorities?

Also, how do you plan to deal with stale DNS cache issues?  If you flush DNS
caches too quickly you would degenerate into getting information directly from
the site.   Why not just get the information directly from the site?  A single
packet exchange could carry quite a lot of information.

With DNS only a single poorly configured server in the cache path to the
destination would play havoc with any address determination.

One of the reasons DNS works farily well now is that in general, name to
address mapping & vice versa is relatively long lived.  I typically see TLLs
varying from 5 minutes up to 3 or more days.  I don't have numbers on what the
current distribution of TLLs is like but my guess is that 1 day would be about
normal.  And generally, the TLLs don't reflect how static a lot of the
information in the DNS is.

When we are talking about routability, that is likely to change on a per minute
basis and you would want the change to be propagated globally as soon as
possible.  The more I think about DNS to do the job, less I am convinced that
it can.  I am of course assuming that you want to convey the best destination
avilable via the DNS - forgive me if I misunderstand what you're saying.

> Good point. But this information could easily be carried in an IP option.

surprise surprise - that's what I'm proposing :)

> properties of the different paths.

Umm.  Nope.  I don't think this will fly with the TCP people if done on an
arbitrary basis. It's sure to screw around with RTT averages and muck up the
retry mechanisms.   You only want to send a packet by an alternative path as a
last resort unless you are very sure that it will be.  

In my recent draft update, I suggested the idea of sending concurrent packets
to all possible destinations at the start of the syn exchange.  Basically you'd
have an election to see which path wins & pick that.  The downside is the
duplicate traffic could send some people ballistic.  In a TCP retry scenario
which would suggest that the path may not be the optimal, you could pull the
same trick to see if another path turns out to be better. 

The issue of load balancing is a thorny one & I'm not sure if any host based
multihoming is going to be able to do that easily. I have to confess I can only
guess at how load balancing is done with BGP. Perhaps those in the know might
enlighten me.

Another thought comes to mind.

If we consider the possibility of hosts within a site "colluding" in the case
of a provider path close by being down it might not take very many packets at
all for most of the hosts in a site to shift their traffic pattern even before
the individual connections start timing out.  The connectiions could even send
gratuitous acks ahead of time.  It probably only takes a few to start the
avalanche, but you would want to be damned sure that it couldn't be triggered
by an attacker.  Controlled multicast might be a good notification mechanism
for this.  Hmm.. we have something already in the way of router advertisements
- why not use them properly.

At the other end, if an ack for sent data in a TCP connection comes via a
different path, it is a strong hint that the current path might not be the best
and to start hunting for better paths.  This is kind of advance warning that
something has happened at the other end.

This of course assumes that we are talking about symmetric network paths.
Where traffic comes in via one provider and goes out by another it might be a
waste of time.

Peter

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Sep 2001 13:45:23 +0200 (CEST)

> desired behaviour if necessary.

Agree.

> recently added support for them into my web server.

I know the capability exists, but I have no idea to what extend it is
actually used...

> not be similar to reinventing AAAA records with priorities?

In my proposal there would have to be a new type of resource record if the
DNS is to be used for selecting alternative addresses. (Note that a host
may have multiple "regular" addresses, each with one or more
"alternatives".)

I originally wanted to bind these RRs to the ip6.int zone, so they are
easy to find with the "regular" address as the key. But if we hijack the
DNS resolver library, we could find this information during the forward
lookup stage.

So this would not be the same as AAAA records with priorities, which seem
like a good idea to be able to traffic engineer and load balance.

> Also, how do you plan to deal with stale DNS cache issues?

Not a problem: the DNS only lists addresses that might be valid, but does
not convey any actual reachability information. The host has to discover
if an address is reachable on its own. If proper host unreachables are
sent, this can be done both easy and fast.

> surprise surprise - that's what I'm proposing :)

But you are proposing this in both directions, which is somewhat more
problematic: you can only send an IP option if you can send period... But
you could try each of the different addresses, of course.

> arbitrary basis.

Are you commenting on the "really ambitious" part or the remark above it?

> It's sure to screw around with RTT averages and muck up the retry mechanisms.

Cycling through the list of addresses will of course have an impact on TCP
operation (so it shouldn't be done too often), but it may be worth it if
you discover a faster path.

> You only want to send a packet by an alternative path as a

That would be adequate. Better heuristics can be developed later.

> duplicate traffic could send some people ballistic.

:-)  You would trigger all kinds of anti SYN-flood mechanisms. But if you
need many TCP sessions anyway (such as when requesting HTML pages) I don't
see anything wrong with it.

> In a TCP retry scenario

This would certainly not waste as many resources at the receiving end as
doing it at the time of the SYN. However, in my rewriting mechanism the
sender wouldn't normally know for which packet (to which address) an ACK
is. That would require some more deep TCP magic.

> multihoming is going to be able to do that easily.

I agree that it wouldn't be easy. But since this could probably be
implemented at the sender only, there is still incentive to do it anyway.

> I have to confess I can only

In normal multihoming operation there is no load balancing at the session
level. "Load balancing" in this context usually refers to trying to
balance ALL traffic over the different pipes. BGP does support link-level
load balancing when there are several pipes between two ASes: then BGP can
add routes over each link to the forwarding information base so the links
can be used concurrently. Depending on the router, they will be used in a
per packet or per destination IP address round-robin fashion.

> - why not use them properly.

This could be very cool.

> something has happened at the other end.

If the other side has interesting info, why not explicitly say so in an
option?

> Where traffic comes in via one provider and goes out by another it might be a

Asymmetric routing is very common in IPv4. However, short (and hopefully
fast) paths are likelier to be symmetric.

Iljitsch van Beijnum

---

From: Greg Maxwell <[email-masked]>
Date: Tue, 4 Sep 2001 09:03:40 -0400 (EDT)

> comes to mind that uses many short lived TCP sessions...

Intestingly enough SCTP addresses these applications (such as HTTP) rather
well without overhead of assoication communication for every stream.

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 06:27:10 -0700 (PDT)

Hi,
I don't think that it is a good idea to assume that every multihomed host
has a DNS entry (for whatever reason); such an "anonymous" multihomed host
may initiate a connection, and  a multihoming solution must
work (redundancy, transport layer survivability, etc.) for these
connections as well. This is my primary complaint with DNS-based
solutions.

My second complaint, and this applies to SCTP as well, is that we are
implicitly assuming here that one end can do DNS lookups to learn the
addresses of the other end---this may be impossible with busy servers.

Also, I don't think it is a good idea to mandate every application to be
aware of all multi-address details, which SCTP requires. We must remember
that SCTP was invented primarily for carrying signaling messages (the
abstract says as much), and one of its co-authors I talked to says he
thinks that general applications should *not* have to deal with all these
details.

-ramki

---

From: Greg Maxwell <[email-masked]>
Date: Tue, 4 Sep 2001 09:32:17 -0400 (EDT)

On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote:

[snip]
> addresses of the other end---this may be impossible with busy servers.

This is not an issue for SCTP. SCTP learns assoiations from it's peer
directly. The only time DNS plays into it is connection built-up, where
DNS is required in the non-multihomed case as well.

> thinks that general applications should *not* have to deal with all these

You can wrap a TCP like api so the application is unaware of any
multihoming issues.

Have you read the SCTP RFC? It's a very clear superset of TCP and every
feature it has is an important feature that current apps are emulating at
higher layers over TCP or UDP (like the use of concurant connections with
HTTP to simulate multiple streams, or the abundance of UDP apps which
impliment their own reliable deliverly (and usually misimpliment
congestion control)).

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 10:29:41 -0400

At 09:27 04/09/01, Ramakrishna Gummadi wrote:
>Hi,
>I don't think that it is a good idea to assume that every 
>multihomed host has a DNS entry (for whatever reason)

Today if a host doesn't have a DNS entry, it generally has NIL
incoming connectivity.  The Internet Architecture expects hosts
to have DNS entries, so such an assumption and constraint
is totally reasonable.

>addresses of the other end---this may be impossible with busy servers.

In deployed reality, this just is NOT an actual problem or issue.

        There are LOTS of real issues and problems with multi-homing.
It would be a lot more constructive if you focused on those,
rather than trying to invent new issues/problems artificially
out of non-issue/non-problems.

Cheers,

Ran
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Sep 2001 17:24:32 +0200 (CEST)

> connections as well. This is my primary complaint with DNS-based

That is why I want this information to be in (somewhat) arbitrary places
in the reversed mapping zone, so it is not necessary for each host to have
DNS entries for all addresses.  (Which is very unlikely for hosts
implementing RFC 3041.) I think doing reverse lookups for the /128, /64
and /48 in question should do it.  Requiring someone to run a reverse DNS
with one entry so an entire /48 can be multihomed doesn't seem like a
problematic requirement to me.

On the other hand, ICMP and IP option based solutions could work well too.

> addresses of the other end---this may be impossible with busy servers.

Generally, the communication over TCP/IP works like this: an application
connects to a remote host, of which it almost always knows the host name
(but sometimes just a (one) IP address). The remote host accepts the
connection, communication happens, the connection is torn down. In this
scenario it would be best if the originating side knows all (or at least:
more than one) of the addresses of the "server" it wants to connect to,
but it is not necessary for this server to know any addresses of the other
side before the connection is established: the fact that a connection
request comes in means that there is enough connectivity to negotiate
additional addresses.

If we want to keep the multihoming in layer 3, it is good to remember that
additional address discovery / address status discovery mechanisms are not
tied to a single session.

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 08:36:56 -0700 (PDT)

> to have DNS entries, so such an assumption and constraint

But it may still have outgoing activity. For example, it may be a
mobile client in a multihomed site. We cannot assume only servers are
going to be multihomed.

cheers,
ramki

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 12:06:55 -0400

>mobile client in a multihomed site. We cannot assume only servers are

Didn't suggest as much.   With Mobile IP, there is no reason why
a mobile host does not have a stable IP address in DNS.  In fact,
such hosts normally do so today.

Ran

---

From: Greg Maxwell <[email-masked]>
Date: Tue, 4 Sep 2001 12:28:48 -0400 (EDT)

> such hosts normally do so today.

Such address is usually an unoptimum tunnled address.

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 09:44:14 -0700 (PDT)

> DNS is required in the non-multihomed case as well.

A busy public web server today can defer (reverse) DNS lookups (if it does
lookups at all) and just record the client addresses in logs. In
multihomed case, DNS lookup is necessary for connection survivability,
which means it has to be done online. I don't think the semantics are the
same in these two cases.

> You can wrap a TCP like api so the application is unaware of any

May not be as simple as it sounds because SCTP is designed to be
asynchronous, with notifications, etc. Supporting this transparently can
be problematic without threading support to wrap SCTP behavior...

> impliment their own reliable deliverly (and usually misimpliment

I read the RFC fairly carefully, and even though it may be a superset of
TCP, the api is not app-transparent like tcp, and can not be directly used
by simple single-threaded apps.

-ramki

---

From: Greg Maxwell <[email-masked]>
Date: Tue, 4 Sep 2001 12:59:06 -0400 (EDT)

> which means it has to be done online. I don't think the semantics are the

It's a total layering violation to require DNS lookups in this place.

SCTP has no such requirement, clear you confusion child. The only reason
that DNS has to be aware of multiple prefixes AT ALL, is because the
client needs 1 working prefix to bring up a connection. As the connection
is brought up, the client may transmit the rest of it's prefixes to the
server and ther server may do the same to the client.

With a minor extension likely to be in most SCTP implimentations, nodes
can transmit additional endpoint addresses at any time during
communications.

Again, the DNS lookup in the SCTP case is only needed where one would be
needed anyways, but it provides just a little more information.

> be problematic without threading support to wrap SCTP behavior...

You can open a single stream and pretend it's TCP. Yes, if you want to
take advantage of multiple streams (which HTTP really should do!) you will
need some massive application chages. Nice thing is that it could be done
totally transparently and SHTTP 1.1 could over time be migrated to SHTTP
1.2.

> by simple single-threaded apps.

Yes it can. You can open a single stream and pretend you are talking on a
TCP connection totally transparently. Yes, you don't get all the
advantages, but you do get multihoming.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 13:46:46 -0400

>Such address is usually an unoptimum tunnled address.

        It moves bits fine and there are reportedly methods 
in Mobile IP for rapidly learning a more optimum address.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 13:48:42 -0400

At 12:44 04/09/01, Ramakrishna Gummadi wrote:
>In multihomed case, DNS lookup is necessary for connection survivability,
>which means it has to be done online. 

Disagree that a reverse DNS lookup is necessary for connection
survivability when multihoming.

Ran

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 5 Sep 2001 02:00:16 +0200

> you could try each of the different addresses, of course.

If I understand it correctly this could be a good trade-off solution.

In a large portion of cases, a DNS query is performed before connection is
established, so this could be a place where to include all the addresses of
the target host, because no extra query is usually requiered.

However if we want to use DNS to obtain source host address set, this would
requiere an extra DNS query which may not be desirable, so source address
set can be carried in the IP prefix option.

In addition, the IP prefixes option could include a flag which indicates
whether the source host has a target address host available (it got it from
DNS) or not, so that the target host can include or not a IP prefix option
in the SYN-ACK packet. This option could be included anyway to override the
existent address set.

Regards, marcelo

---

From: Peter Tattam <[email-masked]>
Date: Wed, 5 Sep 2001 12:06:39 +1000 (EST)

> in the SYN-ACK packet. This option could be included anyway to override the

For the case where you only have a single starting address but there exists
several alternative addresses and there is no way to find the alternatives (no
DNS entries), you can only rely on routing infrastructure to tell you the rest
of the addresses if the peer can't tell you.  This case would force routers to
get involved which I hoped one could avoid.

It doesn't have to be a router that tells you this, just some third party
service like DNS or a reachability cache or somehing. 

I agree with the comments mad by Christian about DNS not being the best vehicle
for this kind of information. 

Is it worth pursuing the reachability cache idea?

Peter

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 5 Sep 2001 05:45:45 +0200

> De: Peter Tattam [mailto:[email-masked]]
> Enviado el: miercoles, 05 de septiembre de 2001 4:07
> severtal alternative addresses and there is no way to find the
> alternatives (no
> of the addresses if the peer can't tell you.  This case would

Sorry, I think I do not understand, but doesn?t always the host knows which
addresses have been asigned to their own interfaces? Perhaps not all of them
are reachable  but this issue could be addressed with Router Renumbering and
Router Advertisement mechanisms, deprecating unreachable addresses.

> force routers to

I am not saying that the DNS is the best option, I am just saying that for
almost the same price of the usual AAAA query, the DNS can provide an
initial address set, that can be overwritten in case that the other end
consider it necesary.

> Is it worth pursuing the reachability cache idea?

I find it interesting. I think that bragg draft proposed something related,
and reachability information was comunicated through redundant information
on the routing protocol. A similar mechanism  could be used to inform a host
about which of their own addresses are reachable from the outside.

Regards, marcelo

---

From: Peter Tattam <[email-masked]>
Date: Wed, 5 Sep 2001 14:10:12 +1000 (EST)

> Router Advertisement mechanisms, deprecating unreachable addresses.

I'm talking about addresses of the peer.  If we have only one address for the
peer there's no way to find out it's alternative addresses if we rule out DNS.

> about which of their own addresses are reachable from the outside.

The information could be considered advisory and would eventually be confirmed
either way by the syn handshake.  The risks of spoofing do however increase if
such a cache we contaminated.  This risk would be roughly equivalent to that of
bogus DNS entries.  We have grown accustomed to some degree of trust level with
the DNS.

It all boils down to what level of security you are trying to achieve.

A level of security based on a DNS lookup of the address could be achievable
with such caches.

Anything more would require you to enter the IPSec arena to establish
authenticity of each end.  Not all applications need this level of security
though.

It's clear that there's not going to be a one size fits all solution.

MH solutions that require high availability and security will take lots of
resources to authenticate in comparison to quick & dirty schemes that rely on
DNS or something similar to seed the MH process.

If you can't contact directly any of the addresses you know to be authentic,
the authenticity of the connection can't be guaranteed and should be reported
as such to higher layers.

However once you get connected to an address you know to be valid additional
addresses can be immediately exchanged.  A man in the middle attack can still
take place, but this is no different to a single - single address connection.
Only IPSec can prevent that from happening, but not all connections need IPsec.

Hijacking could take place but only by a man in the middle controllign traffic
both ways. A man in the middle can do plenty of other nasty things so it's
probably academic whether a connection could get hijacked in this manner.

Peter

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Sep 2001 09:12:26 +0200 (CEST)

> get involved which I hoped one could avoid.

We can't use the routers for this, since this information can't be
aggregated so we'd lose the "small DFZ" we're trying to work towards.

> Is it worth pursuing the reachability cache idea?

I love the idea of a reachability cache where a group of hosts and routers
shares reachability information. However, I don't see how this could be
used to find out alternative addresses for a site for which there is not
yet any information in the cache. Also, it is much more important to
protect the cache against falsified alternative addresses than to
falsified (un)reachability information, since the former can lead to data
interception and DDoS attacks, and the latter only to a slight performance
degradation while the host discovers the cached information is incorrect.

The alternative would be some sort of address registration server, but
this would have to be both redundant and safe.

---

From: Peter Tattam <[email-masked]>
Date: Wed, 5 Sep 2001 17:26:02 +1000 (EST)

> this would have to be both redundant and safe.

Something else to consider.  We are generally trying to work out alternative
prefixes for entire sites, not micro managing every single address on the
planet.  This is assuming of course that the lower 64 bits is the same across
all prefixes.

Peter