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

[Baptiste Jonglez]

On Tue, Jul 15, 2014 at 11:45:27AM -0400, Aaron Z wrote:
> As I understand it, if a device on the inside of the network initiates
> the connection to a device on the outside (say from a VOIP phone to a
> VOIP server), return connections from the server are allowed.

Yes, this is exactly the role of a stateful firewall.

I assume your VoIP example is about SIP.  This is an interesting example,
because actual voice traffic (RTP) will flow *directly* between endpoints,
without going through the server.  Obviously, this will fail if your
firewall blocks all unsolicited inbound traffic.  See:

http://blog.lithiumblue.com/2007/07/understanding-relationship-between-sip.html

> What gets blocked are unsolicited connections from the outside which are
> generally unneeded (and can be a security risk) unless one is running a
> server (in which case, the users should know how to open ports on their
> firewall).

You have a client/server model in mind.  These is not the only kind of
applications out there (see my previous examples: voice or video chat, P2P
file sharing, network games, etc).


This is all about end-to-end reachability, and the end-to-end argument:

  http://coreinternetvalues.org/?page_id=1415
  http://tools.ietf.org/html/rfc3724
  http://en.wikipedia.org/wiki/End-to-end_principle

End-to-end reachability has been mostly lost with the IPv4 NAT.  We have
invested tremendous efforts into ugly workarounds for this lack of
end-to-end reachability: ICE, TURN, STUN, UPnP, many ALG, etc.  So,
really, IPv4 should not be the model and these ugly workarounds should not
be seen as natural.  IPv6 brings back end-to-end reachability, with all
its virtues.

Now back to practical issues.  My favourite use case is video over XMPP
(since I ran into this issue).  Let's say you want to establish a video
conversation with somebody, using XMPP (Jingle).  Assume that the stateful
firewall of your home router discards all unsolicited inbound traffic,
and does not implement any firewall control protocol (for instance, it is
running a default installation of OpenWRT).  Then, video will just fail:
you won't receive any video from your friend, because it is sent directly
to you, and your firewall drops it.

The same applies if you want to run a game server, use a P2P file sharing
system, or more generally any system based on peer-to-peer communication.

Note that I'm only talking about IPv6, so NAT is out of scope: in any
case, this is really a matter of stateful firewall, not NAT.  You have
three general classes of solutions to solve the above problem:

1/ Modify the applications to use intermediate servers for communicating
   between peers.  This is very complicated, inefficient network-wise
   (since you add an extra intermediary instead of sending traffic
   directly), and completely misses the point: it basically introduces a
   client-server model where it's neither needed nor desired.

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.

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).


Currently, OpenWRT implements none of these methods (2/ or 3/), since
miniupnpd is not included by default.  If we want to fix this, I have a
personal preference for (a limited version of) 2/, but 3/ is also fine.
Note that both approaches are not incompatible, and it could actually be a
good idea to do both.

Regards,
Baptiste

[1] http://tools.ietf.org/html/rfc6887#section-14
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140716/843bdd53/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel