Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]]

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 22 May 2003, Iljitsch van Beijnum wrote:
> >  - being able to switch ISP's without renumbering: 1), 3.2), maybe 
> > others
> >  - redundancy due to link failures etc.: 1), maube 2), maybe 3)
> >  - connection survivability (internal connections, external 
> > connections)
> > 1), 4), maybe some of 3)
> >  - more fine-grained (ie. not 50/50) inbound traffic engineering: maybe
> > 1), 2)
> >  - the maximum frequency of ISP (=prefix) changes: 1), maybe some of 3)
> 
> Ok, let's have a look here.
> 
> First of all, what is "switching" ISPs? 

Having a PI address which is globally reachable: not having to change 
addresses used by hosts in your site if you wish to change your network 
service provider.

> Dropping an existing ISP should 
> be trivial: just disconnect and stop your routers from advertising the 
> prefix. This should work well even with current implmentations because 
> IPv6 applications are reasonably smart in trying several addresses 
> until they find one that works. (They have to try v6 and fall back to 
> v4 anyway, so multiple v6 isn't that much more work.) Adding a new ISP 
> isn't all that hard either: add connectivity, start prefix 
> announcements and change the DNS.

Uh, oh.  It isn't as simple as that, and gets even more complicated the
bigger the site becomes.  I can the required operations in my home network
manually in 10-15 minutes, maybe; and I have just one router and a few
computers.

But I'm not as optimistic about bigger sites..
 
> There is one caveat, though: access filters. More on that later.
> 
> And obviously all of this assumes you can work with multiple ISPs to 
> start with. That means either hosts know how to select the right source 
> address (in practice that means they must have a routing table) or 
> source address dependent routing. NAROS or something similar could help 
> here for traditional multiaddressing. Note that source address 
> dependent routing (SADR) is superior as this survives routing changes 
> where a certain destination is suddenly preferred over ISP 2 rather 
> than ISP 1. 

Indeed.

> Without SADR your session dies. Loc/id can solve this with 
> heuristics and/or rewriting source addresses at egress, which is of 
> course even better.

I'm not sure how loc/id could solve this (by guessing to try another 
locators when one doesn't get acks, I suppose), but no matter.
 
> The same thing but worse happens when a link or ISP fails. Only loc/id 
> can save your ongoing sessions then. 

Nope.  Heard of "multihoming at site-exit routers"?

Of course, this doesn't help you if the whole ISP melts down (and not just 
their border router towards you or whateveR).  But that's IMO such a rare 
occurrence with real ISP's that you shouldn't be too worried.

> There are many ways to traffic engineer. Something like NAROS that also 
> looks at the destination address would be a good way. Selectively 
> dropping TCP SYNs to get hosts to connect over the other line would be 
> another. With loc/id + SADR we are in traffic engineering heaven as it 
> becomes possible to load balance a single session over more than one 
> ISP.

I'd like to agree that the traffic engineering with more specific route 
advertisements is rather lousy tool at best.. but the options seem to be 
to do it with that way or in the application layer (with some 
application-specific intelligence and redirection) at the moment..
 
> If we do loc/id in the host firewalls have a hard time seeing who 
> packets are really coming from. Who they are going may also be a 
> problem but this one should be solvable as you can control the 
> who<->where mapping in your own site, but obviously there is no way to 
> know about this for the entire net. 

Agree.

> And even if we don't do loc/id, 
> filtering on remote addresses is evil as it makes renumbering virtually 
> impossible.
> 
> But do we really need the option of filtering on remote addresses?

Maybe not -- but on on remote identities -- might be useful.

One thing is sure: network managers won't want to relinquish security 
control of their nets to the hosts, or host operating systems.  This may 
be mitigated by the new distributed end-host firewalls WG, though -- but I 
haven't had time to look at the direction they're heading.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings