Re: mh (RE: OMB: IPv6 by June 2008)
At 03:51 PM 7/7/2005, David Andersen wrote: On Jul 7, 2005, at 3:41 PM, Andre Oppermann wrote: Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. Yes, but keep in mind that this benefit is completely unrelated to NAT's purpose as an address space extender. A stateful firewall with a very simple rule (permit anything originated from the inside, deny anything from outside except a few pesky protocols) would accomplish exactly the same goal. Indeed, the fact that most NAT implementations combine the address translation with stateful inspection (given it's the simplest way to implement NAPT, IMO), this is the case. And it would be much easier to punch holes through when you needed to. No, it's the same. With a stateful inspection firewall operating as a transparent bridge or as a router, you still need to specify which protocols, ports and addresses to permit. It's exactly the same. From my perspective, the biggest benefit from home NAT devices is that they were a vehicle for delivering such a firewall to millions of windows boxes. Unfortunately, this drug comes with a number of harmful side effects, including nausea, blurred vision, and the inability to deploy a number of new protocols. The inability to deploy new protocols is exactly the same in many cases for a stateful inspection box on public addresses vs. a stateful inspection box doing NAT. The firewall must be aware of the protocol to permit it at all, and if there's going to be any hope of protecting the less secure equipment behind, those firewall devices must understand the details of the protocol. That still requires the vendor to do work. Yes, the address translations still add another layer of trouble in that passing endpoint identifiers (which unfortunately are the same as IP addresses, given a lack of a host identification mechanism other than IP address) creates problems for protocol developers. However in most cases a good protocol design can be arrived at which does not run into these difficulties. Such ideas were documented some time ago by the IETF NAT WG as information to protocol designers.
Re: mh (RE: OMB: IPv6 by June 2008)
On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: And if you still want the protection of NAT, any stateful firewall will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Anyone with a pointer to an *in depth* explanation somewhere of why that assumption is invalid can mail it to me off list, and I'll shut up. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote:
On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote:
And if you still want the protection of NAT, any stateful firewall
will do it.
That seems a common viewpoint.
I believe the very existence of the Ping Of Death rebuts it.
A machine behind a NAT box simply is not visible to the outside world,
except for the protocols you tunnel to it, if any. This *has* to
vastly reduce it's attack exposure.
Not really. Consider the logic in a NAT box:
if (state table entry exists for packet) {
translate_header();
send();
} else {
drop();
}
and the logic in a stateful firewall:
if (state table entry exists for packet) {
send();
} else {
drop();
}
This is *exactly* the core of what a NAT does, minus the header
mangling. The ping of death exposure, for instance, is identical in
both cases: The way to ping of death someone is to find a valid state
table entry and exploit it (e.g., if you could do a PoD in reverse by
using a too-large ICMP reply, and first convince the victim to ping
you).
Configuration options can change the behavior of either, e.g.,
configuring an internal host to be the DMZ host on a NAT, which
changes the logic to:
if (state table) ...
else
send_to_dmz_host();
The equivalent operation on a stateful firewall is a permit rule. A
stateful firewall can expose more internal hosts to the outside than a
NAT with only one IP address, simply because it can have more
addressable space to use (if you've only got one IP address, there's
only one person who can receive pings). But in general, the two are
nearly identical, by virtue of the state table check.
-Dave
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 8, 2005, at 9:49 AM, Jay R. Ashworth wrote: A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. It is true that the exposure is reduced, just as it is with a stateful firewall. The technical term for this is security by obscurity. Being obscure, however, is not the same as being invisible or being protected. It just means that you're a little harder to hit. When a NAT sets up an association between an inside and outside address+port pair, that constitutes a bridge between the inside device and the outside world. There are ample attacks that are perpetrated through that association. A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. It is able to use TLS, SSH, etc as transport layer solutions, but those are subject to attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on, and SSH also has a windowing problem (on top of TCP's window, SSH has its own window, and in large delay*bandwidth product situations SSH's window is a performance limit). In other words, a NAT is a man-in-the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks.
Re: mh (RE: OMB: IPv6 by June 2008)
On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote: On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote: On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: And if you still want the protection of NAT, any stateful firewall will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Not really. Consider the logic in a NAT box: [ ... ] and the logic in a stateful firewall: Sorry. Given my other-end-of-the-telescope perspective, I was envisioning an *on-machine* firewall, rather than a box. Clearly *any* sort of box in the middle helps in the fashion I alluded to, whether it NATs or not. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: mh (RE: OMB: IPv6 by June 2008)
On 8-jul-2005, at 19:34, Fred Baker wrote: A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. It is able to use TLS, SSH, etc as transport layer solutions, but those are subject to attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on, and SSH also has a windowing problem (on top of TCP's window, SSH has its own window, and in large delay*bandwidth product situations SSH's window is a performance limit). In other words, a NAT is a man-in- the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. :-) A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks. I of course couldn't resist, so: ! ipv6 access-list out-ipv6-acl permit ipv6 any any reflect state-acl ! ipv6 access-list in-ipv6-acl evaluate state-acl deny ipv6 any any log ! (don't try this at home, kids: that deny any is dangerous because it blocks neighbor discovery) Unfortunately, IPsec (ESP transport mode) isn't allowed back in: %IPV6-6-ACCESSLOGNP: list in-ipv6-acl/20 denied 50 2001:1AF8:2:5::2 - 2001:1AF8:6:0:20A:95FF:FEF5:246E, 29 packets On second thought: how could it? The SPIs for outgoing and incoming packets are different. I suppose it would be possible for the stateful filter to snoop the ISAKMP protocol and install filter rules based on the information found there, but that's obviously not what happens.
Re: mh (RE: OMB: IPv6 by June 2008)
Jay R. Ashworth wrote: On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote: On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote: On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote: And if you still want the protection of NAT, any stateful firewall will do it. That seems a common viewpoint. I believe the very existence of the Ping Of Death rebuts it. A machine behind a NAT box simply is not visible to the outside world, except for the protocols you tunnel to it, if any. This *has* to vastly reduce it's attack exposure. Not really. Consider the logic in a NAT box: [ ... ] and the logic in a stateful firewall: Sorry. Given my other-end-of-the-telescope perspective, I was envisioning an *on-machine* firewall, rather than a box. Clearly *any* sort of box in the middle helps in the fashion I alluded to, whether it NATs or not. Now I'm confused. Who runs *on-machine* NAT? I guess that's another nice option for firewalls. It doesn't matter whether your firewall runs locally or on a remote gateway. Also, when people here are talking about NAT, note that we are only talking about many-to-one, overloading, PAT, or whatever you want to call it. If you are using NAT pools or one-to-one NAT, it buys you no protection at all unless you add firewalling to the mix. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
Fred Baker wrote: [snip] A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. [snip] No, you can't use AH, but yes, you can use IPsec through NAT. See RFC3947 and RFC3948. But it is not pretty. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
On 7 Jul, 2005, at 21:10, Steven M. Bellovin wrote: Real firewalls pass inbound traffic because a state table entry exists. NATs do the same thing, with nasty side-effects. There is no added security from the header-mangling. To which Len Bosak quipped a few years ago: If you don't know its name, you can't curse it. Sean.
Re: mh (RE: OMB: IPv6 by June 2008)
On 8 Jul, 2005, at 18:34, Fred Baker wrote: A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. Only if you define IPSEC narrowly as AH in order to justify this claim. There are at least two interesting differences between a NAT and a stateful firewall deployed in front of hosts with permanent public address space. The first involves attackers knowing the topological name of a victim who may be unshielded by the firewall during narrow windows offered by the implementation, its operators, or both in combination. The second involves a predictable rendezvous point for covert communications channels. Not all NATs protect against these classes of attack, however an implementation that assigns inside-outside mappings with reasonable randomness will. One which also breaks connections on failures (by invalidating existing mappings) is more fail-safe than one that tries to preserve existing state across crashes or fat-fingerings. People who don't make use of an interoperable and well understood session protocol resilient against this variety of failure in connection-oriented transport communications (identity/locator binding invalidation) will probably disagree as their various long- lived sessions terminate abnormally... Applications-layer protocol writers without a session layer would also have to worry about: attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on Planned renumbering may as a side effect result in all of the three such attacks you explicitly listed. They may also be flummoxed by having to invent a session layer for an application that really wants one, leading to reinventing previously discovered gotchas like in large delay*bandwidth product situations SSH's window is a performance limit Finally: In other words, a NAT is a man-in-the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks. The men in the middle are the I* officers who have refused for more than a decade to admit they don't know everything, that market forces are not always driven by evil doing architectural impurists with nothing to teach their elders (which is incongruous with early I* tensions with the former CCITT), or that they have their heads buried neck deep in NIH kitty litter (ditto). A NAT is a tool many people find useful enough to deploy, maintain and even pay money for, despite the ready availability of substitutable tools, and The IP (both flavours) network and transport layers are very badly designed with respect to host renumbering. Renumbering has been a fact of life since before the early 90s. There is no as-widely- promoted-as-TCP session layer to help mitigate renumbering's effects. There is also institutional resistence to fixing this aspect of the design of the N+T layers in I*. So, people who have actually deployed and run networks where renumberings happen, deployed NATs simply because that was one of the only solutions readily and mostly interoperably available to them. It is unsurprising that the voluntary standards organization dominated by people who have fought against technology to cope with (or even embrace) live renumbering is likewise ridden with loudmouths who call NATs attacks. What is it exactly that NATs attack, Fred? Sean.
Re: mh (RE: OMB: IPv6 by June 2008)
On 8 Jul, 2005, at 18:34, Fred Baker wrote: A NAT, in that context, is a stateful firewall that changes the addresses, which means that the end station cannot use IPSEC to ensure that it is still talking with the same system on the outside. Only if you define IPSEC narrowly as AH in order to justify this claim. There are at least two interesting differences between a NAT and a stateful firewall deployed in front of hosts with permanent public address space. The first involves attackers knowing the topological name of a victim who may be unshielded by the firewall during narrow windows offered by the implementation, its operators, or both in combination. The second involves a predictable rendezvous point for covert communications channels. Not all NATs protect against these classes of attack, however an implementation that assigns inside-outside mappings with reasonable randomness will. One which also breaks connections on failures (by invalidating existing mappings) is more fail-safe than one that tries to preserve existing state across crashes or fat-fingerings. People who don't make use of an interoperable and well understood session protocol resilient against this variety of failure in connection-oriented transport communications (identity/locator binding invalidation) will probably disagree as their various long- lived sessions terminate abnormally... Applications-layer protocol writers without a session layer would also have to worry about: attacks on TCP such as RST attacks, data insertion, acknowledge hacking, and so on Planned renumbering may as a side effect result in all of the three such attacks you explicitly listed. They may also be flummoxed by having to invent a session layer for an application that really wants one, leading to reinventing previously discovered gotchas like in large delay*bandwidth product situations SSH's window is a performance limit Finally: In other words, a NAT is a man-in-the-middle attack, or is a device that forces the end user to expose himself to man-in-the-middle attacks. A true stateful firewall that allows IPSEC end to end doesn't expose the user to those attacks. The men in the middle are the I* officers who have refused for more than a decade to admit they don't know everything, that market forces are not always driven by evil doing architectural impurists with nothing to teach their elders (which is incongruous with early I* tensions with the former CCITT), or that they have their heads buried neck deep in NIH kitty litter (ditto). A NAT is a tool many people find useful enough to deploy, maintain and even pay money for, despite the ready availability of substitutable tools, and The IP (both flavours) network and transport layers are very badly designed with respect to host renumbering. Renumbering has been a fact of life since before the early 90s. There is no as-widely- promoted-as-TCP session layer to help mitigate renumbering's effects. There is also institutional resistence to fixing this aspect of the design of the N+T layers in I*. So, people who have actually deployed and run networks where renumberings happen, deployed NATs simply because that was one of the only solutions readily and mostly interoperably available to them. It is unsurprising that the voluntary standards organization dominated by people who have fought against technology to cope with (or even embrace) live renumbering is likewise ridden with loudmouths who call NATs attacks. What is it exactly that NATs attack, Fred? Sean.
Re: mh (RE: OMB: IPv6 by June 2008)
On Fri, Jul 08, 2005 at 10:24:22PM +0100, Sean Doran wrote: On 7 Jul, 2005, at 21:10, Steven M. Bellovin wrote: Real firewalls pass inbound traffic because a state table entry exists. NATs do the same thing, with nasty side-effects. There is no added security from the header-mangling. To which Len Bosak quipped a few years ago: If you don't know its name, you can't curse it. Sure you can. For a human entity, get a few hairs from its head or nail clippings. For a network entity, get the bits of its externally visible IP address. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: mh (RE: OMB: IPv6 by June 2008)
On 2005-07-07, at 10:10, Kuhtz, Christian wrote: Anyone here care to share operator perspectives shim6 and the like? Do we actually have anything that anyone considers workable (not whether somebody can make it happen, but viable in a commercial environment) for mh? There is no operational or implementation experience with shim6 at this time, that I know of (the technical specifications for shim6 are currently incomplete). The shim6 working group has its first meeting in August in Paris, after which the goal is to progress quickly to a set of specifications which can be implemented. As an easy-to-read overview of the shim6 approach, the following rough draft may be useful: http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt Joe
RE: mh (RE: OMB: IPv6 by June 2008)
From: Joe Abley [mailto:[EMAIL PROTECTED] On 2005-07-07, at 10:10, Kuhtz, Christian wrote: Anyone here care to share operator perspectives shim6 and the like? Do we actually have anything that anyone considers workable (not whether somebody can make it happen, but viable in a commercial environment) for mh? There is no operational or implementation experience with shim6 at this time, that I know of (the technical specifications for shim6 are currently incomplete). The shim6 working group has its first meeting in August in Paris, after which the goal is to progress quickly to a set of specifications which can be implemented. As an easy-to-read overview of the shim6 approach, the following rough draft may be useful: http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. To me, this is still a glaring hole as it has been for years now and nobody seems to be making any fundamental progress here. Partially probably because the deck seems to be fundamentally stacked against mh, which doesn't appear to have been a design criteria in the first place. Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 7, 2005, at 1:09 PM, Kuhtz, Christian wrote: As an easy-to-read overview of the shim6 approach, the following rough draft may be useful: http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. To me, this is still a glaring hole as it has been for years now and nobody seems to be making any fundamental progress here. Partially probably because the deck seems to be fundamentally stacked against mh, which doesn't appear to have been a design criteria in the first place. I've been poking around with end-host / end-network multihoming at the transport and application layers. See, e.g., MONET, a multi-homed Web proxy designed to achieve high availability: http://nms.lcs.mit.edu/ron/ronweb/ In general, this kind of end-host informed multihoming has a lot of potential for improving availability and performance (because the end-points actually see what they're getting), but at the cost of some extra implementation complexity. The shim6 mechanism (in the general sense, not speaking to the specifics of shim6 negotiation, etc.), when augmented with some end-host smarts, could be a nice way to do end-host based multihoming in the ipv6 context. -Dave
RE: mh (RE: OMB: IPv6 by June 2008)
I've been poking around with end-host / end-network multihoming at the transport and application layers. See, e.g., MONET, a multi-homed Web proxy designed to achieve high availability: http://nms.lcs.mit.edu/ron/ronweb/ In general, this kind of end-host informed multihoming has a lot of potential for improving availability and performance (because the end-points actually see what they're getting), but at the cost of some extra implementation complexity. The shim6 mechanism (in the general sense, not speaking to the specifics of shim6 negotiation, etc.), when augmented with some end-host smarts, could be a nice way to do end-host based multihoming in the ipv6 context. But, isn't that just a host based approach in the end and not a solution for entire networks? And if it isn't for entire networks, why do I need any to any connectivity anyway? I know, there's nothing that prevents it (or any schema like it, including shim6) from being network to network, but, good grief, what a huge amount of overhead to design around a requirements flaw. This sort of Moebius strip logic that's used to explain/solve the problem which has been created is fun to watch, but really just sucks in the end. One could argue, however, that we don't need multihoming, we all need to pour money into CDNs for things we really care about and lets somebody else do the worrying. . And it all seems like such a hack. Hurray, network based services are back. The PSTN is dead, long live the PSTN. Argh. Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: mh (RE: OMB: IPv6 by June 2008)
Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. a shim layer seems like a promising enhancement. ietf-shim6 is taking an approach to a shim layer that will, I suspect, take some time to mature. I'd be surprised if it saw significant deployment anytime within the next 5 years, at the earliest. (a more ascerbic view would probably suggest that it is not even likely to produce a complete specification within that time, with deployment taking another 5 years...) the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: mh (RE: OMB: IPv6 by June 2008)
Dave, I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... $.02, - ferg -- Dave Crocker [EMAIL PROTECTED] wrote: [re: shim6] the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: mh (RE: OMB: IPv6 by June 2008)
Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. -- Andre
Re: mh (RE: OMB: IPv6 by June 2008)
I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... i think we are agreeing. i think that any prediction that users will not use nats for v6 involves logic that can, at best, be called idealistic. naive would be another term to consider. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
RE: mh (RE: OMB: IPv6 by June 2008)
Given that shim breaks fundamental assumptions about the stable relationship between the packet header and the application context, there will be many security related issues to be resolved after the shim spec stabilizes. Shim is a 'more than a decade' effort if it ever completes. The disappearance of NAT is not as bad as the FUD that keeps coming up. See: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt and please send comments if some use of NAT is not covered. As far as alternatives for multi-homing, the IESG has focused on shim and denied a request for a bof in August to discuss interim options. I submitted updates to the ID editor early last month but for some reason they have not popped out yet, but I am always accepting comments on: http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-08.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-08.txt Like the approach or not, it is straight up existing BGP and existing host stacks. It will never be the highly optimized 400 entry routing table, but it doesn't pretend to be. It does however create PI space that has some hope of aggregating. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Friday, July 08, 2005 4:12 AM To: Kuhtz, Christian Cc: Joe Abley; NANOG list Subject: Re: mh (RE: OMB: IPv6 by June 2008) Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. a shim layer seems like a promising enhancement. ietf-shim6 is taking an approach to a shim layer that will, I suspect, take some time to mature. I'd be surprised if it saw significant deployment anytime within the next 5 years, at the earliest. (a more ascerbic view would probably suggest that it is not even likely to produce a complete specification within that time, with deployment taking another 5 years...) the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: mh (RE: OMB: IPv6 by June 2008)
Andre Oppermann wrote: Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 7, 2005, at 3:41 PM, Andre Oppermann wrote: Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. Yes, but keep in mind that this benefit is completely unrelated to NAT's purpose as an address space extender. A stateful firewall with a very simple rule (permit anything originated from the inside, deny anything from outside except a few pesky protocols) would accomplish exactly the same goal. And it would be much easier to punch holes through when you needed to. From my perspective, the biggest benefit from home NAT devices is that they were a vehicle for delivering such a firewall to millions of windows boxes. Unfortunately, this drug comes with a number of harmful side effects, including nausea, blurred vision, and the inability to deploy a number of new protocols. -Dave
RE: mh (RE: OMB: IPv6 by June 2008)
Mangling the header did not prevent the worms, lack of state did that. A stateful filter that doesn't need to mangle the packet header is frequently called a firewall (yes some firewalls still do, but that is by choice). Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Oppermann Sent: Friday, July 08, 2005 4:42 AM To: Fergie (Paul Ferguson) Cc: [EMAIL PROTECTED]; nanog@merit.edu Subject: Re: mh (RE: OMB: IPv6 by June 2008) Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. -- Andre
Re: mh (RE: OMB: IPv6 by June 2008)
Crist Clark wrote: And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. Any by connecting to one of the p2p overlay networks you'll have a few million in-use addresses momentarily. Pete
Re: mh (RE: OMB: IPv6 by June 2008)
In message [EMAIL PROTECTED], Tony Hain writes: Mangling the header did not prevent the worms, lack of state did that. A stateful filter that doesn't need to mangle the packet header is frequently called a firewall (yes some firewalls still do, but that is by choice). Absolutely correct. Real firewalls pass inbound traffic because a state table entry exists. NATs do the same thing, with nasty side-effects. There is no added security from the header-mangling. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: mh (RE: OMB: IPv6 by June 2008)
Petri Helenius wrote: Crist Clark wrote: And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. Any by connecting to one of the p2p overlay networks you'll have a few million in-use addresses momentarily. Preventing abuse of information available from databases maintained by P2P services is an emerging and interesting area of info sec. It may become more so as other means of harvesting live addresses become less productive. In The Future, the addresses of live hosts to attack may become an underworld commodity like valid email addresses are now. All of those are better than having Blaster or Slammer propagate so easily. At least make the malware authors work for it. If you were behind NAT, you couldn't use those P2P applications. So, yeah, you were safe on your limited-functionality, pseudo-IP, NATed connection from the Big Bad P2P. And if you still want the protection of NAT, any stateful firewall will do it. IMHO, if there is any reason NAT will live on in IPv6 it is the PI space issue. Even the NAP draft comes out and says, 4.7 Multihoming and renumbering Multihoming and renumbering remain technically challenging with IPv6... That plus the problems with the unique local proposals make it quite likely that NAT will not completely disappear should IPv6 become widespread. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
