Subject: I-D ACTION:draft-huitema-multi6-hosts-00.txt

From: [email-masked]
Date: Fri, 12 Oct 2001 07:10:38 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Host-Centric IPv6 Multihoming
	Author(s)	: C. Huitema, R. Draves
	Filename	: draft-huitema-multi6-hosts-00.txt
	Pages		: 24
	Date		: 11-Oct-01
	
A way to solve the issue of site multihoming is to have a separate 
site prefix for each connection of the site, and to derive 
corresponding addresses for each host. This approach to multi-
homing, which we call Host-Centric IPv6 Multihoming, has the 
advantage of minimal impact on the inter-domain routing fabric, 
since each site prefix can be aggregated within the larger prefix of 
a specific provider; however, it opens a number of issues. We 
analyze in detail the problem created by the interaction between 
ingress filtering and multihoming. We then propose a set of specific 
solutions that enable host centric multihoming, and we review how 
these solutions meet the requirements of IPv6 site multihoming.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-huitema-multi6-hosts-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-huitema-multi6-hosts-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Oct 2001 18:30:40 +0300 (EEST)

> 	Filename	: draft-huitema-multi6-hosts-00.txt

This could be a a rather simple and _natural_ way of doing
multihoming.

Comments below.

A big issue, seen in very many places in the draft:

Here it's very much assumed that ingress filtering is only performed at
ISP-Customer border, by the ISP or possibly the site.  This is often the
case, but responsible sites (at least bigger sites) will do it internally
too, e.g. between different site sub-parts.  The strictest version of this
would be it being done in every LAN connection, by ACL's or with RPF
checks.

Additional checking could also be done elsewhere, e.g. isp-bigISP or
isp-transit border.

If this method would restrict the scope of applicability of ingress
filtering only to a few topological places ... doesn't sound good.

In the draft, it should at least be considered where the filtering can be
done and with which scope (e.g. if you allow both site prefixes, would it
be okay).

Another biggish issues that come to mind:
 - the reliance on DNS.
 - if you get two addresses from DNS, one which is unreachable (e.g.
blackholed), how long does it _actually_ take to select the next one?

   this could take a _lot_ of time.  If you try a tcp connection to an
unanswering system, it's usually a _long_ time, in dozens of minutes in
most implementations I've seen.

More detailed comments...

2.2 Reference topology

We assume that X, when it begins communicating with Y, has learned
the addresses C:Y and D:Y, for example because they were published
in the DNS. We do not assume that the DNS is dynamic: there will be
situations in which both C:Y and D:Y are published, while in fact
only one is reachable.

==> reachable from where?  Depending on where the problems are, different
people might have different opinions about the reachability.

4.1 [editorial]

this means that the exit
routers will have to obtain the right to use as source address a
privileged IPv4 address

==> move 'as source address' to the end.

Asking each potential end of the tunnel to relax its
checks is not realistic; in practice, this means that the exit
routers will have to obtain the right to use as source address a
privileged IPv4 address, such as the 6to4 anycast address or the
Shipworm anycast address; this will imply a negotiation with the
provider of the IPv4 service.

==> you suggest a hack.  IPv4 shipworm anycast address (and similarly
proposed 6to4 address) was specifically allocated for _relays_, not to be
used to get around IPv6 ingress filtering via this loophole.  I oppose
this.

==> General comment about 4.1: This very much assumes that ingress
filtering is only done at one place, isp-site border.  Responsible sites
do it everywhere.  ISP's might do it everywhere too (e.g. ISP-transit
border).

4.2     Source address dependent routing

Another solution to the site exit problem is to perform some kind of
source routing within the site, so that the site exit is effectively
a function of the source address in the packet. Current routers
generally do not implement any kind of source address dependent
routing

==> How is this different from IPv4 policy routing?  (which is thought to
be a very evil practise by many).

4.3 Source address selection by the host

There will however be
cases in which the prefix is learned after the source address is
already selected. In these cases, the host could insert in the
packet a "home address" option that carries the intended source
address, as specified in [MOBILIP6]; the IPv6 source address will be
set to the available interface address that matches the preferred
source prefix.

==> Could you elaborate a bit on these cases (probably related to
renumbering and/or the first stages of stateless address
autoconfiguration)?

==> I'm not sure what you propose:  the already selected address put in
as a Home Address (probably), or as the real source address?  If the
address is already selected, and a new one will be used as the real
source (assuming as above), what would be the disadvantage of
re-selecting the first address too?

==> I do not like this tenuous connection to Mobile IPv6 at all; I do not
consider random use of HA Option to be trusted by any means.

As for path MTU discovery, source address discovery requires that
the hosts receive some information from the network, presumably in
the form of an "incorrect source address" ICMP error; the error
message will have to contain information about the packet that
triggered the error, and also information about the source address
prefix that should be used to pass the source address check. In the
absence of an explicit ICMP message, the hosts would have to rely on
a trial-and-error process, noticing that packets get dropped and
trying retransmissions with alternate source addresses; the
experience of path MTU discovery shows that such processes are
awkward and error prone.

