Handling multiple connections

[Paul Wouters]

On Sun, 29 Apr 2007, Harald Welte wrote:

> oh, you want to do per-application based policy routing? that's
> certainly a non-trivial task to do.  Nothing that I think openmoko would
> be able to look into for at least the next six months.

> which network packets to route to where, and which connections to accept
> and which not is the job of the kernel network stack.  We have _tons_ of
> tools to do stateful packet filtering, policy routing, traffic shaping,
> and combinations thereof (e.g. you can do stateful routing, selecting a
> route at connection startup time).

Some of this is being specified now by the IETF BTNS working group (and
in some sense, the pki4ipsec working group).

Though this is somewhat ipsec specific, it does specify things like channel
binding, and upgrading authentications on existing connections.

> > API, where the app can finetune which connection properties it needs.
> > (It might even go so far: "I need a long running connection", "I need
> > a connection with maximum bandwidth", ...)
>
> I don't think the applications should care about this.  This is

Some of them might want to, particularly "don't connect to X without encryption".
But it is probably enough to block the applications from sending the plaintext
traffic, which can be done without changing the applications themselves.

> Somehow, the user-defined preferences/policies need to be translated in
> policy routing and packet filtering configuration.  This policy is
> always present, and does not require any special application support.

As you say too :)

> If you want to interactively permit/route/... connections, then this
> will most likely need to be done via NFQUEUE mechanisms.  You can QUEUE
> all packets that connection tracking deems NEW, and then return a
> verdict into the kernel.  I believe this is how e.g. the NuFW personal
> firewall handles this.

I know for IPsec with NETKEY, this does not work (yet), as it is missing
packet caching for when the connection isn't up yet (because the packet
actualy triggered the tunnel-establishment)

> Thus, I argue that any such connection policy implementation
> a) does not depend on explicit application support but works with all
>    existing applications, without modifying them, system libraries or
>    kernel code
> b) uses existing infrastructure such as iproute2/tc/iptables/NFQUEUE
> c) uses files in the filesystem to specify the policies
> d) will have some userspace management daemon and/or control programs
>    storing the policies.
> e) application packages (ipk's) just provide a policy file with the
>    default policy

Agreed.

Paul