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

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Fri, 12 Oct 2001, Pekka Savola wrote:

> 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.

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
> isp-transit border.

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

> If this method would restrict the scope of applicability of ingress
> 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:
>  - the reliance on DNS.

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

>  - 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.

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


> 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).

(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.

> ==> 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.

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.

> 4.4     Packet rewriting at exit router

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

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

> ==> 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.

- 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.

> 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.

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