==> I do not see why 'incorrect source address' ICMP message _without the
accepted prefixes_ (which might be a security exposure, and difficult to
implement), would not be sufficient.  Usually a node would just have to
try one or two packets with different source addresses to find one that
matches.

But I agress that an ICMP message, if we take this route, is a MUST.

Another point: sending this kind of error messages should definitely be
togglable.  In this kind of scenario they make very much sense, but if the
source address is spoofed, there is no sense in sending out ICMP messages
to a forged address (possibly harassing someone innocent).

A way here could be that the denied prefix would have to pass some ACL of
"locally valid wrong source addresses" for the ICMP message to be sent, or
the router should by some other means know the valid wrong source
prefixes.

4.4     Packet rewriting at exit router

==> strong "eeevil!" on packet rewriting.  Would break ESP/HA too, I
suspect.

==> Tunneling is valid option but there is one additional problem:
increased requirement for Path MTU.  If node is already sending at the
full MTU discovered, adding extra bytes may be physically impossible
without fragmenting.

One way to work around this might be to set the MTU of interfaces where
you expect to do this so much lower that path MTU discovery will pick the
lower value and leave room for encapsulation.  Heavy to maintain.

==> promiscuous decapsulation is problematic as seen with 6to4 and
shipworm and should definitely be avoided.

5.1.2   Site-exit redirection ICMP message

==> I believe the ICMP message must definitely contain as much as fits in
1280 bytes of the packet that triggered this message.  It might be used as
a weak form of "authentication" for the ICMP message.

==> I'm not sure if the 'preferred source address' is really that
necessary (see above).

5.2.1   Use of "Router advertisements"

In conformance with section 5.5.4 of [RFC2461], the hosts will
deprecate the formerly preferred addresses when their preferred
lifetime is set to zero. They will not use the deprecated addresses
in new communication if an alternate (non-deprecated) address is
available and has appropriate scope.

==> RFC2462, not 2461.

We propose to use the "preferred" lifetime to indicate whether
addresses derived from the prefix can be used as source address in
multihomed networks. When a prefix is temporarily not available
because the corresponding ISP connection is broken, routers SHOULD
advertise a zero preferred lifetime for that prefix.

==> If I haven't misunderstood something, this scenario is unworkable if
the RA is not authenticated due to checks in RFC2462 5.5.3.e 1-3).

6.1.6   Transport-Layer Survivability

==> I think more analysis of the solution is needed before this can be
called TL survivable; you can achieve it with any method, I suppose, if
you can assume on that MIPv6 can be used in the tight spot.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Oct 2001 22:36:34 +0200 (CEST)

> would be it being done in every LAN connection, by ACL's or with RPF

That seems redundant. If you only accept valid addresses at the edges, how
do packets with incorrect addresses get to the core? And aggressive
filtering on source addresses is problematic with asymmetric routing,
which is very common, so I would be surprised to hear that many ISPs do
so.

> Additional checking could also be done elsewhere, e.g. isp-bigISP or

:-)  Transit = default = the entire Internet = all packets from all
sources are ok.

> filtering only to a few topological places ... doesn't sound good.

If everybody filters at the edges that would be good enough. Many networks
still don't.

> Another biggish issues that come to mind:

This doesn't rely on the DNS any more than regular routing.

> most implementations I've seen.

That is no good anyway. Do I have any use for a connection that is
established after 119 seconds? Don't think so. One possible heuristic
could be to expedite the timeout when there are still alternative
addresses to try.

What concerns me more is that the draft talks about sending multiple SYN
packets at the same time. Is SYN flooding an offense yet under the new
anti-terrorist laws?

If this is going to happen there must be support to detect duplicate SYNs.
This could be done by adding all the possible source addresses of the
originating host and also an identifier that is unique at the source host.
Then the receiving host could send back packets to all the addresses
addresses of the originating host with all of its current source addresses
in it. Then if a while later a duplicate packets start to come in, it can
easily match those with the first one using the list of source addresses
and the identifier.

So if the first host sends packets from all of its source addresses to all
of the destination host's addresses and the destination host replies with
packets from all of its source addresses to all of the firs host's
addresses, they would immediately know the best source/destination combo
at each end and also fairly quickly learn what other source/destination
combos work for the other end (when the duplicates arrive).

But I think this should happen at the IP layer, for two reasons:

- if these SYNs are processed by an unaware TCP, they will consume
  application resources (ie Apache process, serval MBs in core tied up
  waiting for a timeout)

- TCP doesn't answer until the application answers. This can take a LONG
  time on busy servers

- this information should survive sessions and also be available for
  other protocols than TCP

> be a very evil practise by many).

(raising hand)

Policy routing is a more general mechanism in Cisco routers.

A somewhat defendable way to do this would be to have different routing
tables and have multiple "virtual routers" inside a real one.

> try one or two packets with different source addresses to find one that

Also, doesn't the "ICMP administratively prohibited" message effectively
accomplish this?

If a host has two source addresses, it just has to try a single other
address when it receives such a message. Not nearly as bad as PMTU
discovery. Also, when there is a TCP timeout it can retry with a different
source address.

I don't like messing around with Home Address options either. Shouldn't it
be possible to just switch addresses during the session? If all source
addresses associated with a session are known at the other end, there is
no reason to impose that the source address can't change during the
session. Or the destionation address, for that matter. If the other end
restores all addresses to those needed in the TCP pseudo-header, there is
no need to do any higher level (TCP checksum) processing and proxy agents
can be permitted to rewrite both source and destination addresses, which
will makes it possible for old-style hosts to use the new style
multihoming.

> ==> strong "eeevil!" on packet rewriting.  Would break ESP/HA too, I

There are worse things... Tunnels, for example.

> full MTU discovered, adding extra bytes may be physically impossible

- more packet overhead
- endpoint creation problems
- scenic routing

The PMTU discovery shouldn't be a problem, since it is mandatory in IPv6
so hopefully builders of stupid "security" products won't filter "packet
too large" messages (or fail to generate them in the first place).

But on the subject of tunnels: I don't see how tunneling to a site exit
router does any good. Sure, the packets get out when everything works, but
the whole point is that your sessions survive when something goes down.
This means every exit router should be able to send out valid packets
without any help from other routers. So if the source address is
inconvenient for a certain border router, it should do something about
that (rewrite, ICMP) and not send the packet to another router.

> lower value and leave room for encapsulation.  Heavy to maintain.

It's better set the MTU of the output interfaces HIGHER. Shouldn't be a
problem unless your uplink is <= 100 Mbps ether.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Oct 2001 00:03:37 +0300 (EEST)

On Fri, 12 Oct 2001, Iljitsch van Beijnum wrote:
> do packets with incorrect addresses get to the core?

If you forget to do proper filtering at one edge point, mistype the
command whatever, there's still some "safety net".  It's good to have
other kind of safeguards if you can.

> And aggressive

This is not being done for two reasons (at least):

1) it cannot be done by ISP with (most implementations of?) uRPF, most
likely (your concern)
2) with IPv4, one big ISP may have hundreds/thousands of prefixes.  Too
big a list.  With IPv6, they might only have one or a few prefix(es) to
check.  Easy.

> :-)  Transit = default = the entire Internet = all packets from all

Transit, sure.  But consider tranit-ISP border.  ISP might want to check
that source addresses of packets going to transit match its prefix(es).

> If everybody filters at the edges that would be good enough. Many networks

Sure, but filtering at the edges can fail if you do it in the "core" too.
:-)

> This doesn't rely on the DNS any more than regular routing.

It relies on the DNS to get all the destination addresses.

That is, if DNS doesn't work, or the destination is in the IP numeric
form, and the destination networks other prefix is dead, you cannot talk
to the destination's other address, as you can't find it in the DNS.

The routing system itself doesn't rely on DNS, but hosts do.

> could be to expedite the timeout when there are still alternative

True.

> packets at the same time. Is SYN flooding an offense yet under the new

I agree that multiple SYN's should not be sent; other connections should
only be tried to be established after the first one fails.

Unfortunately I don't think e.g. socket api has ways to do this, ie.
specify that if the connection is not formed in 1sec, forget about it (or
retry); you would have to do it with application, e.g. with non-blocking
connect() and a timer.  That is, this appears to be generally a no-go.

> Also, doesn't the "ICMP administratively prohibited" message effectively

You could get administratively prohibited message for a lot of different
reasons; not necessarily a bad source address.  But I agree that at least
if one would like to test how this would work in practise,
administratively prohibited wouldn't be too far off the mark.

> There are worse things... Tunnels, for example.

Open-ended tunnels (that were referred to in the draft) are bad, but I
don't think configured p-t-p tunnels are always that bad.

> too large" messages (or fail to generate them in the first place).

Should not be, yes.  I don't think if one packet sent lost by this would
be noticeable.  (host sends e.g. 1500B, 50ms away there is mtu 1480B,
first packet delivery delayed at least 150ms unless the path MTU was
cached).

> that (rewrite, ICMP) and not send the packet to another router.

I partially disagree.  The most important thing is the system to "plain
work".  If one can avoid short or even longer breaks by doing something
like tunneling, fine.

I wouldn't advocate tunneling as a solution for load-balancing or the like
though.  But under a more-or-less emergency situation, everything is
should be possible.

> problem unless your uplink is <= 100 Mbps ether.

Sure, so it would be better.  But that is not always physically possible.
And your clients could be connecting with POS, GE with jumbograms etc.
or something else with an equally high MTU as your uplink too.