On 17/07/14 21:03, David Lang wrote: > I know that IPv6 designers pine for the "good old days" of the Internet > when no security was needed. > > But the reality is that hackers and worms have shown that leaving > systems exposed to the Internet is just a Bad Idea. > > As such, the idea that IPv6 would "restore" the "everyone can connect to > everyone on any port" of the early '80s was wishful thinking at best. > > link-local addressing isn't a good idea, because the average home will > have three separate links (wired plus two bands of wireless), these can > get bridged together, but that causes problems as well. > > There is no answer here that will satisfy everyone. > > But do you really want to see the news stories about how anyone running > openwrt is vulnerable to $lastest_windows_exploit but people running > stock firmware aren't?
Hello, thanks for joining the conversation, you might have not spotted this email https://lists.openwrt.org/pipermail/openwrt-devel/2014-July/026813.html as it is now, the situation is actually the opposite of what you're describing, it's more like: "Hey, my VoIP calls are failing, as well as PopcornTime videos, since I installed OpenWRT. They were working just fine with stock TPLink firmware" Have you got any examples of stock firmware that blocks incoming traffic by default? In this discussion I have only seen talk of two that don't. cheers! > > Yes, it would be ideal if every host was locked down so that it was safe > for them to be exposed. > > But that's not the world we live in. > > David Lang > > On Wed, 16 Jul 2014, Lyme Marionette wrote: > >> ----- Original Message ----- >> On Wednesday, July 16, 2014 2:10:53 PM "Gui Iribarren" >> <g...@altermundi.net> wrote: >>> Benjamin is giving some great examples of real-world scenarios where >>> an >>> default-open firewall simplifies administration, >>> and where a default-closed firewall would be not only unnecessary >>> (provides no benefits), but would indeed complicate setting up >>> things. >> >> There have been many good arguments posted on this subject and to >> throw my opinion in, it a question of effort and expectations. >> >> I think everyone can agree that: >> -It takes equal effort to turn a firewall on, as it does to turn one off. >> -It takes equal effort to create a specific block list, as it does to >> create a specific allow list. >> -UPnP is not included by default for either the ipv4 or ipv6 stacks. >> >> I would also go further to suggest that: >> -Consistency is good, even if it consistent for superficial reasons. >> >> We know that, for NAT reasons, that the ipv4 stack by default blocks >> incoming connections: >> -Because it doesn't know by default where to route them. >> -ipv4 end-points have been traditionally insecure. >> >> The two ways to get around this (for gaming, etc): >> -Through setting firewall rules to route the traffic to an end-point. >> -Through the use of UPnP (which is used by most games to host, and >> gaming consoles). >> >> With the adoption of ipv6 there is the opportunity to change this >> behaviour such that instead of incoming traffic being restricted for >> technical reasons, that incoming traffic is routed to the correct >> end-point. >> However, that begs the questions: >> A) Is that consistent with what people would expect? >> B) Are ipv6 end-points secure by design? >> >> In regards to A, from the mindset of a non-technical user, would wager >> that the answer is 'no'. Even though there is a change in technology >> with ipv6, the ipv6 technology fulfills the same role as ipv4 and this >> could be seen as opposing direction between the two. This would likely >> catch many end-users by surprize unless they read the small print >> regarding this. >> >> As for B, given my view of software development, applications, >> networks, etc (I've been in the IT business for over 25 years now) I >> would wager that 80% of applications are secure, and that the 0ther >> 20% make the potential change in policy very risky. >> >> IMO, which others may disagree with, would be to include UPnP by >> default which would/should resolve most of the hosting issues. >> >> Thanks. >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel