Subject: BALTS: Better At Least Than Singlehomed

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Feb 2002 16:53:01 +0100 (CET)

Since "the" solution seems more elusive than ever, maybe this is the time
to get a "better than nothing" effort off the ground.

The idea is very simple: when everything is working, send regular packets
and do everything just like in a single homed environment.

As soon as the source host learns it can no longer send information to the
destination host using regular means, it starts encapsulating the packets
into IP packets. It then transmits these packets using a different source
interface, gateway and/or destination address. The exact interface,
gateway and destination address choices are determined by local
configuration or heuristics.

At the destination address, the packets are de-encapsulated and processed
like regularly received packets.

In essence, this means creating on demand dynamic tunnels.

A good way to publish secondary addresses would be in a new resource
record in the ip6.int domain, or as an IP option in the first packet of a
stream.

The main problem would be detecting failures. If source address filtering
is configured correctly (or rather: in the way that suites us best) local
link failures will generate a "administratively blocked" ICMP message,
which can be used to trigger a change of source adddress. Host
unreachables can trigger a change of destination address, but there are
many failure modes that fail to provide these.

Advantages:

* simple
* changes limited to IP layer, no higher layer changes necessary
* a lot of potential for improvement down the road

Iljitsch van Beijnum

---

From: Daniel Hagerty <[email-masked]>
Date: Mon, 11 Feb 2002 11:15:29 -0500

> like regularly received packets.

    Your proposal is missing a "security" analysis.  If you spend a
few moments on that, you're going to note some "issues" with this
approach.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Feb 2002 09:25:43 +0100 (CET)

First, thanks to all for replying so quickly.

> few moments on that, you're going to note some "issues" with this

If a system de-encapsulates tunnelled packets without prior tunnel
configuration, this could be used by attackers to bypass firewalls. This
can be remedied by either:

1. Disallow the encapsulation protocol, so tunnelled packets can't enter
   (or leave) the system,

2. De-encapsulate incoming packets first, then apply filters / first apply
   filters and then perform the multihoming processing for outgoing
   packets, or

3. Look inside the encapsulating packet and apply filter rules to the
   encapsulated packet.

Discovery of the backup address through the DNS wouldn't be as secure as
it could be, but since single homed communication depends on the DNS in
the first place, I don't see this as a fatal flaw.

A good later addition would be a mechanism for hosts to determine the
reachability status and other information (such as backup addresses)
dynamically and in a secure way.

Did you have any other issues in mind?

Iljitsch van Beijnum