Subject: Re: Why people by NATs

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Dec 2004 13:19:15 +0100

On 1-dec-04, at 1:06, Stephen Sprunk wrote:

> With v6 we have the ability to fix this; through some magic function, 
> users should be able to get a PA (at a minimum) subnet behind their 
> local router/modem/whatever and have a decent interface to configure 
> inbound filters, similar to how they can configure evil NAT 
> port-forwarding today.

So what's the use of a firewall when the boxes behind it get to 
configure it? If these boxes know what they should and shouldn't accept 
from the evil internet in the first place, isn't it much easier to 
accept/reject packets as per this knowledge?

>> A default filter that rejects packets for services that are generally 
>> intended for local use only would probably be good enough for a 
>> residential IPv6 router. Other services are either not enabled and/or 
>> firewalled in the host anyway, or the user actually wants them to 
>> work.

> Default filters are a pain, because inevitably they end up blocking 
> something that's useless today but a critical need tomorrow...  For 
> instance, my @#%#^& Linksys not only doesn't understand native IPv6 
> (hello, wake up Cisco!) but it even blocks IP-in-IP packets so I can't 
> use an IPv6 tunnel.

Please reread. I said services that are generally intended for local 
use. Unknown services can't be presumed to be intended for local use 
and are thus not filtered by such a policy. Ideally, I wouldn't want to 
filter anything, but systems like Windows come with all kinds of 
services enabled that you really don't want to expose to the whole 
world, but at the same time you want (some of) these services to be 
available for local use.

> At a minimum, vendors should document _everything_ the default filter 
> does and allow the user to disable it if necessary.

Of course. The funny thing is that NAT can generally not be disabled by 
the user.  :-)  :-(

Note that a default stateful filter is much more harmful than filtering 
out some obvious stuff such as SMB as you need to make specific 
exceptions or use strange tricks in the application to allow incoming 
sessions, for ALL protocols that use those.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Dec 2004 13:04:08 +0100

On 1-dec-04, at 1:17, Stephen Sprunk wrote:

>> So _if_ IPv6 PI space is going to be a reality, we should do what we 
>> can to limit the damage. The only way to do this is to make it 
>> possible to filter out the PI prefixes at least in certain parts of 
>> the network without getting in the way of reachability.

> That's not the only solution -- just the most obvious one.  Clearly, 
> if IPv6 PI space spirals out of control like many operators think will 
> happen, we need to find a way to make BGP (and possibly forwarding) 
> performance not dependent on the number of prefixes in the table.  
> There's many ways to skin that cat, and maybe it's time we start 
> looking at that in parallel to the work on multi6 and HIP.

One obvious way to improve BGP would be to work per-AS rather than 
per-prefix. We could even go so far as to remove the entire 
prefix-to-AS mapping from BGP and do this out of band, as this mapping 
is fairly static, and it's much easier to secure it this way. 
Unfortunately, this mostly helps with ASes that source many prefixes, 
but it doesn't help much when the number of prefixes per AS is small 
(which is what we expect in IPv6). Another interesting improvement 
would be "bitmap routing" where a bunch of PI blocks are grouped 
together into a large aggregate and an accompanying bitmap that 
indicates whether a specific prefix within that aggregate is reachable 
or not. This would save a lot of memory and allow for vector based BGP 
processing.  :-)

But all of this is only delaying the inevitable (not that that can't be 
useful sometimes): at some point, we need to move away from the premise 
that all default-free routers must know about all reachable prefixes. 
With this ball and chain removed we can start looking at new 
interdomain routing paradigms, such as an idr link state protocol that 
can function in a never fully converged state. (Which would make for 
some nice PhD work...)

> Worst case is we'll end up eliminating IP addresses as locators and 
> build another layer beneath IP (and thus transparent to TCP) that 
> actually handles routing, at least in the DFZ.  In some sense we 
> already have a foundation for that with MPLS, but we'd need to 
> hack/replace BGP to make the new layer scale across ASes.  Or perhaps 
> we'll find a way to route based on ASNs in the DFZ, and the mapping 
> from destination IP to ASN will be made only at the edge of the DFZ.

MPLS can save you a bunch of router hops, but it doesn't really change 
anything because you still need a router at both ends of the MPLS 
cloud. Currently, the most efficient way to move packets to/from random 
systems across organizations et al is IPv6. Moving to a new 
internetworking layer is going to take A LOT of time. Even tunneling is 
non-trivial because of the destination to tunnel endpoint mapping 
that's required. In essence, doing something like this would be 
starting multi6 from scratch. The whole point of my message (and one of 
the points of Margaret's message that started the thread) was that 
operators don't want to wait for multi6 and/or want provider 
independence anyway.

So we're back at: how do we limit the fallout from PI in IPv6, and 
without significant protocol work at that? I understand that Tony Hain 
has asked / will ask for a BoF in this area at the next IETF meeting. 
Hopefully this will lead to something.

---

From: Simon Leinen <[email-masked]>
Date: Thu, 02 Dec 2004 09:54:25 +0100

Iljitsch van Beijnum writes:
> But all of this is only delaying the inevitable (not that that can't
> be useful sometimes): at some point, we need to move away from the
> premise that all default-free routers must know about all reachable
> prefixes.

But isn't this the *definition* of a default-free router?

Maybe you mean we need to move away from the premise that you have to
run default-free ("full BGP table!") to be taken seriously.

(Maybe I'm just bitter because our network runs with "only" 26783 IPv4
 BGP routes (and two defaults), so I cannot play with the big guys. :-)

> interdomain routing paradigms, such as an idr link state protocol
> that can function in a never fully converged state. (Which would
> make for some nice PhD work...)

There's lots of exciting new work about loop prevention in link-state
internal routing protocols right here in the IETF - check out
http://rtg.ietf.org/wg/rtgwg/ .  Maybe some of this could be leveraged
for a new external routing protocol.

(Not that I think that it will be likely that we move from BGP to an
entirely new protocol without replacing all current IDR players... but
that doesn't mean you shouldn't try :-).
-- 
Simon.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Dec 2004 13:11:00 +0100

> But isn't this the *definition* of a default-free router?

That's my point. We need to find some middle ground between using a 
default and having every single prefix in the world in the table.

> run default-free ("full BGP table!") to be taken seriously.

Who cares about being taken seriously?  :-)

No, that's not it. A default doesn't do any good because the only thing 
it does is move the packets to a place where full routing information 
is known. Obviously today some people run defaultless because they can 
and not because they must, but there are also lots of routers that run 
defaultless because there is no smarter router they can dump the 
traffic on.

> http://rtg.ietf.org/wg/rtgwg/

I don't see anything except web design with broken assumptions...

But correct me if I'm wrong, current link state routing protocols 
already know how to get rid of loops...?

> Maybe some of this could be leveraged for a new external routing 
> protocol.

> that doesn't mean you shouldn't try :-).

A new EGP needs to be able to work with BGP so there is no need for 
everyone to upgrade at the same time. But even then it won't be easy as 
network operators are a conservative bunch (much more so than they 
think they are). Most of all, a new EGP needs to bring compelling 
benefits to the table.