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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 12 Oct 2001 Internet-Drafts@ietf.org wrote:
> 	Title		: Host-Centric IPv6 Multihoming
> 	Author(s)	: C. Huitema, R. Draves
> 	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