Is multihoming hard? [was: DNS amplification]

Thu Mar 21 03:07:06 UTC 2013

Joe Abley wrote:

> In practice, it seems to me that the way people multi-home
> these days for client-filled networks is:
> 
> 1. Number everything internally using private-use addresses
> 2. Use one NAT per upstream
> 3. Send your outbound flows through whichever NAT seems appropriate

Very reasonable approach.

But, how to choose the proper NAT is still a problem.

If there were standard home/site IGP supported by NAT boxes, to
which ISPs tell ASPATHLEN as metric, it could help a lot.

However, because packets are hot potatoes, ISPs are motivated
to tell something larger than ASPATHLEN as the metric, unless
they are legally ("MUST" phrase in IETF standards could be)
forced not to do so.

> There seem to be no shortage of SMB appliances that will take
> care of this for you without you having to understand anything.
> The phrase that seems to be used when describing these routers is
> "dual WAN".
> 
>    https://www.mushroomnetworks.com
>    http://www.peplink.com/balance/
>    http://www.tp-link.com/
>    http://www.draytek.com/
> 
> It's trivial to configure this kind of thing on more general-purpose
> gear too, obviously, but that requires Actual Knowledge of How
> Things Work whereas these products aim to get things running
> without any of that.
> 
> This style of multi-homing is invisible from the perspective of
> the routing system.

That is the correct thing to do.

> Obviously this doesn't work nicely for
> inbound connections, but the fact that people do it anyway
> suggests that isn't a deal-killer

That is a problem MUST be solved by transport (or, at least
application) layer of end systems to be able to handle
multiple public addresses.

It's not very difficult to modify TCP to accept packets with
multiple source addresses and send to multiple destination
addresses, if the addresses are carried with TCP optional
header of SYN and SYNACK packets.

Moreover, you can run SMTP and DNS servers with multiple
public addresses, because clients are, though at the
application layer, implemented to try all the public
addresses of servers, even though they are tried only after
transport layer time outs.

> (presumably every server
> that needs to accept an inbound connection these days lives
> elsewhere, in someone's cloud).

It partially because of the current difficulty to have
multihoming.

But, unless having an entry in DFZ is somehow appropriately
taxed, the number of data centers to offer such cloud will
increase.

The fundamental economical problem of routing table bloat
today is that one can multihome with its own DFZ routing
table entry without paying anything to all the ISPs and
other entities who must pay for enough resources to
support the bloating DFZ routing table.

					Masataka Ohta

> I'm not suggesting this is good architecture,

Yes, it is.

> I think it's incorrect to insist that the Network doesn't
> support pervasive end-site multi-homing when it's clear
> that people are doing it anyway.

Fully agreed.

					Masataka Ohta