Re: Lazy network operators
preventing DDoS and IP source address forgery each also break what the IAB calls "the end-to-end model".
How so?
I was thinking of RFC 1958: An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. While this is given as an argument in favour of datagrams (vs. circuits) as the best transport model, any stateful NAT or firewall violates it, any router or loadbalancer flow-quota violates it, and pretty much anything that can be done to protect against DDoS violates it. I misspoke when I said that preventing IP source address forgery violates it.
(dunno if you heard, but in spite of 128 bits of address space, the enterprise user community is now asking for IPv6 NAT.)
I hadn't, pointer please?
<http://www.acu.rl.ac.uk/msn2003/Talks/TimChown.pdf> comes to mind. but moreso the folks looking at deployment who absolutely don't want another IPv4-like lockin, where provider-assigned addresses mean a huge renumbering effort in order to change upstreams, and the expectation that globally routeable address blocks will not be available, or will not be cost effective, for enterprise or small-ISP use. nowadays ietf is working on what they call NAT-PT as a "transition" strategy, with a new set of heads stuffed into the same old sand, whereby the designers think that network owners are only going to use it until the ipv6 transition is complete. it ain't so. ipv4 CIDR was absolutely necessary to grow the internet, and the wayback designers who thought that 12 million class C nets could ever have been instantiated and routed were obviously not thinking about scale. but ipv4 CIDR also had the effect of making end users fear their provider- assigned IP addresses, and the real incentive for ipv4 NAT deployment wasn't a lack of ipv4 address space but rather a lack of interest in provider-assigned ("lockin") addressing. it's still quite astounding to me that when we finish deploying ipv6 we'll still have provider assigned addresses that customers are afraid to use beyond the edge of their campus, and we'll still have the age-old tension between "i could get global routing for that address block" and "i could qualify with my RIR to obtain that address block (and afford the fees)". anyway, there will absolutely be NAT in ipv6 enterprise networks, but the reason for it won't be a shortage of globally unique address space.
On Fri, 16 Apr 2004, Paul Vixie wrote:
preventing DDoS and IP source address forgery each also break what the IAB calls "the end-to-end model".
How so?
I was thinking of RFC 1958:
An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network.
While this is given as an argument in favour of datagrams (vs. circuits) as the best transport model, any stateful NAT or firewall violates it, any router or loadbalancer flow-quota violates it, and pretty much anything that can be done to protect against DDoS violates it.
"Protect" is an absolute term. Do you mean, "eliminate completely"? That is obviously an impossibility with or without state-based mechanisms. On the other hand, we've had DDoS prevention mechanisms (based on multiple rate-limiters, for different kinds of packets) deployed for over 6 months now. They seem to work just fine, are always active, and require no state in the network. The biggest problem is obviously ensuring that the rate-limiter does not starve (too badly) the legitimate users of the same class. Having multiple classes helps with that, but will likely be less effective when the attackers get smarter to choose attacks which are indistinguishable from mainstream applications. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 16-apr-04, at 8:47, Paul Vixie wrote:
preventing DDoS and IP source address forgery each also break what the IAB calls "the end-to-end model".
How so?
I was thinking of RFC 1958:
An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network.
While this is given as an argument in favour of datagrams (vs. circuits) as the best transport model, any stateful NAT or firewall violates it, any router or loadbalancer flow-quota violates it, and pretty much anything that can be done to protect against DDoS violates it.
To quote Steve Deering: there is good state and there is bad state. State that is created by looking at the actual communication and then recreated when it's lost isn't necessarily evil. (Although I agree that when this stuff is taken too far it breaks e2e, for instance a Pix that will happily chop off part of a DNS packet when it decides said packet is too long.)
(dunno if you heard, but in spite of 128 bits of address space, the enterprise user community is now asking for IPv6 NAT.)
I hadn't, pointer please?
<http://www.acu.rl.ac.uk/msn2003/Talks/TimChown.pdf> comes to mind.
Ok, you won't hear me say that Tim doesn't know what he's talking about... But this can mean all kinds of things, ranging from "everyone will use NAT with IPv6" to "there is probably a misguided soul or two who will try this".
but moreso the folks looking at deployment who absolutely don't want another IPv4-like lockin, where provider-assigned addresses mean a huge renumbering effort in order to change upstreams, and the expectation that globally routeable address blocks will not be available, or will not be cost effective, for enterprise or small-ISP use.
Yes, this is a problem. I'm not sure NAT is the solution, though. I mean, if you're going to use NAT, why switch to IPv6 in the first place?
nowadays ietf is working on what they call NAT-PT as a "transition" strategy, with a new set of heads stuffed into the same old sand, whereby the designers think that network owners are only going to use it until the ipv6 transition is complete.
Unless I'm very much mistaken, this transition mechanism translates from IPv6 to IPv4 and vice versa, NOT from IPv6 to IPv6.
it's still quite astounding to me that when we finish deploying ipv6 we'll still have provider assigned addresses that customers are afraid to use beyond the edge of their campus, and we'll still have the age-old tension between "i could get global routing for that address block" and "i could qualify with my RIR to obtain that address block (and afford the fees)".
IETF multi6 wg is working on this problem. Hopefully it's possible to come up with something that offers both scalability and functionality, as current PI and PA paradigms each only offer one.
On Fri, 16 Apr 2004, Paul Vixie wrote:
it's still quite astounding to me that when we finish deploying ipv6 we'll still have provider assigned addresses that customers are afraid to use beyond the edge of their campus, and we'll still have the age-old tension between "i could get global routing for that address block" and "i could qualify with my RIR to obtain that address block (and afford the fees)".
anyway, there will absolutely be NAT in ipv6 enterprise networks, but the reason for it won't be a shortage of globally unique address space.
Hmmm, or rather, there just wont be any demand for IPv6 deployment, at least from the edges (consumers, small/medium networks). Why bother changing if, despite the (almost indefinitely) availability of sparse address space, one can not claim a tiny piece as ones' own? Which is IPv4's only problem, at least as seen from the edges. Provider independence (to some degree, even by DNS A6 or otherwise) for all should have been IPv6's biggest selling point. It doesnt have it, judging by multi6 it's not likely it ever will, and hence it's similarly unlikely there ever will be any real demand for v6. (i write this hoping it won't be so, but i'm not very optimistic about it). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: consultant, n.: Someone who knowns 101 ways to make love, but can't get a date.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-04-18, at 01.10, Paul Jakma wrote:
Hmmm, or rather, there just wont be any demand for IPv6 deployment, at least from the edges (consumers, small/medium networks). Why bother changing if, despite the (almost indefinitely) availability of sparse address space, one can not claim a tiny piece as ones' own? Which is IPv4's only problem, at least as seen from the edges.
I think you will find that this varies a lot from region to region. There is no drive or need for it in the US, there is slightly more interest in Europe. But in Asia you will find that their scaling problem is completely different. I believe there will be a change. If it will be IPv6 as we know it today, that remains to be seen. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQIJadqarNKXTPFCVEQLuBACfZ6nPHPsCoYQaH/X9OzCF87WuhaQAn3nj FL/3cLcTZyZPIVmV0QXK/hF/ =VsLH -----END PGP SIGNATURE-----
participants (5)
-
Iljitsch van Beijnum -
Kurt Erik Lindqvist -
Paul Jakma -
Paul Vixie -
Pekka Savola