[OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
fhfrediani at gmail.com
Fri Jul 18 00:18:43 EDT 2014
A typical home connection is not an ISP.
Also OpenWRT for the majority of the cases isn't just 'a router', but
also as a firewall and to protect user's network either on IPv4 or IPv6,
not just a dummy bridge device.
I guess I see the good intentions of those defending it should be
opened, but that is taking in consideration only a specific technical
point of view and thinking only how it "should" be in an ideal world.
However the reality that must be taken in consideration are the
real-world effects of this which will certainly bring more problems than
If a "problem" must exist, I prefer it to be that the user have to spend
a minute or two to adjust his router's firewall adding the few
exceptions that have to be allowed into his network.
On 18/07/2014 04:56, Gui Iribarren wrote:
> On 17/07/14 21:59, Fernando Frediani wrote:
>> Perfect and well said.
>> Really don't see why people still think leaving firewalls opened is a
>> good idea.
> leaving *hosts* firewalls opened is a really bad idea. Agreed.
> But openwrt doesn't run on hosts, it runs on network equipment
> I.e. the building blocks of Internet.
> Carriers don't block traffic,
> ISP don't block traffic,
> and back in the day, CPE equipment didn't block traffic either (think of
> dialup, or dumb cablemodems which would simply act as a bridge)
> "firewall" was a software installed in the computer connected to the
> Then, with the ever increasing quantity of devices vs the evident
> shortage of IPv4, people started to use NAT, or ISPs started to ship
> CPEs that would do NAT, which made two-way transparent communication
> I find it difficult to argue that NAT success was driven by a security
> concern, rather than by IP scarcity. :P 
> Fast-forward a few years, we have a new Internet Protocol being widely
> deployed that solves the address scarcity, and thus makes NAT unnecessary.
> Now CPEs can work again like transparent devices.
> ps. RFCs that argue that NAT resulted in a *reduction in security*...
> : http://tools.ietf.org/rfc/rfc6092.txt , january/2011
> Security Considerations
> The IPv6 stateful filtering behavior described in this document is
> intended to be similar in function to the filtering behavior of
> commonly used IPv4/NAT gateways, which have been widely sold as a
> security tool for residential and small-office/home-office networks.
> As noted in the Security Considerations section of [RFC2993], the
> true impact of these tools may be a reduction in security. It may be
> generally assumed that the impacts discussed in that document related
> to filtering (and not translation) are to be expected with the simple
> IPv6 security mechanisms described here.
> In particular, it is worth noting that stateful filters create the
> illusion of a security barrier, but without the managed intent of a
> firewall. Appropriate security mechanisms implemented in the end
> nodes, in conjunction with the [RFC4864] local network protection
> methods, function without reliance on network layer hacks and
> transport filters that may change over time. Also, defined security
> barriers assume that threats originate in the exterior, which may
> lead to practices that result in applications being fully exposed to
> interior attack and which therefore make breaches much easier.
> : http://tools.ietf.org/rfc/rfc2993.txt , november/2000,
> 11. Summary
> NAT advantages - no item about security
>> At the end it will bring more problems than solutions for those using
>> OpenWRT and play against its good reputation.
>> As mentioned before adjusting firewall for specific needs or using UPnP
>> isn't the end of the world.
>> On 18/07/2014 01: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?
>>> 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"
>>>> <gui at altermundi.net> wrote:
>>>>> Benjamin is giving some great examples of real-world scenarios where
>>>>> 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
>>>> 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
>>>> -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
>>>> 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.
>>>> openwrt-devel mailing list
>>>> openwrt-devel at lists.openwrt.org
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel