[OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

[Gui Iribarren]

adding more wood to baptiste fire... :)

On 16/07/14 06:15, Baptiste Jonglez wrote:
> 2/ Allow inbound traffic in the home gateway's firewall.  In an
> ideal world, this is the best solution, since it leaves all the
> intelligence to end nodes (in accordance with the end-to-end
> principle).  In practice, it is generally frowned upon for home
> networks, as people don't have any control on their own end-devices
> nowadays.  This is quite sad, but that's a different story.  Note
> that it is not a "all-or-nothing" solution: the initial proposition
> was to only allow UDP ports > 1024 by default, not *any* traffic.

What if we put it the other way around:
enterprises who built end-devices have neglected investing in security
measures, comforted by the fact that all these years the de-facto
scenario was that inbound connections were technically impossible
unless explicit rules were put in place. (port forwards)

then, what happens when those devices are deployed in a myriad of
real-world scenarios? hackers rejoice!

http://www.networkworld.com/article/2223785/microsoft-subnet/unpatched-trendnet-ip-cameras-still-provide-a-real-time-peeping-tom-paradise.html
http://www.forbes.com/sites/kashmirhill/2013/07/26/smart-homes-hack/

if we wanna do something good for the "people that don't have any
control on their own end-devices", that'd be: leveraging openwrt
position to shift the "de-facto" landscape of SOHO networks,
implementing open-by-default ipv6, and thus push the people who *do*
have control of those end-devices (manufacturers) implement proper
security.

> 
> 3/ Use a firewall control protocol, so that end devices can request
> port forwarding.  There are several protocols for this: UPnP,
> NAT-PMP, PCP. This is not ideal from an end-to-end perspective,
> since a state must be maintained in the home router.  If the router
> reboots, all mappings are lost.  Note that PCP deals with this in a
> mostly reasonable way [1], so it should not matter a lot in
> practice (not sure about UPnP and NAT-PMP). Additionally, it
> requires a modification to the applications, but it's not a big
> modification (we've been doing with IPv4 for years, using UPnP and
> NAT-PMP).

to me, the logic is flawed here: why break existing functionality
(free native flow of ipv6 traffic), then implement a control protocol
to make it work again on the firewall side, and in the end modify
applications to use that protocol?

If you're going to modify applications in the first place, then simply
bind the services to the correctly scoped ipv6 address.

If the concern is about an hypothetic legacy application that assumes
the local network is private and trusted, and is suddenly exposed by
global ipv6 connectivity... i have yet to find such a case ;)
all potentially vulnerable software i come across was a) either
written from an ipv4-only perspective and doesn't actually bind to
ipv6 addresses at all; or b) evolved to support both protocols but
binds to ipv4-only by default

...just my end-2-end-cents, Cheers!

gui
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel